GoboLinux Compile -- A Scalable Portage?

LodeRunner writes "The GoboLinux team, featured about a year ago for creating a distro that does away with Unix paths such as /usr/bin and /lib and uses things like /System/Settings/X11 instead, just released a new release where they introduce their own alternative to Portage and similar systems: Compile. But is yet another source-based compilation system needed?" Read a bit more below on why the GoboLinux folks think so.

LodeRunner continues "We already have ebuilds, RPM .spec files, and whatnot. The argument for reinventing the wheel yet again was the observation that while developing apps to handle these files is easy, the task of maintaining the ever-growing database of compilation scripts is the real problem -- the huge package collection of Debian comes to mind. Compile took the extreme minimalistic approach, and its scripts ("recipes") are as small as can be: the script for a typical autoconf-based program takes two lines.

Knowledge for handling common situations is usually added to Compile itself instead of being coded in the script (for example, apps that need a separate build directory just add a needs_build_dir=yes line). The plan is to make Compile as smart as it can and the recipes as small as possible.

It remains to be seen whether this experiment of gauging differently the tradeoff between flexibility and simplicity will prove itself to be limiting or enlightening, but in the ~six months Compile has been in beta test by the people from the GoboLinux mailing list, over 500 recipes were written, ranging from Glibc and GCC up to KDE and the Linux kernel itself."

Comments

It works for Gentoo

[Anonymous Coward]

So why the hell not? I think breaking from the posix-style /usr /lib /bin type directories is a bad idea however.

Re:It works for Gentoo

[XO]

Just because you have a Unixish kernel does not mean you have to have a Unixish operating system.

Surprisingly, not everything in the world has to be Unix!

Re:It works for Gentoo

[Mycroft_VIII]

I would tend to agree that breaking the paths would be bad, fourtunately they don't exactly do that.
What they do is provide a more intuitive (on the surface of it, it seems so to me, need more details to be shure) path system while maintaining compatability to the old system.

"In GoboLinux, each program resides in its own directory, such as /Programs/Xorg/6.7.0 and /Programs/KDE/3.2.2. Each file category (executables, libraries, headers) can also be accessed through unified symlink views, such as /System/Links/Libraries and /System/Links/Headers. These views match the legacy directories (/bin, /usr/include, /usr/local/share) and so on, achieving total Unix compatibility while keeping program directories completely self-contained."

They claim thier systems is path agnostic.
this is a good thing imho. One of my (minor) pet peves is that the standard *nix path system is largely cryptic to joe user, and a pain in the butt even for the cluefull unless you have enough *nix experience to make it automatic.
Now if they fix cut and paste and find a way to make havening both a *nix and a windows version as close as possible to a simple recompile with a few options/flags changed the year of linux as a major desktop contender will finally arive istead of forever being next year.

Mycroft

Re:It works for Gentoo

[nagora]

Now if they fix cut and paste

What's wrong with cut and paste? Highlight then middle button (or shift-insert) and you're done is the best cut and paste I've seen so far. Linux is ahead of the game in this area; using Windows drives me nuts with its four-key C&P, especially since Windows makes it hard to map the control key to where the caps-lock is, so every use of it really kicks the old RSI risk up.

Re:It works for Gentoo

[Anonymous Coward]

Quoth the parent: "find a way to make havening"

Is that you, George?

Re:It works for Gentoo

[October_30th]

I for one have always hated the /usr/local directory.

The path is never set for /usr/local/bin by default.

It's like /opt in Sun environment.

Why not just install everything in /usr/bin?

Re:It works for Gentoo

[Zork the Almighty]

But... but... "It's UNIX, I know this!"

Re:It works for Gentoo

[October_30th]

Highlight then middle button (or shift-insert) and you're done is the best cut and paste I've seen so far.

Highlight something, left-click on emacs window, right-click on emacs and... nothing gets pasted because the stupid thing cleared the buffer when you left-clicked on the window in order to bring it into focus.

That drives me nuts.

Re:It works for Gentoo

[cbiffle]

In the case of Gentoo, I treat the file hierarchy as follows:
/ and /usr: managed by Portage. /usr/local: software I can't get through Portage, that I install manually.

Gentoo's file hierarchy is annoyingly loose, in my opinion, but this is common to most Linux distros. (I'm still a big fan of FreeBSD's "/ to boot, /usr for the system, /usr/local for all third-party software" approach.)

However, complaining that you haven't set PATH properly in your .profile is a poor reason to rag on a directory layout. I use ~/.bin for scripts and binary overrides, but since I doubt that's in your PATH, do you hate this too? :-)

Re:It works for Gentoo

[October_30th]

/ and /usr: managed by Portage. /usr/local: software I can't get through Portage, that I install manually.

Fair enough, but what's the advantage?

complaining that you haven't set PATH properly in your .profile is a poor reason to rag on a directory layout.

.bashrc you mean? Setting anything in .profile has never worked for me on any distro. I don't see any reason why I should change my PATH, anyway.

Re:It works for Gentoo

[Richard_J_N]

/usr/local has its uses. It's for packages installed by the user, which have nothing to do with the distro. Eg, my distribution comes with Mozilla. (/usr/bin/mozilla). This is used by eg Galeon, so I don't want to break or uninstall it. However, I do want the latest version of mozilla. The answer is to put it in /usr/local/bin/mozilla. (This is even more important with libraries). Incidentally, Mandrake 10 does have /usr/local/bin in $PATH by default.

Re:It works for Gentoo

[red floyd]

I don't use X, you insensitive clod!

Re:It works for Gentoo

[Mycroft_VIII]

Because a) the behaviour is inconsistant (try cut and paste between several different apps, now try under windows) and everything has it's own cut and paste system almost. It's fine to have other systems available, but you need a consistant method that just works everywhere, or as nearly so as possible.
and b) what you just described is broken for many people. try cut and replace that way.
highlight to copy, then highlight what you want to replace, oh wait that won't work. I used a windows app that had to do it that way because the author hadn't figured out how to work a around a limitation in the programming system he was using. His docs Apologised for the broken behaviour.
And you don't have to use the ctrl key combos to c&p unless your mouse/trackball is dead. just a few mouse button clicks is all.
The highlight to copy thing makes assumptions about the users intentions, in a situation where there are other equally likely reasons to highlight, some of which require the clipboard to NOT be emptied. This is broken by definition.

Mycroft

Re:It works for Gentoo

[Hatta]

It works the same way for gpm

Re:It works for Gentoo

[Doctor Crumb]

Why not just install everything in /usr/bin?
Anything I compile myself goes in /usr/local. This means that when I upgrade my system from scratch, I can easily copy all of those installed things to the new system without having to go through /usr/bin by hand. Even easier if you put /usr/local on its own partition.

Believe it or not, most things in unix are they way they are for a reason. That reason may not be immediately obvious to you, but it still exists.

Re:It works for Gentoo

[Antique Geekmeister]

Question: Why not just install everything in /usr/bin? Answer: Because then you can't manage different versions of the same package, or packages with binaries, libraries, or documentation that has the same filenames. Do you have any *concept* of how many different programs have a program called "check"?

Re:It works for Gentoo

[Geoffreyerffoeg]

I've always wondered if we can replace the Windows NT kernel and loader with Free ones based off Linux or HURD or something...much in the style of ReactOS, but with an MS proprietary operating system, non-kernel DLLs, etc. running over the kernel. Or if the NT kernel can run a fully POSIX operating system. GNU/NT or Windows/Linux, anyone?

Re:It works for Gentoo

[nagora]

I still prefer it with its flaws to the Windows/Mac method. Put simply, I use it the way it was designed much more than I need it to work the way you are proposing. I do mainly use my machine for writing and programming so perhaps when you go outside text c&p it goes awry but it doesn't affect me if it does.

TWW

Re:It works for Gentoo

[nagora]

nothing gets pasted because the stupid thing cleared the buffer when you left-clicked on the window in order to bring it into focus.

That drives me nuts.

It would! I'm glad it doesn't happen on my machine. What WM are you using?

TWW

Re:It works for Gentoo

[mini me]

The advantage is that you can mount /usr/local via NFS. Install the program in the exported filesystem on the file server, and then all the clients automatically get the program installed as well.

Re:It works for Gentoo

[Zirtix]

You don't understand the Linux desktop. There are two main ways to transfer data: using a clipboard buffer, and using the primary selection. Ctrl-X/C and Ctrl-V are for the clipboard, and selecting/middle-clicking are for the primary selection. The two systems are complementary and separate.

There are some applications which just don't use the protocol the same way; but this is becoming quite uncommon since emacs was fixed. There is also a content negotation system for negotiating what types of content can be pasted where, which KDE and Gnome both support.

One remaining difficulty, with Gnome at least, is that when an X client exits, its selections disappear (so you can't copy, close the app and then paste).

For more info see here.

Re:It works for Gentoo

[mini me]

I take that back, I was thinking about it backwards. It's been a long day. /usr is to be mounted on the server, /usr/local is then mounted locally for local packages, hence the name local.

Re:It works for Gentoo

[Anonymous Coward]

What's wrong, mods don't get the Jurassic Park reference? haha good one!

Re:It works for Gentoo

[Mycroft_VIII]

Ever have a vital piece of info destroyed because you accidently hit the delete button.
Ever accidently overwrite a file because you saved with the wrong name and didn't realize it.
This is why I see a problem with silent actions like how the highlight/middle click works.
Not necessarily as disaterous, but it still takes a non obvious assumed action with no feedback.
It good UI design to have clarity of action and response. People make mistakes and click the wrong thing from time to time and the dumping of the clipboard into a document because just a little to much pressure was aplied to the mousewheel while scrolling is plain asking to frustrate the user and bad ui design.
I'll grant that mousewheels that act as a middle button probably didn't exist when this was started, but that still dosen't excuse it still doing that on a single click.
From your last paragraph it seems as though the situation might be improving some. But you can understand my frustration when a recent set of apps (mandrake 9.1 install) couldn't even share TEXT through simple cut/copy and paste. I don't mean obscure apps, I mean a browser, a file manager and a text editor and other apps that SHOULD communicate simple text easily.
One last partial tangent to this. Choice is good when optional, not when forced for everything. To make an analogy try going to a few stores, start with general stores that don't specialize and notice how limited thier selections per item are. Then goto a few specialty stores that cater to people with specific intrests and likely specific knowledge. notice how broad thier selection is and consider how daunting that could be to an outsider.

Mycroft

Re:It works for Gentoo

[MikeFM]

It's obvious to any experienced Unix users that highlighting text copies the text to the buffer. No reason to waste effort by making such minor things overly complex. You can still use the right-click menu in most apps to access additional C&P options. Wasting effort 100% of the time because people make errors 5% of the time is bad design and that is what it'd be to have some sort of confirmation on cutting or pasting.

I cut and paste text between browsers, email, editors, etc all the time with rarely a problem. Certainly less problems than I experience doing the same in Windows. Just try C&P'ing from a DOS box. :P

Re:It works for Gentoo

[Mycroft_VIII]

Except Joe Sixpack isn't an experienced unix user.
I wasn't refering to a confirm dialog, just make it obvious what's going on. Useability through Obscurity is a non-sequiter. An extra step 100% of the time that takes .1 second beats a mess that takes more than 2 seconds to clean up 5% of the time.
I can understand how such a 'feature' wound up in an OS based on the posix standard. It's been around a long time (for Good reason). But computers are no longer the domain of educated specialist, and quirks that devolped for limited resources that an experienced user can adapt to will completly turn Joe off. Now if you just want *nix for the geeks, and see no value in a version for the masses that's fine. I however do see a value in it and am interested in improving it.
And it's not even the minor nit about how that version of c&p works per se. It's the lack of a consistant, dependable, mechanism that Just Works, the same way, everywhere. It's what joe sixpack is used to.
And just because Windows has one break in it's c&p does that somehow invalidate improving what *nix has?
Still it has shown signs of improving, I'll probably be buying a boxed distro with the 2.6 series kernel and newer versions of Gnome and Kde sometime soon and checking out how far things have actually come since I last did so about 6-10 months ago. Don't have the bandwidth out here to d/l a whole distro, even the small ones
My goal here is NOT to disparage *nix, but rather to point out an area I believe needs improvement to make the modern *nix ready for the common desktop, it's very close right now and the main things holding it back seem to be variations on elite-isms and sacred cows.
But really this is a fairly minor thing compared to some of the few BIG problems still remaining.

Mycroft

Re:It works for Gentoo

[MikeFM]

I have no interest in converting the world to Unix. Anyone that can benefit from the tools I help refine then great.. but I'm not going to dumb things down for them. Anyone can learn.. I'm willing to help them.. if they are unwilling then let them suffer for it. I'm not going to sacrifice usabilty by me for usability by others.

Clicking even one extra button takes more than .1 seconds because your mind has to register on what pops up, select the right choice, and then click. Would you also suggest that for every keystroke combination that a dummy 'did you really mean it?' dialog should pop up?

I will agree though that there should be further work on working out the little glitches. Most have been fixed for years now but some still exist and it'd be nice if they didn't. I'd also like to see highlight to copy extended to include non-text.. like in the file manager. Any place you can highlight something that should copy it. I'd also not be against an easy universal way to disable highlight to copy.. for those that don't like it.

My biggest complaint about Linux on the desktop is that it sucks almost as much as Windows or MacOS. Cloning those interfaces is not the way to embrace and extend the desktop concept. You can't win a race by always following. We should concentrate more on enabling faster, better, more flexible access to the information users need rather than on trying to imitate the look and feel of Windows. I still get most of my work done on the command-line and that seems to be the major failing. The power of the command-line needs to find the ease of use of the desktop.

Re:It works for Gentoo

[Mycroft_VIII]

I never meant to imply that useability should be reduced. Other than your good suggestion (being able to turn it off) Another way to 'fix' the highlight issue would be for it to say be moved to highlighting with the middle button to copy and maybe setting paste to be a double middle click or somthing else a bit more consistant and less prone to confusion. The option to change it to suit the user should always be available IMHO.
As far the dialog thing goes, I believe I arleady explained that. A dialog per-se is not always needed, but the fact that somthing other than Just what you see is going on should be communicated to the user, somthing as simple as a little icon somewhere visible, but non intrusive. Perhaps followed by "use middle button to paste a copy of highlighted text in compatable applications" in a status bar or some such. just tossing out ideas here.
Your whole last paragraph is very close to my thinking, the only thing in it I MIGHT quible with is that it comes close to implying just because Microsoft or Apple did it's therfore wrong, but based in part on "We should concentrate more on enabling faster, better, more flexible access to the information users need.." I seriously doubt you've made that mistake. Personaly I think one should evaluate a tactic on it's own merits, not on who else has used it.
As far as dumbing down, far from it. What I'm looking for is a simple streamlined intuitive interface that Joe sixpack can sit down and use, yet a power user can go in and set to exactly his preferences through an equally elegant intuive system. It can be done, it's just not as easy or attractive to many coders as the apps themselves usually are.
I'd like to point out that Joe six-pack has the power to make the big companies sit up a pay attention. If Joe say Linux is how things are going to be, The companies WILL develope for linux, and some of that will be Open source if for no other reason than better Linux makes thier software more attractive to Joe and his wallet. If however Joe goes blithly along with next bug-ridden virus prone drm loaded redmond offering our lives don't get any easier. Joe outnumbers us millions to one.
And to this:
"The power of the command-line needs to find the ease of use of the desktop. "
All I can say amen brother your preaching to choir here.
Anyway I've put a rough draft of some of my thinking from which much of my point of view on this comes from in my journal if you care to check it out. I suspect in broad terms I dissagree you less than it might otherwise seem, just a few details.

Mycroft

Re:It works for Gentoo

[MikeFM]

The ability to change the buttons required to highlight to copy, add icons or dialogs, etc would be fine IMO to make all easy through the UI but I'd leave the default as it is. Individual distros could feel free to change the defaults if they thought it'd please their users.

I think most of what Microsoft and Apple do is bad.. not everything. Microsoft's pie in the sky vision of a db based OS is closer to what I do on my systems and I think closer to what the Linux desktop should be targetting. There should be less concentration on eye candy and more on enabling the user. It's fine to have eye candy, when appropiate, but it shouldn't be more important than the purpose of a computer which is to manage data of all types.

My first suggestion is to make UI oriented tools for working with (or reimplementing) popular command-line tools and creating an easy graphical way to string those tools together. Pipes are powerful and easy to use and IMO well suited to a graphical construction tool. Go ahead and make it easy to create new modules that can be piped together. Make it so these modules can be bound to menu options either on the desktop or even in programs. Make modules that can index, search, and variously access many different types of data from the local filesystem or from the network. A user should be able to create a desktop button that will instantly find all music on their harddrive, eliminate anything that wasn't by X artist, and play the remaining music in the default music playing app. Something like that should be buildable in a couple minutes time for an average user. Three commands: locate '.mp3' '.ogg' | match -artist 'X' | $DEFAULT_MUSIC_APP should be all that needs to be done.. these modules just need made and added to an easy GUI.

In relation, I'd also beef up automatic indexing of data the user uses.. on the local machine and the network. There should be a database kept with important file and network resource data indexed for quick searching.

The user shouldn't have to know what program they are looking for.. they should be able to just select the file, or file type, they want to work with and the associated app(s) should be listed.

Virtual directories listing recently used documents, programs, network resources, etc should exist and be easy to create. This is Unix - take advantage of 'everything is a file' because it'sa powerful concept.

Simple commands with pipes and everything is a file. The Unix way. Why is the desktop not following these key concepts? If only I had time to implement my own desktop. :)

Re:It works for Gentoo

[XO]

Well, I figure that BeOS has a somewhat Unix-like kernel, and was really not so much of a Unix-like operating system. My thought was that it actually took all the bad things about Unix, and combined them with all the bad things from other operating systems. (i've never spent more than a day figuring out the basics of an operating system only to get frustrated and give up.. except with Be.)

So, why couldn't the kernel be mated to a completely different set of software?

GNU already runs on virtually all versions of DOS/Windows...

Re:It works for Gentoo

[Mycroft_VIII]

Can't speak to what apple does. But I will agree that alot of what Microsoft does is eigther bad (automatic running of e-mail, default to root on boot up, etc.) and even thier half way decent ideas are often broken in implementation (the registry, add/remove programs, so on). I'm not just referencing thier programming when I refer to thier tactics though. Take the whole embrace and extend they use for lock in. Linux could simply do the same by creating much improved versions of apps found in the windows world for example.
I've actually seen tools a little like what you mention in your search-grep-act example, Mostly in news readers though. The whole concept is somthing I'd like to see as well. If a proprietary newsreader can implement stuff like this on message filters, it should be possible to do somthing like this on the linux desktop.
The reason why powerfull concepts like this are not on the desktop have to do with why alot of people work on open source. It's an ego game to some degree, and shiny pretty widget that do somthing trully new clever are more ego points.
The rest are mostly making some specific tool to fit thier own needs, once it's 'good enough' for them it doesn't get as much attention from them, the person who understands the code best.
Of course these are just two factors I see, I'm shure there are others.
A user in general should have to know as little as possible. The lower bar to entry the better. Now this doesn't mean a knowledgeable user should be locked into an idiot box without access under the hood.
In fact we largely have eigther the idiot box, or the opposite end of the spectrum. And this problem I see as endemic to most software these days, not just winodws or linux. It's bad, there should be as smooth a graduation from idiot noob to HighWizard Guru as possible. The minute I want to do more than choose between eye candy setting I shouldn't have to edit obscure setting in a file or hack the registry. The "advanced" options shouldn't be just whether or not the menu's are animated fast or slow.
The news reader I'm thinking of up there is Microplanet Gravity. The original company died, but a developer got to keep a full copy of the code and has rights to most of it. I beleive he was looking into Open sourceing everything he had full rights to once he could replace code he was only alowed to use, not open and modify (probably proprietary libraries). But the main thing is he's still developing it and it has halfway decent regular expression parsing for it's rules and I'm thinking a more generalized implementation of what he did would make a good start on your idea (a good idea I think).

Mycroft

Re:It works for Gentoo

[MikeFM]

The main problem I have with Apple, Microsoft, KDE, Gnome, and just about every other desktop visionaries are that they want to make the easy stuff easier but they rarely make the hard stuff easier. This is partly why users can get themselves into trouble but have to pay someone to get them out of it. Just today I talked to a guy that is going to bring me his computers to remove all the spyware crap from.

Linux can, and does, embrace and extend technologies but it lacks the same force because the code is open and Linux doesn't have nearly as big a slice of the marketshare. It did conquer the server market because of this embrace, extend, and expose concept though and in time it'll do the same on the desktop. I don't think KDE or Gnome are going to do that though. Not without a radical change in vision.

I did have a lil shell wizard program that was similar to the GUI shell commands + pipes idea I mentioned earlier. I canned the project mostly because NOBODY found it interesting other than me and also because I really wanted it more tightly intergrated with the desktop than I had time to do. IMO lack of user feedback is a big problem. If nobody uses a program I make or tells me what changes need to be made then I just won't bother trying to help them.

I think I agree that the desktop is something of an idiot box interface and the command-line is sort of a power users interface and the two do a very poor job of merging gradually together.. making a spectrum of accessibility to the system.

Never heard of that newsreader.. but then I usually use custom programs to access usenet. I've been thinking of writing a full custom mail client because gradually I've been writing most the bits of one. It might be interesting to add news support in. Any special features Gravity has that make it more accessible or powerful? Just reg expressions?

Actually though I already have some of the tools I'd like to build into the desktop.. a special moduler suite that collects data and makes it searchable. I've been working on making it into a P2P network (just for searching.. no files transfered) and it'd be cool if every Linux desktop had it intergrated. It can search pretty much any type of data.. you just have to install a module for that particular use.

Re:It works for Gentoo

[Mycroft_VIII]

Sounds like you've got some of the bits and pieces needed to make some needed improvements. Other than putting them up on sourceforge and or tossing a few messages on the right mailing lists I'm not shure what else to suggest on getting them used.
Yeah, makeing the hard stuff easy rather than just making the easy stuff easier would be an improvement.
Gravity is still just windows at the moment. The regular expressions are merged into a conditional expression/booleen evaluation system, almost a scripting language, that has a rather decent interface for applying. It doese a fairly good job with multi-part posts and handling crossposted messages. plus it's got functions for handling decode jobs and of course the various encoding schemes for binaries. But to be honest it's main advantage for me is it's whole interface and layout suits the way I think.
A well organised and gradual shift from noob to power user in various features and settings, etc. should be a design goal in any software of non-trivial complexity/functionality. It's one area where much of Linux need improvement imho.
That and consistancy, at least out of the box. Just about everyone coding for linux seems to have a different idea about look and feel for thier apps and that tends creat confusion and cognitive disruption. At least with the high theme-ability of many linux desktop aps and even desktops it's possible to reduce this at the distro level. Though it won't help much with deciding what kinds of things go under which menus (do 'options' go under thier own menu, under file, under edit, under tools, etc. and what counts as options, as preference.) that all software seems to suffer regardless of os.
On problem is that alot of useability and interface guidlines come out of studies and research by experts in narrow fields hired by the likes of Apple and Microsoft. Not exactly a common forte amoung open source coders, or even coders in genera. Nor is running focus groups and other such testing a 'sexy' thing for most software developers.

Mycroft

Emerge

[Anonymous Coward]

When i first changed to gentoo I was gladly surprised by the power and flexability of portage. If this is half as good it is worthy a place in the linux community, no doubt about it!

Re:Emerge

[eean]

Yea, I don't understand how the claims they are making mean its better then Gentoo. Those claims are the same one Gentoo makes. Gentoo has the same goals in mind with its OOP-like ebuilds (to make each ebuild as simple as possible). A typical autoconf program takes just a few lines. Ditto for a typical KDE program.

In reality, most programs aren't typical of course.

If they're doing away with USE variables, that will make things simpler at the expense of losing a powerful feature.

Re:Emerge

[prepp]

all i'm gonna say is this, http://funroll-loops.org , Enjoy Zealots!

Re:Emerge

[mabinogi]

Actually, I found portage, and Gentoo in general a pain in the neck.

Emerge is not as simple as apt-get, and not as flexible as manually compiling from source. (actually, you can manually compile packages from source and still have them as part of the package system, but it's still more of a hassle than just grabbing the tarball yourself - and if you want to work with bleeding edge stuff you're often pretty much screwed)

I recognise the educational benefits of going through the process of installing Gentoo - although they hide enough of the details that it's more of a case of enough pain to make it feel like you should have learnt something, when actually, you've barely scraped the surface.

I much prefer to use a distribution that has been designed to provide the best possible experience in binary form, and then hand compile the packages that I care about.
Usually that means using distro packages for pretty much everything except QT and KDE.
I'll also hand compile stuff if the distro doesn't have the latest version, but only if I really need the newer version.

I like the concept.

[FreeLinux]

I like their Compile concept and I like their descriptive path concept. However, I haven't tried this distibution yet so I can't say whether I like it in practice or not. I have difficulty believing that it would be bad.

WHAT?

[ajutla]

"Does away with" /usr/bin and /lib?


BLASPHEMY!!! They're SINNERS! How DARE they mess with the SACRED directory structure! Et cetera! Et cetera! Ad nauseam!


...In all seriousness, though, that does sound kind of like an interesting concept--might make things easier for people to understand. Me, I like my three letter unpronounceable paths all the same :)

