Slashdot Mirror
Deciding On The Future of Linux
A reader writes: The Free Standards Group has posted a request for feedback, now that they have completed LSB 1.2 and li18nux is also finished. Where should they/we go next? "
← Back to Stories (view on slashdot.org)
Alan Cox is illusively quoted as saying, "The community is great for getting the work done, but when it comes to making decisions about where Linux is going, that responsibility should entirely rest on the shoulders of Linus. It's his operating system, and we shouldn't be able to take that away."
I want to agree with that quote. The guys programming Linux and the kernel and so forth are all hard workers and decide to where it's going.
I can't see why the FSF is trying to become the new Linux authority. First they've tried to claim that much of Linux was written by GNU, this is not true, I put to you, they tried changing Linux to GNU/Linux. Notice that GNU is placed before the word Linux, this implies a strong bias towards the former entity.
Linux was named after Linus Torvalds and he is the monkey at the top of the pole, NOT the FSF. If anyone wants to ask where Linux should be headed, it should be him and not the FSF who are simply angling for bonus points in the petty argument.
mogorific carpentry experiments
What should they standardize next? Copy/Cut&Paste! It is one of the most important features of a modern desktop OS.
RPM is pretty crap how it dumps all your apps into /usr or /usr/bin without any thought. "Program Files" folder in Windows is what Linux needs, except we could call it "/apps" or something like that. Give each program it's own sub-folder and keep things organised (and organisable).
Well, I had a bunch of ideas and then I read wackybrit's comments, and, uh, I agree with those comments. So now I'm stuck wondering if I should suggest anything at all. Since I'm already here....
A common clipboard, for copy and paste, would be wonderful. If I copy text from Konq and want to paste it into Pan, that should work every time. I note SuSE appears to have done some work here -- sometimes I can copy & paste in SuSE just fine, while other distros are not so fine. Another thing that would be great: common menu system. In fact, it would be great if the menu system was actually just a directory on disk with some subdirectories in it, each populated with links to various apps. That way, if a Window Manager or desktop tool didn't want to offer a menu system, you might still be able to navigate it. If that were in common for all or even many of the WMs out there (KDE, xfce, Gnome, IceWM, and so on), that would make things far easier. Note that I'm not suggesting that Red Hat be copied and KDE apps be pulled out of the menus -- populate the menus with hundreds of apps if you wish. Just get it in a standard format. Finally, common desktop icons (again, not that there have to be specific apps that must be there, just that if I create a link to Galeon on my desktop, it'd be swell if it appeared in KDE and Gnome (and other) desktops.
These may be in LSB 1.2 -- I've got the page up now & I'm surfing through it, but you guys are slashdotting it a little, so it's slow going....
My Greasemonkey scripts for Digg &
Till now we have seen this on games. However I know lots of situations where I would prefer a 3D interface rather than this archaic 2D windowish (X, Windows, OS/2, Mac OS - no matter) world.
/var/log and you may see a lot of interest moments where it would be easier to deal with this mastodon in a 3D space.
One of the main situations would be on working with large multidimensional data. Think this is too far from you. Take
We already have 3Dwm. But it looks like a little forgotten puppy in the middle of nowhere. Probably because no one created a standard in the same way X was created. How to fit legacy apps or even the command line in the new world? How people will create new apps for 3D if there is no largely accepted standard? Frankly these are issues I think one should think about. Maybe all this is still a bit futuristic, but the time has come for 3D to get more serious. In the place where we work we are already developing a 3D tool for some highly popular program because no one can hold the information that comes in flat relational tables. When one comes up to 2Gb of information a day, information just seem to blow up in front of your eyes.
Besides, I dream to see a 3D penguin behind the flat surface of Windows...
You are either a troll or a moron.
Libraries are there for a reason.
Get it so i can use a bunch of different font encoding with out my apps crashing all over. Every go on irc and some dude is using fonts from a different encoding scheme and it crashes everything? Or try and read pages in a asian language and it just comes out like gobbledeegook and then when you try and set it to display the asian shit the english stuff gets fucked. Please do make it so any fonts will "just work". I know linux people don't like to have stuff "just work" it makes it less l33t or cool or hardcore or something, but seriously it's just fucking annoying.
There are already organizations that are determining the direction of Linux. Some are for profit, some are volunteer efforts only (at the moment).
Those organizations are commonly called the distributions.
For example:
Mandrake
RedHat
Gentoo
etc
etc
etc
The distro rollers can do anything they darn please and often do. This gives us variety -- and when a certain distro is liked well enough, de facto standards as well.
Think about it: Say the FSF was in charge of the "future direction." What would happen? A whole lot of folks would be POed about whatever that direction was, splinter off, and then we'd be in exactly the same situation we are right now and NO ONE could do anything to change it because of the nature of the GNU license.
Sure, sometimes Microsoft style control gets things done more quickly and efficiently -- and often result in the emergence of features and instantaneous standards that might not otherwise appear. But at what cost?
Dictatorships are the most efficient forms of governance known. Most folks would probably prefer not to live under them though.
Freedom is sloppy.
"Program Files" folder in Windows is what Linux needs, except we could call it "/apps" or something like that.
/opt ???
Hmm... perhaps
Maybe the rain Isn't really to blame. So I'll remove the cause, But not the symptom!
I know this will be modded as a troll... But how about getting all the Linux distributions to actually use it before considering the standard "finished".
Of course, there might still be a need for inter-program dependencies (for example, perl programs tend to work best when perl is installed) but in the interest of eliminating dependencies it's probably best to hide the fact from the user. The "command not found" messages that result in situations like that will undoubtedly alert the user to the fact that he or she should probably find and install the appropriate other package(s).
Duh. Apt and/or a Gentoo ports-like system are the answer to this type of problem. The security and flexibility edge goes to gentoo, for the USE variable - it allows me to not build (for example) PCRE support into Postfix if I don't want to install and depend on PCRE. Apt is easier and faster. Both are nice solutions to a common problem. As another example, Microsoft admins all seem to like the new Windows Update feature, for the exact same reasons we've all loved apt, ports, and gentoo for years - automatic updating of everything that needs updating with dependency resolution. Of course, our solutions are better because we don't force license-changing upgrades on users, but that's not a technical issue at all. For the time being, this type of solution is the best available for a problem faced by ALL computer administrators.
I always interpreted GNU/Linux as "GNU environment running over the Linux kernel". It seems that 90% of the users care for the front-end tools (such as their $EDITOR - vim or emacs or whatever, their shell - like bash, etc.) Most of this is GNU, so I think the FSF does have a point about the GNU/Linux name. I even say "GNU/Linux" myself in the context of discussions dealing with the end-user environment.
OTOH, as far as I read into the FSF docs on the "GNU/Linux" issue, they're *so* nerdy in the worse sense of the word and so much repeating themselves along the lines, that I perfectly understand the frustration of people like you who don't have the patience of hearing the rational points behind all the major rant.
VKh
In my opinion a big issue that keeps many users away from Linux is its dependencies system.
Packages at building/installation time should require only the features they actually need, not the ones present in the original machines they were developed on.
Frankly, I'm tired of being asked almost every time I download something that I need for it to work to get the very-latest[-beta-preliminary] version of some other program/library. I agree that sometimes it's necessary to upgrade some parts of the system to work with fast evolving technologies (new multimedia codecs, new communication protocols) or for security issues, that's ok, but raise the hand who never had to upgrade a bunch of libraries to install a small app, for apparently no reason.
This is a serious problem; something should be done to force packages to require the _first_ version of a module/library/program that contains the needed feature, not the latest one.
I'd love to see some steps taken in that direction.
Just my 2c.
This is solely designed to make things easier for third party app developers, since they know what they need to target. No distro is forced to follow the LSB, but if they want the maximum number of third party apps to run, then they will follow it, and get LSB certified.
Apart from this minimal framework, distro's are still free to do what they like. And since the FSG is not tied to any particular distro, they're not likely to favour one distribution over another.
To call that dictatorship is ridiculous, you might as well accuse the w3c of dictating all content on the internet, since they set the html standards.
All of the distrobutions should work together to create a plug-and-play type environment similar to Apple's. I have a Linksys Wireless card let's say, and when I plug it in and insert the Linux CD, it should install the wireless software, drivers for my card, and prompt me with what info it needs to work.
Standards: yes
Single Standard Implementation: no
All the X GUIs these days seem so focused on the G that they're ignoring the U and the I. There should be some standardization on the I, and the variety of Gs(The WMs and DEs) would be implementations of the standard.
freedesktop.org has the right idea.Cool, I can post, this is my first post here! (sorry for the above)
./configure will fail. This is the standard for any opensource program, but it's _too_ hard for the regular joe user. For the experienced user, installing a few of these by is fine, but compiling the whole OS is for the hardcore. Also there is the issues of libraries/compilers getting ugraded in distros, which can make compiling even harder.
.
What you say is all nice and dandy, but you are missing the point and going to the opposite extreme of the situation, let me explain graphically:
all source - A - B - C -D - all static
A: Compiling all from individual source: you get a tarball and compile, if it has dependences,
B: Get a binary package: Mandrake, debian, etc all use packages. This works fine, and it's amazing to simply do apt-get install
But when some program (or the latest version)
is not aviable, you have to fall back to compiling
from source. Debian proovides all development packages you need, and gentoo by default installs
headers and stuff for libraries, but this is _still_ out of the scope of joe user.
C: Proovide a binary with the dynamic libraries included: This is what windows and MacOSx do!
It's by far the easier for the developer and the user! you just proovide an installer. The installer _comes_ with the libraries you need also compiled, then the installer checks the versions of the libraries already installed and, if not found old ones are found, will just install the new version. Most _important_ libraries in linux
are already stable and support this just fine.
From the user perspective, they just download a program, run the installer and everything works.
They will usually delete the installer or backup it, so this wont take up space. Also, if it wasnt for the reason that unixes dont have "." added to the path by default (is it the same in osx?) you could also do local installs. This is also very
easy for the developer: besides the source, he just puts up a binary, and throws in the needed libraries for each release.
D: Proovide static libraries. This is hell because of what the parent post says, and also because your install will be huge!
Have you guys ever talked to new linux users, their biggest complain on the OS is not drivers,
the existence of multiple dekstops, etc. It's just
that installing programs is _hell_ for them. Even when i know using debian is dead easy, not everything is there, and as developer, not all my programs find a package mantainer.
So, maybe someone more experienced than I am can
tell me why doing things the windows-mac-beos way
isnt possible? I personally think it's simply because of lack of organization, but i may be wrong!
reduz
Even though /usr, /var, /tmp, /etc are ridiculously cryptic, changing them would be horrible?
/etc to /settings or /config /var/log to /logs /var to /data (or something like it) /tmp to /temp (saving one character? sheesh!) /usr to /programs /bin to /system_programs
/etc may have difficulty configuring their box to be sure. But they'll have less difficulty if the directory is named /configuration or /settings won't they? The operating system shouldn't be some kind of high bar or IQ test. It should be a tool to get a job done. /etc to /settings doesn't make your life and my life appreciably harder and it makes life for newbies that much easier.
/etc less oddball than /settings? What universe do you live in? The directory name "etc" is an artifact of history, not a brilliant design plan. 1K of memory was expensive so the directory names were kept as short as possible. Now 1K is a rounding error. The reasons for "etc" no longer exist today. You might as well tell me that people should still hone their PDP-11 assembly skills before doing any programming in a high-level language.
/etc. Good for you. After the rest of the world moves on, you can make your symbolic links. The rest of the world -- this includes all of those folks who accurately regard a computer and operating system as merely tools -- is used to descriptive names. /etc ain't descriptive. It's the UNIX club's code word for /settings. They like code words. It's like a secret handshake. It maintains a feeling of superiority however obviously false that feeling may be.
Get this:
Change
Change
Change
Change
Change
Change
and then (drumroll) make symbolic links so that old scripts and programs still work. You leave that in place for a couple of years, and then you remove the symbolic links. All that's left are logical names that actually convey information. And before people complain about the amount of extra typing, please tell me that you know how to use <tab> for filename completion (se<tab> gets you settings for example).
Users who can't remember that config files live in
And how, by any stretch of the imagination, is
You're used to
- I don't need to go outside, my CRT tan'll do me just fine.
For as long as man-pages stay, OK. I use man-pages, and where an application doesn't have a man-page, I'm first inclined to throw it out, but most often stay cool and start seaching for documentation. At least please package a man-page that points to the documentation with all software.
Documentation shouldn't be X-dependant, but should be readable in text-only 80x25 screen.
Different programs have different needs from their config files. Trying to fit one model to all isn't really a good solution, as that model would have to cater for the extremely complex configuration some software might need, while still be very simple for the programs that just need five key-value pairs.
Config files have to be human-readable and hand editable. I'm not going to use the various whiz-bang graphical configurators when I still have vi. At least regarding system config - configuring various all-graphical applications is another story, but that's not system-config.
However, requiring text-only configuration files and version control of the whole configuration hierarchy would be good. I have seen some ways to use eg. RCS for all of
Of course this also means that there would have to be a hierarchy for configuration-only files, and any non-configuration files in
Perhaps configuration file hierarchy should be such where each package would use it's own directory, and where necessary, use symlinks.
This is something we need ... yesterday. An XML (or whatever SGML they choose) office format standard. I know there is
work in progress from the Open Office Project, but I would rather have this work merged in a standard dictated by the Free Standards group. That alone would represent a HUGE step forward. Let's hope.
Different programs have different needs from their config files. Trying to fit one model to all isn't really a good solution, as that model would have to cater for the extremely complex configuration some software might need, while still be very simple for the programs that just need five key-value pairs.
/etc should have to find a new home. eg. RH73 /etc/sysconfig/network-scripts has both configuration files (ifcfg-*) and programs (ifup*, ifdown*). Whether eg. init's rc-files are configuration or programs is of course questionable..
/etc and you have all configuration. Basically, there are two ways of dividing files -- by program (cf. Windows), and by file purpose. Unix has chosen the latter, and package managers are designed to allow grouping by the former.
True. I'd like to see a standard set of configuration types (ie. INI, table (tab-delimited or whatever), shell script, etc), and then a special type called "custom". That way, someone could say "Standard INI file", or "Standard table configuration file", and there'd be not only a library which parses the thing, but a documented format for the little weirdnesses of each format (ie. INI files all need to have [] header sections, or whatever). Then "custom" means "I'm weird", eg. Sendmail, and it's non-standard.
Of course this also means that there would have to be a hierarchy for configuration-only files, and any non-configuration files in
You'll find that the ifcfg files are actually shell scripts too, it's just that they only set variables, and don't do anytihng else.
Perhaps configuration file hierarchy should be such where each package would use it's own directory, and where necessary, use symlinks.
I don't like this because, at the moment, you back up
I know this will sound troll-like but I've got strong feelings on this one...
I'm sorry but most documentation does not benefit from SGML, and considering that getting free software authors to write docs AT ALL is a chore, there should be as few obstacles as possible. Maybe we need to unify the _access_ to the docs. I can basically type "man command" for any command on my system and get help, but maybe I should also be able to do "docs command|package" and get an automatically generated list of options for related man pages, html files, web sites, etc.
I've said it before and I'll say it again, XML is not a storage or configuration format, it is a transport format to serve as an intermediary between two disparate systems. It is horrible to have to edit or parse XML for human or computer. Using XML for config would be much easier for beginners and annoying for experts. That aside, instead of 80 billion ways to write a config file you'd get 80 billion DTD's. If you think you can unify all the config files on one DTD, good luck to you.
In short - XML is NOT a silver bullet. It's a different breed of the same dog.