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?"
Better hardware support
Better performance
Maintain excellent reliability.
What else could you need?
There is no "I disagree" mod for a reason. Flamebait, Troll, and Overrated are not substitutes.
and concave lenses, with a relatively low refractive index and arranged in an optimum series for magnification of subtle surface-details, at quite a close range - say between 200 and 400 mm.
Thanks. I'll be here all week.
"Flyin' in just a sweet place,
Never been known to fail..."
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.
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).
That just freaking works. I never understood why every distro can't just use the same install method. Whatever it may be, rpm, apt, yast whatever. And I don't mean the 3 step make install method. Wouldn't it be great to go grab a package from freshmeat or sourceforge and...oh look that's the package type I need....
That which does not kill me only postpones the inevitable.
Admit it, wine sucks and there are lots of programs that will never be ported. I want wine to be integrated and almost invisible, like the Classic interface in OSX.
Why is it that all the developers seem to be able to code to a standard API - but they can't even come close to agreement on the way a program is operated? Maybe it's time to create a UI standard for Linux apps?
This would go a long way towards making Linux the favored choice for desktop machines. Ease of use is a great way to unseat the dominant OS; it's not exactly easy to use and it's very possible to beat them at this game.
The first of those two is self-explanatory. High-quality, high-performance Free 3D drivers for good hardware.
The second...
I want some (not all) kernel developers to stop using throughput based metrics to measure performance, and instead use a metric based on interactive performance. I have a suggestion for such a metric...
The time between user input and the user input having a noticeable affect on an output device like a display. And I don't think this time should be as short as possible, though that's a good goal. The time should be as consistent as possible while remaining short. I propose a metric that measures this latency and plots the standard deviation of the latency and uses that as the main metric with that average latency being a secondary metric.
Need a Python, C++, Unix, Linux develop
1) Wifi networking
Too many wifi cards (especially the Broadcom chipsets) are painfully difficult to get working correctly. WPA2 encryption support is flaky. Wired and wifi should switch gracefully.
2) Better sound support
There are too many conflicting ways of producing sound, some of which dislike working together. Midi support should be built-in. Currently, it's a pain to install. Hopefully KDE's Phonon subsystem will help here.
3) Better a/v
Too many movies have unsynced audio and video. Also, many codecs are unsupported. Yes, I know they're proprietary, but I don't really care. Ubuntu is making codec installation easier, but frequently the codecs only work with some particular backend. (For instance, even with mp3 support installed for gxine, Amarok (a KDE app) still needs to install it's own. The desktop environment should provide a generic way for apps play audio, and if a KDE app is running under a Gnome environment, it should be able to "just work".) Don't forget the wonderful closed-source
graphics card drivers!
4) Easier windowing subsystem
No one should have to edit xorg.conf to get anything working. Fortunately, the next release of X windows is supposed to finally do away with this by adding dynamic configuration with xrandr. Also, it will be nice when CompizFusion is more robust. Lots of people really like the eye-candy, and I find some of the features useful.
5) Applications
It should be easier to keep applications up-to-date. I love Ubuntu, but it drives me nuts seeing bug fixes or major enhancements to applications that I can't easily obtain because either the OS updates don't include application upgrades, or the OS repositories are simply not adequately maintained. I don't want to have to
litter my package manager with repositories, or manually install packages just to keep my apps updated.
6) Laptop support
Suspend and resume don't always work very well. Some laptops don't come back, and frequently networking
is messed up.
bytesmythe
Hypocrisy is the resin that holds the plywood of society together.
-- Scott Meyer
Seems like everytime I click the help menu, I get some skeleton outline, if anything at all. I don't mind googling around for the information, but if usage is going to grow outside of the techie segment, the help systems are going to have to catch up with Windows 95 era chm files, at least. I'm not talking about technically, but rather actually having some useful content in the systems. I understand that writing documentation is no fun, so I don't hold out much hope for this.
Sure would be nice though.
While it has been said before, I believe 3D is the path. Please, please, provide support on par with Windows for any 3D graphics hardware, whether inside a computer or a console.
That is the path to success on the desktop. Today, I cannot even run OpenGL apps or any 3D apps on the lastest and greatest 3D graphics hardware from AMD (formerly ATI), the Radeon 2900XT. Why? There are no drivers. They have focused entirely on Windows, and consider Linux a niche market not worth the effort. Because of that, my family do not have a Linux only machine, which is also why I dual boot. The Radeon 2900XT support may well come to Linux, "when it is ready".
Please, take 3D support in Linux more seriously, whether you are hardware manufacturer or a software developer.
http://elektra.g4ii.com/Main_Page
I think it's at least worth trying such an implementation. Ok... now bring on the "It Windows again" haters...
||| I still can't believe Parkay's not butter.
If you want to win the desktop war, you can, in a few years, by asking yourself a single question:
Could my grandmother (who is already "sort of" computer savvy) use this without calling me every five minutes?
It's been a minute since I've used Linux as my desktop, but if users are still being forced to edit text files to change common program preferences, you'd better get used to your third seat behind Windows and OS X. I'm not telling you to have some crazy xml schema with a billion pieces fronted by a hefty GUI - I'm just asking you for the option of using a lightweight GUI to parse and store my preferences to the same text file.
Keep your CLI, and -color-code-for-Klingon-language-support options, but don't even try to force that on every day users. Leave stuff exposed so you can work your admin magic, but build some sane GUIs for everyone else unless you enjoy end-user support.
...with good support for building from source. We obviously need a standard package format with robust support for complex dependencies. The build-from-source part is also really important: right now, no distro (not even Gentoo!) makes it easy to, for example, compile your own Mesa libraries and have them used by the pre-compiled X server. Right now, you can pull a project from cvs/svn and do a make install. But it will overwrite the version from the package and break dependencies. This greatly raises the barrier of entry for testing new code, making the "open source" aspect of Linux software far more accessible.
Once we have a unified packaging system, the meaning of a "linux distro" will change. There will be a lot more sharing of work for the base system, and separate distros will really become sets of config files with just a few changes from the upstream code. Kubuntu is a great example of this: it is a low-maintenance specialization of Ubuntu.
1) PDF support. Almost all PDF readers on Linux except for Adobe's product have difficulties with large PDF documents. What's with the "LOADING" message that takes forever? Adobe Reader looks horrible (inconsistent with the native GUI). There isn't a single PDF reader besides Adobe Reader that supports subpixel rendering which makes the font rendering hurt my eyes.
/etc directory and has three windows: a list of text config files, a window that displays the file, and a window with a paragraph or two of explanations and examples on how to change the file.
2) MIDI support
3) A "configuration manager" that knows most of the contents of the
4) More active development of Fluxbox. It could use more features like shading on mouse wheel scroll and multiple backgrounds for each workspace.
5) A publicity website for Linux! This is probably the most important thing the Linux community could do. Features are nice, but who cares if no one uses them? The website would contain among other things:
-Step by step guide and interactive application to help people select a distribution
-Explanation of all major window manager/desktop environments, again to help people select.
-List of most mature Linux apps with description, screenshots, reviews, and commentary by users
-Discussion forums
-Latest on Linux section: demos of CompizFusion, new apps, tips and tricks, etc.
-Section specifically for articles on switching from Windows difficulties
-User friendly, designed primarily for noobs
-Linux store with quality Linux clothing
-Professional design
"What lies behind us, and what lies before us are tiny matters compared to what lies within us." Ralph Waldo Emerson
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
I'd like to see a Performance Squad attack all the desktop apps and their underlying components.
Not the kernel, but kernel hackers do know a ton about how to get good performance, so if they all took time out from the kernel to make the rest of the desktop snappy that would be just fine with me.
Of course I've seen some efforts at this over the years. Dave Jones' perennial "why userspace sucks" talk, some work by Robert Love, some other GNOME folks looking at memory usage, the recent Intel tool looking at CPU-wakeups eating battery life on laptops, and lots of other pieces of the puzzle.
It would be great if the basics of performance "best practices" would become widely known by desktop app programmers again. Instead we're falling into Microsoft's habit of being lazy about performance and expecting Moore's Law (increasing CPU speed and cheaper RAM) to bail us out.
Now my girlfriend's answer would be different: OpenOffice still sucks too much (feature-wise), and it's keeping her from switching from Windows.
I think Linux should have a totally different interface to Windows or OSX. The target audience for Linux are server administrators and power users and I think the interface designers should realise this. I really don't think that linux will ever beat Windows or Mac for usability, and maybe it doesn't need to. If Linux rewarded you for learning the bash shell then it would be a really interesting environment. As it is I can switch into the terminal to try and get some things done, and if I typeset my latex document I then have to switch back to the GUI to view the pdf. Linux is confused about whether it should be using a GUI to do something or whether the CLI is the better way. Window Managers for Linux all seem to be relatively similar to Windows or Mac, and there doesn't seem to much reason to use linux for a DIFFERENT or better experience. I think this is mainly due to the many different developers involved and their total lack of interest in consistency for their users. The idea of using the CLI is still basically an essential of the latex system due to compiling software. It should be developed to take over the interface, not be hidden behind an inadequate GUI. This would refocus the idea of linux into a straightforward, techie, scripting style interface. However, the CLI needs to be a lot more exciting than the crappy CLI we have now. They need to do things like allowing usage images and media, using search abilities, fixing file heirarchy addressing (as it makes CLIs really difficult) and doing spotlight like smart folders. An CLI interface of this type would need a really good built in text editor that is not quite as obscure as emacs or vi. Linux should embrace its techiness, but not for techiness' sake.
I'd budget $1M/year for a minimum of five years for full-time work on the Hurd. No, it isn't Linux but it is an alternative kernel with interesting features that is sadly stagnating.
No, it doesn't have interesting features. If it had interesting features it would not be stagnating and lacking in developers. OpenBSD is an alternative kernel with interesting features and that is why it has enough developers and support to be usable.
There are no end of unfinished OS projects with a couple of developers that move to a completely different kernel every six months and will never, ever be finished. I don't see how the Hurd stands out from them. I foresee your $5M funding nothing except a huge amount of meetings, committee decisions, politics and rewrites. You'd be better off selecting a random microkernel based OS project on Sourceforge and giving it to them. They might actually produce something.
I don't want to discourage anyone from working on the Hurd if they find it interesting, but giving them $5M and expecting something useful to come out is just ridiculous.