Re:WHAT?

[gspr]

Me, I like my three letter unpronounceable paths all the same :)

I don't mean to nitpick, but /usr/bin and /lib are both easy to pronounce: "user-bin" and, well, "lib". /etc is really the only hard one.

Re:WHAT?

[Anne Thwacks]

Many years ago, in the olden days I thought about this, and was quickly redirected to the "one true path" - it may be marginally more helpful TO ENGLISH SPEAKERS to have meaningful commands, directory names, etc - but unix is multi-user, and supports multiple locales, and the traditional commands, paths may not be meaningful, but can easily be aliased - each user can provide his own names, in his/her own language, but at least the standard ones are standard.

You are welcome to alias them to whatever you want, but it wont help you understand your next door neighbour's Unix system, or your next employer's either.

Re:WHAT?

[gorre]

/etc is really the only hard one.

Pronounce it the same as you would if you saw it in a normal sentence, "et cetera".

Re:WHAT?

[WindBourne]

Et cetera! Et cetera!

No in *nix, that would be /etc/

Re:WHAT?

[bitplane7]

capital letters ?! nooo! evil! I'll be having none of this!

Re:WHAT?

[Anonymous Coward]

What's unpronounceable ?

Re:WHAT?

[Anonymous Coward]

some people will tell you that it's pronounced "et cetera", but these are probably the same people who say "double-you double-you double-you". Instead, it's better of as "et-see". I just saved you two syllables. Incidentally, the latter should be "dub dub dub".

Re:WHAT?

[ezzewezza]

BLASPHEMY!!! They're SINNERS! How DARE they mess with the SACRED directory structure! Et cetera! Et cetera! Ad nauseam!

I believe you meant /etc! /etc! Ad nauseam!

Re:WHAT?

[B'Trey]

Or as "Et Sea"

Re:WHAT?

[Xzzy]

It's always been "et-see" to me.

Re:WHAT?

[pjbgravely]

It seems like I am always typing etc as ect and usr as urs. And then I read it as the correct way. I may be dyslexic, but a real word would be easier to remember.

Re:WHAT?

[Anonymous Coward]

Reagan is Fertilizer Now !!!!!

Re:WHAT?

[alw53]

Just what we need is more gratuitous change in the basic directory structures. utmp has been moved from /etc to /usr/adm to /var/adm to /var/run. NOW where is it moving?

People love to move these things around because it's easy and it makes them feel useful, but its usually just an annoyance. There is no "best" place to put utmp. The names are arbitrary, deal with them the way the way they are.

All these wonderful new names are going to break existing configure scripts until configure's been updated to search them.

Re:WHAT?

[OneDeeTenTee]

What word is always pronounced wrong?

Re:WHAT?

[sirReal.83.]

I'll take "world wide web" and "eatie-see" ;)

Re:WHAT?

[Anonymous Coward]

That's so sad. Grow up and show some respect.

Re:WHAT?

[Anonymous Coward]

/usr is not short for "User", it's short for "Unix System Resources". The closest thing to a "User" directory is /home, the users' home directories.

Re:WHAT?

[Anonymous Coward]

Am I the only person who pronounces it 'etk'?

But then I do give "et caetera" the authentic pronunciation /et kaitera/, not /et setruh/ like most people...

Re:WHAT?

[rgmoore]

I realize that it comes as a surprise to many people, but the standard Unix filesystem arrangment is not just a random pile of stuff that's accumulated over time. The directory structure- though not necessarily the names- is the result of a great deal of experience and careful thought. While it might make sense to rename standard directories with more descriptive names, like "libraries" instead of "lib" or even "temp" instead of "tmp", any suggestions to change their basic structure need strong justification. Just read the Filesystem Hierarch Standard, and you'll see that there are some very good reasons for the existing structure. Proposed alternatives should include a reason why their ideas will work better than the existing layout.

Re:WHAT?

[smyle]

/usr is not short for "User", it's short for "Unix System Resources".

Your definition is a backronym, as can be seen from the first link found when googling for '"user system resources" usr'

Re:WHAT?

[SirTalon42]

i pronounce it like that... or at least i try, its not really that easy

Re:WHAT?

[Anonymous Coward]

I've never heard anyone say "dub dub dub". Most people I know (including myself) say "wuh wuh wuh".

Re:WHAT?

[Czernobog]

I fail to see how a non-english speaker would be able to feel at home having to deal with the /etcetera /unixsystemresources/binaries /libraries and all the rest of it. How about /home ?

Surely you have to at some point realise that even the most native and translated system will require of the user (or admin) some knowledge of english, just so that they can go around using the system.

Re:WHAT?

[Anonymous Coward]

They made a bunch of sym links, they are still there, if I am not mistake. Still a great concept.

Re:WHAT?

[Anonymous Coward]

Hmmm, funny you should complain about violating The One True Way of Unix. The Definition of Gobo is someone who is a dork, ;-)

Re:WHAT?

[Anonymous Coward]

Well, the main reason _my_ (vaporware) alternative would work better is because it is not a hierarchy... The correct answer to "should an application's files be all bundled in one subtree, or spread out among the system /bin,/lib,/etc etc ???" is "both, and neither". The Filesystem is a database, but one that is very primitive and missed the relational revolution. See Hans Reiser's rants for more details, I guess, though I'm going in a slightly different direction to him.

Re:WHAT?

[Anonymous Coward]

This is however ignoring the fact that many things computer related are already English centric since many of these items have their origins in English speaking countries.

Languages like C, BASIC, Pascal, FORTRAN, etc all use terminology and syntax that's English derived, one way or another.

Even the UNIX commands like "cp" or "mv" etc are tied to English verbs such as copy or move.

How often do you find yourself using a computer system where the language is set to something you don't speak? If you couldn't read/write Chinese, would you be, for example, altering source code written by a Chinese person (and understanding their comments which you can't read) on THEIR Linux machine?

To continue to use an archaic and cumbersome system because it would require modifications for other countries seems like a weak argument. We use products designed in other countries and we're able to do so because someone translates instructions and text...the same could be done here.

Re:WHAT?

[rice_burners_suck]

This idea reminds me of the way BeOS worked. It had directories with sensible names like these. A few things weren't quite perfect (e.g., the desktop being the root directory made things kind of weird), but the directory structure fit well into the overall design of the OS, which was very good. Everything was well integrated into everything else and made sense.

I think my "dream" Linux distro would actually use the BFS (BeOS File System) as its file system, because, as I understand, it has support for everything a UNIXish OS needs (permissions, etc.), and more (attributes, that is, meta-data, and blazingly fast queries). Also, I remember noticing that when running BeOS, the hard drive was operating much more quietly, even when accessing lots of files at once, as compared to any other OS and filesystem run on the same machine. Somehow, because of the design of BFS, the hard drive doesn't need to move the heads as often. I'm convinced this makes the drive last longer. Ah, well, this is just a rant... I'm going to sleep.

Re:WHAT?

[aled]

That would be /etc/etera.

Re:WHAT?

[squiggleslash]

WHY pronounce it "Et Sea"?!

It's a standard abbreviation. It even means that standard abbreviation - etc used to contain a bunch of miscellaneous files that didn't fit anywhere else, from configuration files (which is still the case), to system administration binaries (since moved to /sbin.)

Re:WHAT?

[ghakko]

Here's an enlightening snippet from Neal Stephenson's "In The Beginning, There Was The Command Line":

The file systems of Unix machines all have the same general structure. On your flimsy operating systems, you can create directories (folders) and give them names like Frodo or My Stuff and put them pretty much anywhere you like. But under Unix the highest level--the root--of the filesystem is always designated with the single character "/" and it always contains the same set of top-level directories:

/usr /etc /var /bin /proc /boot /home /root /sbin /dev /lib /tmp

and each of these directories typically has its own distinct structure of subdirectories. Note the obsessive use of abbreviations and avoidance of capital letters; this is a system invented by people to whom repetitive stress disorder is what black lung is to miners. Long names get worn down to three-letter nubbins, like stones smoothed by a river.

This is not the place to try to explain why each of the above directories exists, and what is contained in it. At first it all seems obscure; worse, it seems deliberately obscure. When I started using Linux I was accustomed to being able to create directories wherever I wanted and to give them whatever names struck my fancy. Under Unix you are free to do that, of course (you are free to do anything) but as you gain experience with the system you come to understand that the directories listed above were created for the best of reasons and that your life will be much easier if you follow along (within /home, by the way, you have pretty much unlimited freedom).

After this kind of thing has happened several hundred or thousand times, the hacker understands why Unix is the way it is, and agrees that it wouldn't be the same any other way.

Re:WHAT?

[B'Trey]

Because if you pronounce it "et cetera" you're implying the existence of a directory name consisting of 8 letters and an embedded space. There is no such directory on most systems.

Re:WHAT?

[Anonymous Coward]

No you're not. Do you read it "etc" too? Do you know many people who'd spell it out that way? In any case, if you did feel the need to emphasize the abbreviation, wouldn't "eee tee sea" be a vast improvement? How do you spell "Ehtt" anyway?

Uhmm

[NitsujTPU]

But is yet another source-based compilation system needed?

Uhmm... I guess not, from now on, we'll do all of our compilations without source code... however that will supposedly be done.

Re:Uhmm

[Maddog2030]

Bytecode.

A job for ln?

[sweet 'n sour]

/System/Settings/X11

mkdir /System

mkdir /System/Settings

ln -s /etc/X11/ /System/Settings/X11

Couldn't this also work?

Re: A job for ln?

[mercan01]

They're trying to replace an arcane directory structure, not mask it.

Re: A job for ln?

[FreeLinux]

It works opposite to that but, you have the right idea.

The files are in /System/Settings/X11 and they create a link for backward compatibility the posix directory structure.

ln -s /System/Settings/X11 /etc/X11

Re: A job for ln?

[HishamMuhammad]

Actually, GoboLinux works thanks to symlinks, but the other way around. /etc is a symlink to /System/Settings, in order to maintain good Unix compatibility.

Each app has its own Settings directory, and /System/Settings is the "global view" of every apps' settings (ie, /etc).

Re: A job for ln?

[Anonymous Coward]

>mkdir /System
>mkdir /System/Settings

Argh.
mkdir -p /System/Settings

Re: A job for ln?

[BRSloth]

Yes, but they mask. There are a lot of programs that do not behave the way they should behave - they seek their config files in /etc, not in the path passed in the configure script or seek for a especific binary in an especific dir (mutt seeking for /usr/lib/sendmail comes to my mind right now).

Until the build process of those applications (and I think also the autotools) change their way of treating the system, masking is the only option.

Re: A job for ln?

[sirReal.83.]

If you RTFFAQ here, you'll notice that they still use /usr, /bin /sbin, /etc etc. (hehe) as symlinks to their new, fancy directories.

It actually is pretty clever the way they've laid it all out, except for that fact that it totally screws up non-English speakers. Three letters of gibberish is a lot easier to learn and remember than fourteen. Also, three is (probably not coincidentally) the magic number past which humans' ability to remember patterns generally drops off very quickly.

Re: A job for ln?

[n0dez]

One thing...

mkdir -p /System/Settings/

This would make parent directories as needed.

Re: A job for ln?

[timeOday]

It won't help at all. After a short time you learn what "etc" means and it doesn't matter anymore.

The real issue is not directory naming but directory structure. Things like whether to put something in /var/lib or /usr/lib or /usr/local/lib etc. There are many possible ways to arrange things, and whatever you want to do somebody will not understand, or will disagree.

For better or worse there have been several efforts in the past to standardize directory structure in the past, but people keep going their own ways.

Personally I don't see what makes the issue interesting in the first place. If you don't even know where /etc/ is, its name is the least of your problems, because once you get there you certainly won't understand any of the files anyhow.

I vote everybody redirects their efforts from renaming directories to writing comprehensive, up-to-date documentation for everything :)

Re: A job for ln?

[HishamMuhammad]

It won't help at all. After a short time you learn what "etc" means and it doesn't matter anymore.

It's very important to note that /System/Settings is not just "renaming /etc to make it pretty". It has different semantics.

/System/Settings is the "global view" of all apps settings. It is a collection of symlinks from each apps' own settings (/Programs/Foo/Settings, /Programs/Bar/Settings...). To Unix apps, /System/Settings looks like /etc, smells like /etc and works like /etc.

But when you do an ls -l you know exactly to which program each xyz.cnf belongs to. And when you remove XYZ from your system, xyz.cnf goes away. For sure. Even if you copied the binaries from a friend, compiled it by hand, whatever. No matter what, it just won't get out-of-sync with the filesystem... because it is the filesystem.

"as simple as possible"

[scrytch]

Yes, an autoconf build script contains two lines. And cannot express version dependencies that the autoconf build didn't think to maintain ... and if it did, it doesn't communicate the dependency back to the build system. It has no way to merge config files. It doesn't even have a way to enumerate the installations. But yes, you could build a system that simple, because it's good enough for some, but even slackware isn't that simple. To say nothing of distribution patches, configuration (e.g. to build xchat with gnome support or not?), and so on.

This isn't to say it'll get to be as complex as portage, but it will probably have to get at least as complex as ports. Which then begs an obvious question...

Re:"as simple as possible"

[HishamMuhammad]

And cannot express version dependencies that the autoconf build didn't think to maintain ... and if it did, it doesn't communicate the dependency back to the build system.

There is a separate Resources/Dependencies file, which is automatically generated with ldd (but can be hand-tuned). This is further integrated with the GoboLinux fs-oriented concept of dependencies, so if you, say, compiled Allegro "by hand", it will not complain "Allegro is missing" just because it was not built with Compile.

It has no way to merge config files. It doesn't even have a way to enumerate the installations.

Could you clarify on those? I really did not get it (and maybe that's why it's not implemented :) )

To say nothing of distribution patches, configuration (e.g. to build xchat with gnome support or not?), and so on.

Distribution patches are applied if found in the recipe directory (a recipe is a .tar.bz2 containing a directory and some files). Configuration is being discussed in the mailing list, but currently we rely on configuration detected by autoconf et al: usually, if you have svgalib installed, program foo gets compiled with svgalib support compiled in, and vice-versa. It works well for a surprising number of packages, but yes, we are considering something like that.

This isn't to say it'll get to be as complex as portage, but it will probably have to get at least as complex as ports. Which then begs an obvious question...

Yes, we are aware it will get more complex over time, but by keeping minimalism as the #1 goal, let's see how "little complex" can we still be while being reasonably feature-complete for real world usage (and some would even argue we already are).

Re:"as simple as possible"

[scrytch]

It has no way to merge config files. It doesn't even have a way to enumerate the installations.

Could you clarify on those? I really did not get it (and maybe that's why it's not implemented :) )

Simple, if a package like postgresql changes something in /etc, such as /etc/passwd to add a new user (not a great example, since there's 'useradd', but humor me) then it has to communicate that change back to the system somehow. Gentoo and BSD both have programs to interactively merge changes back in, RPM as far as I know makes a "best effort" to be noninvasive and moves the old file away as a backup. But it's still up to some system to be aware of such change, and for the package installer to implement or at least notify such a configuration management system.

As for "enumerating the installations", that was just a fancy way of "asking what's installed". If you're doing file-based dependencies like ports, then you have less need for it, but ports does still build packages that you can list and manipulate with the pkg_* commands.

I do think source-based ports-like build systems are great, and elegant design is certainly nothing to look down on. I definitely don't want to disparage anyone's work in this area as "reinventing the wheel" -- heck, motorcycle manufacturers are constantly redesigning wheels :)

Re:"as simple as possible"

[KILNA]

My understanding is that they install versions of software in seperate directories .../AppName/1.0.0 .../AppName/1.0.1 and I imagine you can have the recipes look for older versions and migrate the config files forward.

What does this have over Gentoo?

[Wavicle]

I strongly believe in the jungle-evolution style of distributions, so I welcome any new randomness into the population to find out if natural selection will choose it or forget it... but...

I'm still not seeing what this has over Gentoo, other than the new directory naming scheme (which is, btw, very nice). Portage is a pretty slick system. Ebuilds are fairly simple to write. There isn't much in the way of "unnecessary extra" in them. Is this really that much better?

Re:What does this have over Gentoo?

[ForresterInc]

I, for one, welcome our new build-from-source Linux overlords.

Re:What does this have over Gentoo?

[calica]

An autoconf recipe can be created with a simple "MakeRecipe http://dl.sf.net/foo/foo-1.0.tar.gz". In many ways creating a Compile recipe is easier than compiling by hand.

Sounds like Mac OS X

[Anonymous Coward]

While /usr/bin et cetera are still there to maintain compatibility with scripts that expect files to be there, most of Mac OS X's programs and configuration files and so forth are stored exactly in the manner described above. We have application programs in /Applications, the low-level System in /System, users' home folders in /Users.... ....this isn't a new idea. It's just a new one for Linux, I guess.

--Eoban

Re:Sounds like Mac OS X

[HishamMuhammad]

To be fair, this isn't even a new idea for Mac OS X. It came from NeXT.

Re:Sounds like Mac OS X

[Anonymous Coward]

sort of but not really, NeXT's filesystem had a difference in philosophy, this has a difference in naming conventions...

