Deciding On The Future of Linux 359
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? "
This discussion has been archived.
No new comments can be posted.
Deciding On The Future of Linux
Related Links Top of the: day, week, month.
In the future, you're going to get computers as prizes in breakfast cereals. You'll throw them out because your house will be littered with them.
Looks like we need a poll (Score:2, Interesting)
Re:Looks like we need a poll (Score:2)
Re:Looks like we need a poll (Score:2)
Other than that, I agree with you.
Re:Looks like we need a poll (Score:2, Insightful)
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 [freedesktop.org] has the right idea.Standard for new hacks (Score:2)
Drivers... (Score:5, Interesting)
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
Re:Drivers... (Score:3, Informative)
Lots of apps work with the M515!
pilot-link, and jpilot and kpilot which work with these sync fine!
Coldsync works fine as well, although can only be used to backup your palm.
If you want to recompile some stuff then Evolution plus Gnome-pilot is awesome! Far more functionality then the Palm desktop!
Cheers
Ferg
Re:Drivers... (Score:3, Interesting)
I'm surprised someone hasn't created a driver abstraction layer that enables the same driver code to work on Windows, Linux 2.4, and older Linux kernels. New Linux drivers often get backported, but each driver developer must do the same type of backporting work. Why not consolidate all the backporting into a single, shared (and debugged) driver abstraction layer?
Re:Drivers... (Score:3, Interesting)
Re:Drivers... (Score:2)
Wrong, the "other problem" is how on earth it would help us get companies to port to linux. If you want a Windows compatible environment, I've heard MS Windows is available.
This is a corrigendum (Score:5, Insightful)
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.
Re:This is a corrigendum (Score:5, Insightful)
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. THere is a very large development community that does not do kernel programming that cares a lot about these issues, although many certainly don't care what the FSF's views on this are.
By the way, GNU has had a huge impact on the useability of linux even if they don't have the impact they would have hoped on the kernel. I don't like some of the arrogance coming out of Stallman's office either, but the GNU folks to deserve a lot of credit.
Re:This is a corrigendum (Score:2)
How dare RedHat or SuSE or IBM try to tell Linus what to do!
Re:This is a corrigendum (Score:3, Informative)
With regards to the kernel itself Linus is the monkey at the top of the pole, everywhere else he's just a normal monkey with a Finnish accent. He has no control over the direction of any of the GNU tools and the FSF doesn't have control over the kernel. At the system level where the twain meet the FSF has as much say asanyone else. They are the ones maintaining the tools every other Linux developer is using.
Re:This is a corrigendum (Score:4, Insightful)
That's fine. It would have no effect on the current GPL'd toolsets we are using now. They can't revoke the license.
Re:This is a corrigendum (Score:3, Insightful)
So if the very people who invented the GPL decide to do the complete and utter opposite of what they're whole organisation is base on ?
Then why on earth did they invent the GPL ? Why didn't RMS pursue what would have been an extremely lucrative career for someone of his skills ? Why did he spend many years of his life promoting the cause of free software ?
And why does the GPL say "If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software
Foundation." (emphasis mine) ?
And by the way, the FSF consider "Open Source" to be something slightly different to what they produce (for what it's worth).
Re:This is a corrigendum (Score:3, Informative)
Do you mean that Alan Cox didn't really say that or...?
I had to look up corrigendum [m-w.com], too. Don't really see how it applies, though.
/ in "GNU/Linux" as in "TCP/IP" (Score:4, Insightful)
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 [gnu.org], 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.
Re:This is a corrigendum (Score:4, Funny)
Linus has pronounced that from now on, in all comments, the adjective must follow the noun, like so:
- Linux GNU
- Car red
- Child small
- Parent poster silly
Please immediately start following this method new of modifying nouns when speaking English. Don't let your megalomania be the demise of you. All programmers Source Open must like Yoda be.pardon me (Score:2)
that should be "like call wackybrit a troll and a jackass." Ah yes, the more I do it the better I feel.
Excuse me? (Score:5, Funny)
Re:Excuse me? (Score:3, Funny)
I'd say asking is valid.
At least we'll actually get a say. I hate M$'s rhetorical catch phrase. "Where do you want to go today?"
-=fshalor
Universal Copy/Cut&Paste (Score:5, Insightful)
Re:Universal Copy/Cut&Paste (Score:2, Informative)
If you're more inclined to use the ctrl-c ctrl-v methodoly, both gnome and kde have this functionality throughout their apps.
Re:Universal Copy/Cut&Paste (Score:2)
Re:Universal Copy/Cut&Paste (Score:2, Interesting)
Yeah, but it's not consistant. Users should not need to know which GUI toolkit their app was coded in. There are also consistancy problems, some apps try to implement their own way of doing the clipboard, and it's entirely possible to have something on the "clipboard" (for lack of a better word) that is different depending on where you paste.
And then there is the issue of doing on-the-fly text replacements. As far as I know, there is no way to copy some text, highlight other text, and paste, replacing the other text with the text you copied. This sounds like something that doesn't come up much, but it really does.
Suppose I want to copy a URL and open it in a browser window that already has a URL in the Address box. In Windows, one would just double click the old URL to highlight it, then paste the new one which deletes the old one. Another way would be to double click the old URL to highlight it, then hit backspace to delete it, then paste the new one, but you can't do that, because that copies the old URL.
So... I usually just resort to opening a fresh browser window, or clicking at the end of the old URL and holding down backspace. Maybe I am just an idiot, but this seems stupid.
I'm not saying cut/copy/paste should act exactly like windows, but it should at least be consistant, which it really isn't. I've adjusted to using X and various apps now, so I don't notice it as much anymore, but when I first switched from Windows, it was one of the most frustrating things I had to deal with.
Re:Universal Copy/Cut&Paste (Score:2)
Also any text entry widget in x lets you ctr-u to blank it. so you can select text, click field, ctrl-u, then ctrl-v or middle click.
But for fields that commonly nead to be rentered with text the x button is sweet.
Re:Universal Copy/Cut&Paste (Score:4, Insightful)
Look, if we build it exactly like Windows we piss off old school Unix users and the Mac users, all of whom think their way is the Right Way. And then all of them chime in unison, "the community just lacks creativity, they just copied Windows!"
"you will do it on my terms, not yours"
Whatever makes you happy. Look, if you buy a Mac, you wouldn't expect it to work like Windows. If you purchase OS2, you wouldn't expect it to work like Windows. But if you install Linux here you are complaining it doesn't work like Windows.
If you change platforms, expect to learn something new. Sure, when I first switched years ago, I was confused by the clipboards -- but I learned. I wasn't being egotisical earlier. I was speaking the truth: just because Linux isn't Windows doesn't mean Linux is wrong.
And you know what? Windows aggrevates me because it doesn't work like Linux.
Re:Universal Copy/Cut&Paste (Score:3, Insightful)
I think you've highlighted a big misconception when people first start looking at linux, namely, that it is a product that is directly competing with windows and needs to copy it feature for feature to be "sold" to people like you. This is not helped by products like Lindows, that are obviously trying to do just that and turn linux into a poor-man's copy of Windows.
But when people ask me why I use linux, and why should they use it, I simply tell them "Linux is different". I explain that things do not work the same as in windows, any more than you would expect MacOS to work the same as Windows. I explain that there is a lack of decent software in some areas, and that the software I use - while faster and easier in the long run - has a steep learning curve and is very frustrating and difficult to master. I further explain that one of the reasons I love linux is the ease with which you can programme in it, which probably won't appeal to them. And also that the other main reason I use it is the ease of customising everything to look and work the way you want it to - a process that requires editing configuration files and making graphics and writing scripts and generally getting your hands dirty. (I also try explaining the whole GPL philosophy and the wonderful feeling that anyone can contribute to code and make a difference, however small, but that usually flies right over their heads)
In short, I tell them to by all means try linux - it's free, after all - but that they will probably be better off with Windows. Indeed, I doubt that Linux will ever become an mainstream OS, unless somebody releases a version that dumbs it down considerably. It simply allows the user too much power to destroy their system - and for most people that's a very frightening thing.
So no, I don't wish to sell linux to you, and by the sounds of it you wouldn't appreciate it anyway if I did. It is an OS that appeals to some because they are free to hack/customise/modify/programme as they want ... but this comes at a price, in that not everything will work exactly as it does in Windows. As far as I'm concerned, I'm happy with the advantages of linux and the disadvantages don't bother me. Obviously this doesn't apply to you, so you have two options: Don't use linux and stick with Windows (and why not, if it does everything you want and you're happy with it? there's nothing smart about changing OS simply for the sake of it!), or, if you really like linux and just hate a few things like copy and paste, see what you can do to change this!! Only don't expect anyone to change a system they like simply so that they can "sell" it to you "on your terms" ... rather, point out that having these added features would make everyone's life easier.
Re:Universal Copy/Cut&Paste (Score:3, Informative)
That's if one if working from a console interface. I can't help but suspect that the original poster was thinking of the nonstandardization of cut-&-paste with GUI apps . . . which is an X issue.
Good feature request, wrong team to fix it: & the philosophy of the folks developing X is not to dictate one binding solution for all. I'd say the best solution woudl be for apps to be written so that they can submit to what the window manager dictates -- not the toolkit or widget set. (ISTR that the biggest differences in how cut and paste work lie in this area.)
But systematically rewriting all of these applications -- Gnumeric, Mozilla, jpilot, etc. -- would require a lot of work.
Geoff
Re:Universal Copy/Cut&Paste (Score:2)
Re:Universal Copy/Cut&Paste (Score:2)
There already is good "cut and paste" support... its called "gpm". Works like a charm... highlight a piece of text, then go somewhere else and simply click the middle mouse button to paste. Its quicker than ctrl-c ctrl-v because no keystrokes are involved.
Oh you got to be kidding me. I use both Windows and Linux/KDE on a daily basis and I hate the cut and paste support in X. No, I don't want to paste at the mouse cursor; I want to paste at the text cursor. Even for console windows, I still get frustrated by the fact that the mouse has to be over the window.
For KDE apps, the cut and paste functionality is very inconsistent. No, I don't want double-clicking a word to copy it to the clipboard; half the time I'm selecting the word so I can overwrite it with whatever was in the clipboard before. Luckily, some apps let me turn this 'feature' off. Also, I hate the fact that when I close the app, the data in the clipboard is lost.
Take your blinders off. The OP was right. Cut and paste is the worst thing about Linux today.
-a
Re:Universal Copy/Cut&Paste (Score:2)
Re:Universal Copy/Cut&Paste (Score:2)
-A
There already IS a universal Cut/Copy/Paste (Score:4, Informative)
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.
Where should they go next? (Score:4, Funny)
Linux Standard Base? (Score:4, Funny)
if you really want to help (Score:2, Informative)
Click on the final link in the description and leave your feedback there or if you plan to leave it on
dependency-hell (Score:2)
Plus these semi-redundant libraries can also eat up disk-space and download time.
Re:dependency-hell (Score:2, Informative)
Re:dependency-hell (Score:2, Insightful)
Where do all the apps go... (Score:2, Insightful)
Hmm... perhaps
Re:dependency-hell (Score:2)
And this gets modded as Insightful?
Dear God, this is a disappointment.
RPM dumps your apps wherever the person who made the RPM file told it to put them. Try running "rpm -ql
Secondly, why is it better to have all the apps in
There may well be some merit towards splitting entries in
Maybe we want to break everything down into a series of individual packages. Hang on, that sounds a bit like RPM.....
Learn about how to use RPM. Read up on the "-ql" and "-qf" options. Then if you want to complain about it, complain about some of the things it doesn't do well, or at all (many of which it wasn't really designed to do).
Re:dependency-hell (Score:2)
Allow me to quote the Linux Standard Base Specification 1.2, Chapter 18, File System Hierarchy (The Filesystem Hierarchy Standard, Version 2.2, Section 3.12.1) "/opt is reserved for the installation of add-on application software packages." [emphasis added]
Also "No other package files may exist outside the
Re:dependency-hell (Score:2)
The application non-uniformness in Linux and X is something that keeps getting on my nerves. Why in holy hell can't the guys from GTK+ and Qt join together and use the same widgets but with two different ways of accessing them? This is done by VCL and MFC created by Borland and Microsoft. Two radically different class libraries, one common interface.
Re:dependency-hell (Score:2)
Non-uniformness annoys you? Why do you then want to break ages-old conventions like naming directories /etc and /opt, like about every other Unix-like system does?
Apple is the one using a non-standard scheme here. It doesn't matter for them too much, I guess, because they didn't expect the typical Mac user to have experience with other Unices, but that assumption isn't valid for Linux. The linuxisms introduced by sloppy coders (just search for '#!/bin/bash' in your favourite packages) are already enough of a PITA for people who happen to use a Unix-like operating system that is less hyped. If they would now come up with some oddball directory naming scheme, it would not do nothing but harm for anyone -- users who can't remember that config files live in /etc should in most cases not have to fiddle with them anyway - just give them a hard-to-misuse GUI or, better, a competent admin.
--valid naming (Score:5, Insightful)
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
Re:valid naming (Score:2)
Yes, and unnecessary.
Anyone with the knowledge to be messing around with those directories (other than via some pointy-clicky GUI) will have no problem remembering their names. There's only a half-dozen of them, for pete's sake.
If you don't like the names, create pointy-clicky GUIs. They're wonderful for things like adjusting settings, and they don't care what the directory name is.
Re:valid naming (Score:2)
I don't claim that /etc is a brilliant design choice. I wouldn't call it that if I were to design a new system from scratch. But I'm not, and neither is LSB. The problem is existing software that depends on /etc being called /etc (and be it by a default setting in config.h).
Your symlink proposal doesn't cut, IMHO. If LSB (that's what we are talking about, right?) would decide to recommend symlinking /etc to /settings or vice versa, users might become used to /settings over time. However, clever software developers would not, because, frankly, most Unix vendors are not that interested in the findings of the Linux standards base, so /etc would still be what works everywhere. And an updated POSIX standard seems unlikely, so you would have to live with this dualism virtually forever.
I think it was the Unix haters handbook where I read an insightful article that argued that the naming conventions in Unix and C evolved with K&Rs ability to touch-type - it all started with "int" and "ls", later stuff like "locate" and "register" appeared... ;-)
Re:dependency-hell (Score:2)
Give me *one* good reason why all application should behave different from each other.
Re:dependency-hell (Score:2, Funny)
Which as any 1337 *nix head will immediately guess, stands for "Apf is similar to Program Files"!
Re:dependency-hell (Score:2)
A standardized, distribution neutral package format combined with a huge, tested repository of free software would be a huge gain.
Re:dependency-hell (Score:2)
Standardizing on a Linux package format and library versions/locations/whatever would only be half the deal - you still wouldn't be able to release one binary that magically works on Linux/i386, Linux/Alpha, Linux/Sparc, Solaris/Sparc, Irix/Mips, NetBSD/Wristwatch etc. Yet, if you know a bit about Unix programming, chances are that your source code would compile and run just fine there. Think lots of potential customers!
What the world needs isn't something like a "standardized Linux package format", but something like autoconf that happens to be more of an actual solution and less of a problem on it's own. Portability rocks. Both for users and developers.
(BTW: That's one point of Open Source/Free Software/Whatever that is too often overlooked: Getting your programs as source code, regardless of the license, is friggin convenient! Binaries are inflexible - it might seem easier at first, but you run into the limitations really, really fast.
Re:dependency-hell (Score:2, Informative)
Psst... use Mandrake + urpmi. It's really easy:
urpmi some-package-with-lots-of-deps-oh-no-Ill-have-to-Oh, wait - it's figured out the deps for me, and automagically installed them in the right place. Just like apt-get - huh!
Re:debian & gentoo are not the answers (Score:2)
You really think that libc6 dependancy is there 'just because'? Or that all those apps depending on libssl don't really use it?
Get a clue.
Re:debian & gentoo are not the answers (Score:5, Funny)
God-fucking-dammit, isn't it about time we had magical depenencies? Where the computer uses it's psychic abilities to create this depenency code on the fly, pulling it out of its ass or something? It's ridiculous, when you think about it. Who ever in their right mind has ever walked up to you and said "you know, to run Word, you need windows and a fuckload of DLLs already loaded and running!" It just doesn't happen, my friends. Why, because Windows already has Micro$oft Magical Library Generator XP, which creates them on the fly. And sure, if sometimes it is just random code that locks the CPU, isn't it worth it?
Damn, sarcastic mode is exhausting. BTW, mgkmsal2, you're one of the biggest slashtards I've ever seen here. Ever play with windows, and have it go spastic, wanting to know which version of the DLL you'll keep? Every operating system has this problem. If you don't like it, don't install software. Wanting your cake and eating it too, makes for really lame whining...
Yes, static linking is the answer (Score:4, Insightful)
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.
Re: It's not the answer, its the extreme opposite. (Score:2, Insightful)
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
Re: It's not the answer, its the extreme opposite. (Score:2)
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.
Re:debian & gentoo are not the answers (Score:2)
You're kidding right? The genius of *nix is the ability for one program to use another rather than re-inventing the wheel. You will have far fewer bugs if program X relies on program Y to do what program U does best (assuming that program Y publishes it's interface methods and sticks to them).
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.
There is a big difference here. If MS had one program for grabbing data from a web server, and that program could be used by others (including IE which would then render html) there would be *much* fewer bugs and security concersn in MS code. Rather what they do is expect IE to do *all* of it *and* expect other programs to use it for *any* aspect of internet access Case in point - why does my Counter Strike install on Linux (using winex) generate an IE error? That's insane...
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.
Oh sure - take a 10Gb desktop linux install and make it 20 or 30GB? No thanks. If you hate rpm dependancy hell, then use debian or gentoo (or come up with a more reasonable fix). But bundling libraries with each package is insane for the following reasons:
It's unfair to expect Programmer of X to also fix bugs in Library Y - it's programmer of Y's responsibility. This is A Good Thing tm - It allows Programmer X to focus on program X, and Programmer Y to focus on library Y Breaking code (and programs) into little, significant sections, has been a halmark of programming (and unix) for decades...
The other reason is this: If you do it your way - you end up with maybe 5 versions of library Y. You thoght it was hard to keep up with bug fixes before?
helper program calling (Score:4, Interesting)
Re:helper program calling (Score:2, Interesting)
$ cd
$ ls -l mime*
-rw-r--r-- 1 root root 7559 Feb 27 2002 gnome-vfs-mime-magic
-rw-r--r-- 1 root root 36823 Apr 15 17:47 mime-magic
-rw-r--r-- 1 root root 99960 Apr 15 17:47 mime-magic.dat
-rw-r--r-- 1 root root 12758 Jul 21 20:10 mime.types
and none of these files say what the helper apps is.
Isn't that a GNOME/KDE thing? (Score:2)
Re:helper program calling (Score:2)
Re:helper program calling (Score:2)
Re:Security Through Obscurity (Score:2)
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
Misc Binaries ; was: Re:helper program calling (Score:2)
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.
Linux or RiscOS or OS/2 or... (Score:2, Interesting)
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!
Re:Linux or RiscOS or OS/2 or... (Score:2)
Written in assembly hunh? I'm sure that aids portability doesn't it? I was under the impression that compilers were pretty good nowadays.
Where to go next. (Score:2, Funny)
UTF-16 support (Score:2, Informative)
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.]
some suggestions.... (Score:4, Insightful)
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....
Go for 3D interfaces (Score:3, Insightful)
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...
Re:Go for 3D interfaces (Score:3, Funny)
Linux is not the windowing system, whether your choice is X or one of the alternatives to it.
What now? (Score:2, Insightful)
1. To this effect, I believe a coherent, stable and easy as far as development is concerned, Multimedia API has to be developed. To put it bluntly, no widely used/standardised API, no Linux Desktop.
2. Fonts. You know what hits Windows users when they first look at a Linux desktop? Its ugliness. The fonts are excruciatingly ugly. Only half solutions exist (see RH Xfs), to my knowledge, exist so far.
3. A registry. Yes I know you people hate it. I know a million things can go wrong. But without it you don't have an OS. And again, storing an
The next time you use some other window manager, you have different settings. Solution? Make a bloody registry, that understands security in a multiuser environment.
4. Limit choice. We whine that closed source takes choice away. We have no say. Well guess what. Too much choice has exactly the same effect. If you don't see that, you are blind.
Sure, flame me all you want, but unless there's 5 of everything (no, make that 3), Linux is going to stay exactly what it is today.
A geek friendly OS that tries to be Joe Bloggs friendly. We wish our mothers could use the thing and say "Wow, that's nice and easy", but it's not going to happen as long as we have a million window managers/desktops, browsers, multimedia apps, etc. and at the same time we can't play a DVD as any other common user of another OS can. Same goes for CD burning.
You might not think these issues are important. You might think that the GPL is the Holy Book. You might think that what's the most important thing is to write cool, clean, fast, phat code.
Well, nobody really cares, at least to the extent you'd like them to do.
Re:What now? (Score:5, Insightful)
While this seems to be an uninformed troll, I'll bite anyway :)
1. To this effect, I believe a coherent, stable and easy as far as development is concerned, Multimedia API has to be developed. To put it bluntly, no widely used/standardised API, no Linux Desktop.
There is one--it's called SDL
2. Fonts. You know what hits Windows users when they first look at a Linux desktop? Its ugliness. The fonts are excruciatingly ugly. Only half solutions exist (see RH Xfs), to my knowledge, exist so far.
All you need to do is to install some pretty fonts and you're good to go. The reason for all the nasty looking fonts is that higher quality fonts are difficult to make and often have licensing fees. Xfs is not a "red hat" solution, but is built into X. As soon as more apps support freetype, we'll be seeing prettier antialiased apps.
3. A registry. Yes I know you people hate it. I know a million things can go wrong. But without it you don't have an OS. And again, storing an .app_rc in ~/home or making the window manager keep track of associations is stupid.
The next time you use some other window manager, you have different settings. Solution? Make a bloody registry, that understands security in a multiuser environment.
What do you mean that you don't have the OS without the registry? Everything is stored in the user's directory for user settings and everything for the system is stored in one of the /etc directories. You can switch between fifty window managers and the apps will all remember the individual settings. The idea of making a central registry so that all the window managers can keep track of the individual apps is silly. There are many more things that can go wrong and you don't want to compromise your system by having a central registry.
4. Limit choice. We whine that closed source takes choice away. We have no say. Well guess what. Too much choice has exactly the same effect. If you don't see that, you are blind. Sure, flame me all you want, but unless there's 5 of everything (no, make that 3), Linux is going to stay exactly what it is today.
You miss the point. When there is choice, then you can pick which window manager you want to use and how you want to use it. The average windows -> linux user will likely choose a similar environment in which they have used before and will probably use KDE or GNOME. The more advanced user will probably pick something a bit more efficient.
These aren't even issues at all--it seems to me that this is more an uninformed whine about how linux distos don't seem to be the same as windows.
Not an interface (Score:2)
Not an interface means not the responsibility of the LSB. Fonts are an important thing, but not for the LSB.
Personally I would like to click and choose different resolutions and color depths instead of ctrlalt+/ctrlalt-, but once again, no program should maintain "800x600x16" mode in its codebase except for the actual underlying GUI layer (eg. XFree86). It's an implementation detail, not an interface detail. Important, but not to the LSB.
Go help out at the XFree86 project. They're the ones who would be dealing with this stuff.
Re:What now? (Score:2)
GNOME also has GConf which is a registry for preferences for GNOME applications. This also avoids a lot of the problems with the Windows registry. It also adds some interesting features such as key change notification - in the comp sci labs here if you log in to two machines at once and change a preference (eg. the desktop background) the change automatically propagates via CORBA instantly to all the machines you're logged on to.
People probably need to get over their hangups on registries. Yep, the Windows registry sucks, it doesnt mean we cant make something better. I'd love it if adoption of GConf became more widespread.
Re:What now? (Score:2)
While I do agree w/what you are trying to get at, "limiting choice" is not the way to do it.
RH is getting the right idea by coming up w/an enviornment that is the same across several platforms.
I still want to be able to throw out GNOME/KDE and put on Enlightenment. I am comfortable with what I have been using for several years and I am not about to change just b/c Linux needs to move more onto the desktop.
Re:What now? (Score:2)
The registery, though, makes no sense. There is no registery, no one is writing a registery, and very few people want a registery. This is not the place for a standards body. Standards bodies codify and make explicit existing practice, they should not impose a new practice.
Re:What now? (Score:2)
Multimedia API has to be developed
One API to rule them all..then what differentiates Linux from Windows? No, the solution here is to bring all the desktop parties together to pool their resources and create one desktop, infinitely extensible. Right now, the fractionization of the desktop community into KDE camps, GNOME camps, etc. prevents true innovation as each camp fights for their own "stand."
A registry. Yes I know you people hate it. I know a million things can go wrong. But without it you don't have an OS.
A non sequitur of the highest degree. *nix is about stability, robustness, and configurability. You advocate introducing a mechanism which, by your own admission, is failure-prone in many aspects.
Limit choice. We whine that closed source takes choice away. We have no say. Well guess what. Too much choice has exactly the same effect.
No, it will not. You want to know where Microsoft went wrong? It wasn't their attempt to standardize the UI, the so-called "one-size-fits-all" approach. No, they went wrong by trying to force the one-size approach upon the world, whether or not they wanted it. Catering to the lowest common denominator is a wise marketing move, but extremely insulting to those who don't consider themselves in the LCD. Limiting choice would be a nail (no, several nails) in the Linux coffin.
In fact, now that I think of it, I think the author of the parent post forgot a markup tag on his post:
<sarcasm>
In which case, I've been hooked, along with every other moderator who voted this post up as anything other than "Funny."
Re:What now? (Score:3, Interesting)
-------
I totally agree with you about configuration. The Windows registry is not a worthwhile construct to emulate. That said, a lot more consistency in config file formats would be nice. (Oops! This one is tab-delimited. Oops! This one is key/value pairs separated by an equals sign but spaces are only data-significant on the right side of the pair. Oops! This one uses spaces for the key/value pair delimiter. Oops! This one uses parentheses for hierarchy. etc.)
-------
As far as Microsoft is concerned, I have to disagree as well. Note that I'm writing this post on RedHat 7.3 on a laptop with Mozilla 1.2a. There are no end of applications that don't use MFC or some other Microsoft GUI toolkit. Most Windows applications use the MS APIs because they're easier, faster, or more powerful a lot of the time for whatever reason. People reuse the IE browser rendering component in their apps because it's easier and faster than writing their own renderer.
Don't get me wrong. I'm no great fan of Microsoft and many of their APIs, implementations, or business practices. But by having a standard implementation, for better or for worse, a lot of people gave up on reinventing the wheel and simply got their program done. This has shown up in security problems on Windows. It has also manifested itself as a robust and very efficient XML parser and browser component that many people used for years before libxml, libxslt, xerces, xalan, Mozilla, Opera, and Konquerer started getting embedded.
Criticize Microsoft all you want. I'll join you. But don't ignore their occasional good ideas or you'll be throwing the baby out with the bathwater for the sake of blind hatred.
Config File Formats (Score:2, Interesting)
Re:Config File Formats (Score:2)
Re:What now? (Score:2)
2. Yes, fonts generally suck, but there are solutions out there. This is a distribution issue though. Font choice and text display are already handled by the OS and supporting libraries. How those fonts are displayed should not have anything to do with the front-end application. Otherwise you have twenty thousand implementations for font rendering. There's no interface that needs defining here; there's only implementation. LSB doesn't apply.
3. A registry is simply one implementation of the concept. The Windows registry is already obsolete (by ActiveDirectory...err...LDAP...). NDS would be better than the Windows registry. Standardizing on LDAP would be better for uniform local and network resource configuration and user authentication. However, keeping configuration files as text in
As for configuration in ~/.app_rc, same story as above. It doesn't make LDAP export an impossibility and 90% of the problems would go away with some configuration file consistency.
4. Choice is configuration format is a lost cause. If all of your creative energies are focused on making a new configuration file format, there are worse problems in store for Linux in the future than ease of use. Configuration files should be consistent. Period. People shoud find some other way to demonstrate their individuality. It's like bridgemakers making driving lanes in whatever width they like, car makers making cars of whatever width they like, and no one is talking to each other. Sure you've got individuality, but your car can only travel on some of the bridges.
I want cool, clean, fast code (I don't know about making it Pretty, Hot, and Tempting -- I prefer a girlfriend for that). The coolest configuration file format is the one I don't have to invent for the thousandth time. The cleanest config file format is the one that everyone else uses. The fastest config file format is the one where the parser's already written and heavily optimized by people who really care about file parsing. The problem isn't that people care too much. Currently not enough people do care enough about the config file format, and some of the ones who do care are so hung up on 1337 code that they miss the forest for the trees.
The GPL isn't a holy book. It's not even a holy license. It's a license that tries to assert certain rules in order to maintain a particular code of conduct among the licensees -- just like every other license and EULA out there. If you don't like it, don't use it. If you aren't a programmer, it really isn't your problem.
Multimedia interface (Score:3, Interesting)
Re:What now? (Score:2)
Yup, VI!!!!
(or Emacs for you freaks)
We have organizations to do this already (Score:3, Insightful)
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.
I think you misunderstand the role of the LSB (Score:5, Insightful)
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.
Get someone to use it. (Score:4, Insightful)
Similar to beunited.org (Score:2, Informative)
The BeOSJournal [beosjournal.org] recently spent over 2 hours in the second part [beosjournal.org] of an ongoing interview [beosjournal.org] 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 [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.
Single UNIX Specification (Score:2, Interesting)
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.
I just put in my big 2... (Score:5, Interesting)
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
Hear hear! (Score:2)
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).
Re:I just put in my big 2... (Score:4, Insightful)
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.
Re:I just put in my big 2... (Score:3, Interesting)
KDE has something that makes man pages a little more palatable. If you type a url of the form man:/command into a Konqueror window, you get a rendering of the man page for that command in HTML. Then you get colors, hyperlinks, nice formatting, the ability to dynamically resize the page, a nice search function, a back button, a scroll bar, mousewheel support, and all the other niceties of a modern browser. If the documentation was in a better format to begin with, one that had more ability to specify hyperlinks and graphics, this would be the perfect documentation browser.
Re:I just put in my big 2... (Score:3, Insightful)
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.
Is there anything big still missing? (Score:5, Interesting)
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.
Huh? (Score:2)
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.
Office Documents Format (Score:5, Insightful)