Create an Account
username: password:
  MemeStreams Logo

Less technical than nuclear mechanics


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

sponsored links

Dagmar's topics
  Sci-Fi/Fantasy Literature
  Role Playing Games
  Video Games
   PC Video Games
   Console Video Games
   Multiplayer Online Games
Health and Wellness
Current Events
Local Information
  Politics and Law
   Internet Civil Liberties
   Intellectual Property
   Computer Security
   PC Hardware
   Computer Networking
   Computing Platforms
   Software Development
    Open Source Development
    Perl Programming

support us

Get MemeStreams Stuff!

Current Topic: Linux

Dropline GNOME 2.18.3 beta for Slackware 12 now available
Topic: Linux 4:06 am EDT, Aug  4, 2007

(Disclaimer: I'm a major contributor to this project, but no one
else has posted it, so... whatever.)

For those Slackware users left out there, the Dropline GNOME team is pleased to announce the availability of the beta of Dropline GNOME 2.18 for Slackware 12.0.

Basically, after you've installed Slackware 12.0, grab the beta installer client, install it, and then run dropline-installer. The installer will then give you the ability to download and install all the wonderful packages necessary to use GNOME 2.18.3 on your Slackware Linux 12.0 machine. This means easy access to Inkscape, Evolution, OpenOffice, Ekiga, and all the other wonderful GNOME 2.18.x applications.

We can still really use testers, although it would be preferrable if you'd do this on a clean install of Slackware 12.0, since over half the bug reports on upgraded machines boil down to errors made while upgrading.

Dropline GNOME 2.18.3 beta for Slackware 12 now available

Apparently you can't even *give* Linux away in Austin, TX
Topic: Linux 4:29 am EST, Dec 12, 2005

Someone on IRC referred me to this one.

A man spends a day on a streetcorner trying to give away Linux CDs.

Apparently you can't even *give* Linux away in Austin, TX

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 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