Slashdot Mirror
How Would You Refocus Linux Development?
buddyglass writes "The majority of Slashdot readers are no doubt appreciative of Linux in the general sense, but I suspect we all have some application or aspect of the platform that we wish were more stable, performant, feature-rich, etc. So my question is: if you were able to devote a 'significant' number of resources (read: high-quality developers) to a particular app or area of the kernel, and were able to set the focus for those resources (stability, performance, new features, etc.), what application or kernel area would you attempt to improve, and what would aspect you focus on improving?"
Find out all the things at take too many clicks, or require editing text files and make them "Just Work" in a simple and easy way.
1. Better GNOME usability for Ubuntu (with delivery of Bulletproof X and the GTK Xconfig ASAP, please)
Seriously, the desktop lacks stuff that has been in Windoze since '95. The kernel works pretty good. We have pluggable storage okay.. but there's still basic holes in the usability (like changing the res on the fly when I move my laptop in and out of my office) that just need to get fixed.
2. Spend whatever time is left over to make OOo faster and easier to use.
The MS Office import filters are so *almost* there, but this app really needs to close the usability gap with Office. I have a semi-decent machine running Ubuntu, and even with Java disabled, it still takes what seems like forever to open a simple document that someone emails to me.
I know these aren't *really* linux-specific, especially OOo, but it's what needs to happen to make linux a real, legitimate desktop force. I'm an easy sell, I love open source, but right now there are too many excuses for why this stuff isn't gettin' fixed, and not enough fixin' it, and right now I'm not telling my computer-illiterate friends that they should go order a Dell machine with Ubuntu preloaded.. I'm telling them to buy a Mac, so I don't have to tell them how to fix basic stuff.
If you are looking for a completely GUI drive *nix I would say OS X is your best bet (yes, I know you can use the CLI in OS X, but you never have to unless you so desire).
You know what I'd love more than further improvement in any of those areas? Comprehensive, well-written documentation.
Visual coherency and a refined GUI. Taste in UI's vary between people, but most linux GUIs that aren't very minimalist tend to suffer from wasted space.
/etc, what goes in /bin, what goes in /usr/bin, and so on). Things like KDE, Gnome and other window managers are merely applications as far as I'm concerned and should be considered no more Linux development than, say, Open Office. Of course, I don't mean to say your view is wrong in the least. I just considered the question more narrow than you did and wanted to explain why I didn't consider any X development as part of the question.
Granted, this is important to the Linux community, but when I hear Linux development, I think kernel, modules, and organization (like what goes in
Also, since X relies on video hardware, I'd consider X and XGL/Compiz-Fusion/Beryl to be categorized under hardware support.
In interests of making linux more accessible, more configuration utilities that don't require specific knowledge and in-errant editing of configuration text files.
Good point, or better yet, make these files standard across distros so the same configuration utilities works as well on Gentoo as Ubuntu.
A standard method for installing applications across distros would be nice too. I forgot to mention that!
There is no "I disagree" mod for a reason. Flamebait, Troll, and Overrated are not substitutes.
Granted, this is important to the Linux community, but when I hear Linux development, I think kernel, modules, and organization
Then you didn't read the summary very carefully:
if you were able to devote a 'significant' number of resources (read: high-quality developers) to a particular app or area of the kernel
In other words, something that improves KDE, Gnome, X, etc. is a perfectly fine answer to this question.
1. An easy, approachable Hardware Compatibility lookup website. It would consolidate all the compatibility info from kernel & X11 devs, major distros, OEMs and also allow end-users to add their input. FWIW, the HCL at linuxquestions.org is an interesting start but nowhere near exhaustive or current enough to empower Linux users (not hackers) to confidently purchase new equipment.
1a. A certification program for drivers that allows products which meet criteria to bear a special Linux compatibility trademark emblem.
2. Fix the sound architecture. Blocking of sound output still occurs after many years of ALSA. There is no GOOD reason why Harriet shouldn't hear her softphone ring or calendar alarms just because a minimized web page contains a Flash object. Telling her to muck about in the CLI, to buy a pricier multi-channel soundcard, or to learn about sound servers and juggle them is beyond the pale.
3. Create an excellent default IDE for the LSB Desktop environment. The IDE will be geared to target the LSB Desktop spec by default, with desktop applications as the focus. Something you would write a video editor or DVD burner with, not so much a video card or disk driver. GORM on steroids: If it doesn't inspire budding application developers like XCode and Visual Studio then Linux will not inspire application developers to write. Linux will not benefit from many more systems developers at this point because its the apps that matter: The apps sell the platform.
3a. Well-rounded API documentation for the LSB Desktop target, ala MSDN or Apple Developer Connection, eventually integrated with IDE.
4. Enable app developers to become as independent as possible, such that distro managers do not insert themselves between the developers and their users. Distros ought to distribute OS software, and for the most part stay the F*ck away from controlling installation of particular applications. High-level package managers like APT, YUM, etc. should stick to managing (or mangling) the OS dependency tree and leave apps the hell alone! Provide dependency targets in the OS repo like "LSB Desktop", and only one or two others like "Java 6". Then, accept that all the extra stuff you supply on top of LSB is ONLY extra, and will get used when and if the user decides in specific cases.
4a. Ensure those budding app developers can easily share their work with friends and customers. Make appdirs like on OS X and Gobo Linux a standard. Dear God, please.
5. Hacker culture works extremely poorly for application software today. Fund efforts to spread the discipline of user-centered product development. Teach FOSS developers the concepts and ropes of SDLC and Rational Unified Process, with emphasis on adding actor definitions and use-cases to docs and project wikis so that these elements are continually refined and re-thought eventually becoming the centerpiece of requirements. Create use-case instances (scenarios) in close association with unit/app testing scripts. Anything to keep developer minds on the kinds of users and situations the software is meant to satisfy. Encourage budding Business Analysts to do 6-12 month stints with FOSS projects.
6. Create settings persistence (configuration) APIs for crucial system services like X11, Samba, Apache, sound, etc. Get these projects to set and manage their own config files, as no one else seems capable for doing this consistently or well. Maybe when they have to write AND parse their own config data, they will stop creating needlessly bizarre & open-ended formats that umpteen distro tools only understand halfway.
7. Next-generation, object oriented shell based on something like Ruby, Python or even Groovy.
Lastly, all of the above must be in the spirit of fulfilling primary personal computing scenarios like app and driver installation, and configuration of essential services (change screen res, use a network share, etc) in a predictable manner. Unlike MS and Apple, Linux does not yet grok PC land because
IMHO the toughest job facing the OSS community is education: teaching, learning, and how to document.
This is compounded by the issue that most developers do not find documentation fun. If the common perception that geeks tend to be nerdy and poor at communication is true, then we have a triple whammy. This is one reason I say documentation and communication and education is our collective biggest failing.
The learning curves for _any_ of our packages are steep. SysAdmins rejoice in the job security they perceive they gain as their expertize for apache, mysql, postfix, postgreSQL and so forth increases. The thing is each package has so many options that it takes forever to learn how to set them up. At last count Debian boasted over 30,000 packages available. How is one suppose to even know what a small percentage of these packages do? That is much less than to learn how to install, support and maintain them?
But this is just the systems administration arena. The API's and programming is an order of magnitude more difficult to keep up with.
Then the documentation. To use WxWidgets for instance I am faced with over 3,000 pages of main manuals, I need to decide if I use DialogBlocks or CodeBlocks or neither. I need to figure out what each does and what each doesn't, and after I buy Julian Smart's book - its another over 500 pages to read. In spite of the fact he's written DialogBlocks there is no useful information on same in his book. Thanx.
This is only one (1) package. I have not addressed version differences and library dependencies and so forth. I have not considered the issues of limitations and bugs.
To keep up is typically information overload to the gawd-zillion'th degree.
---
M$ recognized this and attempted a solution. From what I can tell in around w95 they pulled all the error messages out of the system. I experienced the great joy of accidently turning off the external SCSI hard drive on a W95 computer while the system was accessing the disk... reading it actually. No error message was reported. We got what looked like "END OF FILE". This was M$ code reading the disk.
Then on another occasion I noted a networking message from NT4.0 had the exact same text as from OS/2. The error number in NT4.0 was missing. Everything else was the same. On a hunch I looked up the message in OS/2 and lo and behold the error number lead to the issue at hand. Of course NT4.0 was no help at all because this information had been removed.
Either it was removed or never put in. I dunno. What I do know is that the systems ability to correctly diagnose was hamstrung.
So what do we have in the OSS world?
1) volumes of crappy documentation layered on more volumes of poorly organized documentation.
2) When problems are found and corrected - no good method exists to upgrade the docs.
Here is an example. Many years ago I ran into a sound configuration issue in Debian Woody. This had to do with esoteric issues of generic SCSI drivers and bad permissions and so forth. I ended up posting in SourceForge a complete description of the problem and how to walk through it and fix it.
Two (2) years later none of this information had been disseminated through the documentation of the package at hand where I had discovered it. Debian was still misconfigured. People were still coming into IRC pleading for assistance on how to get the software running (It was GRIP as I recall).
---
This is just terrible performance and we are not getting much better at it.
There are several websites of documentation. SourceForge does this. IMHO they do it poorly. There are many wiki's dedicated to various packages. Nothing is coordinated. The man and info pages I have in my latest system are still the first place I would like to look for information and they are basically just as bad now as they were in 1997. Probably these documentation sources have not been updated much since 1997. Why not? If there is new
The winning aspect of Ubuntu is: if something's too hard for a newbie, that's considered a reportable bug that should be fixed. This attitude makes all the difference.
http://rocknerd.co.uk