Komodo and GenSTEP

[[root@localhost /]#]

A flurry of new distros coming out that FINALLY shift the focus on to ease of use, Calyptos, Komodo, and GenSTEP

in the GUI (where all config can be done) GenSTEP uses this as a folder tree

/
/System/
/System/Library/ GNUStep will reside here
/System/Komodo/ Komodo's core components will be living here
/Applications/ GNUStep and Komodo apps
/Applications/Admin/ Administrative apps, obviously

the terminal will still be there and will have the respective /bin /usr /etc from the CLI

Komodo (the base of GenSTEP, has Resource Forks (like on Mac OSX) implemented in KFile so Metadata can be stored as well as be able to create the .app functionality of OPENSTEP and OSX.

GenSTEP will be source compatible with NeXTSTEP and Cocoa (OS X) applications as well as is uses the YellowBOX API from GNUSTEP.

Calix homepage:
http://calix.calyptos.com/
source availible, no iso's yet.

GenSTEP homepage:
http://cthulos.sourceforge.net/

[Calum]

all good stuff, but i do wonder about this sudden tendency of so called user friendly distros to change the filesystem tree structure around for no good reason. seems dumb. ease of use for me is knowing where /bin and /etc are amongst other things. will these be symlinked to /C/Program\ Files/ (or whatever it's supposed to be)? sounds messy, but good on them for the effort, i hope a sensible approach does turn out some linuces which are not as ragged round the edges for newbies/windoids as the current crop.

[[root@localhost /]#]

eh, it is more like the STEPs (including OSX) and from the terminal, you can see /etc and /bin

GenSTEP is a linux based STEP

[JimmyJames]

Komodo (the base of GenSTEP, has Resource Forks (like on Mac OSX) implemented in KFile so Metadata can be stored as well as be able to create the .app functionality of OPENSTEP and OSX.

This is misleading. GenSTEP will not use KFile for its desktop. Instead, it will use GWorkspace (http://www.gnustep.it/enrico/gworkspace/) combined with WindowMaker to recreate the OPENSTEP user experience.

GenSTEP will be source compatible with NeXTSTEP

Will it? I'm not so sure. A number of changes were made between NeXTSTEP and OPENSTEP to the API. YellowBox is not necessarily 100% the same as AppKit.

and Cocoa (OS X)

Yes. GNUstep currently has from what I can tell very robust Cocoa support.

applications as well as is uses the YellowBOX API from GNUSTEP.

However, I don't know how much YellowBox support is left. If GNUstep supports Cocoa, then YellowBox might be problematic. Many YellowBox apps won't compile on Mac OS X. Mac OS X Server 1.0 apps are troublesome enough. Hell, even apps built for OS X 10.0 are crashy on 10.2 and later.

ease of use for me is knowing where /bin and /etc are amongst other things

The app and the OS don't care though. Why force the user to think in silly 3-letter folder names? If the OS can do the work of keeping things in order for you, then let it.

Komodo brings the concept of bundles to Linux. GenSTEP inherits bundles through GNUstep. Bundles are just a concept that let you put an app, its resources, and support files inside of a folder tree and then abstract it into a single icon in the GUI.

NeXTSTEP did it first, using .app bundles. You can put them anywhere, double click 'em in Workspace Manager, and they run. When the OpenStep specification was published, you could even have multiple binaries inside the package for execution on multiple platforms. OPENSTEP/Mach x86, OPENSTEP/Mach for NeXT Computers, OPENSTEP/SPARC, and OpenStep on NT. One bundle, runs on them all. Package once, run anywhere.

You could do the same with Komodo's bundles.

will these be symlinked to /C/Program\ Files/ (or whatever it's supposed to be)?

Nothing so ugly and hacksy. Komodo uses its own methods, but the STEP parts of GenSTEP aren't tied to any sort of UNIX conventions. Think Mac OS X.

[Furious]

Komodo is *not* in anyway intended to cater to the Windoze lusers. That's not saying it doesnt accomodate them, but Komodo is intended to be the next-generation of Linux, not a specialized distro at all. The idea is to redesign it from the ground up looking at efficiency and usability. The way the traditional Linux filesystem is designed is very inefficient, because you will find yourself having to wade through hundreds of files in a bin or lib directory and you dont know whether its in /usr or /usr/local or some custom place. Wouldn't it make much more sense to go to where *you* installed the software, enter the software's folder and do what you need to do?

Read the About doc on http://calix.calyptos.com/. Calix is the old name by the way. The doc has some interesting features of Komodo. And of course if yo uthink any of it is bull hockey, tell me why and how you think it could be better. It's not like I think my designs are law .

[Furious]

Btw Calum, symlinks are not used to create the filesystem. The filesystem is 100% native real directories. In fact by release, the /etc, /bin, etc folders will be the symlinks to the Shared cache. This means provided none of your apps are STUPID (some are, believe me I've seen it all!) you could just delete them. This isn't the case yet becaues I haven't moved all the packages to Komodo bundles quite yet.