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)
Should linux next try for a) a standardized and integeated windows like shell b) new functionality c) faster preformance(its starting to get fragmented) d) cowboy_neal based penguin logo
When life gives you crap, Make Crapade.
Sluggy Freelance.
How about creating a standard for dealing with new hacks that have to be put in place to deal with propietary software that people think is necessary? For example, there should be a way to add to networking systems everytime some influential company decides to extend to their own "standard." It would be especially nice to be able to tell my users when and how something will be in place cuz once they get the bug up their butt they want answers now.
It's all about drivers and compatibility with those gadgets...
:)
For example, the reason I'm running Windows now is because I can't get my darn Palm m515 to work in Linux, and I don't even know where to start looking for help with my Minidisc Player...
So it's all about compatibility with those gadgets in my book
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
I think Linux needs a standardised pricing scheme.
Did they just ask "where do you want to go today?"
What should they standardize next? Copy/Cut&Paste! It is one of the most important features of a modern desktop OS.
On vacation.
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
If these folks were real coders instead of marketroids trying to jump into the Linux bandwagon, they'd know that the LSB acronym is already taken. Sorry folks but LSB will always mean "Least Significant Bit".
Click on the final link in the description and leave your feedback there or if you plan to leave it on
At least in the RPM dependent style of package installation this can be a real pain in the *ss. I kinda hate having to install 10 or so other programs just to get the intended one to work. Yah I could just build it myself, But if Winders can do it so easily, then why can't we?
Plus these semi-redundant libraries can also eat up disk-space and download time.
..........FULL STOP.
Get linus torvolds to stop using bit keeper and make linux truly open source.
I think that they should decide on creating a interface for basic administration in all unices.
For example, setting devices, admin of packages and so on.
If someone else can understand what I am saying please elaborate.
I currently use Windows for ease of use. With it, you can specify what programs you want to handle certain types of files, and the operating system remembers your choices. This greatly aides with the multi-media functions of my home computer. The last time I tried linux on my desktop, that was the one thing that annoyed me the most about the OS in general. There seems to be no standard way for users to specify what programs they want to use for certain file types, which would in my opinion greatly increase user productivity and decrease user frustration when using Linux on the dekstop.
Not to start a flamewar, but what efforts should we put on establishing Linux as the number one OS of the future? The more we follow in a single file, the easier we fall. There are some superb alternative systems around thesedays -- I particularly like RiscOS for ARM boxes. Very, very sweet and usable desktop, extremely fast (written in assembler), and has a decent range of hardware.
As a Linux user since 1997, I've been impressed by the strides made in the user-friendly desktop arena, but it only takes one man to win the game before the cows come home. I think we should all consider this -- as they say in football, it's a game of two halves, and Linux isn't necessarily the OS of the future.
Linux is in greater need though of uniformity between the multitude of administration tools. It hasn't made a great deal of progress in the last 5 years in this department, sadly. Fortunately, things are getting better in this area and we may soon be in the position to conquer corporate desktop deployment on a large scale.
So let's not base our future on Linux as a whole, but on the wide range of free and Open Source software we can apply to our systems. Linux is the OS of the future, but we must maintain our dignity and versatility in accepting other systems.
Just my thoughts. Mod accordingly!
Decode A Penguins Gene Sequence and embed it in to the kernel.
Disneyland!
If I'm reading this issue correctly, it's the idea of dependancies themselves that are the problem.
I kinda hate having to install 10 or so other programs just to get the intended one to work.
All you debian people will start screaming about 'apt-get' here, but that's not the point. ONE program shouldn't necessarily require the installation of 4-5 other programs, regardless of how the installations are done. Just because your 'apt-get' downloads and installs them for you doesn't mean you're not having to install other packages, you're just not thinking about it. There's still extra bandwidth and diskspace taken up, and more security considerations to consider. Having package X installed to run package Y means I have to be worried about security for 2 packages, even though I only want to use one package. We bitch at MS for this - tying multiple programs to IE - but it often happens in the linux world as well with packages - package X requires package A, B & C be installed. Why can't just the required bits of A, B & C be rolled into package X by the author? Or - heaven forbid - just provide a binary with all the necessary libraries bundled together.
creation science book
The I8N team has only released specs for UTF-8. That is not the complete Unicode 3.1 spec. UTF-16 is needed.
The obvious thing to do is get support for UTF-16.
Both input and output.
And yes, I realize that inputting UTF characters on an ASCII keyboard is not simple. Either virtual keyboards, or a complete list of the UTF-16 set, with the alt keys would be very useful.
[ though typing alt0x0100 etc gets to be painfully slow.]
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 &
Try it out... it has...
a) a standardized and integeated windows like shell b) new functionality c) faster preformance
and it has very easy RPM installations.
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.
Maybe I'm an idiot, but what does the FSF have to do with the Free Standards Group.
You actually have the powers of observation and fact checking. The ultimate goal of any Slashdot troll is to demonstrate that public moderation is flawed, since you have idiots who will believe anything that seems halfway believable.
Those idiots moderate up trolls. By posting trolls, we make idiot moderators moderate us up.. and then in meta-moderation they get knocked down. In this way, trolls are killing off poor moderators and improving Slashdot for everybody.
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.
Huh? Is that supposed to mean "internationalisation"?
Where to go next? For starters, remove the Unicode/UTF shit in the latest RedHat release, and ddon't introduce it in other distros. It seems like this has broken all "international" (i.e. non-English) installations, which used to work just fine in 7.3 and previous versions.
It seems like the Unicode mess was introduced to help users in East Asian countries, but then Asian locales don't even default to Unicode in Psyche!
First they need to convert every output to hexadecimal. It's good to able to post knowing nobody will read what I have to say.
"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".
They sound like they should be taking notes from beunited.org
The BeOSJournal recently spent over 2 hours in the second part of an ongoing interview that outlined the future direction of the non-profit organization.
BeOS may be dead, but openBeOS is alive and well, and with the help of beunited.org, will start to achieve many great things.
It would be great if both groups started a relationship that would surely benefit everyone involved. It's through open communication and a willingness to sit down at the table that anything positive is going to be done.
I'm not trying to bash the Linux Community at all, please understand, but I feel it's in our best interest to help each other, when the giants that we all love to hate (such as M$, IBM, and others) won't sit idly by while their market erodes in front of them.
That's all I'm saying. Take a good hard look at what beunited.org is up to, and see if that will help you any. Thank you.
user@host$ diff
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.
Which is the same comment I would apply to most of the things I see brought up here. I don't helper apps has anything to do with the OS itself.
I think a good move for Linux would be to keep heading for the Single UNIX Specification from the Open Group.
It would make it much easier to port all of the existing UNIX applications over to Linux. Also, being UNIX compliant would give Linux creditability in the minds of corporations who are looking for alternatives to Windows but do not want to pay or cannot afford a commercial UNIX environment.
What distro are you guys running? I see comments about needing a clip board, and using control-x,c,v for cut and paste, and needing a way to define helpers for certain file types etc.... I don't know what you guys are on but my Linux does all this stuff. I'm on Red Hat 7.3 with Ximian desktop...
which are:
Unified System Documentation I want all docs in a single, standard format that all programs must write their basic documentation in. No more man, info, html, pdf, ps or whatnot. I'd prefer a fixed SGML DTD (docbook is OK, but I'd prefer a designed-from scratch one specifically to address the system documentation target). That way, we can can get good viewer independence with modern features (hyperlinks, fonts, in-line graphics). All of the current formats are lacking in at least two areas, and we don't have agreement on which to use. This is a big place for them to step up.
Standard Config Files No, this is not a request for a Registry (the merits thereof are for another discussion). What we want here is to get rid of the 80 billion different ways to write a config file. I'm sorry, but they all should be a nicely tagged XML (or similar) file nowdays. It sucks to have to figure out the idiosyncrasies of the various config files. This issue isn't simple, but is definitely a place where a good discussion is needed.
-Erik
There are always four sides to every story: your side, their side, the truth, and what really happened.
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.
Others seem to want to turn linux into windows. If only (mime support/windows like shell/c:\Program Files like dir structure) was finally included I would start using it. Yeah right like anyone cares. I think that with the burst of the internet bubble the idea that linux should go to the masses has been left behind. If you saw the interview with Linus himself on the BBC you will have heard that he does noet even wish to compete with windows. MS has its market and linux has its own. That is real freedom of choice people. Those people that want linux to become like windows just want a gratis (not free) version of windows.
The FSG is a standards group, I presume therefore that their question is on what if anything needs standarization next. Standarization is not the enemy of freedom when standarizing on it does not put a brake on innovation. A standard desktop for instance would limit innovation and therefore choice. A standard directory layout does not unless I missed some special signifigance in keeping youre logs in /.[sic]
So what needs standarizing next? I have no idea. Software creators now are reasonably sure where to install the bits of their software and how they can achieve multi language support. Printing is also ridicously easy (could be because I only have access to HP printers). Is anything more needed, almost certainly, let the creators figure this out and not disturb them with a dozen wish lists by windows users who will never switch over because it will always be hard to switch to something wich is different. If it wasn't different then what would be the point of switching at all.
Use linux not because someone tells you to. Use linux not because you want to stick it to Gates. Use linux not because you want to be l33t.
Use linux because you like it strenghts and can forgive its weaknesses.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Why is everyone referring to the FSF?
This is the Free Standards Group (FSG), not the Free Software Foundation (FSF).
This is about standardizing things across distributions, and setting up a set of useful guidelines that have been well thought through.
Some things I think need researching:
- A bunch of wrappers aimed at making it easy to write GUIs for services (activation, status, description), hardware/network/... configuration, etc etc. A bit like standardizing the backends of the ex-Ximian Setup Tools.
- A decent set of guidelines to handle virtual hosts on servers + wrappers for their configuration/administration.
- moving beyond the fhs: new filesystems and kernel changes introduced will allow a whole bunch of new functionality. I'd like to see some discussion starting about how we can leverage the advantages of union mounts ( "/" vs "/usr": really still needed?), extended attributes and ACL's, LVM etc.
I'd also very much like a comparison with completely different filesystem layouts like MacOSX. I realize that the FHS came to be for very good reasons, but I'm hoping that since we'll have all these features available to us we'll be able to simplify the structure alot without giving up any of the advantages. It's not always nice to be stuck in a lowest common deminator legacy world.
But system documentation is fundamentally different from technical documentation (DocBook)? If a new schema is made, I would hope that it's at least a subset of DocBook (like already existing Simplified DocBook).
Other than that, you took the words right out of my mouth. An LDAP interface to general configuration info would be nice too: network aware and accessible configuration and authentication info as a standard feature (but network access to it turned off by default of course for security reasons).
- I don't need to go outside, my CRT tan'll do me just fine.
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.
Reduz, I think you'll need to learn that posting something nominally thought out, or even just basically against the 'Linux rules! Unix rules!' mindset is frowned upon here. Obviously you didn't read the parent post well enough. EVERYTHING should be dynamically linked. EVERYTHING. ALL THE TIME. Because to suggest static linking OBVIOUSLY implies that it must be done ALL THE TIME. The parent poster must know what he's talking about, right? After all, he's probably a 50 year Unix veteran and Linux kernel hacker who's contributed much to the current way of doing things (that's why he knows so much about the way things work).
Suggesting using a technique in moderation and in instances where it would make things easier for end users - or even worse, suggesting doing anything like MS or Apple - is just not the done thing here. I hope you can internalize these points and remember them in the future when you post.
Thanks!
creation science book
Actually, the best way to implement this would be in the shell. Trying to put MIME types into the kernel would be a REALLY Bad Thing(TM).
Of course, then you run into the whole sh, ash, bash, ksh, zsh, csh, tcsh thing, which means that you would have to get people working on separate projects to agree on the format of the configuration file and where to put the information.
Frankly, I don't understand why the OSF hasn't taken this by the horns and rolled it into POSIX. If compliance with POSIX is a Good Thing(TM) for shells, compliance with the MIME standard seems to be made to order for the OSF to address.
Just my US$0.02
utter rubbish
As long as rpm is there as the default format in LSB, LSB will be considered as a counter-productive standard by many bolded linux geeks. As a next move, LSB group should think of the ways to reformulate the requirements for rpm as the default package
This post deserves to move in that direction. It contians many insults and nothing positive. There are so many silly things said, it's hard to even start correcting it and we can imagine that wackybrit knows better but wishes to be malicious.
I can't see why the FSF is trying to become the new Linux authority.
Funny, but I don't see them doing anything like that. The tools they provide are first quality and they have every right to guide the development of those tools. Those tools are supposed to be kernel and architectur independent and are. Remember the hurd? It's here and the GNU tools work with it too. The only thing the FSF really cares for is your software freedom and the GPL. They stand for your right to run, modify your sofware as you please and your right to share those modifications with your friends. Under those rules you can make your own kernel and your own tools from thier set and call them what you want.
My wife and I like monkeys. One of my pet names for her is Orang because she has red hair. She calls me Gorile. Most people, however, don't like being called a monkey. We are strange, you, wackybrit, are a jackass.
Friends don't help friends install M$ junk.
that should be "like call wackybrit a troll and a jackass." Ah yes, the more I do it the better I feel.
Friends don't help friends install M$ junk.
Also, all source distribution is not the opposite of all static linking. All source distribution and all binary distribution are opposites. Static linking is the opposite of dynamic linking. Both static and dynamic linking can cause problems.
In general, the proper approach for normal userland applications is dynamic linking with versioned symbols for preserving backward compatibility for existing binaries while offering new functionality to applications built against newer libraries. This is what glibc now does, and the approach has been a huge success. I remember the libc5 -> glibc2 transition. It was painful and ugly. It won't be necessary again thanks to versioned symbols.
Static linking is appropriate for applications which need to be functional when the rest of the system is not, for a sufficient portion of the kernel to be booted properly, and for most proprietary software (because proprietary vendors who link dynamically usually link against outdated libraries not likely to be present on modern systems).
The question of building from source versus binary package distribution is fairly unrelated to the question of dependencies - in either case if dependencies are not met the installation should notify the user and, according to the user's preferences, either automatically fetch and build or install the dependencies (apt, portage), ask the user what to do, or fail the installation with a descriptive indication of the problem, perhaps offering an explanation of how to eliminate the dependency if possible.
Again, to reiterate, distributing libraries with applications is not the proper solution. It bloats distributions, wastes bandwidth and disk space, causes conflicts among applications and libraries, generates mysterious and baffling interdependencies which should not exist among unrelated applications, and confuses users and administrators. In the best possible case, it requires each application to live in its own segregated world on the filesystem with custom startup scripts to ensure that the correct libraries are loaded. Even in this case, the benefits of dynamic linking (update your libraries without updating the applications using it) are discarded, and the additional startup scripts and distributed libraries require additional maintenance. This approach has been tried and has caused more problems than it solves.
My idea is that it should be built in to the OS in some way, so that if you type "./linuxrocks.mp3" at the console it would notice you're in console mode, and start an instance of mpg123 or whatever mp3 decoder you want to use and start playing it.
This problem is mostly solved, but perhaps it is something you could contribute to. check out "Misc Binaries" in the kernel docs.
I have to admit, it would be a little weird if every mp3 had to be executable in order to use it
CONFIG_BINFMT_MISC:
If you say Y here, it will be possible to plug wrapper-driven binary formats into the kernel. You will like this especially when you use programs that need an interpreter to run like Java, Python or Emacs-Lisp. It's also useful if you often run DOS executables under the Linux DOS emulator DOSEMU (read the DOSEMU-HOWTO, available from ). Once you have registered such a binary class with the kernel, you can start one of those programs simply by typing in its name at a shell prompt; Linux will automatically feed it to the correct interpreter.
You can do other nice things, too. Read the file Documentation/binfmt_misc.txt to learn how to use this feature, and Documentation/java.txt for information about how to include Java support.
Actually, the best way to implement this would be in the shell. Trying to put MIME types into the kernel would be a REALLY Bad Thing(TM).
Check out Misc Binaries in /usr/src/linux/Documents/binfmt_misc.txt (or wherever it lives on your box)
This Kernel feature allows you to invoke almost (for restrictions see below)every program by simply typing its name in the shell.This includes for example compiled Java(TM), Python or Emacs programs.
Although this mentions scripting languages, I don't see why mp3/etc couldn't be used. Additionally, it does not use mime types, but the more unixy strategy of magic bits
I think you are quite misinformed. Windows DLL hell happens because windows dynamic library layout is simplistic and unorganized.
In windows, say, you have dlls like MYDLL.DLL Microsoft usually keeps backwards compatibilty in DLLS between windows/upgrades/service pack versions, so new DLLs should work with older programs. Now, the problem is when you install a program that comes with an OLDER version of MYDLL.DLL, then programs that use the newer version will not work properly. To get around this, since win2000, microsoft includes a dir with a backup of every DLL, so if one gets replaced, it will throw back the "latest" version. The VBrun example wasnt very good, since that one has an implicit versioning scheme (something most other windows DLLs dont). You have to also remember that, very often, microsoft, instead of upgrading an api, they create a new one from scratch with another name but same functionality. And you have to _also_ remember, that the COM approach they use keeps them safe from incompatibility during api upgrades.
Oh, and you should __also__ remember, that many installers (including many ones by microsoft) simply check file date instead of version, remember the usual windows popup about conflicting dates which happen most of the time for libraries? "The file being copied is older than the one on the system, do you want to keep the old one?"
In unixes you simply have libmylib.so.majorversion for different versions, with a symlink to the minor versions, so having multiple , major versions of a library (usually when api changes happen) is possible, and it's also possible to have very specific minor versions of a library for a program. Also with this method, you can identify a library version 100% correctly, no symbols or messy stuff needed
So, all in all, using the "windows approach" of distributing the binary with the shared libs needed all together, and also checking library version by filename, does not mean falling into the "DLL hell".
And no, my views of opposite in the graph were about userfriendlyness vs messyness, not about static being the opposite of dynamic, so forgive me if i was unclear.
reduz
Read this:o ards.tx t
http://www.freedesktop.org/standards/clipb
GTK+ supports it since 1.2. QT supports it properly since 3.0. Mozilla supports it properly for as long as I can remember.
Yeah! And the next thing you know, America's economy suddenly turns upside down.
That would be helpful right about now
They don't want to be the authority for the kernel. They want to know what new features to add to the interface and the features.
I'm going to suggest they update the standard packaging system to the current version of RPM - the spec as it stands only recommends RPM version 3 as documented circa 1997, which is getting fairly long in the tooth now. The current edition is much more improved in terms of both security and reliability, and very few Linux distributiosn actually use the 3.0 edition.
In future, I'd also like to see the inclusion of one tool to to automatically fetch packages from a configurable list of sources with the dependencies matched in the LSB. I think its a reasonable thing to expect of most modern Linux distributions, which inevitabley include such a tool, but up2date, urpmi and apt-get all deal with Linux pakcages is slightly different ways, and standardization on these higher level tools would be useful.
Long term, I'd like to set a target date, at some point in the future (2004), where the LSB will plan to redefine RPM support as a genuine bona-fide implementation of RPM, not something which unpackages the installs into useless tarballs - yes, I mean alien. In the meantime, the few distributons that currently use such hacks to qualify as LSB compliant can update RPM with whatever improvements they're looking for.
something like autoconf
Just the thing for POSIX systems circa 1990.
Back in this century, Java and Dotnet have happened,
Or maybe Linux is about nostalgia?
So WHY are we not using Apple's "package"'s?
Or ".dsk" Images for that matter.
Seems like there's a lot of NIH running rampent in the community. Every OS has had to deal with software installation/deinstallation, yet the wheel gets reinvented almost every year.
Flip side of the coin. Were's the discipline in software packaging by developers? If one can do anything in packaging, then one will end up with the chaos that's Linux software packaging. How many different ways are there now?
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.
If nothing else, linux needs to have 1 degree of separation.
Yes, the source is important to open source. Unfortunately it's generally in C. This means that it's much less easy to modify than Java, C# or Python.
So unfortunately, thanks to the legacy technology inherent in KDE and Gnome, we've already lost this battle relative to MS and spurned the only platform that could have competed.
Today games, tomorrow Berlin!
Welcome to the land of the free...pay toll ahead...no photography...please open your bag...
I think it's time to include groups into group member lists - let's play trees. Well, with multiple group assignment it will be actually a DAG.
Let's use profiles with pre-assigned user parameters (and scripts) even on group level. Of course such parameters should be inherited (another question - overriden?) by users traversing their DAGs. At run-time or at new user constructor - it is up-to implementations. That's not difficult even with bash scipts and will be just singing with Python as a profile scripting language.
Filesystem permission should be assigned to roles in a way similar like today user-group-others. Of course, "user" becomes a role "owner", "group" goes for list of roles the user "belongs", "others" becomes a role "guess" or "anonymous".
Besides grouping users and their permissions, roles can be used to group user profile fragments. Again, user's profile inherits all environment variables and login scripts from all roles it belongs.
Of course the relationsip "belongs" (in its own turn either "part-of" or "sort-of") is not the only type of relationships between nodes. But different applications (like FS driver above or login script) may use (interpretate) different types of relationships with different type of inheritance inference.
We don't live without networks, remember? RBAC DAG should be distrbuted. User profiles should roamed. Domains (aka NT domains) should be nested.
bla-bla-bla. We all were reading about RBAC at some time. Now it might be time to discuss how make the system where security level is a subject of configuration. You want a simple home desktop - most of such RBAC configuration goes as default. You need a regular corporate desktop - choose the configuration type "aka NT domain" on the server and workstation. You are required to install a box with C2 level of security - you need RBAC (at least) for it.
back to "Linux TNG" subject. There are lots of theoretical research done. There is (are) some stand with reference implementation form NIST. There is SE-Linux project (still alive?) from NSA. there is no Linux standard for RBAC.
That should be something like LSB, defining default user roles, their default profiles and permissions. Such standard will help to accelerate Linux RBAC implementation in the kernel, encourage Linux application developers to design keeping Linux RBAC in mind and assure corporate decision makers that Linux is targeting corporate networks seriously.
Less is more !
AShadeOfGrey talks about RMS: Like it or not... it isn't hard to argue that rms is the single most important person in the developments that brought each and every one of us the choice of Freedom. Worship him? Make him god? no.. but don't forget... the man deserves a tiny bit of credit here...
I wont deny the man credit, but he really thinks he must be worshipped
No sig for the moment.
How about some sort of XML based configuration file standard? The way I see it is a specific directory with xml config files for everything on the system. The directory will have cvs or some other system that will let you roll back to a previous version of the config in case you break something while making a change.
To support legacy applications that have not caught up with the new system, you could have a program that transforms the XML file back into the original config file via XSLT or whatever, or am I just dreaming
Disclaimer: This could all be crap, I'm not a programmer :-)
there needs to be a standard for /etc and (imho) all apps should store local user data in ~/.etc/appname/config.xml (why the dir? so things like mozilla can keep their cache someplace)
Secondly, everything should be moved over to XML rather than random configuration format for everything.
Imagine... Apache using an XML configuration file?
8-O
You nimrod!
Get your acronyms straight.
Linux should make a technological quantum leap in software terms and jump ahead of Windows or any other operating system.
This is only viable through open source; big companies like Microsoft are slower in adopting new ideas.
Linux should become totally object-oriented and componentized.
The word "application" must be forgotten. At best case, an "application" should be a banch of components working together to achieve some functionality.
The word "filesystem" should also be forgotten. It should be replaced with a hierarchy of persistent(== memory mapped) objects, where each object maps to a system component. Components of the tree could be in the same process, in different processes in the same machine, in the same local network but in different computers, or across the globe.
This essentially new Linux should be responsible for real-time component linking and for security. All the rest would be handled by components. The kernel itself would be a component, too. Each component would be of specific class; class metadata would be kept by the O/S and be available to any other component in hand.
That means essentially to drop Unix. Unix is old, and although it does the job, it is inadequate at the end and the cost of it does not help economy at all. One good thing about Unix though is the capability of chaining small programs together to do the job at hand. This philosophy is very good and what I am proposing here is essentially the same thing but in a fully object-oriented context.
In another topic, some guy is asking slashdot about a better application for managing his mp3 collection. If the system was fully object-oriented, the only program that would be needed was a browser that reads the mp3 component properties and API and present a user interface according to those properties, much like how it is done in GUI IDEs.
As for static linking all apps to avoid dependencies, as it has been proposed by some other guy, it is a backward quantum leap! there is a simple solution: versioning.
There would be no conflict in modern operating systems if dependencies were resolved not only by name but by version also. For example, if a program wants to use the library 'Foo', it should make clear which foo is using: 'Foo 1.1', or the new 'Foo 1.2' that breaks compatibility ?
In the above mentioned system, a class would be versioned. Therefore, the problem of dependencies would be avoided, and classes with the same name but with different version would be installed in the system as long as they are used by some other component.
That's why you use it, 'cause you stink, you russian hippo! Slow down communist cowboy! Stalin will send you to siperia!
The Macintosh interface was designed before we had a lot of experience with graphic user interfaces and knew how people try to interact with the computer. The MS-Windows GUI followed Macintosh close enough to get sued. Apple took a big leap with the Lisa and the first Macintosh. Now a couple of decades have gone by and a lot has been learned. OS X did not take the plunge, but GNU/Linux could.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
Modularity is what makes this great. Being able to use any shell, or any WM, or any text editor...that is what makes this free software stuff so beautiful - you can run a great system that you have tweaked exactly how you like it. and so can I. and while I can run the same apps you do, my setup is Icewm with minimal graphics and very few "extra" applications running, and you'rs is KDE with every little graphical doohicky cranked up. I just think that modularity is beautiful.
Remember the industrial era? it was workable because each widget 5A was made exactly like every other widget 5A. you could assembly-line, you could swap out one part for another, and the final product worked the same. Maybe this is an idiotic illustration. But I think lots of little peices making up one great big OS is just nifty. that's all.
Who is this Anonymous Coward character, how does he post so much, and why is he always such a whore?
UTF-8 is a brilliant solution to adding Unicode support to existing systems. In fact it may be close to the best support possible for Unicode, even if you ignore back compatablity, since it builds in a crude Huffman-style compression and allows many useful functions like searches to be done with much smaller lookup tables (ie 256 entries), it encodes 32-bit unicode with no weird hacks (ie no "combining characters" that they had to add to UTF-16), and in fact can be extended in obvious ways to encode objects larger than 32 bits if they become necessary.
I strongly encourage the LSB to insist that ALL interfaces be UTF-8. This means that all "wide character" interfaces and all interfaces that require an "encoding", to be specified be depreciated and eliminated ASAP. It also means that all current byte interfaces be made 8-bit clean and redefined as taking UTF-8 (ie I also propose that Ascii interfaces be removed as well, but the names of them reused as UTF-8).
The original poster may have been confusing UTF-8 with ascii or ISO8859-1, too. Just for the record UTF-8 is able to record all Unicode characters up to 31 bits (the 32 bit is somewhat undecided but I recommend that if needed the encoding be extended to record infinitly-long tokens, rather than using the remaining bit as the 32).
I know some people have mentioned this already, but I'll try to go a bit more in depth with it.
Linux really needs standard configuration files more than anything. I'd prefer something XML-based, as it could be adapted to the need of just about any application. This would also allow GUI config programs to be used without screwing up existing configuration files, and they could even automatically be used to configure new applications based on the specification XML file that would be present for each app.
Also, global configuration files would be nice. Especially options such as proxies, font settings, compiler options, etc. would be much nicer if they could be changed from one place, instead of for every application individually.
On slashdot, as in Real Life, worry less about what someone says, and more about what they actually do.
In other words: the people on slashdot don't have to get under your skin. If, tomorrow, Linus/Alan/major Linux person/LSB says that cutn&paste has to be implemented some way, as standard, then is the time to let it worry you if you don't like it.
Slashdot is almost entirely talk. Read through it to find the content, the wisdom, the knowledge. But don't let it offend you...if you can help it.
Sometimes its fun to flamewar though... : )
Who is this Anonymous Coward character, how does he post so much, and why is he always such a whore?
cd /se<tab>
get over it
- I don't need to go outside, my CRT tan'll do me just fine.
Your original argument was that the Linux desktops are not written in a recent language; Therefore they are behind MSWindows desktops. Since you agree that this is also the case for MSWindows, there is a disconnect.
... At this point I peter out on the issue and stop caring.
If you're wishing to argue that MS's new dotnet architecture will be superior to existing technologies, then dotnet vs. existing architectures stands across desktops and applies to MSWindows, Gnome, and KDE similarly.
You can write programs for all of these environments in many languages. The language that the environment is written in is not required.
If you're comparing C# to equivalent efforts in the OSS comunity, then you will want to explore Python, Ruby and the like. Again, you can write aplications using all of these on all of the above platforms (with C# support on UNIX a bit lagging.)
The reason for the "troll" modification was the leap from language war to platform war
This is not a political statement. This is not legal advice. It's a frick'n Slasdot post. However: I'm Running For
One thing Microsoft has done (and it took them several tries and years to figure this one out) is to provide one (relatively) consistant user interface. This all started back with Win95 and Win98 and they carried it into NT 4. Why? So some grey haired, sneaker wearing grandma (think: mom) can surf the web (remember the MSN network??? Microsoft's own version of the www that never took off...) and use an office suite. (Latest stats seem to indicate most users only use Outlook and Word...) This allowed "everyone" to work on a PC at work... because they could do the same thing at home. This allowed for thousands of hours of "free" training is using Microsoft for business because so many people were using it at home. For Linux to beat M$ at this, a simple and limited distibution is needed to allow these above mentioned users to switch over to Linux. Please remember, many people out there have little to no interest in learning "how to use a computer" they just want to sit down, read email, send pic's of the grandkids, chat with some friends, and plan the next trip to see the family. Most people could not care less about how it happens (on/in the computer) just that it does happen. Lindows may do it. Tis a good sign Walmart is selling blank PC's... and supposedly Dell is too! * * the Dell's come with DR-DOS or something similar installed I believe. -- any errors in the above mentioned are solely the fault of the author (me).
Albert Einstein, when asked to describe radio, replied: "You see, wire
telegraph is a kind of a very, very long cat. You pull his tail in New
York and his head is meowing in Los Angeles. Do you understand this?
And radio operates exactly the same way: you send signals here, they
receive them there. The only difference is that there is no cat."
- this post brought to you by the Automated Last Post Generator...