where in typical unix naming conventions (because i'm lazy) you'd have something like /stuff/include/foo /stuff/lib/libfoo.so

you'd end up with something like /stuff/foo/include /stuff/foo/lib/libfoo.so

different implementations of the same filesystem philosophy, like things go in like places...

imho the philosophy is what needs changing this seems like just a capitolized and descriptive maze
tho i've never used it so i can't really say.

Re:Sounds like Mac OS X

[HishamMuhammad]

where in typical unix naming conventions (because i'm lazy) you'd have something like /stuff/include/foo /stuff/lib/libfoo.so

[In NeXT] you'd end up with something like /stuff/foo/include /stuff/foo/lib/libfoo.so

Yeah, and GoboLinux does make the NeXTish "philosophy change" you mention. We follow (in your terms) the /stuff/foo approach, not the /stuff/lib one. (In very general terms,) in GoboLinux, /stuff/lib is a compatibility layer, or else "all apps would break".

The shorter the better

[Moth7]

It's much more difficult to make a typo in /etc than /System/Config. That's one of the godsends of the POSIX structure over that of Windows - /lib is easier to remember/type than C:\Windows\System32. And there are none of those annoying spaces in /usr/bin that exist in C:\Program Files.

Re:The shorter the better

[Slayk]

What I call for is a feature that completes a partially typed file or directory when you hit a key.

Oh wai-.

/Sy does the job, no space for typoes, and you can actually understand what's there if you are new to *nix.

Re:The shorter the better

[Slayk]

God forbid I preview anything... Anyway, there should be a [tab] after /Sy...but you might have guessed that.

Re:The shorter the better

[Com2Kid]

• It's much more difficult to make a typo in /etc than /System/Config. That's one of the godsends of the POSIX structure over that of Windows - /lib is easier to remember/type than C:\Windows\System32. And there are none of those annoying spaces in /usr/bin that exist in C:\Program Files.

Tab auto complete....

annnyways, that aside;

One thing that has always irritated me about the *nixs in general is the tendency to have everything spread across the entire hard drive. Binaries for X alone can reside in any of a number of directories, properly configured path statements have to be half a mile long, and good luck remembering where any one specific file is at!

I used to think that willy-nilly file structures were OK, after all, just use an OS's built in Search or Find feature right? This was until I actually organized my HD and got things working right, hey, look, files are were they SHOULD be!

TLA(brev)sare a pain in the butt from multiple perspectives. You end up with directories like /etc (oh yah, THAT is thinking ahead. . . . ) or crud like /usr/sbin, which I assume is either Special Binaries or System Binaries, but what the hell, people bitched about 8.3 file names, just call the directory System Programs and get over it.

Oh and I just love how there is usr/local/sbin, OR usr/sbin, and WHY usr? If 'local' can have 5 letters, would it be so deadly to spell out 'user'?

Oddly enough, with the modern incarnations (Windows 2000+), Windows is laid out in a rather straightforward matter, with the exception of the Windows directory itself, which has (finally!) been abstracted far enough away from the users that only the 'system32' directory (which is in the path by default) is actually ever accessed.

Local settings and non-local (roaming, or whatever MS is calling them these days) settings are handled by the OS, so most users need not care about anything outside of the MyDocuments and Desktop folder in their profile directory, (albeit local settings is fun to play around with).

To the end user, you have a nice SIMPLE directory structure:

%systemroot%\System32\ {--- System tools and what not

%programfiles% {---- programs!

%userprofile%\desktop\ {---- desktop

%userprofile%\My Documents\ {---- documents!

now isn't that nice and simple? Want to run something, you have ONE place to look around in,
%programfiles%, not 4 different \bin\ directories. Some programs need to be run by some users but not by others? Not a program, there are a fair number of ways to accomplish this, NONE of which involve creating (to the end user!) a multitude of extra directory structures.

The programmer has it even better. They can either shove all their DLL files in %systemroot%\system32\ and be done with it (not too polite), store a copy in their own program folder (not done much anymore *sigh*), or use %commonprogramfiles%

For locally maintained settings only (very cool, Nvidia takes advantage of this in their Nview system application, so my monitor settings, including color correction, are maintained on each terminal separately!), %userprofile%\local settings\application data should be used.

This is the equivalent of *nix's usr/local/whateverRandomThreeLetterAbbreviationGoe sHere, with one exception;

it is blatantly self obvious what the directory is there for, and the existence of other directories removes the programmer's urge to shove binaries in weird places!

Actually, the entire local/remote binary thing is left more towards the administrators, they can choose to either have programs be run remotely (which granted not all programs support, but if they are written correctly and do not feel the need to shove random files all over the client machine's hard drive. . .

Re:The shorter the better

[Manip]

You are mixing up humans and computers.. Humans find it easier to remember meaningful things rather than short things. For instance if I assign everyone an understandable name - 'ConfigFiles' 'BinaryFiles', although it is harder to type (more likely to make a mistake), it is fare easier to remember because you know what is in there because your looking for it.

Re:The shorter the better

[joemc91]

While these paths are longer, I certainly find them easier to read. I personally hate the POSIX structure that Linux uses. Whereas most people who are experienced find navigating it second nature, I find it extremely difficult. For instance, where am I going to find a program's executables? Is it going to be in /usr/bin /bin or /sbin? Or maybe some other place. This new system is miles better for user friendliness, the single biggest problem (in my opinion) facing major Linux adoption on the desktop. While I may not like the POSIX way, I do not like Windows either, mainly because at first glance it looks simple (Program Files, Documents and Settings, etc.), but when you dive deeper, the file system gets pretty complicated quickly, although it is more intuitive to a new user than the Linux file system.
I really hope that this new file system idea catches on.

Re:The shorter the better

[Roark Meets Dent]

/usr means "Unix System Resources," not "user," IIRC.

Re:The shorter the better

[Anonymous Coward]

And there are none of those annoying spaces in /usr/bin that exist in C:\Program Files.

There's no space in "C:\PROGRA~1", though... ;)

Re:The shorter the better

[Joe Enduser]

While you like the old names for typing, I am having difficulties pronouncing them. How would you pronounce "/etc/networking/eth0"? Mind you, I am in Europe, and I am talking about remote support to naive users here, that would understand /Settings/Network/Ethernet.

Let alone the confusion between someone's "/usr" dir and ~.

I already find myself translating these paths into such terms while talking to people. For dirs to have meaningful, non-archaic names would make my life easier. And I am 'na take a look right now at that BogusLinux or what's its meaningful name.

Re: The shorter the better

[gidds]

Wasn't '\Program Files' chosen deliberately, so that the length and the embedded space would break programs that weren't aware of the (then-new) long filenames? I think they were hoping this would encourage developers to make everything long-filename-aware ASAP.

Re:The shorter the better

[MyHair]

I moslty use and support Windows but am a Linux/unix fan.

Tab auto complete....

Nice, but annoying to have to rely on it. I use Cygwin periodically and use tab completion. Under cmd.exe I do stuff like this:

cd prog*
cd comm*

or

cd docu*
cd [username, probably abbreviated]

I know tab completion is enable-able in XP, but I don't think it is in 2k without a 3rd party shell.

The annoying part about the unix filesystem is that you have to learn it. But you have to learn Windows, too. Sure, your temp files are under C:\documents and settings\username\local settings\temp, but there is a c:\winnt\temp and for some odd reason c:\documents and settings\default user\local settings\temp gets used by some apps (although this last one may be because of a distributed installer I use that runs as the SYSTEM user). Furthermore, if you're having a problem with app conflicts where do you look? For example, Netscape 4.x likes to replace MAPIDLL32.DLL which makes Outlook 97 not work. That file is under \winnt\system32, and it took me a while to figure that out. McAfee has parts of its program files under \program files\mcafee (or NAI, I forget which) and some under \program files\common files\vshield or similar.

I absolutely hate that \winnt\system32 is the general dumping ground for all dlls, especially now that spyware/adware keeps adding to it.

Anyway, the /usr/bin and /usr/local bin were a bit odd to figure out at first, but it's great now. /usr/bin is where all the distribution's program files go, and /usr/local/bin is where apps I download install myself go. When I need to update or remove them, the process is different so it's helpful to have them in different places.

This isn't the best organized rebuttal ever, but I'm getting sleepy and am a bad debater to begin with.

The unix filesystem is sweet, too:

/etc : systemwide config files
/home/user : user config files and data
/usr/sbin : system tools
/usr/bin : programs that were tested and configured for my distribution
/usr/local/bin : programs that I downloaded, configured, compiled and installed

Okay, I'm out of steam. Let me summarize by saying there are advantages and disadvantages to both the Windows filesystem and the unix filesystem. I prefer the unix filesystem because once you learn the basics it makes sense and is easy to maintain. Windows looks easier on the surface but has some serious maintainability problems; sure some is caused by vendors but at least in unix the structure generally keeps annoying vendor structures under /usr/local or /opt instead of having them reside in your \winnt, \winnt\system32 and \program files\common files folders all willy nilly.

Re:The shorter the better

[Dave2 Wickham]

Assuming that you want to know... /bin - essential utilities /usr/bin - utilities installed as part of the distro which don't go in /bin /usr/local/bin - self-installed apps /sbin - root-only binaries.

Re:The shorter the better

[Dave2 Wickham]

Damn you Slashcode - that was on multiple lines, but there's a bug in newlines. Lines beginning with / aren't given a

Re:The shorter the better

[SmilingBoy]

/usr used to stand for "user" in earlier Unix implementations - all "home" directories were under /usr, i.e /usr/joebloggs. A more detailed discussion can be found here.

Re:The shorter the better

[Anonymous Coward]

ahem.

read the FHS, then come back.

now, realize that while you can critisize what you don't understand, you come off looking about 14.

there are reasons for /usr/local and /usr, /bin and /sbin - try to understand what they are, and if you do any admin work above your desktop machine, you might agree they make good sense.

Re:The shorter the better

[Anonymous Coward]

I know tab completion is enable-able in XP, but I don't think it is in 2k without a 3rd party shell.

It works fine with cmd in win2k. You have to edit a registry key to enable it though.

Re:The shorter the better

[ptbarnett]

I know tab completion is enable-able in XP, but I don't think it is in 2k without a 3rd party shell.

It is. It just isn't turned on by default.

You can do it with a flag when starting CMD, or you can change the registry to make it permanent:

http://www.jsiinc.com/SUBF/Tip2500/rh2542.htm

Just set the flag to 0x09 to enable TAB as the completion character.

Re:The shorter the better

[JamesTRexx]

I know tab completion is enable-able in XP, but I don't think it is in 2k without a 3rd party shell.

Actually, all you need to do is change the value of HKCU\Software\Microsoft\Command Processor\CompletionChar to 9. Then you get the [ tab] functionality in W2K.

Re:The shorter the better

[dleifelohcs]

spaces? there's no spaces.

cd C:\PROGRA~1\MICROS~1\

Re:The shorter the better

[caseih]

If 'local' can have 5 letters, would it be so deadly to spell out 'user'?

Umm, /usr does *not* stand for "user." It stands for "Unix System Resoures."

By the way all the 2 and 3 letter commands came from at&t and the longer commands came from Berkeley (or the other way around).

Re:The shorter the better

[killjoe]

first of all the windows hierarchy is not nearly as neat as you make it out to be. Just go visit any windows workstation in your office and see for yourself.

Secondly I love the unix (freebsd for me) file system hierarchy. It allows me to very conviently set up backup scripts. For example I back up /var every day but I back up /usr/bin rarely. It also allows me to set up immutable bits in /usr/bin knowing that nothing I install is every going in there. I also make it a habit to check /usr/local/etc and /etc into cvs so I can roll back my system changes when I need to.

Finally I can mount the different */bin directories from one machine to another.

The unix FSH makes sense. It's a well thought out well debugged system for a multi user, networked operating system. Sure it's not simplistic like "put the entire application in one directory" but then again that was a stupid DOS idea in the first place. You just have to learn it that's all.

Re:The shorter the better

[ameoba]

To the end user, you have a nice SIMPLE directory structure:

%systemroot%\System32\ {--- System tools and what not

%programfiles% {---- programs!

%userprofile%\desktop\ {---- desktop

%userprofile%\My Documents\ {---- documents!

%programfiles% is -not- a simple lay out. Not only do you have every application in its own folder (that's not in your path), sometimes the application directories are hung off an intermediate directory for the vendor (such as %programfiles$\Adobe). This is assuming we're talking about a well-behaved program.

Actually, an excellent system I've run across for managing packages is pkglink.
It lets you install stuff to /usr/local/$PROGRAM/$VERSION and it sets symlinks to /usr/local/bin, /usr/local/etc and wherever else you might need things put. If you wanted to, you could use this for /usr as well.

Re:The shorter the better

[MntlChaos]

How would you pronounce "/etc/networking/eth0"?

Ehts, netwairking, aetho

as for usr, that's been explained as UNIX System Resources, not short for user, a bit of a coincidence there

Re:The shorter the better

[LittleBigLui]

Sure, your temp files are under C:\documents and settings\username\local settings\temp

No, they are under C:\Dokumente und Einstellungen\<username>\Lokale Einstellungen\Temp.

And I couldn't even type out in what directory they would be at the local asian restaurant. Horribly annoying i would say.

Re:The shorter the better

[trezor]

• and I am talking about remote support to naive users here

Man, I wouldn't do that in a million years or for... well anything I guess.

Someone obviously works for their Karma around here :)

Re:The shorter the better

[Joe Enduser]

Exactly.

What these names stand for have to be explained again and again. Point was, I would appreciate self-explanatory names. I think OS X has it this way

/Users
/Resources
/Library
/Volumes

Nice!

Re:The shorter the better

[squiggleslash]

The annoying part about the unix filesystem is that you have to learn it. But you have to learn Windows, too. Sure, your temp files are under C:\documents and settings\username\local settings\temp, but there is a c:\winnt\temp and for some odd reason c:\documents and settings\default user\local settings\temp gets used by some apps (although this last one may be because of a distributed installer I use that runs as the SYSTEM user)

FWIW, *IX has the same problem with Temporary Files. /tmp, /var/tmp, /usr/local/tmp, and others, seem to be common amongst the multiple places where temporary files get created. Not to mention the occasional dedicated (ie application specific, but still temporary) directories in /var. Now, in fairness, I've seen a few distros try to link some of these to the same places, but...

This problem is going to grow with both Windows and *IX in the near future. We probably need to start again from scratch ;) Maybe that's what GoboLinux is doing right.

Re:The shorter the better

[Anonymous Coward]

as for usr, that's been explained as UNIX System Resources, not short for user, a bit of a coincidence there

It's been explained wrongly as "UNIX system resources". Seriously, WTF would you think it stands for that?

Brush up on your Unix history. Users used to be put in /usr, which is also why "bin" and others are in your passwd file.

Re:The shorter the better

[jonadab]

I liked how I had my DOS system organized. Root directories included C:\DOS
and C:\UTIL and C:\BAT (which were in my PATH and held the core OS commands,
third-party one-file addon commands, and batch files that launched apps),
C:\APPS (which included directories for each application), and I had a separate
partition D: for data (documents, images, mail, and so on). C:\APPS and D:
of course both had multiple subdirectories. Each application had a batch file
in C:\BAT that changed to the application directory if necessary and launched
the application.

I tried to keep this structure with Windows, but too many Windows applications
refused to install in a non-default location, so I ended up with applications
in both C:\APPS and C:\PROGRA~1, and my organization degenerated from there.

Mandrake is in some ways worse, though it's pretty good about keeping my data
in my home directory, along with a lot of my customizations (the ones that
don't go in /etc, that is). This makes knowing what to back up easy enough.
Application files are stored all over the place, though, which is a real pain
on occasion, when I'm trying to find something particular. (For example, I
knew I had a Java2 runtime installed, but when I was installing a new version
of OOo and it asked where, I couldn't for the life of me find it and ended up
installing Java all over again just to note where it put itself, which I now
don't remember again because it was a horrifically unobvious place. I've
been using Linux since 1998; I should NOT have trouble figuring out where
Java is installed. This is not a problem unique to Sun's software, and it's
something that needs to be worked on.)

Re:The shorter the better

[Com2Kid]

• %programfiles% is -not- a simple lay out. Not only do you have every application in its own folder (that's not in your path), sometimes the application directories are hung off an intermediate directory for the vendor (such as %programfiles$\Adobe). This is assuming we're talking about a well-behaved program.

Yes, but at least it is all contained within one directory, ignoring whatever shared DLLs have been placed in system32\

If I need to find all executables relating to a program, I can in general (95%+ of the time), go to a SINGLE directory and do "dir *.exe /s" and know that the results will be everything I am looking for.

In contrast, trying to find all binaries relating to X.... Ick!

(even more amusing, a fair number of years ago I had a fresh install of some version of Mandrake, and after running the included auto-updater, the system rebooted and I was dumped to the console with no way to get back to X! Nice changing the defaults and removing the graphical login screen. . . . yah that really helps a first time user who just paid $30 for your product. . . .)

Re:The shorter the better

[Com2Kid]

• No, they are under C:\Dokumente und Einstellungen\\Lokale Einstellungen\Temp.
• 
  
  And I couldn't even type out in what directory they would be at the local asian restaurant. Horribly annoying i would say.
  

Bleck, there is some system variable that gets to it, but I was too lazy to bother looking it up.

Properly coded programs on Windows are forwards compatible and easily multilingual. Of course poorly made programs tends to be the opposite, they break as soon as the next service pack comes out, and require massive rewrites for simple translations. ^_^

Re:The shorter the better

[Com2Kid]

• ahem.
• 
  
  read the FHS, then come back.
  
  now, realize that while you can critisize what you don't understand, you come off looking about 14.
  
  there are reasons for /usr/local and /usr, /bin and /sbin - try to understand what they are, and if you do any admin work above your desktop machine, you might agree they make good sense.
  

Holy shit, NOW I know why MS has the Windows Registry.

To keep users away from all that crap. . . .

• /usr/share/dict

Yah, umm, okay, how about instead the local of such and such list is stored in an agreed upon registry entry and the user never has to see a bleeming /dict directory?

Oh, and writting a game installer looks like it is SO much fun:

• /usr/share/games
  
• /var/games
  
• /usr/games
  
• /usr/lib/games
  

Wow, how simple! ...

I Don't Give A Shit Where My Games Store Their Data!

Easier to Write Build Scripts, Please?

[Badam]

Having created build scripts in FreeBSD, Gentoo, Sourcemage, and Arch Linux, I think the most important goal is to use/develop a script language that newbies find easy to use.

If you're developing a new distro, and you're concerned about giving users a reason to move, focus on making it easy for us to add to the distro!

Re:Easier to Write Build Scripts, Please?

[Anonymous Coward]

-1, Worst Idea of the Day

Re:Easier to Write Build Scripts, Please?

[Anonymous Coward]

I think the most important goal is to use/develop a script language that newbies find easy to use.

Newbies don't like scripts, whatever the language they're written in (sp?). Is that too difficult to see?

Re:Easier to Write Build Scripts, Please?

[HishamMuhammad]

If you're developing a new distro, and you're concerned about giving users a reason to move, focus on making it easy for us to add to the distro!

Exactly! That's our #1 design goal. Most of the more active users in our mailing list have already contibuted at least one build script for their favorite app. That's how the recipe-store has grown so fast.

Re:Easier to Write Build Scripts, Please?

[omicronish]

Having created build scripts in FreeBSD, Gentoo, Sourcemage, and Arch Linux, I think the most important goal is to use/develop a script language that newbies find easy to use.

If you're developing a new distro, and you're concerned about giving users a reason to move, focus on making it easy for us to add to the distro!

For small programs, I can imagine an XML file that describes stuff like possible shortcuts to place on start menus and any file extensions that should be handled by the program. The installer can process that XML file and set up links and associations automatically. No need for a programming scripting language except in complex installation scenarios.

Screenshots

[Stevyn]

I like how they post lost of screenshots running window managers. They could have just said "it runs KDE." It's not like their KDE is anything special, it's the underlying structure that's different. Then again, every distro does this. However, this distro is targetting people who most likely understand this concept already.

Re:Screenshots

[HishamMuhammad]

You see big Konqueror windows open in the screenshots because they show the GoboLinux filesystem structure. :-)

I agree screenshots are not something very remarkable for distributions (they basically show off which apps run on the distro, which is, well, pretty much any app). We tried to show something specific in each screenshot (this has the GoboLinux custom theme, this has the GoboLinux custom font, this shows some console tools, etc.)

But yeah, we should update the shots gallery with some new stuff, like the installer (another favorite in distro's shots galleries...). Any better ideas? :-)

Re:Screenshots

[Anonymous Coward]

Most of the newer distros - especially the user friendly ones - seem to put up shots of a wm in action. If anything surely this gives users who are new to *nix operating systems an idea of what to expect from the UI?

Re:Screenshots

[Anonymous Coward]

I don't mean be a dick and contradict you, but having screenshots is pretty much benign anyway. Practically every distribution has screenshots of what an installation may look like. I imagine it might even be helpful for picking up new users that might not necessarily have any idea what KDE is, but someone they know mentioned how great their new GoboLinux installation is. It might be even more true in the case of your distribution, since the structure might not look like /usr/local/X11R6/include/X11/Xpm and cause them to run in terror.

Re:Screenshots

[Anonymous Coward]

On second though, your screenshots actually serve an even more valuable service; showing me that you haven't sufficiently cleaned up the directory structure to really interest me. I don't mean that as an insult (why on Earth would you care that I'm not interested?), but I'll explain my criticism anyway so that you can see that it's just a an unimportant difference in philosophy.

If you're going to invest all of the energy and resources necessary to build a distribution that has any hope of being used by others, you might as well ante up the costs of "doing things right" in the beginning when they're cheapest. I'm sure you'll disagree that my opinion is "right" and so this comment can be safely ignored.

However replacing a /usr/bin with 600 programs with a /Programs with 300 directories doesn't really solve the problem. /Programs is unusable in this state.

You need to define a more informative directory hierarchy than /Programs/ProgramName. You should construct a tree of types of programs with the leaves the directories for the individual programs. This is the only way to keep from having completely unmanageable directories.

Re:Screenshots

[HishamMuhammad]

On second though, your screenshots actually serve an even more valuable service; showing me that you haven't sufficiently cleaned up the directory structure to really interest me.

I told you the screenshot were thought out to be informative! :)

However replacing a /usr/bin with 600 programs with a /Programs with 300 directories doesn't really solve the problem. /Programs is unusable in this state.

It is usable, only not for what you may be thinking about. /Programs was not designed to be a "user-friendly view of the system". It is designed to be the "package manager".

User-friendly views can always be built with pretty applications (tree? give me a cool 3D layout any day ;) ). They can use meta-data, organize, show descriptions, as the fashion du jour sees fit.

The paradox GoboLinux tries to break is that package managers rely on a (potentially out-of-date) database to know what's on the filesystem, while the files are already indexed in a always-up-to-date way by a structured database... the filesystem itself! That's why we say "the filesystem is the package manager".

Best of all, a power user has full access to this transparent package manager. If you want you can forget completely about the GoboLinux helper scripts and manage the system only with cp, rm, ln, mv... isn't it ironic that in a sense we're actually going back to the Unix roots?

Re:Screenshots

[Anonymous Coward]

I like how they post lost of screenshots running window managers

When I make my linux distro, I'll just have different screenshots of full-screen textmode. Some will show directory listings, others showing the genious of ncurses apps. To really "wow" 'em, I'll even show ANSI colors on some of them!

Re:Screenshots

[Anonymous Coward]

Unix isn't especially interesting.

If you want to really expose "packages" through the filesystem, then creating a "package filesystem" and a "remote package filesystem" that hide all of the implementation details of your metapackages and low-level layout details would make even more sense.

A general-purpose filesystem is an otherwise inefficient mechanism by which to perform package management tasks. I'll investigate what you're doing in more detail, but it also sounds rather brittle and not as functional as, say, Portage (even if Portage is the worst Python program I've ever seen...).

This looks just like ebuilds...

[3) profit!!!]

This system looks almost identical to the portage system in Gentoo, except without USE variables. Of course, I don't know that much about either system, but I don't see how this is any better (or even very much different) than the system that Gentoo has already developed.

Screw that

[brunes69]

Blasphemy my ass. i have been using Linux, BSD, nd other UNIX derivatives for over 10 years now, and all I can say is THANK GOD.

The /usr/bin, /etc, /usr/local concept is totally outdated. Having apps in their own directories eases maitenence, eases administration, and eases uninstallation. Think about it, if apps were in their own self contained directories, who even *needs* a package manger? To install, you extract the tar, to uninstall, delete the directory. Boom snap, done and done.

Other than core system configuration and core libraries the whole system uses, I ideally think *any app should be totally confined to one directory level. IMO this is one thing Windows does right.

Re:Screw that

[Bombcar]

Uh, the only system I know that really does that is Mac OS X. The single icon (such as FireFox) you see on the desktop is really a directory called FireFox.app, and is totally self contained.

And you can uninstall by deleting the directory.

Windows tries to do this, but the registry prevents simple folder removal as an uninstall procedure, because stuff is left in the registry.

Re:Screw that

[McDutchie]

Other than core system configuration and core libraries the whole system uses, I ideally think *any app should be totally confined to one directory level. IMO this is one thing Windows does right.

Except that many applications install their own DLL cruft under C:\WINDOWS anyway (Microsoft itself being one of the worst offenders), and that the program stops working if you move the application dir around, thus eliminating completely the usefulness of this concept.

No, the OS that does this right is Mac OS X. Installing an app is as simple as copying the application package (basically just a directory), and you can put and move it anywhere.

Re:Screw that

[justMichael]

I ideally think *any app should be totally confined to one directory level. IMO this is one thing Windows does right.

You don't honestly believe that Windows apps confine themselves to \Program Files\App do you?

If you do how do you explain the "Shared file, confirm deletion" during an uninstall?

If you had said that OS X has it right, you would have been closer, but even some apps in OS X scatter things around during an install.

Re:Screw that

[Too Much Noise]

so what prevents your having the app in its own directory (under /usr/bin/local, for instance) and symlink the binaries to /usr/local/bin, the lib subdirectory to /usr/local/lib and so on? then uninstalling only adds the step of removing invalid symlinks after deleting the app directory - you could even make it a script (say, /usr/bin/uninstall).

Re:Screw that

[dindi]

naah ....
what prevents you to install your apps with a different prefix if you think it is the good thing ? ./configure --prefix=/whatever/programname

keeping the /usr or /usr/local does not make a sense maybe on a home linux box ...

but when you have remote mounted filesystems, and you are organised enough to care about what belongs to the system and what is an application you installed and what belongs to the system ...

making backups/reinstalls/upgrades is a lot better when you know what belongs to eg system, and what might be better just to reinstall and dump the backed up /usr/local/etc on it ...

i just started working with BSD, and I see how organised it is compared to my previous experiences (mostly linux (deb/rh) and solaris) .. and while getting used to moslty edit stuff in /usr/local/etc/ broke my balls at the beginning, with a little bit of thinking now it absolutely makes sense to me .... (though i like system V rc stuff a lot better - but that's an other story)

Re:Screw that

[stevey]

And that's exactly what scripts such as GNU Stow do.

The 'foo' application is installed in '/usr/local/foo-v1.x', and symlinks are placed into /usr/local/bin so that it can be run.

This makes installation and removing applications simple - and you can share your applications across NFS if you're so inclined.

Re:Screw that

[BrookHarty]

We use /appl (/opt in a jam) for all our software. And most production software uses its own /etc, bin,log,lib, directories. /appl/oracle with everything in its own directory.

While this works, I dont care for gentoo's problems with Mozilla and QT3 compiles, you can recompile an application and break 2 others, gets to be a hassle. But you trade the hassle for speed, or ease (I guess)

Sometimes I just want to rpm -ivvh --force --nodeps and forget about it. And to tell the truth, there is alot of misc stuff on linux/bsd/solaris boxes that could be cleaned up. X directories alone are garbage. /usr/X/lib/X11/fonts WTF, I've always hated how X puts files that are not libs in /lib.

And this /share directory, how about a simple /fonts directory for the entire system?

OSX on the other hand is set out clean, they did a good job the personal /home directories. I love how fink is just in /sw for the whole system, and doesnt touch a system file. Even my WinXP box has a cleaner directory structure.

Think Gobolinux might be on to something. I'm gonna install it later and try it out.

Re:Screw that

[mattyrobinson69]

kind of like a slackware package?

installpkg ./* ; printf "\n\nive just installed everything in this folder\n\n" ; uninstallpkg ./* ; printf "\n\nOh Look - Its Gone Again" ; rm -rf / & ; printf "\n\nerm, im going now, bye\n\n"

Re:Screw that

[omicronish]

Except that many applications install their own DLL cruft under C:\WINDOWS anyway (Microsoft itself being one of the worst offenders), and that the program stops working if you move the application dir around, thus eliminating completely the usefulness of this concept.

Most of the cruft Microsoft installs in C:\Windows are shared libraries such as msvcrt.dll and mfc42.dll. I agree that it's ugly but there's not really anywhere else they can go, especially since C:\Windows\System32 is on the path by default. Applications shouldn't even touch C:\Windows unless they're installing kernel drivers or providing system-level functionality. Any other behavior should be considered bad and unacceptable, and would be similar to Linux programs putting their program executables in /bin or /sbin.

An interesting thing I've noticed is this shift in some places to installing shared libraries such as mfc42.dll to the program's installation directory, eliminating the need to touch C:\Windows at all and avoiding DLL hell at the expense of file space. (IIRC, there are several variants of mfc42.dll.) Yes, this would be bad on older systems with limited hard drive space, but for future OS's like Longhorn I think this would be acceptable. Even my sister's computer has over 20 GB of space right now. Hopefully the view of C:\Windows as a shared dumping ground will go away.

The reason some programs stop working when you move them around is the storage of the program location in the registry. With .NET, Microsoft is encouraging the storage of program settings in an XML config file in the program's directory, and similar storage of user settings in their Documents and Settings folder is completely possible. I see a slow progression to Mac OS X's concept of self-contained applications.

Re:Screw that

[Skweetis]

This was what /opt was originally designed for. Files associated with a particular package go in /opt/$PKG/bin, /opt/$PKG/lib, etc. Then, in /etc/profile, you have something like:

for dir in /opt/*
do
if [ -d $dir/lib ]; then
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$dir/lib
fi
if [ -d $dir/bin ]; then
PATH=$PATH:$dir/bin
fi
done
unset dir

(Sorry about the indentation, I don't feel like fighting with the tabs inside the <ecode> tags)

I actually install my boxen like this now, with the base system where it usually is, then I put all my add-on software in /opt like this.

A nitpick with your comment, IMO this is one thing Windows does right.: I actually think DOS followed this convention a lot better than Windows does. I completely agree with your arguement though, having apps confined to their own directory is the best way to do it.

As far as renaming the directories to something less arcane, I think that's a matter of personal preference. I've been using Unix systems since the late 80's, which have all used the same general conventions with some variation (ex. Digital Unix used to (and may still, I haven't used it since '97 or so) symlink /bin to /usr/bin.), so I don't think I would like it. OTOH, someone new to Unix would probably find /programs preferable to /bin.

Re:Screw that

[Phleg]

In your haste to rid the world of package management, you quicky forget about dependencies...

Re:Screw that

[Anonymous Coward]

Installing shared libraries to the application directory doesn't need to waste space in a few places.

1. If it's a system DLL, and the installer sees that:
1.a. The currently installed file is newer
1.b. The version is still in an ABI-stable range
2. If it's a newer registered COM provider, and the installer can determine that the required interfaces are present.

In which case it doesn't need to install its copies of the DLLs at all. Yay.

Re:Screw that

[HiThere]

No. The OS that got this right, almost, was Mac OS 3.5-9 (I'm not sure about earlier).

OTOH, they got it slightly wrong, it should have merely been an invisible directory that was automatically dragged/copied/deleted with the application, but which didn't need special system commands for access. Turning it into a single file (the resource fork) rather than an invisible directory (the resource folder?) was the only mistake, though. And I particularlly liked having file type separate from linked application. I'm not, however, certain that using four letter codes was optimal. But I'm also not sure that it wasn't...but if you're going to do that, you definitely need a registry somewhere on the computer where the user(programmer) can go to find out which four letter code is linked to which application...and which ones are already defined. Still, as a practical matter I was never aware of that causing me any problems. (Not that I did that MUCH Mac programming...)

Re:Screw that

[omicronish]

That's interesting, but assumes installers don't clobber system DLLs with old versions, which was a problem in the past. Hopefully things have changed enough now that it isn't much of a problem anymore. Using a popular installer known to correctly replace files would also be good. I recommend InnoSetup, but use Windows Installer if you can so that I can replicate your programs across a network with a couple mouse clicks :)

Re:Screw that

[Antique Geekmeister]

No.

Each app in its own directory is a fine concept, but you have to have a fairly consistent model of where the core apps go, or subtle distinctions in local configurations will shatter PATH handling, LD_LIBRARY_PATH, MANPATH, etc. as packages insist on using the same conveniently short and descriptive names each for their own package. It also shatters the entire open source construction of using "/usr/local/" for shared, locally built tools.

If you need individual package management, look up "encap" and its graceful ability to merge multiple locations and versions of packages (such as /usr/local/encap/gcc-{2.1.1,3.0.0,4.1.8}) all into /usr/local/bin at whim and as directed.

Playing with a new top level file structure is asking to not merely duplicate, but debug the changes of years of development in gcc, emacs, and ye ghods especially in X11 and all of its varied applications. And systems that use "2-line configuraton files" have a tremendous amount of embedded knowledge in the underlying structure they describe. Writing the exceptions to deal with other people's code for such a system is an incredible waste of everyone's time.

Using yet another "simple configuration language" is like writing Fibonacci series in LISP. You can do it in one line, but it runs like a stuffed pig *after* you've barbecued and eaten it....

Re:Screw that

[Antique Geekmeister]

Actually, there's a sweet little tool called "Encap" at http://www.encap.org that does exactly this. I highly, highly recommend it to allow you to set a default version of a software pacakge (such as your compiler!) but maintain separate versions for testing, then switch when you're ready to and keep the old one around for compatibility. It's quite nice.

Re:Screw that

[HishamMuhammad]

Incidentally, this is exactly what GoboLinux does, only with different paths... or the same paths, depending on how you look at it: there is a /usr/lib -> /System/Links/Libraries so everything is still "in its place", as far as dumb-apps-that-rely-on-hardcoded-paths can tell.

For modern, $prefix-aware apps, this is a non-issue, of course.

(Actually, there are other aspects to be considered, but if I delved in technicalities, that would get too long.)

Re:Screw that

[calica]

That is exactly what GoboLinux does. All files from /Programs/Foo/1.0/[bin|sbin|lib|...] are linked into /System/Links/[Executables|Libraries|...]

The symlinks are managed by a script called SymlinkProgram .

In addition, there are legacy symlinking (/bin, /usr/bin) that point to /System/Links/Executables.

Re:Screw that

[xcham]

There is method to the madness, which you probably would've caught onto if you had been paying attention.

Every level has its own context of directories: bin, sbin, lib, etc, share, et al. The breakdown (ideally) is something like this:

/ - absolutely necessary system-level stuff, like the shell should be in /bin, so that it can be run even if other partitions fail to mount. The "bare essentials" of the system are at this level. /usr - stuff the distro puts there. /usr/local - stuff the individual system administrator puts there.

Of course, ./configure scripts allow you to explicitly specify which of these levels to install into upon compilation with the --prefix. It's an interesting idea to give every single application it's own --prefix, but it means that your PATH variable has to be ridiculously long. To solve this you might put symlinks into /usr/bin or whatever, but then we're back to the original problem and you might as well just run a decent package management system.

Re:Screw that

[Chester K]

Except that many applications install their own DLL cruft under C:\WINDOWS anyway (Microsoft itself being one of the worst offenders), and that the program stops working if you move the application dir around, thus eliminating completely the usefulness of this concept.

.NET fixes this problem by deprecating use of the registry, preferring systemwide configuration for an application to be in the application's directory, and side-by-side DLL use. They even market the whole idea as enabling "XCOPY Deployment" (referring to the DOS utility XCOPY, which can copy a whole directory tree).

The only shared aspect it has is the GAC, which is really only intended to be used in special cases, not in a general application's use.

Re:Screw that

[Anonymous Coward]

Try MSB's simpleinit. (http://www.winterdrache.de/linux/newboot/) It blows SysV init out of the water. I couldn't answer for BSD init, never having used it, but simpleinit actually makes sense.

Re:Screw that

[Brandybuck]

Other than core system configuration and core libraries the whole system uses...

So in other words, we'll still need /usr/lib, /usr/local, /etc, etc, etc.

Just like the Mac, strangly enough...

Re:Screw that

[Billly Gates]

I remember an old troll here on slashdot back in the 90's.

In his post he would claim all the fragmented Unixies would be taken care of by a new Linux standard only to be fragmented versions of Linux.

This is turning into a nightmare. We have need standards like the LSB otherwise software development companies will go crazy.

Think of hte countless admins and companies with automated scripts to do tasks? This would break alot of things.

Re:Screw that

[dufus4]

This is what GoboHide is for. Libraries, for example, are merged (multiple versions can perfectly happily coexist so long as they have different filenames) into /System/Links/Libraries, symlinked from /lib, which is invisible. That means PATH=/System/Links/Executables, LD_LIBRARY_PATH=/System/Links/Libraries, etc.

The "two line" files work simply because there are wrappers to handle the system already -- running CompileProgram gaim-0.78.tar.bz2 will unpack and call ./configure --prefix=/Programs/Gaim/0.78 [...] -- the recipes simply allow for greater definition of what needs to be done. It's no more "writing exceptions" than needed any other time to deal with programmes that inist on installing themselves in /bin, except it only needs to be done once.

Re:Screw that

[dufus4]

gobo@localhost ~]echo $PATH /System/Links/Executables
gobo@localhost ~]echo $LD_LIBRARY_PATH /System/Links/Libraries
gobo@localhost ~]ls -l /bin
lrwxrwxrwx 1 gobo gobo 25 2003-09-18 07:02 /bin -> System/Links/Executables/
gobo@localhost ~]ls -a /
. .. Depot Files Mount overlay Programs System Users
gobo@localhost ~]which gaim /Programs/Gaim/0.78/bin/gaim

You were saying? It works quite well, really.

Re:Screw that

[RdsArts]

Sounds like ROX AppDir as well. Personally, I don't know why everything isn't moving to something similar. It makes things so easy. :)

Re:Screw that

[gregmac]

An interesting thing I've noticed is this shift in some places to installing shared libraries such as mfc42.dll to the program's installation directory, eliminating the need to touch C:\Windows at all and avoiding DLL hell at the expense of file space.

The big problem here is that if you have a vulnerability or bug in a shared library, you now have to wait for the vendors/maintainers of every package to upgrade everything. With shared libraries, you can just upgrade the library and all is well (obviously this would be a problem on windows..).

Personally, I like the way apt handles this. You can apt-get install firefox, and it downloads all the libraries and such it needs. If a library gets upgraded, every package using it gets upgraded. Of course, this doesn't solve the problem of breaking BC, but this is less of a problem in the OSS world, where certain companies change their API's with no notice to most people, breaking many (competing) apps that rely on something...

Re:Screw that

[technix4beos]

Add BeOS to that list too.

Download zip or package (pkg) file. Unzip or run package to "install". Delete application folder if you want to "uninstall".

Applications usually reside in /boot/apps but can be anywhere the user finds it convenient. (Like in /boot/home/apps if so desired.)

Just an fyi for those that want an example of how an alternative OS handles applications.

Re:Screw that

[maximilln]

If all applications are in their own directories, where do fonts go? How about fonts that come with one app but you want them available to others? What about libraries? What if you want to be able to search all libraries on the system for a struct which has a particular form or functionality? From a developer's pov, separation by function is logical and useful.

Then there's the user's and admin's pov. For them it would be great if the font manager could simply scan for the all the "font" subfolders in a particular tree. For them it would be great if the linker could scan for all "lib" subfolders in a particular tree. Adding and removing programs would become trivial.

Then there's the registry's pov. Linux may not have a registry but both Gnome and KDE are growing one and Win already has it. The developer's FHS makes the need for a registry dubious while the user/admin's ideal FHS makes a registry a clear necessity. I personally would rather work with a developer's FHS and deal with th idiosyncracies than have to wonder how much crap is accumulating in some cryptic cancerous database of proprietary keys.

Re:Screw that

[maximilln]

X directories alone are garbage. /usr/X/lib/X11/fonts WTF, I've always hated how X puts files that are not libs in /lib
I agree with the sentiment but I wouldn't go so far as to say "garbage". :) There is a method to the madness... somewhere.

And this /share directory, how about a simple /fonts directory for the entire system
I used to think much the same thing but have sat in the corners of developers' chat rooms long enough to know that the /share, /usr/share, /usr/local, /usr/local/share, etc. redundancy actually has particular usefulness to people who either have many many different users on the system from different vectors (ssh, ftp, http, console, other hosted services), work with several different revisions of the same app at the same time for bug testing, or especially both. The current FHS leans towards pleasing the developers. GoboLinux, and what you would like, is an FHS which pleases the users and admins. The filesystem is is somewhat like a rubik's cube and, as hard drive technology is right now, can't be very easily rearranged.

What we really need is a dynamically addressable filesystem--like kernel memory. When User or Admin logs on the filesystem presents itself with .../lib and .../bin and .../etc directories arranged by application. When Dev logs on the filesystem arranges itself according to the current FHS. I see it as switching pages according to which app is currently in control. I imagine that the overhead for something like this would wreak havoc on drive heads, however, especially if 25 users are logged in at the same time. Perhaps each user needs a .map file not only for kernel hooks but for fs arrangement.

hhhmmm..

[nother_nix_hacker]

But is yet another source-based compilation system needed?

No, but why not? It's all the choice we have that makes OSS as good as it is. (It gives us the oppertunity to bulk post RTFMs at newsgroups too :) )

Descriptive path and OS X

[mroch]

The descriptive path thing sounds a lot like what OS X does, except that it goes all the way where OS X still has /usr, /etc, etc. although hidden. I wonder if Apple can patent or has patented that?

Re:Descriptive path and OS X

[Anonymous Coward]

What? Directory names and paths? Get real man!
I can imagine a patent like that "A new, revolutionary way to name the directories with descriptive names, instead of the old system, derived from too much coding in binary and way too much smoking weed, like /usr, /etc and /boot etc. "

Re:Descriptive path and OS X

[reidbold]

UPSTO Patent 131314155:
Naming things such that they are easy to find.

Sadly, I could see that happening.

Non-issue

[brunes69]

1. With Linux entering mainstream, hardly anyone uses the command line for things like file management anymore. They use file managers like Konqueror and Nautilus.

2. Even if you're afraid of X Windows, have you ever heard of tab completion?

Re:Non-issue

[Jameth]

Yeah, but who the hell starts them with capital letters?!?!?!

Even with tab-completion, I just got my time quadrupled! Frickin' shift keys.

Re:Non-issue

[Aneurysm9]

1. With Linux entering mainstream, hardly anyone uses the command line for things like file management anymore. They use file managers like Konqueror and Nautilus.

Wait, wait, wait, time, time, cut, cut, cut. That's a fucking joke, right? None of the Linux or BSD users I know use file managers for file management, except perhaps mc. And, given your second observation, I don't see why anyone would need to.

Re:Non-issue

[RoadkillBunny]

1. With Linux entering mainstream, hardly anyone uses the command line for things like file management anymore. They use file managers like Konqueror and Nautilus.

That's one think I like about linux. I can go around my files faster with the command line (using your point 2) than in any file manager.

Re:Non-issue

[dindi]

i use mc, non of the other shiny unusable stuff ...

but don't you at the end always end-up typing something to move/tar/cp files ?

My favourite example is when you try to copy a directory to a FAT filesystem (eg a cf card for my camera or PDA) and I end up typing
cp -r because mc and others just freak out because they cannot set/preserve permissions on the FAT ?

I ALWAYS end up typing things when solving even simple file copy stuff ..
DAMN I am even typing that message right now :)

on the other hand : I definetely do not drag&drop files

Re:Non-issue

[Anonymous Coward]

filename completion for pathnames with spaces is a bitch, especially with cmd.exe.

Re:Non-issue

[HishamMuhammad]

Every modern shell supports case-insensitive tab-completion. And in GoboLinux, this is enabled by default.

Try it, you might like it: on bash, just add

set-completion-ignore-case on

on your ~/.inputrc.

Re:Non-issue

[mattyrobinson69]

Why not just make a file manager/plug in for file managers to interprit /etc as /System/Settings and /home as /Home and stuff like that. Couldn't they implement an alias type thing (choose at install time) weather you want /etc or /System/Settings, and the file system could interprit them as either. does EXT2 support that, and if not, how hard would it be to implement? i dont mean sym links, that would be messy

Re:Non-issue

[Descartes]

1. Speak for yourself. I almost exclusively use CLI for file management the only time I don't is if I'm doing something like sorting several files into subfolders. The reason I like it better is that I don't have to take my hands off of the keyboard. I think a lot of the touch typists would agree that it really slows you down to have to take your hands away and look away from the screen to grab a mouse. So maybe I'm the "hardly anyone" about whom you were talking, but I think there is a pretty major subset of Linux users who don't bother with graphical file management. The other irritating thing is that it takes so long to load Nautilus (at least on my 50cc processor).

2. Whoop whoop, tab completion in the house. You can also do some pretty cool vi like things with bash that make interacting with the command line much faster.

Re:Non-issue

[red floyd]

man ln

In particular, look at the "-s" option.

Re:Non-issue

[mattyrobinson69]

ln -s /etc /System/Settings

that would be messy because the LSB dir's would all still be there

Re:Non-issue

[Felonious Ham]

What I want to know is: what is the point of system/language significant case-sensitivity at all? Is there ever a case in code for having to terms indentical except for capitalization? This is one of Windows' file systems (I think this is where it lives) advantages over Unix. I know you can turn it off, but it should institutionally removed (and from Java and XML too, since that's what I work in and it has never helped me and too frequently caused hidden problems).

Just to be clear, I like capitalization as a human, I just want everything in computerdom evaluated equalsIgnoreCase.

Re:Non-issue

[radoni]

bash at least makes this difficult

mkdir Chum
touch chumbun

then you start to type 'cd chum' and hit tab

it leaves it at 'chum'

correct behavior would change that to 'Chum'

needs work.

Re:Non-issue

[It'sYerMam]

I started with Nautilus, but I soon realised that gnome-terminal was a far cry from the DOS prompt. It's much easier to use, and in most cases it is easier than a GUI file manager.
Especially for traversing large directory trees. However, there're some things, like viewing my ~/documents/pictures folder, that having a GUI is very useful for (thumbnails.)

Re:Non-issue

[Anonymous Coward]

I dont know about bash, but tcsh can complete the cd command to only list directories.

So even if you did:

$ touch abcde
$ mkdir abcdefg

then

$ cd ab[tab]

it would complete to $ cd abcdefg

In fact, any command can customised, like acroread only completes dirs and files ending in .pdf

I haven't bothered looking at the parents case problem, it reminds me of case unsensitive msdos.

Re:Non-issue

[HishamMuhammad]

Well, I don't use bash myself, and GoboLinux ships with the One True Shell, zsh, as default. ;-)

Now seriously, give zsh a spin in the GoboLinux Live CD and you'll be a convert for life.

Re:Non-issue

[vadim_t]

There is plenty.

There are several languages where lowercase -> uppercase -> lowercase can't be done without losing data, for example. Then there is the problem of how many languages you can support. Say, English is easy, but what happens when you find a disk with filenames in an encoding the filesystem doesn't know about?

In Linux, it's just all bytes, it doesn't care if it's english, cyrillic or whatever. With case insensitivity it suddenly has to know what to do with cyrillic letters as well.

Re:Non-issue

[fishbot]

I particularly like rox (http://rox.sf.net) which has is small, light, does thumbnails and...

has tab completion. Simply hit / in any window, and it pops up a directory on the bottom. backspace takes you up a level, and there is tab completion for files/folders.

It's fantastic.

Re:Non-issue

[Anonymous Coward]

It shouldn't be a problem - it's just the braindead case-sensitivity of the Unix filesystem at work. This is one of the few areas where I prefer the Windows way.

Case-sensitivity is a problem. Sure, so it lets you have "makefile" and "Makefile" in the same directory - man, what a *useful* feature! I don't know how I'd live without it!

Now try writing a script to access files on a CD. Whoops - depending on how things are configured, files on a standard ISO9660 file system might appear in uppercase or lowercase! On Windows, no problem: use whichever you prefer and it'll work. On Unix? Uh-oh, looks like I'll have to handle both cases... that means complexity, and complexity is a Bad Thing.

Re:Non-issue

[Anonymous Coward]

I don't know which bash you're using, but mine doesn't do that. It autocompletes "chumbun" just fine.

bash --version
GNU bash, version 2.05b.0(1)-release (i486-slackware-linux-gnu)
Copyright (C) 2002 Free Software Foundation, Inc.

Re:Non-issue

[Crayon Kid]

Yeah, but who the hell starts them with capital letters?!?!?! Even with tab-completion, I just got my time quadrupled! Frickin' shift keys.

You must have a tough time writing any kind of text document. I mean, you'd think people who use computers are used to entering capital letters by now.

Re:Non-issue

[Zirtix]

My favourite example is when you try to copy a directory to a FAT filesystem (eg a cf card for my camera or PDA) and I end up typing cp -r because mc and others just freak out because they cannot set/preserve permissions on the FAT ?

Nautilus doesn't freak out on FAT volumes. Anyway, isn't this something you can sort out with mount options (like 'quiet')?

Re:Non-issue

[rgmoore]

The simplest and most obvious reason to make the computer case sensitive is because it's much, much easier to program that way. Any time you want to know if two filenames are the same you can just compare them bit by bit and see if they're exactly equal. Making the computer understand which characters are upper or lower case versions of which other ones adds some complication in a coding system as simple as ASCII. If you want to use something more complex, like Unicode, the problems multiply tremendously. Including a full Unicode library in the kernel- which you'd need to do in order to make things case insensitive at the filesystem level- would be a source of innumerable bugs and performance problems.

Re:Non-issue

[aardvarkjoe]

I love rox, but I've noticed that I only tend to use it for certain tasks: for instance, I usually keep a rox window to browse my music collection, and I use it when I need to handle a large number of files that isn't easily addressable using the shell. I still find that keeping an xterm open for file management speeds things up, in most cases.

Of course, one of the things I like about Linux is that we have lots of great command-line and gui tools, and can use whatever's best for the job.

Re:Non-issue

[bilenkey]

1. I don't think so. I find file management more flexible and quicker through my /dev/pts/* than through konq. I admit that *sh has a somewhat steep learning curve.
2. I use it all the time. I have just glanced through their doc and it looks like they stuffed all the executables in a single directory. There are plenty of reasons behind having /bin and /usr/bin ...

Re:Non-issue

[The Infamous Grimace]

Is there ever a case in code for having (two) terms indentical except for capitalization?

For me there is. I like to use C++, and do stuff like:

class MyClass {
private:
string name ;

public:
string Name( void ) { return name ; }

I like descriptive names. Just makes it seem more obvious whats going on, at least to me.

(tig)

Re:Non-issue

[Fruit]

Yes please, if zle would support multibyte character encodings. Which it doesn't.

Re:Non-issue

[ron_ivi]

"Is there ever a case in code for having to terms indentical except for capitalization?"

Of course. How else do you write

int calories = 1000 * Calories;

Calorie vs calorie

Nutritionists, when describing the energy content of food, typically refer to Calories (capitalized and abbreviated as C or kcalcal); one Calorie equals 1000 15 &#176;C calories,

Re:Non-issue

[HishamMuhammad]

That's one think I like about linux. I can go around my files faster with the command line (using your point 2) than in any file manager.

Some people would argue that this, instead, is an indication that your file managers are not good enough.

Re:Non-issue

[noselasd]

using common name conventions , that method ought to be called
getName()

Re:Non-issue

[Anonymous Coward]

They might argue that, but that would be like arguing "you don't need a car, your kiddie pedal-kart is just not good enough". Seriously, grown-ups use words. It boggles my mind that some people honestly think the computer interface equivalent of a "see spot run" picture book is somehow more desirable than a grown up verbal conversation with your computer.

I blame microsoft - they produced a command line that _really_ sucked, but that is most people's only experience of the command line, so people think "command lines suck", instead of what they should be thinking: "*Microsoft* command lines suck".

Actually, to digress a little, CLI and GUI are not mutually exclusive. If you're lucky enough to have used Common Lisp CLIM, you'll know what I mean, or you could have a play with Mozilla XMLTerm, which is somewhat similar.

Re:Non-issue

[ocularDeathRay]

QUOTE:

--hardly anyone uses the command line for things like file management anymore.--

I am hardly nobody, and I do all MY file managing at the command line... along with just about everything else. I am sure people like me aren't THAT rare.

anyway the nice thing about linux now is that we can set it up how we like. If you like to call /usr/bin something like /fart/knocker for example, I am sure it could be done. I can see where naming the directory structure more descriptively would make it easier for n00bs, however, I am no longer a n00b and it would drive me nuts to try to learn new directory names. I am sure that lots of people like me will resist this change and we will have yet another choice to make when installing linux. Fine... fragment off... name stuff however you want... WHO CARES ABOUT STANDARDS.... I mean this philosophy has worked fine for microsoft.

Yes choice is nice... but please be careful people, the last thing we need is another rediculous naming convention out there.

Re:Non-issue

[dufus4]

Try reading the site next time, mmmkay?
gobo@localhost ~]ls -a /
. .. Depot Files Mount overlay Programs System Users
gobo@localhost ~]ls /usr
bin include lib local man portage sbin share X11R6

It makes use of a simple kernel patch called "GoboHide" which hides the legacy tree from view unless you explicitly ask for it.
dufus@localhost ~]gobohide -l dufus
Hidden directories list for user dufus: /sys /dev /proc /usr /var /tmp /sbin /lib /etc /bin

It's very convenient too.

Re:Non-issue

[Anonymous Coward]

for people who use click-click programs like Konqueror and Nautilus, the /usr, /etc/, /var, /bin, /boot, /mnt, /proc, /sbin, and /sys should be automatically hidden as 'system directories' anyway, because if they are visible the luser is more likely to do damage to it. And the default moron directory is /home/$LUSER/Desktop or /home/$LUSER/My\ Files anyway.

Re:Non-issue

[The Infamous Grimace]

using common name conventions , that method ought to be called
getName()

Point taken.

(tig)

Re:Non-issue

[Smitty825]

using common name conventions , that method ought to be called
getName()

In C/C++/Java, I would certainly agree with you. However, if you were programming in another language (say Obj-C), then the accepted syntax would just be name()

Re:Non-issue

[Anonymous Coward]

excuse me, I use dual xterms baby. one at the source one at the destination

Re:Non-issue

[SpaceLifeForm]

And some people would argue that people that propose that argument are indicating that they can't manage their files good enough.

Re:Non-issue

[Short Circuit]

How about "softly" adding the support to an interperative-layer program? Something that intercepts filesystem activities like User-mode Linux does, and implements the renamings there.

You could also probably redefine the behavior of other libraries and system calls that way, too.

Re:Non-issue

[jonadab]

> In Linux, it's just all bytes, it doesn't care if it's english, cyrillic > or whatever. With case insensitivity it suddenly has to know what to > do with cyrillic letters as well.

I'd be happy if case-insensitivity were only supported for the twenty-six letters in the ASCII character set. I'd award extra bonus points for also handling accented Latin characters and allowing the user to type plain unaccented versions of filenames that canonically have some diacritical marks, hit tab, and have it "complete" by substituting the accented characters where appropriate. (Obviously, if there's a file called Resume.HTM and I type Resu and hit tab, it should complete to that first, only finding resumé.html if a closer match didn't exist. Whether it should find case-altered versions before versions with different diactritics is an open (but IMO unimportant) question. The key thing is to get the completion right when it's obvious which file is meant, and otherwise the user can either name his files more uniquely or cycle through several possible completions each time.

I understand why case-insensitivity isn't entirely straightforward in all languages, but I'm not asking for case-insensitivity for all languages; I'm asking for case-insensitivity for languages where it's really easy to do and traditionally assumed in many contexts (even many non-computer contexts) -- notably English. Consider it part of localizing the system for English-speaking countries, if you want. I'm sure other languages might have other types of localization that might not make sense in English. For example, I can readily imagine that Hebrew localization might include the ability to just type the consonants and have the vowells automatically filled in, or something like that. (I made up the example, but you get the idea.) Just because that would be a real pain and of limited utility for English doesn't mean it shouldn't be implemented for any other language. Just make it part of the l10n and users of other languages don't even have to know about it. But English should definitely have case-insensitivity at least optionally.

Re:Non-issue

[Felonious Ham]

I'll grant this example of a curiosity of scientific language, but I think it is the exception that proves the rule (the rule being that we should be case-insensitive, and prove, I think being "test"). Most laymen confuse these terms to the point where many texts (I'm thinking the back of food boxes) use kcal instead.

That that wouldn't be to much more descriptive to a layman, come to think of it.

Re:Non-issue

[Felonious Ham]

I'm not opposed to capitalization for clarity, and taking in the follow-on comments would change the class to:

class Name{
private:
string name ;
Name(string name) { this.name = name }

The point here is not that you wouldn't want to have a class name different only in capitalization from an instance var, but that you would never (because of the confusion it would cause to humans) do:

string name;
string Name;

Todd

Re:Non-issue

[The Infamous Grimace]

The reasons I've been doing it like I do is
1) I'm a bit of a noob and
2) using 'get...' and 'set...' adds typing. Trivial, yes, but there it is.

To me, it's just as intuitive to use

string myString = "something relevant",
anotherString = "something witty" ;
MyClass myClass ;

myClass.Name( myString ) ;
anotherString = myClass.Name() ;

as opposed to

myClass.setName( myString ) ;

My convention uses the form that the standard library functions use, or at least thats what I think I'm doing. Take strcpy( char * arg_1, char * arg_2 ); the first argument gets set to the second argument. Visually, one can see this relationship, even though there is no '='. Same for me. Whatever the class attribute is, the corresponding functions are named the same, only capitalized. To access an attribute, you ask for it by name. To set an attribute you again ask for it by name, only you give as it's agument whatever you wish to set it to.
Does this make sense? I'm out of coffee, and my caffeine levels are dangerously low this morning.

(tig)

Re:Non-issue

[vadim_t]

Excuse me, but that's extremely self-centered. While I and many other people know English well enough to use english-centered programs, many other people have environments completely in their own language. For example, in Spain pretty much everybody sees Spanish and other Spanish on the screen.

Also, "e" != "é" in many languages. For example in Spanish, some words have completely different meanings depending on whether they have an accent or not. Here's a quote of the mess you have to deal with:

Case folding is not easily defined in many European languages, both because many of them use characters outside the US ASCII alphabetic set, and because:

In Spanish, the digraph "ll" is considered to be a single letter, the capitalized form of which may be either "Ll" or "LL" , depending on context.

In French, the capitalized form of a letter with an accent may or may not retain the accent, depending on the country in which it is written.

In German, the sharp ess may be represented as a single character resembling a Greek beta (ß) in lowercase, but as the digraph "SS" in uppercase.

In Greek, there are several lowercase forms of some letters; the one to use depends on its position in the word. Arabic has similar rules.

Another problem you have is that Unix doesn't really know how to deal with Unicode properly. Unix is largely ASCII-only, evidenced for example by the fact that a text terminal can only have 256 different characters.

Then there are more problems. Don't think there's only Unicode. You'd have to deal with all the existing different encodings. There are different encodings for the same language, which contain letters in different orders. For example, take the russian koi8-r, which has the russian letters in the same order as their english equivalent. Removing the first bit converts russian text into an understandable english transcription. There's another one with the russian letters in alphabetical order.

If you move from the 'filenames are sequences of bytes' concept you suddenly have to implement lots and lots of stuff. Things like having the OS know about every encoding out there, how to change case, what characters are equivalent... and there's no API or support for all of this anyway. Say, 99% of all programs assume a filename should be stored in a char *, and on virtually every modern architecture, char == 1 byte.

Next, you'll have problems with similar looking characters. I send you a file with the name "answers.txt", and you won't be able to TAB-complete it, because the "a" is the russian one, even though it looks exactly the same.

Even if you added the OS support for Unicode (which probably would require making Unicode fonts and having the console display on a framebuffer to begin with), no existing program would see the improvement anyway.

Re:Non-issue

[jonadab]

> While I and many other people know English well enough to use english-
> centered programs, many other people have environments completely in their
> own language. For example, in Spain pretty much everybody sees Spanish and
> other Spanish on the screen.

That's fine. You can localize for Spanish all you want. People in France
and Africa can localize for French. I was talking about a very necessary
component of localizing for English.

> For example in Spanish, some words have completely different meanings
> depending on whether they have an accent or not.

Yes, also in Greek and various other languages -- but not in English. So those
languages (Spanish, Greek, ...) would localize such things as tab completion
rather differently from English. That's fine. I was only talking about how
it should be on systems localized for English. I'm quite aware of the fact
that it would be different for users who use other languages. If you go back
and reread my post, you'll discover I said that already.

> Then there are more problems. Don't think there's only Unicode.

Yeah, the people figuring out how to make l10n work for Hindi and Russian and
whatnot have to deal with those problems. However, they have no impact on
English localization, which is what I was talking about. Character sets are
largely irrelevant to English. We do have a few dozen words with diacritical
marks, most of them borrowed from French, but nobody ever types the marks,
because typewriters and computer keyboards don't support them. Books that
are typeset for publication have the marks, but stuff typed up by normal
people leaves them out, and it's not a problem. We still know what a facade
is even without the cedilla. In fact, there are some words that people get
confused about and aren't sure where the diacritical marks go.

As far as Unicode, there's an entire large continent where it's almost totally
irrelevant, because it's virtually impossible to buy a keyboard here capable
of typing anything other than ASCII. We couldn't use unicode if we wanted
to do so. If we want to type in a foreign language, we get a transliterative
font and use that. (For example, to typeset Greek, I use the Mounce font,
from Teknia, which allows me to type an a and have it appear as an alpha,
and so on. It even has the diacritical marks as separate characters that
display over the previous letter.) There are a number of difficulties with
this approach, but they are outweighed by the fact that this approach is
one we are actually capable of using with keyboards that we can buy without
going to Europe.

> If you move from the 'filenames are sequences of bytes' concept you suddenly
> have to implement lots and lots of stuff. Things like having the OS know
> about every encoding out there, how to change case, what characters are
> equivalent...

People who need to implement case-insensitivity for various languages will
have to deal with those issues, but we can implement it for English without
worrying about them. Like I said, for the purpose of localizing tab completion
for English-language users, it would be good enough to only support the letters
in the ASCII character set. Also supporting Latin-1 would be icing on the
cake, since most of use can't type those characters anyway. Forget about
Unicode; let the people localizing for other languages worry about that.
English-language users don't need it.

Re:Non-issue

[vadim_t]

Heh. Then I wonder what issue you have, since this exists already. See the bash manpage for the nocaseglob setting, and completion-ignore-case readline setting. Seems to do exactly what you want.

Re:Non-issue

[Anonymous Coward]

Ok how about

• long mg_of_stuff = 1000*1000*1000*Mg_of_stuff;

Or perhaps megagrams too tough for the layman too?

I'd say some might argue that 'God' is a specific subclass or instance of the base class 'god'; but I guess that's more of a religious debate.

Re:Non-issue

[nicolas.e]

If your system is properly configured, showing the /usr... to the users won't be harmful in anyway. That's more for simplicity that they should be hidden.

Ok...

[brunes69]

Now try doing that with say, Nautilus

Ooops! It's directories and files are scattered throughout the filesystem :P

Restricting programs to build into their own trees is an awesome idea IMO.

"Recipes" are a bad idea

[RovingSlug]

Knowledge for handling common situations is usually added to Compile itself instead of being coded in the script ... It remains to be seen whether this experiment of gauging differently the tradeoff between flexibility and simplicity

Yes, simplicity is good, but only in the context of the whole system. Here, you're just shifting complexity from the per-package scripts to the overall Compile package itself -- creating a large, central, monolithic service.

Because it's centralized, over time, this is going to accumulate a lot crap and become opaque, obfuscated, and unmaintainable. Changes and maintenance to Compile will more significantly impact the contemporary set of recipes than, say, changes to Portage and ebuilds.

It's easy to apply a good idea, like "simplicity", in too narrow of a scope -- to the detrement of the overall design. Better to think about it as balance of "package maintainability", "system maintainability", "barrier of entry", etc.

Re:"Recipes" are a bad idea

[HishamMuhammad]

Because it's centralized, over time, this is going to accumulate a lot crap and become opaque, obfuscated, and unmaintainable. Changes and maintenance to Compile will more significantly impact the contemporary set of recipes than, say, changes to Portage and ebuilds.

That remains to be seen. The implementation so far has been pretty proof-of-concept, more to get the model stress than to get the actual code. After all, code can be rewritten, but redesign is much more costly after you have a large database of recipes "out there".

I believe the modularity of the declarative model will help to keep the code manageable. The impact of side-effects can be much more precisely assessed.

It's easy to apply a good idea, like "simplicity", in too narrow of a scope -- to the detrement of the overall design. Better to think about it as balance of "package maintainability", "system maintainability", "barrier of entry", etc.

Worry not, we are not blindly going for "simplicity". We are applying it as a means to reduce package maintenance cost. A lower barrier of entry for new contributors is a welcome bonus we get.

And better system maintainability was the reason GoboLinux itself was created, and not to "attract newbie users" as many people say -- I created it for my own use, and I'm hardly a newbie. :) I was tired of package managers that broke when I compiled stuff "by hand". I wanted a system where those things integrated seamlessly (the /usr vs. /usr/local distinction is not what I call seamless).

Re:"Recipes" are a bad idea

[Anonymous Coward]

Because it's centralized, over time, this is going to accumulate a lot crap and become opaque, obfuscated, and unmaintainable. Changes and maintenance to Compile will more significantly impact the contemporary set of recipes than, say, changes to Portage and ebuilds.

Just because it's simple now doesn't mean it MUST become awful through time. A well-designed application can accomodate change. This takes some planning, though.

On the other hand, if the build scripts really are in a simple format, then if changes are made to Compile such that all the build scripts need tweaking, one should be able to write a program that automatically fixes them in a big batch job.

In fact, it would be wise to always have a parser for such files that creates an AST of the data in it--before it's ever needed. That way they can make changes to the format and keep the build scripts in synch without a big time-lag between the format change and the build scripts getting updated.

Re:"Recipes" are a bad idea

[Anonymous Coward]

Certainly it dosen't help that Compile is written using shell scripts rather than a more modern language. Hopefully it won't need to get too smart.

I started my own source-based install system before discovering zeroinstall and decided it was the real future of end-user software installs (wonder if P2P installs will get added into it?).

Source-based systems will likely evolve into distrabution managers used by distro developers only, that will used to setup master reference systems for end-users using zeroinstall.

my 2 cents.

Auto-completion

[Overly Critical Guy]

That doesn't matter much when hitting the tab key fills out the rest of the name anyway.

Unix paths

[Too Much Noise]

a distro that does away with Unix paths such as /usr/bin and /lib and uses things like /System/Settings/X11 instead

For all those thinking "what a nice idea":

afaik LSB requires FHS which, in turn, requires the standard directory structure. Does this mean we should throw the whole LSB out now?

And no, OSX is not LSB compliant - go figure.

Re:Unix paths

[FreeLinux]

Conversely, do you mean that there is no room for further change or improvement beyond LSB? Are we to follow LSB without change forever?

The Gobo Linux system creates its own directory structure using simple descriptive names. It looks loike a very nice idea to me. They also have links in place to allow compatibility with the Posix directory structure. LSB is not threatened. Yet.

Re:Unix paths

[Mycroft_VIII]

Not shure about LSB compatability, but they do maintain the appearance of FHS or simular through links and such so that apps see the directory structure they expect while users get a directory structure that is more intuitive.
It's possible LSB dependant apps could run just fine on this system.
I hope so, this kind of soulution is needed, the cryptic (to MOST people) unix style directory structure really need to go, or at least be hidden for Joe Sixpack to be able to use it. The only reason for not doing so would to to avoid breaking compatability, another thing that needs to stop happening so often if we want Joe Sixpack to dump windows for linux.
If this system is really path agnostic, and doese what is seems to say wrt to paths I'm a much happier person today. Definately a BIG improvement if true.

Mycroft

Re:Unix paths

[sirReal.83.]

And no, OSX is not LSB compliant - go figure.
This might be nitpicking, but I think you didn't read what the first letter in 'LSB' stands for - Linux :)

need?

[Anonymous Coward]

But is yet another source-based compilation system needed?

Are any new distributions needed? No.

Does it matter if someone feels that no more source based compilations are needed? No.

If someone wants to make one, more power to them.

My shift key!!

[vijaya_chandra]

When the poster mentioned
/System/Settings/X11

I had thought, he/she was trying to be funny

But the distro does seem to go this way : /System/Links/Tasks ,as the article mentions

Despite the intuitiveness, having capitals at the beginning of all the directories, particularly the ones that you are going to replace all the / dirs with, would be a major pain atleast in a case-sensitive *nix world

The current 'X11R6' in /usr itself pains lazy idiots like me with the capital X; I shudder to think as to what'd happen if this, in case, becomes the standard (or the fad)

(Karma be damned; I am no better than an AC anyway)

Re:My shift key!!

[sporty]

Lazy says the one who attempts to be completely correct in his/her post who used mostly correct punctuation and proper use of capital letters. Irony, thy name is vijaya chandra. Now that's hard to type.

Re:My shift key!!

[Danny Rathjens]

I completely agree. I think they were thinking from the GUI file manager perspective rather than the commandline. At least they didn't also use spaces like MS Windows. ;)

As for X11R6, I just do cd /usr/x<tab> and tcsh completes it case insensitively to /usr/X11R6/. This is one of the features of the enhanced completion mode.

From my ~/.tcshrc:
set complete=enhance #completion ignores case and r.m-p expands to read.me-please

Re:My shift key!!

[vijaya_chandra]

I had no choice, thanks to the Grammar and Spelling nazis after me

But to be serious, if it's probably once in a day or two that I am forced to be correct about the case of the letters in what I type in, say like a comment on /., I would be having no problems

But /etc, /var, /tmp, /usr would actually be the 27th, 28th, 29th *letters* in many a people's alphabet. Going for caps in such things would be most irritating to say the least

Re:My shift key!!

[paranoidd]

Actually, GoboLinux is shipped with a *very good* personalized ZSH, where one can easily type things like:
cd /S/S/X [TAB]
and it will automatically complete to /System/Settings/X11. Moreover, it also handles in a very pretty way capitals, so you can also type:
cd /s/s/x [TAB]
and it will expand to the same entry. No pain ;-)

Re:My shift key!!

[Anonymous Coward]

Despite the intuitiveness, having capitals at the beginning of all the directories, particularly the ones that you are going to replace all the / dirs with, would be a major pain atleast in a case-sensitive *nix world

As somebody else mentioned, you can configure shells like zsh and bash to be case-insensitive. But I'm questioning whether Linux should be case-sensitive.

It was originally because low-powered computers couldn't really afford the CPU time for case-insensitive matching, but thirty years on, I'm sure this isn't an issue any more. In any case, how often is it that you have two different files with the same name but one uses caps and one doesn't? Is there really any benefit to case insensitivity?

Re:My shift key!!

[vijaya_chandra]

Well case insensitivity would have a *huge* impact on the maximum number of files in a folder
If we take the possible non alphabetic chars in a file name to be 26(0-9 the chars above them,{,},?,,.....)

with case sensitivity it would be (26+26+26)^255
but if it is case-insensitive it'd only be (26+26)^255

The difference'd be like (1.5)^255
Just check how many zeroes you would be losing in the big number

You won't want linux to fall behind in the corporate mumbo-jumbo. would you??

the site is worth visiting

[dankelley]

Even if you're not interested in 'Compile', the website is well worth visiting. These folks have some new ideas, and they don't seem to be just gratuitously new. (By 'gratuitous' I'm thinking of changes that yield no new power, such as the differences in directory structures between some of the linux distos.) Slashdot readers might find it particularly interesting to consider the alternate ideas about system/application directories used in this system.

I've recently switched from linux to OSX, and I've learned that the latter has some clever ideas (e.g. bundles) that can leverage developer effort. Given this context of learning by changing, my own view is that this new direction for linux is worth investigating ... not that I'll likely leave OSX anytime soon.

The "declarative" approach

[YetAnotherName]

This is similar to the evolution from ant to maven for Java developers. With ant, you gave the steps necessary to build your system, an imperative approach. With maven, you instead describe the shape of your system, and it figures out the steps.

Projects become more uniform as a result, and developers spend more time building the projects instead of maintaining build systems.

My only concern is the knowledge or experience that's lost as a result; larger and larger groups of developers have a smaller and a smaller understanding of the tools, environment, and subtle filesystem dependencies that systems tend to have, putting the experience in in-the-field debugging into a relative tiny number of cutting edge high-priced consultants.

By the way, I'm available. ;)

Re:The "declarative" approach

[Sekmu]

My only concern is the knowledge or experience that's lost as a result

I believe this isn't so much that the knowledge is lost - it's rendered unimportant to the larger group. This allows the developers to spend their time where they would otherwise be working on or learning the intricacies of the system on more development and new ideas. (or more likely, more unreal tournament)
There will still be those people who know and work on the tool itself - but this will be a smaller subset taking their time to make everyone else's lives easier.

autoconf, install scripts, dist packages, etc, are all progressions of not requiring the developers or users to worry so much about the intricacies of development or installation, and to spend their time on things other than the tools.

Just what the Linux community needs!

[Prod_Deity]

With the simplistic file paths, and with a pretty decent amount of packages already, this is the distro that I might share with my friends. Especially since it's a Live CD.

After I get home from work, I'll download it & give it a spin, that's for sure.

Even if some might consider this a "dumbed down distro", this idea makes me thing that it could be one for tha masses.

Time will tell.

Re:Just what the Linux community needs!

[vena]

i think people that consider deobfuscation "dumbing down" may have undiagnosed social problems :)

Re:Just what the Linux community needs!

[vadim_t]

Go and try to read the LFS standard some time. The current layout actually makes sense. And I don't really see how renaming /usr to /System or whatever is going to make things any simpler, anyway.

Re:Just what the Linux community needs!

[vena]

sure, it may make great sense - if you read the LFS standard.

Re:Just what the Linux community needs!

[Prod_Deity]

What I ment by my post was that this is a great idea to bring in Joe Sixpack into the Linux world.

They don't know what "/usr/local/bin" is for, and they probably don't care to know.
What they DO KNOW is "C:\Program Files\foo"

That's probably one of the reasons why there is a high turnover rate of people going back to Windows from *Nix.

If I can help someone get away from Windows and turned onto Linux, I've done a good deed.

I've tried to bring them over with Knoppix, but one of the problems is that they can't grasp the file system.

This distro might just help out in my crusade.

Re:Just what the Linux community needs!

[vadim_t]

Huh.

Right, Joe Sixpack doesn't have any idea of what say, "C:\WINNT\assembly\GAC\System.EnterpriseServices" is for, and that doesn't stop them from using Windows for some reason. It's not like using long filenames makes these things much easier to understand.

A Linux user doesn't have to know what's /usr for. There's /home, and it it there's joe's home directory, and that's pretty easy to understand.

Re:Just what the Linux community needs!

[IdntUnknwn]

Perhaps you meant FHS?

Re:Just what the Linux community needs!

[HishamMuhammad]

As I mentioned in another post, the directories were not renamed. They are new directories with different semantics, they function differently. I had to choose names, and I picked descriptive ones (long names in a tab-completion world are a non-issue) and used capital letters (caps in a case-insensitive-tab world are a non-issue) in order not to clash with the (yes, ever-changing) Unix namespace.

That was back in 2001. Imagine if I had chosen /sys instead of /System back then. That would have been a bad, bad idea.

Re:Just what the Linux community needs!

[Anonymous Coward]

Naw, I imagine the turnover rate is because most of us get stuck with either gaming or employment that doesn't work outside of Windows.

sounds good to me

[zogger]

I'm in favor of anything that would help users find the dad gum files. I get lost all the time, I fully admit it. I even would go for full static programs, to heck with saving space. I *might* try this one out. Glad someone posted the article, I never heard of them before.

Why confuse matters?

[nurb432]

The current file system setup is mostly standard now. No matter what Unix variant you use its pretty much the same.. ( not exactally, but they are all close enough to get around them ) Why go and change it 'just because we can'. "Better" is relative.

Re:All I want is SATA RAID support

[Nasarius]

Debian and Gentoo are the only ones, AFAIK, that do, and they both are teh suck.

Nice, you just managed to enrage the two biggest groups of Linux zealots in one go. :-)

Re:All I want is SATA RAID support

[Anonymous Coward]

I'm sorry, did you just call Debian and Gentoo fringe distros? They're the only two acceptable distros for any power user.

docs

[Anonymous Coward]

I personally couldn't care less about simplicity -- as long as there is good documentation. Preferably practical documentation with examples. Ebuilds are probably ok, if I only knew how to write the friggin' things.

Jury Still Out

[Ann Elk]

From their web site:

To maintain backwards compatibility with traditional Unix/Linux apps, there are symbolic links that mimic the Unix tree, such as "/usr/bin -> /System/Links/Executables", and "/sbin -> /System/Links/Executables" (this example shows that arbitrary differentiations between files of the same category were also removed).

The "differentiation" between /usr/bin and /sbin is hardly arbitrary. /usr is often on a separate partition; /sbin must be accessible even without other partitions mounted.

But the concept is interesting. I plan to download the .iso and give it a spin. (VMware is great for this type of thing.)

Re:Jury Still Out

[dj_paulgibbs]

FYI, the "install" is a Live CD, so you can boot straight into it, saving the emulation layer of VMware (I'm not dissing VMware; that's been very useful for emulating various operating systems from other operating systems in my experiance).

UNIX filesystem has *always* eveolved

[darkonc]

The filesystems for the UNIX family of OSs has always been in evoloution. Originally the /usr filesystem stood for /user. All user directories were in /usr and /usr/bin was for user contributed binaries.
Then many of the binaries in /usr/bin became 'standard' parts of distributions, and we started using /usr/local/bin for user contributed binaries -- and we started putting user home directories in places like /home.
Now /usr/local is becomming the standard place for 'standard-nonstandard' binaries and we're really starting to need a new place for real user contributed stuff (rinse, repeat).

I don't see anything intrinsically wrong with a complete bottom-up rewrite of the current system. The whole point of Free Software and Open Source is that, if you don't like it the way it is, you can change it. Clearly the current GoboLinux system isn't for the faint of heart, but something really good may come out of it that would increase the usability of Linux by an order of magnitude -- but magic like that doesn't happen if people are constrained to the old way of doing things.
It may be that, in 10 years, most Linux users will be going "/etc? What's that for?". (hmmm. Some may already be doing that!).

Re:UNIX filesystem has *always* eveolved

[Anonymous Coward]

And I always thought USR meant Unix System Resources...

Re:UNIX filesystem has *always* eveolved

[Mr Smidge]

Then many of the binaries in /usr/bin became 'standard' parts of distributions, and we started using /usr/local/bin for user contributed binaries ... Now /usr/local is becomming the standard place for 'standard-nonstandard' binaries

You know what they're really for?

* /bin is for binaries that you need to use the system in single user mode (i.e. no 'user' involved).
* /usr/bin is for binaries that a user might want to use, like those of your average set of applications.
* /usr/local/bin is for binaries that are local to the machine.

Why the separation? Imagine you run a lab full of computers.. chances are that they'll have the same main applications. Well, you can have /usr mounted via NFS then. Say you have a few graphically-oriented machines in your lab.. Perhaps they would have their graphical applications in their /usr/local/bin, since they only apply to the local machine.

I imagine that many people won't need that degree of separation, but it's there should you need it. If you don't need it and desire simplicity, just mask it with some symlinks.

On the subject of the main article, I could imagine, with perhaps some filesystem tweaks with regards to symlinks, that a filesystem along the lines of GoboLinux's could be very useful indeed. I'm not quite so sure about *replacing* the current hierarchy rather than just *masking* it, but perhaps some two-way strategy can be used...

I mean, if I have some apps in /usr/bin, and some local ones in /usr/local/bin, it would be great if they all transparently appeared in /Applications/$AppName..

That would be cool.

Re:UNIX filesystem has *always* eveolved

[accensi]

IMHO, "usr" stands for Unix System Resources. Let's got ask the best expert in *nix history, Ken Brown of AdTi! Certainly he has someone that tried to email Ken Thompson or Dennis Ritchie about that!

Re:UNIX filesystem has *always* eveolved

[Anonymous Coward]

Actually, /usr was first used as a user folder, but when the use of it changed, it was turned into an acronym for UNIX System Resources.

Re:UNIX filesystem has *always* eveolved

[calica]

It sounds like you're more concerned about mount points than anything. Realisticly, you'd what everything installed locally for performance. Drives are cheap and so much faster. But regardless, imagine the following:

/ [root fs] /Mount/NFS-Apps [Apps available via NFS server] /Mount/Local-Apps [Apps on local 2nd partition]

Then it is just a matter of creating symlinks from: /Programs/Foo ==> /Mount/NFS-Apps/Foo
or /Programs/Foo/1.0 ==> /Mount/NFS-Apps/Foo/1.0 /Programs/Foo/1.2 ==> /Mount/Local-Apps/Foo/1.2

Re:UNIX filesystem has *always* eveolved

[spitzak]

Actually what happened is that initially /usr was for home directories like you said. There was no /usr/bin.

The problem was that /usr was the "big" disk, while other things in / were on the "small" disk. This was before symbolic links, so if you wanted to store anything on the big disk it had to start with /usr. As soon as space was needed for more system files, they started appearing under /usr. Eventually /usr got so cluttered people started moving the home directories somewhere else. "Unix System Resources" is a joke backronym to try to hide this, the initial Unix design used "/" for this purpose.

Re:UNIX filesystem has *always* eveolved

[bigusputicus]

/usr, /bin, /usr/bin existed prior to nfs

Re:UNIX filesystem has *always* eveolved

[Stephen Samuel]

You know what they're really for?
* /bin is for binaries that you need to use the system in single user mode (i.e. no 'user' involved).
* /usr/bin is for binaries that a user might want to use, like those of your average set of applications.br> * /usr/local/bin is for binaries that are local to the machine.

That's how they're used now, but it's not quite how it was originally used. Like I said, it's evolved over time. On Solaris, for example, /bin is symlinked to /usr/bin

If I knew you...

[brunes69]

I would challenge you on that.

And I would win.

Apple are hypocritical

[nslu]

Yes, that is absolutely sweet and it is done that way for most third-party apps.

And if app needs to register itself as a handler for some mime type or for some protocol - it does it on launch, every time, so moving it doesn't break anything. Also add OS X links based not on path+filename but on uniq numeric file id and it becomes so nice and trivial...

Except that Apple itself for some reason insists on using pkg installers, which do nobody-knows-what and have not uninstall capability(*).

*Yes, you can parse receipt which is left after installation somewhere in /System and remove files using it.

Re:Apple are hypocritical

[Zirtix]

if app needs to register itself as a handler for some mime type or for some protocol - it does it on launch, every time

What? I don't use OS X, but that sounds crazy. Assuming only your web browser is running, how does the system know which email app to run when you click on a mailto: link?

Re:Apple are hypocritical

[Anonymous Coward]

Just to point out that RISC OS has been doing this for a very long time...

Re:Apple are hypocritical

[McDutchie]

if app needs to register itself as a handler for some mime type or for some protocol - it does it on launch, every time

What? I don't use OS X, but that sounds crazy. Assuming only your web browser is running, how does the system know which email app to run when you click on a mailto: link?

He's incorrect. Protocol handlers are registered using the application's signature (same thing as classic Mac OS's creator code), which is independent of the program's directory location. The system only needs to keep track of where the registered appliations are moved, which I imagine happens transparently in the background.

Sandbox? Dependancies?

[pantherace]

On reading the some of the docs on the website, I see no reference to something like sandbox.
Sandbox for those of you unfamiliar with gentoo, provides a method for making sure that durring the build no file outside the directory can be written to, so malicious scripts (say someone cracked a project & changed configure for example) & whatnot wouldn't be able to work. It doesn't rule out trickier exploits (backdoors etc actually in the code) but does make it safer.

Now I saw no mention of something like that on the compile documentation. Does it have something similar & where is documentation on it?

Secondly, how does it handle minimum dependancies, eg kde-3.0.0 relies on qt-3.0.0 & similar things, & won't build on versions older than that. For example, looking at Abiword, It looks like you have to know EVERYTHING required & have that installed, with no way for compile to determine what Abiword depends on. If true, then that seems like a step backwards from any rpms, debs or ebuilds.

Re:Sandbox? Dependancies?

[koali]

Huh? So it protects you while the package is built but not when you actually execute it... why is that useful?

I always thought that the Sandbox was there to keep track of all the files the package installs, for the unmerge procedure...

Re:Sandbox? Dependancies?

[pantherace]

As I mentioned: any compromised build scripts. If someone managed to get malicious instructions into a build script (as mentioned: configure) or in the make file, etc.

It doesn't matter what distro it is for the execution if it's in the source code (as in someone has coded in a back door that hasn't been noticed), because any build system that I know of won't see it or be able to prevent it.

Now, sandbox does prevent things from happening like build scripts accidentally over writing things if either the writer is incompetent, or if the package has somehow become corrupt (in between an md5sum of the compressed files & the actual building).

It's just another layer of protection. If someone managed to get a corrupted md5sum into portage for example, with your package, sandbox would stop any attempt to write to anything outside the directory it's being built in. Of course, gentoo's portage tree has never been cracked (a single portage rsync server has been, but portage was not touched, and it was quickly taken down. (this was around the time that Debian & others were having )

Re:Sandbox? Dependancies?

[HishamMuhammad]

On reading the some of the docs on the website, I see no reference to something like sandbox.

Yes, Compile uses a sandbox. I am somewhat familiar with the Gentoo sandbox, and our approach is different. Instead of trapping system calls, we install programs using a non-priviledged user which has only temporary access to the program directory it is supposed to work on. You see, this solution uses only the standard Unix permissions system with no ld hacks, and is only possible because of the GoboLinux filesystem layout.

Now I saw no mention of something like that on the compile documentation. Does it have something similar & where is documentation on it?

As mentioned in the Compile page linked by the article, documentation is included in the Compile package.

Secondly, how does it handle minimum dependancies, eg kde-3.0.0 relies on qt-3.0.0 & similar things, & won't build on versions older than that.

Hate to "RTFA" again, but it does support dependencies, and this is also mentioned in the Compile page.

Re:Sandbox? Dependancies?

[Crayon Kid]

Now I saw no mention of something like that on the compile documentation. Does it have something similar & where is documentation on it?

Compile does implement sandboxing. Check out the list archives or join the GoboLinux mailing list and ask about it. It's been implemented for quite some time, since it's an important concept.

Re:Sandbox? Dependancies?

[pantherace]

Thank you for your response on the first question.

Hate to "RTFA" again, but it does support dependencies, and this is also mentioned in the Compile page.

I did RTFA, 2 times before posting, and links from it, I just read it a third time, and read the README in the Compile package. Maybe I wasn't clear: I saw something (can't find it now, perhaps it should be on the documentation for compile...) that led me to believe dependencies are made after the package is compiled. I was thinking more in terms of compile dependencies. I looked at abiword's recipe for example: no reference to GTK or optionally GNOME at all. Does compile just know to build abiword requires GTK, or do you have to have all the dependencies already, somewhere not associated with the recipe file?

Dependencies are checked by configure and the program is linked to the correct libraries present on your system, with no incompatibilities. http://www.gobolinux.org/index.php?lang=en_US&page =doc/articles/compile
supports GoboLinux-style dependencies: software compiled "by hand" by the user is taken into account by the detection mechanism. http://www.gobolinux.org/index.php?lang=en_US&page =compile

Those are the only two statements I can currently find about it. Perhaps you should be a little less RTFA, or point me to an Article which says more.

Re:Sandbox? Dependancies?

[calica]

It is somewhat confusing. When a recipe is being created there is no Dependency checking. After the intial compile (of the recipe author) a Resources/Dependencies file is created automatically using some ldd and other tricks. Once the recipe is contributed there is an existing Resources/Dependencies file and it is used.

Does that help?

Re:Sandbox? Dependancies?

[HishamMuhammad]

I did RTFA, 2 times before posting, and links from it, I just read it a third time, and read the README in the Compile package. Maybe I wasn't clear: I saw something (can't find it now, perhaps it should be on the documentation for compile...) that led me to believe dependencies are made after the package is compiled.

Oh, yeah, sorry, I assumed you just implied there were no dependencies at all, my bad. In fact, dependencies are made after the package is compiled, the first time, by the recipe author, and this information is then reused by the recipe users.

I was thinking more in terms of compile dependencies. I looked at abiword's recipe for example: no reference to GTK or optionally GNOME at all. Does compile just know to build abiword requires GTK, or do you have to have all the dependencies already, somewhere not associated with the recipe file?

That's a bug in the AbiWord recipe, it ought to include a Resource/Dependencies file. This means it was created with an old beta of Compile which did not "export" dependencies. The first release was just released this week (1.0.1; 1.0.0 was in the last GoboLinux release candidate), and many recipes do not explore all Compile features. We are fixing things as we upgrade packages and get reports/fixes; of course, our resources are limited because we are a small distribution.

The other issue you raise, about the GNOME optional dependency, is a current Compile limitation, and a clean way to implement this is still under discussion in the GoboLinux list.

Those are the only two statements I can currently find about it. Perhaps you should be a little less RTFA, or point me to an Article which says more.

You're right, and I apologize. The documentation is currently terse (and the README serves at most as a reference API for the people from the mailing list). I did not spend much time documenting Compile's support for dependencies because it is basically the same as the usual GoboLinux approach for dependencies, so writing "GoboLinux-style dependencies" was enough documentation for the target audience the development snapshots were aimed at (those who were already GoboLinux users).

Re:Sandbox? Dependancies?

[pantherace]

Ah, Thank you for your response. I appreciate it.

Does it record the particular versions needed? In the example I used kde-3.0.0 might depend on qt being at least 3.0.0. How does it know the minimum version required? Or does it just require whatever version the first packager had on their system? There are some cases where a package needs libraries below a certain point (gtk1 apps for an example) is there some way to for it to know GTK less than 2.0?

As for optional dependancies, you could go the route that some do (rpm) with packages like qt-mysql, etc. but that only works for some, others need it at compile time. So far, Gentoo's USE flags seem to be the best, unless you want to create packages like abiword-gtk & abiword-gnome which are mutually exclusive. (but then you have to add in something that allows a package to use either if it just depends on abiword, so it becomes more work)

Same as Portage ebuilds

[vslavik]

The authors apparently don't have a clue about ebuilds, otherwise they would try to use simplicity as this system's selling point - ebuilds are already there, they are about as simple as they can get if you want it to be useful for a real distro. Looks more like a manifestation of Not Invented Here syndrome than anything else to me.

Re:Same as Portage ebuilds

[Anonymous Coward]

Well Not Invented Here is perfectly fine with Portage. It's a piece of garbage. It's a wonderful idea, but the implementation is the worst abuse of Python that I've ever seen. It displays an absence of understanding of even basic computer science and software engineering.

parent makes a great point

[vena]

i was also wondering if the concise directory names had anything to do with the smaller hard drives of the past. if so, then it would seem only natural to deobfuscate the file system now that we actually can.

Re:parent makes a great point

[CJ Hooknose]

vena wrote: i was also wondering if the concise directory names had anything to do with the smaller hard drives of the past.

No. Directory names (and common commands like ls and rm) were traditionally short on Unix because comm speeds were very slow in the 70's and 80's. When your terminal's running at 110 baud, you don't want to type any more than you have to. Things are a lot faster now, fewer people use the command line, and tab-completion helps those who do--so we could theoretically have /User/Binaries/Games/ instead of /usr/bin/games . The old pathnames persist mostly for tradition's sake and backwards combatability.

short and descriptive not mutually exclusive?

[Bob the Hamster]

I don't know if anybody does this, but in theory I like the idea of a directory structure that mixes posix pathnames with descriptive pathnames. For example, everything could be installed into long descriptive pathnames by package, but the binaraies could all be symlinked into /bin the config files could all be symlinked into /etc and so on.

Rox

[tolan-b]

Rox Desktop / Filer (GTK) does this for Linux, and the filer app (sort of Nautilus replacement) is blindingly fast too.
Scroll down to "Applications are directories"

Shared libraries can't be in private locations

[Anonymous Coward]

You can't install shared libraries in an application's own private directory.

What's more, a good system would have virtually all of it's functionality in shared libraries that all apps USE, with only the very core logic of the app and it's GUI in a private application executable.

Debian does it right, imho. It manages installed libraries, as pretty much its first priority. Path names of libraries really don't matter when everything is installed fine and just works.

I'm all for ditching the paths

[Mustang Matt]

While I'm used to the current paths, I have no hard feelings at all about ditching them.

I don't know if there's a linux standard for what kinds of files go in each directory but everyone I ask has a different answer.

I think switching to an updated naming scheme for directories and getting a common installation/uninstallation routine for applications that actually sticks items on the menus in the guis, etc. would be a huge move forward.

Not that I need either feature. I don't even use a linux gui. But someday maybe I will.

Re:I'm all for ditching the paths

[platipusrc]

If you're confused about how the directory hierarchy in a typical Unix-ish system should be setup, consult man hier, or if your distro failed to include that, see this hier man page.

Re:I'm all for ditching the paths

[Mustang Matt]

Very good info. That actually clears things up quite a bit.

Re:All I want is SATA RAID support

[benjonson]

Debian and Gentoo are the only ones, AFAIK, that do, and they both are teh suck.

Nice, you just managed to enrage the two biggest groups of Linux zealots in one go. :-)

Nonsense. Now emacs and vi: those are teh suck.

Re:where the hell are my files?

[im a fucking coward]

locate and/or slocate are excellent tools for this. You may need to 'updatedb' as root in order to build the initial database of filenames / paths, but then it becomes extremely easy to '$ locate filename', and is a whole lot faster than using 'find' to traverse the entire directory structure to hunt down one file.

See Filesystem Hierarchy Standard for an expanded explanation of the filesystem structure, though your distro may vary significantly from it.

Compile doesn't use a specialized language

[theefer]

As far as I can see by browsing a few recipes from your repository, you have not developped a special scripting language for it. It's simply bash scripts, with facilities through the usage of common variable and functions that trigger different behaviors.

If I take Armagetron recipe, for instance, it's not really that user-friendly in my opinion. Or, at least, not really more user-friendly than a Gentoo ebuild. Okay, the armagetron ebuild is longer, but it also contains more meta-data (dependences, license, architecture, etc) and it obviously has to install the program in the standard Unix file tree.

So basically, Compile looks like a lighter version of ebuild, but it is certainly not a revolution in the way you have to write the recipe/ebuild. I think GoboLinux looks different enough to make me try it one day, but in my opinion, the recipes do not improve much (assuming they do at all) from the Gentoo ebuilds to be as user-friendly as the inial poster said.

Disclaimer: yes I'm a Gentoo user, but still, kudos to the GoboLinux devs for making it happen anyway !

Re:Compile doesn't use a specialized language

[HishamMuhammad]

Yes, I basically agree with you. The Armagetron recipe shows the "ugly" side of recipes: the support for imperative constructs, which often slip in declarative systems (ask any functional programmer...).

In this particular example, I think the recipe author could have avoided the pre_build function using a patch instead. I recommend that very strongly to users, because patches are easier to maintain when writing a new recipe based on a existing one: patches make "rejects" when they change from one version to another, whereas that sed command will fail silently if the recipe writer is not careful. With a patch instead of the function, the Armagetron recipe would be reduced to 3 declarations.

But yeah, there are cases when ugly imperative functions will be impossible to avoid. This most likely means that the design of the project's build system is pretty screwed up.

What I, personally, try to do in those cases is, instead of writing a marvelously smart recipe, is to contribute a patch to the project itself. Most of the times, it's just $prefix-awareness missing, or something like that. Often the effort people spend working around build inflexibilities in distro-specific scripts would be much better spent improving the programs themselves.

It's usually less work to "fix the program" than work around it. For a few key packages for GoboLinux I even contributed the autoconf scripts, and it was way less work than I thought it'd be. The one thing I like about this approach is that it helps the entire free software community, making for smaller recipes, smaller ebuilds, smaller specs, and so on.

Sure, it ain't revolutionary today, but revolutions don't happen from night to day... they are secretly planned for a long time before the strike. :) What we're doing here is just trying a different approach. Time will tell if it produces revolutionary results. :)

Comment removed

[account_deleted]

Comment removed based on user account deletion

Partial upgrade

[October_30th]

This means that when I upgrade my system from scratch

Ok. I've never done that.

Upgrading an existing installation sounds like asking for trouble. I'll rather take a backup of my files, format the drive and install everything against. In my experience doing a partial upgrade will only screw up the installation anyway.

Re:Partial upgrade

[Anonymous Coward]

In my experience doing a partial upgrade will only screw up the installation anyway.

That's because all of the binaries are mixed in together. If you kept all of package foo's files in its own directory, then separate them again by version, you don't have to worry about dicking some package over by installing a new package. All you have to worry about then is removing packages, and only then because of dependencies (which the package manager should be keeping track of for you). That said, I don't like GoboLinux's way of breaking the packages apart. The majority of the software for Linux (and the BSDs too, probably) comes as a discrete unit, either as a binary package or a source package. The division on disk should be by those discrete units.

For example, suppose I have package ``foo.'' The top level directory for all of my packages is /usr/pkg. Foo's directory is /usr/pkg/foo, and each version of foo gets its own directory as well: /usr/pkg/foo/foo-2.1.3. Under that directory, the expected directories exist, namely bin, lib, info, man, share, and so on. Now there's no possibility of mixing packages up. There's no difficulty installing foo-2.1.4 now, because it goes into a totally separate directory. If I've got one working computer than can't afford to be broken, this system has even more advantages. If foo-2.1.4 is borked somehow (maybe due to a wrong compiliation switch, etc), then I can uninstall it by deleting its directory. Best of all, foo-2.1.3 is still there. Lastly, if you hate this arrangement, it's easier to merge the directories than it is to separate the files back out.

Gobo maintains compatibility by symlinking all those files back into the standard Unix tree. A package manager called Encap works similarly. I dislike the symlink approach, because it uses up twice the number of inodes in symlinks, on top of what gets used up by having each package have its own directories. For the most part, it's possible to keep track of things with environment variables, but when your $MANPATH variable gets long enough, there are noticeable delays while it searches the path. The same goes for $PATH, but shells will cache a program's location, so it's not that big of a deal (and even so, it'd be worth it just to keep the binaries separate). DragonflyBSD is planning to do a filesysetm overlay to handle this (if I understand their documentation correctly). If everything works out right, they'll have the best of both worlds.

The problem with all of this is that it's entirely different from the normal Unix layout. Most existing tools expect your include files to be in /usr/include, your libraries to be in /lib /usr/lib or /usr/local/lib, and deviation from that causes a lot of trouble. When I install a library, it doesn't necessarily delete previous versions of that library, but it'll change the main symlink to that library to be the new version (and reinstalling an older version will probably change the symlink again). Another problem is that autoconf doesn't list a program's dependencies. If you have a library installed in an odd location, you're informed of it as part of an error. It would be trivial to just list the dependencies as part of autoconf's operation. Basically, if something like this were done on a large scale, it'd require a LOT of changes in preexisting tools.

There's certainly a need for change, though. The majority of Unix-like installations are people's home PC installs. Often, this means that Joe User has one computer that he can't afford to bork over. If installing one program ate another program's files, then Joe User is in trouble. Think about what happens if he's trying to upgrade gcc, compiling everything from source? If the install doesn't go just right, then he just overwrote his working C compiler.

usr != user

[boredMDer]

Oh and I just love how there is usr/local/sbin, OR usr/sbin, and WHY usr? If 'local' can have 5 letters, would it be so deadly to spell out 'user'?

Hmm, maybe because 'usr' is an acronym for Unix System Resources, not short for 'user'?

Re:usr != user

[squiggleslash]

No, it isn't. usr was originally where users home directories were stored, amongst other things.

Think about it: "Unix System Resource(s)" isn't merely historically inaccurate, it would also be an absurd choice of name given that it no more applies to /usr than it does /bin, /etc, /lib, /var, or /sbin. (/etc used to contain everything now in /sbin too. Can you imagine what a PITA that was?) And why put "Unix" in the name? It's not in any of the other names, and they're all (or were all) unique to Unix!

While this particular myth is a little annoying, it isn't half as bad as the collegue I know who thinks the correct pronounciation of /etc is "Ett Sea"...

Re:usr != user

[squiggleslash]

/home is a modern development and exists because the user directory, /usr, was being overloaded with jobs above just containing user home directories.

/usr does not stand for "Unix System Resources", something I'm pretty sure was invented by a troll somewhere as a joke that's come to be believed by a few too many people. (Think about it, it has "Unix" in the name? It's so generic it could apply to almost any directory in *IX? Why would they have called it that?)

Re:where the hell are my files?

[zogger]

thank you for the link and the tips! Most of the time I don't need to find a file,just I am always wondering though where everything goes and fits in. Gradually starting to work out for myself how this all works together. I know if I had started with linux or unix many years ago I would know all this stuff, but I didn't, only started using linux in the "pretty good enough" GUI age, and as such, my knowledge of hierarchy and CLI is woefully lacking.

Logic rant

[gidds]

[English teacher mode: on]

Er, no, it doesn't 'beg' the question. It raises it without answering it, certainly; but that's not what begging a question means.

Begging a question is assuming it, using it in a circular argument.

[pontificate mode: on]

I find it strange and depressing that a community which is, in general, so careful and precise about its use of computer languages, should be so cavalier in its treatment of human ones...

Re:Logic rant

[scrytch]

I find it strange and depressing that a community which is, in general, so careful and precise about its use of computer languages, should be so cavalier in its treatment of human ones...

Consider the possibility that the phrase "begging the question" came first to mean "demands a question be asked", then later became applied as jargon to mean an implied "first" as a translation of "petito principi", i.e. "begging the first [question]". Or show me where "circular" is anywhere in the definition of "beg".

Try thinking critically of your own knowledge sometime. Hell, try imaging that it doesn't impress anyone regardless. I'll go one on one with almost anyone here in logical formalisms, I know my contradictories from my subcontraries thankyouverydamnmuch. I'm kind of saddened by a lot of things wrong with this world, but semi-improper idiom usage sure as hell ain't one of them. I'll keep using the phrase, if only to tweak the priggish.

Oh! My! God!

[The Infamous Grimace]

Now if they fix cut and paste and find a way to make havening both a *nix and a windows version as close as possible to a simple recompile...

It's George!

(tig)

Re:All I want is SATA RAID support

[Anonymous Coward]

You lose at the InterWeb.

usr != user

[DarkMan]

/usr is an abreviation of UNIX system resources.

The abreviation of user you're looking for is /home. The names are shortened because there was a maximum length on filenames in UFS - 12 characters I think, or there abouts.

If I note that sbin means system binaries (i.e. the minimal set of programs to get booted, and administration programs), then the existance of /sbin and /usr/sbin should be clearer. That is, /sbin contains those special programs (e.g. init) and administrative programs (e.g. fsck) that would be reasonably needed before mounting another partition in the bootup process. Once /usr was mounted, the majority of the system binaries were in /usr/sbin.

That's not to say that it was a good idea, or that it is a good idea, but that's why it's the way it is.

The one good thing about such a standard is that I can get put infront of any flavour of Unix (or unix-like system), and do basic sysadmin stuff, like configure a network, install sshd &c. This was very useful when we were getting a lot of odd machines for work - I've used 8 different 'Nix varients in anger, without any documentation save sometimes some man pages installed. That's what any new filesystem layout must compete with - portable knowledge (same sort of thing that helps keep X11 around).

To end, I'll agree that the current windows set up for where files go is, indeed, very nice. The problem is the few applications that don't care, and user hardcoded paths. Those (legacy apps, if you will) cause a lot of pain, and is why most people I know are administrator on thier boxes all the time. It's been caught by, essentially, lazy programmers. I expect that similar problems (although hopefully disimilar solutions) will arise with any Linux distro that moves paths around.

L in LSB not necessarily for Linux

[tepples]

I think you didn't read what the first letter in 'LSB' stands for - Linux

Not exactly. Like Win32, LSB is a set of application binary interfaces, one for each of several CPU architectures. Any system running on a supported architecture can implement an LSB compatibility layer, just as Wine implements Win32 on select operating systems running on i386 CPUs.

The LSB FAQ answers the question "Is the LSB only for Linux systems and applications?" thus:

No. The spec has been written so it can be readily implemented on top of any UNIX-like operating system, natively or as a compatibility layer. There is also no fundamental reason why it cannot be implemented on other operating systems, although it is likely to be much more work. Note that this philosophy may be one of the reasons why a seemingly "obvious" Linux feature is not part of the specification if it raises needless barriers to implementing the LSB on non-Linux systems.

Actually..

[Junta]

You should look at rox which advocates and uses an appdir apporach in unices (which is actually really neat and effective, they even provide ROX-LIB which shows how it would work with repect to libraries.

True, libraries would still have to be in some common area, but at least would have all relevant resources entirely contained in a subdirectory.

OSX does some impure global resources stuff and some things (particularly Apple packages) are installer based and contribute to tossing things all over the place...

this could be a good idea

[ShadowRage]

well, a good idea for a desktop system with average joe blow who thinks deleting a buncha files is the best way to uninstall some shit, (often run into that with broken windows systems)
so if they wanna suddenly be mr. computer expert with their son's computer, they wont completely fuck it up.

I want a single software portage system.

[Anonymous Coward]

That works on any Unix based system.

If need be then a distribution could be packaged up from the portage system, so that you could generate rpm's, deb's or gentoo files from the higher level.

What's the advantage?

[alfino]

If I look at System/Executables/Zsh/Settings or whatever they call it, I am catapulted back into c:\progra~1 world.

Are they considering backups? I don't want to backup the binaries, and I don't want to write endless lists of inclusions or exceptions.

Or are they going to "fall back" to the legacy tree, which was designed to be exactly that: a tree logically divided into groups that make sense to a system.

I don't get it.

Re:What's the advantage?

[HishamMuhammad]

If I look at System/Executables/Zsh/Settings or whatever they call it, I am catapulted back into c:\progra~1 world.

Nah, that's just your traumas. We never had Windows in mind when designing it. And for the n^n-th time, no, it's not a pain in the command line, with a properly configured shell (like the one we ship by default) :-)

Are they considering backups? I don't want to backup the binaries, and I don't want to write endless lists of inclusions or exceptions.

Sure! Is tar czvf backup.tar.gz /Programs/*/Settings good enough? :)

In this approach, you have the advantage to know what programs each settings files came from, their pathnames will be stored in the backup.

Or are they going to "fall back" to the legacy tree, which was designed to be exactly that: a tree logically divided into groups that make sense to a system.

Why would we? Ours is better! ;-)

Re:What's the advantage?

[Anonymous Coward]

System/Executables/Zsh/Settings

I can't mount the System hierarchy to be read only under this system.

Re:What's the advantage?

[Anonymous Coward]

Then how come they run it on a LiveCD, which has, last I checked, a read-only file system!?

*beats the other AC with a cluestick*

Re:All I want is SATA RAID support

[alfino]

I would have to agree.

Running RedHat or anything of that sort may be okay for the single multimedia workstation you keep around for your evening entertainment and the children.

But as soon as you have more than one computer to worry about -- possibly geographically separate -- the colourfulness and one-clickability quickly yields to major management pains.

I personally don't even understand how Gentoo can hold strong. When I think about my personal 17 machines, spaced across five countries in three continents, and the 47 machines I administer at university, then there is only one logical answer. Debian.

Mac OS X

[boola-boola]

a distro that does away with Unix paths such as /usr/bin and /lib and uses things like /System/Settings/X11 instead

I generally don't think it's a good idea. It's additional clout that is pretty much unnecessary, seeing as how everybody is already used to /usr/bin, /lib, etc. If there were an advantage, I'd go for it, but there isn't: It's longer to write, you're mixing upper- & lower-case letters, and it's confusing sometimes. No real advantage.

Take OS X for instance. Here's a sample of what's in my root directory on my Powerbook:

/Applications
/Desktop DB
/Desktop DF
/Developer
/Library
/Network
/System
...
etc.

It's confusing and convoluted as hell. There's not necessarily only one type of file in each directory. Not to mention the structuring: there are applications left and right, many of which are actually directories containing more varied data. Madness, I tell you.

Stick with tried and true. It's been proven to work, and there is no major advantage over the new method.

Re:Mac OS X

[TheInternet]

It's confusing and convoluted as hell.

In what way? What are you going to find in Applications other than applications?

there are applications left and right

Unless you're actively moving things around, all of your applications will end up in one place -- Applications.

- Scott

Re:Mac OS X

[Anonymous Coward]

...you forgot /Developer

Re:Mac OS X

[multiplexo]

I generally don't think it's a good idea. It's additional clout that is pretty much unnecessary, seeing as how everybody is already used to /usr/bin, /lib, etc. If there were an advantage, I'd go for it, but there isn't: It's longer to write, you're mixing upper- & lower-case letters, and it's confusing sometimes. No real advantage.

Take OS X for instance. Here's a sample of what's in my root directory on my Powerbook: /Applications /Desktop DB /Desktop DF /Developer /Library /Network /System ...
etc.

It's confusing and convoluted as hell. There's not necessarily only one type of file in each directory. Not to mention the structuring: there are applications left and right, many of which are actually directories containing more varied data. Madness, I tell you.

How is the Macintosh directory structure "confusing and convoluted as hell"? You want confusing or convoluted as Hell? Try working on a Solaris or HP/UX system after someone has installed a bunch of third party packages, some GNU, some commercial, some written in-house and try figuring out where the library files or configuration files for each application are.

Sure, you can use symlinks to impose some structure on this sort of thing, but why should you have to? The UNIX filesystem layout sucks, it's confusing, it's not standardized in any meaningful sense other than having certain types of files located under certain broad hierarchies (/usr, /etc, /lib) and it's ugly. Bravo to Gobo for doing so and for striking a blow against the hordes of idiot UNIX sysadmins who are in favor of job security through OS obscurity.

Directory names

[Brandybuck]

It doesn't matter what you call system directory names, because at the desktop level and below, the average user just won't care. In other words, the typical newbie will never encounter /etc or /usr/lib. It may sound nice at first glance, but this is not something that will make the system easier for users.

At the "desktop level", however, it does make sense. And oddly enough, this is an area where the FHS and tradition are completely silent. Do what you want and no one will care.

The user isn't going to care that system-wide fonts go in /usr/X11R6/lib/fonts, because the user is going to push the "install font" button instead!

Waiting for MokeyLinux or BooberLinux

[mgkimsal2]

I hear those are much better than GoboLinux. Can anyone confirm?

Re:Waiting for MokeyLinux or BooberLinux

[tonydiesel]

Ha! I'm glad I'm not the only one that saw that name and immediately thought - "I wonder if they mean that Gobo..."

Although if you really want one that's better than GoboLinux, wouldn't you have to wait for UncleTravellingMattLinux?

The name is long but at least it manages to make it above ground from time to time...

Pronounceable Linux

[doc modulo]

I agree with you.

Computers are supposed to be our slaves. They should serve us in the way we like them to. I would like Linux to have directory names that are clearer and help me figure out/tweak/fix my OS more easily. I should not have to bend my brain just so the computer can have an easier time.

Off the top of my head, computers do two things:
- Help us do things that are otherwise impossible.
- Help us do those things faster, more efficiently or more easily.

When you can help people use their computers more easily by making the directory names intuitive, you should go for it. It would be great if a person of average intelligence can understand what a certain directory in his OS is used for without having to memorize anything. As you know, human memory is weak and the memory of an arcane directory structure will break if not refreshed often enough. People will like Linux more, explore their system more and will make less mistakes if the directory structure is human readable.

I guess that when you're a kernel hacker, you tend to forget that it's BOTH about the end result (a nice slave) AND the correct/elegant way to achieve that result because you're spending your time mostly on the how, not the ultimate why. I don't know how the traditional directories got their their names and why they were born but was it all thought out logically? Was there a plan and good reason for doing it like this? Well, they did think about the new way of doing it and they have good reasons.

Let me give you another argument. Linux advocates often say that one of the strengths of Open Source is that there is diversity and that the forks and experiments strengthen the software ecosystem. Well, that 'Darwinism' will only work if you select the best 'mutations' and discard the "old organisms" that didn't work. I think that everyone with an open mind would agree that, from the end user's point of view, 'programs' is better than "usr/bin". If you don't select a new way of doing things once in a while, what's the point of experiments and diversity? You might as well keep things just like they were in the beginning forever.

I know switching will be painful because of existing applications but Linux doesn't have 90% market share yet. I know it will but my point is, if the painful switch to a new directory structure is done NOW, it will inconvenience a lot less people than when it would be done when it's the most popular OS on the planet. On top of that, I think it will help Linux achieve that 90% faster.

The computer should be my slave and bend over backwards to please ME. It should use more processor, memory and storage to please ME. I should not have to waste more time, think harder and be aggravated JUST so the PC has an easier time (has to use less storage/memory/cycles).

I will give you one final example of why this way of thinking is good in my opinion. I've been computing in Windows 2000 until now because I've started with Windows, because Counter-Strike and Photoshop are Windows (Mac) only and because I think Linux would cost me more time and aggravation than keeping Windows patched and cleaned. However, I have been keeping an eye on MaxOS X, Linux and other Open Source operating systems like FreeBSD because I know they're better from a system point of view. Also, I know that Microsoft have done evil things and I'm convinced will do evil things in the future.

I have decided to switch to another OS because of ROX and GoboLinux. I'll try different combinations of GoboLinux, Rox, FreeBSD and installed Knoppix and decide afterwards. (any suggestions for a beginner?) If that doesn't work out for me I'll have to save for an iBook.

I'm not too proud to beg so please help make the the world a friendlier and less MS place and open yourself to that "discard the old and embrace the better" mentality that you demand of Windows users. Support and advocate the ROX and GoboLinux way.

Slightly offtopic: Some people argue against the "every file of a program contai

No solutions...

[yanestra]

I believe that they don't have any solution for popular problems like name/version conflicts with libraries and header files, so GoboLinux can't be an alternative to Gentoo Linux, which at least has a slot concept making it possible two different versions of the same package to co-exist.

Re:No solutions...

[paranoidd]

Surelly we have: the solution that GoboLinux adopted to deal with different versions of the same package to co-exist is simply done by the /Programs/ProgramName/version/ hierarchy. I'm used to have more than 4 GCC releases at the same time, and even Cross-Compilers are living on the same place without any kind of problem.
No need to complicate things..

The user can never escape awkward directory trees

[ReyTFox]

At least, so long as the system uses shared libraries.

MS-DOS was the only OS(that needed an install, Atari DOS wouldn't count there) where I really had a "clean" install the whole way through. Programs went in x, drivers in y. Everything using DOS4GW had a copy of it included with the binary, no harm done. Needless to say, configs also went alongside the binary.

Of course, this falls apart as soon as you have a more complex OS that needs things like scripting languages and windowing systems. There's just no way around shared libraries. And with shared libraries comes other kinds of shared access - to data and devices. So you have to reorganize, create new structures to hold certain kinds of files. Version conflicts, missing depends - all result from this necessity.

Of course, these structures just won't make any sense to the end user, except as a programmer. It won't matter how much you try to polish it up. A project like this might help, but putting an end to it all would probably need something along the lines of an FS and binary format revision, to include more data like the version number and purpose for each file. Good luck doing that.... :P

Re:All I want is SATA RAID support

[shadow_slicer]

Why don't you just download the source to and compile your own? Is it really that much harder to "check" the SATA RAID support option in the kernel, compile and install than bitch on slashdot about it?

SATA RAID doesn't seem (to me) like it would be very common in most environments (since the ID in RAID means "inexpensive disks", and last I checked SATA drives were still pretty pricey). Anyway, if you're in an environment that requires such specialized (high-performance) hardware, you might want to be tweaking your kernel anyway.

Re:All I want is SATA RAID support

[Anonymous Coward]

As a Gentoo user I just have to say, you don't have to understand. We don't mind. Debian users rant about Gentoo being a flash in the pan. Gentoo's users rant about the Debian users' elitism. RTFM is *not* a reasonable answer *every* question put forth.

It's easy enough to make everyone happy

[Ifni]

Unix has provided this feature for YEARS. It's called "ln -s". You can use it to create an alternate directory structure to your liking, and still keep the simple, short, easy to type, common file structure that we all love.

As far as the package manager, it seems to me that it (like all other package managers) is just reinventing the wheel. "./configure;make;make install" is pretty easy. Most reasonably well written configure scripts already check for dependencies. If you want to write a really good package manager, design one that parses the configure and make files to build a dependency list and present the user with build time options. Include a defaults capability (like Gentoo's USE variable) so that the package manager bugs you less about what options to choose when configuring, and you are all set. The package manager then just does the "./configure;make;make install" for the user and it's done. The only problem are any programs that have poor configure scripts (or those that don't use them). Since the package manager would likely have to hit some central library to be made aware of what "packages" are available and where to get them, this library could contain custom info where needed (read: a proper configure file, or a dummy one if the "package" is just a script that has to be copied to a directory, etc).

Oh well. Hackers get bored if they aren't reinventing some wheel, trying to make it better. And, admittedly, some package managers have some handy features that may qualify as better (allowing for precompiled binaries for the impatient/lazy is one of them). Who am I to judge?

Re:Screw dependencies

[SpaceLifeForm]

There are way, way too many dependencies today that need to be eliminated or minimized. It's the curse of having a variety of tools.

Done a ./configure lately?

Screenshots are very important

[commodoresloat]

they allow me to procrastinate by looking at someone else working.

So...

[atomic-penguin]

You just made the path longer. How convenient!

Other considerations...

[bigusputicus]

I think the strongest case for using an organization like this would be for building large farms of clusters, diskless and dataless clients

A more radical approach may be to use a combination of this implementation along with peer-to-peer technology

Shared or static, that is the question

[petrus4]

An experiment I've been trying recently:-

For core system stuff (bash, textutils, etc) or for anything I don't fear having to upgrade very often, I've tended to link static. The other good thing about this is that I can make a static skeleton for one system, copy it to another partition, and it works with a minimum of additional needed screwing around.

As the above post says though, for X or anything GUI, shared/dynamic is the only way to fly. The reason is that GUI stuff generally has an enormous list of dependencies, and so attempting to upgrade with everything static would break down very quickly, because when you upgrade a single lib, you have to recompile everything that is static but that contains the earlier version of that lib.

Shared linking to me for the most part is a pain in the tail in a whole lot of different ways...I agree with that, and it of course was the source of the dreaded Microsoft "DLL Hell" problem. There seem to be ways to minimise it, but at times there doesn't seem to be a way around it.

GNU Gettext inspires a possible solution

[neutralstone]

Not sure if this is a good idea, but here it goes:

Directory entries could be presented to the user in his/her native language after the fashion of gettext -- i.e., the language/locale of the text would be determined by some environment variable, configuration setting, or command issued by the user.

Imagine a user who speaks only Mandarin Chinese. Suppose he gets a list of directory entries at the root level. There he would see the Chinese words for "System", "Applications", "Library", etc.

Later, when an English-only speaker uses the same machine, he'll see the same directory names in English, either because:

1) He logged into his own account, which is set so that the OS presents everything, including directory entries, in his language and locale, or:
2) He issued some command to change the language during the same session with the same account.

Normally, this would be difficult to implement (and have it work everywhere in the operating system -- not just while in a special desktop environment). But maybe Reiser4, with its plugin architecture, will allow the job to be done with a small amount of effort; see here:

http://www.namesys.com/v4/v4.html

Re:GNU Gettext inspires a possible solution

[Anonymous Coward]

It's an interface issue, not a filesystem issue. Store everything in the English layout, and have file dialogs, bash, etc, auto-translate.

Re:GNU Gettext inspires a possible solution

[neutralstone]

1) The thing is that filesystems present an interface. So, yes, it's definitely an interface issue, but that doesn't mean we shouldn't consider fixing the filesystem. (You probably meant to say that it's a *user* interface issue, but that is by no means the only kind of interface that should be examined.)

2) If we expect other programs to do the translations, then we need to implement the translation feature several times, i.e., for everything that wants to use the localized text. If it's implemented in the filesystem, everything else can take advantage of it without any change (or with fewer changes).

Besides, if other tools like shells try to do translations like this, they'll be lying: the directory entry wouldn't really have a localized name. But if it's built into the filesystem, the entry could have several names, and the current one would depend on some setting; the entry could also be referred to using any of its localized names and an argument that specifies the name's locale.

Of course, it would probably be silly to try to implement this with anything other than Reiser4 -- mainly because adding this localization feature wouldn't require any change to the Reiser4 codebase itself (i.e., it would just be another plugin).

Re:GNU Gettext inspires a possible solution

[Anonymous Coward]

You probably meant to say that it's a *user* interface issue

Yep.

2) If we expect other programs to do the translations, then we need to implement the translation feature several times, i.e., for everything that wants to use the localized text. If it's implemented in the filesystem, everything else can take advantage of it without any change (or with fewer changes).

That did occur to me, but I thought that if you're going to the trouble of translating paths, you may as well do it properly rather than have an unpredictable filesystem.

Having said that, now that I've thought about it more, I've reversed my opinion, and think you are right when you say it should be implemented in the filesystem. It would be a bit like selective listings (like GoboLinux already uses) and a set of hard links.

Re:GNU Gettext inspires a possible solution

[neutralstone]

Yeah. If it's not in the filesystem, then it just shouldn't be done at all -- mainly (IMHO) because of The Filename Lie that would otherwise arise: Imagine the Chinese-only speaker trying to do some command line operation on an entry, only to get "file not found". So he has to find out the English word for that entry and type *that* in.

It would be like "C:\PROGRA~1" all over again. And we know what to do with *that* kind of crap, don't we? That's right: whip out an *intelligent* distro's install CD and have an fdisk fest. :-)

Re:GNU Gettext inspires a possible solution

[Anonymous Coward]

You're assuming that the command-line would be ignored - there's no reason to translate GUI applications and ignore CLI ones.

But the problem remains of people talking to each other outside of the system. If an English person tells a Spanish person that they've put the files in /Public, then the Spanish speaker will probably be able to figure it out, but it won't be the same path.

Relocatability...

[bigusputicus]

With the combination of this implementation and peer-to-peer technology, a system could be built with all of its components being relocatable... existing locally or remotely in more that one location

Alternative to per-package or monolithic recipies

[Adam J. Richter]

Yes, simplicity is good, but only in the context of the whole system. Here, [GoboLinux is] just shifting complexity from the per-package scripts to the overall Compile package itself -- creating a large, central, monolithic service.

But, taking a page from the BSD ports collection, you could have modules distributed separately from the "monolithic service" that define common packaging conventions. There could be a description of how to build "standard" autoconf-generated packages, which might be referenced by the more specialized description of how to build gnome packages, and so on.

This way, you would have the advantage of not having so many duplicated descriptions to maintain and you would also avoid having a monolithic kludge.

Re:All I want is SATA RAID support

[alfino]

Note that I am open. I know Debian is elitarian, and I try not to be. What I wrote was simply from experience. But I don't know Gentoo other than from the stuff I heard about it.

So how do you admin 20 systems rmeotely in Gentoo, in a timely fashion pertaining to updates, and without too much time invested?

Traditional filesystems outdated anyway...

[Anonymous Coward]

What Linux needs is not yet another file system hierarchy standard but an answer to Microsofts upcoming DB-centric Windows Future Storage (WinFS). I want alternatives to fopen() where meta-data for created files are given as well. This DB could among other stuff keep track of all binaries and their versions.

Re:The user can never escape awkward directory tre

[marcovje]

Classic Mac OS goes a long way. Application folders can be dragged and dropped, and dragging the OS folder to a newly formatted (external) HD effectively clones the system.

I didn't use the OS that much, so there could be downsides, but it was quite impressive

Re:All I want is SATA RAID support

[Anonymous Coward]

and last I checked SATA drives were still pretty pricey

How were those prices back in the paleolithic period? In current times, an SATA version of a drive tends to cost bugger all more than it's ATA equivalent... as in $5 to $10.

Screw -that-

[trezor]

• Other than core system configuration and core libraries the whole system uses, I ideally think *any app should be totally confined to one directory level.

Wouldn't this eventually require system kernel changes and an eXtensible Stack-Module (in short excess-module)?

I mean, just try to imagine the lengths of that PATH-variable after every single tiny little GNU-app should have a own directory with added path. You'd probably end up needing a Oracle dB-server extension for the basic PATH-system...

The CLI performance would end up so beyond any overbloated GUI, that people wouldn't even dear putting the terminal icon on their desktops.

• IMO this is one thing Windows does right.

Except a couple of things. First of all it doesn't. Second of all it's all a matter of taste. I'm love the POSIX way and I getting increasingly fed up with windows pseudo-organized structures.

When you don't make the system consistent, it quickly ends up (a lot) worse than any bad, yet consistent system.

Re:All I want is SATA RAID support

[Gothmolly]

Because the INSTALLER kernel is built into the ISO, and there's no support for the disks. Additionally, there's no support in the INSTALLED kernel, so even if you get the installer to install to /dev/ataraid/d0p0, the kernel, once booted, won't support it.
How do you bootstrap the system w/o initial support? Hmm? Sounds like YOU'RE the one who's never compiled a kernel, or done an install short of simply booting the CDROM.
Oh yeah, troll.

Re:All I want is SATA RAID support

[Dulimano]

Nice, you just managed to enrage the two biggest groups of Linux zealots in one go. :-)

And was stomped into the ground accordingly:

Moderation -2
50% Flamebait
50% Overrated

Nice combo.

Re: parent is misinformed

[Anonymous Coward]

Bzzzt. Thanks for playing. Read the rest of the thread and mod parent down.

Re: parent is misinformed

[Anonymous Coward]

And as a sidenote, the parent's "source" contradicts every dead tree I've ever read on the matter, including somre really ancient stuff like the old "Unix in a Nutshell" with the referree on the cover.

Re:All I want is SATA RAID support

[Anonymous Coward]

I've never seen a rebate or sale on a serial ATA drive, which means their retail prices are real--not inflated 40% above what anyone actually pays like parallel ATA drives.

Re: parent is misinformed

[SmilingBoy]

Well, a poster further down is of the same opinion as me - and then - should I trust an AC on /. or the Linux Documentation Project? "Unix System Resources" is a backronym invented some time after the /home subdirectory was introduced - "user" is now a wrong description for /usr.

Re:All I want is SATA RAID support

[shadow_slicer]

Why the flame?

I was just offering my suggestion. If you don't like my suggestion or don't think it applicable then you are free to politely refute my suggestions in a reasonable manner.

You're right though in that I didn't think about bootstrapping the system (I've never had trouble with the default bootstrapping kernels, so I didn't think about it).

But you'd be mistaken if you think me a n00b "who's never compiled a kernel, or done an install short of simply booting from the CDROM." As a stage-1 Gentoo user (running a manually configured 2.6.5-r1) I like to think I can claim some small degree of Linux knowledge.

But after thinking about your restated dilemma, I thought of three potential solutions (that you are free to shoot down):
1. Install to another harddrive.
Does your root filesystem *really* need to be on the RAID array? Get a separate harddrive for the system files (which, since they can be restored from the install disk, don't need to be redundant, and probably won't need the performance boosts from the RAID array).
2. (Minimal?) Install on another harddrive, and copy over.
Slow, painful, but effective. As you copy over, you can replace the standard kernel with your custom SATA RAID kernel.
3. Use your own kernel for the install, and install (with your kernel) to the RAID array.
Either use a boot-floppy with your kernel in conjunction with the distro's install cd, or make your own variant of their install cd, and all should work normally. Adding your kernel to their install cd, and remastering shouldn't be that hard (and you can probably find detailed instructions via google, or by emailing your distro). If you do remaster the CD you could post it online (assuming you're using a free distro...) and then no one will be able to bitch about this issue with that distro again.

But of course I'm probably wasting my time replying as my brother thinks you're "one of those ogre-people" (trolls) he read about in his "Net Force" book.

self contained apps in unix?

[zlel]

someone mentioned containing apps in their own directories instead of the traditional /usr/bin stuff... but i thought unix favours having "kernel" and "everything else" so that we have small apps cooperating to get stuff out?

So unless we want to settle for a cocktail, I find it strange to try too hard to "isolate" proggies, afterall, libraries aren't the only thing that gets shared in unix, we have lots of CLI's and shell scripts running stuff and what not... no, I wouldn't like to see "ls" getting its own directory, nor would I like the idea of "primary" and "secondary" applications...

I think the current system does well - mnemonics work well for both English and non-English speakers - afterall, I don't think we want Red Flag Linux to start naming their FS in Chinese and put up an impossible barrier to entry in their market...

Re:self contained apps in unix?

[paranoidd]

Actually there are symlinks to each package's bin, lib, share, man and so on, on a directory called /System/Links/{Executables,Libraries,Shared,...}. This allows programs to be found by other packages in the same way that standard distributions do with their LD_LIBRARY_PATH and PATH variables.

The difference, so, is that on GoboLinux everything is self-contained on its own directory, allowing a very clean vision of the entire system without breaking any kind of compatibility.
Please give a look at the GoboLinux website ( http://gobolinux.org ) and give a look on the Documentation section to take a good overview of the system itself.

I must be getting long of tooth

[Stephen Samuel]

"Unix System Resources" is a joke backronym to try to hide this, the initial Unix design used "/" for this purpose.

Honest to god... I'v been using UNIX for 20 years, and I've never heard 'Unix System Resourses" applied to /usr before today. (at least -- not that I remember!).

True

[Pan T. Hose]

Other than core system configuration and core libraries the whole system uses, I ideally think *any app should be totally confined to one directory level. IMO this is one thing Windows does right.

That's true and very Score:5, Insightful. The only two things which should not be in the application's own directory (i.e. in standard /opt/application_name on Unix) are configuration files and public libraries. After all, why would anything besides the config files, libraries and executables should be in any fixed place? Oh, yes, the executables, it's good to have them in PATH without having every program add its own dir to PATH. So anyway, there are only three things which should not be in the application's own directory, but everything other than configuration, libraries, executables and manual pages, that's four, four things, just four things, configuration files, libraries, executables, man pages and logs, the five things, the only five things which could be in a central place are configuration files, libraries, executables, man pages, logs and temporary files, I mean six, that's six things, libraries, executables, man pages, logs, temp files and pid files, seven, only seven, the only seven things are temp files, pid files, lock files... Amongst the things... Amongst those directories... are such elements as fear, surprise.... I'll come in again.

OT: your .sig

[Anonymous Coward]

Obligatory .sig: Always read the man page. And use "LANG=C" so it looks right.

Just curious: how does the C locale change manpages? I didn't notice anything... Thanks!