Commentary

Serdar Yegulalp
 

Make Linux Suck Less

Linux sucks! So says Bryan Lunduke, himself a Linux software developer, at a presentation he gave at Linux Fest Northwest. In truth, it's not a hatchet job -- it's exactly the kind of pointed and forceful Linux criticism we need more of.

Linux sucks! So says Bryan Lunduke, himself a Linux software developer, at a presentation he gave at Linux Fest Northwest. In truth, it's not a hatchet job -- it's exactly the kind of pointed and forceful Linux criticism we need more of.


More Software Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

The important thing to keep in mind is that this isn't a flat "Linux Sucks" rant. It's about desktop Linux sucking, which is only one part of the larger Linux equation. Bryan likes Linux a great deal, but like so many of the rest of us there are parts of it that he just keeps tripping over and breaking his nose on.

Here's Bryan's major points:

Fix hardware problems. A lot of the compulsive breaking of hardware is due to the way new revisions of the software are hustled out without regard for proper backwards compatibility. Maybe with things moving to the HAL (hardware abstraction layer) setup in Linux this'll be less prevalent, but his point is made: have some regard for the people who choose to use this stuff, or they will choose someone else.

Pick a packaging standard and stick with it. RPM. Period. Yes, any choice is likely to inspire no end of war between the various package-management-standards defenders ... which is in itself a broad symptom about exactly what is wrong with the way Linux is created. Instead of solving problems, all too often people pick turf wars and become ideologically jealous.

Fix desktop audio. Pick the API that the programmers use most -- GStreamer -- and write for that. Forget about everything else, it's not worth the hassle. (That's probably going to come as serious bad news for the PulseAudio lovers, since Ubuntu uses PulseAudio.)

Commercial software for Linux must come to the fore. Simply put, open source development has failed miserably when it comes to delivering a project like a professional video editing system. The commercial market has this stuff all sewn up; the few people who even think about using open source solutions in a pro setting usually do so because there's a programmer of some kind on staff.

This is also why GIMP hasn't replaced Photoshop -- not only because GIMP doesn't have this or that feature (native CMYK support, mainly, and font handling that has more than a trivial feature set). It's because Photoshop has become a de facto standard, and you can't unseat such a thing by simply offering an alternative for nothing. You have to actually outdo the existing standard across the board.

Bryan's answer requires that Linux users -- and Linux developers generally are Linux users, too -- take a stand. Either donate to open source projects that equal what you'd pay for a commercial app, or bug the closed source companies to make more Linux software.

The former I see happening a lot more readily than the latter. I talk to vendors all the time and ask them the same questions: Are we going to see a Linux version of this? The answer is predictable: No, because there's no real demand for it. When I dig deeper, I get other answers: Anyone who uses Linux is probably using open source app X anyway, or dual-booting to Windows to get that done. You tell me if they're wrong.

Good job, Bryan. It's comforting to know there are other people out there doing this sort of work aside from the Linux Hater's Blog (who, by the way, seems to have come back from the dead).


InformationWeek will be highlighting innovative government IT organizations in an upcoming issue. Nominate your agency by submitting an essay on your most innovative IT initiative completed in the last year. Find out more, and nominate your organization by May 1.


Follow me and the rest of InformationWeek on Twitter.


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links