On Monday, the Free Standards Group released the latest version of the Linux Standard Base, Version 3.0, and announced that Red Hat, Novell, the Debian Common Core Alliance and Asianux are all certifying their latest operating systems versions to it. Update: In a recent post on his blog, Red Hat’s Ulrich Drepper makes some criticisms of the LSB and its shortcomings of the v3 certification process.
does this implies to Ubuntu as well ?
(does Ubuntu a Debian Common Core Alliance member ?)
does this implies to Ubuntu as well?
No, it doesn’t.
(does Ubuntu a Debian Common Core Alliance member?)
Ubuntu is not a member of the DCC (neither is Debian by the way…)
IANAE (I Am Not An Expert) but AFAIK the LSB certified distros are all RPM based.
Nope. The LSB only specifies how 3rd-party LSB-compliant packages are distributed (which is in an RPM), not how the OS is packaged. Debian has had LSB support for quite some time (and they simply use “alien” to transform an LSB RPM into the native DEB format for installation).
http://www.livejournal.com/users/udrepper/8511.html
let me also say, I am still awaiting an /apps or /applications directory for the FHS (http://www.pathname.com/fhs/) standard (which is part of LSB). Eg. all the files and specific libraries for GIMP could be in /apps/gimp/ rather than be in with all the system and OS files.
I think that simple change would be a huge step towards the Linux Desktop(tm).
Why?
Isn’t the GIMP just another system binary like X, KDE and GNOME?
I almost missed your sarcasm but you are correct, GIMP is not a system binary and therefore should not be treated as one.
no, I wasn’t being sarcastic. It is a system binary, just like GNOME, KDE and Firefox.
Commercial software could be installed in /home/joe/bin or /usr/local/bin or /usr/local/msoffice/bin or whatever.
But the rest of the apps are part of the system or part of the user’s binary collection. In any case they should be in a binary path. That’s /bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/X11R6/sbin:/usr/loca l/bin:/usr/local/sbin:$HOME/bin
etc. Their real location can be /usr/apps/GIMP-2.2.1/bin with a symbolic link to /usr/bin or /usr/X11R6/bin, but the more directories you add the longer your path will be. So its best to just Keep It Simple, Stupid.
“That’s /bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/X11R6/sbin:/usr/loca l/bin:/usr/local/sbin:$HOME/bin
etc.
Then “So its best to just Keep It Simple, Stupid.
lol
That is only for the binary, the rest of the program files are just as all over the place. One application could be just thrown about like any one of ~30 directories. That is SOO much simpler than /apps/gimp/?
Software should not reside in your home directory. It can be alright on your own computer, but some security-conscious people are setting the noexec flag on /home.
I believe /opt is the right place for commercial software. As for optional/user-installed packages, I like the scheme used by the BSDs: the base install in base directories, everything else (like ports and pkg_src) in /usr/local.
Either way, I don’t believe another directory structure for applications (/apps) is necessary. Since home users should know the admin password(s) for their machines, I believe the OS X/Ubuntu way of installing stuff (a dialog asking you for your password) is a good compromise. I believe it’s more secure than a group/world-writeable directory. After all, you shouldn’t have to hunt for installed files if you are using a well-designed application: configurations should be in your home directory, shared files like themes in /usr/share, etc. I don’t see the need to have everything in the same directory.
“I believe /opt is the right place for commercial software.”
Yes, but look at your own system and tell me how many of your GUI applications are not in /opt? Like 95%?
“Since home users should know the admin password(s) for their machines”
But if every person using the desktop types in the root password when something needs access what is the point of just not making them root users?
If the package they are trying to install is a virus won’t they just enter the root password?
That is the point of a possible middle ground like /apps, they could install the package but it won’t have full root access to the system.
“configurations should be in your home directory”
Maybe user specific configs, but in a multi user system the other user is also going to need access to the same application.
Have you used a multi user system? Have you admined one? Have you ever designed one?
You’re talking with people who have and do.
[i]Have you used a multi user system? Have you admined one? Have you ever designed one?</a?
Yes, Yes, and no.
Also, I would not be so sure about me being wrong. Windows, OSX, and BeOS all do it the way I suggest. I think Linux is the only desktop operating system that does not and it is not really a majority.
So actually you are the minority, Apple and Microsoft (who would know more than me) disagree with you.
But don’t let that stop you from insulting me
Nobody is wrong here. You’re quite welcome to design a multiuser system with any directory structure you like.
But the whole point of the FHS is to make some sort of standardized filesystem we can all agree on. I think they go overboard with making stuff like /opt mandetory for compliance, but I could be mistaken.
You are obviously very creative. But your comments seem to lack a lot of experience with older UNIX filesystems and multiuser environments. That is why I asked.
I have been working on these old UNIX OSs for years and know them rather intimately. So I personally think keeping the filesystem as simple as they made it would save everyone a lot of headache over time.
For example, RedHat has /etc/rc.d/init.d, but almost every other UNIX system I use has /etc/init.d, sometimes linked from /var or /usr somewhere, but I prefer /etc/rc.d/ and /etc/init.d to /etc/rc.d/init.d. It seems RedHat added a link to /etc/init.d to appease grumpy ol’ UNIX hackers like me. But then they made /etc/sysconfig. Again, KISS is the best rule of thumb to use when designing these things because they quickly get out of anyone’s control.
Help fight entropy or deal with the chaos. Be part of the solution or part of the precipitation. Either way it doesn’t really matter.
Windows, OS X, and BeOS, verus *NIX. Let’s see, operating systems designed for desktops, versus a family of operating systems designed for large sets of networked computers. Which one has a model more suitable for the enterprise? Let me think…
Also, I would not be so sure about me being wrong. Windows, OSX, and BeOS all do it the way I suggest. I think Linux is the only desktop operating system that does not and it is not really a majority.
I’m sorry, but that’s simply not true. Several Windows apps install components all over the place – especially Microsoft apps.
I agree with other posters: I don’t need to know where the binary is, I just want it in my $PATH and I want a shortcut to be automatically added to my menu.
If I ever need to find something, there’s the very useful “locate” command (and the equally useful “locate:/” kio_slave, which means I can use locate inside Konqueror).
The problem is that you assume that the *nix way is inferior because it’s different…in fact, it is much more elegant and efficient than the Windows way of managing software packages.
” “locate:/” kio_slave, which means I can use locate inside Konqueror). ”
You can also use it in the open dialog as well. I have to spread some kio_locate love.
Yes, but look at your own system and tell me how many of your GUI applications are not in /opt? Like 95%?
I don’t run commercial software on my Linux rigs.
But since you are asking, I had applications or games in the past that were in binary format and they were sitting in /opt, like /opt/nwn.
But if every person using the desktop types in the root password when something needs access what is the point of just not making them root users?
Not when they need access the application, but when they need to (un)install one. Nobody should have super-user priviledges unless necessary. Having “computer administrator” priviledges like in MS Windows is definitely a bad idea, save for virus writers.
Typing a password is giving a confirmation on the action, just like a signature on a contract. Of course, the user couldn’t verify his course like the fine prints on a contract, but it’s their problem.
If the package they are trying to install is a virus won’t they just enter the root password?
It wouldn’t be much safer than a malicious program in /apps that is asking innocently for a root password…
That is the point of a possible middle ground like /apps, they could install the package but it won’t have full root access to the system.
We seem to have different philosophies. Unless I am mistaken, you are telling me we should protect the user from himself. Personally, I believe we should let him do what he wants. If Joe User got his package from an untrustworthy source and got fscked, too bad for him.
Maybe user specific configs, but in a multi user system the other user is also going to need access to the same application.
Does he really needs your configuration? So far, I haven’t see applications like that under Linux. At worst, there is /etc or /usr/local/etc. In Windows, I have some applications that are using Program Files as their dump-for-everything and it really annoys me since my girlfriend and I definitely don’t have the same preferences.
BTW, I’m not saying you’re wrong. I just don’t think it’s a big deal when we have package managers around. IMO, what we really need is a standard for interoperability between them or something like that…
Of course, the user couldn’t verify his course like the fine prints on a contract, but it’s their problem.
Woops. That sentance doesn’t make any sense… It should be: Of course, the user might not care of the instructions or the safety of what he is doing like the fine prints of a contract, but it’s his problem.
Software should not reside in your home directory. It can be alright on your own computer, but some security-conscious people are setting the noexec flag on /home.
As I understand this thread, the problem is that there is currently no FHS endorsed way for orinary users to install application.
I say put them in $HOME if you can’t pursuade your admin to install it for you. I have some apps in $HOME/opt. Some to let them handle their own updates, and some just because I can’t see why I’d want them system wide.
The argument that $HOME might have a noexec flag doesn’t hold. If the admin wont trust you to install binaries in $HOME, he wont trust you to install apps anywhere else either.
On another note though. I can’t see any reason for the FHS to spill inte GUI space. Why should users ever be aware of anything beyond $HOME? And on top of that, why force them to use a file system at all? The only time I ever care of the file nature of my data objects is when I’m concerned with the the space left on the storage device, or about remote availabillity.
One of the worst usabillty issues with gnome, IMHO, is the esitance ot the file selector. The FHS exsits for precisly this reason, to let developers worry about finding files instead of users. If the FHS isn’t enough, I’m sure freedesktop.org would be happy to host some extension standard for desktop files.
You make the same mistake of seperating “users” from “admins” where on a desktop (not workstations) they are the same thing.
Also, installing everything in $HOME/opt does not make sense because how many copies of OO.o, Firefox, and XMMS do you need on the same disk?
“.If the FHS isn’t enough, I’m sure freedesktop.org would be happy to host some extension standard for desktop files.
I do sort of agree that FHS may not be the place and freedesktop.org may be but, the entire point would be moot by adding only one line to the FHS.
“/apps : Optional location for GIU desktop applications”
Also, the difference in security permision for /apps is just a possibility, it would probably still require root for most distros.
Maybe one of these days I will just subscribe to the FHS dev list and try to make my case there.
” Also, installing everything in $HOME/opt does not make sense because how many copies of OO.o, Firefox, and XMMS do you need on the same disk?
You make the same mistake of seperating “users” from “admins” where on a desktop (not workstations) they are the same thing.”
If users and admins are the same thing (on your home desktop systems), then the user-slash-admin can install his app to /usr/local. Why do you keep insisting on inventing a new directory for this?
You keep harping on about how all users could write to /apps but not have full system access, then go on to say that users and admins are the same thing on desktop systems, rendering your whole argument about where they are allowed to install things entirely moot, which you compound by stating “Also, the difference in security permision for /apps is just a possibility, it would probably still require root for most distros.”
So what the hell is the point? Sounds just like /usr/local to me. If /apps would usually require root access anyway, and your desktop user is actually an admin anyway (*you* keep saying it) what is its raison d’etre? I submit there is none.
If a user does not have root access (which by your own word doesn’t apply to home desktop users) then he has no business installing system wide software *period*. Not in /usr/local, and not in /apps (which you seem to recognize by stating most distros would require root access for /apps). For such users, ~/apps suffices (unless, as stated before, the admin disallows executing apps in $HOME, in which case he would hardly allow lusers to install to /apps either).
In short, by stating most distros will require root access for /apps, and that on the desktop users are admins anyway, you destroy your main reason for having /apps in the first place. Please take it up on the FHS mailing list, you will be told the same thing, only by people with more technical knowledge than I.
I mean, if you want to install stuff there because you like the name better, feel free. But there is no reason to add another mandatory directory to a list that already has an entry which has the same purpose.
-MO
When I say on a desktop that the users are the admins I don’t mean the user accounts have root privs.
The point is that people have this idea that nobody needs to know where anything is because that is the job of the administrator. On a desktop system there is no such luxury of having a full time admin so most admin related tasks are usually done by the user (with a seperate account).
I am sort of glad so few people agree with me on this point, that way 10 years from now when things change I can say I was basicially alone in being right about it 10 years ago.
I made 10 year predictions about desktop Linux over 7 years ago and nobody agreed with me on that either.
On a desktop system there is no such luxury of having a full time admin so most admin related tasks are usually done by the user (with a seperate account).
I think the point of the other posters in disagreement with you is that only a real administrator would need to know where something is.
Users that just manage their own private systems usually don’t need to know where package X install which file into, they only care about package X being installed
Why should users ever be aware of anything beyond $HOME?
This bears repeating. The UNIX model is designed around a multiuser paradigm. There is no fighting that, and you wouldn’t want to anyway — fighting the precepts of the system lead to an ugly system. In UNIX, all the user should care about is $HOME. The proper solution isn’t to try to emulate other OSs and achieve a half-assed result, but to take the UNIX model to its logical conclusion. Build up compatibility between package managers, so the user never has to fix things manually. Make sure all packages create the appropriate symlinks, etc. That’s the only correct way to design a desktop on the UNIX model.
what about /usr/local/appname (/usr/local/gimp) or perhaps /usr/local/apps/appname-current (/usr/local/apps/gimp-current -> /usr/local/apps/gimp-2.2.8)
relyk
Umm, why? I always hear this come up but have yet to hear a good argument for it. Users shouldn’t have to know how the filesystem is layed it. It simply shouldn’t matter. The only thing they deal with is their home directory. GIMP is just any other program located under Applications, Graphics. It could reside in /apps/gimp/bin or /usr/bin, for all I care.
But in the desktop work the user IS the administrator and they DO need to know where to find stuff on the disk.
Eg. I install a semi large application like say, trillian.rpm and it completes. Now I want to create a shortcut to it or browse for my chat logs, where do I go?
What if I need to edit a config file for it? What if I need to delete it to free space and I didn’t install it with what ever package manager the distro I am using dictates I use? What if it can’t run becasue it is missing a file, where do I look for it?
All these questions could have the same answer /apps/trillian
If I need it in $PATH (which I might not since it is not a command line app) I could just place a link in /apps/bin or one of the usual 10-12 directories.
Eg. I install a semi large application like say, trillian.rpm and it completes. Now I want to create a shortcut to it
To bugs.trillian.com (making this up) to file a bug for not installing a .desktop file.
or browse for my chat logs, where do I go?
Chat logs would be in your home directory so that’s not really relevant for this discussion.
What if I need to edit a config file for it? What if I need to delete it to free space and I didn’t install it with what ever package manager the distro I am using dictates I use? What if it can’t run becasue it is missing a file, where do I look for it?
Configuration files are in /etc (or perhaps gconf). Programs shouldn’t be installed sporadically across the system anyway (this is what package managers are for). Yes they need improvement and some kind of interoperation, but the solution isn’t to just forget about it.
Configuration files are in /etc (or perhaps gconf). Programs shouldn’t be installed sporadically across the system anyway (this is what package managers are for). Yes they need improvement and some kind of interoperation, but the solution isn’t to just forget about it.
But if you had a specific location to keep stuff you wouldn’t need the same package manager for everything. You could use 3rd party installers if even that.
It would make it easier to use more than one package manager, makefiles etc.
As long as you have binary compatibiliy you could even just extract the archive to a folder rather than have to deal with a package manager at all.
I am not saying that just extracting to /apps/appname is the best solution, but it does open up that option.
Now I want to create a shortcut to it or browse for my chat logs, where do I go?
To create a link in your home directory:
ln -s `type -P trillian` trillian
Or if its in your path your shortcut should search the path.
Chat logs should be in your home directory in $HOME:/.trillian/logs or something similar.
What if I need to edit a config file for it?
cd .trillian && vi configfile
Or the GUI can put a quick link to edit that file with your system’s default editor.
Or the GUI can provide a frontend to the config file with all the options you need access to from an end user’s perspective.
What if I need to delete it to free space and I didn’t install it with what ever package manager the distro I am using dictates I use?
Then delete the directory from wherever you install it or use the package manager to manage the package.
What if it can’t run becasue it is missing a file, where do I look for it?
http://www.trillian.com/support
Currently, on Fedora, all GUI apps are included in your path. At any time you can type “firefox” or “konsole” or “konqueror” or “gnome-terminal” or “vmware” or whatever and get the non-command line apps from the terminal. That is not a mistake.
But you’re right, you could use /apps and put /apps/bin in your path and make sure the current versions of all the software you use is in /apps/bin. That’s not a bad idea. But let’s not make /apps/bin and /usr/apps/bin and /usr/local/apps/bin and /multimediaapps/bin and /officeapps/bin and /usr/apps/multimedia/office/apps/bin. Its not really necessary and the GUI isn’t going to see ANY of those directories anyway.
[/i]But let’s not make /apps/bin and /usr/apps/bin and /usr/local/apps/bin and /multimediaapps/bin and /officeapps/bin and /usr/apps/multimedia/office/apps/bin.[/i]
Maybe not that, but maybe /apps/kde, /apps/gnome, and /apps/editors could be optional.
Also, part of gain is that not every single file installed with trillian needs to be in $PATH, only really the binary.
Command line tools can follow the traditional locations.
If Trillian.rpm didn’t create a link to the software, go yell at your distro maker about it. If you want to find your chat logs, use the UI trillian gives you for your chat logs. If you really must get the files, look in ~/.trillian, because in a good *NIX setup, the app can’t really write anywhere else anyway.
If you installed a package that wasn’t what your distro uses, then that’s your own damn fault. I don’t expect sympathy from Mac users when I complain I can’t run .exe’s in OS X! Using a .rpm in Debian is no different.
When you say “users” you’re making a blanket statement. I do care where my applications go, and I do care about more then just /home. If a distro wants to simplify such things, they can. Gobolinux?
Of course, I’m not the Great Unwashed that many think should be the only target audience for Linux kernel based operating systems.
I have to agree with this. I don’t know where my applications are, and I don’t particularly care. As far as I know, clicking on Internet -> Firefox Web Browser could cause magical elves carry the bits from Mozilla’s webserver to my computer’s RAM. When I want to install or uninstall an app, I use Synaptic, and again, I still don’t care where it is. There is little point moving away from this model when everybody else will be moving to this model. What do you think the whole “search-based UI” is heading to? The whole idea behind it is: “I don’t care where my data is, as long as I have good tools for finding it.”
The whole idea behind it is: “I don’t care where my data is, as long as I have good tools for finding it.”
May be Ok for my father to find his emails/docs
But that’s such a bad idea when it applies to OS related stuff…
Of course that is the logical thing to do for LotD, and that’s why it won’t be accepted. A bunch of Unix curmudgeons will say some brain dead shit like “those who don’t know Unix are doomed…” or some other crap that nobody gives two shits about.
Forget about LotD until the old Unix heads are bitch-slapped back into their underground lairs once and for all and something usable that puts a facade on the Unix in linux comes out.
And it would be a huge step backwards for Linux in the Enterprise (TM). The current hierarchy is optimized for large networks of machines with shared software bases. Right now, such markets are way more important for Linux than home user desktops.
Am I missing something, or isn’t “/opt” quite exactly what you are asking for? I use it exactly the way you describe it for manually installed packages.
For managed applications I strongly prefer the standard paths, as there is no need to replicate the “etc-bin-lib-share” hierachy for every little application and as package managers make it far too easy to locate all components of a program – even if the are spread over the entire filesystem.
The FHS is retarded.
What are the Enviroment Variables For?
Just make a standar enviroment variable like $PROGRAMS or whatever.
Also another reason to have an /apps/gimp is for security. If it is a desktop (and not a workstation with a paid administrator) the user is going to have to be able to install applications on their own, and there is likely also more than one user.
So yes, this means they need root access or a full time admin. You could have them install it in $HOME/ but what about the other users that need to access the PC?
In this situation giving non-root write access to /apps could be the perfect middle ground in desktop linux security.
It would also offer a clear seperation of GUI apps and command line apps on the file system.
Also, I searched the FHS 2.3 for “desktop” and found 0 results. It does not say where to put desktop applications and is basicially subject to interpretation.
This explains why there are currently so many directories used for desltop applications today.
FHS makes no distinction between “command line utility” and “desktop application”
What about Onebase Linux? Is that distro like a “tech demo” (or whatever you want to call it) for the LSB? Forgive me, if this is something totally different…I’m a Linux n00b. 😉
http://www.ibiblio.org/onebase/
“I believe /opt is the right place for commercial software.”
Yes, but look at your own system and tell me how many of your GUI applications are not in /opt? Like 95%?
Why does you change commercial software to GUI applications in your reply? And why talk about %? Most people don’t have many commercial applications on their Linux machines anyway, making your 95% rather high in my estimates. But it’s not relevant anyway.
But if every person using the desktop types in the root password when something needs access what is the point of just not making them root users?
If you think about it for a second it’s rather obvious. The difference of running as root all the time, or to be able to switch to root mode when needed are huge. Since 99.99%(or more) of the time you don’t need the root privileges, and you run as ordinary user(even if you know the root password). Making it much harder to make fatal mistakes, like typos of the rm -rf /. kind.
If the package they are trying to install is a virus won’t they just enter the root password?
Possible, it’s still one step more than just running it. Some may stop and think and decide against it, but noting is foolprof. Users are also known to delete all their data files and not having backups.
That is the point of a possible middle ground like /apps, they could install the package but it won’t have full root access to the system.
Or perhaps $HOME/bin? You can call yours apps if you like.
“configurations should be in your home directory”
Maybe user specific configs, but in a multi user system the other user is also going to need access to the same application.
As it already is today, system configuration is located in /etc. And it’s shielded from tampering by normal users, they can only tamper with their user settings. In true multiuser fashion. Besides all systems need one or more administrator even if you don’t call them such. The only difference are how you place your trust. Ranging from one or more dedicated roots to everone are administrator all the time.
The issue with /apps is that it’s a backwards proposal. Instead of starting from a problem, and looking for solutions, people are starting from a solution (ie: the way Windows does it), and trying to apply it to problems. The actual problems that have been mentioned are as follows:
1) What happens when an app doesn’t install a link in the menubar?
2) What happens when the user wants to install an app but doesn’t have administrator access?
While /apps arguably solves the first problem, that doesn’t mean its the right solution for the first problem. Moreover, it’s debatable whether its even a very good solution. The average user won’t find /apps/gimp any more logical a place than /usr/bin. What average Windows user would know to look in C:/Program Files/Gimp? The comment somebody made about “what if I need to edit a config file for the program” is illustrative. Once editing a config file is involved, your average user is down for the count, regardless of whether it is in /apps/foo/bar.cfg, or $HOME/foo/bar.cfg!
If the user isn’t an average user, he must be an experienced user. If he is an experienced *NIX user, he knows where to look anyway. Only if the user is a Windows power user unfamiliar with Linux will he have enough knowledge to be able to link to /apps/gimp, yet be confused by /usr/bin/gimp. Does it really make any sense to do a drastic redesign of the *NIX FHS just to cater to Windows power users?
But the merits of /app are irrelevent. We’re looking for solutions to a problem, not figuring out how to justify a pet solution! The real problem isn’t whether /apps makes more sense than /usr/bin, because that’s too esoteric for the average user. The issue is the actual problem at hand, which is why the hell that link wasn’t created properly! That’s the problem that needs to be solved!
holy crap, this thread needs a *nuclear* cluebat.
in other news, I want to know why the freaking Debian Common Core Alliance (which has yet to actually _release_ anything at all) and Asianux get a mention in this PR and Mandriva 2006 (which is LSB 3.0 compliant, not that this would let you know) doesn’t. Did we not grease the right palms? sheesh.
LSB is mostly vaporware in the sense of ISVs using it. They prefer certifying for specific implementations, i.e. a couple of versions of a small number of distributions.
So my guess is that if Mandriva would have announced a vaporware compatible version, for example Mandriva 2006.5 VaporWare Edition it would have been first in the announcment
There’s a misconception that /apps or /Programs is somehow a newbie thing. It’s not when you think about it. It’s not a hindrance to newbies, but its really for the power user that is interested what belongs to a package.
GoboLinux does /Programs but it’s flaw is that it doesn’t have a package manager. I think /Programs coupled with a proper versioning packaging system like Conary http://lwn.net/Articles/138358/ sounds like a good idea to me. Also, it would probably play better with installers like autopackage.
We’re mainly talking about home/consumer/single user systems rather than multi-user/server boxes.
I don’t think Linux is going anywhere in the home if people think “It’s the Unix Way” and don’t start thinking outside the box.
1) /apps are for *Windows* power users. Linux power users who really know what they’re doing don’t have a problem finding things in /usr/*. It’s actually quite logical once you know how it works. As I’ve said before, I see no point in making such a change just to cater to Windows power users. There are actual problems to solve.
2) Your logic eludes me. First you say that /apps is for “power users”, then you say that Linux won’t get anywhere in the home, blah blah blah. Since when are “home users” “power users”? On top of that, I don’t think home users are a particularly good target for Linux anyway. They’re demanding, don’t pay for expensive support contracts, and use cheap random bits of hardware.
3) The “Unix Way” isn’t about dogma, its about the integrity of a design. An operating system isn’t a bunch of pieces, it’s a whole thing that is designed using certain precepts. You can’t just mix and match the pieces you like and expect to get a design that works. If a problem has to be solved, it should be solved “the UNIX Way”, because that’s the only way to get a coherent solution that won’t cause more trouble later than it solves.
1) /apps are for *Windows* power users. Linux power users who really know what they’re doing don’t have a problem finding things in /usr/*. It’s actually quite logical once you know how it works. As I’ve said before, I see no point in making such a change just to cater to Windows power users. There are actual problems to solve.
It’s logical because all the pieces of a package are spread out all over the place? I’m not buying that. Of course if you just buy the “It’s the Unix way” hook, line, and sinker then you won’t see any reason to change.
2) Your logic eludes me. First you say that /apps is for “power users”, then you say that Linux won’t get anywhere in the home, blah blah blah. Since when are “home users” “power users”? On top of that, I don’t think home users are a particularly good target for Linux anyway. They’re demanding, don’t pay for expensive support contracts, and use cheap random bits of hardware.
Wow, where to start on this one. So home users are not power users too? You seem to be forgetting the fat middle where people actually have a fairly comprehensive understanding of their computers, but aren’t programmers or “hobbyists”.
I’ll agree with you that in the current situation Linux on the desktop isn’t really going anywhere.
3) The “Unix Way” isn’t about dogma, its about the integrity of a design. An operating system isn’t a bunch of pieces, it’s a whole thing that is designed using certain precepts. You can’t just mix and match the pieces you like and expect to get a design that works. If a problem has to be solved, it should be solved “the UNIX Way”, because that’s the only way to get a coherent solution that won’t cause more trouble later than it solves.
Lots of handwaving there – “integrity of design”? hehe. But you can just mix and match pieces in the case of GoboLinux. It works, but suffers from lack of manpower and lack of a package manager that is still needed.
Please spare me the sound bites like “the Unix way, because that’s the only way to get a coherent solution”. That means nothing as you should know and just degrades the conversation. Give concrete examples.
46 posts (with a few exceptions) wasted discussing where software should be placed on the filesystem, when the LSB doesn’t specify anything about the filesystem other than the locations of /dev/null, /dev/tty, /dev/zero, cron scripts, initscripts, and default permissions for /var/tmp. It says that administration utilities might be located in the sbin directories. That’s it. Let it stop now.
DCCA did actually release something, or at least they announced that they released something. Last week I think.
The LSB doesn’t necessary specify the RPM format for LSB packages. It uses that RPM file format as the standard and allows for any other type of package manager that uses the same package format. So a conversion layer that turns RPMs into whatever else would be acceptable. A reimplementation of RPM to support smarter merging of config file changes (for example, hint-hint) would be LSB compliant as well. Just having the (possibly not recommended) ability to install RPMs into /usr/local, for example, would earn an otherwise complaint distribution full LSB compliance. I actually found the specification of the RPM/LSB package format (in nice C-style data structure definitions) to be quite an interesting read.
I guess the world just hates Mandriva. It’s like the red-headed stepchild of the RPM distros. I wonder if this has anything to do with the French and how everybody hates them, too. You know, because they drink pee, eat babies, and shave in all the wrong places…
Really, it doesn’t matter what the layout of the file system looks like (previously stated, I understand), thanks to various tricks we can have a variety of views of the data on the file system, including what’s installed. What needs to be understood is that the heirarchey is there to facilitate fast access, security and what not — think of it as more a setup for the programming and administering the low level system. Applications and other such ‘abstract’ collections are another matter entirely, something that doesn’t need to be addressed by the file heirarchey. That is to say the layout is there to organise files and nothing more.
What’s really needed is protocols. First off, how to query the protocol, find out what you need to talk to and possibly how to talk to it. Then talk to it, find out what’s installed. Uninstall something. Configure something. All of this of course has to be done securely and with respect to concurrency of access (multiusers).
The problem with the unix file heirarchey is that it’s great for what it does, but no one has taken it any further. The biggest problem is that people haven’t been willing to embrace heavily structured data and data access (XML/s-expressions + some validation + semantic standardisation).
Sadly, I’ll hear people going on about, “overhead”, “bloat”, “it’s not a panacea” and “stop drinking the kool-aid”.
The point is that people have this idea that nobody needs to know where anything is because that is the job of the administrator.
No, that’s not the idea. Even the administrator don’t really need to know where anything is, expect for the configuration files and they are always located in /etc and $HOME. The rest is up to the package manager. The only expections to this are when:
a. Installing binaries not intended for the distribution.
b. Installing from source.
c. Using a distribution without decent package manager.
Case a and c are not recommended for novice users and basically will require some administrator knowledge/experience to do correctly. Making it a big no-no for normal users. Since this is a advanced task really requiring a skilled administrator, the location problem are void.
As for b, it’s also require some knowledge and you can always use ./configure –prefix to install wherever you want. It be /opt, /usr/local, /apps or wherever you want. Making the location problem also in this case void.
It’s logical because all the pieces of a package are spread out all over the place? I’m not buying that.
For those with security in mind yes this is very logical.
Please spare me the sound bites like “the Unix way, because that’s the only way to get a coherent solution”. That means nothing as you should know and just degrades the conversation. Give concrete examples.
Files within /usr and /etc are to have read access but not write access. Files within /home/~ are to have read and write access. Files within /var are to have write but not necessarily read access. Files within /bin and /sbin are read only, and are separate from /usr/bin or /usr/sbin because they need to be available at boot time in case /usr is mounted remotely. The logic goes on and on like this. Something like /apps (which is basically how /opt is currently used anyway) is a bitch to administer because the process of setting the permissions is a bitch. Besides, what does the home user care about where the files are as long as they can access them through their desktop menu. And what does the power user care? They already know where to find the files anyway.
Making a system idiot proof generally only benefits the idiots.