Create an Account
username: password:
 
  MemeStreams Logo

Stupidest Slashdot Topic Ever

search

Dagmar
My Blog
My Profile
My Audience
My Sources
Send Me a Message

sponsored links

Dagmar's topics
Arts
  Sci-Fi/Fantasy Literature
Business
Games
  Role Playing Games
  Video Games
   PC Video Games
   Console Video Games
   Multiplayer Online Games
Health and Wellness
Miscellaneous
Current Events
Recreation
Local Information
Science
Society
  Activism
  Futurism
  Politics and Law
   Internet Civil Liberties
   Surveillance
   Intellectual Property
  Media
  Philosophy
  Religion
  Security
Technology
  Computers
   Computer Security
   PC Hardware
   Computer Networking
   Computing Platforms
    Linux
   Software Development
    Open Source Development
    Perl Programming

support us

Get MemeStreams Stuff!


 
Stupidest Slashdot Topic Ever
Topic: Linux 8:49 am EDT, Apr 21, 2005

From the initial question posed by mydoghasworms, to the complete and utter lack of evidence to show acquaintance with the subject matter of the people posting, to the rather horrifying upward moderation of their comments, Slashdot has hit an all-time low with this article.

The fact of the matter is that the Linux Standards Base initially neither provided anything useful in the way of defining the structure and operation of a Linux machine, nor did it provide constructive justifications for the things that it *did* specify. Now in what seems like their nth revision, they *still* haven't gotten a clue, and have strayed even further into uselessness--a uselessness which now apparently incorporates a certification body! (Because there's nothing like bureaucratic overhead to make an operating system function smoothly!)

If you'd like some really stellar examples of the kind of mistakes they were making, the initial standards documents actually contained very little in the way of where files should go, and instead focused heavily on requiring people to use RPM. No joke. Their latest revision has entire sections devoted to what amounts to a re-documentation of the X library APIs. It's all well and good to attempt to freeze APIs--development teams for the various projects that make up the typical Linux machine do it all the time--but for an outside vendor to do this in the absence of any context for facilitating the upward change which makes Linux so attractive to people who actually know what they're doing, well, it just doesn't bloody work! A Linux machine effectively ceases to be a Linux machine once you've metaphorically vivisected it and pinned all it's various organs out on the block and then sealed it in ambergris for all time. It becomes a _dead thing_.

Probably a million times more useful is the Filesystem Hierarchy Standard located at http://www.pathname.com/fhs which, in a very straightforward and engineer-like way worries about the filesystem layout first, and trusts that vendors have engineers smart enough to be able to write shell scripts to determine whether or not something is going to work if/when it's installed.

The main difference between these two approaches being that the LSB folks seem to think that installation of software is something between sticking your hand and arm as deep as you can into a nest of sleeping scorpions in total darkness and possibly airlift-delivery of a playground deep into the heart of New York City. They apparently feel that the host operating system should be required to lie there perfectly still and "just take it". The FHS team's approach is one much more like "stuffing" a volkswagen bus. They appear to feel that as long as everything is laid out reasonably, that one can get feedback from the people already inside the bus about whether or not there's room for more people and whether or not they should come in through the door or the back window.

Stupidest Slashdot Topic Ever



 
 
Powered By Industrial Memetics
RSS2.0