Linked by Kroc Camen on Thu 5th Nov 2009 21:05 UTC
There's no right way to do it, only ideas that are better than others in certain situations. But if you had the opportunity to head up the design of a new OS, one to Put Things Right, one that could be radical enough to varnish out those UI/X bumps that have clung on for years, but practical enough to be used every day, what would you design? How would you handle application management? What about file types and compatibility? Where would you cherry pick the best bits from other OSes and where would you throw away tradition? I've tackled this challenge for myself and present (an unfinished idea): KrocOS (warning: HTML5 site, will display without CSS in IE/older browsers). OSnews Asks: What would make your perfect OS?
Thread beginning with comment 393300
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Member since:
2006-01-02
Re: KrocOS.
), joe, ...
Now, first, this has been one of the most entertaining, thought-provoking, and Wikipedia-link-following-for-hours threads in a good while. Since I've said my pipe dream, let me criticize our star, Kroc.
Branding: I somewhat agree. I think distinctive software should be, well, distinctive, but not to the point of its own foundation with a special license and everything else. The user gets, like in politics, to choose the least worst. I would go with noun/verb combos giving you program choices, but not that being everything. The thing is, how many verbs can you really have? Edit: nano, leafpad, vi, emacs, scite (an OS w/o scite is something I don't want
App/OS separation: absolutely. While I ran into the char limit, I would go so far as to do things like have a very low level regex system, and most every generally powerful thing in the C++ std, boost, or standard Java or Haskell bits, that can stand alone, as shared OS functionality. Compile an app that uses it, and it just asks the OS for it. Otherwise, you can use it many different ways in the OS. There are many features should be basic OS things, and simple system programs, that get pushed into libraries and language extensions, adding obfuscation and complication. I had not thought of it in terms of branding, before, but it makes a lot of sense.
Context: yes and no. A file manager which can morph into a music manager would be neat, but maybe, just maybe, I want to see files. That is one of a billion reasons for a metadata-centric FS. You can have your cake and eat it, too, with all that context, and I can see damn files, and start my damn music player to play the way I damn want to! The whole time, neither of us have to use a radically different system to do it, and could even have that separate work flow using the same music player and file manager--just change a few check boxes in the options. To work well, though, for both, context metadata needs to be supported from the ground up.
Also, being a tinkerer kind of person, I like exposed plumbing. But, the user should not have that plumbing shoved in their face. It should be neatly against the walls and ceilings, should they want to inspect it.
App folders: *shrug* As long as I can get my app there and working, I don't care. The one thing I don't want is for a Debian-like hiding of the build system, so I can never track down enough packages in the right places, if the package hasn't had its make file tweaked for Debian. Give me Slackware or Arch's slightly bigger packages, so things actually build, any day.
FS view: hard drives matter, sometimes, and should be exposed, but not like in Windows. Add an extra button to show additional storage resources, of make a FM option. The plumbing thing, and all. make some of the innards very easily discoverable and usable, just slightly out of the way.
FS in general: I may have just been getting out of elementary school at the time, but I remember BeOS. With my current knowledge, I think a relational file system, giving defined types of attributes to a set of a bytes, is THE way to do it. You can then organize it flat, in a normal tree, in different trees, even in 3+ dimensional networks (fast indexing becomes iffy, then, of course), if you care to. UI complexity would be the major limitation (that's when you bring up a console...). Custom apps would especially be good with this, as tying data from different things together would be a snap (your calendar example, FI).
Menus: looks good to me.
File handlers: yes.
Window manager: less is better, and it needs to be adjustable by workflow. Real research is the key. Tiling WMs, Expose, Compiz Expo (grid of VWs), etc., are quite cool. The real trick is finding a good enough one, or a window/menu/task system that is flexible enough to work really well in many WM paradigms.
Calendar, RSS, address book, and the file system: that's why a relational FS, surrounded by a context-app system, would rock, IMO. Data is well-defined, at the OS level (not DE-level), and apps just do stuff to it, in a OS/FS-sanitized way.