Slashdot Mirror
Yet Another Call for Linux Standardization
An anonymous reader writes "Newsforge has an article Commentary: United We Stand...the Division in the Linux World, in which David Meyer argues that UnitedLinux will provide standardization for the Linux community that will allow it to win the desktop market from Windows. The article has a number of supporting comments, but then this one particular negative comment that disagrees with David. This particular comment offers an alternative view on the need for standardization. This aternative view that is put forward simply argues that 'Over what is almost twelve years we have pulled ourselves up by the bootstraps. We have done this using a development model that allows us to produce software that proprietary vendors cannot compete with', and then summarizing that 'the Linux community does not need to set up businesses with the specific intention of trying to "win" users from Microsoft; all we have to do is continue to develop software in the same way, and the users will make the switch all by themselves'."
- Why do we still have to choose between a bunch of different desktops, ALL of which are mutually incompatible?
Out of all the duff crap in your post, this is worst. There's nothing stopping a KDE user from loading Gnome apps or vice versa, you just have to have the appropriate libraries loaded.
The author makes little to no suggestions as to what we can do to solve this problem. Even more useless is that he does not even describe the problem he's trying to present. Like another poster mentioned, just because a group of people use Windows does not make them united.
I believe the Linux wave is going great. Linux software is farther ahead than it's ever been (since it's been given time and hard work), and we're gradually coming to accept a certain number of features as "standard" for any given distribution. Making his comparison to Microsoft, he seems to suggest that all the distributions should "unite together" and make one big distribution. But then... where's the choice? Where's the variety that shows us alternatives and suggests ways to improve our systems even more? There is no one solution, and I'm happy that all these distributions exist, as it allows me to find my own solution based upon the work of a dedicated group of people. Without Mandrake and Suse, who's to say Red Hat Linux is the right solution? Likewise, without RH and Mandrake, who's to say Suse is the right solution?
The only thing I can think of, and something he didn't touched on, is the rippling of changes back to the original maintainers. There's nothing more frustrating than adding a component to your own custom system and thinking, "How did Red Hat put this all together?" Of course, you can always grab their source and figure out how they did it. I find a lot of these changes that the individual distributions make are bug fixes or feature improvements (patches so the software installs properly, or extra data to allow better integration into GNOME/KDE menus). It frustrates me that these changes don't make it back to the original package maintainers as often as they could. I would love to see the pam_stack module make it back into the Linux pam distribution so it can provide base level authentication services without the need for lengthy post-package patches and other tweaks.
Granted, there are some modifications that come with the territory. I see no reason for maintainers to have to adopt the Blue Curve theme that Red Hat uses to dress KDE and GNOME like each other. But at the same time, it would be nice to be able to pick and choose software packages and not have to worry about re-doing common work that all the distributions have already done.
Anyways, back to the article. I think this guy spouts a whole lot of nothing. There is nothing wrong with the way things are going with Linux and if there is, we'll get there soon. But keep in mind that Linux users are not Microsoft any more than Windows users are Microsoft. I use Linux because I feel comfortable and secure using the environment. I built my own server system from scratch because I wasn't happy with the choices offered by the different distributions. And that's the luxury of using an open system, to pick and choose exactly what you want.
What's the problem?
/etc/init.d/ since the get-go while RH have been messing around with this "/etc/rc.d" abomination which then needs legacy support on the assumption that there are idiots out there who can't cope with RH correcting their previous mistakes.
/proc, to tell me where in the filesystem the httpd is located that's responsible for a given webserver. If you can't debug that, you ain't gettin' root on my boxes.)
a) RPM already has at least two ways of being upgraded dynamically - urpmi and apt-get. It just needs a consistent well-maintained high-quality upstream pool-set
b) Debian supports RPM packages just fine.
c) The standards (specifically, the LSB) say nothing about requiring RPM to be the system's native package-managing system.
d) Debian already strive for LSB-compliancy, at least where it makes sense. This is why we've had
"the system directory on Windows 2000 is \WINNT"
Well, only *if* you install it that way.
And one for thought: which is more important, adhering to a standard for the sake of it, or knowing what you're doing? (A specific example of the latter: given an IP#, I expect you to be able to trace through DNAT, netstat -p or similar and through
~Tim
--
Rushing on down to the circle of the turn
Linux programs can have config files in /usr/local/etc too. And for a very simple reason. On pretty much any distribution programs go into /sbin, /bin, or /usr/bin. Those are the ones that come packaged. When you compile something most programs default to installing into /usr/local: /usr/local/bin, /usr/local/sbin, etc to avoid messing up your system.
/usr/local then it won't interfer with anything vital (root doesn't have /usr/local/bin in $PATH), and if it doesn't work well you can quite safely nuke /usr/local because the distribution never installs anything there.
/usr/local/etc will have the config files for those programs. If squid was installed as a package but the config file was in /usr/local/etc then the package wasn't made correctly.
It's actually a very good thing. If you ever say, compile Perl and install it in
Logically,
To use your analogies:
Different TVs, but they all can view the same channels and use the same antenna connectors.
Different VCRs but they all use the same tapes and work with any TV.
Different cars, but they all use the same gas and standardised oil grades.
Differnt refridgerators, but they all use the same electricity.
That's the kind of similarity you need to standardise in user space.
Engineering is the art of compromise.
Regarding RPMs - Two thoughts - find aptrpm and get it to work, or try Debian.
Seriously, Apt is Debian's #1 selling point for most users. The #2 is stability. Rock solid, if you're running the "stable" distribution, you can update software daily, and nothing should break. Ever. (The only exception being the incredibly rare case of the feature you depend on being inherently insecure, but even then, I think they just fix it as much as possible, and provide a warning on install.)
Dependencies are most RPM distributions single biggest problem, imo. Apt or its cousins, aptrpm (maybe apt4rpm?) and up2date serve primarily to solve those problems - try that, and see if that makes your life better.
I may be a Debian bigot, but I know it's a hard distribution to get used to, heh.
And they won't be. I think you're missing a fairly crucial point which is that the desktop Linux effort only really started in '96 with the launch of KDE. In '98 KDE1 was released, and that's when the ball started rolling. That means the linux desktop has in effect been in existance for 4 years now.
In that time, KDE and GNOME have gone from ugly, unstable and primitive desktops into powerful, beautiful and yes, in the case of GNOME2 even usable desktops. Not only that, but a truckload of applications have been developed, installation of the OS has become childs play and an open standards effort has been started to unify the interfaces between desktop components.
That's a lot of progress.
And, it will not happen if too many Linux developers continue to imagine that their development model is what they're selling. It isn't.
Given that Linux has never been marketed as such, it's only ever grown through word of mouse, I think there is sufficient interest in not just the technology but also the development model.
Business in particular is keen on the idea of ridding themselves of vendor lockin, being in control and being able to easily maintain old software if the original vendor/maintainer no longer carries on.
There is: the etc/ directory is for global configuration data. /etc/skel/ is for the default user config. The user's home directory (aka ~ aka $HOME--often /home/username) contains his/her data and config files. lib/ is for shared libraries. shared/ is for the program's data. bin/ is for the programs executables. I believe the "shared" directory is a new concept (at least to Linux), everyone used to put their data into lib.
The users config files are usually named as a dot, the program's name then "rc" tacked on the end. If the program's name was bar, then it'd be ".barrc" in the home directory. Realise that anything starting with a period in Linux/Unix works like a hidden file in DOS/Windows--ls/dir won't display it unless you use the "-a" option. So looking at a listing of your home directory, you'll only see the data files instead of the clutter of all your config ones too.
If you wish to backup your general settings in Linux, storing /etc, /usr/etc, and /usr/local/etc should do it. The problem is not all programs written for Unix/Linux will conform to this standard. For example, Jed and lynx put their configuration files into the lib directory. Just like some Windows programs store their settings in ini files under the C:\Program Files directory...
Having three different places (/, /usr, and /usr/local) for everything may seem strange, but there is a reason behind it. Everything in /etc, /bin, /sbin, /lib are supposed to be the basic critical programs and system settings. /usr is for the programs used by most everyone in your organization and is often mounted read only from the network. /usr/local would be mounted on the computer's hard drive and programs added for the user(s) of that specific computer.
You may think the registry is a good idea, but it is just a poorly designed clone of the Unix way. Same goes for the "My Documents" folder vs the /home directory. Just proves the old saying "anyone who doesn't understand Unix is doomed to reimplement it poorly."