Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
The Unix tree rethought: an introduction to GoboLinux

By LodeRunner in Technology
Fri May 09, 2003 at 03:51:41 PM EST
Tags: Software (all tags)
Software

Lately, there has been lots of discussion on the current state of Linux as a desktop system, and articles pop up here and there, occasionally with very good ideas. However, none have surprised me more than this one. It was all very hyphothetical, but had pretty radical ideas on how the author thought the Linux directory tree should be reorganized. This was clearly the most polemical part of the article, and raised many discussions whether something like this could actually be implemented. And that's the reason for my surprise: we had this implemented for over an year. GoboLinux is a Linux distribution based on an alternative directory tree, which has evolved from a custom LFS installation to a distro that's used and maintained by a small group of people today. It was interesting to see that there are a lot of people interested in ideas similar to ours. So, maybe it's time for us to come out of the shadows.


A bit of history

We all remember the time when talking about Linux distributions for the desktop meant arguing which has the best installer. Much has evolved since: the easy, graphical installers are here, but we're not quite there yet. Among the usual rants on "why (insert pet peeve here) is the problem", some interesting ideas come up from time to time. More interestingly, some people started to believe maybe it's time for more adventurous attempts.

Oddly, GoboLinux did not start as one of those. The whole thing started when I had to install programs at the University. As I had no write access to the standard Unix directories, I created my own directories under $HOME the way I saw fit. I upgraded the programs from source constantly, and couldn't use a package manager. My solution was the most obvious one: to place each program in its own directory, such as ~/Programs/AfterStep. Soon the environment variables (PATH, LD_LIBRARY_PATH...) got bigger and bigger, so I created centralized directories for each class of files, containing symbolic links: ~/Libraries, ~/Headers and so on. A natural evolution was to write shell scripts to handle the links, configures and Makefiles.

This system proved itself to be very convenient to use. At my home system, I started to gradually remove pre-compiled packages and recompile them with those scripts. I was moving towards a completely custom Linux system, which I jokingly called LodeLinux. When I had it about 80% complete, the Great Filesystem Crash struck. It was time to start it all over again, but this time through a different route: instead of "deconstructing" an existing distribution, a friend (André Detsch) and I (Hisham Muhammad) spent two days building a modified Linux From Scratch system. Without much fuss, on March 20, 2002, GoboLinux was born. A month later, we presented an article at the 3rd. Workshop on Free Software called "A new proposal for the Unix directory tree".

What is it all about?

GoboLinux is definitely not "yet another Linux distro for the desktop". It is entirely based on an alternative directory structure. Every program lives in its own directory: you'll find XFree86 4.3 at /Programs/XFree86/4.3/, and ping at /Programs/Netkit-Base/0.17/bin/ping. To see what programs are installed in the system, all you need to do is ls /Programs.

For each category of files, there is a directory under /System/Links grouping files from each application as symbolic links: Executables, Libraries, Headers, Shared and Manuals. For compatibility, each "legacy" directory is a link to a corresponding category. Therefore, /bin, /sbin, /usr/bin, /usr/local/bin (and so on) are all symlinks to /System/Links/Executables. Environment variables are also simplified: export PATH=/System/Links/Executables is enough.

