No, this is not a traditional “Linux distro”. The RoxOS guys are feeling like innovating today, even by breaking legacy and some compatibility at places with other Linux distros or Unix. RoxOS is a desktop OS which is evolving by using existing tools (Linux kernel, X11, ROX Filer, gnu etc), but somewhat modified (e.g. new filesystem hieriarchy and dependancy on filesystem’s metadata). Most apps will probably
need repackaging or altering in some way in order to run on RoxOS. Join the discussion or the project. This project was made known to us after the long discussion we had the other day about innovation and on creating a new OS, but by re-using existing tools and extensively modifying them, in order to cut production time and to easily get hardware support (via X11 & Linux or FreeBSD’s kernel).
RoxOS Discusses the Possibility of a New Linux-based OS
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
First, nice to see some fellow estonians hit the front page of OSNews
Second, RoxOS seems like a good idea. Let’s just hope that they dont mess things up like RedHat did. And I’ve been using ROX-Filer for quite some time, also built a Gentoo install around the ROX Desktop. I must say, it was very cool and comfortable.
…be interesting to see what they accomplish over and above what you can do without breaking compatibility. I’m a bit puzzled what it might be, but I guess I’ll just have to wait and see.
So long as others don’t decide to break compatibility too. While I appreciate how much easier it is to ignore legacy, we certainly don’t want another UNIX-like splintering of the market. It’s bad enough already. 🙁
-Tim
http://lemmit.offline.ee/home/green/Linux/ROX%20OS%20Filesy…
Doesn’t the red colour font hurts your eyes too? I think, they need to change the colour or something else.
Anyway, when it’s arriving to the stable/mature level and I wouldn’t mind to give it a try. 🙂
I think it would be neat to start seeing projects basing themselves on BSD kernels. I think it would help everyone out in the long run. By supporting BSD kernels, they support the BSDs in general (who are in need of support), and by packaging stuff over them, it would encourage OSS projects to make sure that their stuff doesnt only run on linux but on other unices also. It would also give more variation on how distros can go about and do things instead of trying to stick to the “linux mentality”.
I think you’ll find the red font is used for a reason. It won’t be appearing on final documents.
This is not really innovation is it?
ROXdesktop is based on RISCOS, and that had application directories about 15 years ago roughly, eh?
UNIX file systems are unlogical if you ask me and i have been waiting until someone started renaming stuff in a more logical way, i think i will like this when it reaches testing time
I agree with your comment about wanting to see more projects being based on the BSD kernel. I would have to say this project is an attempt to get away from the ‘linux mentality’ rather than stick with it.
I disagree. I firmly believe that you can create something really nice, when you shave out all the legacy stuff, and build your OS on top of existing toos, but modified. For example:
Use the linux or FreeBSD kernel (it doesn’t matter which one you choose, you just need something mature to base your OS on), but modify it to make it easier on installing/uninstalling new drivers via GUI tools.
Change the glibc, which is known to be a pain and a mess. Use another libc if possible. That would make you lose binary compatibility possibly, but at least it could give you a clean system.
Add resource forks to ELF.
Use Qt and the kde-libs to create a brand new dekstop environment, that it is _not_ KDE. It won’t have a kicker for example. It would be new. You would just need the existing tools to do what you want!
Change the file system hieriarchy the way BeOS, AtheOS/Syllable and MacOSX does it (via virtual fs, while the system or posix dirs are hidden). However, no matter how much binary compatibility you might lose, _make sure_ that your OS remains POSIX. This is a must have.
Restructure the way you install/uninstall applications and where, define a policy about dependancies etc.
Rethink a brand new DE, something that can compete with OSX’s sexiness and XP’s productivity. Get a clean sheet and start over for this one.
Make sure that the whole DE is **integrated** to your OS. Current DEs on Linux are not integrated, because these DEs are running on different flavors of Unix or Linux distros. Having proper integration is what could make such a project fly.
And remember: By creating something like this, you DON’T take away Linux from its users. The Linux distros will REMAIN as they are. This would be just a different project to create a *new platform*, as opposed to a new distro. This is what I would call innovation, and I hope that someone with the money can do it. I don’t believe that an open source group can do it as well as a company, simply because open source groups are governed by geeks, who give no flying monkey what the UI/usability designers say, so they end up with yet another X desktop.
Anyways, I was supposed to write an editorial about it a week ago, but now I started learning french, don’t have the time, so I will just discuss it here.
ROX is not based on Risc OS. However Risc OS did have some nice features. Some people have suggested considering including some of the ideas into the project.
If they’re set on breaking legacy why not ditch xfree and go for a kde only system running scitech SNAP drivers for QT.
Drivers.Drivers, Drivers, Drivers, Drivers.
sorry but thats a fact. BSD does not have the drivers for consumer devices that the Linux kernel does and will have.
BSD is a fine Kernel though, so its not AFAIK some kernel prejudice or anything.
Ditching XFree is no GO.
XFree is not too bad, and in fact, it has such extensive support for graphics cards, that you will need another 10 years to re-create something like this. And on top of this, remember: we are re-using tools to cut production time. This mean, that if you ditch XFree, you will lose easy GTK+, KDE and Qt integration and porting. X has to stay. Throw glibc if you want, but X is a must-keep.
But do not forget: we said that such a project would be based on modifying existing tools. So, there is nothing stopping you from modifying or optimizing XFree, simply because we are not afraid to lose compatiblity (however, you must keep source compatibility regarding the X stuff)!
As for integration I talked earlier, starting with such a semi-clean sheet, you can port GTK+ and Qt/KDE apps to look and behave EXACTLY the same, a level of integration much better than BlueCurve’s which is only on the surface.
I think you’ll find the red font is used for a reason. It won’t be appearing on final documents.
Actually, the answer is no when the background is dark grey. It’s same as with blue font with black background. I doubt many people can read this, which it does hurt the eyes. It is good reason to use red font, when you have the white, lighter grey or else background.
>GTK+ and Qt/KDE apps to look and behave EXACTLY the same
And that won’t mean that GTK+ would have to look like Qt apps or the opposite. Both will be modified (but still by keeping as much source compatibility as possible) to look something new! They will need to look as the new DE that you would design. Same will go for the Java apps, they will need to look the same. Unix/Linux already have this problem having a single screen filled up with toolkits that are completely different, at least for such a project make them behave as they should.
Take some pointers from MacOSX for example. This is what Apple pretty much did.
BlueCurve is nothing more than a fancy theme IMO, although a fairly nice one.
Eugenia, you hit it on the head…everything you said is exactly what Rox is doing. one of the things I am excited about is we are using ONE widget set. we want consistency. and progrmas will be easy for the end-user to install/uninstall (drag and drop)
as far as breaking legacy…look at the linix world as is…most apps need to be build for each distro anyway…so if binary compatability is broken becasue we have a diffrent libc…oh well, it is not like it is harder to build the package for our system becasue of that. how app dirs will affect it, I don’t know becasue I am not an app dir expert, but I do know it is much better for the end-user and that is what this is focusing on.
Exactly. There is no real integration between KDE and GTK+ apps.
The project I am discussing about should be able to modify all the supported toolkits (GTK, Qt, Java etc) to look AND behave exactly the same.
More over, if we are talking about a desktop OS, I would make the “X11’s third mouse button paste” optional. It creates more problems to newbies than being a feature.
> Eugenia, you hit it on the head…everything you said is exactly what Rox is doing.
I don’t think that RoxOS are going as far as I would like them to go. Their changes are not so groundbreaking, it is still IceWM with Rox-filer, with no new DE.
Without these guys get dirty with the low level stuff, like gcc, glibc and kernel, I still consider RoxOS a “linux distro”, and not a brand new OS. There is a lot of work to be done before you say “I created a new OS based on the Linux or FreeBSD kernel”, and dealing only with the high level stuff, like filesystem hierarchy and a bit with the desktop, it just doesn’t justify the word “new OS” (even if I respected their wording and used that in the article).
I do belive we are putting a new libc in…but don’t quote me on that. and Ice-WM + roxfiler with a consistent look and feel. there is nothing wrong with IceWM as a base. it is fast and clean and provides a nice productive environment to build upon.
Eugenia, maybe you should put your vision in an article? Just a thuoght.
More things:
Fix the current problem of resource forks in the ELF format, so you can incorporate icons and other info inside the binary.
Define policies about dependancies, so apps won’t have to overwrite system libraries, but they can include their own in a <app folder>/lib/ dir (as in BeOS, the system first looks there, and then in the OS system lib dirs) or do it the OSX way and include them all inside a single package (this way might have a few setbacks).
Optimize X for speed and create a window manager that doesn’t say “I am here, I am here” ever 1/100 of the second or something.
Use Qt, kde-libs to recreate a new desktop. Take Konqueror apart and make it usable, instead of having a zillion menus on it that most of the time are only relevant when you are using a different Konqueror module. Another problem currently is that the Trash on KDE is just a folder, so it doesn’t have its own context menus (this is actually fixed in the CVS now). I think you get the idea: get all these shortcomings that KDE project are afraid of taking care of in order to not lose their compatibilities, and do break compatibility and recreate something that works well and looks modern.
Make sure that GTK+ and Java or C# or Python GUI apps, are all look and behave the same. All should have the same level of integration with the OS and with eachother.
Important: Linux distros are breaking compatibility with themselves all the time. An RPM that works on version 7.3 might not work on version 8.0. With the new OS that we are discussing, apps created for version 1.0, should still work on version 5. Break as much legacy now, but keep a layer of compatibility for the future. Desktop systems are not known for breaking compatibilities wiht themselves.
Again, a lot of work will need to be done UNDER the hood. Fix that damned LD loader, which has trouble with C++ code. Use another libc. Use a BSD-like system for your init or your /etc operations, but make sure that all that are completely transaprent to your user. However, advanced users should still be able to open a terminal and do stuff with the comamnd line. Give the power to both kind of users (desktop and power users). Like OSX does.
Oh, and keep POSIX in tact and source compatibility as much as possible. That will pay out later, when devs won’t have headaches to port their apps.
As for the new DE, make it sexy. Make it as good and as LOW BLOAT and as STRAIGHT FORWARD as it can be. Because we like it or not, most users are drowned to a new system for trying it, first on the way it looks and then on the way it works. So, make it sexy and easy to use. But of course, make sure it works. Define a bug policy.
Tell developers to never create apps that require a zillion dependancies. The developer should release apps for the apps.myOS.com and these apps should be accepted there only if it fits the requirements of releasing apps for this OS: no big deps (or use the /lib dir in the custom package), if you are creating a file manager make sure it respects the metadata, use the UI guidelines etc.
A lot of changes will be made for existing apps by the OS group. For example, when someone from the OS is porting KOffice to include it in the iso, UI changes might be at hand in order to comply with the new DE.
Applications installation, uninstallation and launching should be served from the same place. I have a few ideas how to make this, but that will need altogether a new article…
Has anyone taken a look at LinuxSTEP? While many aspects are currently only experimental… LinuxSTEP does have a very comprehensive and well thought out FileSystem layout.
>Eugenia, maybe you should put your vision in an article?
I just wrote a comment above, which outlines my ideas, but indeed, it is not as extensive as an article. Not all my ideas are in my comment.
I have worked the past few months on a new UI paradigm regarding application installation/launching/uninstallation. I will be needing to write that down and publish it at some point…
Eugenia, our system is considrably more than “IceWM and ROX.” It’s a fundamental change from the traditional UNIX-type operating systems that are ever-growing in popularity. Instead of worrying about package mangement, you just drop the AppDir in to your ~/Applications directory, and you’re ready to go. The FS layout alone is a massive shift away from the standard UNIX way of doing things. The use of metadata is a welcome addition, and as for the screenshot on lemmit’s page, which I belive colored your view of our system, we have not decidedwhat WM we’ll be using. That screenshot was taken on a debian system, and is more meant to introduce the concept of AppDirs to those not familiar with them, rather than introducing our project. We also have some changes for ROX in mind as well, but we’re working on having a solid, functional comman-line system before we expent the effort to port XFree86, ROX, et al. If anyone has any questions, please feel free to ask us on the ROX OS mailing list, and if anyone wants to join the project, we’ll take just about anyone, coding skills or not.
Just to point out that an ELF object can have non-executable data embedded into it. AtheOS and Syllable can use this. See os::Resources and rescopy. There is no reason a Linux based system could not make use of these too.
that has been discused.
some of the stuff she puts up though has not been disscused as a goal yet…Rox might want to take them under advisment.
Vanders:
This is exactly why I say that modifications (and maybe compatibility problems might emerge from this) should be done to all these tools (not just ELF). Because the current ones, are staying as is, because people afraid to destroy the legacy. The OS we are discusing for, would shave off all this legacy and add proper support for modern things. While binary compatibility might get lost
when you do such changes along the way (not just for ELF), I clearly say that source and POSIX compatibility should be kept as safe as possible.
For me, this “new OS” based on existing (modified) technologies, is the only way to get Linux or FreeBSD or *whatever* kernel, closer to the desktop/workstation user (without taking the power away from the power user).
Linux distro companies *will never* get there, not only because of the legacy problems they are afraid to shave off, but because they are short sighted already. They don’t see the big picture and where they can go by creating a new **platform** (as Apple did with OSX by using BSD), instead of “yet another Linux distro”.
They don’t have the guts. Nor the money. (pick one or two
. On the other hand, open source groups are not listening to UI/usability designers. I believe that to create what we discuss here, SUCCESSFULLY, it requires a company that wants to innvovate, that has the vision AND the money to do so. And that is not an easy feat, to find funding for such stuff today…
In other words we should build something like OSX but with qui based on KDE/QT
“Use Qt, kde-libs to recreate a new desktop. Take Konqueror apart and make it usable…”
I think its quite obvious that they are using ROX as the file manager. And that uses GTK.
Yes, but my discussion is not about RoxOS exactly. My discussion is about more general stuff, how it could be done to maximize innovation and interest from the public, not necessarily what RoxOS does.
How does this compare to <a href=”http://www.gnustep.org“>GNUstep or GNUstep based Distributions/OS concepts like SimplyGNUstep?
Is there anyway those two projects could help improving each other?
dev0
Ok, Eugenia, let’s assume someone with the money creates this brand new, innovative OS from the bsd or linux kernel. What are you gonna do about the apps?
Hi all,
I’d like to know more about your implementation of AppFolders. Last time me and Thomas Leonard discussed this, he didn’t have answers to a lot of my questions on exactly how such a system scales etc. Considering that even Apple distribute the new versions of the iLife apps as installer .pkg files, I want to know how you intend to avoid the same fate: namely, how will you make appfolders work, when most other implementations don’t?
Don’t get me wrong. I’d love to see such an implementation work, and I’ll give you some hints on how to do it below. But I think you’d need to do some low level work on the filing system first, probably pretty boring stuff.
One thing you might want to look into is making files and directories code objects. What does this mean? It means, FS objects are instances of classes, and can subclass other types of objects. That allows you to have “smart” directories, which IMHO are a must for any decent appfolder implementation. Obviously you need to be careful about the security implications of that.
But for instance, when you “trash” an appfolder, you have to consider:
– How do you clean up preferences files (macos simply does not, it just throws away disk space and inodes)
– How do you unintegrate it (file associations etc)
And when you drag one into the applications folder:
– How do you manage dependancies. MacOS simply has no dependancies, ie it’s centrally controlled. They use something called weak symbols to allow an app to launch even if some APIs it needs are missing.
glibc isn’t so bad. It needs some things changing however, for instance, investigate the symbol fixup search algorithm of ELF. I can explain this in IRC if you want to know more. Basically it means you can’t have multiple major versions of the same DSO in the address space at once. It’s basically a “bug” in the ELF specs. My plan is to either fork ld.so, or try and get the LSB to alter the search algorithm in the LSB specs (the lsb has its own linker). We have to do that, because we are trying to steer Linux as a whole, but you guys can do whatever the hell you like, so fix this first.
Common misconception that you have to use scripts if you want the binary and the libs to be in the same directory. Not so! The other day I came across a little known quirk of ELF, if you use the string ${ORIGIN} in dlopen() or the link stage of an app, then it’ll be replaced with an absolute path to the binary being linked, meaning you can link against libs in a relocatable fashion without needing scripts or hacks to ld.so, just alter libtool to use this substition appropriately. More info can be found in the System V ABI specs.
Eugenias suggestion of adding resource forks to ELF I don’t really agree with – why bother making the file harder to access when you can simply stuff it in the appfolder?
You’d need to have some way of efficiently transferring folders across the net, something we do badly today. For instance, what if you wish to email me this great piece of free software you’ve found? On Linux, we have to send a .tar.gz if we wish to send a folder. That’s ugly. Better, to just let users drag FS objects into the mail program, and have it transparently compressed, so it appears in the mail app as a folder that can be opened, dragged in, dragged out etc.
Look into LUFS as the VFS system. You can plug programs into the VFS very easily this way to provide for instance a ~/System directory. If you use english names in a VFS plugin, it should be for the user only, DON’T allow programs to use it, otherwise the english names become fixed and can’t be translated.
Oh finally: @Eugenia
I think you don’t “get it” with respect to Linux. What we have today is the result of over a decade of hacking, more if you count Stallmans pre-natal work. You don’t just throw it all away every few years and start over, if we took that approach Linux would still be in the 1996 era, perhaps less hacky, less crufty, but less advanced also.
Also I don’t agree that the Linux distro companies are short sighted. They know that Linux is flexible enough to do anything, but they also know that Desktop Linux is still missing big pieces, it’s not just a case of a different UI, a different packaging system or putting icons into binaries. We need better hardware support from the vendors themselves, Wine needs to be far better (getting there fast), strong office suites are needed, interactive training, NTFS resize/write support and so on and so on.
Those things aren’t stuff you get just by starting over, fiddling with glibc.
So, I think you need to be more realistic. There’s no reason Linux as you see it today can’t be a great desktop OS. You don’t need to embed icons into binaries, nor do you need to deploy appfolders, nor do you need to break backwards compatability just for the hell of it. Maybe if these guys do that they’ll get there first, but they’ll have done so at the cost of not dragging everybody else behind them. So both approaches are valuable, ROX-OS if it succeeds in building something truly new will show us new techniques and ideas, but make no mistake, Linux as it stands will be what most people use. MS know the same thing, breaking backwards compatability just for the hell of it is very bad. Only Apple have done so, and they are finding it tough indeed as you well know. There are large parts of OS X that are still not mature yet.
Anyway, rant over. Good luck to these guys. I’m still not sold on appfolders though :p
recompile the apps 😉 it is just binary incompatable (which most linux distros are anyway)
> Fix the current problem of resource forks in the ELF format, so you can incorporate icons and other info inside the binary.
We’ll use XFS’s extended attributes. Of course for applications we don’t need this. ROX-Filer application directories can do all this and more. They provide a tooltip, an infobox exposing things like authors, license, project homepage. And you can browse the help files without launching the app.
> Fix that damned LD loader, which has trouble with C++ code.
As we won’t use KDE this is no big problem for us. It’s really only KDE which exposes this weakness of ld. Pure Qt
apps, even larger ones like QT-Designer pop up instantly. Same with Gtk– and wxGTK apps.
> Applications installation, uninstallation and launching
> should be served from the same place. I have a few ideas
> how to make this, but that will need altogether a new
> article…
Guess what. This is already a reality. On my machine I have some 150 apps running from inside appdirs. Even bitches like Evolution. Installation/Uninstallation are done via drag & drop.
Oh finally: @Eugenia
I think you don’t “get it” with respect to Linux. What we have today is the result of over a decade of hacking, more if you count Stallmans pre-natal work. You don’t just throw it all away every few years and start over, if we took that approach Linux would still be in the 1996 era, perhaps less hacky, less crufty, but less advanced also.
Maybe you don’t get it. Eugenia is not proposing a new Linux system. It would be based on a mature kernel, like BSD or Linux, but it’s not going to be a new distribution of Linux! Yes people have done lots of hard work, but that doesn’t mean things are already optimal, and couldn’t be changed for the better.
Eugenia,
Could you give an explanation why glibc should be replaced
(or could you point out a few references)?
Also, you mentioned that a new desktop should be created
with QT and kdelibs, and that the desktop should be
lean.
I agree that the desktop should be lean, but
I’m not sure how you can achieve this with QT3.
On my SuSE linux 8 system,
A simple “hello” program written in QT3 (under 20 lines
of code) has a virtual memory size of 12.5 MB and
a resident memory size of 5.5 MB. I appreciate
both QT3/KDE3 and Gtk2/GNOME2, but I have a major
issue with the memory requirements. Just as a
comparison, a minimal program written with only
Xlib require just 800K of resident memory and
2.2 MB of virtual memory.
it sucks…it looks like crap and is limited.
Anonymous, thank you. Mike really doesn’t get it. We discussed about it 5 days ago, and he still doesn’t understand what I am trying to propose. Yes, the Linux kernel has 10 years of work behind it and that’s great. It is mature. Hell, this is why I am proposing it as a base for this new OS. However, the whole distro/unix system has a 10 to 30 years of legacy behind it, which is what I am trying to shave off.
But in the system I propose the kernel is just a part of it, and _maybe_ the one which would require the less modification. By no means that kernel would be the center of the universe, as it happens today in the Linux distros. I am not tying to create a new distro. I am trying to create a new OS, that happens to be based on *modifications* and ADDITIONS on top of proven technologies. And in fact, I am not even talk about the Linux kernel! It might just be the FreeBSD kernel. I would personally only pick the Linux kernel because it has better hardware support, not because of another reason.
As for the XFree discussion we had earlier: yes, Xfree does have limitations, but at some point, you need to outweigh the good and the bads, and you will soon see that if you lose graphics card driver support, no matter if your new X-Server or new graphics subsystem is able to bake cookies, you will end up losing users who are not happy running VESA. You will have a market and a userbase who will need to answer to. And in that respect, X has to stay. Don’t forget, you can always optimize or modify X, nobody is keeping you away from that.
>What are you gonna do about the apps?
You recompile them. Where were you when we said that source compatibility and POSIX would have to be there?
Of course, new stuff will be introduced, so in order to have a binary port, instead of taking you half an hour, it might take you 2 hours. Big deal. Bottomline is, the source compatiblity will be largely there.
>There’s no reason Linux as you see it today can’t be a great desktop OS.
There are a lot of reasons. I have emailed a few people in some distros, including Mandrake and Red Hat and SuSE people, and when I ask them “why we can’t have this? This will greatly help usability”, I get a zillion reasons about how you break the compatibility with older systems and status quo, or because of this and that. Bottomline: the current Linux distro status quo just doesn’t go “there” as fast and as directed as it should be. Gnome and KDE are NOT integrated to the OS, they don’t work with the OS, they work with themselves only. The OS I am trying to propose would have all these issues FIXED. Because the tools/libs would be modified in a way that helps integration. It would be an OS design, as opposed a few hackers doing their thing and then throw them all together in a CD and call it a “distro”.
>What we have today is the result of over a decade of hacking, more if you count Stallmans pre-natal work. You don’t just throw it all away every few years and start over
Who said that you are going to throw away stuff? You just keep what you need. You still don’t understand. Apple very successfuly kept what they needed from Mach and BSD, and they built their thing on top. And it works. Much nicer than ANY Linux distro. Linux distros exist since 1993. OSX was introduced in 2000. In 2 years, OSX has come 10 times the way the Linux desktop has come in 10 years. That’s a 100*fold. And there is a good reason behind it: ONE vision, Innovation, ONE focus, standards, developers who do as they told, bug fixing (as opposed to waiting the Linux distro employees to actually clean up the bugs of the hackers…) etc etc.
Again, you are thinking that I am proposing to all distros to leave behind what they have and start over. NO, I do NOT propose that. I propose ONE company, with the money, to start create a new platform, based on existing technology. The Linux distro status can remain as is. No one is taking your Linux away. You could still use Debian or Red Hat the way it is today. What I am suggesting has nothing to do with “the future of Linux” as you know it. It is simply a project to innovate, and why not, to capitalize on it.
>Could you give an explanation why glibc should be replaced
Another libc would be more appropriate. The glibc even when it is compiled for i686 is not as fast or effiecient, plus when you try to embedd it on another project is just a pain. I was part of an OS project some months ago and glibc was just a big “no-no” to port it. It was just unmaintanable.
>I’m not sure how you can achieve this with QT3.
The important thing is that Qt is one of the most complete toolkits out there. It can do more than GTK+, and KDE-libs have a pretty modern infrastructure. In my mind, Qt is the toolkit to use. BUT, as you said, there are some bad things about QT, like speed and memory requirements. And this is where AGAIN I have to write about it: modify it. Change it. FIX it. This is what this project is all about. Nothing will come as a “simple recompile” when it comes to the system. It will need work to bring it to a level that will make you happy to use it. Otherwise, don’t start the project at all. And my gripe is that OSS devs are mostly interested in starting new stuff instead of debuging and optimizing other people’s stuff. This is yet another reason why I am afraid why such a project won’t work as well as an OSS project, but it needs a company behind it.
I can’t speak for Eugenia, but what I’m after is a linux-based OS that just works, and that I can recommend to possible converts in good faith.
I already explained two reasons why I would prefer and why I think that such a project would work better if it was done by a company and not by an OSS group.
1. OSS Developers don’t listen to UI/usability designers by large. Only a few of them do. You see, there might be a UI spec that require you to code it for 2 days, and in the OSS world, the hacker will think “oh screw it, I will do it my way, it will only take 2 hours”. So, you end up with this “freedom” having yet another X desktop, inconsistent and all.
2. OSS hackers don’t like fixing other people’s bugs, especially when these bugs or modifications have to be on gcc, glibc, X, Loader or Qt or other such low level and DIFFICULT parts of an OS. Most of the time, SuSE, Mandrake and Red Hat employees are the ones who fix the issues. Hackers mostly like on working on new features. While in our proposed OS new features will be in place, a lot has to be fixed/changed underneath. And that stuff are not trivial. And OSS devs don’t like that too much.
3. Let’s say that you want to use Qt and KDE libs, simply because they are really complete and C++ and modern and blah-blah as the base of your new DE. Well, after you do that, Qt will be the main toolkit of the OS (however, GTK+ and Java or .NET could also be available). Now, the X11-free Qt license does not allow you to create closed source apps with it. And a platform without a toolkit that comes for free, is going nowhere. Developers need it, and a PLATFORM can only be truly successful if big companies do port their apps (e.g. Adobe) as in addition to the OSS app collection. So, this is where you need a company, to shave down the money to TrollTech and obtain free license to Qt.
4. By having ONE company controlling the PLATFORM, you get NO FORKINGS. One of the reasons of the chaotic Linux distro today is because there are a lot of distros, largely incompatible between them. I would not want to see that again. Hate me for proposing SOME of the system to be closed source (e.g. you can leave closed the modified/licensed Qt and XFree and all its new desktop applications and control panels etc etc), but I see it as the only way to prevent the chaos of the Linux distros. In my mind, having a Unix-like system that employees all the good things of what we already have (X, kernels, KDE libs, Qt, GTK, apps etc) on a platform that WORKS _for everyone_ even if it is not 100% open source, is more important than having to create yet another chaotic situation.
5. To create something nice and profesional, you need professionals. And a company can pay for those.
Define policies about dependancies, so apps won’t have to overwrite system libraries, but they can include their own in a <app folder>/lib/ dir (as in BeOS, the system first looks there, and then in the OS system lib dirs) or do it the OSX way and include them all inside a single package (this way might have a few setbacks).
I’ve never understood why you regard libraries as such a problem. If the application comes with its own, specific support libraries (JS/GIF/JPEG/PNG/CSS libraries for a web browser, for example), they should of course be kept with the app. But if the application comes with a newer version of a shared library than the one already installed, wouldn’t it be a logical course of action to replace the old library? The new application might not work with the existing version of the library, but if the old ones won’t work with the new library version, the programmer must have been about as competent as my little sister.
> But if the application comes with a newer version of a shared library than the one already installed, wouldn’t it be a logical course of action to replace the old library?
No. This is EXACTLY how you create dependancy hell.
> The new application might not work with the existing version of the library,
The OS would be coming with version XX. You either make your app work with the library version XX, or you don’t even think of installing new SYSTEM libraries that replace what comes with the OS. This is a B_DONT_DO_THAT.
If the app _really_ needs to use the newer version library, the developer should use the dependancy hell policies as defined by the OS manufacturer, or you statically link them, or you are using the <appfolder>/lib/ trick. But in no way an APPLICATION should need or be allowed to replace libraries that COME with the OS. No way.
> but if the old ones won’t work with the new library version, the programmer must have been about as competent as my little sister.
Excuse me, but the programmer who delivers his app and he decides to overwrite YOUR system with the new library, is the one in the foul here. Because that programmer, cannot possibly TEST his library against the 3000 more applications for this OS that might use that library. This is why, you wait for the OS manufacturer to upgrade the SYSTEM libraries after extreme testing (remember what we said: desktop systems should not break compatibilities often), not Joe-Hacker in Alabama. You don’t let Joe-Hacker in Alabama to overwrite ANY of your system libraries that other applications are dependant one. This is what happens today in the Linux environments, and that is downright wrong for the *desktop*. It might be your choice, and it might let you feel that you are in control, but in my opinion, it is stupid. For system libs, you wait the OS manufacturer to give you proved upgrades.
I want world peace in my lifetime too
We’re all waiting for you to start this wonderful project Eugenia. Or do I have to do it?
You will have to do it. I am getting ready to grow my family.
I have no time for micromanaging anything and anyone. I can give pointers, give advices regarding UI or usability, but I have no plans to start any project or actively participate in any other. I have other priorities right now.
Oh, and I clearly said that such a project would be better if it was a company. Which rules out you and me, as I am sure, we don’t have the right capital.
I just hope that someone who DO have the capital and the vision is reading this.
But is gonna realize them?
The discussion has brought up some great ideas for a modern workstation/homeuser OS, but still nobody seems to be willing to realize them.
The last time a company really tried to do such an enormous task it ended up being bought by Palm and the OS they created is slowly dying.
I’ll be pragmatic about this. Yes there are tons of problems. Yes, things are borked. But the truth is that you’ll probably do much more good by changing things one piece at a time and working with others than just running off and trying to create the perfect _one true system_.
But obviously I’m in the minority here.
with Stallmans GPL crap ? No one is going to take this serious and invest in it if they have to fork over the source code to a bunch of hackers. Also why would a company even attempt this if it’s going to have to deal with the 9000LB Gorrilla known as Microsoft who has gotten a free ride by the courts as of late and more then likely will continue to do so in the near future.
> The last time a company really tried to do such an enormous task it ended up being bought by Palm and the OS they created is slowly dying.
You have messed up a few things: BeOS was never a Unix (it was just *somewhat* POSIX – that doesn’t make you a unix). BeOS was written *from scratch* with a copy of the XINU next to the developers (“XINU Is Not Unix”). BeOS was a brand new OS, based on nothing. What we are talking here, is basing the OS in existing technologies. It would still be a Unix and POSIX. Pretty much what Apple did with OSX.
You GPL and open back ALL your changes to the GPL apps, and you keep closed the ones that you don’t have to open. Especially if you license Qt, you don’t have to open back none of the graphical stuff (except the KDE libs used), not even X. Not even the control panels, new tools, new apps that you might develop.
You do it as Apple: You open only what you have to open. Not the rest. There is no problem with the GPL with the paradigm I am proposing.
If OSX is already so close to your views, Eugenia, why do you keep promoting the idea of a new POSIX compliant GNU/Linux/XFree powered OS?
OSX closed to my views? What do you mean? OSX is freaking slow. Apps can’t resize and scroll as fast as I would like them. Even XFRee with KDE feels more responsive to me.
Look, you are taking things too personally. I have 12 OSes here. I run them all. I like their best parts, and I hate their worst parts. I have a wide perspective on OSes.
OSX has some good things, regarding how to create a new platform and make it user friendly. I like that.
However, OSX has other sh*t that it needs to fix for itself.
Same goes for BeOS.
Same goes for Windows. Same goes for XX.
But for what I am proposing here, **strategically** (not feature-wise, neither “look like”) OSX is closer to that vision, because **strategically** Apple did almost what I propose over here.
It has nothing to do with “OSX is great, let’s create a clone”. I AM NOT proposing that.
I wish people pay more attention to the discussion before they post such stuff here.
Apple is a hardware company that is making money off it’s hardware sales. Why would a company even dare to jump into the PC world and jump on board your idea without a huge amount of money already in the bank and ignore dangerous the looming threat of Microsoft extending, embracing, and extingushing what ever progress you make ? Ever hear of Be.Inc ? Do you seriouly think that PC hardware and OEM vendors would even think of betraying their Lord and Master Bill Gates ? Shit they barely support Linux in a half assed manner because they are able to use the “Linux is not a threat moto Master Gates.”. What makes you think that if you are succesfull that they will jump on baord at all ?
> Apple is a hardware company that is making money off it’s hardware sales.
Yes, but Red Hat is not a hardware company. And that company wouldn’t need to be anything more either.
The same applications that run on Red Hat (99% of them) would run on that system as well after a recompilation. As for the closed source apps (nvidia 3d drivers, opera, purify, ICC, Moho etc), a company can deal with these companies, and it would be pretty cheap, as the work that would be required would be pretty minimum to port over (except maybe for Purify). A company also has the advantage to have the money to license codecs, mp3s etc, while an OSS group can’t.
“Yes, but Red Hat is not a hardware company. And that company wouldn’t need to be anything more either.”
and it’s barely in the black.
“The same applications that run on Red Hat (99% of them) would run on that system as well after a recompilation. As for the closed source apps (nvidia 3d drivers, opera, purify, ICC, Moho etc), a company can deal with these companies, and it would be pretty cheap, as the work that would be required would be pretty minimum to port over (except maybe for Purify). A company also has the advantage to have the money to license codecs, mp3s etc, while an OSS group can’t.”
Which will not happen because companies like Apple, Microsoft, etc.. will never allow this to happen. Let’s see Microsoft play nice with a potential rival like you will eventually become and see if they license out their codecs and other stuff. Not to mention that Microsoft the fact that once you become a real threat to them they will sue you death. This is what is going to happen to Linux as well. People forget about the power of the DMCA.
P.S. Will this also incorperate DRM/Palladuim technology ? If not then good luck getting OEM and Hardware vendor support in the future.
>[red hat] it’s barely in the black
I agree on this! There is no way you can make enough money on OSes today. However, creating such an OS, it *differentiates* you from the rest of the Unixes and Linux distros. And that is what can keep you afloat, if not make you large profits. You would still be on the black, but at least you won’t be dying for sure (see: Mandrake).
I disagree. By all accounts of almost all Be enthusiasts (esp. on OSNEWS) BeOS was that excellent desktop oriented OS. It was developed on a completely new slate etc etc.
It is now (for all intents and purposes) dead. Technical/usability excellence does not large profits make.
Why would someone want to use this OS over Microsoft Windows ? I can see why people would like to use Linux because you can get it for free. What makes you think that people will switch over to this OS if they have to pay ? If they are going to pay for an OS why not stick with windows. It has all the applications and hardware support you could want. Why would I want to use this RoxOS over windows ? What’s the point of this OS ?
Disagree? On what? This is exactly what I believe about BeOS as well.
>What’s the point of this OS ?
None. It will just be better than what we have today in the free Unixes.
It’s just cool. And if you do have a free demo ISO that only works via CD (not installation to hdd) and people can freely try it out, and they like it, then you might have some luck. Haha.
If I had 100 million dollars, I would definately put 6-7 millions on the project. But I don’t have that much.
. By having ONE company controlling the PLATFORM, you get NO FORKINGS.
No forks, no innovation. Simply, huh?
“None. It will just be better than what we have today in the free Unixes.
”
So you have not real reason to make this comercial and any company with big bucks will have no real interest in making money off it or even picking it up. If you are not aiming at knocking out the big guy from the start you won’t get very far.
“It’s just cool. And if you do have a free demo ISO that only works via CD (not installation to hdd) and people can freely try it out, and they like it, then you might have some luck. Haha.
”
SuSE does the same but they aren’t exactly swiming in cash are they ?
“If I had 100 million dollars, I would definately put 6-7 millions on the project. But I don’t have that much.
”
I wouldn’t waste my money if I was you. Seriously if you can’t offer a advantage over Microsoft Windows on the PC you won’t make that much and eventually be either considered a niche OS ( Linux ) or dead on arival like BeOS. Your best bet is to switch over to another platform like they are doing with YellowDog Linux and start from scratch because the x86 platform as everyone knows is Microsoft turf and it will stay that way for a loooooooooooong time.
LoL –
Microsoft has innovated (yes, they have). Apple has innovated. SGI has innovated. Be has innovated.
And they were all based on closed source projects and they have something really valuable: CONTROL over their product.
No forks != No innovation.
On the contrary. You can get innovation in the closed source community. I have seen more innovation coming from these guys, than the purely OSS people (however, there are a few OSS-breed projects that are innovative). The OSS people are best to copycat the big players, not to innovate. It is easier that way anyway.
“It’s just cool. And if you do have a free demo ISO that only works via CD (not installation to hdd) and people can freely try it out, and they like it, then you might have some luck. Haha.
”
SuSE does the same but they aren’t exactly swiming in cash are they ?
CD demos has not to do with SuSE’s bad financial shape.
Anyway, looks like the first CD demo that has really got attention is Knoppix, mostly because Knopper made a CD demo that works.
But, you won’t get any arguments from me there.
Of course and you can’t take down Microsoft Windows. But with that plan you CAN survive EASIER than any other Linux distro, *because* you are different and because you are better than their offerings.
NOT swim in cash though. That can’t happen in the OS market. Even Apple has trouble.
Please stop using my name as the synopsis of your comments. People can’t figure out who is replying to whom.
Please write something that really synopsizes your comment in the header field, and then use a RE: to reply.
Which means that you’ll just be another niche OS fighting for that 1-5% of scrap users that Microsoft throws aside because you will not be offering anything that I can’t do on Windows already.
okay…okay.
On the contrary. You can get innovation in the closed source community. I have seen more innovation coming from these guys, than the purely OSS people (however, there are a few OSS-breed projects that are innovative).
Uffff, I’m started to think that you’re advocating that OSS and innovation doesn’t mix <g> 8-D
Of course. Isn’t this what every consumer OS does today already? Having 5% of the OS market is already good enough.
BTW, are you the same troll who I told to not comment again a few days back because of your weird stance on being trollishly pro-Microsoft? If yes, I will stop replying to you. No matter what I will say, you will still continue to troll and never understand what OSNews is all about.
I have nothing against OSS. I believe that OSS has an important role in the software community and it has its place.
It is just that I believe that closed source ALSO has its place. And closed source and bring as much good as OSS can. Including innovation, and most importantly, money.
In other words, I am a realist. Not Stallman’s weenie.
Either:
XWindows
QT
GTK
Kernel modules
Windows managers
Package management
Funky directory structure
or nasty compatibility problems with ‘non-forked Linux’ with the above. This is not the way to create a user-friendly desktop OS, unless the user is a geek. Linux is a train-wreck on the desktop, it’s better to start afresh than to battle its faults or suffer forks and messed up software compatiblity between a plethora of different Linuxes.
I know you’re concerned about driver support, but if a freesoftware desktop OS ever becomes more than a hobbiest niche thing, it’s going to have the critical mass to have the hardware support anyway.
If you want to have companies invest in your work and have your OS succeed you should not have this attitude that the 1-5% of market share is enough to survive in the OS world. People won’t take you seriously unless you offer to capture more then that 1-5% and offer something that they need as well, especially if you are planning on making it comercial in nature.
Making a real commercial OS succeed and make a profit is a lot harder then it sounds when you got a 9000lb gorilla in one corner and a freebie OS like Linux in the other corner that people can turn to. Like I said if you are not offering something new or something that people can’t live without then why make it commercial at all ? What motivation is there for me or anyone else too forking over X number of dollars for your OS over instead of downloading Linux for free or buying the next version of Windows XYZ ? These are questions you need to answer before putting in a lot of blood sweat and tears.
No, none of the issues you are talking about will be present. There won’t be packaging management problems. There won’t be alternative window managers. The X/Qt/KDE will be INTEGRATED, and it wouldn’t allow window managers.
Funky directory structure?? You missed our previous discussions sweetheart and how I remind how OSX, AtheOS and BeOS does it, so it is NOT funky or unixy at all.
The fact that there will be X-windows, doesn’t mean AT ALL that the user will know about it. No plain user knows what a GDI is, or do they? On the same way, no one will have to know what X is and how to configure it, because the integration of the OS will take care of all that.
I suggest you re-read our discussion. You haven’t understood that we are trying to modify the tools, and take AWAY all these issues you just listed.
Explain to me why a person buying a PC cares about X86 sv PPC vs Space vs Etc……?
The only thing most people do is go in and compare the products.
They’ll look at things like Mhz, RAM, Hard Drive size, things like that. Whats more is these numbers don’t actually mean anything. They just use them as a way to evaluate value.
Someone looking low end buys a low end machine.
Midrange guy buys midrange.
High end buys high end.
The way to get any kind of real market share is through the business desktop. It was true for MS and x86 15 + years ago and is true today.
> People won’t take you seriously unless you offer to capture more then that 1-5%
Apple has only 2.3% and they already have THOUSANDS of applications from third parties. They are serious enough. Why? Because they have a _platform_ as opposed to a simple OS. And that doesn’t always requires hardware to have a platform. Our imaginary company here, could do the same. Having _anything_ above 1%, would already be huge.
Ok, I am going to watch a movie now, I won’t be around for the next 3 hours to reply, sorry.
Tell me, Eugenia, is Linux more brain-damaged than I’ve perceived it to be? I have been replacing libraries for ten years on a non-Linux system, and so have installers been doing (doing a version comparison and asking me nicely, in most cases) for as long. I can recall exactly one case of incompatibility. In ten years. Despite installing lots and lots of software. If all my old software works with my new library, why wouldn’t this be the case on Linux? Are you just joking, or is this what your famed dependency hell is supposed to be?
If the library implementation on Linux is so brittle, I’m amazed that you don’t put its replacement high on your list of things needing revision for the implementation of Eunix/ROX OS.
Eugenia you don’t seem to *get* it-propietary commercial operating systems are not a viable solution to the future of computing needs. Yes, as of this moment, most computer users use OS’s based on the paradigm of propietary commerical programming, ie. base on the notion of IP.
In this distopiann world we have a plethora of OS’S with which few are actually happy, and in which quality has time and again been defeated by quantitiy, as measured in purely capitalistic terms. The propietary commercial programming world has innundated the world with wonderful examples of how quantity has beaten quality.
Market success is not and never has been a measure of quality, neither in programming, nor in engineering, BEOS is but an example of this which is accutely obvious. No one company will ever realize your dream Eugenia, because your dream is what commercial success is made of- Winbloze is what commercial success is made of, and the presence of quality in Winbloze is most notable in its absence.
If only noble investors would come galloping on horseback from the distant horizon, wisely investing their noble money to realize your noble dream and these noble knights would rescue our damsel in distress, justice would reign supreme, at least for UI designers.
Eugenia, your dreams are not for naught, many read your opinions and your suggestions and invariably you are influencing some fraction of operating system and UI designers. You are helping to mold a discourse which has being shaped by your vocalism. Yet others will do the work, others will write the code, and those who are apt to listen to you, and who are actually in a position to implement your suggestions and ideas, are those who are not bound in the chains of propietary commercial programming, ie. those who are free to write what they want to write when and how they want to- which is only true for OSS developers.
Programmers in the current still dominant paradigm take their cues from the investors who have the money, writing the software which they are assigned to do- and UI designers are not the investors, for they do not earn the money to be able to fund such companies, let alone found them. You may not realize this Eugenia, but OSS developers are the only ones who could turn your dream into something more than merely a dream and your attacks against them, born out of impatient frustration, lessens the likelyhood that those who could pull this off will even take you seriously.
OSS is much much more than yet another linux distro- it is a revolution in how people work, how money is made, and what is considered to be of real value- OSS is all about values and quality is a value which has proven to be relatively worthless in the current dominant propietary commercial programming world. OSS represents a paradigm in which the economics of programming is not the only value of programming, ie. where programming becomes something more than self-centeredness, primarily because when indidividuals collectively work together, their invidual desires meet more than their individual needs, creating a surplus from which all profit.
This idea once was fundamental to the capitalistic enterpise which gave birth to the current propietary commericial paradigm, yet because propietary=commerical and commercial=propietary this paradigm has stopped producing benefits which go beyond itself, and hence people are no longer profitting from it like they once did, which is why quality has taken such a beating. Eugenia why do you make the simple mistake of connotating professionalism with commercialism with being propietary, have you never experienced quality for which you did not have to pay a price…..
They been around for a long time and thus have been able to get application writers to port for them. In fact they were at one time the defacto desktop makers that everyone wanted to follow and have their applications run on. They had this luxury to begin with you don’t ! Think about it, you have no hardware platform of your own to control and you really won’t be able to offer anything new ( besides the packaging system and file system ) that Linux has to offer. Hell the fact that Linux is free is a big advantage on it’s part and more motivation for people to use it then your OS. Do you really think that you will have OSS application writers flocking at your doorstep to code for you ? Especially since you will not be GNUifiy your OS ?
Now let’s talk about the commercial aspects. What advantages do you offer to commercial application writers to port over to this OS ? Why would they waste time and money making applications available for your OS when it will only garner 1-5% of the desktop space if you are lucky ? Think about it Linux is set to equal or pass up Apple and it still gets very little if any commercial application support. Also if you look at it at another angle you can also see that Apple is losing desktop market share to a free OS like Linux despite being commercial in nature and have it’s own hardware platform ! Don’t even have me bring in BeOS into this discussion as well. That still born baby needs to be put to rest.
Anyways I would advise you to think about all these issues before hand and see what you are about to embark on. Also you must realize that people and companies do not throw money at stuff that is cool or has no real intentions of beating out the big boy at the top. You must look at what you are going to be up against if you are going to make this a commercial OS. Anything that is remotely viable to being a desktop that is good enough to take away application writers from the 1# OS will bring the Redmond boys and their group of laywers a knocking at your door. You must realize that you will need to offer something that the free Linux kiddies can’t do and that other commercial only OS’s can’t offer as well. Your ideas are nice on paper but no offense in the real world money talks and BS walks.
or your ideas are.
After the gnome 2.2 rc2 discussion turned into
one on your new OS (which I have dubbed Eunix), it should be clear that even if you quite legitimately mention your vision as a contrasting alternative , the discussion will once again turn into a disucssion of Eunix rather than Rox.linux.
Let this fledgling os have its days.If this keeps up, by the
time you get around to publishing your article on Eunix,it
will have been discussed to death already on the back of
other articles.
Not your fault, I know.
Like the header says,I guess you are just too darn sexy.
That should be fast enough for you. Then you can be as close to Eunix as one will get for a long… long… time.
Anonymous, all you talk about is investers and commercialization and market share. Eugenia is simply talking about operating systems! She is an operating system junkie, I am an operating system junkie, the vast majority of people that come here are operating system junkies. We love operating systems for their own sake. I know that’s not how it’s supposed to be – the OS is to be the means to an end, but operating junkies have always been this way. That’s why she said you don’t understand what OS News is about. You don’t actually say it, I’m not trying to put words into your mouth, but you imply that, because there are Windows, Mac OS, and Linux, nobody should waste their time thinking, using their imaginations and, yes, even creating something new. To an OS junkie, an operating system is a work of art – it is beautiful (or ugly) in and of itself. And, of course, part of the beauty is how it enables people to do things with it. Because the Mona Lisa exists, should painters stop painting? Because the Pieta exists, should sculpters stop sculpting? Do you think the hackers at MIT in the 60’s gave a sh*t about the potential commercial value of what they were doing? They would hack for 30 hours straight just to figure out how to bum one instruction off a program to make it leaner, faster. That’s what they lived for. Operating junkies are like all explorers – they cannot resist seeing what’s over the next hill. And, once in awhile, something big happens when they keep looking beyond the next hill. This thread was one of the best ones we’ve had here in awhile until you party poopers put a wet blanket on it 🙂
Couldn’t have said it better Jay. Thanks.
[Back from the movie. “Swordfish” is a great movie :]
I really enjoyed reading their discussion regarding the file structure. My suspicion is that no one in the history of Linux has ever had such a discussion. As an end-use, the Linux file structure is a mess!
I look foreward to seeing their final decision regarding heirarchy.
-Bob
Read my response in the moderated down section.
Linux distro companies *will never* get there, not only because of the legacy problems they are afraid to shave off, but because they are short sighted already. They don’t see the big picture and where they can go by creating a new **platform** (as Apple did with OSX by using BSD), instead of “yet another Linux distro”.
I think you’re on to something here. Only I don’t think a distro company could do it – most of them are barely surviving as it is, and breaking compatability with existing apps would be their funeral. Operating systems in themselves aren’t a big money maker unless you’re either Microsoft or you’re in a niche where you’re irreplacable.
But an application software company could. Someone like Shawn Gordon’s the Kompany would be an ideal candidate for this kind of a project. He’s making his money selling applications, and he would be able to provide them for the new platform. And he already has a customer base that’s prepared to pay money. The advantage to him would be having a single platform to support, he wouldn’t have to worry about supporting every bizarre kernel/glibc/X/KDE combination in the world. If you have an “in” with Shawn, you might want to suggest it to him.
IIRC, that’s how Microsoft started out. They provided an OS to IBM simply to have a platform to sell applications on. They had no intention of being in the OS business. The original deal with IBM was that IBM could license DOS for free on every computer that had Microsoft ROM Basic on it. If you ever wondered why IBM PC’s still had ROM basic included long after the rest of the world abandoned it, that’s why.
Your suggestion on a Linux-based (or BSD-based) OS sounds interesting, especially about replacing glibc, easing the dependency hell, etc., but it holds absolutely no weight commercially.
Making a OS may be easy, but selling it is a totally different thing altogether. How do you market something that has absolutely no applications (no binary compatibility) except your own? It involves a lot of work. For what? Yes, easing the dependancy hell and creating a clear path for binary compatibility for future versions sounds good, but you won’t be scoring points writing a business model out of it.
Writing a replacement for things like glibc is expensive and takes a lot of time. Not only that, writing your own DE based on kdelib and Qt makes no sense. Why? Most of the problems with KDE are with the back-end. The libraries. The front-end may be cluttered, but I’m sure as hell that fixing that is far easier than writing a new DE over it.
But if you are writing a new DEl, why Qt and especially why kdelibs? I have been exploring FOX in the past few weeks and my early conclusion that it is much better than Qt, and may get better than Qt. If you are about to write a new DE, you may as well write it on FOX.
Personally, if I was to enter the Linux business, which is very very very very unlikely, I wouldn’t do as suggested. Maybe rewrite glibc to keep binary compatibility going on for a longer time, and perhaps forking GCC with a new more prolonging ABI for C++ applications. But that’s about it. It would stick as Linux.
Why? If I enter this field (desktop Linux), it wouldn’t be pure desktop Linux in its sense. It would be more like thin clients. Thin clients have a amazing potential to succeed. They cost way less than PCs, they are far easier to administrate, and because most of them don’t contain moving parts, they are bound to survive a longer period of time.
In other words, if I create a Linux distribution, most of my efforts would go either to improve XFree86 for remote desktops or get a commercial X for it. Of course, this is how I see it from the business point of view. When it comes to what would make me more excited, your idea sounds way better than mind. But then again, the chances of your idea bringing in profit is slim.
I would also like to add that the Linux kernel don’t have binary compatibility with drivers linking directly to it…
The average user does not care what goes on ‘under the hood’ of the OS, so why not just use the conventional file-system layout and make Rox-Filer a translation layer?
Just hide the unix / from the user, and let them see a hierachy that consists of /home and a /programs.
When they remove or add an app to /programs, they would not be changing actual data, but starting up RPM to add or remove the app from the real filesystem. If this distro is having to have dedicated packages anyway, going to this system.
Stopping installation of apps being a problem with dependency hell does not need a new FS, it just needs a dependency manager. Gentoo and Debian sort out dependency problems automagically already. Debian does it with binary packages too.
If the average user finds the existing filesystem difficult, why will they find…
System/
System/Applications
System/Boot
System/Core
System/Devices
System/Library
System/Settings
System/StartUp
System/Temporary Items (Optional)
Applications/ (Optional)
Library/ (Optional)
Users/ (Optional)
Developer/ (Optional)
any easier?
This may sound like a hack, but for an ‘easy to use’ Linux, it just has to be ‘easy to use’. What goes on under the surface is of no interest to the user, and while a cleaner fs may be appearing, the amount of incompatibility and breakage it will cause will make the ROX author’s jobs very difficult. Moving /proc around is not fun!
If anyone thinks this is an ugly solution, well look in a Windows box’s /WINNT. Do you have any idea what ANY of those directories in there are for? No. Do you need to know what they are for? No.
Linux is a complex OS, and changing names around in the filesystem will not make it easier, if you are going to ‘easy to use’, go the whole distance, and TOTALLY seperate the real OS’s filesystem from the user.
Why not develop up Darwin x86 as the base for this new proposed OS? After all, from doing some reading, it would appear to have the base of what we want. Mach kernel (not the linux monolithic crap). Then put all energies into the GUI and packaging system.. much of this i guess could be borrowed from OSX… just my thoughts
If anyone thinks this is an ugly solution, well look in a Windows box’s /WINNT. Do you have any idea what ANY of those directories in there are for? No. Do you need to know what they are for? No.
If we were back in 1985, you would argue against the necessity of a GUI, too, wouldn’t you? After all, most people seemed to get along perfectly fine with their CLI.
I’d certainly like to know the philosophy behind the WINDOWS directory structure. No, I’m not a perfect novice. Are all computer users either perfect novices or UNIX gurus?
As long as computers have normal hierarchical file systems, we might just as well make them as graspable as possible.
“If we were back in 1985, you would argue against the necessity of a GUI, too, wouldn’t you? After all, most people seemed to get along perfectly fine with their CLI. ”
I am arguing the complete opposite. I am saying that the days of expecting the average user to understand and navigate the machine’s root filesystem are over. It’s as radical a progression as the move from CLI to GUI.
“I’d certainly like to know the philosophy behind the WINDOWS directory structure. No, I’m not a perfect novice. Are all computer users either perfect novices or UNIX gurus?”
I’m a novice UNIX guru.
The windows /WINNT just seems to be a place to chuck everything they could not find anywhere else to put. I love the way that ‘Prairie Wind.BMP’, ‘twunk_32.exe’, ‘Notepad.exe’, and ‘directX.log’ are all thrown into the same top system directory.
Bitmap resources, the twain 32bit thunking server, a text editor app, and log files are all mixed together in the same directory Lol!
“As long as computers have normal hierarchical file systems, we might just as well make them as graspable as possible.”
Graspable for who? And in what depth? For a developer, the existing filesystem is not a problem (though it is a bit crufty). For a user who just wants to use the computer as an appliance (or a developer on their day off), it’s pointless complexity.
I’m all for cleaning up the Linux filesystem, but just general adherence to the existing fs standards by distributions and developers would go a long way doing this.
See: ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/fhs-2.0…
Well, I’m always amazed at how much interest ROX OS alway attracts, despite
having almost no actual code! As usual, everyone has their own idea of what it
is.
The goals below are my own (I’m the author of the ROX desktop, from which ROX
OS takes its name). These are not necessarily the agreed goals of the ROX OS
project.
* Hiding the system with the GUI
A big goal of ROX OS is to make sure that the underlying system is simple and
sane. NOT to hide a complex and stupid system with a clever GUI metaphor. See
Joel’s “The Law of Leaky Abstractions”:
http://www.joelonsoftware.com/articles/LeakyAbstractions.html
Hiding the real system doesn’t work, and the further the system the user sees
differs from the real system, the more often they will be confused by the
behaviour of the system. If your GUI metaphor describes a sensible, consistant
system, why not really implement it that way? If it’s not possible to really
implement the metaphor, then the metaphor must be limited, and will lead to
confusion.
* Application directories
The primary goal of application directories is to ensure that objects in the
file system have a one-to-one correspondance with installed packages. So, you
install Gimp by extracting an archive to a new directory called Gimp. No
files are created outside of this directory at install time.
To uninstall, the directory is simply deleted. So often, you will hear users
of other systems complain “I tried to install this program, but it went wrong.
Now I can’t start [some other program]. I tried to uninstall it, but that
doesn’t work either!”. This cannot happen on a ROX OS type system, because
applications can be added and removed as easily as a word processor document.
* ROX OS is not designed for your pet hampster
The goal is an OS that any person of normal intelligence can easily
learn to use and understand. We are not aiming for the Windows idea that
the system guesses what you want and it all “just works”. Such systems tend
to only “just work” for as long as the user does exactly what the designed
expected them to do. When they go wrong (they always will), the user has no
hope of fixing the problem.
* User preferences
Mike, you ask how user preferences can be automatically deleted when an
application is removed. This does not happen, either in ROX OS or in other
systems (eg, Debian). Preferences that the user has set are valuable and
must be kept until the user explicitly deletes them. On the other hand, default
settings are part of the application and are kept inside the application.
Let’s say I install 1000 applications, and I explicitly configure 100
of these and each uses 4K of disk space (let’s assume we’re not using ReiserFS,
so this is the minimum file size). Now, I’ll probably keep using applications
which I’ve taken the trouble to configure, but assume I get rid of 20 of them.
That mean that I’ve wasted a full 80K of my 80G disk (that’s 1 millionth of the space, or 0.0001%). And, if I decide to reinstall the program, I’ll be glad
the settings weren’t lost. Of couse, by storing the settings in an obvious way
(ie, not one big registry file) the user can easily see and delete them when
they desire.
How does an application get unregistered as a MIME handler when it’s
uninstalled? Easy. Since the application no longer exists, the user is told
that there is no run action for the file, just as if they had never created
the association. If the application is reinstalled in the same place without
changing the association, it will work again (useful if you’re upgrading!).
I myself am interested in this project, ROX OS. I have used Rox-filer intermittently for years-its advantages make a linux distribution based upon it very appealling. No software in the linux world has implemented DND to a degree comparable with ROX. ROX is lightening fast, tiny in size, and virtually inifnitely configurable-in terms of object association. ROX has to date not been able to get beyond being a tiny niche file-manager. Primarily because most applications under linux do not take advantage of DND principles beyond that application itself.
With ROX one can simply click on a file to open it- whether it is a document, a media file or an executable application-the details of which application are used to open which kinds of objects are freely configurable, and configurable with absolute ease. Applications which would trully take advantage of the DND principles underlying ROX would not need a file-open/file-save dialog- if you want to save your document you simply drag the document from its application window to the file where you wish to have it…
The only problem is that few applications have been written which takes advantage of ROX’s functionality, and with ROX one never uses the CLI everything is DND, one rarely needs to use the keyboard at all….
I am currently using the cvs version of XFCE4 with ROX, both are now based on GTK2, with its excellent font rendering technology(Xft, freetype), and are completely themable allowing for a far greater degree of visual consistency. The two, XFCE4 and ROX are both ultralightweight systems which are blindingly fast, and although XFCE4 is still under heavy development, and consequently is still quite buggy, it looks very promising offering much of the good things from GNOME2 via GTK2 without its negatives.
IF a project were to take ROX-filer seriously and really implement it with a customized WM to create a unified environment and if application writers would add ROX-based functionality to their applications, perhaps as a compile-time option, linux as a desktop OS could really take off, and it would be unique,self-consistent, easy to use and fast/lean. The sheer configurability of XFCE4 and ROX-filer could remain unchanged provided that upon initial install currently present applications were automagically associated with objects, leaving the user to customize their system as seen fit later.
ROX OS seems to want to capitalize on all of the advantages of ROX and extend them down into the system layer modifying the entire file system to compliment the UI. Rox-filer is already tailored to the actual file system in use in linux, it simply circumvents the conventions used in manipulating the fs, which one has learned through their use of CLI based applications.
Abandoning this legacy, the legacy of learned conventions based on CLI metaphors which are far less than optimal in a GUI setting, is a worthwhile goal-it is simply not possible to re–impliment CLI functionality at the GUI level based on a CLI metaphor-without producing endless amounts of user-confusing options, which at the CLI level are appropriate, but nightmarish at the GUI level.
If I were a developer working with ROX OS, I would recommend the opposite of their fs approach-ie. impliment the extende attributes stuff on the underlying fs(XFS or perhaps reiserfs) allowing apps to use this extended data, but maintain the current linux heirarchy for maximum capability and overlayer this with the filesystem heirarchy which they propose, using the same plasticfs system-it is better to implement this very new system as a layer superimposed on top of the current system, as to using the new system immediately as a new base and superimposing simulated legacy heirarchical linux file system support. For the end user this is irrelevant, provided that the end user only has to deal with this new system directly, what goes on behind it is irrelevant….
for those who know little about ROX-file….
“Traditionally, Unix users have always based their activities around the file system. Just about everything that’s anything appears as a file: regular files, hardware devices, and even processes on many systems (for example, inside the /proc filesystem on Linux).
However, recent desktop efforts (such as KDE and GNOME) seem to be following the Windows approach of trying to hide the filesystem and get users to do things via a Start-menu or similar. Modern desktop users, on Windows or Unix, often have no idea where their programs are installed, or even where their data files are saved. This leads to a feeling of not being in control, and a poor understanding of how the system works.
The ROX Desktop, however, is based around the file system. It’s core component is ROX-Filer, a powerful graphical file manager which, in addition to being a pretty neat filer in its own right (IMHO!), provides a couple of extra features which allow it to solve the above problems.
The first of these features is support for `Application Directories’. An application directory is a directory which contains an entire application – its documentation, binaries, source code and so on. When you open an application directory in the filer the application is run. This has some interesting implications:
* Installing an application is the same as copying a directory. No need for special setup programs (or root access). For example, let’s suppose that your friend has the latest version of ROX-Filer and you want it. She simply copies the directory onto a floppy disk and hands it to you. You can run the program directory from the floppy if you want, or you can drag it onto your hard disk to `install’ it.
* Uninstalling is the same as deleting a directory.
* Want to install two different versions of the same application? Just copy them to different directories on your hard disk.
* To read an application’s help usually involves hunting around for man-pages, info pages, directories in /usr/doc and so on. With an application directory the help is inside it – just choose Help from the filer menu to see it (all this does is to open a subdirectory inside the application called ‘Help’ – simple, eh?).
* There is no need for a separate filer and application launcher. The filer does both, and you always know where your programs are.
The second unusual feature is drag-and-drop saving. You’ve probably already seen DND loading (dragging a file from the filer to an application) but ROX takes this one step further: you can save by dragging the file back from the application into the filer.
This may seem a bit strange at first (especially if you’ve been using Windows) but you’ll quickly start to wish that all applications supported it!
For example, imagine that you’re producing a report. All the resources you’re using are in /home/fred/Work/July/Report.
You create images in one program, graphs in another, and write the text in a third program. Every time you want to save you have to renavigate to the directory using that program’s mini-filer (each one is slightly different, of course). This is annoying! With DND saving you could just keep the directory open and drag files into it from each application. This has the additional advantage that after you’ve saved an image from the Gimp you already have the directory open ready to drag the image straight into Lyx. Assuming that both programs supported DND.
Both of these features are taken from an operating system called RISC OS (ROX stands for `RISC OS on X’) which has had them for years. They proved very popular amoung the users, although the operating system itself had some other short-comings and never enjoyed much commercial success.
(I posted earlier under “anonymous”, with a small “a”)
@ Eugenia
>>But if the application comes with a newer version of a
>>shared library than the one already installed, wouldn’t
>>it be a logical course of action to replace the old
>>library?
>No. This is EXACTLY how you create dependancy hell.
Uhm. No. The dependancy hell comes from the OSS nature of forking everything back and forth. The problem is that there is no consistency in the OSS world (given the nature of OSS development). M$ is a great example of how NOT to do this in the corporate world. AmigaOS is a prime example of how to do it.
If it was possible back in the 80s, it is possible now too. You talked about having a company pick up e.g. the Linux kernel and build an OS on top of it. Such a company should be able to do what Commodore did.
>>The new application might not work with the existing
>>version of the library,
>The OS would be coming with version XX. You either make
>your app work with the library version XX, or you don’t
>even think of installing new SYSTEM libraries that replace
>what comes with the OS. This is a B_DONT_DO_THAT.
Uhm. Not really. Future versions of library X should either be backwards compatible OR cleraly state that they aren’t. Once again, look at AmigaOS.
>If the app _really_ needs to use the newer version
>library, the developer should use the dependancy hell
>policies as defined by the OS manufacturer, or you
>statically link them, or you are using the
><appfolder>/lib/ trick. But in no way an APPLICATION
>should need or be allowed to replace libraries that COME
>with the OS. No way.
Now we’re on par.
Thomas Leonard,
“* Hiding the system with the GUI
A big goal of ROX OS is to make sure that the underlying system is simple and
sane. NOT to hide a complex and stupid system with a clever GUI metaphor. See
Joel’s “The Law of Leaky Abstractions”:
h ttp://www.joelonsoftware.com/articles/LeakyAbstractions.html
Hiding the real system doesn’t work, and the further the system the user sees
differs from the real system, the more often they will be confused by the
behaviour of the system. If your GUI metaphor describes a sensible, consistant
system, why not really implement it that way? If it’s not possible to really
implement the metaphor, then the metaphor must be limited, and will lead to
confusion.”
First off -thank you for your programming efforts, I really appreciate your work, and what you have contributed.
I can definitely see what you mean here. I am not a current programmer and certainly not an OS developer, but here are my two cents.
As I see it you have three layers, at least for the sake of what I wish to show here:
I) the filesystem properties and charachteristics
II) the conventions used in laying out the filesystem hierarchy.
III) the actual libraires which coodinate and couple the all of these levels together(level 1,2,4,5 are all bound to this level and all are implemented at this level)
IV) the applications which the user uses
V) the UI to these applications
what follows are questions, suggestions….
1) if one extends those charachteristics of level I) will this level still support the legacy code ?-ie. is mere extension enough or do you actually want to modify it.
2) IF one extends level I) and implements these changes at level IV) and V) is it not possible to leave II) and III) in tact and extend them to take advantage of the extensions to I) and how level IV) and IV) implement this.
3) what I posted in my last post looks at first glance like a call to “hide” the system-but can one really talk about “hiding” if level 1) is really being extended and these extensions are being implimented at level IV) and level V) ?
4) level II) is merely a matter of convention, one should be able to a) extend the existing convention to take advantage of the APPfolder/Libfolder metaphor b) capture all IO tied to these conventions(or the old conventions) and rerouting them appropriately and/or c) maintain mulitple current convention systems for maximum compatibility.
5) levels II) and IV) represent +90% of all the programming work for an operating system. This work cannot be simply abandoned, too much work has already happened here. Applications can be written to include compile time options which would enable the usage of extensions to levels I) and II) with relatively little work and if level 5) was a self-consistent integrated environment application programmers could delegate their work better focusing more on internal functionality and utilitlizing the external/inter/intra functionality of level V) -instead of trying to reduplicate the entire UI for each and every damned application.
6) Why do you need to eliminate the existing file stucture ? can’t one simply extend this and use symlinks extensively and only allow for the depiction of symlink structurers only at the UI level of file management ?
7) can’t one use the existig GNU base and simply created modified versions of certain key libraries in addition to the existing ones and allow the applications and objects which are metadata aware to automagically use these additional libraries (level II) and extended fs attributes(level I)?
I could go on, maybe I am mistaken, I would appreciate your feedback…..
For ROX OS to work the way you wish it to work the filesystem must suport the extended attributes which allow for meaningful use of metadata by applications, this you have