Submitted by GoboLinux 014.01 has been released. “We are pleased to introduce GoboLinux 014.01, the new release of GoboLinux, the Linux distribution featuring a rethought file system structure. This release is our first ‘point release’, providing a stability update for our latest major release, GoboLinux 014, which was released three months ago.”
It is one of the nice clean and fantastic distribution. unix file hirarchy may be good for developers but it si PITA for average joe. On other linux distros, i cant figure out where my installation went, how to start newly installed program, or how to remove cleanly any program. Just try to remove konqueror(monopoly!) and see how it breaks KDE.
Gobolinux is more like Mac system. I am pleased with their approach of simplifying my life.
Edited 2008-04-04 15:16 UTC
While I agree with you that Average Joe will not understand (nor care for) the difference between, say /lib and /usr/lib, or get a compleet overview as to where all installed files in a package went on his disk, I fail to see why this is an issue.
Average Joe should not need to know where his installation went, just that it went well. Newly installed programs should just popup in his menu, and his distro’s packagemanagment should cleanly uninstall any program.
A user should only se his /home folder and there he’s free to organize his folders any way he would wish.
And should Joe need to venture out in the unknown FH beyond his /home, give the man a warning: This be the domain of root, become him at your own peril ’cause here be dragons that’ll bork your box.
Thats also a good way to scare people out of learning anything new
If everyone took the “There is no reason for you to know so im not going to teach you, and you shouldnt bother learning” attitude, where would any of us be?
Im pretty good with linux and honestly ive never really understood the difference between /usr/bin, /bin, /usr/local/bin, etc..
I mean, as far as local goes, they are all local arent they? Its not like the other two are on a network drive or something (they probably could be, but then again so could /usr/local/bin).. As far as /usr goes, none of them are related to any specific user, or it would be in the home directory. Why make this pointless distinction between three different versions of bin that no-one seems to have a good answer as to why there are these distinctions at all? The same goes for /usr/lib /lib, and /usr/local/lib, and all the other pointless duplicates…
I love what this distro has done, and its a long overdue clean up of the giant mess that is the standard unix directory layout.
Edited 2008-04-04 18:39 UTC
Here’s where learning by playing with a single Linux box shows its limits. In networks where a server exports filesystems over NFS, /usr/local is used for things that are actually still specific to individual machines. Of course, I’ve actually seen it the other way around, where /usr/local/ was an NFS mount.
What I want to know is what GoboLinux is doing about .so libraries. Drag and drop application installations in Linux frameworks often involve hackery with LD_LIBRARY_PATH and applications being precompiled monoliths, and this is not good when a security fix comes out for something common like say, SSL or gzip. Then, who knows if all the apps are really fixed? You’re no better off than you were with Windows. Give me a mature package manager over that anyday.
I don’t see why LD_LIBRARY_PATH would affect security fixes through library updates. The libraries are still dynamic after all.
As for dynamic linking allowing for security updates. In theory, perhaps. In practice, older versions of libraries and older libraries are usually dumped by the wayside. If your software is linked against the old version, or depends upon an old version of a library or an unmaintained library, then you don’t receive that benefit from dynamic libraries. Besides which, developers often develop their own work-arounds for bugs rather than dealing with getting the bug fixed in the library.
That’s what we call Bad Practice, and maybe it’s done in the closed source world, but we don’t have to. Why would you want a dozen workarounds instead of a single fixed library? That’s practically asking for a higher bug count. Having a drag and drop Applications or Programs folder may seem nice, but really, it’s oriented towards closed source ideas, and it doesn’t do as much for the system as a well-designed package manager can.
I for one want a clean system with as little redundancy as possible, and monolithic applications, even if they are simply all keeping their own compiled copies of .so’s, are just plain bad. Bugfixes and security fixes should be system-wide whenever possible. So, is Gobo solving this issue?
I’m using OSX on my laptop now, and while at first glance it’s easy to see the allure of that /Applications folder, after extended use I am really missing the dependency resolution and efficiency that my Kubuntu desktop has. Yes, there are fink and ports. No, they don’t replace having a package manager integral to the system.
No, dependency-solving package managers are a better idea. For that matter, many system administrators make /tmp and /var partitions for good reasons, and expect applications to use them. See, these conventions aren’t merely old, they are mature and well thought out. Why would an /Applications folder much like the current /opt with symlinks not be sufficient? If you must, make extensions to handle /Applications specially. Make an appfs, even, with hooks to the package manager. Wiping out the old Unix hierarchy is not to be done without thinking it through.
Edited 2008-04-04 23:35 UTC
I have not looked at it lately, just the original release, but I believe they do it with careful symlink magic (a bit like stow).
It can be deeply bewildering to attempt to understand the *nix FSH, especially since each *nix is a little different. Most detractors simply stop trying after a short time and declare the whole thing to be rubbish. This is unfortunate as no replacement system could possibly hope to see adoption if it fails to offer the benefits of the system it hopes to replace. Real admins will laugh at you if you try to tell them your simplifications are harmless.
That said, some kind of rethinking would not be out of order. There is no particular reason why everything has to be the way it is, especially the admittedly arcane names. /usr and /etc are my two favorite examples.
GoboLinux’s approach can work, but not for everybody., (Repeat after me: App bundles are not the answer to all of our problems. If you think that’s crazy then you are already out of touch.) GoboLinux is good because it opens the door to an examination of the original problem, not because it has the ideal solution. For some desktop scenarios their answer is a fine one and I applaud the fact that they *did* it rather than just insist that an existing distribution change.
What you should take away from this post is this: Even if you don’t see it there *is* a sound and logical reason for (almost) everything you see. Modification is *good*; you shouldn’t let anyone tell you that it ought to stay the way it is, but if you just try to throw out what you don’t understand you wont get anywhere useful.
As while I agree that the “average joe” user does not have to know where everything is. The benefit in a FHS like Gobo uses is much more beneficial to the people who have to fix things for those people. System administrators and IT staff would greatly benefit from a simpler, logically structured FHS. Developers would too. As much as people try to argue the traditional Unix FHS is great for developers, 95% of them would most likely disagree. I cant’ tell you how many Windows only developers I’ve known that found the FHS as one of their greatest hurdles in switching to Linux development.
Simple is always better…
If you couldn’t tell me how many Linux only developers that switched to Windows development ’cause they found the Linux FH to be a problem, I’d take that into consideration.
Windows only developers finding great hurdles in switching to linux development, is another case of linux != windows
“And should Joe need to venture out in the unknown FH beyond his /home, give the man a warning: ”
An OS should empower the user, not cripple his rights.
As long as these things are optional I have no problem, but I have a huge problem if any developer thinks his way is better than my way (no matter who is “right” and who is “wrong”) and wants to enforce his way upon me.
This is why I will only agree (and of course favour) on modular solutions, and I will forever disagree on anything that requires the user to stick to the “only true way” of whatever solution upstream developers give you.
Exactly THAT is the big advantage of Linux – you can tweak it to however you want it to have.
This is, by the way, not specific to Gobolinux. This is valid for *every* distribution and to every upstream developer.
Gobolinux is just ahead of most other distributions in the sense that it allows self-contained applications, something which you simply dont get anywhere on a distribution-level. And if people do not realize that self-contained programs are better than spread-over programs, then noone can help them anyway (but with that being said, there are multiple ways to view it, and noone is inherently “wrong” or “right” on it. But my perception is that self-contained apps are much more “right” than the FHS “solution”).
Self-contained apps are like alluring candy; they doom you to rotten teeth, but damn if they don’t look good!
There are serious advantages to having apps spread out and only a single disadvantage (or two, if you prefer to count it that way). The disadvantage is: It’s hard to delete. Secondarily you might say that it’s hard to know whether a given file is needed by a given app.
Even on Mac OS the self contained application is largely mythical. Yes it is *possible*, but rarely does it happen. On Windows you still see it very rarely, usually only for very simple apps. For those crying foul… on your Mac, how many library and framework files get thrown around by your apps? I know some apps have dependencies, like iTunes requiring QuickTime. How self contained is self contained?
One big, nasty problem with self-contained apps: How much of the system is standard? On Windows and Mac you can be *pretty* sure that a vast array of userland libraries are present on all systems. Your self contained app can be installed, use Win32 or Cocoa and be just fine. A truly self contained app operating on a Linux box can assume… what? Libc, most of the time, the kernel, and that’s about it. In order to be sure it can be dropped into any distribution every stand alone app would require a huge portion of the standard userspace libraries to be bundled with it. Common-distribution foundations are a partial answer, and LSB helps a lot, but it’s still unpleasant to contemplate.
The standard solution to the one issue with spread out apps is to allow a package manager to track the files, which mostly works. If adequate solutions could be found to the several problems of self-contained apps then I might consider them seriously, but as of now only one viable answer exists.
http://www.thecodingstudio.com/opensource/linux/screenshots/index.p…
Unless I’m missing something it looks like vanilla kde 3.x.
Exactly. Unlike ubuntu, its default color scheme does not induce vomiting on first site.
Which is remarkable if you consider that underneath is a completely different file system organization and custom packaging system.
I find this filesystem structure exciting since, lets face it, the unix way is a mess.
Compared to what? The windows hierarchy is equally as confusing and nonsensical, IMO. At the end of the day, most users really only care about their docs and apps. Doc management is equal everywhere AFAICT – users litter their desktops with docs until it’s too messy and then they shove them somewhere else, like “Documents and Settings” or “Home.” Apps – yes, app management is kind of gross on linux/unix for the average joe. OS X and PC-BSD are trying to fix this, though – hopefully there will be some serious thought in the linux/unix camps on how to compartmentalize user installed crap from OS installed crap in the future.
Confugulating the FHS does two things, IMO – 1) makes it difficult for people used to the traditional FH to navigate, and 2) makes it difficult for people who become adept at the confugulated method to navigate anything that conforms to the FHS.
EDIT: ah, ok, I see what they’re doing-
“You may have noticed that the Unix paths did not show up in the system root listing in the very first example. They are actually there, but they are concealed from view using the GoboHide kernel extension.”
Interesting…
Edited 2008-04-04 16:18 UTC
From my understanding OSX’s FSH is not too terribly different from the route the Gobo guys have gone. The legacy Unix style FSH that most Linux and BSD distros use today is not beneficial to but .001% of its users. Honestly, the only people who find it preferable are those who have dealt with it so long that it’s just what they’re used to now. As while I don’t find Gobo’s layout 100% perfect it’s much more manageable whether you be a developer, sys admin or average joe user. Having various files scattered about the filesystem for a single app is just awful to manage (and yes many Windows apps do the same exact thing).
It could be that we’re all so used to knowing what is in c:\Windows, Program Files, Documents and Settings, but as much as I dislike Microsoft, this may be one of the things they’ve gotten right (after about a decade of trial and error). But again, Vista has a different folder structure – so I agree that consistency has never been their strength.
But the differences are also based on the fact that since the DOS-days we’ve used drive letters instead of mount points – kind of good, but mostly bad. And unlike *nix distros or other more recent platforms, DOS/Win users were almost expected to just dump files in the c:\ root – bad habits which lead to installers using root to store temp files, install programs (not under \Program Files where they should be), and generally clutter and crappify your drive until you couldn’t find a damn thing. Now that we’re so used to XP, things generally seem to be where they should – but as we all know XP won’t be around forever and you’ll have to figure out Vista’s new layout all over again.
I’m not sure the GP said anything about other OSs having a superior file structure. Vanilla UNIX is better than almost anything else–including Windows–but that doesn’t mean it can’t be seriously improved upon.
Although I’d say that UNIX file structures are simpler and easier to understand than a needlessly restricted and complex lettered scheme like Windows/DOS employs I still have to say that UNIX is still too esoteric for the general user. One shouldn’t need arcane knowledge of a file structure to find and fix simple issues when a package manager, package or script fubars something in your system.
Edited 2008-04-04 17:17 UTC
see! look it has icons and windows! must be easy to use, right?
…but you don’t want to see what it looks like on the inside
The UNIX file system hierarchy is well intended. To increase feelings of comfortability and easiness of use, today more and more well intended concepts are thrown aboard or bypassed. Therefore, I applaud GoboLinux’s basic concept for something “new” and still have toe goal to be compatilbe with the “old”.
While I admit that this is true, any user is welcome to look behind the “secrets” of the file system hierarchy layout. For example, FreeBSD provides a “hier” manpage that explains everything, so you don’t need to guess.
Hmmm… it’s just a question about how you consider such an accident to be a “simple issue”. But in general, I agree here. It’s obvious to add that you need some knowledge about system maintenance even under improved circumstances. The hierarchy concept is one of the important steps to make things easier.
I like GoboLinux’s approach, allthoug I find the uppercase first letters annoying (requiring useless additional keypress); because in the english language, most stuff is written in lowercase anyway (e. g. “system, n.” or “programs, pl.”, the directory entries could have been named /system or /programs. That would’ve been nice. We’re Not In Germany Here! 🙂
Indexing by categories is an interesting approach, too.
But I’d like to ask a question: Traditional UNIX and Linux installations feature multi-purpose directories like /tmp or /var. According to GoboLinux’s idea, every application has an own subtree within /programs, sorry, /Programs; what if /Programs/Gimp wants to store temporary files, but then fails from any reason – how simple is it to remove obsoleted temporary files from tmp/ subdirs within the /programs tree? Or is there a centralized /tmp for every application? (If it was, it would violate the basic idea, but…)
zsh (default shell) comes with mixed case tab completion turned on in gobolinux.
and when your referring to temporary files, your referring to files that should last longer then the next “reboot”, yes?
there is a central tmp dir, under /System/Variable/tmp, and its symlinked to as /tmp. said symlink is hidden by gobohide.
Edited 2008-04-04 23:29 UTC
The zsh is a very powerful CLI, I know. But uppercase letters still look ugly; furthermore, the binary commands (and builtin commands) are usually lowercase, e. g. ls – not Ls, or gimp – not Gimp). Maybe that’s something users can live with.
Basically, yes. In most cases, they should not survive the shutdown of their originator program. 🙂
Ah I see. So it’s easy to clean up if needed. And good for compatibility reasons.
Just for fun, let’s gobohide the / directory because nobody ever uses it. 🙂
given how gobohide works, it should not break anything beyond tabcomplete if my experience is anything to go by.
as for the dir names, its a habit, like many other things in tech life. i guess it can be compared to going from one DE to another.
This should not be a big hindrance. It is relatively easy to fix it (“fix” in the sense that a user can use lowercased letters and the Gobolinux scripts help there)
One bigger problem is how to get people to help out with Gobolinux, because under the hood there are many problems and a lot of work – maybe not so much here specifically, but elsewhere.
Like a lack of manpower, something Ubuntu probably has nothing to complain here.
😉
To me, the *nix filesystems have always been somewhat arcane – we really don’t need to be using three character directory names anymore, so this is a great idea. Does anyone know if this can be implemented easily on other distributions? I’ve installed Sabayon 3.4 for a friend of mine (who knows nothing about Linux), so if I could set this up it would be a life-saver for him. Regardless, this will help greatly for those who can’t navigate through the standard filesystem easily. Beautiful!.. and much cleaner than MacOSX – which is sad. Apple had a chance to tackle the filesystem issue with a clean slate – but instead of simplifying things, they made redundant directories everywhere (seriously, I’ve never seen so many System, Library, etc folders on any other OS – it’s really a mess).
No, unfortunately it won’t be easy to implement on other distros. Although Gobo is not the only distro to try this… The problem is that many apps have hard coded paths, so they will have to be ported to work properly sometimes. Gobo tries to ease this through a hidden “legacy” FSH with links to the new proper placement, but it’s far from perfect…
With that said, I’d love for someone to make a derivative distro focused on good preconfiguration and ease of use, much like Ubuntu does with Debian. As it stands Gobo currently has more in common with the build it yourself distros like Debian and Gentoo.
well there is the option of using gobolinux in a similar manner to autopackage.
the gobolinux filesystem started as a way to manage compiled programs inside a users home dir…
this is now known as goborootless.
Edited 2008-04-04 23:33 UTC
Well, Debian doesn’t have to be a “build it yourself” distro unless you choose to make it so. And even Ubuntu has a minimal installation option (if you download the right installation image).
The default Debian installation installs a “desktop task” that includes a desktop environment plus a set of applications and utilities that the Debian developers think are useful for desktop users. Ubuntu builds on the foundation that has already been built by Debian and fine-tunes it according to their own preferences. You might argue that Ubuntu’s default installation has a better selection of packages but that doesn’t mean that Debian wouldn’t come with a similar set of preselected packages for the ease of use.
Ubuntu also benefits from Debian’s easy package management system, Debian’s large package collection, Debian’s “debconf” preconfiguration system for packages, and Debian’s extensive localization for many languages. Ubuntu fine-tunes these ease of use features according to their own taste and maybe adds bits and pieces here and there but the same ease of use features exist also in Debian, and they already existed in Debian before Ubuntu was started.
But back on topic. I’ve read from some reviews that GoboLinux has a rather limited set of packages and I wonder if the unorthodox filesystem hierarchy causes problems or additional complexities for installing your locally compiled applications? How about installing RPM or DEB packages on GoboLinux, is that easy/possible?
Also, I’d be curious to learn if there are any other advantages, beside the simpler filesystem layout, in using GoboLinux?
to me it’s not having any potential.
Regarding the three char directories — it helps when typing but then, we have a command line completion feature.
The FHS/LSB is good, this one is a drawback. IMHO o course.
Care to explain with logic rather than emotions though why you feel that way? I’m not trying to flame/troll/whatever… I honestly can not see any real logistic benefit to the legacy Unix FSH other than it’s what people have grown accustomed to.
it’;s not really legacy. it’s being thought of for reasons. Throwing overboard those ideas is not a rather good idea.
People who don’t understand much of it won’t bother, just like windows. They use a graphical interface and all will be fine.
People who need to do stuff with it, like administrating will find binaries in places that shouldn’t be there. Unless you think that the reasons of having separate binary paths is not being thought of. Well, if you can’t find the separate paths, let’s just present is as a heap of all stoff.
Finally most of the more serious distributions start using the FHS/LSB setup and now. well, let’s make things ‘easy’. It ‘seems’ easy but people with some administration talents know it’s not. Those who don’t have this talent, don’t *need* it. So what’s the point?
Edited 2008-04-04 16:50 UTC
Way back in 1998 when I first started messing around with Linux, the single biggest obstacle I had to overcome was the arcane file system layout. It took me several non-starts and attempts at using Linux as an OS and not just a plaything before I really grasped it. Fast forward 10 years and I still don’t see why it hasn’t become simpler.
One of the biggest draws to OS X for me was the dead-simple application management. Apart from a few anomalies that use installers, you just drag-and-drop your app — which is actually a container itself — into the Applications folder. Run it from there, and when you are ready to uninstall, just drag it to the trash and be done with it. I know that package management like apt and rpm on Linux are almost as easy, but they both sometimes suffer from dependency issues. I have yet to run across a Mac app that doesn’t already contain every single dependency it needs to run, provided they’re not already part of the OS itself.
Again, I know I’m comparing apples to oranges so to speak; Linux is OSS and free in every sense, whereas OS X is commercial, but it’s also Unix and they seem to be doing things better in my opinion. I salute the GoboLinux team for having the balls to push forward and make life easier on those of us who haven’t been using Linux since 1993 and other Unices before then. Just because you’re comfortable with it doesn’t mean everyone else should have to deal with it. It’s about time someone took advantage of the openness of Linux to make it better for everyone!
As has been stated many times, those ideas where not “thrown overboard”, just re-thought.
Seriously, your criticism of the system has all been said before, and none of it stands up.
I’d suggest you read this: http://gobolinux.org/index.php?page=doc/articles/clueless
I should also point out that Gobo is not a beginners distribution, it is geared towards compiling the software you want on the system you want.
Edited 2008-04-04 18:11 UTC
this file system is supposed to be easier to use but now everything becomes more complicated…it doesn’t seem as if ubuntu can just adopt this system.
i feel the need to ask you to elaborate on that…
“this file system is supposed to be easier to use but now everything becomes more complicated”
What becomes more complicated?
Every program resides in a self-contained directory under /Programs. No exception. What is so hard to understand about that? You dont have to search through /usr /opt /bin or wherever files are spread.
System stuff can be found under /System.
I’d rather would like you to explain why the FHS deemed it worthy to introduce a special exception a few years ago for /usr/X11R6
And the LSB will not solve anything because the LSB *extends* and builds upon the FHS (look at the places for cron files).
I dunno, seems like a great idea to me, and it is compatible with apps still dependent on the traditional unix file system.
It has versioning of applications too. What could be wrong here. I doubt it would get much traction on its own, but it’s certainly an idea another distro could adopt. Ubuntu seems like the perfect candidate as it is supposed to be for humans
Even now with ubuntu, you don’t know where things are installed to… I often resort to going into the menu-editor and seeing what the command line is.
Another one bites the dust. But it’s really an alternative for people who don’t get anything
There is one clear indication that the traditional Unix file system hierachy doesn’t work: the glut of software that is designed to manage it.
Most Macintosh and many Windows applications can be “installed” by decompressing an archive then adding a link to your dock/start menu. Uninstalling is just the inverse. In Unix land though, you usually need some sort of package manager to deal with placing and removing files. Only a tiny minority of software is sufficiently dis-entangled from the system to do otherwise. (Unless you compile it yourself and do what Gobo does.)
To be fair, a package manager of some description is still a good idea. After all, who really wants to keep track of what software depends on what libraries?
So yes, the filesystem is hard to understand, but no, package management is important.
I agree. Package managers first emerged to deal with the mess that is the traditional FSH. But now that they’re here we can see there are many more benefits to them. Easy updating of software is probably the best thing about them, and of course automatic dependency installation as well. As while I love the idea in the simplicity of Gobo (and MacOSX) to not needing a package manager, I’d still like to have one.
Since the tag line the definition of package manager has slid a bit. When GoboLinux was created package managers were software like dpkg and rpm (and still are imo). That type of package management, which uses a database to hold which files go with what package is unecessary on GoboLinux.
There do exist several ways to install packages and calculate dependencies on GoboLinux, much like aptitude (frontend to dpkg) and yum (frontend to rpm) do.
Even if it is easy to mix them, package managers and package installers are not the same thing. The latter may be use by the former; but it is the former that is not needed on GoboLinux – the latter exists.
Ask yourself if you need to save hard drive space and internet bandwidth by preventing small library duplication. If not, maybe stand-alone program directories are a good idea.
Ask yourself if having a confusing system is really better than a not-confusing system, if all else is equal. If the not-confusing system lets more people fix their system, thus reducing their need for professional help, isn’t that a good thing?
Ask yourself how many computers are used under one user login name. Does the system and its applications really need to be designed to accommodate multiple users in a client-server environment first, and then a single-user environment second?
Ask yourself if you really need more than a “OS” directory for your OS, and a “Programs” directory with one directory for each program. Is making things simple really such an alien idea?
As time goes on, technology improves, and old limitations fall away. We don’t need short directory names, we don’t need complex package management tools to manage complex directory structures which manage complex application dependencies to save a few tens of megabytes of disk space.
Is anyone willing to improve upon the past rather than dwell in it? GOBO LINUX IS…
thing is that gobo do not do pr app libs. it still use central libraries.
I don’t think rearranging the filesystem has any good purpose. It’s not like Joe User has a clue about the Windows file system. The other day at a LAN party I was telling some kid how to install mods for Jedi Academy. I asked him where it was installed. “??? On the computer?” was about the best he could come up with. Most people have no clue about where things are installed. That’s what package managers (or the registry) are for.
Further, what does it say when a user navigates to c:\program files or c:\windows? I can’t quote it but it is basically a message telling them they have no business there and are they sure they want to poke around (“you might wreck something!”). Microsoft understands that users don’t belong in the file system.
So most users don’t have a clue where things are in Windows, and Microsoft doesn’t want them messing with the filesystem anyway. So why the huge effort to change things in Linux? Each directory in the FHS has a purpose that is well understood by the people who work with it. Those who don’t understand it shouldn’t need to.
Most windows users have no clue about where programs go. Some few have figured out they can control exactly which directory to install to. It seems to me like some of those users moved to Linux and were frustrated that it doesn’t work that way in *nix (heck, I know I was that way, but I got over it) so they started an effort to junk years of tradition to cater to a small percentage of people who get anal about installing to certain directories in the assumption that most people are that way. I just think it’s really delusional to think that any random user cares where things (outside of his/her documents) go. ~ and ~/Desktop are all that matters (though KDE4/plasma is working to kill the latter wtf)
[i]Just try to remove konqueror(monopoly!)[/url]
apt-get -s remove konqueror
The following packages will be REMOVED:
konq-plugins konqueror konqueror-nsplugins
??
A better organized filesystem structure doesn’t automatically mean it’s to make things easier for new users.
As a technical user, I crave the simplicity and benefits of the GoboSystem.
and one should note that the real reason for the /Programs tree is not to clean up the file system (even if thats a interesting side effect) but to remove the need of a database to track what package holds what files.
i guess any distro user with some experience have run into a corrupted package database at some time or other…
“I just think it’s really delusional to think that any random user cares where things (outside of his/her documents) go.”
Well I care where my stuff is, as do most of the rest of the semi proficient users I know.
You act like Gobo’s file system model caters to some small niche of people but overlook the fact that this is what is used by Windows and OSX (ie. >96% of desktops worldwide).
The biggest and most common misconception I hear people state is “They don’t need to know”.
Many users may be dolts, but those dolts also likely have a clearer picture of the market than you.
Without commenting on whether they should know, I will posit that the vast majority of those 96% of users don’t know. What they do know are the shortcuts and links presented to them on the desktop and in the file selector, and how to click next, next, next, accepting the default folder in InstallShield.
Bring up Explorer. Put them in the root of C:. Tell them to navigate to their pictures. And watch them flounder. Without the usual smoke and mirrors they are helpless.
They’d have a better chance on Linux, where what is usually called “Sally’s Home” on the desktop is in /home/sally.
Edited 2008-04-05 07:35 UTC
Rearranging it could serve a purpose, as long as no harm was done. Is /etc/ really better than e.g. /cfg/ ? The former is arcane, the latter could aid someone in figuring out what the directory is for.
I played with it a little .. my usual test:
-Install and slightly older version (in this case 0.14.0)
-Update it
I couldnt do it. Manager would not work properly and the Freshen script was not installed. I installed Freshen, but it was broke. So i tried “compile Freshen”
and that had a problem with ruby. So I tried compiling a new version of ruby, but that could not fetch the source package.
My take: A mess! Linux like in pre-Debian area. Awfull! If something as simple as getting updates is this complicated for someone who knows a lot of OSes, the distro is not worth it. The docs also stink btw.
Edited 2008-04-05 17:38 UTC
I don’t see why anybody would like to install an old version, when the new version is a stability/bug fix release of the old version.
Also I can’t find the freshen “problem” you experienced. I do find a (misplaced) information message that freshen isn’t installed, which could be interpreted as something was broken.