In short, what he have is a database-less package management system: the directory structure itself organizes the system (wasn't that its original purpose, after all?). Each program directory (for example, /Programs/KDE) holds version directories (/Programs/KDE/3.0, /Programs/KDE/3.1.1), and a version-neutral directory for settings (/Programs/KDE/Settings), to keep files that would normally be in /etc. Keeping two or more versions of a library is trivial. When most distributions switched to GCC 3 they released a new major version, mostly incompatible with previous ones. When the 006 series of GoboLinux adopted GCC 3, it was just a matter of keeping old versions of libraries alongside the new ones, while they were gradually phased out. No "compat" packages involved.

Most tasks in GoboLinux are automated by a collection of scripts. To create a GoboLinux package, just type something like CreatePackage CoreUtils. All this command does is storing CoreUtils/5.0/ and CoreUtils/Settings in a .tar.bz2 file called CoreUtils--5.0--i686.tar.bz2. A link called /Programs/CoreUtils/Current indicates which version is currently in effect. This is used by the scripts as a 'default version'. Installation of a program is handle by three scripts: PrepareProgram, which creates the /Program/<program-name> hierarchy and passes the proper options to configure. SymlinkProgram creates the links at /System/Links. A wrapper script, CompileProgram covers the common configure && make && make install case (with a number of command-line options to handle special cases).

Alternative boot scripts

Since we felt like we were "starting from scratch" and we really wanted to make a system where everything just made sense for us, we also took the time to rethink the boot scripts. I felt the two historical models (System V and BSD) were overkill for our common desktop-machine setup. GoboLinux uses a simpler system: two scripts, Init and Done, do most of the job. Additional scripts, such as Multi and Single, take care of the runlevels. These files are simply sequences of commands, prepended by the word Exec and a message string. Here's an excerpt of Init:

Exec "Setting clock..." SetClock
Exec "Loading keymap..." loadkeys "$KeymapLayout"
Exec "Bringing up the loopback interface..." ifconfig lo 127.0.0.1

More elaborate tasks such as SetClock are defined as shell functions in a Tasks file (these tasks can also be called from the command-line using the RunTask script). Configurable settings are defined as environment variables in the Options file. The wrapper function Exec allows for a nifty additional feature: boot themes. The boot sequence can look Slackware-like (with the standard error/output messages), RedHat-like (with lots of OK's), or GoboLinux-like (the latter uses a modified version of the Linux Progress Patch).

The "legacy" tree

Unfortunately, not all programs have the flexibility to be installed anywhere. Occasionally, hardcoded paths creep in, even in programs that belong in userland (which should, at least theoretically, allow themselves to be installed inside a user's home directory).

As much as I'd like to see this done in the long term, patching all applications is not an option. For this reason, GoboLinux keeps a legacy tree where all usual Unix paths are mapped to GoboLinux equivalents, so, if a Makefile looks for /usr/X11R6/include/X11/Xaw3d/XawInit.h, it will find it, although it is at /Programs/Xaw3d/1.5/include/X11/Xaw3d/XawInit.h, where it belongs. When two applications have a directory entry with the same name, the GoboLinux scripts recursively expand them. Both XFree86 and Xaw3d have X11 under include. A directory /System/Links/Headers/X11 is created automatically, holding links from both X11 directories.

Another interesting feature is that the GoboLinux scripts execute make install using a special user id that only has write permissions inside the program's source directories and the program's entry under /Programs. This way, files can't "escape" from the GoboLinux hierarchy and slip directory into the legacy tree.

The GoboLinux directory structure brings a fresh, clean look the Linux system, but the presence of the legacy tree, while necessary, takes some of this beauty away. Mac OS X uses a "dirty trick" to cover up its Unix nature: the Finder won't show the Unix directories, but you can see them from the command line. In Linux we have many different ways for looking at the filesystem (shells, file managers, browsers...), so we had to go deeper to have a clean-looking system. GoboHide is a (obviously optional) kernel patch plus userland application written by Lucas Correia Villa Real and Felipe Damásio that effectively implements "hidden files" on Linux (way beyond dot-files, which are implemented on UI-level just like Finder does).

Here's what ls / looks like on GoboLinux:

Depot
Mount
System
Files
Programs
Users

Related work

As you read this, you have probably found many familiar concepts (not to mention directory names). GoboLinux has clearly found inspiration in other operating systems, like Mac OS X, BeOS and AtheOS, but I think that the notion that they build "something different" using an existing Unix base (be it using a Unix kernel as in OS X or using GNU tools as in AtheOS) was the most important influence of all. Right now there are several other projects, in various stages of development, that use the Linux Kernel as a foundation and feature alternative directory trees. Interestingly, most of them are clones or heavily inspired by a specific proprietary operating system: ROX OS intends to be a RiscOS-like system, LinuxSTEP is a project based on GNUstep aiming for a NeXT-like system, and BlueEyedOS aims for a source-level-compatible BeOS clone.

GoboLinux, on the other hand, is not a clone of anything else. It uses standard Linux desktop software. We believe that the well-organized directory structure makes it a good testbed for new ideas -- possibilities are wide open.

Where are we now?

GoboLinux has evolved immensely during the last year. At gobolinux.org you can find an ISO image of our latest release, 006. It's a bootable "live CD" running GoboLinux in a chrooted read-only filesystem, so you can walk around the directory structure and have a peek at what GoboLinux feels like. The CD also features the usual installer scripts and extra packages. There's no flashy graphical installer yet, but I think the ease-of-use of the installation reflects the overal ease-of-use of the system as a whole (unlike it happens on many distributions).

Despite the very small user base (we have never really announced it anywhere yet), the project has progressed quickly and has been fully usable for quite a while now (most GoboLinux developers use it as their only operating system, and a few others do so, as well). So, we invite you to give it a spin too. You might like it.

Acknowledgements

Besides the names that were already mentioned above, I'd also like to thank Guilherme Bedin and Rafael Jeffman for their contributions to this article and to the project.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Hmm, GoboLinux...
o That's what I was waiting for 16%
o Will check it out 16%
o Heresy! It's too un-Unix! 14%
o Good ideas, weird name 27%
o Ok. So what? 25%

Votes: 87
Results | Other Polls

Related Links
o here
o this one
o GoboLinux
o LFS
o not quite there yet
o André Detsch
o Hisham Muhammad
o Linux From Scratch
o 3rd. Workshop on Free Software
o GoboLinux-like
o Linux Progress Patch
o Lucas Correia Villa Real
o AtheOS
o ROX OS
o LinuxSTEP
o BlueEyedOS
o gobolinux. org
o Rafael Jeffman
o Also by LodeRunner


Display: Sort:
The Unix tree rethought: an introduction to GoboLinux | 292 comments (280 topical, 12 editorial, 0 hidden)
So . . . (4.28 / 7) (#1)
by ubernostrum on Fri May 09, 2003 at 01:09:45 AM EST

It's Mac OS X?


--
You cooin' with my bird?
No... (none / 0) (#103)
by gidds on Fri May 09, 2003 at 10:40:17 PM EST

...but it does have interesting similarities. For example, the idea of keeping all an app's files together in one directory so it can be easily deleted &c is similar to Mac OS X's bundles, which are treated by the GUI as a single file which can be moved, copied, deleted, renamed &c transparently, and will work anywhere.

In many ways, Mac OS X is a hybrid system; there's quite a gulf between the way Unix apps work (installation in /usr/local, command-line operation or X, hidden from the GUI, can't start from the GUI, linked with standard libraries, not scriptable) and GUI apps (usually installed in /Applications &c, available from the GUI but can be started from the command line with `open', linked at runtime with frameworks &c, scriptable).

The GUI is great, and the OS has made many great improvements to the base Unix system, but this dichotomy remains and makes many things quite awkward.  Removing it would be extremely awkward, though :(

Andy/
[ Parent ]

partitions (4.33 / 3) (#4)
by adiffer on Fri May 09, 2003 at 01:53:04 AM EST

My understanding of the old directory tree is a little murky, but one thing I remember is that certain bottom directories were meant to be given their own disk partitions.  This made it hard for users to fill up partitions required by the OS for smooth operation.  Users may get locked out when /home fills up, but the administrator can still get in to fix things because the box still runs and /root isn't on the same partition.

Do you make any effort to protect access to certain system-needed tools this way?
--BE The Alien!

You can if you want it (4.00 / 1) (#6)
by LodeRunner on Fri May 09, 2003 at 02:08:00 AM EST

I personally think that the best way in a multiuser environment to control that the users won't fill up the drive is through quotas. But if you want you can mount the superuser account in a different partition, it just doesn't need to be placed in the root directory (mount points are traditionally subdirectories of /mnt, after all). So, basically, this kind of protection works as usual.


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

Home partition (5.00 / 1) (#45)
by influx on Fri May 09, 2003 at 11:43:28 AM EST

I prefer having /home being a seperate partition because it makes upgrading distributions or changing them completely much simpler. Just select that partition as a mount point for home in whatever installation/upgrade, make sure to back up any /etc or other programs into home and then you can wipe the entire drive.

---
The more you know, the less you understand.
[ Parent ]
Quotas won't handle ... (none / 0) (#252)
by HypoLuxa on Mon May 12, 2003 at 05:05:19 PM EST

... log files and /tmp directories and mail spools getting out of hand. It's not much of an issue on single user systems, but for systems designed as servers (the vast majority of linux systems outside the hobbyist realm) proper partitioning is a must.

--
I'm guided by the beauty of our weapons.
- Leonard Cohen
[ Parent ]
You can still use partitioning, of course (none / 0) (#263)
by LodeRunner on Tue May 13, 2003 at 03:58:04 PM EST

In GoboLinux, /var works exactly like in regular distributions. It has only been moved to /System/Variable. You can mount it (or even subdirectories like log, spool or mail) as separate partitions. The /Users directory can also be in a separate partition.

The only current limitation is that /System/Links and /Programs have to be in the same partition. When we have union-mounts (a feature not yet available in 2.4 kernels), it will be possible to compose /Programs logically out of a number of physical partitions, for example, isolating programs needed for boot, programs loaded off the network and programs installed locally, just like /bin, /usr/bin and /usr/local/bin do. This will bring the best of both worlds: the logical abstraction (which is what a file system is for) and the physical flexibility. This is in the to-do list for GoboLinux 007.

---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

You're kind of right.. (none / 0) (#287)
by Wiggy on Tue May 27, 2003 at 08:30:33 AM EST

you're specifically talking about "the /var problem" where if an application goes mad and starts syslogging, it fills the disk and nobody can log in but root (in olden days, and sometimes now on some systems, because you can't write to disk, you can't login - the reason why is left as an exercise to the reader). This is especially a problem if the machine is in a lights-out facility on another coast, as you probably didn't set up any remote secure terms (i.e. the only way to get root is to log into a user account who is allowed to su and then su) so nobody can log in at all.

It's normally a reasonable idea to give /usr it's own mount point seperate from / as well, just to make sure your users don't cause problems by filling disks with mail and warez. :-)

Hope that helped..

[ Parent ]

no (3.62 / 8) (#10)
by heng on Fri May 09, 2003 at 03:45:22 AM EST

(Generally) The people saying Linux on the desktop is shit and that it's too hard to use are the Windows semi-power users. Those people that like to tinker with their windows machine, understand the directory structure and aren't afraid of the control panel, but don't do any *real messing (registry etc). To them Linux represents something different and frightening, and because they are the most influential in the computing world, basic users (the people that just use programs) believe them when they are told Linux is hard.

The reality is that a well set up linux desktop is as easy (if not easier) to use than a windows desktop for people who don't want to tinker. My little (10 year old) sister can use my computer quite happily with no Unix experience at all. She need not know about the command line, or the directory structure, or shell scripting. She just cares about what Gnome offers. This is the reality for most computer users. The sooner the semi-power users stop exerting their unfounded influence, the better off everyone will be. But then, change takes a generation, I guess we'll just have to wait for them to die off.

Also, the linux directory structure really isn't difficult to understand. If you wish to tinker with the underlying structure (leave the home directory), then you should read that single paragraph that describes what /usr, /etc, /bin... etc are used for.

This is _not_ about user-friendliness... (4.33 / 6) (#11)
by LodeRunner on Fri May 09, 2003 at 04:17:29 AM EST

This is about organization. The motivation for the GoboLinux hierarchy was to have a structure where it's easy to compile and install programs from sources (the original .tar.gz's distributed by program authors) and later remove them, with no database-oriented package system involved. I got tired of package databases that go out of sync, 'cause I never was the type that waits for a package to come out for my distro of choice -- I'd always go ahead and compile it myself. In GoboLinux, creating a "package" is not much more than running tar, removing a package is not much more than running rm. A few scripts automate boring tasks, but nothing is "automagical".

About your comments about Linux on the desktop, I basically agree with them all. For people who don't want to tinker (ie, don't administrate their boxes), which distribution or which directory hierarchy is in use makes no difference whatsoever. I just introduced the article in the context of "desktop Linux ideas" because there is where most pro-change ideas are. I also agree with you that the Linux directory structure is not difficult to understand and tinker with. If it were, perhaps I wouldn't be able to modify it that much. I can see that the traditional layout may have its uses (I read the FHS and I'm aware of why the traditional tree is laid out the way it is), but I also think that the GoboLinux structure (or GoboLinux-like structures in general) makes more sense, at least for our current dominant computing model based on personal computers.


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

Dependencies (5.00 / 2) (#36)
by greenrd on Fri May 09, 2003 at 08:43:39 AM EST

Does your system have any dependency handling? Or do people have to RTFM or figure out the error messages to find out what the dependencies are for each package?


"Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
[ Parent ]

Dependency handling (5.00 / 3) (#39)
by LodeRunner on Fri May 09, 2003 at 09:32:13 AM EST

We have the beginnings of a dependency handling system. It is incredibly simple but actually pretty effective.

The CreatePackage script, before creating a .tar.bz2 file containing, say, App/1.0 and App/Settings, runs ldd on each binary file and traces back the owner app of each library that was identified, Results are stored in a file named App/1.0/.dependencies. Let's take a complex app for example. This is what the file /Programs/KDE/3.1/.dependencies looks like:

Bzip2 1.0.2
CDparanoiaIII alpha9.8
GCC 3.2.1
Glibc 2.3.1
Lame 3.93.1
Lesstif 0.93.36
LibART_LGPL 2.3.11
LibJpeg v6b
LibOGG 1.0
LibPNG 1.2.5
LibVorbis 1.0
LibXML2 2.5.1
LibXSLT 1.0.23
PCRE 3.9
QT 3.1.1
Shadow 4.0.3
XFree86 4.3
ZLib 1.1.4

When you call InstallPackage KDE--3.1--i686.tar.bz2 it looks in a few pre-configured directories (/Depot/Packages, /Mount/CD-ROM/Depot/Packages, etc.) for package files matching the names specified in the .dependencies file (that are not already installed, of course) and asks if you want to install them. If you pass the --batch option, they are installed automatically. As expected, dependencies are searched for recursively.

Obviously, this automated method of generating packages is not perfect (for example, if a package contains a shell script that calls some program, this program won't show up in the dependency list). But it's a clever heuristic, and it suffices for the vast majority of cases. Anyway, the .dependecies file can be hand-edited and completed if necessary.

One aspect of GoboLinux that turned out to be quite interesting is that packages do get installed even if dependencies are missing, and the user can fix the dependency issues afterwards. It's important to note that this behavior is harmless, because we don't depend on a database. I know this sounds hackish, but at this point of development (where we don't have a big team developing packages, and it's basically the user base informally helping each other out) it's much quicker to just install a program, run it, check the "missing library libpng.so.1" message, look at the .dependencies file, and download everything that's missing. And yes, we plan to have, eventually, automatic downloading of packages like "everybody else".


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

Capitalization (4.00 / 1) (#93)
by jsoderba on Fri May 09, 2003 at 08:38:08 PM EST

LibJpeg v6b
LibOGG 1.0

It seems a bit odd that you haven't upper-cased a word that is quite clearly an initalism, while you have written a name that is not an abbreviation or acronym of any kind in all-caps. (Against the stated wishes of the developers, no less.)

A small nit, but still.



[ Parent ]
Good catch, but... (none / 0) (#174)
by LodeRunner on Sat May 10, 2003 at 02:14:54 PM EST

Proper capitalization of names has been a concern from the beginning. Right now what we have three mechanisms to deal with this:

First, when CompilePackage runs, it scans for the README file and finds the most frequent capitalization used. This works on a lot of programs with uncommon capitalizations (e.g. LyX).

Second, a script called DeduceName does some heuristics to find a proper capitalization, based on the length of the name, common prefixes and suffixes (Lib, Progs, Utils, etc.) and placement of vowels. This script was responsible for LibJpeg and LibOGG. It does a fairly good job, but can always be improved.

Third, the user can enter the name by hand. Before proceeding, CompilePackage shows the deduced name and version numbers and asks for Enter or Ctrl-C. Names like XFree86 were entered by hand, IIRC.

Perhaps we could add a text file with a 'dictionary' of program names for the cases where the first or second methods don't suffice. I'll add this to the To-do list.


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

OK, but why that name? (none / 0) (#281)
by gsabaco on Sat May 17, 2003 at 07:02:54 PM EST

Ok, but wouldn't it make more sense to have the file name be /Programs/KDE/3.1/Dependencies? Why (after work to the contrary) do you switch to using dot files and all lower case?

[ Parent ]
Installing packages from sources (5.00 / 1) (#72)
by 1j1 on Fri May 09, 2003 at 06:15:11 PM EST

I use to be worried about installing programs from sources, but now I rely exclusively on installwatch.

You compile your program as usual: ./configure;make
but then install the package with something like /usr/local/sbin/installwatch

The beauty of the program is that it install the program in a temporary location and then generates the apropiated file (rpm, deb, pkg). You can later install the package, say with rpm.

This way you mantain your package db up to date and don't risk that the installer overwrites some existing file.

[ Parent ]

Let me tell you an exciting story (1.81 / 16) (#12)
by starsky on Fri May 09, 2003 at 04:19:58 AM EST

I am friends with a major developer of the KDE desktop doobrie. I was kind of interested in Linux, and since my friend was always getting free boxed linux distributions, he gave one to me to try.

It installed pretty easily and I was very happy, until I cam to install my modem and was asked to type in INDIVIDUAL AT COMMANDS. Yeah, nice one.

I produce software that MILLIONS of people all over the world use every day, and I CANNOT BE FUCKED to do gay little things like this.

I'm sure you're gonna say 'well, that was then, now....' - whatever, dude. Windows does all this, and more already. Windows IS free, my work buys me it.

If you like Linux, that's great, use it. But why do so many Linux users devote so much fucking time to telling peopel how great it is and why we shoudl use it?

[ Parent ]

thank you (3.00 / 2) (#16)
by heng on Fri May 09, 2003 at 05:06:46 AM EST

You're a perfect example. How many users actually install their own operating system?

[ Parent ]
Actually (4.66 / 3) (#20)
by starsky on Fri May 09, 2003 at 06:01:53 AM EST

I've installed Windows many hundreds of times. IN many languages, including Arabic and Hebrew. Thats backwards, with little crushed insects instead of words. And I can still do it. And yet I find Linux installations tricky. How tricky would I find them in arabic?

[ Parent ]
I do know (5.00 / 3) (#28)
by gazbo on Fri May 09, 2003 at 07:05:07 AM EST

That an ever increasing number of people maintain their systems. That they will install their new USB digital camera. Or replace their now broken modem. People don't need to get the "professionals" in to do such things nowadays, and that trend is continuing. In other words, people may not install the OS from scratch initially, but they most certainly add/remove devices and install upgrades.

-----
Topless, revealing, nude pics and vids of Zora Suleman! Upskirt and down blouse! Cleavage!
Hardcore ZORA SULEMAN pics!

[ Parent ]

Yeah right. (4.00 / 4) (#29)
by gordonjcp on Fri May 09, 2003 at 07:35:46 AM EST

What were you installing? Redhat 4.0 or something? Linux is just as easy to install as Windows.
Probably easier, actually. I installed Windows 2000 on a machine for one of my users, and I actually had to type in a licence code before it would work - and *then* I had to reboot before it would work. Would you believe it?

Give a man a fish, and he'll eat for a day. Teach a man to fish, and he'll bore you rigid with fishing stories for the rest of your life.


[ Parent ]
I don't think you'll find anyone (4.80 / 5) (#32)
by DesiredUsername on Fri May 09, 2003 at 08:17:38 AM EST

saying that the "Linux Advantage" is "ease of installation". In fact, I'm pretty sure no will (sane) will try to claim it's even "ease of use".

I use Linux at both work and home all the time. Whenever I have to switch over to Windows, I feel constrained. Why can't I have multiple desktops? Why is the CL so hard to use? Why can't I cut and paste by just highlighting? Why can't I pipe correctly? Etc. (Yes, I know there is software addons to fix a lot of this.)

Linux definitely takes some getting used to, but for some types of tasks (such as the ones I like to do) it is much more powerful and flexible. There are also some things, like installing hardware, that can be trickier under Linux than under Windows. But I hardly ever install hardware and when I do it's usually a couple of years behind the times (for cost reasons but also because I don't need bleeding edge). Neither do I play many games, so software availability isn't a problem for me.

The reason Linux users tell other people how great it is is that they aren't aware that other people have different needs. You can blame this on their smelly hippy-tude if you want, but I wouldn't say that tech people in general have a reputation for empathy.

Play 囲碁
[ Parent ]

My story (4.50 / 2) (#82)
by mindstrm on Fri May 09, 2003 at 07:08:38 PM EST

I'm a power user.. by far. I get as technical as one can get... I've been using linux for 10 years, since early .86 (or something like that) kernels. So.. my view on computers has always been from a point of view of great technical understanding. This is why I always really liked unix: it gave me the power.
But everyone knows that story, right?

I recently took the time to look at linux from a totally different point of view: to install a desktop system, and use it for regular office work (email, spreadsheets, documents, web tools, and some sysadmin tasks) without resorting to old school unix ways... in other words, to treat it as a new desktop system, not as unix.

So I grabed mandrake 9.1, and installed it, with gnome as the only desktop system.

It was easy. It worked.  It didn't ask me bizarre questions. When it DID ask a question, it actually  explained the question properly. It didn't tell me lies about what it was doing.  I didn't have to do anything obscure. I should point out I made a real effort to consider whether any step was easy or hard for an average computer user.  

So I used it for a bit.. and found the gnome desktop really easy to use. It was actually useful... not just in the ways that I've always found X useful, but from an officework point of view, it was useful.  I tried not to fall back to the shell and instead do things through the config tools with great success. It was easy to find what I wanted.
What I'm saying is, I found the GUI layout and design to make MORE sense and be MORE straightforward than what Windows. It was more usable, and more logical.

So.. of course, I might be wrong. After all, my view is distorted by almost 20 years of hardcore computer use.. so I grabbed my girlfriend.
She's a very average computer user (or at least, she was before we started working with this). Very smart, but no real computer experience, just a bit of windows.

I pointed out a few things that were different about how the desktop worked, and how I thought she might want to use them:
- Add a menubar at the top of the screen, and grab icons for apps you use all the time out of the foot menu and stick them there.  Saves you clicking.
- Use the windowlist in the top right corner to find stuff. Don't hunt around for it.
- Instead of minimizing windows, make use of the virtual desktop... it's far easier to keep track of what you are doing that way.
- Pay more attention to how you lay out your tools on the screen. Don't just maximize/minimise everything. Keeping things arranged the right way on each virtual desktops helps you keep track of what you are doing. (Think about hit.. how much does digging around on your windwos desktop to find some window distract you from your task?)

All these things, she does now, automatically; I didn't have to mention it more than once initially. In total, I've spent maybe 2 hours going over linux.. and now she does just fine. I came in, found she had her desktop set up the way she liked it, and I don't mean with pretty pictures.  

Now.. applications don't all work the same way.. something like the weird menu buttons in XMMS threw her off, because they aren't consistant... and that's a big hurdle for user interface. We need consistancy in GUI apps.  Cut & paste mostly works great.. but sometimes it doesn't work at all when you think it should. There ARE problems... but once you get used to them.... well, she really likes using gnome/linux now.

So what I'm saying is.. a real easy to use desktop , from the point of view of the average home/office user IS within reach, it's already here. We don't need to re-invent anything to do it... we just need to focus on making sure that we don't NEED to resort to the shell.
Of course.. we need to also focus on making sure we CAN resort to the shell without breaking everything.. but that's another story. So far, we're doing good.

[ Parent ]

consistency (none / 0) (#130)
by lemming prophet on Sat May 10, 2003 at 05:21:21 AM EST

without wanting to start a flamewar, i think KDE achieved a consistency that gnome just doesn't have (yet) , if you use the "KDE"-versions of the programs...
that is, noatun for mp3 playing,
kmail for email,
sim / psi / kopete for IM,
konqueror for browsing,
koffice for office tasks,
... and i think the "newbie" users don't care what brand of mp3-player they use, as long as it's point-n-click and plays mp3s :)

another thing, the kde kcontrol / config menu is really easy-to-use, as opposed to the "gnome registry" the developers thought was needed for gnome2 ...
--
Follow me.
[ Parent ]
No flame war necessary. (5.00 / 1) (#168)
by mindstrm on Sat May 10, 2003 at 01:47:28 PM EST

I agree with you.. KDE has been ahead of gnome since day one. I used to refuse to use gnome, because KDE was just so much more together. And, I'm sure it still has an edge.

I used Gnome because, well, there is just something about kde that rubs me the wrong way.  Gnome feels more exact, to me... KDE felt a bit bloated.  As for the control/config menus, i'm having no problems with those.

In a way you emphasize my point. I agree with all your points. I'm ponting out that even if I take the less-polished GNOME desktop, it's easy enough for a newbie to use... therefore, the stuff about linux not being ready for the desktop is hogwash.

[ Parent ]

Multiple Desktops under Windows XP (5.00 / 1) (#104)
by OldCoder on Fri May 09, 2003 at 10:59:53 PM EST

I have multiple desktops on my XP system. It either came with XP or with the Windows Plus Pack (extra dollars). It is limited to exactly 4 desktops, but it has nice features, like configurable keystrokes for each desktop, a button bar to switch between them, a preview mode I can use to click on the desktop I want, and a different background image for each desktop.

The command line is harder to use because it was conceptualized as Windows. On the other hand, the XP command line toolset is better than its predecessorrs in that it has several good new system administration tools and one super-duper feature that is new to Windows CL: Documentation! Just open up the help browser (also new to XP) and it's all there! I was so happy to see that I nearly cried! Real, complete documentation of the command processor and the command line tools. It was actually a better processor than anybody knew. There are "else" clauses for the if statement and subroutines in the same file.

Piping works better under XP and 2k than under earlier windows. They even snuck in correct usage of the "1>&2" idiom from *nix.

Cut and paste by highlighting, and a useful universal cut stack, are not available, AFAIK.

--
By reading this signature, you have agreed.
Copyright © 2003 OldCoder
[ Parent ]

LiteStep (none / 0) (#139)
by Pholostan on Sat May 10, 2003 at 06:11:30 AM EST

I use LiteStep in W2k. I've used it since early 1998. It is higly configurable and sports things like multiple desktops. The main reason I started to use it was that it crashed much less than explorer did during program testing :-)


- And blood tears I cry Endless grief remained inside
[ Parent ]
Let me tell you an exciting story (3.90 / 10) (#53)
by pb on Fri May 09, 2003 at 04:15:17 PM EST

I am friends with a major user of the warez underground. I was kind of interested in Windows, and since my friend was always burning free beta windows cds, he gave one to me to try.

It installed pretty easily and I was very happy, until it popped up a box and was asked to type in BIZARRE REGISTRATION CODES. Yeah, nice one.

I produce software that MILLIONS of people all over the world use every day, and I CANNOT BE FUCKED to do gay little things like this.

I'm sure you're gonna say 'well, that was then, now....' - whatever, dude. Linux does all this, and more already. Linux IS free, and legal as well.

If you like Windows, that's great, use it. But why do so many Windows users devote so much fucking time to telling peopel how great it is and why we shoudl use it?
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]

What the fuck (3.00 / 6) (#147)
by starsky on Sat May 10, 2003 at 08:21:35 AM EST

are you even on about? Where did I mention ripping off software? I hardly think you can compare typing in a registration code to typing in AT commands for a modem. Also, nice to see the lovely /. moderation bias - ooohh, pro-linux, 5, 5, 5, let me suck your cock uh uh uh. Gay bastards.

[ Parent ]
well, there's perspective for you.... (none / 0) (#186)
by pb on Sat May 10, 2003 at 03:59:49 PM EST

I just thought you'd be interested in a little story, I figured you might find it to be just as interesting and enlightening as your little story was. Perhaps I was wrong?

I've never had Linux ask me for a registration code, btw, much as how you apparently have never had Windows ask you for modem commands. (actually I haven't had to type in modem commands for anything since the days of DOS and Telix, and that was entirely optional, but hey....)

As for the rest of your comment, well, (a) you're not on slashdot, and (b) you might find that some moderators don't appreciate being called "gay bastards", regardless of their sexual orientation.

Cheers!
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]

Interesting Politics and Ecology (4.60 / 5) (#13)
by OldCoder on Fri May 09, 2003 at 04:26:01 AM EST

Something like this has needed to be done for a very long time. The amount of administrator work saved by a really rational directory tree could be enormous. The trouble is, it takes a while to be sure that what you've built is actually an improvement overall, and not just a speedup of today's squeaky wheel.

It is especially interesting that the proprietary Unix vendors and corporate Linux distributions haven't, to my knowledge, done this; It's exactly the kind of thing that one would expect to be handled better by a hierarchical management organization. Just issue the order to do it.

But these existing organizations are married to the installed base, and are terrified of alienating it. You will run into similar problems as you try to propagate your ideas.

It's also pretty interesting that the Windows directory tree is able to change somewhat from one release to the next without too much of a problem. But they don't change it much. In Windows XP, the program directory "Program Files" is spelled the same in several language variants but is different in say, Japanese Windows. So stuff that used explicit paths when needed for security suddenly broke and had to switch to using the envariable "ProgramFiles". But it was available. GoboLinux will need a similar scheme if it is to be multi-lingual.

The use of /mnt for mount points is not "Traditional" Unix to me. It is a middling-old innovation. But that's just me.

It is very useful, necessary, in fact, for all the machines under the same administration to have the same directory tree. For script and program compatability compatibility, of course. On which Linux distributions have you tried GoboLinux?

--
By reading this signature, you have agreed.
Copyright © 2003 OldCoder

Interesting questions (5.00 / 1) (#17)
by LodeRunner on Fri May 09, 2003 at 05:20:38 AM EST

Something like this has needed to be done for a very long time. The amount of administrator work saved by a really rational directory tree could be enormous. The trouble is, it takes a while to be sure that what you've built is actually an improvement overall, and not just a speedup of today's squeaky wheel.

Those who got to use it usually regard it as a definite improvement. About the time to evaluate if this is effective, what I can say is that I've used this structure "hosted" inside other distributions for about six months, and then alone as a distribution by itself for another year. The structure has changed (not radically, but in a few key points) during this time, and everything indicates it will continue to evolve in the future. This is free software, and a young project: we can afford the changes.

But these existing organizations are married to the installed base, and are terrified of alienating it. You will run into similar problems as you try to propagate your ideas.

True. But I think that the free software model alleviates this a lot. New versions can be obtained for free, things can be recompiled. Getting the software as good as possible is the end goal. The GCC guys were not afraid of breaking compatibility with version 3. It was a bold move, but it was necessary.

In the specific case of GoboLinux, its modularized structure makes it much more amenable to its own changes. During the last year, as things changed, we made conversion scripts. I, for one, never reinstalled my system since day one.

It's also pretty interesting that the Windows directory tree is able to change somewhat from one release to the next without too much of a problem. But they don't change it much. In Windows XP, the program directory "Program Files" is spelled the same in several language variants but is different in say, Japanese Windows. So stuff that used explicit paths when needed for security suddenly broke and had to switch to using the envariable "ProgramFiles". But it was available. GoboLinux will need a similar scheme if it is to be multi-lingual.

From our part, we took care of this. GoboLinux programs/scripts use environment variables such as $goboPrograms instead of hard-coding /Programs, for example. We have a package called "Rootless GoboLinux" that can be hosted inside other distributions. It uses the standard GoboLinux toolset, only with $goboPrograms set to $HOME/Programs, and so on. The problem is that many programs hardcode the prefix they were compiled with into the binaries. GoboLinux could theoretically have internationalized directory trees, but they would be largely binary-incompatible to each other. I have noticed that Windows XP also does some renaming on UI level, displaying "My Documents" or "Foo's Documents" depending whether it's Foo or someone else who's logged on. I personally dislike the idea. But, anyway, these are high-level UI issues, beyond the scope of GoboLinux.

The use of /mnt for mount points is not "Traditional" Unix to me. It is a middling-old innovation. But that's just me.

Oh, sorry. Perhaps I should have used "traditional Linux" (but I fear that would not be accurate, as well).

It is very useful, necessary, in fact, for all the machines under the same administration to have the same directory tree. For script and program compatibility, of course. On which Linux distributions have you tried GoboLinux?

I think the "Rootless" hosted mode can run in most, if not all, Linux distributions. A friend of mine even ran it on Windows 2000 using Cygwin (there's a fun screenshot of it in our site). However I think the maintainability gains really shine when using it as a stand-alone distribution.


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

Still More!!! (5.00 / 1) (#94)
by OldCoder on Fri May 09, 2003 at 08:50:42 PM EST

The next windows, Longhorn, will have the "Windows Future Storage" system based on an expanded SQL Server. Of course, a complete file system re-write is a bigger project than an overlay of directory structures. ZDnet says Future Storage:
.. promises to make the physical location of files irrelevant, thanks to an elaborate system of shortcuts and desktop-based searching.
Some additional information is available here. The relevant part is the discussion of "virtual folders" made by "stacking files". I don't know if this part of the new file system helps system administration much. So I guess WinFS addresses many of the same issues that GloboLinux is addressing.

Proprietary vs Open Source
I think that initiatives like Future Storage are an area where proprietary operating systems could march ahead of open source/free operating systems.

Lots of Linux and of Windows is totally non-innovative. Even for Future Storage, which clearly is an innovation, also crucial is the of quality of execution and of integration of the changes with all the products impacted. Oracle came up with an "Internet File System" that does some of the same things for applications (on servers, I suppose), but of course MS won't integrate its applications with it.

In the competition between the Open Source and the proprietary worlds, the search for the killer app may, in the end, be decisive. If one of these two schools is continuously faster than the other in introducing useful innovations, the other school is doomed to failure. On the other hand, catching up is always easier than innovating. Can proprietary efforts, such as Microsoft, hold back and keep secret whole groups of innovations and then introduce them all at once to flabbergast the world? I don't know, but it's reasonably certain that the Open Source world cannot do this as easily, if at all.

Grids vs Trees
My own opinion of tree-structured directories is that they are often used by software engineers where a grid of directories would be more appropriate. For all the different versions of whatever.lib, there are parent directories for architecture (x86, mips), sometimes version number, product level (pro vs entrylevel) and so on. There is no natural "Top" to the hierarchy. It's an n-dimensional lookup that we habitually map onto a tree. Very unnatural. It's the same with business correspondance.

A vendor may send correspondance (email and word processing docs) to both IBM and General Motors about it's new office furniture, and a different series of correspondance about office supplies, a third set about electronic products, and a fourth about commerce going the other way about using the company's software or fleet of cars. There is no natural "Top" to the hierarchy, and it's again an n-dimensional grid. Programmers have enough trouble using environment variables to organize builds. I don't think non-computer businesses will get it right. Directory structure is about searching and sorting, that is, finding things.



--
By reading this signature, you have agreed.
Copyright © 2003 OldCoder
[ Parent ]

On the future of data management (none / 0) (#225)
by LodeRunner on Sun May 11, 2003 at 04:59:52 AM EST

Yes, I think that in the near future things can become radically different. I have lots of ideas on this subject, but I suspect that those aren't very different than those that you or anybody else who's thinking about it has. The bottom line is that tree hierarchies can only go this far, really, and when the time comes when we're spending a considerable amount of time creating the "ontology of our files" (mail folders come to mind), then it's time to move to something else. We want a search-oriented interface, which usually imply in heuristics, but we also want a deterministic way to access files. How to integrate it to the interface is another question.

I think GoboLinux is a step forward inside the current paradigm, but of course I don't think, even in this paradigm, that it's a be-all end-all solution (au contraire, it has lots to evolve yet).

I'd love to see even a tiny step in the direction of new paradigms. There was a project called newdocms (for "new document management system") that appeared, gained some momentum and died off quickly. It was an implementation of a search-based, metadata-oriented interface to files, using SQL as a backend and using a modification to the KDE file dialogs as a frontend. It was quite limited but it showed potential, but apparently the author didn't feel like carrying on.

I may sound too optimistic here, but it wouldn't take long to get something usable in this direction. Any improvement is an improvement: if I could organize my MP3s in a grid-like manner, as you said (not having to choose between separating by albums or by styles -- songs in albums have different styles) I would already use it. Maybe MP3s were a bad example, because there are probably playlist managers out there that do this (not surprisingly, since MP3 is one of the few formats that explicitly carries metadata). Once I wrote a few command-line tools to index my research papers in a similar way, as a proof-of-concept, and the experience was positive. I'm sure there must be somebody out there working on something like this as I type -- GoboLinux was "hidden" for an year and a half, something else might just come up tomorrow.

What we know that will come up, eventually, is Longhorn. Until then, a free next-gen data management system might or might not come up. It may not be a jawdropping implementation, it may not "redefine our systems as we know them", but if it comes up, it'll be a welcome start. All it takes is one person to do it, really. If it's usable enough to interest more people and open enough so this people can contribute, it'll progress. If events take that route, it will probably become something completely different than Longhorn. If nothing happens until then, we're back to "catching up" as you said, because someone will want to clone at least the ideas behind it.

GoboLinux was originally created as a solution to my own everyday needs, it's the typical "scratching-one's-itch" situation as it's usual in free software. Breaking new grounds, as in terms of abstractions we use to interact with computers, doesn't fall in this category. It demands a stronger kind of incentive, be it in form of a exploratory feel to pursue an idea, or academic research, or the funding that companies like Microsoft have.

Who knows, this very thread might inspire someone to start writing the data mgmt system we'll be using years from now. :-)


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

'Documents and Settings' can't be moved on Win2k. (none / 0) (#64)
by nstenz on Fri May 09, 2003 at 05:08:05 PM EST

I have yet to find a place where I can change the 'Documents and Settings' location. The installer always forces it to be in the root of the system's boot partition. However, NT4 to 2000 upgrades leave the user profiles in \WINNT\Profiles, so there must be a setting somewhere that decides where the directory goes.

I searched my entire registry for 'Documents and Settings' and changed every path to another drive letter, but it didn't work.

If anyone knows how to move that directory, it would be nice to know. I want to put my users' profiles onto a RAID array my system disk isn't a part of.

[ Parent ]

Try Magic Tweak (none / 0) (#84)
by OldCoder on Fri May 09, 2003 at 07:38:42 PM EST

I know there is a way to change the "Documents and Settings" in Windows XP Pro, which is what I'm using. I think there is a way in win2k. Try the windows "power tools" and/or the "kernel tools", or is it "kernel toys"? on the MS website.

Next, go to magictweak.com and download the free trial of Magic Tweak to see if they have a way. Perhaps you could copy off your registry and .ini files, run the tweak, and then compare the new registry and .ini files to the previous. If you can't figure it out, you can purchase the product, or try the newsgroups under microsoft.public.win2000 or microsoft.public.windows. There are some areas called registry in there, which sound promising.

--
By reading this signature, you have agreed.
Copyright © 2003 OldCoder
[ Parent ]

TweakUI or just REGEDIT [nt] (none / 0) (#98)
by grouse on Fri May 09, 2003 at 10:23:58 PM EST


You sad bastard!

"Grouse please don't take this the wrong way... To be quite frank, you are throwing my inner Chi out of its harmonious balance with nature." -- Tex Bigballs
[ Parent ]

Doing it is the most important part (none / 0) (#145)
by mairsil on Sat May 10, 2003 at 08:05:46 AM EST

Something like this has needed to be done for a very long time. The amount of administrator work saved by a really rational directory tree could be enormous. The trouble is, it takes a while to be sure that what you've built is actually an improvement overall, and not just a speedup of today's squeaky wheel.

It probably can be done better if you put enough time in it. The important thing about GoboLinux, I think, it that it is actually done. Even if it's not the best solution, it is a massive improvement, and it is available.

I'll take a working moderate improvement over a hypothetical major improvement any day.

[ Parent ]
Alright! (2.40 / 10) (#14)
by carbon on Fri May 09, 2003 at 04:33:21 AM EST

I like it! It's about time somebody reversed the annoying screwups perpetuated by RedHat on the filesystem hierarchy. If anything, this is more like the way things used to be done, although only medium and large things got their own directories, rather than everything.

Really, though, this seems like generally the first step along a nifty path of UNIX reform. Perhaps next people can start seperating the POSIX shiznit away from C. Then, and many oysters later, the world will be our oyster! Now imagine me laughing like Professor Chaos.


Wasn't Dr. Claus the bad guy on Inspector Gadget? - dirvish
So... (4.00 / 1) (#15)
by tang gnat on Fri May 09, 2003 at 04:38:31 AM EST

How do you construct a menu for your window manager? In order to get programs interacting at all, I think it is unavoidable that programs will creep out of their homes.

What is the equivalent of the /var directory? It is not unreasonable, even today, for a workstation to only have read access to /usr/share (or /Programs in your case). What is the equivalent of /usr/local?

If you can get this switchover to work, GoboLinux seems superior for an isolated desktop system.

Answers (5.00 / 2) (#19)
by LodeRunner on Fri May 09, 2003 at 05:51:03 AM EST

How do you construct a menu for your window manager? In order to get programs interacting at all, I think it is unavoidable that programs will creep out of their homes.

The menu for my window manager is currently at ~/.icewm/menu. :-) But I do understand your question. There are many programs that interact to each other. For example, all KDE-based apps share a common icon repository. This is implemented using the /System/Links/Shared. This directory holds symlinks to the contents of each program's shared files. There, they appear "grouped" to the applications, but they're actually stored separately. It sounds funny when written, but it works.

What is the equivalent of the /var directory?

/System/Variable. /var is a symlink to it, and it works as usual. I very rarely find the need to fiddle with it, so it just sits there, doing its thing, holding logs, locks, spools and other somewhat "volatile" data.

It is not unreasonable, even today, for a workstation to only have read access to /usr/share (or /Programs in your case). What is the equivalent of /usr/local?

There is no /usr/local (actually, /usr/local/lib points to the same place as do /usr/lib and /lib, that is, /System/Links/Libraries). All programs get installed as subdirectories to /Programs, there are no different "domains" where programs are installed. This is something that can be done in the future. However, while I can see the gains of having programs installed physically at different locations (locally, over the network), I can't see gains of having them logically in the system at different locations. Far from that, I see disadvantages. I'd love to see a way to have programs installed in different physical places but have them all show up under /Programs. We haven't researched much into this, but it should be possible.


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

I think gnu/hurd found a way to do it. (5.00 / 1) (#76)
by tang gnat on Fri May 09, 2003 at 06:31:09 PM EST

I recall they made some sort of virtual filesystem thing which is creates a merger of other filesystems in the same spot. It could even give users the power to change the look of the system so they could pretend to overwrite global files (even though the changes are really only kept in the user's account). It might not be that hard to create a sort of MergeFS in the Linux kernel, which just brings together several directories into one.

[ Parent ]
plan9 (5.00 / 2) (#97)
by sholden on Fri May 09, 2003 at 10:07:20 PM EST

Did it wonderfully.

No need for $PATH when you just mounted all the directories containing executables on /bin at the same time (especially useful in heterogeneous environments with netowork filesystems - so you would mount the appropriate architectures binaries).

And of course those filesytem namespaces are per process (inherited by children).

Alexander Viro did some stuff to do similar things under Linux a few years ago, but I haven't followed it.

--
The world's dullest web page


[ Parent ]
Check out overlay filesystems (5.00 / 1) (#89)
by Alhazred on Fri May 09, 2003 at 08:11:19 PM EST

There are several implementations, they would certainly do what you want as far as /Programs go (you could obviously manage it with another layer of symlinks as well, but that gets a bit ugly).

In fact, I think you could do a lot of stuff with overlay.
That is not dead which may eternal lie And with strange aeons death itself may die.
[ Parent ]

What about maintenance (4.00 / 1) (#193)
by fluxrad on Sat May 10, 2003 at 05:04:52 PM EST

What about slicing? Assuming your system takes a dump, and you have to get the system back with basic utils (i.e. fsck, mount, and the other "essential" system binaries) in order to get the system back to a fully booted state, how is the filesystem layed out to accomodate this?

I'm just wondering if keeping /Programs and /System/Links/Executables off the root partition would make things ten times more difficult for this type of setup to work.

As an example, my boxen at home are all configured with / and /usr being on two different slices, giving me access to /bin as long as I can get /dev/hda1 to boot. Mandating the placement of every system binary on /dev/hda1 seems a bit restrictive to me, not to mention the troubles that might be caused if you went the other way and had different subdirectories of /Programs sitting on different slices.

Do you have recommended slicing examples? Or is the whole fs just thrown on one slice?

--
"It is seldom liberty of any kind that is lost all at once."
-David Hume
[ Parent ]
Slicing (5.00 / 1) (#226)
by LodeRunner on Sun May 11, 2003 at 05:12:56 AM EST

Do you have recommended slicing examples? Or is the whole fs just thrown on one slice?

Yes, the usual practice among GoboLinux users is to throw the whole fs in one slice. I obviously don't have any figures, but I'd guess that this is the most common setup on systems that do not have remotely-installed programs.

The discussions about overlaying filesystems could be a solution to the problems you pointed out -- problems I was aware of, and a reason why I would not recommend GoboLinux to any Linux setup.

What I am against, however, is making the physical distribution of files explicit in subdirectories as in /usr vs. /usr/local or /Network vs. /Local. I believe the file system is a logical abstraction: the whole system appears abstracted as a single tree, regardless of how many disks, partitions or network hosts constitute it. For this same reason, I think that programs should appear under one single directory, regardless of in which disk, partition or network host it is physically located.

This is definitely something that should be investigated in greater depth in the future. I'd add it to the To-do list of our webpage right now, but I can't access the server because it is under heavy slashdotting.


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

You (3.00 / 5) (#18)
by xah on Fri May 09, 2003 at 05:30:36 AM EST

You, sir, are a genius. So what is the license?

GPL, of course :) (5.00 / 3) (#24)
by LodeRunner on Fri May 09, 2003 at 06:22:59 AM EST

All GoboLinux-related code included in the distribution is released under the GPL. The applications included are subject to their own licenses, obviously.


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

Attention! Important Note! (3.42 / 7) (#26)
by RobotSlave on Fri May 09, 2003 at 06:40:28 AM EST

Please be aware that LodeRunner is not Lode Runner.

But Mommie, who's medham?  
   /       
  /    o  -- Hush, Dear.
 o    (|)
/ \   / \
 |\    |


OK, thanks (5.00 / 1) (#34)
by curien on Fri May 09, 2003 at 08:29:11 AM EST

But the author doesn't appear to be impersonating anyone. His comment history only shows about 30 comments, but they date back to June of last year.

--
Murder your babies. -- R Mutt
[ Parent ]
You're welcome! (5.00 / 1) (#41)
by RobotSlave on Fri May 09, 2003 at 10:44:30 AM EST

Um, I don't think I said anyone was trying to impersonate anyone else, did I? Seems that would be pretty silly, here.

I'm just trying to draw attention to what might quite easily be a source of confusion. That's all, nothing more, no sinister accusations. OK?

[ Parent ]

Sounds good (5.00 / 2) (#43)
by curien on Fri May 09, 2003 at 11:20:56 AM EST

I didn't mean to imply that you meant to imply that the author was impersonating someone. I just wanted to clarify by adding information that a casual reader might not have bothered to look up, and without which he might have jumped to conclusions.

I really did mean the "thanks". Until you pointed it out, I didn't notice that the author was a different person.

--
Murder your babies. -- R Mutt
[ Parent ]

Cripes. (5.00 / 2) (#55)
by tkatchev on Fri May 09, 2003 at 04:23:05 PM EST

What's wrong with the poor kid's leg?

BTW, the correct way of drawing toilet stick figures looks something like:

  O   O
 /_\ |_|
  |   |

   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

Thanks for sharing (none / 0) (#87)
by Big Sexxy Joe on Fri May 09, 2003 at 07:59:53 PM EST

I was starting to believe that you weren't him, but you gave your game away. Oh well.

I'm like Jesus, only better.
Democracy Now! - your daily, uncensored, corporate-free grassroots news hour
[ Parent ]
It's hard, isn't it? (none / 0) (#158)
by RobotSlave on Sat May 10, 2003 at 12:13:44 PM EST

Knowing that there's someone out there who's smarter than you is a bit of a blow, but even then you might still convince yourself that you're brighter than everyone else with only a slight convulsion of self-deception.

But knowing there are two people... well, that's a lot harder wriggle out of. And it inevitably leads to that terrifying speculation: what if there are more? What if there are many? What if they're all around you?

No, best not to think about it. The only safe thing to do when you encounter two people who routinely say or quote things you don't understand is to assume that they're the same person.

You could read more books, you know. Or even subscribe to some of those smart-people magazines that run long articles about books. Be careful, though. Real books (as opposed to, say, science fiction) are very dangerous for those who root their self-regard in their imagined rational intellect.

[ Parent ]

Yes, I think you've hit the nail on the head (none / 0) (#167)
by Big Sexxy Joe on Sat May 10, 2003 at 01:44:53 PM EST

I spend many sleepless nights worrying that there is some more well read than I am. To think there are two such people, quite frankly, disturbs the hell out of me.

Oh well, perhaps I'll follow your advice and read magazines about books. I don't know if I have time though. I do actually spend most of my time reading science fiction. This was a very keen observation on your part. In fact, it was so keen you should have posted it as medham. I suppose if you post denials under both accounts it would give your game away too much though.

I'm like Jesus, only better.
Democracy Now! - your daily, uncensored, corporate-free grassroots news hour
[ Parent ]

do you think it's coincidental? (none / 0) (#95)
by Lode Runner on Fri May 09, 2003 at 09:54:29 PM EST

If you know a lot about Dungeons and Dragons weapons classes and Middle Eastern languages then skip the following paragraph and try to figure it out for yourself.

Hisham is Arabic for crushing; medham means piercing or keen. The former uses my handle, but always signs off with the claim that he isn't me; the latter does the exact opposite.

I have only one account here, I swear.

Claude Lévi-Strauss would laugh with me and at the lot of you.



[ Parent ]

Of course not. (none / 0) (#162)
by RobotSlave on Sat May 10, 2003 at 12:41:52 PM EST

You know perfectly well that coincidence can only exist in the realm of perception.

You may be laughing along with Claude at Ferdinand's joke, but the younger folks at the table seem to find him rather boorish. In fact, I think Michel's gone and killed himself out of sheer disgust, though they're still pouring him drinks.

[ Parent ]

RIP Michel (none / 0) (#241)
by LookingGlass on Mon May 12, 2003 at 12:41:03 AM EST

... but he died as a consequence of aids not suicide. His lover was hit by a laundry car, which has a certain irony if you disregard the fact that it was not a Citroen. Claude had a complex about Oedipus but not in the Freudian way. One Jacques is more reflective than an Other even if he is less true.

You are not the only person here who reads these books though you seem to think so.

[ Parent ]

Call it what you will. (none / 0) (#244)
by RobotSlave on Mon May 12, 2003 at 11:53:40 AM EST

You're right, I was thinking of Guy, though Michel at times seemed to regard his illness as something approaching an act of will, even after the fact. I'm sure he wouldn't want to be pinned down on it one way or the other, at any rate.

Anyway.

Why on earth would you suggest that I don't think anyone else has read those funny little books by the Frenchmen? I wouldn't have responded to Mr. Lode Runner as I did if I hadn't thought he'd done his homework, would I?

So welcome aboard, sexy. Though you, in your bitchy little snit, might find it hard to believe, I (for one) actually enjoy having people around who can understand the occasional reference to an easily recognized theorist or two from outside the narrow confines of computers-fiddling and astrophysics.

[ Parent ]

Easy tiger (none / 0) (#248)
by LookingGlass on Mon May 12, 2003 at 04:02:30 PM EST

You assume too much. But first:

Why on earth would you suggest that I don't think anyone else has read those funny little books by the Frenchmen?
Well, for this reason:
You could read more books, you know. Or even subscribe to some of those smart-people magazines that run long articles about books. Be careful, though. Real books (as opposed to, say, science fiction) are very dangerous for those who root their self-regard in their imagined rational intellect.
Attacking the literary shortcomings of a web forum with a scientific tendency is a bit like confronting a poetry circle with their failure to perform calculus. It's cheap and not exactly fair. As for bitchy little snits:
Knowing that there's someone out there who's smarter than you is a bit of a blow, but even then you might still convince yourself that you're brighter than everyone else with only a slight convulsion of self-deception. No, best not to think about it. The only safe thing to do when you encounter two people who routinely say or quote things you don't understand is to assume that they're the same person
I do believe you when you say you enjoy having people around who can spot the occasional reference but sometimes you manage to give the exact opposite impression. I enjoy your posts on k5 but bashing people over the head with the width of your reading causes me to wince.

As for my uid ... well I gather you are no stranger to multiple accounts.

[ Parent ]

Coincidences (none / 0) (#175)
by LodeRunner on Sat May 10, 2003 at 02:16:49 PM EST

If you know a lot about Dungeons and Dragons weapons classes and Middle Eastern languages then skip the following paragraph and try to figure it out for yourself.

Hisham is Arabic for crushing; medham means piercing or keen. The former uses my handle, but always signs off with the claim that he isn't me; the latter does the exact opposite.

Well, I didn't "get it", if there was anything to get, but I'm okay with that. :-)

As far as my father told me, Hisham is arabic for "generous". A quick Google search confirmed this.

I have only one account here, I swear.

Me too. This whole nick thing was just a big coincidence. Since both Lode Runner and I have been using our nicks for a long time in other places, I don't see the need to change. The thread linked in my sig explains it all.

Claude Lévi-Strauss would laugh with me and at the lot of you.

I didn't get this too, so either I'm ignorant or I just have too many sleeping hours to catch this week. :)


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

on crushing generosity (4.00 / 1) (#180)
by Lode Runner on Sat May 10, 2003 at 02:40:14 PM EST

In classical Arabic, Hisham literally meant crushing, and yes, generosity is one of the word's connotations.

Here's how: when people in caravans wanted to be generous, they would crush a big piece of flat-bread and give out the pieces; the more pieces a man crushed, the more generous he was considered. Hence the act of crushing was a vital part of magnanimity.

At this point the gentle computer programming sci-fi reader should ask himself why recursive incongruence is never employed as a device in his favorite "literature." Structural anthropology is a science too, you know. . .

[ Parent ]

I wasn't aware of that... thanks! :-) [nt] (none / 0) (#223)
by LodeRunner on Sun May 11, 2003 at 04:02:55 AM EST


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

you sir, are a wise man (none / 0) (#250)
by werner on Mon May 12, 2003 at 04:11:42 PM EST

would you like to join my pub quiz team?

[ Parent ]
are you (none / 0) (#257)
by Lode Runner on Mon May 12, 2003 at 11:44:37 PM EST

suggesting that ancient Arabic customs are trivial?

I'd be eating well at Applebees if they didn't put so many stupid Hollywood and sports questions into their game.

[ Parent ]

No, I wasn't suggesting that, (none / 0) (#260)
by werner on Tue May 13, 2003 at 09:18:24 AM EST

but if you're asking, yes, I think most ancient customs are trivial. The same goes for many modern customs.

I don't know Applebees.



[ Parent ]
Litestep Guy? (none / 0) (#126)
by ZeuS572 on Sat May 10, 2003 at 04:23:23 AM EST

So is this the Litestep Lode Runner?

[ Parent ]
No, that was Lone Runner... (none / 0) (#166)
by LodeRunner on Sat May 10, 2003 at 01:37:27 PM EST

...if my memory serves me well. I used to use Windows and LiteStep back in 1998.


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

Everyone agrees it should change, but not what to. (4.00 / 3) (#27)
by Fyndalf on Fri May 09, 2003 at 06:49:48 AM EST

This is more or less what I do when Debian doesn't have the package I want and I need to install from source.  Many unixy people grow their own trees like this at various positions within the filesystem.

In my way of doing things, I don't Use A Lot Of Uppercase Letters because im a lazy typist.  It would seem /Programs would end up being typed enough that the milliseconds saved by not having to shift would add up.

Other people might use nospaceswhatsoever or crypt abbr, ad nauseum.  

So while I think there has been support for changing the file system standard to something with currently relevant reasoning behind it, the stumbling block has been that no one can agree on what to change it to.  

Case-insensitive tab-completion (none / 0) (#30)
by LodeRunner on Fri May 09, 2003 at 07:46:34 AM EST

In GoboLinux, we agreed on PrettyNames just because of case-insensitive tab-completion. Slash, P, Tab, and you're there. zsh features it (by default in GoboLinux), I think bash has it too. Nice to look at, and quick to type.


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

Interesting (5.00 / 1) (#31)
by phraggle on Fri May 09, 2003 at 07:57:07 AM EST

I find this fascinating. We have been running a similar type of system for CSLib at the University here. We have a student-run NFS server which mounts at /usr/cslib in which we can install programs. Interestingly, we settled on roughly the same model as you - we have programs installed into /usr/cslib/{category}/{programname} and there are then symlinks in /usr/cslib/bin to run the program. It can be messy at times, though. Some of the programs depend on libraries, which requires setting up the environment so it can find the libraries (we only have symlinks for bin/, not lib/). I'm interested in this project as its so similar to what we're doing: would it be possible to adapt the package manager to work ontop of an existing linux distribution? (the lab machines here run redhat)

Yes, it would. (5.00 / 1) (#35)
by LodeRunner on Fri May 09, 2003 at 08:34:42 AM EST

We also have a "hosted" version called "Rootless GoboLinux" that can run using any arbitrary directory as a base (for example, /usr/cslib/{Programs,System,...}). You can find it here. It comes pre-configured to work based on $HOME, so some manual configuration may be required. The Scripts package was recently updated for this week's release, so it may also be necessary to sync Rootless back with the main branch. We'll be doing this soon (a friend is working on it, he wants to make it run on Mac OS X, just for the screenshot's sake ;-) )

It can be messy at times, though. Some of the programs depend on libraries, which requires setting up the environment so it can find the libraries (we only have symlinks for bin/, not lib/).

I seriously recommend you to symlink libraries and headers too. Our LD_LIBRARY_PATH and ld.so.conf contain only one entry, it's very convenient. C_INCLUDE_PATH and CPLUS_INCLUDE_PATH take care of the headers, though our legacy tree also plays an important role -- many Makefiles still assume /usr/include blindly. I'd really like program authors to become more careful about these issues, as they only hurt the program's portability (think about environments such as Cygwin). Symlinking "share" directories is a bit trickier, but can be done, Check out how we do it in GoboLinux for some insights. Or just use our Rootless package, as we already took care of the harder stuff (recursive resolution of symlink conflicts, etc.)


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

packages (none / 0) (#49)
by phraggle on Fri May 09, 2003 at 03:47:46 PM EST

How many packages are supported by the distro? Or more specifically, how easy is it to adapt packages to use the GoboLinux directory structure? :)

[ Parent ]
packages (5.00 / 1) (#62)
by LodeRunner on Fri May 09, 2003 at 04:53:43 PM EST

How many packages are supported by the distro?

You can find our packages in gobolinux.org/packages. They are divided in 005- and 006- series (compiled for GCC 2 and GCC 3) but, thanks to the GoboLinux structure, if you want to use older packages that need old GCC libraries, it's just a matter of keeping /Programs/GCC/2.95.3 around (even with GCC/3.x still as Current). We've got about 500 packages compiled over the course of this year-and-a-half. It's not that much I know, but that's what we needed (my personal /Programs directory contains about 250 entries, and no, it's not a mess at all).

Or more specifically, how easy is it to adapt packages to use the GoboLinux directory structure? :)

Most of the time (most, really), it's pretty easy. Autotool-based apps are trivial. The rest usually just need to modify one or two variable in the Makefiles (INSTDIR, PREFIX, etc) and you're good to go (the scripts will warn you in those cases and even suggest -- nothing automagical here, folks -- the changes).

A very few apps get really tricky. Imakefile-based apps are a major pain because they insist to get installed inside the XFree86 directory. Those are getting rarer each day, fortunately. There's discussion on xwin.org to drop imake even for XFree86.

Having said that, it's important to point out that there was never an application that we failed to get working on GoboLinux.


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

packages (none / 0) (#63)
by evandrocd on Fri May 09, 2003 at 04:55:39 PM EST

You can see that at Here
Evandro
Gobolinux User #0b1100
[ Parent ]
Hrm. (5.00 / 5) (#33)
by regeya on Fri May 09, 2003 at 08:21:09 AM EST

Call me stupid, but was there any particular reason you didn't use GNU Stow or one of the other Encap variants? I suppose I'm having trouble understanding the advantage having a version directory would give you.

[ yokelpunk | kuro5hin diary ]

I checked those out. (5.00 / 4) (#37)
by LodeRunner on Fri May 09, 2003 at 08:49:05 AM EST

This is a fair question, and actually a omission from my part in not mentioning them in the article.

I checked both GNU Stow and Encap (and referenced them and CMU Depot in the article for WSL2002), but I recall that they both falled short of supplying everything we needed and weren't suitable to build an entire system based solely on their kind of packages, They are designed to live inside /usr/local and complement an existing distribution. Also, IIRC, with Stow one has to pass one prefix to make and another to make install. My comments may, of course, be outdated.

Version directories are more of a design decision. We could have versions embedded in the directory name, like in Encap (/usr/local/encap/sed-2.0) and achieve the same functionality. But we believe having a program directory containing a subdirectory for each version, a version-independent subdirectory for settings, and a symlink indicating the current version is a more organized approach.


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

Bravo. (4.75 / 4) (#38)
by i on Fri May 09, 2003 at 09:18:55 AM EST

This is exactly the directory structure I wanted for my own distro, so I'm inclined to give this a try.

But does going the databaseless way mean that I must track package dependencies manually? Or do you have an equivalent of apt-get?

and we have a contradicton according to our assumptions and the factor theorem

Dependencies (none / 0) (#42)
by LodeRunner on Fri May 09, 2003 at 10:48:31 AM EST

I was answering these questions as you typed. :) Please check out this other thread.

---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

A few thoughts on this. (4.85 / 7) (#44)
by sophacles on Fri May 09, 2003 at 11:31:13 AM EST

I think that in a server environment, the traditional Unix directory structure would be better than this. The ability to mount different parts of an app as read only is a well thought out and tested security feature.  The traditional structure also allows for more granularity in terms of administration and access.  You, however don't make any claims about this being a server environment, instead this distro is focused on the desktop environment so that isn't a criticism.

In fact I like this structure for a one- or few-user  machine.  The simpleness of it would make more sense for a lot of people.  The ability to keep old versions side-by-side with new versions is a great feature.  I wish more operating systems allowed this with ease out of the box.

I'm glad to see people doing experiments like this.  Even if yours doesn't end up taking off, it will hopefully provide good data or ideas to other people and yourself to build on in the future. Like you've mentioned before, this is one of the beuties of free software, there can be experiments like this.

A couple of questions:

Do you yet have a graphical application installer? It would seem that wouldn't be too hard in this setup.

Have you considered a startup manager for this project, since your start-up scripts have been simplified, it woudn't seem as bad to write, and could be another one of those good experiments towards usablility.

Over-all I think this is fantastic work, and much needed too.  Thanks, keep it up.

old and dumb (3.50 / 2) (#46)
by xah on Fri May 09, 2003 at 03:37:30 PM EST

I'm too long in the tooth and thick in the skull to learn how to use Unix, but I think I could learn this. The things I would need to transition away from Windows to Gobo would be (1) a Windows emulator, like Wine, for certain apps, and (2) a PPPoE stack. I'm going to seriously think about this.

What is wrong with PPPoE under linux? [nt] (none / 0) (#59)
by nusuth on Fri May 09, 2003 at 04:29:09 PM EST



[ Parent ]
It's in the kernel? Thanks. [n/t] (none / 0) (#79)
by xah on Fri May 09, 2003 at 07:03:28 PM EST



[ Parent ]
Huh? Thanks. [n/t] (none / 0) (#146)
by zerblat on Sat May 10, 2003 at 08:05:49 AM EST



[ Parent ]
Yes, it is in the kernel (none / 0) (#156)
by nusuth on Sat May 10, 2003 at 11:28:26 AM EST

And what is wrong with PPPoE being in the kernel?

There used to be a userland driver too but, IIRC, it was only for Alcatel Speedtouch and was not very fast.

I can tell you with authority that PPPoE in linux has no shortcomings whatsoever. I switched completely a few months ago after dual booting with 2k (later XP) for ages. I haven't encountered any difference in function or speed while dual booting. My modem has been running flawlessly for the last few months on linux exclusively.

[ Parent ]

yes, it should be in the kernel (none / 0) (#199)
by xah on Sat May 10, 2003 at 06:28:14 PM EST

I agree that PPPoE should be in the kernel. I just didn't realize that it was. I recently searched Google to see if Linux had PPPoE support, and only found references to the userland app that you mentioned. Thus, I stand corrected, and am quite happy about that.

[ Parent ]
good (none / 0) (#249)
by werner on Mon May 12, 2003 at 04:04:15 PM EST

this means it will run faster. there is nothing wrong with something being in the kernel, as long as it is stable.

[ Parent ]
hmmmm? (none / 0) (#60)
by PigleT on Fri May 09, 2003 at 04:38:34 PM EST

OK, you don't make sense. All that's different from any other *nix is the filesystem layout, and that makes it learnable compared to a regular linux distribution?

Some other thoughts while I'm passing. It's obviously early days for Gobo, because I've been tempted by such things as Plan9 (but it wasn't open-source, unfortunately) precisely because of the change from /usr. However, Gobo seems more than a bit weak here: it's one thing to stick all your executables in a differently named directory, it's quite another to not have an obvious way of maintaining them by packages when they're there. It's also really daft to go around having symlinks from /usr/bin -> /Programs/Executables/ just for the sake of it. It's the searching-for and replacement of legacy(!) directory names that determines the amount of work put into the project, and it really should be increased a bit - no symlinks at all, pure new layout or not at all.

For those of us who like a 1-directory-per-application approach, there's nothing wrong with _stow_ - using it is simply a matter of
./configure --prefix=/usr/local/stow/packagename
cd /usr/local/stow
stow packagename
and hey presto, the executables are symlinked into /usr/local/{,s}bin/ ready to be used in the PATH.

Finally, whoever made that glib comment about using the filesystem to organize things should note that that is exactly what happens in the existing FHS. There *is* organization: /, /home, /usr, /bin, /sbin, /var, /usr/local, and /opt, so this is merely a *different* form of it, complete with novelty value (this is a good thing IMO) but not completely worked-through just yet.

~Tim -- We stood in the moonlight and the river flowed
[ Parent ]

symlinks (none / 0) (#80)
by xah on Fri May 09, 2003 at 07:05:23 PM EST

I think it would be ideal for Gobo to have the symlinks, and a preference to disable them/get rid of them. That way there would be a clear transition path.

[ Parent ]
So (4.00 / 1) (#48)
by Judas Iscariot on Fri May 09, 2003 at 03:46:17 PM EST

Installing apps yourself becomes a nightmare. the classic ./configure; make; make install won't work anymore.

it still works... (none / 0) (#54)
by detsch on Fri May 09, 2003 at 04:19:57 PM EST

GoboLinux has scripts that handle configure; make; make install; automatically, but you still can do the job manually. Just use the right "--prefix" when running configure.

[ Parent ]
Exactly the opposite. (4.66 / 3) (#58)
by LodeRunner on Fri May 09, 2003 at 04:29:07 PM EST

I'd say that GoboLinux is oriented towards the compile-it-yourself case, and not the opposite. The classic configure && make && make --install is the easiest case. It is managed gracefully by the CompileProgram wrapper script. Installing apps yourself in GoboLinux is not harder than it would be installing apps inside your $HOME, for example. In fact, it's easier because the wrapper scripts pass the correct options to configure for you. Obviously, installing pre-compiled binaries (InstallPackage) will always be easier.

---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

Yeah... (3.00 / 1) (#150)
by Karellen on Sat May 10, 2003 at 08:55:26 AM EST

./configure --prefix=/Programs/foo/1.0; make; make install

is really difficult.


[ Parent ]

If (4.00 / 2) (#154)
by Judas Iscariot on Sat May 10, 2003 at 10:14:51 AM EST

you think that'll work smoothly with all apps, you're living in a dreamworld.

[ Parent ]
-1, no assessment of competition (3.25 / 4) (#50)
by daedal on Fri May 09, 2003 at 04:05:10 PM EST

As other comments have mentionaed, what you're doing isn't unique. Many other people are doing and have done similar things that are united by more or less the same philosophies. Tools such as GNU Stow or Encap can be manipulated to produce some of the same functionality. If you look up the linux from scratch hints page [under "package management"] there are many other tools that do some of the same, and some different things. [The most amusing to myself personally was one that had created different users for each package. In a [currently moribund] installation of my own I was mixing this with a symlinked approach similar to the one you have outlined.] Likewise, googling for some of the key words find others.

As someone who has started a vaguely similar system based on some of the same ideas and the ideas in some of the programs mentioned in the page linked to above, I want to know in what ways your system is better, and in what ways it is worse. While you are right that it is worthwhile to raise awareness, you are doing so in a self-interested way without analysis of the competition.

If you rewrote giving this analysis then it would be well worth a +1. A tiny nitpick perhaps, but the names of your directories are deeply annoying to me. Capitals in directory names are irritating. I'm not sure if anyone else feels the same. :-)

Don't oversimplify (4.20 / 5) (#51)
by p3d0 on Fri May 09, 2003 at 04:08:53 PM EST

I can only recommend that you understand the current hierarchy before you try to design a better one. Take a look at the Filesystem Hierarchy Standard. They have a good rationale section that you may want to consider.
--
Patrick Doyle
My comments do not reflect the opinions of my employer.
no (none / 0) (#57)
by momocrome on Fri May 09, 2003 at 04:28:09 PM EST

'They' do not have a 'good rationale section'. This is FHS, after all.

"Give a wide berth to all that foam and spray." - - Lucian, The Way to Write History
[ Parent ]
You're right (none / 0) (#184)
by p3d0 on Sat May 10, 2003 at 03:27:38 PM EST

They don't have one good rationale section. They have a rationale attached to each section. That's even better. Even if you disagree with their decisions, at least you can make sure you don't overlook something they have considered.
--
Patrick Doyle
My comments do not reflect the opinions of my employer.
[ Parent ]
Those who fail to understand unix... (4.00 / 4) (#66)
by NoMoreNicksLeft on Fri May 09, 2003 at 05:35:16 PM EST

Are doomed to reimplement it.

Poorly.

(Some please tell me whom I should credit for that?)

--
Do not look directly into laser with remaining good eye.
[ Parent ]

Bloody hell (none / 0) (#270)
by ksandstr on Tue May 13, 2003 at 10:48:17 PM EST

If I could only give one "5" rating per article for a comment in said article, this would be it.

Attributed or not, this statement stands on its own.  


Fin.
[ Parent ]

Henry Spencer (none / 0) (#272)
by beergut on Wed May 14, 2003 at 07:19:12 PM EST

I believe.

i don't see any nanorobots or jet engines or laser holography or orbiting death satellites.
i just see some orangutan throwing code-feces at a computer screen.

-- indubitable
[ Parent ]

Been there, done that. (4.33 / 3) (#73)
by LodeRunner on Fri May 09, 2003 at 06:24:45 PM EST

We read it, and we understood it.

I don't intend to diss FHS here, but having an arbitrary list of which executables should go inside /bin and which ones should go inside /sbin is not "good rationale", IMO.

I'm aware of the set of assumptions on which FHS is based. GoboLinux is simply based on a different set of assumptions. This poster "got it". :)


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

All I can say.... (3.80 / 5) (#52)
by lb008d on Fri May 09, 2003 at 04:13:30 PM EST

It sure beats the hell out of c:\Program Files and c:\Documents and Settings.

Really? (none / 0) (#77)
by ok on Fri May 09, 2003 at 06:36:02 PM EST

Remove the cee colon and reverse the slash and it's the same thing.

[ Parent ]
Maybe, maybe not (5.00 / 1) (#92)
by hardburn on Fri May 09, 2003 at 08:29:47 PM EST

While 99% of a Win32 program's files go into Program Files, that other 1% is what tends to bite you. That's why you need a real uninstaller as opposed to just nukeing the subdir in Program Files. In particular, the registry makes this whole process a pain.

GoboLinux appears to actually put everything in the specified directory, which is the way MS developers should have done it since Win95.


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


[ Parent ]
heh... (none / 0) (#165)
by pb on Sat May 10, 2003 at 01:36:22 PM EST

Even that would have been a vast improvement. Drive letters are a horrible idea because they aren't fixed, but rather based on the way your MS OS perceives your hardware configuration. As for the reversed slash, that has also bugged people for a long time. Why couldn't they have done it like everyone else? Well I guess that would have been too easy...

...and don't even get me started on all the spaces in the directory names... Sure, you can do it, but it's damn annoying (generally less so on Linux with a good shell, but still...).
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]

Spaces (none / 0) (#234)
by lb008d on Sun May 11, 2003 at 06:11:39 PM EST

I hate spaces in pathnames. Even though they are allowed in Unix, and the shells can deal with them in tab completion, they are not used.

Only recently could cmd.exe deal with spaces. But nobody in their right mind would call that a full-featured command interpreter after using those that come with Unix.

Drive letters are inane as well.

[ Parent ]

kiss (4.60 / 5) (#56)
by truckaxle on Fri May 09, 2003 at 04:23:26 PM EST

I think if you follow this approach through it will prove (again) the point that with a good foundational design new features come for cheap. Or in this case eliminate the need for awkward support tools such as rpm (as nice as it sometimes seems) and of course the multi cross-referenced windows registery mess and not to mention uninstall programs that don't fully work or clean up after themselves.

There is something simple and attractive to "package" all the programs, data, information, dependencies, etc that a applicaton needs from a single directory node on down and than use symlinks to organize the information the other way by function (ie man/document pages, libs, configurations, etc.). What could be cleaner than the "rm -rf *" for removing an application? or "ls -lrt" to see what is installed or "more .dependencies" to view dependencies. Moving apps around or backing applications up is simplified.

I like it where do I sign up.



Some like it hot Mozilla Users get an automatic %5 Discount . . .
dependancy management? (none / 0) (#69)
by gps on Fri May 09, 2003 at 06:00:33 PM EST

how are package dependancies in gobolinux handled?

For instance if I deinstall XFree86 using rm -rf suddenly vim will stop working if it happened to have been configured and built with any GUI (X11) support.

this is the one job that a package management tool is useful for.  it's why i like freebsd (ports) and gentoo (portage).


[ Parent ]

That's not all (5.00 / 2) (#74)
by Miniluv on Fri May 09, 2003 at 06:25:02 PM EST

File ownership by package with this scheme isn't as fluid as it is with, say, rpm -qf.

I don't have a conceptual problem with people laying their file system out any which way they want, but claiming it obviates the need for a package management system is bogus. Dependency trees, file/package relationship maintenance, and other things along those lines are totally not addressed by this scheme.

This really sounds like a power user distro to me, rather than a newcomer friendly distro. Power users can parse the output of configure if dependencies fail, whereas newcomes need the ability to just download a package and install it.

What would make this a really swank distro would be making apt or rpm, or portage I suppose, aware of these file system mappings and let the user just download rpms, debs, or portage ebuilds and do the translations in software. At the very least you could build a utility which would take an rpm in one end and spit out a GoboLinux compatible rpm on the other, possibly requiring a src rpm instead of a binary one.

"Too much wasabi and you'll be crying like you did at the last ten minutes of The Terminator" - Alton Brown
[ Parent ]

WRONG (4.00 / 2) (#205)
by dh003i on Sat May 10, 2003 at 08:15:55 PM EST

Your idea is flawed and ignores the reason why we have shared libraries in the first place. Shared libraries are still beneficial, for several reasons:
  1. Hard-drive consumption. Some libraries are huge.
  2. RAM consumption. See above.
  3. Load time. See above.
  4. Convenience. Yes, convenience. If you want to update an insecure, poorly performing, or instable library that many programs are using, with shared libs you only have to do this once. If every prog has it's own version of the library, you have to do it many times over, and have to determine which progs use that library.
  5. Consistent behavior. One major advantage of shared libraries is shared behavior.
  6. Compile-options: who knows what poorly performing, unstable, insecure options each different library was compiled with?
  7. Bandwidth. I don't want to download huge libraries over and over and over and over again because engineers were too lazy to solve the problem the right way.
Now, if you are arguing that we should make shared libraries more simple, putting them all in one place (with subdirectories), I'll agree there. But if you're going where I think you're going -- take the "simple" solution that OSX and WinXP have taken -- then you're wrong.

Donald Rumpsfeld likes to say that for every human problem, there is a solution that is obvious, clear, and wrong. Putting everything in one folder is certainly the easy solution; however, it is just as certainly the wrong solution, for the reasons noted above (namely, that it creates 7 more problems).

Social Security is a pyramid scam.
[ Parent ]

Versioning (none / 0) (#216)
by dennis on Sat May 10, 2003 at 11:30:32 PM EST

I don't see why his approach necessarily has to prohibit shared libraries. You could put your big shared libraries in the same sort of directory structures as your applications, with subdirectories for versions again. Then you can install new versions alongside the old ones, but you can also apply a patch to an existing version.

[ Parent ]
Ah, I c (none / 0) (#217)
by dh003i on Sat May 10, 2003 at 11:56:02 PM EST

Interesting. Let me just make sure I get your idea clearly:

What your proposing is that there be a /lib that mimics /apps exactly, so there would be /lib/KDE/glib and /lib/wmaker/glib, but both of those glib's would be exactly the same (e.g., links) or the like?

Social Security is a pyramid scam.
[ Parent ]

Any plans for automated installation? (5.00 / 1) (#61)
by Xiphas on Fri May 09, 2003 at 04:39:34 PM EST

I'd have to admit that this project looks very interesting - I'm downloading the ISO right now.

Are there any plans to automate the compiling process similar to Gentoo's portage or BSD's ports? Or do you plan on sticking to the manual ./configure && make install?



technically (none / 0) (#67)
by RJNFC on Fri May 09, 2003 at 05:41:30 PM EST

You CAN install portage on a non-gentoo system, you know. People have done it. Just a thought - I was actually sort of thinking of trying this distro with Gentoo's portage and seeing how that works.

[ Parent ]
You can..really? (none / 0) (#83)
by tweek on Fri May 09, 2003 at 07:27:33 PM EST

After your comment, I decided to go searching for just that information and couldn't find it.

If you've got some links, I'll suck em up but I would LOVE to give it a shot.

By the way, for anyone who wonders "why?", because johncompanies.com doesn't have gentoo virtualized yet ;)
Some people call me crazy but I prefer to think of myself as freelance lunatic.
[ Parent ]

righto (4.00 / 1) (#233)
by RJNFC on Sun May 11, 2003 at 05:38:37 PM EST

The place I heard about it was the Gentoo Forums, here

There's a lot of info there, I haven't read it all, but according to the first guy it IS possible. Good luck.

[ Parent ]

Next step: kill dotfiles, please. (4.33 / 9) (#65)
by Professor Collins on Fri May 09, 2003 at 05:26:20 PM EST

Having configuration information stored in a billion artificially-hidden files is a gross hack, the rationale of which I've never understood. Once you've solidified the system layout, work on killing .* and replacing it with a sane ~/Settings/ directory that doesn't need to be rendered invisible.

KDE RCs (none / 0) (#71)
by ensignyu on Fri May 09, 2003 at 06:15:08 PM EST

Yeah, like the way most KDE programs store their stuff in .kde/config/xxrc (except, not in a dot folder, I guess)

[ Parent ]
At some point... (none / 0) (#88)
by SleepDirt on Fri May 09, 2003 at 08:06:42 PM EST

At some point it would be useful to dump all those config files into a database. Since just about every distro ships with mysql it would be a trivial system to setup.

I imagine it's too close to the idea of the Windows registry for some people but there are some huge benifits to that style of a system. It wouldn't suffer the same shortcomings of the Windows registry because it would be a standard SQL database instead of a huge binary hive.

"In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity." - Hunter S. Thompson
[ Parent ]

Huh? (none / 0) (#100)
by grouse on Fri May 09, 2003 at 10:27:33 PM EST

It wouldn't suffer the same shortcomings of the Windows registry because it would be a standard SQL database instead of a huge binary hive.
I don't know about you but my version of MySQL stores everything in huge binary MyISAM files, which are not a standard as far as I know. What exactly are the shortcomings of the Windows registry that changing the file format would fix?

You sad bastard!

"Grouse please don't take this the wrong way... To be quite frank, you are throwing my inner Chi out of its harmonious balance with nature." -- Tex Bigballs
[ Parent ]

File formats (5.00 / 1) (#105)
by SleepDirt on Fri May 09, 2003 at 11:09:32 PM EST

Actually, I have no problem with the Windows registry myself. I'm only stating what other people commonly say about it -- especially when you bring up the idea of replacing the UNIX PTC files with something like it.

File formats aren't the main issue really. As you said, both will end up being in binary. What's more important is how you can modify it. The Windows registry is a pretty ugly, monolithic, thing. It's not uncommon to dig 5-10 keys keep to find what you're looking for. They registry itself swells in size quickly causing Windows Rot. If you find yourself with a crashed system, editing the registry is a pain. It can be done but it's very difficult.

I think all these problems can be solved using an SQL backend. It may not be perfect but there's a middle ground between the Windows registry and plain text configuration files that would offer the best of both worlds.

"In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity." - Hunter S. Thompson
[ Parent ]

I'm not convinced (2.00 / 1) (#106)
by grouse on Fri May 09, 2003 at 11:21:07 PM EST

You haven't supplied any reasons why using SQL for this purpose would be superior to plain text files, or how it would be any less monolithic than the registry (and try fixing a broken MySQL file sometime for fun).

I guess SQL is more buzzword-compliant. Maybe you could run a Beowulf cluster of MySQL back-ends to manage your prefs!

You sad bastard!

"Grouse please don't take this the wrong way... To be quite frank, you are throwing my inner Chi out of its harmonious balance with nature." -- Tex Bigballs
[ Parent ]

It might not be any better (4.00 / 2) (#110)
by SleepDirt on Sat May 10, 2003 at 12:19:50 AM EST

The original poster simply asked about ways to replace plain text files and I gave him a solution. Is the Windows registry superior to plain text files? Not really, just different. Apple's preference system isn't bad but again, is it superior to any other system? I don't think so.

There are many features an SQL backend could expose. Use your imagination.

-Maybe programs could search trough the database looking for hints on what defaults to use. For instance, if you define your e-mail address in one program, why shouldn't all programs be able to access it? An SQL backend would let you do that.

-It would eliminate the need for a strict FS layout. Program A, which relies on program B, could simply query the database instead of looking in /etc/programb. A killer feature? Maybe not.

-It would allow multiple versoins of the same software to be more easily installed on your system as well. You could query the database for Program B, Version X.Y while having Program B version X.Z safely seperated.

-You could use it to archieve old config settings.  You could easily tell a program to start Program B with settings from XX/XX/XX.

-You could have these SQL severs exposed to your network so you could point a program to another workstation for its preferences.

-You could use existing technology to access an SQL database to expose settings in any number of other mediums. Web based interfaces? No problem. Java config applets? No problem. All the plumbing is already done.

-etc, etc, etc, etc

Like I said, is it going to be a superior solution? Maybe, maybe not. All these things could be done using existing technology with enough effort probably. Personally, I think it would be.


"In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity." - Hunter S. Thompson
[ Parent ]

some problems (5.00 / 5) (#120)
by martingale on Sat May 10, 2003 at 03:52:44 AM EST

There are issues with some of your suggestions:

-Maybe programs could search trough the database looking for hints on what defaults to use. For instance, if you define your e-mail address in one program, why shouldn't all programs be able to access it? An SQL backend would let you do that.
This is a security nightmare. It begs for pervasive access controls, which will needlessly complicate application programming. Right now, we can get by with read/write/execute, and because file formats mostly aren't standardized (as they would be in xml say), it's usually too much work to read/change settings for other programs on the system. With a well designed common database, you'd get programs overwriting each others' settings inadvertently (and that's not counting malicious programs).

-It would eliminate the need for a strict FS layout. Program A, which relies on program B, could simply query the database instead of looking in /etc/ programb. A killer feature? Maybe not.
Like any system which is separate from the file system itself, there's the problem of synchronization. What happens if you change the fs, and the SQL backend no longer tells the truth about what's on the system? In principle, only the file system itself is competent to always give truthful answers about what it contains.

-It would allow multiple versoins of the same software to be more easily installed on your system as well. You could query the database for Program B, Version X.Y while having Program B version X.Z safely seperated.
I'm not sure how much SQL helps for this. Windows has DLL hell, because the components have the same name throughout revisions. SQL would be an extra layer of brokerage to get the right component, but wait: how do you know which component is the right one? Obviously, your program already needs to know the name to use, and if it does, there's no reason it couldn't go look directly in the filesystem for it. I can't see SQL bringing any benefit on this.

-You could use it to archieve old config settings. You could easily tell a program to start Program B with settings from XX/XX/XX.
This sounds good, but it hides the need for a full backup of all relevant components. If you want the old settings, you may also need the old version of the program to go with it. And of course roll back the data files if there were incompatible changes etc. Of course, on a very small scale, this could work well. But does that justify an SQL solution?

Just some thoughts.

[ Parent ]

Problems with the windows registry. (5.00 / 2) (#149)
by Karellen on Sat May 10, 2003 at 08:50:31 AM EST

It's such a waste of effort.

It's a tree structure containing information in some arbitrary binary format. Why not use a goddamn directory tree with files? Why not put the registry as a bunch of directories under, say, "$SYSTEMROOT$Registry/HKEY_*...", and allow it to be browsed by normal filesystem tools? Key/Value pairs can be represented by Filename/File contents pairs.

Need to add content-type data to the name/value pairs? Use filename extenstions. "/HKEY_.../Name.txt" is a string value, /HKEY_.../Name.int-32-4321" could be a signed 32-bit little-endian integer value (if you need to be that precise - Name.int would probably suffice)

Someone's had to implement the `regedit` search tool. If you used the filesystem, you could just reuse the existing file searching tools to search the registry by key/value as easily as everything else.

You could use the already written FS permissions code to limit access to parts of the registry, instead of duplicating that.

To copy registry settings between computers, you could just zip parts of the registry up, copy and unzip.

The whole registry back-end is just a reimplementation of what the FS does anyway, and it seems such a waste of time and effort. That's what I hate most about the windows registry.

That's an implementation issue though. The thing I hate about the design is the fact that you can't put comments in the registry. The thing I like most about unix config files are the ability to put comments that explain what each setting does near each setting, and to provide a number of commented out example settings. If you just need to tweak something quickly that can be so handy.

K.

[ Parent ]

Because (none / 0) (#157)
by i on Sat May 10, 2003 at 11:34:05 AM EST

most filesystems suck at storing very many very small files, that's why.

and we have a contradicton according to our assumptions and the factor theorem

[ Parent ]
So fix the filesystem then. (none / 0) (#171)
by Karellen on Sat May 10, 2003 at 02:02:57 PM EST

Right, so instead of making the filesystem better, and improving all the applications that use the filesystem in some way (uh, all of them), it's better for each application to invent it's own tree-structure-in-a-file system? One that's incompatible with all the other tree-structures-in-files? One that you need to write your own tools to fix if it gets corrupt, instead of simply debugging and enhancing the existing FS checker/fixer (and therefore helping all other apps which use the FS, which is, as I already mentioned, all of them).

If you're going to put the effort in to make an efficient tree-structure-in-flat-file representation, why not put it in to make an efficient tree-structure-on-bare-disk - i.e. write a filesystem? Or better, enhance/fix the existing one.

K.


[ Parent ]

You are barking at the wrong tree. (1.00 / 1) (#178)
by i on Sat May 10, 2003 at 02:36:19 PM EST

Tell Microsoft, not me.

and we have a contradicton according to our assumptions and the factor theorem

[ Parent ]
Hehe (5.00 / 1) (#207)
by vadim on Sat May 10, 2003 at 08:50:46 PM EST

So you arrived at a nice conclusion. Instead of writing a filesystem-like database the optimal solution is text configuration stored on ReiserFS (optimized for small files and directories with lots of files in them)
--
<@chani> I *cannot* remember names. but I did memorize 214 digits of pi once.
[ Parent ]
Damn, rumbled. (none / 0) (#224)
by Karellen on Sun May 11, 2003 at 04:42:28 AM EST

Guess I made it too obvious I'd been reading Reiser's papers, huh? ;)

[ Parent ]
Pain... (none / 0) (#209)
by miah on Sat May 10, 2003 at 09:13:11 PM EST

Why not just have a system where all your config files are stored in two places.

The first place is the ~/.etc/ directory that someone earlier mentioned. This is where all of the users configs are for every app they run. It could obvigate some of the pain of having a million .*rc files in your home dir.

The second place is a global /etc/ directory that overides options on applications giving the sys admin the control. A global option to turn file caching off on a web browser would be a nice "feature".

These ideas come from admining a system that uses LDAP for authentication on all machines and NFS to store the files on a fileserver. This allows any user to use any machine and still access their files. And, it cuts down on the pain of backing up a million workstations.

As my system sits right now I have config files from KDE 1.0 programs sitting in my home dir that are for apps that I used almost four years ago. It would be really nice to have them under ~/.etc/kde1.0/ and be able to kill that without losing all of my current configs.

If you need a database, your filesystem has failed. Filesystems and LDAP are both databases, they are just hierarchical rather than relational. There are things that trees can do that adjacency matrices cannot.

Religion is not the opiate of the masses. It is the biker grade crystal meth of the masses.
SLAVEWAGE
[ Parent ]

Local Config (4.33 / 3) (#122)
by squigly on Sat May 10, 2003 at 04:09:59 AM EST

I agree.  Essentially, the problem is that we don't have a logical tree for config files.  It's more like a grid with applications on one axis, and users along the other.

As another poster commented, we could use SQL, but we need to make it clear what apps we can configure.

What I think may work is a second heirarchy - So we have an apps heirarchy, and a user heirarchy where files can be in both trees if neccesary.  

[ Parent ]

GConf (none / 0) (#135)
by TheEldestOyster on Sat May 10, 2003 at 05:42:00 AM EST

GConf uses XML files for a backend now, but there's no reason it couldn't move to an SQL backend and keep compatablity.

Personally, I like putting configuration options for CLI programs in files and options for GUI programs in gconf. At least until a good CLI GConf editor comes around. I also haven't seen a good way of storing complex configurations (think web servers) in GConf.

But, I do like the idea of ~/.etc/ for user-level configuration files. (But then, I rarely look at "hidden" files, so I don't really care that much.)
--
TheEldestOyster (rizen/bancus) * PGP Signed/Encrypted mail preferred
[ Parent ]

Does it run on PPC (2.00 / 1) (#68)
by hesk on Fri May 09, 2003 at 05:51:45 PM EST

Hi, so if it's like Max OS X. Can I put it on my iBook? I'm using Debian right now, but I would surely like to try GoboLinux out.

--
Sticking to the rules doesn't improve your safety, relying on the rules is

So .... (2.66 / 6) (#70)
by chbm on Fri May 09, 2003 at 06:05:36 PM EST

you managed to duplicate the annoying long paths from Windows. Exactly, what good comes from that apart from a link spaghetty ?

-- if you don't agree reply don't moderate --
Spaghetti (none / 0) (#99)
by Ublis on Fri May 09, 2003 at 10:24:50 PM EST

Long names are not uncommon in Linux, as proven by the numerous SomePackageName.Someversion.Somesubversion.tar.gz The directory structure is however quite unintuitive to new users. Home is just about the only thing that sounds recognizable. I do think the structure used by Gobo sounds a lot better. From my understanding (no Linux expert) the links spaghetti is there to keep apps which use absolute paths or which otherwise depend on the "classic" structure working under Gobolinux.

[ Parent ]
Incoherent semi-rant: Designing for New Users. (3.50 / 2) (#102)
by Verax on Fri May 09, 2003 at 10:40:05 PM EST

The directory structure is however quite unintuitive to new users.

I think it makes more sense to optimize for the general case. Sometimes new user intuition isn't that great; why try to cater to that? Wouldn't it be better to make the system as useful and efficient as possible, and then provide as clear documentation as possible for everyone, novice and expert alike?

As an example (not that linux is perfect), I enjoy using linux, where files are easily specified by typing with automatic file completion. A recent and disgusting trend has been for some applications to copy the windozy way of doing things, providing alphabetized directories and requiring mouse clicks to navigate them. But you can only fit so much on a screen, and it really stinks to have to seach very long (literally hundreds to to thousands of files each) directories, one nested within another, when I know the path to the file that I want, but am not allowed to just type it. Please don't add to my eyestrain and backache by requiring mousing on account of a new user. Plus, new users don't stay that way. Why not optimize for what they will be for most of their life, rather than for when they are new?



----------------------------------------------
"It is a poverty to decide that a child must die so that you may live as you wish." -- Mother Teresa of Calcutta
[ Parent ]
Good idea, implementation debatable (4.66 / 3) (#75)
by ensignyu on Fri May 09, 2003 at 06:26:18 PM EST

I like the idea of keeping everything in its own directory and such, but I don't necessarily agree with the directory names and that particular layout. I'm also wondering how the GoboHide patch works ... seems a little bit extreme (even if it's optional, I don't think normal people would want to use it.) Is the list of hidden directories configurable a la Mac OS X?

GoboHide (5.00 / 1) (#113)
by lucasvr on Sat May 10, 2003 at 01:19:39 AM EST

GoboHide is a patch we did that basically keeps a list of the inodes one wants to hide from userland. So, we only have to execute GoboHide at boot time, telling which directories/symlinks we wish to hide, such as /lib, /etc, /bin, /usr, /boot and so on (since they are available on different directories on the proposed tree).

So, there exists a userland application called gobohide that talks with the kernel. It's simple as it should be: to hide an entry, just execute:
$ gobohide -h <dir>
If one wants to unhide an entry, just execute:
$ gobohide -u <dir>
There is also a statistic feature in order to show the entries being hidden:
$ gobohide -l <user>

So, by using this solution on kernel space, we can let *any* application use the proposed tree, without need to modify their source codes.

[ Parent ]
Possible alternative... (none / 0) (#278)
by tchuladdiass on Fri May 16, 2003 at 02:00:54 PM EST

The way I'd like to see gobohide work is, instead of issuing a kernel call to hide each file, impliment it using file attributes. That way, you'd beable to "chattr +h" on a file, and it would stick between reboots. Also, if done right, it wouldn't need a kernel patch, just a patch to glibc's "readdir" function.

[ Parent ]
file attributes (none / 0) (#285)
by lucasvr on Tue May 20, 2003 at 02:20:33 PM EST

We have discussed about a "persistent" implementation, so directories/symlinks hidden wouldn't need to be hidden at boot time again. The problem with this approach is that once the inode is hidden, there is no way to know what are the current inodes being hidden.
It could be possible to keep a simple database to store such information, but it is mostly annoying. The initial gobohide patch passed through this idea, but the current implementation is more secure and better to manage.
Anyway, thanks for the suggestion, they are always welcome :)

[ Parent ]
Elaborating on my own comment ... (none / 0) (#138)
by ensignyu on Sat May 10, 2003 at 06:10:25 AM EST

Are the paths configurable? Could I, say, have the system files in /LinuxSys2 instead of /System? (Without recompiling anything).

[ Parent ]
Why this is nothing new, and won't help. (3.33 / 3) (#78)
by mindstrm on Fri May 09, 2003 at 06:48:16 PM EST

This is nothing more than a novel but obscure way of doing package management.

So what?

We have package systems, GOOD ones, already... I have tons of software installed on this Mandrake 9.1 workstation, I used a GUI to do it, and I didn't even have to call on ANY of my wizardlike unix skills to do it. My girlfriend has no problems using it, unassisted.  I'm fairly certain my Mom could figure it out too.

A totally new filesystem layout is not going to progress linux on the desktop. It's only going to fragment things further, if anything.  The problem is in applications working together, and in a coherent, user-friendly desktop that people can use.
The only other barrier is having a standard package format that developers can target... rather than having to make separate packages for Redhat versions, mandrake versions, debian, etc. Does this solve that issue? no.. it's yet another totally differnet standard, requring modification of all current paradigms with regards to linux development, and it doesn't actually solve a problem that needs solving.


Nothing new, but overdue nonetheless. (none / 0) (#172)
by the Speed Bump on Sat May 10, 2003 at 02:04:35 PM EST

Packaging systems like RPM and DEB are fundamentally redundant.  Files live in directories somewhere; packages consist of a bunch of files.

It makes sense to unify directories and packages, does it not?  This way, package/filesystem inconsistencies become impossible, because the two are one and the same.

Moreover, this means that no custom applications or file formats are necessary.  tar.bz2 is all you need; tar and rm become plenty sufficient to install and uninstall things.

As for what's new, this is done on the distro level; we (the retarded computer users) don't have to do anything to set it up, beyond stuff the CD in the drive and hit the power button. (and some other stuff)

[ Parent ]

No, it doesn't. (none / 0) (#200)
by mindstrm on Sat May 10, 2003 at 06:56:37 PM EST

Because fundamentally, a filesysetm is not a package management system, and cannot account for everything .

" No custom file formats or applications are necessary"

How is RPM more custom than TAR? Both require a tool to unarchive them; one has more options than the other. Sure, tar is older than rpm.. but then again, bz2 is newer.

Adhering to a file structure of some sort as a means of package management is not inherently easier than, say, using rpm. or deb.  Both require the same amount of planning and deployment. Those deploying an application still have to put the right things in the right folders.

My point is still that this a) doesn't solve a current problem anymore than current solutions do and b) creates a mess by doing things differnetly.

You may think it's neat, and looks elegant, and in a way it is.. but overall, it doesn't bring anything to the table.

And as I said.. all I did to set up my computer was: Put in the cd, hitthe power button (and some other stuff)

how is typing "cd /; tar -jxf package.tar.bz2;/install/package/setupscript.sh" somehow less work for the user than "rpm -Uhv package.rpm" or "dpkg -i package.deb"  or "urpmi packagename" or "apt-get install packagename".

I'm not saying it can't work... just that it's not better than the current situation. It creates more problems than it solves.

[ Parent ]

It eliminates redundancy. (none / 0) (#220)
by the Speed Bump on Sun May 11, 2003 at 02:35:59 AM EST

The directory structure does indeed solve the current problem better.  Gobo's directory/package setup can not go out of synch.  If you nuke /opt/kde on a RPM based distro, the RPM registry won't know that kde is gone, and things will get screwy.

Awhile ago, I wound up having to compile Python on my own (mod_python weirdness), which threw the RPM stuff into chaos, because it had no idea that I had Python already; it just knew that I hadn't done so through RPM, and thus borkage ensued.  Not fun.

This can't happen in Gobo's directory tree, simply because the directory itself is the program.  Deleting /Programs/KDE uninstalls KDE.  No database to keep synched, no potential for screwups.  If /Programs/Python exists, then Python is obviously installed.  Brilliant. :)

[ Parent ]

wasn't going to reply, but . . . (none / 0) (#236)
by binford2k on Sun May 11, 2003 at 06:48:08 PM EST

This is utterly moronic.  If you have a user who is dumb enough to delete /opt/kde and you have to cater to him, then who says you won't have a user that will rename /Programs/Perl to /Programs/Python because somebody told him he needed Python installed and he read your comment above that stated "If /Programs/Python exists, then Python is obviously installed."

Fileystem structure is NOT a package database and won't even do something as simple as dependancy tracking.  Anyone who claims different doesn't understand the issue.

[ Parent ]

Well, I wrote the article... (4.80 / 5) (#81)
by sethadam1 on Fri May 09, 2003 at 07:05:53 PM EST

LodeRunner - I am the author of the article you linked above, the one that surprised you the most.  I think your project is awesome.  

I believe of the keys to success doing what you're doing is package availability.  When a user makes the move, if they're missing even one "crucial app:" a KaZaa clone, a good IDE, a capable browser, etc, they generally don't stay.  Looks like there're quite a few packages available for GoboLinux.  I'm downloading it now!

Good luck!

--
Adam Scheinberg
OSNews.com

Thanks / package availability (none / 0) (#182)
by LodeRunner on Sat May 10, 2003 at 03:11:58 PM EST

Thanks a lot. If you hadn't written that, perhaps GoboLinux would continue "in the shadows", known only by my friends and a few more people, for another year or so.

About packages: the packages that are available are the ones we wanted to use. There's much to improve on this subject, the package selection was never looked at with the importance it deserves.

We are also investigating possibilities for source-based packages, considering if Portage or the Debian system will adapt to our model of if we'll roll our own. As I said in the article, possibilities are wide open.


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

yes, scuse me, (1.16 / 6) (#85)
by turmeric on Fri May 09, 2003 at 07:44:14 PM EST

why do we need directories at all why do we need files? whats the friggin point?

While we're at it . . . (5.00 / 2) (#90)
by hardburn on Fri May 09, 2003 at 08:21:22 PM EST

Could we get rid of molecules? Maybe nutrons, too. They just sit there without any charge, after all. What's the point?


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


[ Parent ]
no, not neutrons! (4.50 / 2) (#101)
by martingale on Fri May 09, 2003 at 10:31:15 PM EST

Just because neutrons don't have charm, it's not their fault! At least they're not half strange either.

[ Parent ]
But... (3.00 / 2) (#229)
by Stick on Sun May 11, 2003 at 01:12:06 PM EST

Saddam gassed his own people.


---
Stick, thine posts bring light to mine eyes, tingles to my loins. Yea, each moment I sit, my monitor before me, waiting, yearning, needing your prose to make the moment complete. - Joh3n
[ Parent ]
Don't bother... (1.80 / 5) (#86)
by SleepDirt on Fri May 09, 2003 at 07:58:47 PM EST

There's really no reason to rearange the Linux FS layout at this time. Assuming the general trend of Linux developers trying to clone Windows continues, in 2 or 3 years we'll have a Linux version of WinFS. I'm assuming it'll be called LinFS or GNU/FS or something. Either way, it'll be the same basic database driven file system that is being released with Microsoft's newest version of Windows. This will solve all the user-unfriendly features of the Linux FS. For the users who decide not to use this new database driven FS, they'll have their old style Linux FS layout which they're comfortable with.

"In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity." - Hunter S. Thompson
Er? (none / 0) (#132)
by TheEldestOyster on Sat May 10, 2003 at 05:36:18 AM EST

Microsoft cloned ReiserFS and BFS and the FS in OSX, IIRC.

Don't forget. While the FOSS communities are playing  catchup with MS and Apple in terms of usability, Apple and especially MS are playing catch-up everywhere else. Hear about the new .NET enabled CLI shell Longhorn will have? Or the version of Windows Server which will allow configuration via text files?

It's not as onesided as you think.
--
TheEldestOyster (rizen/bancus) * PGP Signed/Encrypted mail preferred
[ Parent ]

Excellent (none / 0) (#91)
by ComradeFork on Fri May 09, 2003 at 08:29:25 PM EST

This is exactly what I've been wanting. As soon as I get a CD burner, I'll be using this.

dialects (4.00 / 4) (#96)
by bigdavex on Fri May 09, 2003 at 09:55:09 PM EST

The thing that I find most deficient about the unix file structure is how it varies between the different unices and the versions thereof, just when you think you're getting it, and in completely meaningless ways.

Expecting it in /etc ?  ha-Ha!  /private/etc !
Expecting it in /usr/bin?  ha-Ha! /usr/local/bin!
Expecting it in /usr/local/bin?  ha-Ha!  /local/apps!

So even clever re-groupings aren't going to make me happy.  In fact, they're the problem.

Deficiencies (4.33 / 6) (#107)
by CAIMLAS on Fri May 09, 2003 at 11:26:33 PM EST

Here are the problems I see with it:
  1. There is no global depository for configuration files. This is a very strong point on a linux/unix system - you can back up your system config with a single command (tar -czvf config-date$.tgz etc), and rebuild a system quickly. Not only that, but it allows for hasty system cloning w similar or identical hardware.
  2. What about a /chroot dir? /chroot/bind, /chroot/apache, etc. would all be nice and practical. Why not automate that?
  3. Why do we need this, again? As already stated, there are several means through which to efficiently and properly install programs. There's either dpkg or rpm, and both work wonderfully with the miriad of frontends.
  4. The only reason I could see this as being something nice is if you're unable to grasp the (fairly simple) heirchy of organization used on a linux/unix system. Sure, if you're coming from a Windows desktop, there are some things that need adjustment. However, like moving to anything else new, you have to re-aquant yourself. The basic philosphy is the same, but the organization is different.
  5. Your use of "Files", and "Depot" - wtf are these for? I'm guessing that Depot is the equivilent of /tmp. Where's your /proc? Your /var? Your /log? These are all important. "Files" shouldn't be seperate from "Users" - if you have "Files", I'm assuming you want to have a single-user system. This just seems redundant and useless.
Your ommisions of these things seem to me to be a relatively deep lacking in understanding of how, and why, things are currently done the way they are. Linux on the desktop should not mean that much of the functionality and usefulness for 'non-desktop' tasks is removed. Many people will want to run a web server (and do run a web server) on their desktop. You ignore this, and seem to propose this functionality removal.

--

Socialism and communism better explained by a psychologist than a political theorist.

Hmm (none / 0) (#183)
by Julian Morrison on Sat May 10, 2003 at 03:16:00 PM EST

"there is no global depository for configuration files."

Sounds like each package will have its own $PROGRAM/$VERSION/etc dir. So one merely uses "find" to get at those dirs. This is hardly rocket science.

A side effect of this is that one could share configs for some programs and not others, which might be of use in a large organization. Why should a database box have access to a web-server box's configuration? A shared /etc could even be seen as an information leak and a security worry.

[ Parent ]

/etc is never shared. (none / 0) (#215)
by abulafia on Sat May 10, 2003 at 11:26:53 PM EST

Think about it.

Why should a database box have access to a web-server box's configuration?
Why indeed? Why should it be easy to share that as a consequence of sharing other things, like X, [su|grep|perl|...]?
Do we now need a config file for sharing a subset of a directory tree, to make sure only the "exportable" subset is shared?
Hm, that Seems Like A Bad Idea. Or maybe I missed the point of what we're trying to solve.


[ Parent ]
Some answers (5.00 / 1) (#189)
by LodeRunner on Sat May 10, 2003 at 04:47:01 PM EST

Here are the problems I see with it:

Ok, let's go:

1. There is no global depository for configuration files. This is a very strong point on a linux/unix system - you can back up your system config with a single command (tar -czvf config-date$.tgz etc), and rebuild a system quickly. Not only that, but it allows for hasty system cloning w similar or identical hardware.

Each program has a Settings directory (well, those who need it), so the placement of config files is well-organized. A shell line with find and tar should do the trick. Maybe adding a script BackupSettings to do just that would be a good idea.

2. What about a /chroot dir? /chroot/bind, /chroot/apache, etc. would all be nice and practical. Why not automate that?

Because we haven't thought of that. :) Ideas are always welcome, we certainly could try that out.

3. Why do we need this, again? As already stated, there are several means through which to efficiently and properly install programs. There's either dpkg or rpm, and both work wonderfully with the miriad of frontends.

I think that's more a matter of personal opinion. We're not arguing for the end of RPM or dpkg. Choice is good, it's all free software.

4. The only reason I could see this as being something nice is if you're unable to grasp the (fairly simple) heirchy of organization used on a linux/unix system. Sure, if you're coming from a Windows desktop, there are some things that need adjustment. However, like moving to anything else new, you have to re-aquant yourself. The basic philosphy is the same, but the organization is different.

We understand the Unix tree, we just don't like it. :) Just to make things clear: the idea was to have things more organized, not just "simplified". We did not have "Windows users in mind". That's actually a FAQ, already. :)

5. Your use of "Files", and "Depot" - wtf are these for? I'm guessing that Depot is the equivilent of /tmp. Where's your /proc? Your /var? Your /log? These are all important. "Files" shouldn't be seperate from "Users" - if you have "Files", I'm assuming you want to have a single-user system. This just seems redundant and useless.

There are several things I did not address in the article (it was, after all "an introduction to GoboLinux", not an in-depth view, and I didn't feel making a multi-part series was appropriate).

"Files" holds extra files needed by applications that are not part of the app package itself: plugins, codecs, audio patchsets... In other words, things you won't replace when you upgrade your app in /Programs.

"Depot" is more like a 'common user area'. Its contents are not dictated by the GoboLinux hierarchy, the user uses it and sets permissions as/if he/she sees fit. Think of it as a /pub directory. Maybe it does make more sense in a single-user machine, but I can see it being useful in a multi-user setup. For example, I keep my MP3s in /Depot/Music.

/proc is on /System/Status, and /var is on /System/Variable. They work as usual. Their symlinks at the root directory were hidden with GoboHide. /log is /var/log, in other words, /System/Variable/log. Whether Files (actually Depot) should be separate from Users or not, it's a matter for the users to decide. I'd rather share stuff with other users of my machine putting them on /Depot than opening up permissions of specific directories of my $HOME (I like to keep it rwx------). But that's just me.

Your ommisions of these things seem to me to be a relatively deep lacking in understanding of how, and why, things are currently done the way they are. Linux on the desktop should not mean that much of the functionality and usefulness for 'non-desktop' tasks is removed. Many people will want to run a web server (and do run a web server) on their desktop. You ignore this, and seem to propose this functionality removal.

Don't worry about these things. We don't intend to remove functionality arbitrarily. We have GoboLinux users running Apache, and things work like they should. :)


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

While we're changing paths (none / 0) (#282)
by gsabaco on Sat May 17, 2003 at 07:11:15 PM EST

How about changing /System/Variable/log to the more sensible /System/Logs, or breaking up the logs to /Programs/SendMail/Current/Logs and /Programs/Pure-FTPD/Current/Logs etc (maybe even with links in /System/Logs to the location of the logs for the "Current" version of the program). I understand why things are in /var under a traditional unix file system, but I think it would make more sense to tie logs directly to the system or the programs rather than to some "variable" thing. Also, it should be Logs (capitalized, plural) just like it is "Programs". If the logs are stored with the individual program it might make sense to have /Log (if there is only one log file) but, I'd think plural is better since things like Apache normally have mutliple logs and we'd like to have things stay for consistant

[ Parent ]
Why do we use directory trees anyway??? (4.00 / 1) (#108)
by limivore on Fri May 09, 2003 at 11:34:23 PM EST

It's probably super obvious but I dropped out of CS. Why do we use directory trees to arrange stuff. Why not just use unique identifiers for everything and then assign keys and descriptions or whatever and view the stuff in whatever way suits your momentary whim? Keep track with databases and search engines and tables. speed?

organization? (none / 0) (#116)
by X3nocide on Sat May 10, 2003 at 02:44:14 AM EST

The system is partially about legacy. Its how files systems are done, quite simply. Research goes into maintaining their integrity, efficiency, but the directory hiearchy and file system remains.

One reason is organization. Another is that users probably don't know the unique keys anyways. Not that DB file systems havent been done. I hear that BeOS used a crazy 64bit database filesystem. But I've never used it. I hear that the next version of windows intends to use a query system over the hiarchial browsing.

pwnguin.net
[ Parent ]

ehh ... (5.00 / 1) (#134)
by joto on Sat May 10, 2003 at 05:38:41 AM EST

Because it's useful and convenient.

You could have a flat filesystem, but then everything needs a unique name (or number :-)

You could have a one-level filesystem, but then every directory-name would have to be unique. E.g foo/README.TXT, but what if you install a program that insists on being put in foo (or you had forgotten you already have a foo).

The natural extention is to have a hierarchy of identifiers, so you could have both a/foo/README.TXT, and b/foo/README.TXT. This is comparable in speed to the one-level proposal (sometimes faster, sometimes slower, depending on implementation). This is also quite flexible, and most users don't have too much problems understanding hierarchies (which are quite common outside computers too). Trouble is, that sometimes we want more flexibility, see below.

So, why should we limit ourselves to a hierarchy, when we could have a network. Maybe we wanted to organize our mp3 collection so we could access the files in several ways, e.g: /mp3/byArtist/Elvis Presly/Love Me Tender.mp3", /mp3/byTitle/Love Me Tender/Elvis Presley.mp3", and so on. To make this possible, we should allow cross-links within the file system, and we would end up with a network of links, which you could probably follow forever. (The forever is the tricky part here, programs (or users) that look through the file-system may not know when to stop). This solution certainly has some merit, although it's easy to see that it could also be quite confusing. (Unix lies somewhere in-between the strictly hierarchical, and the network model).

But, to make things even more general, you could have a relational system, e.g: SELECT file FROM all_disks WHERE TYPE="mime:audio/mp3" AND TITLE="Love Me Tender" AND ARTIST<>"Elvis Presly". Trouble is, as the example shows, that it would be hard to know how to describe a file uniquely. And that is what we want to do most of the time (think programs accessing files, not users clicking on one in a file-select box). Also, the example looks very verbose, but that's probably fixable. It would definitely be slower than hierarchical, but maybe not by much. It would be much harder to browse for files, but probably easier to search for them. This makes it harder to find stuff you've forgotten about, and harder to remember to delete old junk. But the idea definitely has some merit.

We could also try a more unstructered approach, such as selecting files based on keywords, e.g: [1999,budget,football,excel,june]. The downside is that it is probably worse then the above proposal in almost every way (not limited to forcing the user to enter all kinds of keywords to have any hope of finding it back again), but I've seen people advocate it.

Conclusion: We choose hierarchical, because it is easy to understand, manageable, and fast. Other solutions (such as relational) could be built on top of it. So far, none have become really popular, but it might happen in the future.

[ Parent ]

But what is the order of the components? (none / 0) (#159)
by Ubiq on Sat May 10, 2003 at 12:22:50 PM EST

Should it be /Programs/Links/Executables or /Programs/Executables/Links? Can you tell me which one BogoLinux uses without glancing back at the article? Very often when I try to organize things I end up with files that belong into multiple directories or directories that could be organized in many ways without one way being `obviously correct'.

A database system with keywords would solve this problem.



[ Parent ]
A path is a name (none / 0) (#269)
by ksandstr on Tue May 13, 2003 at 10:42:52 PM EST

Like the subject says, an absolute path to a file does uniquely designate the file in an UNIX-like system.  Through this hierarchy, we get groupings like man, info, share, lib, bin and others.  

"Whatever suits your momentary whim" does not work for programs that aren't AI-complete, sadly. So cut this dreamworld candyland bullshit right out, please.


Fin.
[ Parent ]

A path etc... (none / 0) (#277)
by limivore on Fri May 16, 2003 at 08:08:53 AM EST

>Like the subject says, an absolute path to a >file does uniquely designate the file in an >UNIX-like system. Through this hierarchy, we >get groupings like man, info, share, lib, bin >and others. I don't see the issue. Path string is one way to identify, unique key is another, description is another. >"Whatever suits your momentary whim" does not >work for programs that aren't AI-complete, >sadly. So cut this dreamworld candyland >bullshit right out, please. Candyland? A really dynamic and flexible file manager interface doesn't strike me as that long a leap. And while we're on the subject, what's up with manners on the internet? What's up with your rudeness? Why is buttheadly behavior so common? Do you little geeks even think before you flame? Monkeys flinging shit.

[ Parent ]
Uppercase letters.... (4.83 / 6) (#109)
by duffbeer703 on Sat May 10, 2003 at 12:12:20 AM EST

Ditch them. You gain nothing by mixing case but a whole new class of typo.


Alternatively... (none / 0) (#112)
by ewhac on Sat May 10, 2003 at 12:41:24 AM EST

Either that or make the filesystem case-insensitive.

Schwab
---
Editor, A1-AAA AmeriCaptions. Priest, Internet Oracle.
[ Parent ]

Case sensivity and directory names (4.00 / 1) (#115)
by lucasvr on Sat May 10, 2003 at 01:30:58 AM EST

You gain on legibility, for both GUI and console. Also, the actual stage of shells can let one configure TAB completion in order to work with case sensivity. ZSH, the default shell used on GoboLinux, handle that graciously.
Still, there is no need to make the filesystem case-insensitive, this would be the same as we regreting to MS-DOS again :-)

[ Parent ]
Legibility? (4.00 / 1) (#119)
by squigly on Sat May 10, 2003 at 03:46:15 AM EST

Okay, I see how having some capitalised letters look a little better than all lower case, but why does there have to be a distinction internally?

Still, there is no need to make the filesystem case-insensitive, this would be the same as we regreting to MS-DOS again

In Windows I have a "Program Files" directory, which I can access from the command line as "program files".  There's no way I want to be able to have two files with the same name and diferent capitalisation.  That would be too confusing.

[ Parent ]

while we're on that topic (none / 0) (#125)
by martingale on Sat May 10, 2003 at 04:21:08 AM EST

Personally, I don't care about case insensitivity, you can have that. What really bothers me is spaces in filenames. It completely breaks the command line user interface, which is the only thing I use. In my ideal OS, spaces should be outlawed in favour of underscores. That would really make things clean and elegant.

[ Parent ]
about spaces... (none / 0) (#129)
by joto on Sat May 10, 2003 at 04:52:25 AM EST

Another fun thing is to make a filename that is (or contains) a *, or a ?, or a $, or for csh users, a !. What really annoys me is that we can't have filenames containing /, ascii NUL, or filenames that is zero characters long.

I think they should all be allowed, trouble is that it really makes things difficult when working with find, xargs, awk, etc in shell-scripts...

[ Parent ]

yep (5.00 / 2) (#133)
by martingale on Sat May 10, 2003 at 05:38:39 AM EST

Maybe what's needed is a pool of special characters reserved for all applications. Say all the symbols which live on top of the numbers !@#$%^&*()_+|~, these would not be allowed in file names either. The tools would be free to use them for meta purposes in any way (there's no way to fix incompatibilities with sufficiently many tools), but it would be obvious at a glance what a command line was composed of.

This is not as far fetched as it seems, provided all tools understand unicode. We could reserve whole swathes of symbols for shell applications...

A different thing I'd love to see is syntax highlighting as part of the shell. Take Bash, which already has programmable completion. It shouldn't be too hard to hack the GNU readline to colorize the input line on-the-fly based on a regular expression. Then, Bash could introduce on-the-fly programmable colorization for commands. Neat!

[ Parent ]

Fun filenames (none / 0) (#245)
by squigly on Mon May 12, 2003 at 12:48:56 PM EST

The really fun thing is to create a file called "--" then try to delete it.

"rm --" doesn't work because -- is a control sequence.  

[ Parent ]

Aw hell... that's easy. (none / 0) (#271)
by beergut on Wed May 14, 2003 at 06:32:27 PM EST

"rm -- --"

Next!

i don't see any nanorobots or jet engines or laser holography or orbiting death satellites.
i just see some orangutan throwing code-feces at a computer screen.

-- indubitable
[ Parent ]

Make them interchangable (none / 0) (#142)
by mairsil on Sat May 10, 2003 at 07:30:30 AM EST

What really bothers me is spaces in filenames. It completely breaks the command line user interface, which is the only thing I use. In my ideal OS, spaces should be outlawed in favour of underscores. That would really make things clean and elegant.

But underscores look ugly.

Why not allow people to use underscores as spaces in names? Together with case insensitive dirs, "Program Files", program_files and "PrOGRaM files" would all get you to the same directory.

Case-insensitivity and case-retention (ie. windows style) is the way to go as far as I'm concerned. Unix is way too picky about filenames.

[ Parent ]
an analogy (none / 0) (#155)
by martingale on Sat May 10, 2003 at 10:24:57 AM EST

Why_not_write_English_text_separated_by_underscores.

Or#we#could#use#hashes,it#doesn't#matter.#This#way#"Program Files"#can#have#spaces#and#it's#still#obvious#for#a#human#which#bits#of#the#sent ence#are#word#tokens#and#which#"word combinations"#are#meant#to#be#together.

Spaces enhance our ability to read text, which is why the command line interface is using them to separate tokens. When the tokens include spaces, those spaces must be separated from the other spaces. In#the#sentence#containing#hashes#"Program##Files"#could#be#written#with#a#doubl e#hash#to#mark#the#hash#as#a"##"#(ie#a#space#symbol).

If the spaces were reserved for the command line interword separator, there would be little lost in GUI scrolling lists or icon decorations (since spaces have much less meaning) and it would make it easier to recognize double_word combinations when they represent a single token.

It's not going to be changed, but it's still annoying...

[ Parent ]

Here's the problem. (none / 0) (#214)
by abulafia on Sat May 10, 2003 at 11:09:43 PM EST

Personally, I don't care about case insensitivity, you can have that. What really bothers me is spaces in filenames. It completely breaks the command line user interface, which is the only thing I use. In my ideal OS, spaces should be outlawed in favour of underscores. That would really make things clean and elegant.
Writing software requires delimiters between tokens. It is only natural to use spaces for that. (Fortran attempted to vary that, but I don't think we need to worry about them, wink.)
Giving users the ability to name things, and use named things in an environment in which they can also used executable tokens causes a confict.
Part of the problem is that users want to overload filename to store multiple facts about a document. Tension arrises when standard tools want to make assumptions about what valid, unambiguious input looks like.
This is reductionist thought, but that's exactly what you have to do to make a filesystem.
I'm not going to offer my conception of a replacement here, because I'm not done yet.

[ Parent ]
Wrong (4.66 / 3) (#163)
by rmn on Sat May 10, 2003 at 01:05:06 PM EST

Still, there is no need to make the filesystem case-insensitive, this would be the same as we regreting [regressing?] to MS-DOS again

A file system can be case-insensitive while still preserving case (ex., FAT32, NTFS). IMO, case-sensitive file systems are extremely annoying, and definitely cause more problems than they solve. Seriously, how many people need to have a file called "ReadMe" and another called "Readme" in the same directory?

No, writing a file system that preserves case, is case-insensitive and works with different character sets isn't a simple thing. But hey, Microsoft managed to do it. Ten years ago. And it's these little things that drive some people away from or towards a particular system.

Hacking it in the shell doesn't really solve the problem. What if a program goes looking for its configuration in myprefs.config and the user saved it as MyPrefs.Config?

To a computer, "m" and "M" are completely different things (more different than "A" from "B"). To a human, they are very similar. It's up to the operating system (or software in general) to translate between the two. Otherwise you might as well tell people to type directly in binary.

It's (unfortunately) a typical attitude of (a significant part of) the Linux community to look at a problem that should be solved by the system and write it off as a "feature", leaving it to be handled by the user.

It reminds me of that joke "How many Microsoft employees does it take to replace a lightbulb? None, Bill Gates just defines darkness as the new standard!"...


[ Parent ]

Collisions, Unicode (none / 0) (#213)
by abulafia on Sat May 10, 2003 at 10:58:22 PM EST

A file system can be case-insensitive while still preserving case (ex., FAT32, NTFS). IMO, case-sensitive file systems are extremely annoying, and definitely cause more problems than they solve. Seriously, how many people need to have a file called "ReadMe" and another called "Readme" in the same directory?

You're solving the wrong problem.

How do you store different character sets next to each other? Examples abound in the thread for various values of "conversion" between what is stored and what is displayed. As with anything, it is yet another layer of indirection. At best, something somewhat useful.

Remember that software writes files well more often than people do . Maybe it should be a barrier that software doing so should check case, use a "gimme a file" interface, or something else. You've still caused a rewrite for everything aside from WinX.

There are reasons for a file system to support something beyond a single user machine. Maybe that should be talked about, but assuming the single user model is simply incorrect reasoning. Linux (and computers in general) do a lot more than being something one person types at. There are many, many reasons to keep that supported. If someone wants to "fix" that, more power to them; I don't have a problem with Gobo. They aren't, however, solving problems for me.

[ Parent ]

Perfection (none / 0) (#218)
by rmn on Sun May 11, 2003 at 12:38:58 AM EST

Perfection is a beautiful thing, but just because you can't get "perfect" does't mean you shouldn't at least try to get "good" (or "better").

Case insensitivity doesn't need to cause any collisions or problems with other character sets (even if you don't go for Unicode). Windows probably runs in as many languages as Linux and works quite well (well, as far as file naming is concerned, anyway) without being case-sensitive.

Arguably, there isn't much point in keeping a kana (Japanese) filename if you can't type kana in your latin keyboard. It would, of course, be great if you had the option to convert the filename to romaji when it was transferred to your system, but that's probably overkill (and not something that should happen without the user specifically requesting it).

As long as the original filename is preserved, it can still be transferred back to Japanese systems with no loss of information.

You can argue: what if two files that have different names in kana are transferred to a latin system and their names happen to differ only in the (latin) capitalisation?

Well, without some extra tricks, they wouldn't be able to co-exist in the same directory. Hardly a universe-destroying catastrophe, and extremely unlikely to happen anyway.

But it is possible to let them co-exist (even without going for Unicode). Simply store information about the file's character set in the filesystem. Isn't this what Windows does?

Yes, it's a "messy" solution, but so are human languages in general. People have tried to create "elegant", artificial languages, and weren't very successful. I guess you could say humans tend to be more like Aristotle than like Plato (there are no "perfect things", there are just things).

Do you think it makes any sense for a capitalisation error in a file name to prevent a program from running correctly? Do you think that it makes any sense that, when I'm telling someone about an URL, I have to specifically mention which letters are in upper- and lower-case? I don't. From a usability and "human interface" point of view, I think it's a bug.

And since it's something Microsoft got (more or less) right, it's a bug people notice.

RMN
~~~


[ Parent ]

Case-insensitivity not in file system (5.00 / 1) (#153)
by Amorsen on Sat May 10, 2003 at 10:01:49 AM EST

If the file system is case-insensitive, it needs to know which letters are upper-case, and which are lower-case. This may seem trivial at first, but how does it know whether æ is a Danish letter or a French ligature?

Windows solves this by actually encoding region information right into the file system. This is really fragile and does not work too well over the network. It is also very bloated, with huge character tables sitting around in kernel memory. If you really want case-insensitivity, put it in the shell/GUI. That way it will work right, no matter which locale you are in.

[ Parent ]

This isn't a troll... but (3.57 / 7) (#111)
by sinistar on Sat May 10, 2003 at 12:34:17 AM EST

I think we just write a new operating system from scratch.  Just like Windows get new parts grafted onto the same old base, Linux is a clone of Unix, a very old operating system.  Should't we write something from scratch, instead of reinventing the wheel?

ummm.... (4.00 / 2) (#118)
by squigly on Sat May 10, 2003 at 03:39:35 AM EST

Should't we write something from scratch, instead of reinventing the wheel?

Isn't writing something from scratch the same as reinventing the wheel?

Anyway, Linux is a perfectly adequate kernel.  Essentially, all it has to do is schedule tasks, and handle hardware.  It does the first of these adequately, and the second of these very well indeed.  

[ Parent ]

No (none / 0) (#164)
by sinistar on Sat May 10, 2003 at 01:28:47 PM EST

I think the Linux kernel is slow and archaic, but that's just me I guess.

[ Parent ]
Indeed (none / 0) (#201)
by OddFox on Sat May 10, 2003 at 06:59:13 PM EST

That must be why it's becoming more and more popular both on the desktop and on servers. I mean really, people love to use things that suck, especially for important things like, oh, creating movies, servicing your bank's customers, writing software, etc...

--------------------------

"No escape from the mass mind rape
Play it again jack and then rewind the tape
" - RATM


[ Parent ]
People do love things that suck. (none / 0) (#251)
by sinistar on Mon May 12, 2003 at 04:52:07 PM EST

I mean, look at popular music for example.  Anyway, that's just me. If I wanted hardware compatibility, I would go with NetBSD. FreeBSD seems to be noticably faster then Linux for me, even on a majorly tweaked Gentoo box. Gentoo is however good. But I sometimes feel the archaic part of *NIX variations in general and wonder if it's time to move on.

[ Parent ]
It's just a kernel (none / 0) (#222)
by squigly on Sun May 11, 2003 at 03:33:23 AM EST

I never said it was perfect.  Don't know about speed.  Seems fast enough for me.  Maybe there are faster options,

The thing is, it works.  The performance boost you'd get from a different kernel is minimal, and you'd lose a lot of hardware compatibility.  As for archaic - How so?  I mean is it actually a problem?

[ Parent ]

Not always the best idea (3.50 / 2) (#121)
by ocelotbob on Sat May 10, 2003 at 03:53:16 AM EST

Should't we write something from scratch, instead of reinventing the wheel?

Shouldn't we redesign the wheel, after all, it's a very old idea as well </sarcasm> Seriously, though, the point here is that the Unix directory structure works, and is logical for some people -- if you're running a system with a few hundred users, the traditional structure scales a lot nicer than even the windows directory tree. It allows for a very easy upgrade path if you need to swap out drive space -- there's little to no need to worry about program registries and other bullshit. At the same time, though, it's a bit unwieldy when you're only handling a couple of users. Most users have a single hard drive that's more than enough space for all their apps and personal files, and thus, the unix directory structure gets in the way of adding new programs and the like. This setup seems to allow one to set up the filesystem in a way that is more logical for single/family use yet still remain compatible with Unix apps. IMO, it's about scaling that choice that has always been a strenght of unix to the end user.

Why... in my day, the idea wasn't to have a comfortable sub[missive]...
--soylentdas
[ Parent ]

OS & Interfaces .. (none / 0) (#288)
by Peat on Mon Jun 09, 2003 at 06:56:12 PM EST

The Linux kernel manages your hardware and processes .. it doesn't determine where your files are kept.  It's the dirty work behind the scenes ...

What you're probably interested in is interface development -- I don't mean just GUI, I mean the whole interface ... how do you, as a person, interact with your computer?

Redesigning the file system is one way to approach this.  Building a pretty GUI is another.  Designing a new shell language is another.

Granted, some of it leaks down into the kernel .. for example, "relational" file systems, metadata, etc.  But for the most part, you should be able to solve nearly all of your user issues outside of the kernel -- it's designed that way.

Personally, I'm all about experimenting with new interfaces and behavoirs -- if it gets the job done easier/faster/better than the traditional method, we should embrace it.

Rant rant.  :)

bigbluebang internet services - hosting, consulting, tools, and more.
[ Parent ]

Another kludgy fix for clueless users (2.54 / 11) (#114)
by fluxrad on Sat May 10, 2003 at 01:25:46 AM EST

Ok. listen very closely...come on, closer...a little closer...there:

Linux is not your grandmother's OS of choice!

Now that that's out of the way, I'll get to the point. This idea seems rather lame to me. If linux apps are installed correctly, you don't need to worry about a gigantic LD_LIBRARY_PATH (i think my ld.so.conf is about 8 lines, and i build binaries from scratch alot!), you don't need to worry about your PATH, or *where* include files may or may not be.

Remember, what's why there's a difference between /bin, /usr/bin, and /usr/local/bin. If you have any trouble distinguising between what types of apps/binaries should go where, RTFM! It's not my fault you install everything to /usr/local/foo or /usr/local/baz. The beauty of linux is that it's almost infinitely configurable. Don't take that flexibility away just because most people fuck it up.

--
"It is seldom liberty of any kind that is lost all at once."
-David Hume
bah... (5.00 / 2) (#128)
by joto on Sat May 10, 2003 at 04:34:22 AM EST

Linux is not your grandmother's OS of choice!

Maybe you think that's a good thing. Personally, I would rather get work done, than endlessly tinkering to make my system work. There are lots of stuff that could be done to simplify a typical unix installation without taking out power or convenience away for knowledgeable users. There are also a few things that shouldn't be done. Organizing programs better using the file-system is not one of them, it's the right thing to do, and that's why symlinks were invented.

I believe almost anyone that manages a (collection of) unix system(s) that compiles binaries themselves already do this. It's the sane thing to do.

The other idea, to try to break everything by renaming /home to /Users, etc... is something I myself would consider silly, but if it makes him happy, then why not?

Now that that's out of the way, I'll get to the point. This idea seems rather lame to me. If linux apps are installed correctly, you don't need to worry about a gigantic LD_LIBRARY_PATH (i think my ld.so.conf is about 8 lines, and i build binaries from scratch alot!), you don't need to worry about your PATH, or *where* include files may or may not be.

And neither do you need to worry about that, if you use his approach. What's your point? Besides, what do you consider "correctly"? Simply doing a "make install" with the often maddenly scattering of files everywhere? rpm or dpkg is nice, but forcing everyone to make rpms for dpkgs for everything is just lame.

Remember, what's why there's a difference between /bin, /usr/bin, and /usr/local/bin. If you have any trouble distinguising between what types of apps/binaries should go where, RTFM!

There are lots of different theories around, among different unix (and linux) vendors, sysadmins, programmers, and so on about what should go in /bin, /usr/bin, /usr/local/bin/, opt/bin, /usr/opt/bin, /sbin, /usr/sbin, /usr/local/sbin, etc... If you think you have the correct solution, you are wrong (as your map does not fit the territory). Case in point: Sun used to put (maybe they still are?) telinit in /etc. Having a system of symlinks also make it easier to add disks, etc...

Personally, whenever I install third-party stuff, I generally put it in /usr/local/store/foo-1.31 with a symlink to /usr/local/store/foo, and then symlinks from /usr/local/store/foo/bin|lib|include]/whatever to /usr/local/[bin|lib|include].

A cuter system we use at work, is to have some shell-functions and aliases for managing PATH, LD_LIBRARY_PATH and so on, to load different packages (different users need different versions of different software packages). The users favourite modules will most of the time be loaded from their shells initialization scripts. The downside is that you need these scripts for every shell (but some shells won't even support it, so basically you need to dictate what shells users can use). Another downside is the added complexity (and need for writing package definition files for each package to work within the system), which this proposal tries to get away from. For a single-user system it makes more sense to use symlinks. Of course, you could also put ~/bin, ~/lib, and ~/include first in the path, and let the users override some symlinks there.

It's not my fault you install everything to /usr/local/foo or /usr/local/baz. The beauty of linux is that it's almost infinitely configurable. Don't take that flexibility away just because most people fuck it up.

Wake up to reality buddy! The proposal is not taking flexibility away. It tidies up the stuff that is currently scattering around everywhere, and makes it more flexible by allowing you to choose which version of what program/package you are running/using, and where you want to put it. It makes things simpler both for users and administrators....

[ Parent ]

You make good points, but... (none / 0) (#191)
by fluxrad on Sat May 10, 2003 at 04:56:00 PM EST

I also wonder about a couple of things in this distro though (which are not covered in the writeup). Things like, what about slices? I don't like keeping / and /usr on the same slice (maintenance and size issues). It looks to me like this sticks you in a "your whole distro on one slice" system since statically linked binaries like mount/fsck/init would necessarily live in the same directory as, for example, gltron. What happens when the disk/filesystem /System/Links/Executables is on takes a dump? Or, if these are all symlinks and everything lives in /Programs, then it sounds like you must have /Programs on the root slice. As a sysad, I don't like that.

The layout seems ok to me for people who want things super-simple. But as I tried to assert in my previous post, I don't think linux should be a remedial OS (e.g. MacOS or Windows) and that's the feel I get from GoboLinux. Call me crazy, but when I see things like this, I just can't help but feel alot of people are switching to linux from windows, then trying to turn linux into windows.

Like I said, I don't see what's so hard about the linux filesystem structure as it is. I'm sure you obviously know the how and why of /sbin over /bin or /usr vs. /usr/local, so I won't go into it. I just wonder why you believe GoboLinux is inherently better?

--
"It is seldom liberty of any kind that is lost all at once."
-David Hume
[ Parent ]
a very late reply (none / 0) (#264)
by joto on Tue May 13, 2003 at 05:26:45 PM EST

I'm sure you obviously know the how and why of /sbin over /bin or /usr vs. /usr/local, so I won't go into it. I just wonder why you believe GoboLinux is inherently better?

I think it is better to to put related packages one place (aka c:\program files), then to spread them all over /usr. But, to make it useable, things should be in your PATH. This can either be done with path-management scripts, or with symlinks. Symlinks makes sense for less than five users, i.e. your typical linux system. Symlinks are intuitive, and easy to find (when you change your system) with tools like "find".

I don't think it's particulary smart to change the names of everything. But at least by doing so, you kind of prove that the new system works. Most people are just not crazy enough to try changing unix in this way.

Unfortunately I am not going to try out his system soon, I've been happy with my debian for 3 years now (after I got bored by changing distro all the time). But I do think that debian could learn from his distro. Hardcoded paths is the root of all evil. Over-reliance on package tools is also evil, although not quite as badly....

[ Parent ]

Amen, brother! (none / 0) (#266)
by LodeRunner on Tue May 13, 2003 at 07:10:59 PM EST

Unfortunately I am not going to try out his system soon, I've been happy with my debian for 3 years now (after I got bored by changing distro all the time). But I do think that debian could learn from his distro. Hardcoded paths is the root of all evil. Over-reliance on package tools is also evil, although not quite as badly....

True! Hardcoded paths are, indeed, evil. And I'm not only saying these because they are bad for GoboLinux, but because they are the sole reason we get tied to any kind of directory hierachy.

And this hinders innovation (not in the "Microsoft" sense of the word) seriously. Look at all those projects I listed in the "Related work" sections of the article. All of them intend to create new free operating systems, based on the Linux kernel. If we lived in a better world with no hardcoded paths anywhere, the same binaries could work in all of these projects -- not to mention in regular Linux distributions --, given that the necessary support libraries are found in the system. In the world we live in, you need one binary of sed for Cosmoe, one for LinuxSTEP, and so on (assuming we don't want to live tied to the legacy symlinks to the rest of our lives).


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

You're pissing me off. (3.00 / 2) (#140)
by ti dave on Sat May 10, 2003 at 06:15:53 AM EST

Don't take that flexibility away just because most people fuck it up.

How in the F*ck is Gobolinux taking anything away from you?

Your solution is simple: USE ANOTHER DISTRIBUTION.

I'd like to put a bullet in your head, Ti_Dave. ~DominantParadigm
[ Parent ]

A perfect example... (4.00 / 1) (#187)
by fluxrad on Sat May 10, 2003 at 04:26:43 PM EST

Window managers. It used to be that you could use any WM you liked without fear of application X not working without any kind of extraneous support structure because they were all linked against a relatively stock set of graphics libraries (say, for example, QT, or GTK).

Now that Gnome and KDE are pretty much the de facto "desktop environments" for 90% of linux users, it becomes signifigantly harder to get an ever increasing number of applications working without having those particular libraries installed. I, myself, use WindowMaker since it's lite, robust, and can be configured to taste. I don't like Gnome of KDE (using any WM) becuause, IMNSHO, they're bloatware. However, a huge number of applications I run require Gnome widget libraries and whatnot just to draw a fscking window. I don't consider that flexible.

The problem is the same. Something that was once an option has a very annoying tendency to become a necessity, leading Linux down the path of a "user-friendly" desktop OS, which I honestly do not believe Linus ever intended.

But hey, as long as you're into fixing the symptom, and not the problem...

--
"It is seldom liberty of any kind that is lost all at once."
-David Hume
[ Parent ]
Well then, the scene's dead... (none / 0) (#192)
by ti dave on Sat May 10, 2003 at 05:02:41 PM EST

If Linux is now the choice of Soccer Moms everywhere, perhaps you should consider
taking up a newer, bleeding-edge OS?

I'd like to put a bullet in your head, Ti_Dave. ~DominantParadigm
[ Parent ]

You're pissing me off (4.50 / 2) (#196)
by fluxrad on Sat May 10, 2003 at 05:24:13 PM EST

Now you're just trolling for dollars.

--
"It is seldom liberty of any kind that is lost all at once."
-David Hume
[ Parent ]
Hey now! (none / 0) (#206)
by ti dave on Sat May 10, 2003 at 08:50:00 PM EST

I meant what I wrote.
I can't help it if some people don't have the stomach for the truth.

I'd like to put a bullet in your head, Ti_Dave. ~DominantParadigm
[ Parent ]

You EUNUCHS weenies piss me off (1.46 / 15) (#117)
by butfuk on Sat May 10, 2003 at 02:55:05 AM EST

...with your petty little issues, and all


     
Unix and C are the ultimate computer viruses.
Seriously, you guys, (3.66 / 3) (#227)
by butfuk on Sun May 11, 2003 at 05:36:24 AM EST

way too many nerds here...


     
Unix and C are the ultimate computer viruses.
[ Parent ]
Eeeeexssselent (3.60 / 5) (#123)
by bugmaster on Sat May 10, 2003 at 04:15:30 AM EST

Finally, something that makes sense. As a regular user, who has virtually none of those guru skills, I really like your new system.

I was actually raised on DOS, and I always liked how simple it was. There were a couple of config files (autoexec.bat, config.sys) that the OS kept track of, and everything else was the province of the user. You could install your programs wherever you wanted, and their configuration files (if any) were usually in the same directory as the program. This meant that if you were looking for program foo, you would just search for the "foo" directory in Norton, and you would find everything you want. And uninstalling a program was as simple as deleting the directory.

Contrast this with Windows, where programs put random files into Windows\System32 and the configuration settings are kept in some kind of a twisted binary file called "the registry". Now you never know how to do anything that the system does not automate for you. Want to uninstall a program ? Well then you better hope the uninstaller works.

And on *nix, the situation is actually the worst of both worlds. Not only do we have hardcoded directory names, but we also have this /etc directory with all the config files in it, which are usually named something like "xzpwtrfg.x11.conf". There isn't even a registry editor... It's just you and your trusty emacs. And there is no single Windows\System32 directory, either: now we have /usr/bin, /usr/local/bin, /usr/sbin, /sbin, /wherethehellami/bin, etc. Where are your files ? No one knows.

Anyway, if you can really get GoboLinux to work with most of the applications out there, it would be a big step forward -- for the users of the shell first and foremost, since in the shell there is no pretty UI to cover up illogical directory structures.

In conclusion... w00t ! :-)
>|<*:=

DOS (none / 0) (#243)
by Cro Magnon on Mon May 12, 2003 at 11:48:48 AM EST

I agree with you about the simplicity of DOS. Back when I used DOS, I felt like I was in charge. When I switched to Windows, I felt like I was fighting the system. With *nix, I'm sorta in charge, but the directory structure IS very complex. I'm not sure WHAT I think about GoboLinux.
Information wants to be beer.
[ Parent ]
Libraries (4.00 / 2) (#124)
by squigly on Sat May 10, 2003 at 04:18:41 AM EST

Far too many times have I had the problem of needing to upgrade countless packages to get an application to work when using source.  Other times, I've found that I need two different version of the same library (I've since learned not to try to use Redhat packages in SuSE).

But this isn't the only problem.  Sometimes we have a whole tree of dependencies, and no way of knowing exactly what we need to install to get an app to work.

So, how does GoboLinux handle libraries and dependencies?

Libraries and dependencies (none / 0) (#173)
by LodeRunner on Sat May 10, 2003 at 02:14:20 PM EST

So, how does GoboLinux handle libraries and dependencies?

Libraries

It's trivial to keep two versions of a library in the system. It's just a matter of not uninstalling the first one when you add the second. You'll have something like:

/Programs/LibFoo/0.92/lib/libfoo.so.0
/Programs/LibFoo/1.33/lib/libfoo.so.1

Both libraries will appear at the proper places. As we all know, it is the job of the libfoo authors to bump the .so number whenever the API changes, and the job of the application writers to link to the correct version (instead of just libfoo.so). Assuming the app and library authors got it right, things will work like they should.

As an example, at one time I had something like this in my system:

/Programs/GCC/2.95.3/lib/libstdc++.so.5
/Programs/GCC/3.2.1/lib/libstdc++.so.6

It worked like a charm.

Dependencies

I answered this in this other K5 thread, here.


---
"dude, you can't even spell your own name" -- Lode Runner
[ Parent ]

Dependencies (none / 0) (#176)
by lmb on Sat May 10, 2003 at 02:23:39 PM EST

Far too many times have I had the problem of needing to upgrade countless packages to get an application to work when using source. Other times, I've found that I need two different version of the same library (I've since learned not to try to use Redhat packages in SuSE).

As pointed out in the article, you can keep different versions of the same library installed on your system. When we switched to GCC 3.x (which is not binary-compatible with older versions) it was possible to keep the new and the old GCCs living together, with programs and libraries compiled with both versions working flawlessly.

But this isn't the only problem. Sometimes we have a whole tree of dependencies, and no way of knowing exactly what we need to install to get an app to work.

The current dependency system is simple yet effective (certainly it can be improved, but is very satisfactory for me). Every package has a '.dependencies' file which lists its dependencies (this file is created automatically). The InstallPackage script automatically checks for dependencies and install the necessary packages if they are available.

You may also want to check this thread for a more detailed description of the dependencies management in GoboLinux.
-- Leandro Motta Barros
[ Parent ]

great (1.57 / 7) (#127)
by Angelic Upstart on Sat May 10, 2003 at 04:33:22 AM EST

great idea!

My email exchange with Adam Scheinberg... (3.75 / 4) (#131)
by swifty on Sat May 10, 2003 at 05:21:28 AM EST

...the author of the article linked to in the other site's story.

"This was thinly veiled satire, right? You were flaunting Mac OS X in all of the other distro's faces, right?

Human readable dir structures: check (as you mentioned)
Drag and drop install: check (.dmg)
Software repository: http://www.versiontracker.com/macosx/
Online community: check (Apple's own discussion boards but countless other sites as well)
Choice: check (aqua, etc.)
Installers: check (packages)
Bloat: check (heh)
Aftermarket addons: check (of course, they're mostly in-house; iTunes, etc)
Defaults: check (system preferences)
FreeBSD: check (Darwin)

I mean.. you didn't deviate from an accurate description of Mac OS X once. Not once."


his reply:

"Thinly veiled? I'm not sure it was so thin ;)"

I mean, really. Just use Mac OS X.

Freiheit ist immer auch die freiheit des anderen.
But OSX is a bloated piece of shit (5.00 / 3) (#136)
by ocelotbob on Sat May 10, 2003 at 05:58:32 AM EST

The difference is the fact that most of the bloat in Linux can be turned off -- the eye candy and such is not mandatory. Apple's method of mountable disk images is incompatible with everyone else; every other OS has sane, sensible loopback filesystem support that doesn't rely on some proprietary solution to get the job done. Besides, Apple's not based on FreeBSD. Yes, it has a lot of userspace utilities borrowed from FreeBSD, but the underlying core is still very much Mach, much the same as Next/OpenSTEP.

I see this as being an imrovement on OS X, as you don't need the overpriced gaudy hardware, and you don't need to drink the Jobs Kool-Aid. This takes many of the improvements of OS X, such as an easy to understand filesystem, and adds the Linux philosophy that the developer doesn't always know best, so it's usually best in the long run to let the user decide how they want to use their system, something that megalomaniac in Cupertino doesn't understand.

Why... in my day, the idea wasn't to have a comfortable sub[missive]...
--soylentdas
[ Parent ]

Well.. (2.50 / 2) (#141)
by swifty on Sat May 10, 2003 at 07:16:35 AM EST

Darwin. Mac OS X without all of the things that make it so hatefully spitefully usable bloated, in x86 to boot (har). "Everyone else, every other OS" blah blah blah. You think J. Hubbard and all the other OS X developers set out to conform with mediocrity? Whining that it isn't the same as this, isn't the same as that wah wah is kind of pointless.. doing it right was probably the idea, not doing it the same. I've heard the Titanium PowerBook G4 be called a lot of things, but gaudy is new.. Oh, and every platform has its share of megalomaniacs, but I won't bite that troll by naming any names.

Freiheit ist immer auch die freiheit des anderen.
[ Parent ]
Mac users get so defensive... (4.50 / 2) (#144)
by ocelotbob on Sat May 10, 2003 at 08:03:43 AM EST

When you point out the flaws of their precious OS. Yes, the TiBook looks decent, but the rest of the line is fugly, plain and simple. Jobs needs to learn about subtletly, something that seems to be missing from the current apple line. As far as doing it right? Ha. I've used the mac interface, and the only thing it seems to excel at getting in my way. I want a system where I can turn things off, where I can redesign the system the way I want to, where I can remap the keyboard shortcuts to the way I like them, where I can do something as simple as change the color and style of the windows without third party hacks.

Darwin is a joke. I've looked into it, it supports such a limited range of hardware as to be useless. All it seems to be is a continuation of Father Jobs Knows Best. Were apple to support a wider range of hardware, I may be willing to give it a spin, but the chipsets and motherboards it supports is downright restrictive. I'm happy running Linux right now, and if I were to go to a BSD, I'd much rather run Hubbard's other system, FreeBSD, as it actually supports the hardware I use and doesn't come with the bloat a microkernel such as mach causes.

Apple is much like MS in many respects; they both want stuff done "Their Way", thus hampering people who have a different idea as to what's usable. Though apple zealots claim that the mac is "Insanely Great", that greatness falls apart pretty quickly. Apple doesn't seem to be able to do the simple things that would make a truly great desktop; why do you have to adapt to apple's workflow, why can't the computer adapt, or be adapted to, your way of working?

Why... in my day, the idea wasn't to have a comfortable sub[missive]...
--soylentdas
[ Parent ]

Heh. (3.00 / 3) (#151)
by swifty on Sat May 10, 2003 at 09:08:37 AM EST

Funny how you're about a dozen times more aggressive in attacking the only reasonably functional desktop unix in existence than I am in defending it. Shrug. Your categorical rejection of Aqua and Apple hardware design is amusing. I would love to see what laptop appeals more to your aesthetic sense than the tibook. But that's all eye of the beholder stuff anyway.

I won't continue this because you've made it glaringly obvious with statements like "turn things off" or "can't change key commands" that you have, at best, tossed a look at OS X in some CompUSA display. It's now obvious that you only responded with the intent of reaffirming your own underinformed opinions, and that is a non-starter for discussion. Have fun devoting further hours to adapting linux to your workflow.

Freiheit ist immer auch die freiheit des anderen.
[ Parent ]

OS X Reasonably functional!? (3.00 / 5) (#152)
by ocelotbob on Sat May 10, 2003 at 09:38:21 AM EST

Once again, bullfucking shit. Yes, if you agree to Jobs' ideals, then it may be functional, but I happen to find that the interface is clunky and ugly. The "lickable" aqua interface makes me want to gag, plain and simple. Plus, it's a resource hog; one can peel away most of the eye candy in a PC interface and still have a functional desktop. Why can't you on a mac?

As far as my OS X experience goes, I haven't used it as much as you have, but I've used it more than just in a compusa display window. I played around with it for several hours, but it got in my way way too often for me to really feel comfortable using the machine -- with Linux desktop environments, I was able to turn off the features within a minute or so of them bothering me; apple's bothersome features seemed to want to persist much longer.

The answer to the laptop question is simple. I'd much rather have a nice, light, compact, subnotebook, like a Toshiba Libretto or Sony Picturebook. Something that can get 7+ hours of battery life and is small enough to fit anywhere. Current subnotebooks are far more stylish than anything apple's put out; they seem to have that subtlety that apple's lacking.

As far as customization goes, I'm pretty much done doing that. I've got a desktop setup that just works, and am quite happy with both the layout and the functionality. The few tweaks I do perform are adjusting a shortcut here and there as my needs and uses change. Plus, I'm not tied to one vendor for my hardware or software -- if my current hardware maker goes under, I can switch with no change in workflow. Can you do the same?

Why... in my day, the idea wasn't to have a comfortable sub[missive]...
--soylentdas
[ Parent ]

Bottom line: (3.33 / 3) (#160)
by swifty on Sat May 10, 2003 at 12:28:45 PM EST

You don't have OS X experience to speak of. Sorry. Declaring that you "can't do this" and "can't do that" so "that's why it's bad" is just silly when you really mean "I don't know how to do this or that." There is no backpedaling allowed after you make declarative statements like those above, so comparing your paltry experience to mine after the fact doesn't cut it. Imagine the raucous, derisive, laughter you would elicit if you ever tried to argue like this in real life.

I'm wondering what this elusive "eye candy" business is that you're talking about. If you mean the three color scheme for window buttons, that can be switched to all greys. Settings like zooming windows, dock effects, etc. are all configurable. Besides, Aqua is OpenGL accelerated anyway. The only thing it pulls resources from is your graphics card, and the only thing you need that for is Quake. Aqua won't be pulling any background cycles to speak of while you're fragging around, because you're probably not going to be resizing finder windows at the same time.. Hell, you don't even have to use Aqua. Login to terminal mode and run KDE or Gnome or whatever else you want on it. Or run them on top of Aqua. Whatever.

Accelerating the GUI through the GPU is a very Good Thing, so good that I hear Longhorn will do the same. That wouldn't surprise me; after all, Apple's hardware and software design is so industry (not ocelotbob) acclaimed that every other vendor falls over itself to keep up every time they bring something new to market. I can think of half a dozen hardware products off the top of my head from pc vendors that were direct imitations of a new Apple product.

Since it's obvious that you have next to no idea what you're talking about regarding OS X, I find it hard to swallow that you can qualify your aversion to Apple hardware as well. It's almost as if you picked up your sense of design at Radio Shack or something. Apple has long had the easiest to work in desktop cases in the industry, period. Every other laptop on the market feels like a fisher price toy compared to any of Apple's, just handle them. Their hardware design is, without question, industry leading. Your preference for a pseudo-PDA is convenient given that Apple doesn't make anything in that form factor, but try comparing a 12" titanium to anything else out there.

If OS X were released for x86 tomorrow it would render linux on the desktop irrelevant overnight. I loved this though: "if my current hardware maker goes under, I can switch with no change in workflow." I take it your workflow includes downloading, compiling, installing/updating drivers for all that hardware, resolving any conflicts, etc. I would love to watch you move your stuff to a new box, then have you watch me do the same. I do it every six months or so anyway and it's so painless that every step is enjoyable. I can toss pci cards, usb devices, firewire, bluetooth, 802.11b, anything at my Mac and it never blinks, and certainly doesn't need me to hold its hand while it figures out which end is up. What hoops do you jump through to boot off of a firewire drive? Attach a USB bluetooth adapter? Install a 802.11g card? With OS X there are no hoops. Plug it in, turn the machine on, and it's there. Oh, and as far as being shackled to one "volatile" vendor.. don't make me laugh.

Freiheit ist immer auch die freiheit des anderen.
[ Parent ]

Aqua still sucks (3.50 / 2) (#179)
by ocelotbob on Sat May 10, 2003 at 02:38:37 PM EST

My point is that on lower-end machines without opengl, aqua's a hog, plain and simple. Yes, on high-end machines it can perform tricks to offload the bloat, but the bloat is still there. Wouldn't it be nicer just to be able to shut off the rendering altogether? And I was talking about still viable old machines, like P200s and the like. They work great under Linux. Can your PPC 200 run OS X at all without third party hacks?

I can think of half a dozen hardware products off the top of my head from pc vendors that were direct imitations of a new Apple product.

It goes both ways, really. USB was invented by intel. Backlit keyboards, something that apple fanboys were drooling over when Jobs launched the new Tibook have been available for years on ruggedized PC-based laptops. Tit for tat is the name of the hardware game. Everyone steals from everyone.

Apple has long had the easiest to work in desktop cases in the industry, period.

The case I've got will probably last until the ATX platform is obsolete. It's a damn good antec, insanely easy to work in, space for lots of drives, screw the new drive on the rails, slide them in, done. No messing with screws in the cramped quarters of a case. Yeah, if you compare to the cheap taiwanese cases apples are good, but you get a good case from a quality maker, PC cases are damn nice to work in as well.

Besides, the entire case design field is perpetuating the myth that cases need to be flashy. I'd love computer case design to take a page from older "state of the art" hardware. For a while, automated record changers were designed to look like a piece of fine furniture; they blended in, they were subtle. Apple seems to be at the forefront of perpetuating the shiny, sparkly case design trend which dates itself entirely too quickly.

Their hardware design is, without question, industry leading. Your preference for a pseudo-PDA is convenient given that Apple doesn't make anything in that form factor, but try comparing a 12" titanium to anything else out there.

You're dodging the issue. A typical modern subnotebook has more than enough processor power to run any modern PC-based app, yet is quite small. I've used laptops and subnotebooks, and honestly, for day-to day usage, the laptop's advantages are pretty much nonexistent.

I take it your workflow includes downloading, compiling, installing/updating drivers for all that hardware, resolving any conflicts, etc. I would love to watch you move your stuff to a new box, then have you watch me do the same.

Easy enough to do. Most modern Linux distros have hardware auto-detection. Plug and play type stuff. Bluetooth support's been around for a good while now, and vendors are starting to provide Linux drivers for 802.11g hardware; 802.11b already works fairly well. Though usually, a complete system upgrade is not needed. I can plug in a replacement part for the underperforming one and be on my way. Why the hell do you need to upgrade every 6 months anyways? Surely if you've got a good desktop system it should stay stable and usable for longer than 6 months.

Why... in my day, the idea wasn't to have a comfortable sub[missive]...
--soylentdas
[ Parent ]

Um.. I just said that you can. (5.00 / 1) (#185)
by swifty on Sat May 10, 2003 at 03:47:10 PM EST

Read my previous post again. If you knew enough about OS X to have such strong opinions on it you would know that you don't have to use Aqua. Boot into the CLI, or "terminal mode" as it's called, then run KDE or Gnome or whatever your heart desires instead of Aqua.

Interesting that your threshold for "high end" is a 32mb AGP card. That's bare minimum low end by anything's standards today. Talking about low end machine viability in a discussion about the best possible modern operating system is facetious. I suspect you would find it ridiculous if I complained that there was no hardware support for my old Macintosh SEs in this new wunderdistro. Besides, if I had an old 603e/200 machine lying around Mac OS 9 would do the trick just fine. As I recall this is all about making a linux distro that is more human-usable on the desktop. So let's keep the discussion to boxen that you would actually be caught dead using as your primary machine, eh?

As far as USB goes, if you recall Intel didn't develop it, they bought it, and it was the iMac that brought that technology fully into the mainstream partly by throwing out any legacy alternatives for it. I'll concede that everyone takes ideas from everyone, but there isn't another company that sets trends like Apple does. Flat panels.. FireWire.. translucent plastics.. All in one designs..

I upgrade every six months because it's cheaper in the long run to drop about $300 (on the price difference between what I pay for a new machine and what I get for my old one) every six months then it is to drop $1500 every two years to keep up with the latest and greatest. Migrating software is bonehead easy in Mac OS X, and migrating hardware is even easier from one G4 tower to the next. Only a PC user could talk about hard drive rails like they're not utterly standard fare. Hell, the earliest mac I can think of with hard drive rails was the Mac II, the SEs' replacement back in the eighties. Nowadays I can fold out my motherboard from my G4 with one finger in two seconds. That basic case design has been around since the first post-iMac G3 towers and has yet to be as effectively adopted by any ATX folks. The closest I've seen is a door on the side of a Thermaltake, but that still forces you to reach inside your computer to mess with anything. It's pretty obvious that you've never had the opportunity to actually work with an Apple case before, or you wouldn't be touting an Antec case as something easy to work in. Just because you don't cut your hands in it doesn't mean it's not a dinosaur.

Please, spare me the novel concept that linux plug and play is anywhere near as functional as it is in Mac OS X. I've never so much as clicked a dialog away when adding a newer video card, usb sound input converter, five button mouse, usb joystick, firewire hard drive, bluetooth adapter, 802.11b adapter, serial ATA card, or a DVD burner to my G4. If you can look anyone straight in the eye and say you accomplished that with an out of the box linux distro then you're pathological. Oh and yes, those were upgrades to replace underperforming parts in my machine.

I'm not even going to comment on the idea that a larger screen on a laptop is a nonexistent advantange. Anything I say to that will only detract from its purity of absurdity.

Another note. You've mentioned third party hacks a couple times now as if they're some kind of bad thing. How is every single piece of Linux ever made not a "third party hack"? Somehow it's ok for linux to require 8,000 different distros to accomplish everything that it can(t), but if Mac OS X needs one modification (in this case to run on old hardware) it's a "third party hack."

Freiheit ist immer auch die freiheit des anderen.
[ Parent ]

Disagree (5.00 / 1) (#197)
by ocelotbob on Sat May 10, 2003 at 05:38:41 PM EST

If you knew enough about OS X to have such strong opinions on it you would know that you don't have to use Aqua. Boot into the CLI, or "terminal mode" as it's called, then run KDE or Gnome or whatever your heart desires instead of Aqua.

Then why run OS X at all? The reports I've seen show Darwin to be slower than Linux/FreeBSD on the same hardware. By sticking with OS X no matter what, you're not giving yourself the best performance from your machine.

The closest I've seen is a door on the side of a Thermaltake, but that still forces you to reach inside your computer to mess with anything.

I've worked with apple cases, and it's not that much more difficult working in a PC case. Given that the PC case I have has several more expansion bays for things like CD-Rom drives and hard disks, I'd say that the PC is much nicer to work in.

but there isn't another company that sets trends like Apple does. Flat panels.. FireWire.. translucent plastics.. All in one designs..

Flat panels made it not because of Apple, but because they had finally gotten inexpensive enough for the consumer to afford it. Were apple to stuck with CRTs, the display market would be little different today. All in one designs were a flash in the pan; a few no-name makers put them out, but by and large, the big names kept with keeping the parts as discreet components. Yes, translucent plastics is a bit longer lasting fad, but it's just that, a fad. Most case makers are going back to more traditional cases, or moving to brushed metal, because people are realizing that their nice translucent case will start to look ugly after a short while as the plastic ages. Plus, there are technologies and standards that Apple's missed on until much later, such as DDR, or what I feel is their current mistake of not offering 802.11a.

It's pretty obvious that you've never had the opportunity to actually work with an Apple case before, or you wouldn't be touting an Antec case as something easy to work in. Just because you don't cut your hands in it doesn't mean it's not a dinosaur.

I think you misunderstood me. I'm talking about rails for drives like CD-Roms, not hard drives. you screw the drive onto the rails, pop off the faceplace, slide in the drive and you're done. I know it's easy to migrate hard drives, what about your CD burner or your DVD drive?

Though Linux may not have the plug and Play feel the mac does, I happen to prefer Linux's system better. Verify that yes, this is what it sees. Give the user a chance to make changes before something goes wrong. Autodetection doesn't always work, giving the user a chance to fix things could be nothing but a good thing. Matter of personal preference I guess.

I'm not even going to comment on the idea that a larger screen on a laptop is a nonexistent advantange. Anything I say to that will only detract from its purity of absurdity.

For me, a bit larger screen is not that much of an advantage. By and large, my uses are easy. Surfing the web, some light game playing, and an occasional movie. A 10" screen is more than large enough for such needs.

Somehow it's ok for linux to require 8,000 different distros to accomplish everything that it can(t), but if Mac OS X needs one modification (in this case to run on old hardware) it's a "third party hack."

Installing on older hardware should Just Work. It's the big reason that while I think Mandrake's a good distro, it's lacking in legacy support. Nearly every other distro has no problem installing on older hardware. Additionally, the third party hacks which enable use of non-apple or legacy hardware invalidate any support with Apple, thus causing trouble if something does go wrong. Linux vendors, on the other hand, will support damn near anything, regardless of who makes it and how long ago it was made. Additionally, the distros allow people to concentrate on one aspect of Linux, providing just firewalling, for example, without having to worry about the bloat or security implications of extra software. Different people have different needs, and distros allows people to focus on just that which they want to deal with.

Why... in my day, the idea wasn't to have a comfortable sub[missive]...
--soylentdas
[ Parent ]

Revenge of the grammar nerd.... (none / 0) (#283)
by r0b on Sun May 18, 2003 at 06:49:25 AM EST

It's "Jobs's ideals" not "Jobs' ideals"


..........and he did.
[ Parent ]

UNIX users gets so defensive... (none / 0) (#290)
by thebigmacd on Sat Jun 14, 2003 at 06:21:05 PM EST

when other UNIX users innovate to provide an alternative to what the end-user sees as flawed.

[ Parent ]
iDeas (5.00 / 1) (#161)
by rmn on Sat May 10, 2003 at 12:35:45 PM EST

Might as well say OS X is a copy of Windows 9x (InstallShield, Control Panel, Windows Updates, Windows Blinds, etc.). Or that Windows 9x is a copy of OS/2, or that NT is a copy of VMS. And so on.

Just because you have an idea that someone else has had before, that doesn't mean you're copying the idea. Maybe it's just a pretty obvious idea, that comes across most people's minds sooner or later.

Apple is pretty good at refining existing concepts. Unfortunately, lately, they seem to care so much about how things look that they completely lose track of how things should work. Anyway, most of Apple's "innovation" actually came from other companies' research (such as Xerox and IBM).

Why should I "just use Mac OS", when I can use a system that does everything Mac OS does (and more), that does it faster, and that does it for less money? Especially, why would I pay Apple of all companies (think Microsoft only with a hardware monopoly too) for it? Maybe if I really wanted to run a specific Mac-only program, that would offset the extra cost and the slower hardware. But otherwise, I can't see any advantage in going for an overpriced, underpowered, proprietary system.

You sound like a friend of mine that, whenever he sees a message from someone having problems with his system, replies "man, just buy a Playstation".

He's happy with his Playstation, I'm happy with my Athlon MP. Just because you're happy with the system Apple thinks you should use doesn't mean other people don't prefer a system they can configure to their own taste (and I mean this both in terms of software and hardware). Different people think differently, even if sometimes they have similar ideas.

[ Parent ]

For the record.. (5.00 / 1) (#177)
by swifty on Sat May 10, 2003 at 02:29:01 PM EST

OS X has no installshield, the control panel dates back to system 6, auto software updating to OS 8.6, Kaleidoscope back to OS 8... To say that OS X imitated W9x is pretty egregiously ignorant. Really, you should know your enemy. Anyway, you're reading into this way too much. I was poking fun at the whole sentiment that any of these linux improvements are breaking new ground in some way. The article referenced a column linked to on the other site, I happened to have a short email correspondence with its author lying around, so I thought I'd share the wealth.

I could argue about how Apple has practically been the lone innovator in desktop computing for the past couple of decades, but this really wasn't what I planned on getting into. I just think it's funny that if OS X were available on x86, it would make linux on the desktop look like a pretty useless endeavor. Sure, there would be purist holdouts, but then there are still people writing software for Apple II's.

Freiheit ist immer auch die freiheit des anderen.
[ Parent ]

iNsanity (5.00 / 1) (#188)
by rmn on Sat May 10, 2003 at 04:45:54 PM EST

OS X has no installshield, [...] you should know your enemy.

I didn't say OS X used InstallShield. Nor do I consider Apple (or Microsoft, for that matter) as my "enemy". First, because I really have better things to spend my time on than "IT religion". Second, because I use the three systems (Windows, Linux and Mac) on a more or less regular basis (for different kinds of work). I suggest you read my message again, without the iGlasses.

I could argue about how Apple has practically been the lone innovator in desktop computing for the past couple of decades

I could argue about how Microsoft produces reliable software and how the USA bring peace and freedom to the rest of the world. Some people would listen and nod, some would just laugh uncontrollably. Reality is very abstract, and perception is very flexible.

I just think it's funny that if OS X were available on x86, it would make linux on the desktop look like a pretty useless endeavor.

Then... why doesn't Apple release it? After all, there are more people using Linux than OS X, so why doesn't Apple follow your advice and instantly double (or even triple) their user base?

Fortunately for Apple (and for its shareholders, and for sane Mac users), and despite the occasional crisis of megalomania, Apple's management is smarter than you. Unlike Commodore (remember the Amiga?) they were able to learn from their mistakes, and they were able to acknowledge and adapt to their limitations.

Maybe one day they'll also learn the difference between an adjective and an adverb.

RMN
~~~


[ Parent ]

iNanity (2.00 / 1) (#194)
by swifty on Sat May 10, 2003 at 05:10:09 PM EST

My response: heh! My clarification regarding OS X on x86: I wasn't advocating, I was hypothesizing.

Freiheit ist immer auch die freiheit des anderen.
[ Parent ]
Hm. (3.00 / 1) (#195)
by i on Sat May 10, 2003 at 05:24:11 PM EST

[...] why doesn't Apple release it?

Because Apple is a hardware company?

and we have a contradicton according to our assumptions and the factor theorem

[ Parent ]

Not exactly. (5.00 / 3) (#208)
by rmn on Sat May 10, 2003 at 09:03:05 PM EST

No, Apple has never been a hardware company in the normal sense of the term.

For a long time (during the late 80s, early 90s) they were a "solution" company. They did for DCC (publishing, video editing, etc.) what Sun or IBM do for servers. They're trying to hold on to a part of that market (basically by buying popular software like Shake, RayZ, etc., and discontinuing the Windows / Linux versions), but they were smart enough to find a new niche. One that doesn't rely so much on having cutting-edge hardware (which is hard, and will get harder) and more on spin (which is much easier).

Of course, technology isn't just hardware. But since the IBM and Xerox "idea wells" dried up, Microsoft and Apple (and Linux) have just been copying each other ad nauseum. None of them has had a truly innovative idea in eight or ten years. Seriously, what can you do with a Mac or PC today that you couldn't in 1995? Computers are faster and more powerful, but that's it. Evolution, sure, but innovation, not really.

Nowadays Apple is mainly a "lifestyle" company. They sell an image (like Lacoste or Gucci or Mercedes). Their products are polished, but they're not technically superior to the competition (as they were a decade ago). Most of them aren't even very different, if you look beyond the surface. The same factory that makes $300 Lacoste shirts also makes $10 shirts, and both use exactly the same kind of cotton.

So why doesn't Lacoste (Apple) lower its prices, or release a range of cheaper producs (ex., stand-alone x86 OSX)? Surely, they would increase their market share...?

The problem is, when you have a brand whose main (or, in some cases, only) asset is its "exclusivity", too many sales can actually harm you in the long run. What prestige would a Mercedes have if everybody had one?

Apple's main market is the low-tech upper-middle-class, that buys Macs to read e-mail and to impress their low-tech upper-middle-class friends. Apple know this very well; just look at the "switch" ads. It's a delicate balance, suggesting that PCs are "too complicated" while trying not to call their prospective clients "stupid". Hence the other "think different" ads ("you're not stupid, you're... special").

But no-one with an above average level of technical knowledge will be particularly impressed with a Mac. Just as no-one with a good knowledge of cars will be very impressed with a Mercedes. Sure, they may look nice, and they're not bad cars, but they are extremely overrated. If you use you car as a tool, you'll be better served by a Toyota (or, if you use it as a tool and want to impress your friends, by a Lexus).

But of course, most people who buy Mercedes are driven not by practical thinking but by something closer to religion. Act as if you had faith, and faith shall be given to you. Act as if your Mercedes was the best car in the world and, to you, it will be. Same thing with computers. Some people will always say Apple is the best or Intel is the best or Linux is the best or nVidia is the best or Quake 2 is the best. You can argue with them, but it's a waste of time.

If Apple released an x86 version of OSX I'm sure they would sell a lot of copies (though I suspect most would be to Mac users that are frustrated by the slow hardware and expensive upgrades). But they would lose the "mystique". And in the long run this wouldn't just hurt their profits, it would probably be fatal.

In its day, the Amiga was a very advanced system. Unfortunately, Commodore (and Amiga users) were so busy telling everyone (and - mainly - themselves) how good they were that they didn't notice that everyone around them was catching up, and eventually leaving them behind. They went through a brief stage of denial ("There are no computers with truecolour support, they have been surrounded, they are committing suicide!"), then self-righteous nostalgia ("Multi-tasking? Hah! We had that in 1985!"), before finally dying.

Apple went through more or less the same process. But although some of its more fanatical users are still living in 1992, Apple's management was able to re-invent the company and turn it into something that's both profitable and sustainable. In a way, I guess they were able to innovate where it mattered the most: their heads.


[ Parent ]

I would gladly use OS X (3.33 / 3) (#202)
by kuro5hinatportkardotnet on Sat May 10, 2003 at 07:28:47 PM EST

if it weren't for the $1999.00 dongle.

 

Libertarian is the label used by embarrassed Republicans that long to be open about their greed, drug use and porn collections.
[ Parent ]
Drop the caps (3.33 / 6) (#137)
by diego on Sat May 10, 2003 at 06:01:26 AM EST

I hate to have to hold shift everytime I want to change dir.

This is a dump idea too, there's a reason we have /bin for essential system binaries, /usr/bin for binaries that came with the distribution and /usr/local/bin for locally built binaries (and /usr/share/local/bin for binaries shared across the network.)

share (4.00 / 1) (#143)
by treat on Sat May 10, 2003 at 07:57:55 AM EST

This is a dump idea too, there's a reason we have /bin for essential system binaries, /usr/bin for binaries that came with the distribution and /usr/local/bin for locally built binaries (and /usr/share/local/bin for binaries shared across the network.)

share is for files that are shared between different architectures, which would only be important when binaries are shared across the network in a hetereogenous environment. /usr/share is because NFS-mounting /usr used to be common. /usr/local/share is becaues people still do NFS-mount locally (meaning site) installed software - but I havn't seen someone sharing "share" between architectures in years. Even the smallest amount of effort to maintain it will exceed the cost of the disk.

[ Parent ]

Caps (4.00 / 1) (#169)
by lucasvr on Sat May 10, 2003 at 01:50:52 PM EST

Fortunately, ZSH can handle this very fine. Bash can do that, IIRC. That's just settings one must configure in the bashrc/zshrc. So, using directories with capital letters isn't really annoying on GoboLinux.

[ Parent ]
Keep the caps (4.50 / 2) (#170)
by lmb on Sat May 10, 2003 at 01:54:26 PM EST

I hate to have to hold shift everytime I want to change dir.

Actually you don't have to. By default the GoboLinux shell is configured to make case insensitive completions. So, if you type "cd /p" (even with a lower case 'p') followed by a tab, the shell will expand it to "/Programs" (GoboLinux uses ZSH by default, but this is also possible with Bash).

This is a dump idea too, there's a reason we have /bin for essential system binaries, /usr/bin for binaries that came with the distribution and /usr/local/bin for locally built binaries (and /usr/share/local/bin for binaries shared across the network.)

You are right, but the point is that many Linux users use their computers as stand-alone, non-networked systems. These people keep /bin, /usr/bin and /usr/local/bin in the same partition of a local disk. In these cases the GoboLinux directory structure appear to make much more sense for me.
-- Leandro Motta Barros
[ Parent ]

Directories (4.00 / 1) (#181)
by Toshio on Sat May 10, 2003 at 02:49:03 PM EST

Before I even start countering your point, let me make one point crystal clear: for power users, there is nothing catastrophicaly wrong with unix file system layout as it is now, however, the issue debated here is problem of creating a desktop operating system for users with no or little knowledge of command line and/or operating system philosophies. That said, I would just like to mention, the fact that I was most intrigued with thinking of creating a FreeBSD based distro, not new *BSD fork, but just a distr.

As far as the caps go, I think that it's more natural for me to see directory names starting with caps. As the issue is desktop user, that will only rarely, if ever, touch command line, the point you make about holding shift doesn't hold. It would annoy you, as it would annoy me as well, but nobody is proposing this to become new standard for all *ix deployments.

The same argument as with caps could probably hold for using /bin, /usr/bin, ... path names. It would simply be a little easier to mantain such system. While you explain which path is used for what, the approch itself is probably getting a little outdated. Just imagine developer developing new application that has to check all other applications just to prevent filename clashes. If you stuff all binaries into one general directory, you are begging for trouble these days. At very list (IMNSHO), we should start pushing for /usr/bin/appname-vermin.maj path style, or something alike (one other possibility is /usr/appname-vermin.maj/bin).

The crust of the whole topic is probably that this proposals are meant for desktop users and desktop users only. Other candidates include setup creators and QA people who will need this kind of installation for deployment testing, but nothing more than that. Nobody will force anybody outside these groups to use anything that they don't like. But the fact is, that if we establish a new standard for desktop deployments, we (as in we, the developers) will have to explicitly target desktop or server, which in itself isn't that bad after all.

My €0.02



--- To boldly invent more hot water ---
[ Parent ]
My usual convention (3.00 / 1) (#211)
by astatine on Sat May 10, 2003 at 09:50:30 PM EST

is /usr/local/appname-x.y.z/{bin lib etc}, although I've also worked on large networked installations where there was a /local with packages sorted under it.

Society, they say, exists to safeguard the rights of the individual. If this is so, the primary right of a human being is evidently to live unrealistically.Celia Green
[ Parent ]
RPM etc (4.62 / 8) (#148)
by Julian Morrison on Sat May 10, 2003 at 08:34:42 AM EST

Lots of folks are posting "we have RPM, DPKG etc, why do we need this". Folks, those package managers are an over-engineered solution to an unnecessary problem.

The problem is that *nix apps spew files all across the filesystem, such that without special assistance you'd have to be a total guru to connect a particular file with its purpose or origin.

The overengineered solution has been to keep track of the origin of every file, and have complex scripts for emplacing, removing, and checking to see that installations don't step on one anothers toes. Like all overengineered solutions, it's brittle: if you install without telling the package manager, say from tarball, then you won't be able to revert the install nor detect conflicts applying to it. If your package has been inexpertly constructed, it will erase what it oughtn't or require you to jump through unnecessary hoops beforehand. If your package manager's DB is corrupted, you're toast.

None of these problems occurs if you simply keep together what belongs together.

It's not as easy as that (4.66 / 6) (#190)
by mickwd on Sat May 10, 2003 at 04:52:39 PM EST

You're over-simplifying a very complex issue, while at the same time making simple things more difficult.

It's a complex issue, because all modern operating systems have highly-complex interactions between different components. A good example is componentisation, and the use of shared libraries / DLLs. These are designed to be shared between different programs, for several reasons (e.g. saving on resources such as RAM footprint and disk usage, providing common functionality, avoiding unnecessary duplication (a good source of errors)). Similarly with other resources (icons are one example). Resources such as this must be accesible to a wide range of programs, particularly if you want a "common look-and-feel" between any of those programs.

In addition, the libraries on which other programs depend should be updateable independently of the programs themselves - as far as is possible. For example, if a security vulnerability is found in a particular library, it should be possible to update it without needing to change any of the programs which depend on it. This is only possible to a limited extent - change the shared resource too much, and certain programs will stop working.

"Folks, those package managers are an over-engineered solution to an unnecessary problem."

Using shared resources is used by most modern operating systems (if not all). It brings great advantages, but also added complexity. All operating systems have to deal with this complexity. What about "DLL Hell" in windows ?

"The problem is that *nix apps spew files all across the filesystem, such that without special assistance you'd have to be a total guru to connect a particular file with its purpose or origin."

How is using multiple directories worse than filling a single directory (such as \windows\system32 on Windows) with thousands of files ? How many people know the purpose or origin of all the files in that directory ?

Using something like RPM, you can simply execute "rpm -qif /path/to/a/file" to tell you the package a file is associated with, and what that package is used for. You aren't expected to know this command off by heart - look it up in the online manual page: "man rpm".

"...if you install without telling the package manager, say from tarball, then you won't be able to revert the install nor detect conflicts applying to it."

How is this different from any other operating system ? At least with the package management systems you CAN detect a conflict, or an over-written file.

This is not a problem if you use the /usr/local directory in the way in which it was intended - for installing extra files which are "local" to the system in question. Thus, files installed via the Operating System's package management system, and those installed locally via tarballs, don't over-write each other. Hell, most tarballs install here by default anyway.

"If your package has been inexpertly constructed, it will erase what it oughtn't or require you to jump through unnecessary hoops beforehand."

As will an inexpertly constructed tarball, or any other distribution / installation format.

"If your package manager's DB is corrupted, you're toast."

Well your system's still working, isn't it ? Surely, if your package manager's DB becomes corrupted you're in the same situation as if you'd installed from tarballs in the first place ?

"None of these problems occurs if you simply keep together what belongs together."

If it was that easy, it would have been done by now.

Still, the fact that it is complex is no excuse not to try and improve on what we have now. There are elements of cruftiness which could be improved, I hear good things about what Apple has done with OS X, but I'm not sure whether they've introduced any new problems. But it's good for people to try and improve things, especially when they appreciate the complexities involved.

[ Parent ]

if your solution... (5.00 / 2) (#204)
by dh003i on Sat May 10, 2003 at 08:11:43 PM EST

Is for every program to contain every library that it needs within it's directory, then that's bunk. Shared libraries are still beneficial, for several reasons:
  1. Hard-drive consumption. Some libraries are huge.
  2. RAM consumption. See above.
  3. Load time. See above.
  4. Convenience. Yes, convenience. If you want to update an insecure, poorly performing, or instable library that many programs are using, with shared libs you only have to do this once. If every prog has it's own version of the library, you have to do it many times over, and have to determine which progs use that library.
  5. Consistent behavior. One major advantage of shared libraries is shared behavior.
  6. Compile-options: who knows what poorly performing, unstable, insecure options each different library was compiled with?
Now, if you are arguing that we should make shared libraries more simple, putting them all in one place (with subdirectories), I'll agree there. But if you're going where I think you're going -- take the "simple" solution that OSX and WinXP have taken -- then you're wrong.

Donald Rumpsfeld likes to say that for every human problem, there is a solution that is obvious, clear, and wrong.

Social Security is a pyramid scam.
[ Parent ]

END the heirarchial file system! (4.66 / 3) (#221)
by mcrbids on Sun May 11, 2003 at 03:12:38 AM EST

The problem here is that a file only has one position in the file tree. Yeah, there's symlinks, but they're messy and horrible, and don't guarantee referential integrity.

I suggest a filesystem based on both LOCATION and ATTRIBUTES.

Take a standard *nix file system, then add attributes. Such as

* Library
* Executable
* Config
* Documentation

One should be able to get all Config files with a simple, easy query. Sortof like a "super etc" directory.

How many times have you seen "/usr/local/packagename/etc/configfile.conf"?

What's wrong with /etc/packagename/configfile.conf? Well...

If the "configfile" carried the attribute of "config" and was accessable by a simple query to /proc/files/config/packagename ?

This is more of a relational system than a heirarchial one - for backwards compatability, you'd most definitely have to keep the heirarchial model so that you could still go to /usr/local/Freeradius-0.8.1/etc/raddb.conf and get something meaningful.
I kept looking around for somebody to solve the problem. Then I realized... I am somebody! -Anonymouse
[ Parent ]

Ways to toss heirarchial system? (none / 0) (#255)
by Fen on Mon May 12, 2003 at 07:48:39 PM EST

Always good to throw away old legacy junk, and the fixed heirarchy is one of them. I like to just stick stuff in root to avoid dealing with it.
--Self.
[ Parent ]
Um, this won't help one bit (4.00 / 1) (#267)
by ksandstr on Tue May 13, 2003 at 10:28:27 PM EST

Lots of folks are posting "we have RPM, DPKG etc, why do we need this". Folks, those package managers are an over-engineered solution to an unnecessary problem.
Yeah, in the original MacOS it used to be that programs had separate "code" and "data" forks through some trickery that would be considered utterly perverse today. This way, you didn't have to carry around your bitmaps and other crap in separate files -- just stick 'em in the fork and let the user do what they will with your bastard hybrid pidgin mutt of a binary. Later versions of MacOS introduced an incarnation of shared library support, pluggable system services and whatever else, which eventually led to the same kind of a DLL hell that even today makes even the most fanatical Windows victim cry.

I understand that Apple has given up on this approach in favor of something more Unix-like for MacOS X.

Still, I'm having a hard time understanding your opposition to having a package management system. I mean, the problem of package management is by now one of those for which sufficient solutions can be found with little searching (frex Debian GNU/Linux has ``dpkg'' and ``apt''). I daresay the problem and its associated subproblems are well understood and provably working solutions exist today, so why on earth would you like to try something different, seemingly oblivious to the problems inherent in such an endeavour? It's not like package management systems were too heavy -- I doubt if you're running out of CPU cycles (hell, anything from a 486 upward can easily support dpkg & apt) or disk space by using one!

The problem is that *nix apps spew files all across the filesystem, such that without special assistance you'd have to be a total guru to connect a particular file with its purpose or origin.
Now this kind of an argument just makes me a bit ticked off. Let me give you a point-by-point on why I believe that your comments actually stem from an insufficient understanding on How Things Are Supposed To Work (in a Well-Adjusted Debian Installation [since that's all I know]):
  • The debian package manager, dpkg, doesn't only track files and their origins. It also allows packages to contain pre- and post-installation and -removal scripts, configuration files, init.d scripts and other stuff that you wouldn't have, or would have to reimplement, were you to ditch the concept of "old-style" package management. I believe you'd also have to become a "total guru" on these topics in order to out-do the Debian policy structures and the whole of the Debian package maintainer gang in maintaining the 1990s-style monstrosity you'd eventually inflict upon yourself.
  • Any argument about the package manager's storage formats being "brittle" or "unreliable" due to a technical reason is really just an argument about software being imperfect and buggy. This aspect of software development and maintenance can be controlled, through careful programming practices, peer review and testing. Yet the fact remains that a well-written program will always be more reliable at repetitive, well-defined tasks than a human could ever aspire to being, given that the program is running on remotely sane hardware.
  • If you were to toss the package management, you'll be left with one of two major alternatives and one that's barely worth mentioning:
    • The first is that you'll be sprinkling your system with binary fairy dust from a billion winged little source packages from all over, which makes them a bitch to upgrade or deinstall. This is the real reason why we have package managers today as I see it. This solution has been shown to be if not entirely unworkable, then at least something that you don't want to be doing when it can be automated (unless you get paid by the hour for adminning proprietary UNIXes, of course).
    • The other solution is installing your packages in their own separate little playpens and relying on a link farm manager like GNU Stow to handle symlinking for you. This is actually not unlike using a package manager, though in this case you'll again be left without a sane process for upgrading your packages (unless remove/reinstall counts -- shame about your config files, in that case... unless you're making manual backups).
    • The third, and most absurd, of the alternatives is where you either use a tool to manage your PATH, LD_LIBRARY_PATH etc for you, or do it by hand. Drudge, drudge, drudge, eh? I'll give you a free hint: linear searching is still just O(n). Not to mention that your shell might not appreciate your enormous environment variables.
  • I had several other points too, but I'm too tired to remember them right now.
Also, I'd really like you to further explain why you feel that the problem of package management that you describe is "unnecessary", seeing as I haven't really seen an alternative to dpkg/apt that actually works better.

(oh dear, another ill-structured comment begun in the heat of the moment at 3:00 AM and posted nearly two hours later when I should have been sleeping for the last six. I wonder what I'll reap for sowing this :-)



Fin.
[ Parent ]
Bah, you skip the real important question (1.00 / 6) (#198)
by RyoCokey on Sat May 10, 2003 at 05:54:08 PM EST

Does this properly handle text files? I'm not using an OS that doesn't understand lines are terminated by both a Line Feed and a Carriage Return.



"Seems to me the whole world has lost a basic virute, that of patients." - travlight
I like the idea, but I find one thing very amusing (3.40 / 5) (#203)
by Skid on Sat May 10, 2003 at 07:55:22 PM EST

... all this is basically making Linux use the exact same sort of file system the DOS/Windows worlds uses, in terms of arrangment. Of course, in this day and age you have registry bloat and inconsiderate programs and such, but ideally my Windows box is like this:

Program Files contains Programs and all of their associated files.

Windows/System (or System32 on NT/2k/XP) contains all shared libraries.

Documents and Settings has all user-specific stuff.

It's not that useful for server-level stuff, but for single-user systems I think this arrangment makes sense; the names are easier to remember, and you can more or less place things where you like. Yeah, yeah, "you can put things as you wish under /home" - look, it's MY fucking computer, I'm not sharing it with anyone, if I want to put my MP3s and pr0n under /my/fucking/entertainment/files, that's my right and privledge. The computer should adapt to fit the user, not the user to fit the computer.

Again, all this is at the single-user level - if you're running a server with a hundred people with accounts, the traditional Un*x system makes perfect sense. This is really just another example of the principle that there are very few "fits all sizes" solutions.

"The problem is, there's no shit... people shit, animal shit. You ought to spray everyone with shit as they walk in." - Hob Gadling, The Sandman

be humble (2.66 / 6) (#210)
by loudici on Sat May 10, 2003 at 09:49:03 PM EST

sysadmins have run unix systems for years before the directory structure evolved to where it is now. there are many books and articles you can read to learn why things are the way they are and how they are supposed to be used. assuming that the architecture of the directory structure is wrong when you run into problems, and not asking yourself whether you are doing something wrong sounds like a lack of humility to me.

but then i might be wrong. or so lazy that i read system administration books instead of re-inventing the system.

--
gnothi seauton

I don't know (3.00 / 1) (#247)
by TheModerate on Mon May 12, 2003 at 02:48:34 PM EST

Sys Admins just seem like the lazy type to me. I don't think things are the way they are because of any explicit design, they just take the way things are and then do the least amount possible in changing it when something breaks. That, and they don't like typing a whole lot and have something personal against the shift key.

"What a man has in himself is, then, the chief element in his happiness." -- Schopenhauer
[ Parent ]

Repetitive, but needed, I think (4.75 / 4) (#212)
by abulafia on Sat May 10, 2003 at 09:53:29 PM EST

The odd mess that occupies mental space as the "unix filehierarchy" is a mostly good idea for a particular problem. For instance, the difference between /usr and /usr/local makes perfect sense, and also implies a difference between /lib and /lib/local. Desktop systems are solving a different problem, and I don't have any issue with rethinking the filesystem. I don't like this one, but I won't bother to illustrate why. That's not the point. Server OSes will be ill served by this ill-concieved ideas. Much like OSX, however, a rethink for end users isn't a bad idea. My thought: the problem is that the file system is overly exposed to end users. That's a UI problem, not an organization problem. Apple solved that one OK, so long as you stay in the GUI. Problems creep in when one is the sort of person who uses a command line. I'd suggest symlinks to the old structure begs the question: why bother? More importantly, how do you fix that? I think that without driving a wedge between "administrator" and "user", there isn't a way. So it might make sense to have two distributions. That causes problems, but maybe that's OK.

Ok so I only skimmed it, but still.. (4.50 / 8) (#219)
by ph317 on Sun May 11, 2003 at 01:25:28 AM EST


I think there's something you fail to understand in the unix mindset here, about why things are the way they are.

Pathnames are for software, for engineers, for programmers, etc.  They have to make some human sense, in the same way variable names in C should.  However, just like those variable names, they aren't there for Joe Blow to make sense of, they're part of some internal workings that only computer scientists ever look at.

Unix was designed to be this way.  It was designed by programmers for programmers, to be a back-end system that ran things, not your grandmother's desktop OS of choice.

I would suspect that if you follow the design philosophy to it's natural end and desire to put an end-user experience on the front of it, the correct path is not to make the filesystem normal-human-friendly.  Harking back to the C variable names analogy .... the end user of the C program in question gets a nice human interface that has nothing to do with C variable names, and so should your desktop OS user.

The unix filesystem should remain the way it is, and if true end-users want *nix at the core, or you want to give it to them - then you should just build an abstraction layer on top, in your desktop environment and user apps, rather than change the underlying machinery.

A web and mail station built on linux, for example, never has to show the user a single peice of any unix pathname, they never have to know about the heirarchichal directory structure and it's arcane names and meanings.  They just have to read their mail in a nice-exchange-looking interface and browse the web and save files onto some desktop space.  Why do they care whether when they clicked the "Browse the Web" button in their desktop environment whether mozilla was launched from /usr/bin/mozilla or /Actions/WebBrowser, which is a softlink to /Programs/Mozilla?

You might make the case that I explore only two extremes - the true end user and the computer scientist... and that there's some middle ground of people who want to dig in their filesystem and still want it to look pretty... and you might be right, but I just say screw 'em, they can learn unix the way it was meant to be, maybe they'll get a moment of zen enlightenment from the process.

I totally agree with you.. (4.00 / 1) (#228)
by stpap on Sun May 11, 2003 at 11:25:56 AM EST

"Why do they care whether when they clicked the "Browse the Web" button in their desktop environment whether mozilla was launched from /usr/bin/mozilla or /Actions/WebBrowser, which is a softlink to /Programs/Mozilla?" --Answer: They don't.
I think this sentence says it all. I believe the real problem is the  exposure of the end user to the filesystem tree. It happens all too often with both GNOME and KDE and it should not be the case. But this is a seperate problem which can be effectively dealt with, without changing the way the Unix directory tree is structured. It is an interesting experiment to do things this way just so that you expose hard coded paths in applications but I don't see any other real benefit.

[ Parent ]
Oh, shut up. (none / 0) (#235)
by erp6502 on Sun May 11, 2003 at 06:42:16 PM EST

I'd like to set you down in the middle of a 256kW 11/45 running 6th edition and see you "learn Unix the way it was meant to be".


[ Parent ]
Oh, shut up (5.00 / 1) (#242)
by ph317 on Mon May 12, 2003 at 11:11:51 AM EST


I'd like to set you down in the middle of a crcuit board with a soldering iron and have you build one.  One-upmanship on how retro you can be is pretty fucking lame.

[ Parent ]
Complications for a UNIX mindset... (none / 0) (#276)
by Gooba42 on Thu May 15, 2003 at 04:48:51 PM EST

The home PC is foreign territory from a UNIX perspective. It was designed for a very clear delineation between Administrator and User. UNIX on the desktop only became an issue when Grandma became her own Admin.

It's elegant for an Admin because everything is in a fairly predictable location, Libraries in
[something]/lib, binaries in [something]/bin. It was elegant for a "pure" User because they never care where a binary or a library was because it would just work, due in no small portion to the Admin's work.

Now we have users who are also admins, so they care where the libs, bins and confs are but they also aren't prepared with an Admin's experience or knowledge. I think GoboLinux has come to a reasonable compromise for this relatively new Admin/User hybrid.

[ Parent ]

Nice comment (none / 0) (#292)
by 5s for Everyone on Fri Nov 14, 2003 at 06:50:39 PM EST

I would mod you up, but this story is old and people are expecting to see 5s, not 3s. So instead I will give you a reply. I hope you liked it.
--
There is Damezumari in the Bamboo Joint
[ Parent ]
Tradition simply for the sake of tradition... ? (4.00 / 5) (#230)
by purphse on Sun May 11, 2003 at 01:24:22 PM EST

I think all the die-hard *nix sysadmins missed the point of the article.

The arguments against the re-design seem a bit childish to me. The "well, it's always been done that way", or "damn them idiot end-users to hell!" is a tired and elitist approach that doesn't help anyone.

It's not the particular distribution which defines the role of the system, it's the applications installed therein. Other than BSD, most of the latest distro's are clearly aiming their releases at the desktop market (have you seen an installer lately?) with their pre-defined application templates, 3-4 security "options", and their breadcrumb GUI's.

The Unix directory tree IS antiquated. It appeals to me because so few people understand it and it keeps me in a job. But in the desktop O/S market it's preposterous to assume that joe (or jane) regular-user is going to read the amount of material it has taken me to understand the directory structure and it's uses.

I realize that there are security implications of a well-known directory tree but any reputable administrator knows that it is process and diligence that works regardless of how the system is designed (especially if you work with Windows).

I would love to see Linux distro's on more end-user desktops, this is just one more step in that direction.

p.
the price of defiance (3.00 / 1) (#231)
by dh003i on Sun May 11, 2003 at 01:54:29 PM EST

Breaking with a standard or ubiquitous thing is only worth it if it gains you an increase of 100% in useability.

Social Security is a pyramid scam.
[ Parent ]

Not really... (none / 0) (#232)
by purphse on Sun May 11, 2003 at 02:26:46 PM EST

That's a little too "all or nothing" for me.

It's like saying that software should ONLY be released once the bugs are all worked out.

;)

p.
[ Parent ]
well, the idea is (none / 0) (#240)
by dh003i on Sun May 11, 2003 at 10:13:00 PM EST

That by changing any stanard that has become "the user model" you are making things harder for the user, even if your new way of doing things really is better (as measured by user-testing on completely new computer users). See Joel on Software. For example, maybe doing Alt+=> or Alt+<= isn't the best way to navigate back and forward through web-pages...but if you do something different, you're confusing people alot.

Social Security is a pyramid scam.
[ Parent ]

What a non issue. (1.75 / 12) (#237)
by FieryTaco on Sun May 11, 2003 at 07:10:20 PM EST

This whole article is dumb. The locations of non-user files on the disk are irrelevant to users. They want to know where they saved their report, their budget, their music or their porn. They don't really give a shit where libz.so, libX.so, libXm.so, libVIS.7.65.so are. Coming up with new and fancy names for non-user file repositories doesn't solve any problems. If a user is encountering a difficulty with a library not being found it doesn't matter if it's missing from /usr/lib or from /Libraries, because what matters is that it's missing. A new file system layout isn't the solution to, well, anything. It's just not relevant to the user experience.

Keep in mind that it's not really important to a user where their files actually are on the disk. What matters is where they perceive the are. You see, the idea of putting something in an actual on-disk directory called /MyGroovyShit isn't any different from putting it in /user-files/876ABCCedd_222.grp/usr/bigfiles/userABCDEFF/ and then telling the user it is in /MyGroovyShit.

Dear Sir, (none / 0) (#246)
by TheModerate on Mon May 12, 2003 at 02:41:38 PM EST

Are you not a user? Why do you speak of yourself in the third person?

"What a man has in himself is, then, the chief element in his happiness." -- Schopenhauer
[ Parent ]

Disagreed (5.00 / 2) (#253)
by Pedro Picasso on Mon May 12, 2003 at 05:11:43 PM EST

The article isn't dumb. The idea is worthwhile. You make too many assumptions about who users are and what they want.

I am a Linux, Mac OS X, and Windows user. I do have extensive knowledge of computers, but I also like things to be pretty to look at and easy to use and remember.

Coming up with new and fancy names for non-user file repositories would solve some of my problems. It would allow me to remember what I'm doing and how to do it. For example, unless I've done this action many times I won't remember that /etc/fstab is the place to find auto-mounting settings in Linux. Heck, I have done it many times and I still forget. The etc directory is a contributing factor. What the hell does "etc" mean anyway? I can only assume 'et cetera', but that doesn't mean settings files. It means 'whatever else.' How the hell do you even pronounce it? "Et-see?" That's inane.

I understand the need for backwards compatibility and standards. I'm not randing against that. I'm just saying that as an honest to goodness user, having a /Settings directory in place of an /etc directory would clear up some minor but consistent problems for me.

Keep in mind that while not all users are programmers, some of them are. Hell, a lot off them are. And when you make an interface available, it should be made pleasant for those who use it, even if it's a command line.


-the Pedro Picasso

Cult of the Flaky Hardware
[ (sourceCode == freeSpeech) | kakkune.com ]
[ Parent ]
Just one question: (4.50 / 2) (#238)
by avdi on Sun May 11, 2003 at 09:47:13 PM EST

The one major advantage I see of the legacy UNIX arrangement is that I know that I can put /usr/lib, /usr/bin, etc. on a read-only volume; that /etc probably shouldn't be read-only, but if I ever need to back up my essential system settings I can just grab /etc and ignore the rest; and that I can speed things up by putting /var on a separate, fast disk, maybe with a FS honed for fast access to small files, like ResiserFS.

Is this possible with your arrangement?  Or do all my packages now have to be installed on the same, read/write volume?

--
Now leave us, and take your fish with you. - Faramir

Seems feasible... (4.00 / 1) (#262)
by z84976 on Tue May 13, 2003 at 10:56:27 AM EST

Well, it seems to me that people who put the various filesystems on separate physical partitions/disks are generally only doing so because either A) they are running a server or B) they are geeks (or C) we are both). This filesystem seems aimed mostly at Desktop users, that is, those who would have to interact with a filesystem and thus who would notice the improvement in layout. That being said, though, a geek like myself might find himself inclined to put various folders (like /Programs/mysql or something) on its own drive anyway. Who's to say we can't pollute this with random mount points if we want to? Also, since the symlinks to /etc are still there, your backups could seemingly proceed as normal.

I dunno... it all seems a bit cumbersome to me, but I guess if I used it for a bit I'd probably start to like it. I would MUCH rather explain that system to my mother than the current one.

[ Parent ]

This article (2.50 / 2) (#239)
by sdem on Sun May 11, 2003 at 10:04:59 PM EST

Shall be the benchmark against which I shall measure all other articles from now on. Good work, sir!

"the troll band is a cross between mr. rogers neighorhood and riker's island" - tacomacide
Don't let the whining naysayers get you down (5.00 / 1) (#254)
by qon on Mon May 12, 2003 at 05:19:54 PM EST

I have my nits to pick with this filesystem structure, but I'm very glad to see someone taking on this problem in a decent way. The traditional Unix directory structures are the result of decades of ad hoc evolution. It's in dire need of a re-think. We aren't hitting PDP-11s with 300 baud teletypes anymore, right? And we have filename completion, right? So there's no need for the ancient three-letter directories like /usr and /etc. I think it's time to move on.

Many Unix sysadmins will find much to dislike in this new structure. How much this structure has to change to accomodate their legitimate gripes will be interesting. I suspect the illegitimate gripes will be bourne of conservative traditionalism cloaked in pompous pseudo-logical dress. In reality, the Unix directory tree is more or less non-rational, with elaborate shell features and find arguments to bypass the more grotesque problems. Better to nuke the pointless complexity than to engineer around it with elaborate packaging semantics.

Q

Capitalization. (2.00 / 2) (#289)
by Haelo on Thu Jun 12, 2003 at 05:18:48 PM EST

My main gripe with the set-up defined above is the capitalization of everything. There is not any logical reason to it, that I can conjur. All it does is slow down your ability to type in paths, especially if there are lots of sub-directories that have been capitalized as well. I work with people who use Macs all of the time, and doing system maintenence in the directories they create is out of control annoying.
A.
[ Parent ]
Wrong problem. (5.00 / 1) (#256)
by Graymalkin on Mon May 12, 2003 at 08:17:43 PM EST

I don't think the problem with the Unix directory structure is a problem that needs solving. I think what instead needs solving in regards to software management is the interface with the file system. On a single or few user system why exactly do users need to both with the path of ping or XFree86? Developers and administrators might need to know the exact paths of applications but the user by default shouldn't need to mess with the file system. Users, especially new ones, only really need to have directories to put their personal files in and easy access to the applications they need/want to use.

I think Apple's approach is a bit friendly to portability to this than GoboLinux though maybe not the absolute best. The traditional Unix directory hierarchy is maintained but tucked out of view of Most Users©. Unix/Linux apps typically have no need for makefile modification because Darwin maintains the file structure programs expect AND novice users can be trusted to find Safari or Mail when they need to.

Yeah, that's it, sweep the Unixisms under the rug! (5.00 / 1) (#280)
by qon on Fri May 16, 2003 at 02:17:58 PM EST

Apple's approach sucks. Instead of dealing with the complexity of their own beast, they simply hide it behind the Finder by means of an ugly hack. So you get the visible "/Users" dir but it won't show you the invisible "/usr" dir. You get to see both in Terminal though! Very lame.

Q

[ Parent ]

daemontools (5.00 / 2) (#258)
by piranha jpl on Tue May 13, 2003 at 04:37:40 AM EST

Two programs make a lot of sense for this: GNU stow, and DJB's daemontools. Since stow was already mentioned in a rated-5 comment, I'll discuss the latter.

daemontools includes a few utilities that work together, including supervise and related programs. It's a process manager, meaning it starts continuously-running programs on bootup and keeps track of their state. It's a very elegant and easy-to-use abstraction to daemon management, and works a lot better than SysV-style init scripts.

svscan looks for directories in /service. Each directory corresponds to a process managed by supervise. Inside each directory is a script called run. The run script is started automatically, and restarted if it dies. (For this reason, the process must not fork into the "background".)

Here's how this could work in a distribution: If a program is installed into /Programs/QUUXd/0.1, its package may contain a ready-to-use /service directory in /Programs/QUUXd/0.1/service/quuxd. Upon package installation, an installation script, or the user, would simply have to do ln -s ../Programs/QUUXd/0.1/service/quuxd /service. A symlink would be created to the service directory, and the daemon (actually, its run script) would be started nearly immediately. Upon reboot, the daemon would start automatically.

There are many important issues to consider if you're building a system (or distribution) that replaces SysV-init scripts with daemontools. That includes dealing with different runlevels, and a mechanism to start processes in a defined order (perhaps based on a dependency system)--I believe svscan launches all daemons immediately, in its default behavior.



- J.P. Larocque
- Life's not fair, but the root password helps. -- BOFH

svscan (none / 0) (#261)
by z84976 on Tue May 13, 2003 at 10:48:17 AM EST

hehe, not to mention the services typically used with svscan are MUCH simpler to use and more secure than their traditional counterparts (bind!).

[ Parent ]
Down with hierarchies! (3.00 / 1) (#259)
by davidmb on Tue May 13, 2003 at 07:03:28 AM EST

It seems to me that the best approach would be to replace the current hierarchical tree with a relational model.

The command line could use SQL to browse and the GUI would provide whatever view on the files that the user desired.
־‮־

Way too bleeding edge in the near term (4.00 / 2) (#265)
by qon on Tue May 13, 2003 at 05:51:19 PM EST

Better to rationalize the filesystem than to reconceptualize the entire notion of operating system persistence. Think of all the APIs you'd be breaking, and whole new notions of file semantics (assuming you'd even retain the notion of a 'file' in such a scheme). Definitely worth persuing but this is something for the future.

Q

[ Parent ]

PalmOS is based on a database 'filesystem' (nt) (none / 0) (#274)
by codemonkey_uk on Thu May 15, 2003 at 09:13:53 AM EST


---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
Palm has no Unix legacy to honot (nt) (none / 0) (#279)
by qon on Fri May 16, 2003 at 02:02:32 PM EST



[ Parent ]
Oh please. (1.00 / 1) (#268)
by ksandstr on Tue May 13, 2003 at 10:35:36 PM EST

It is my opinion that this sort of innovation mainly comes from insufficient understanding of why things are like they are in your typical Debian GNU/Linux setup, a misdirected malcontent with the way things are right now, or both.

So, this is where I don my "crotchety old geezer" hat and mutter "kyllä routa porsaan kotiin ajaa" in my native tongue, which translates roughly to "the frozen ground will drive the fled pigs back home yet, yessirree.".


Fin.

Nice hat! (none / 0) (#275)
by purephase on Thu May 15, 2003 at 12:15:33 PM EST



[ Parent ]
Justification? (4.00 / 2) (#284)
by flex_fc on Tue May 20, 2003 at 10:01:35 AM EST

Could you say why it is your opinion that the traditional layout is better? I think it is not a matter of one layout being better than the other, more like which layout is best suited to the task at hand. For a desktop system, the GoboLinux layout may be the best because of its simplicity. But for a production server I would recommend the traditional layout using RPM or Debian packages due to established assumptions about the file layout with regard to maintainance by many people. Can anyone give any technical problems with using the GoboLinux layout in prodution? Any comments about the above would be appreciated!

[ Parent ]
So Reactionary! (4.75 / 8) (#273)
by S_hane on Wed May 14, 2003 at 09:26:27 PM EST

LodeRunner provides an interesting article about a new Linux distro that he's been working on. He notes that it's experimental, that it's trying something new.

75% of readers whinge, bitch and moan. "UNIX is like UNIX for a reason". "You obviously don't understand why UNIX is organised the way it is". "Those who don't understand UNIX are doomed to reimplement it. Poorly."

Grow up, guys. What LodeRunner is doing is called "research". He has an idea, he goes and tries it. And, for him at least, he finds the results satisfying.

If you don't like it, you don't have to use it. If you are unsure of the point, or disagree with the philosophy, you don't have to use it.

I won't be using it in the near future - I'm perfectly satisfied with my box the way it is. However, I'm not going to complain ad-infinatum about how perfect UNIX currently is, etc. etc. etc. Because the point is, we don't know how good or bad ANY idea is without actually going out and comparing it against new ideas.

It's possible that GoboLinux will have no net effect on the future of Linux distros. It's also possible that LodeRunner et. al. will discover a large increase in utility from their alternative organisation, be able to demonstrate this to the rest of the Linux community, and improve future versions of Linux for everyone.

So Loderunner, I congratulate you on a fine effort. May many more people start experimenting with their distros.

    -Shane


It doesn't sound that different than /opt (4.00 / 1) (#286)
by drivers on Tue May 20, 2003 at 04:51:08 PM EST

In the HP-UX world, option and add-on packages are installed in /opt. For example you might have /opt/whatever. Under that you'd have ./bin ./man ./lib etc. Then people's login scripts automatically add /opt/*/man to the MANPATH, /opt/*/bin to the PATH, etc. Basically, it replaces /usr/local/bin, but keeping the components that go with one package in its own directory. With /usr/local/bin (as in linux), all the bin, man, lib's of different packages get mixed up. It's kind of annoying actually, that the place I download HP-UX depot (packages) has switch to linux style and installs everything in /usr/local/bin instead of /opt. Gobolinux appears to rename /opt to /Programs and include everything in the /Programs directory whether it is /bin /sbin /usr/bin /usr/sbin or /usr/local/bin or /opt.

But users also want toinstall and manage software? (none / 0) (#291)
by jago25 on Fri Jul 18, 2003 at 01:09:19 PM EST

But users also install and manage software.

The Unix tree rethought: an introduction to GoboLinux | 292 comments (280 topical, 12 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!