I think one of the reasons people like Richard Stallman are so insistent on this point is to cover up the shortcomings of the GNU part. GNU is Not Unix -- not by a mile. GNU is Not Usable, too. GNU is also not an operating system. It's a half-assed, half-finished implementation that's been hamstrung by the very people who insist on inserting "GNU" before Linux. Rather than embracing "free" software that already existed, Stallman, et al, chose to reinvent the wheel. They haven't gotten very far and instead have wasted a lot of time in pissing matches about freedom and issues that are unrelated to free software (e.g., anti-DRM measures which are content- or data-centric rather than related to software, per se). Were it not for Linus Torvalds and his kernel, GNU would be even less Unix and usable and useful than it is now.

Some words take on meanings that are either broad or narrow. In the narrow sense, Linux is a kernel. In a broad sense, though, it encompasses a lot more than that -- the broader ecosystem transmitted in the form of a distribution. In a way it's analogous to trademarked names that become increasingly generic because of prevalence and familiarity. I know I've been given plenty of "xerox copies" from non-Xerox printers. I think Linux is like that and can be safely and accurately used in a broader sense to encompass not just the kernel but the full system of any given distro.

As I noted above, most users don't experience the kernel or GNU utilities directly but rather through interfaces that are definitely not GNU. Without X, without desktop environments like KDE or window managers like enlightenment, Linux adoption would be even less than it is now (especially on desktops). But we don't hear the X or KDE people insisting that it be called X/KDE/GNU/Linux. Thank goodness.

Moreover, not every distro uses the GNU utilities. Some use busybox  to replace GNU utilities and leave out a toolchain, but they still most definitely use the Linux kernel. This is where the arrogance of the FSF types and GNU/kooks prevails and cons developers into calling it GNU/Linux despite the lack of a GNU toolchain or utilities. I'm singling out Slitaz for using "GNU/Linux" when they're really just Linux. Or busybox/Linux (which is even dumber than prepending GNU). How much GNU software is in Slitaz' base? X isn't GNU software. Neither is jwm or Xfce. Nor openbox. X isn't even under the freaking GPL.

If it's not GNU, why the stupid blanket insistence by the GNUtards that it be called what it isn't? Dumb, dumb, dumb.

So this got me to thinking about how much of the GNU bloatware I might be able to replace. I already ditched bash for the free-er and more nimble ksh -- mksh  to be precise. I considered the Linux port of OpenBSD's ksh but the guy who ported it reflexively slapped GPL on it. I really hate that kind of thing but that's an article for another day.

My latest de-GNU'ing came last week when I installed libarchive (from FreeBSD) and symlinked bsdtar and bsdcpio to be my de facto tar and cpio. I also added OpenBSD's pax (with Debian's patch). Can never have too many archiving utilities, especially when considering replacing one operating system (or one distro) with a better one.

I know I'm mostly stuck with GCC, which is unfortunate because it typifies the kitchen-sink bloat mentality of the GNU types. And there are some things like screen that I know I'll continue to use whether it's GNU or not -- but that's separate from the base utilities. I'm looking for more anti-GNU replacements for this just to see how little GNU I can have in my Linux. That way I can correct any lamer GNUtard who stupidly tries to correct me when I intentionally and willfully -- and quite happily -- leave GNU off Linux.

There's a catch-22 between supporting newer hardware and supporting older hardware and keeping it "damn small." I think one negates the other to a large degree unless drastic compromises are made. Those kinds of compromises seem to be off-putting to many users -- the ones who show up and say "this used to work when ____" or "but it works when I run ____ so you suck." People take it personally when support is reduced in one area even if it's at an extreme in new or old, such as removing certain modules or applications. It doesn't matter if you make the modules or applications available so users can still use it, they demand things be just as they were but better.

Other compromises also include doing things that are suitable for newer hardware and unsuitable for older hardware, like certain compression protocols. Some distros do this and claim they're suitable for older hardware when their compression decisions really aren't suitable for those with slower CPUs or less RAM. To DSL's credit, it hasn't jumped on the "compress the shit out of it" mentality and still delivers utility in its 50 MB. So while other "small" distros pack as much or more in a similar ISO, they do it in a manner that makes it an unwise choice for certain hardware.

The question always boils down to, Which user base are you willing to give up? Will you give up those who have newer hardware or those who have older hardware? Or are you willing to make other compromises like increasing the base size from 50 MB to 50+N? Or just remove that limit and make it as "small as possible"? If so, where do you draw the line between what you add and why?

Not easy choices.

The days of "easy" one-size-fits-all distros are over, no matter what size. You can either stay on the bleeding edge so every new fangled device is supported or you can fill a niche and do what all these advocates say Linux is good for -- extend the life of older hardware.

It was easier to fill everyone's needs in one distro when there was a lot less to support. Debian Woody (upon which Knoppix 3.4 and DSL were built) was "approachable" by most hardware of its own era as well as what preceded that hardware because there was less technology to deal with. That's why DSL was, and to a large extent remains, "approachable" to a lot of hardware up to a certain point.

A lot has changed, for better or worse, since that time frame when Debian Woody, Knoppix 3.4, and DSL were concurrent with those vintages of hardware. The kernel has a new version, a lot of new processes are thrown into the mix, hardware has gotten faster and fancier, and all software has grown very bloated. The demands of users have changed right along with the abilities of their hardware to absorb the resource demands of bigger kernels, more powerful hardware, and GB wallpaper to fill GB RAM.

DSL was suitable for hard drive installs while Woody was supported by Debian. Not anymore. There's too much that needs to be fixed and updated, and that's not even getting into changing kernels, while the world has moved along with bigger, faster computers.

I'd thought about re-engineering and updating DSL so there could be a separate traditional hard drive version. That would serve two purposes: it would allow DSL to focus on its intended use and it would also "freshen" up things so those wanting a traditional install would have a bit more security and a system that's really designed for hard drive installs. I'm not dissing DSL in this respect at all, it's just getting long in the tooth with respect to available security patches and the "Debian -> Knoppix -> DSL -> pseudo-Debian" process could use a bit if fixing so it's more like "Debian -> pseudo-Debian." Not to mention the issues with using extensions that are intended for nomadic rather than static use.

I think the age of the base alone is reason to discourage hard drive installs, short of users taking time to manually patch up the base (which I've done to a large extent and can attest is a very time-consuming proposition). You can't reboot into a fresh state if something has been corrupted on your hard drive install, and you can't un-do someone's data being compromised if a computer is breached because of the age and security state of the software included in the base. At least with a frugal install, the damage can be restricted to /home and /opt (and possibly MBR or other mounted partitions if you're using rewritable media). I realize not everyone has hardware that is suitable for frugal installs, which is why I've considered freshening and tweaking things to make a legacy install version.

Alternatives to DSL on hard drive if it's not freshened up? Unfortunately, there's not many modern options especially if you don't want or need a 2.6 kernel. Even minimal installs of Debian come with a bloat factor if one uses apt, and that's the while idea. DeLi looks like it might fill the niche but it uses ulibc, which really isn't a 1:1 replacement for glibc, and I haven't bothered installing it to see how well it stacks up to other distros (I also question the developer's judgment in porting OpenBSD's ksh and slapping GPL on it). Slackware still supports down to version 8 (versions through 11 use 2.4 kernels) and has a lot of flexibility in the way its installed, but that requires a little planning and reading documentation -- something most users seem unwilling to do. That's it for Linux, the kernel that supposedly avoids "planned obsolescence" according to all the fanboy sites and their "20 reasons you should use Linux instead of Windoze." I don't think the distros have gotten that memo.

I've gone in a different direction. I picked up a new hard drive the other day and was going to copy over my last DSL hard drive install and be done with it, even though I want a few things that will require updating a few more things than I already have. Then I thought I'd do a minimal install of Slackware 11 instead and stick with 2.4 and have a fresher base and fewer hassles down the road and an easier pathway to the things I want.

Instead, I installed OpenBSD and updated to 4.3-stable (I may update to -current so I can install Firefox 3, but I may not mess with Firefox at all on my desktop; it's kind of funny that for my browsing I'm using dillo without SSL and elinks with SSL now).

$ sysctl kern.version                                                                            
kern.version=OpenBSD 4.3-stable (GENERIC) #0: Mon Aug  4 23:17:04 CDT 2008

Besides my familiarity with (and preference for) OpenBSD on my servers, one of the reasons I chose it over Linux and the other BSDs is because its installed defaults are pretty spartan -- not that FreeBSD or NetBSD install with excessive bloat, either. Though that's intended for security reasons, there's a side effect of shipping something that has few services started by default: it's excellent for older hardware that should start as light as possible.

The other day I mentioned in the DSL forums the hassles of using Vector, which was supposedly "light" and suitable for older hardware, and having to turn off all kinds of stuff that was enabled by default, changing icons, un-setting wallpaper, etc., just to have a system that was reasonably usable with more RAM available than in use when starting X. And then I ended up recompiling a whole lot of stuff to reduce system demands and dependencies. Light Linux? If so, I don't care to see the heavy stuff.

In contrast, the one daemon/process running in a default OpenBSD install that I could shut off is sendmail. I guess I could also defer running sshd until I need it, but I seem to use it all the time anyway. There's no CUPS running at boot (something I wouldn't have installed in Vector if I'd known it wouldn't give me a choice about starting it at boot -- something else I had to undo to use my freaking computer), no automounters paralyzing the system waiting for devices that may never get stuck into a port, etc. There's also no 500kb wallpapers (no wallpaper at all! hallelujah!), no slavish accommodations to the fashion Nazis, no blurry fonts, no icons all over the place. For such a clean slate you have to set up X yourself, write your own .xinitrc to suit your own needs and tastes (mine is just a couple lines to set a font path for Terminus, set the background black, and start ratpoison), etc. No big deal.

That's one of the reasons I've been a big fan of DSL, and why I've looked forward to tinycore. DSL had no BS and not a lot of crap to turn off so it's usable. Tinycore has even less to strip -- it's a base upon which to build, not clutter to clean up. It may not be user-friendly (yet), but too much stuff that's deemed "user-friendly" is friendly to neither user nor hardware.

Anyway, I've freed up another hard drive, or a significant part of one, for working on core. I still have my DSL stuff on it and don't know if or when I'll delete it. I don't even know how many users want a 2.4 hard drive install with a freshened base. I still see more posts whining about wanting DSL to work with NeatoDooDad v3.8 (which requires kernel 2.6 and libopendoodad for its driver blob to work -- quite crappily -- in Linux) and complaints about the lack of eye candy than any concern for re-Debian-izing things, SSL/SSH patches, or UCI-to-tar.gz extensions for hard drive use.

I suspect it's not something with enough of an audience to even work on it. Please let me know if I'm wrong about that because I could end up trashing those DSL partitions for core development sooner than later.

Bogeymen, secret societies, remote control aircraft, grassy knolls, UFO secrets, and all the rest.

Now add Foxconn and Microsoft. At least for certain Ubuntu fanboys.

Turns out someone ran into some serious ACPI issues with a new Foxconn mobo. A bit of BIOS hacking revealed something a bit odd -- Linux support appears to be broken. Rather than learn more or even wait for answers, the user decided to run to the Ubuntu forums and present this is the latest MS attempt to kill Linux. It gets picked up by semi-coherent twits at Slashdot, snowballs, and before you know it there are all kinds of allegations and insinuations being made.

Uh, what's the definition of FUD again? Nothing like a conspiracy theory to demonstrate the power of fear, uncertainty, and doubt. Especially among the uncritical thinkers who use Linux as some anti-Microsoft fashion(less) statement.

Matthew Garrett delved deeper into the issues, the BIOS, and Linux ACPI.

mjg59: Further Foxconn fun:

Take home messages? There's no evidence whatsoever that the BIOS is deliberately targeting Linux. There's also no obvious spec violations, but some further investigation would be required to determine for sure whether the runtime errors are due to a Linux bug or a firmware bug. Ryan's modifications should result in precisely no reasonable functional change to the firmware (if it's ever hitting the mutex timeout, something has already gone horribly wrong), and if they do then it's because Linux isn't working as it's intended to. I can't find any way in which the code Foxconn are shipping is worse than any other typical vendor. This entire controversy is entirely unjustified.

That's what happens when you shoot first and ask questions later. Anyone who's ever compiled a kernel and taken the time to read the documentation knows of all the hardware-specific kludges (or "bugfixes") contained therein. It wouldn't be the first time there's a problem related directly to a bug in the kernel source or in the way it was compiled. It's not the manufacturer's fault when Linux kernel development is often over-ambitious and frequently imperfect. Dittos for the problem of using a default one-size-fits-all (when they don't) kernel. Usually default kernels are adequate for most hardware. But not for all. Is this something related to Ubuntu's config?

I have an old board that will not even boot with SMP kernels and, being a fan of older hardware, I also have boards that have other SMP issues. That's no cause for me to attack the board makers, just compile a non-SMP kernel for them. BFD. That's why you have the source in the first place -- so you can use it as you need it to run and as you see fit. Not so you can whine about MS and hardware vendors.

Now how the hell do these anti-MS zealots and conspiracy-peddling crackpots put the toothpaste back in the tube?

Les contaré una historia...

Hace mucho tiempo los sistemas operativos vivian en paz, hasta que una gran ventana fúe construida, desde ahi, la gran ventana fue invadiendo las casas de los usuarios, hasta que todos tuvieran una parte de ella. Ahi fué cuando una horda de pingüinos provenientes de la isla Unix, salieron y empezaron a tocar puertas intentando ganarse un cachito del corazon de cada usuario, demostrando las debilidades de las ventanas..."

Algunos de esos pingüinos son grandes, otros medianos y uno que otro pequeñito, aquellos pingüinitos tan pequeñitos, caben en tu propio bolsillo, dentro de una Memoria Flash USB o dentro de un CD.

Les voy a presentar 2 Pingüinos de esos, DSL y Slax.

DSL - Damn Small Linux

Uno de ellos es algo conocido, se llama DSL, afamado por su poco peso, solo 50 mb, cabe hasta en un Mini-Disk...

• Para instalar en un CD lo unico que necesitan es un CD Virgen y quemar Esta imagen ISO, con su programa preferido, como lo es Nero, Alcohol o su preferido.
• Para instalarlo en una Memoria USB, aparte de la Memoria en sí, necesitaremos estos archivos:
  HP-USB Format Tool, Creador de Boot, DSL-Embedded.
  Pasos:
  1. Formatear USB con HP-USB Format Tool.
  2. Descomprimir DSL-Embedded y el Creador de Boot. Los archivos descomprimidos copiarlos a la USB.
  3. Ejecutar el programa "makeboot.bat".
  4. Reiniciar la computadora ¡y probar DSL!

  Nota: Recuerda configurar tu BIOS para que permita hacer boot desde USB.

Slax

Slax, utiliza un entorno de escritorio basado en KDE que lo hace ser mas agradable a la vista, así como es estable gracias a su antepasado Slackware, una de las distribuciones de Linux mas antiguas y que actualmente siguen en uso. Para instalar es todo muy similar, esto va a parecer un Copy & Paste del anterior, pero todo conforme a Slax.

• Para instalar en un CD lo unico que necesitan es un CD Virgen y quemar Esta imagen ISO, con su programa preferido, como lo es Nero, Alcohol o su preferido.
• Para instalarlo en una Memoria USB, aparte de la Memoria en sí, necesitaremos estos archivos:
  HP-USB Format Tool, Creador de Boot, Slax-USB.
  Pasos:
  1. Formatear USB con HP-USB Format Tool.
  2. Descomprimir Slax-USB y el Creador de Boot. Los archivos descomprimidos copiarlos a la USB.
  3. Ejecutar el programa "makeboot.bat".
  4. Reiniciar la computadora ¡y disfrutar Slax!

  Nota: Recuerda configurar tu BIOS para que permita hacer boot desde USB.

Prueben ambos, si uno no les gusta, chequen el otro y si siguen sin estar convencidos... Busquen una Distro acorde a sus necesidades en esta página: "Distro Chooser".

Saludos ^.^

Before ensuring extraneous processes aren't started and extraneous modules aren't loaded at boot:

Actually, that's with ntfs and reiserfs removed from /etc/filesystems and (to make damn sure) modprobe -r for each in bootlocal.sh (DSL's rc.local hack, made necessary by the fact /etc is ro in a live CD environment -- another thing that makes it kind of quirky as a traditional hard drive install). So it was even a little higher -- 15 or 16 MB -- before with bash and 14 with mksh as my shell.

Now I'm only loading ext2/3-related modules along with vfat and msdos (which are small but I could also trim because I have maybe two ZIP disks that are FAT and the rest are ext2, which is my "shared" filesystem between Linux and BSD). I also have made sure reiserfs and ntfs can't load by default or during one of hotplug-knoppix' crazy freaking shotgun module loads. I also found a hefty module that loads by default that my hardware doesn't require. Here's the result a minute or so after boot and starting X (using ratpoison):

I know it's only 4MB trimmed but that's nearly a 50% reduction and boot time is a little faster with some of the changes I've made. I will update the page for DSL hard drive reconfiguration as soon as I get a chance.

Speaking of which, this might be my last DSL HD entry on this blog. I'm leaning towards setting up one frugal install for 4.x and dslcore and reclaiming a few GB. I'm deliberating over what to do with my computers and right now I think I'm either setting everything back up on BSD or a combination of BSD on the ground and Linux in the air (i.e., laptop) at least until I get another wifi card or more improvements are made to the OpenBSD bwi driver (4.4 is now beta and WPA has been added for bwi -- one of my criteria). My opposition towards the bloat inflicted upon users by most binary packaging systems is leading me back to thinking ports are best for me. Using something like pkgsrc on one computer will allow me to compile and distribute as-I-see-fit packaged binaries to the rest of them.

If dslcore has a shell with a little more flexibility and power, maybe the project can drop lua and the "GPL plus strings" BS with a certain developer. That would make it even smaller.

I'd installed bash-3.2 on my DSL hard drive install Friday. I compiled it with nearly every option. The result is a large binary. And this is stripped!

-rwxr-xr-x    1 root     root       686912 Jul  4 18:55 /bin/bash

I also made a pretty prompt showing date and time, which is useful since I see shell prompts more often than clocks, etc., in ratpoison ("ctrl-[escape key] a" shows the time). This was a little less slow than zsh, which is my favorite shell except its slower speed -- all that function and dazzle comes with a price. I wanted something lighter and faster and, if it can be used in dslcore, without sacrificing too much power.

I also run OpenBSD. Its default shell is ksh. The Korn Shell is a very nice shell. It's feature-packed yet unbloated. The version in OpenBSD is much improved over versions I've used in the past. I installed zsh for a day or two on my server but took it off because it was too slow (MMX 200mhz/64MB RAM) and overkill for the few things I need.

I thought of trying ksh in DSL so I decided to look around at Korn Shell offspring. One of the derivatives of the Korn Shell I found was mksh from MirOS (which is based on OpenBSD and NetBSD). I played around with the build script to see how small it could be made. Even after stripping it was in the 200kb range. Suitable and comparable to the default (older) bash in DSL. The license terms for mksh are very simple and not as cumbersome as the GPL.

I started it from my existing bash shell. It was noticeably faster with the first few things I tried. I decided to check "resource drain" with it set as my default. I didn't check the original DSL bash so this isn't a comparison -- you can check your default and weigh these results. It's also not a look at the difference from boot; I have a few hours uptime. As a result, I also had more processes running than a default environment at boot.

These two shots were taken at the same time. The top part is from htop, the bottom is ps aux (with PIDs, etc., removed).

It's very nice to run a kind of complex one-liner and get an immediate result -- something I miss when using zsh and bash on older hardware. I'm going to play around with this a little more later today if I get a chance. I should get around to posting my productivity tip on shells and shell use later this week or next weekend -- and more OpenBSD content also coming on my other blog.

This issue arose when the aforementioned person complained that I hadn't yet submitted an extension even though I'd previously written that I was withholding it pending release of what's now called dslcore. Because of his snotty, demanding attitude I decided that from now on I won't submit anything unless users who want particular extensions are willing to support one of two projects used by DSL: either OpenSSH directly or vim (which is "charityware" with contributions directed to help children in Uganda). I chose these as my "bounty" targets because they're worthwhile causes and supporting both of them further supports DSL and its community. I thought this was fair since the submissions cost me time away from things I value and are probably of some value to others.

Nope. Too many users see "free" software and demand it with respect to cost. (And rarely to freedom.)

The snotty, demanding person took exception to this and, as you can see above, suggested it was at odds with GPL. There are a couple problems with his analysis in the context of the particular libraries the thread was about: not one of them is under GPL. OpenSSH is BSD licensed, zlib has its own "permissive" (in the view of FSF) license, and OpenSSL has a relaxed license as well. All three allow their code to be used in proprietary systems without accompanying source code. Sell it, change it, do what you will, just give credit where it's due.

The other problem is an error that is far too common among Linux users: the GPL is NOT against the sale of software. In fact, FSF openly encourages people to sell free software so long as it's in compliance with the freedoms enumerated by the GPL. You can charge whatever you want for it, but you must not put an excessive or prohibitive cost on the source code (which must accompany GPL binaries).

That's because "free" in the GPL has nothing whatsoever to do with cost. It has to do with freedom -- whether the user has unfettered access to the source code, can use it as he or she sees fit, can change it as he or she needs, can redistribute it.

Unfortunately, this error persists and users don't think in terms of freedom. It's ironic the person quoted above raised the name and circumstance he did because the developer in question publicly offered his code under GPL and then attached strings the license doesn't allow and complained there was some violation (nope) when users actually exercised their rights under the GPL. The offenses the developer initially stated were that the bindings had been separated against his wishes and then redistributed, but those are freedoms central to GPL. As it turned out, the only changes to the code were after the false accusation of GPL violation -- DSL added copyright information where he'd never bothered to put it himself because he assumed he could control how users compiled the various pieces of the runtime he assembled.

When it came to that developer's demands, many DSL users were open to compromise and even insisted that I be just like they are in that regard. No debate about what it means to compromise away your freedom, no discussion desired at all. I was called obstinate, told to go start my own distro, and to leave the forums alone and post my thoughts here on my blog instead. They didn't care about the GPL. They didn't care about their freedoms. They only cared about the cost.

What's the cost in the long run, though, when you lose your rights to use code because you don't stand up to a petty tyrant of a developer who offers something under the GPL and then pulls the rug out as soon as you use your freedoms that license allows?

I'm hardly one to defend the GPL. I have a list of entries categorized as "FSF sucks" reflecting some of my grievances against GPL. But the prevailing confusion over it -- what it actually means -- doesn't serve the wider community who use and rely on software licensed under it.

Such confusion causes whiners like the person quoted above to whine even louder because they don't understand GPL isn't about price or money at all. Not only do they object to even a token "bounty" like he did, they're willing to overlook the conditions beyond the GPL that a developer tried to slap on DSL and all its users. They're more concerned that something is offered "without charge" than "with strings." They're offended when someone offers to do something for a few dollars that will benefit either a project they already benefit from or a program that helps children in a nation ravaged by HIV/AIDS; and they'll roll over and give away their rights -- not to mention their dignity because false accusations were leveled against DSL without any apology -- as long as a developer will give them a freebie.

I think the free software movement has its work cut out when it comes to educating the masses. The masses aren't software ideologues, they just want free (as in beer, as in price) software. And they'll trade away their freedom to get it.

It's important to note dslcore isn't a newbie-friendly release. It's a minimal Linux environment with a kernel, tiny X (kdrive), jwm, fltk, busybox, dropbear (minimal ssh), lua (with certain unnamed fltk bindings -- wink, wink), and scripts from DSL and some of Robert's new ideas. It's stripped way down (9MB ISO) and not particularly useful as it exists. It has no roots in Knoppix or Debian like DSL does.

I compiled all the above to /opt so I could submit for MyDSL. That may or may not occur now. I asked yesterday that my submissions licensed under GPL be withdrawn from MyDSL until DSL either receives confirmation that sources are not required (which would be very surprising to me) or DSL figures out a way to make the sources for its GPL'ed extensions available in compliance with GPL. This was an issue I was dealing with behind the scenes to keep things from being as "dramatic" as they've become. So much for that effort. DSL isn't even mine and other users only seem to care that version X.Y is available, screw any requirements.

I don't think the whole issue of licensing -- with respect to both the freedoms and the responsibilities -- has sunk in among many in the DSL community. This is unfortunate. Some seem quite willing to sacrifice their freedom in the name of pragmatism or even assuaging someone's fragile ego, while at the same time being dismissive of the obligations to make source available (whether at cost or for no charge) for things released under GPL.

It's also very unfortunate things have turned so ugly so quickly, but things start to stink when people come in and stir up a lot of shit like John Murga did (and in the way he did it) and disrupt the community. Between the suggestions I start my own distro and leave if I don't like things, requests that I not share opinions or explain things people seem too willing to overlook (i.e., the GPL's freedoms and responsibilities), the principles that should matter a lot more than the pragmatism (go ahead and include Flash, Opera, and everything else that has strings attached while you're at it), etc., it makes me wonder why I even bother helping others or why I'm even participating in any "community."

Think I'll take the rest of the weekend off to figure that out.

Yes, this is GNU screen running inside ratpoison with a classic solid black background -- eye candy! Heh. I also have some ear candy courtesy of 181.fm's classical guitar stream via mplayer.

The DSL team where sloppy when they violated GPL in this instance as it would have been easy enough for them to comply, while still undermining the standard platform I am(was) trying to create. Maybe I would have only been half as annoyed, and just complained a little, but as it is they removed my copyrights from my work which added insult to injury ...

-- John Murga

The above quote is not just a lie or a damned lie, it's a goddamned lie. First, the GPL was not violated. There were zero changes made to source, just in the compilation; the source is also available (had he asked to see it and compared it to his own he would find no changes where he said there were some). Second, no copyrights were touched. Robert Shingledecker has posted the relevant code directly from Murga's own tarball to show what was (or rather, wasn't) there; after being proven wrong, Murga asked for an attribution to be added where there was none. Third, there was no injury. Fourth, the only insult was Murga's decision to throw a public tirade and make unfounded accusations against others.

The only thing that changed with respect to attributions in the recompilation is Murga's name at the invocation of any part of the runtime -- lua, FLTK, sqlite, zlib, luafs, luasocket, etc. -- even though he wrote none of that. That's what hurt his feelings. Not that the GPL was ever violated.

I'll reiterate what I posted this morning in the DSL forums: It appears that DSL didn't violate the GPL in this instance, the author of the bindings did. Not only does he want to dictate how his code is configured and compiled, he demands credit even when it's not due him. Both points are in violation of the license he chose -- he wants to control the entire runtime and he demanded credit not due him even when his bindings weren't used.

The FSF and SFLC have traditionally come to the assistance of developers when the GPL has been violated. Would they be interested in standing up for users when an author starts making demands and attaching strings to code he or she places under the GPL?

At issue was an allegation that DSL had stripped Murga's lua/FLTK bindings of copyright information. This was shown to be false.

Murga then claimed his bindings were a command line invocation. This, again, was demonstrated to be false.

Throughout the episode over the last few days, Murga was repeatedly asked (including by me) to state his grievance as it relates to how DSL used his bindings before the refactoring of the bindings to the time afterward and present. He did not answer but chose instead to lash out at others and accuse them of "butchering" his project, "molesting" his project, as well as various and sundry ad hominem attacks.

The only thing that happened differently was murgalua was recompiled so its full runtime wouldn't load at invocation of any of its parts. The runtime had become so bloated that it was impractical to use as-is for the purposes of DSL.

This is what led Murga to claim it had been butchered. In the post in which he accused DSL of GPL violations, his sole link to reference his sentiments on untying the FLTK-lua bindings on his forums said he would not condone or approve of anyone doing that. Even though he chose the GPL for his bindings (most of the parts of what constitutes "murgalua" are under much less restrictive licenses).

He admitted throughout his accusation that his feelings were hurt, that he would need time to be more reasonable, etc. So it was at least as much about his feelings as it was about the licensing.

In the course of the resolution of the matter, Murga asked for things DSL isn't in the position to give him -- such as a copyright notice when things he didn't write, like FLTK and lua, are invoked independently of his bindings. To the credit of the DSL developers, this was not agreed to.

But something else caught my eye among his replies. He stated that he had given permission for DSL to use his GPL code.

Permission? Permission beyond the scope of the terms of the GPL? Or just a personal approval?

Between his initial complaint (and hurt feelings) over the bindings being separated, to the odd (and unethical!) demands that he be given ego strokes every time pieces (which he didn't write) of what he put in his runtime were invoked, and the statement that DSL either had or required his assent to use code he released under GPL, I was leery of including his code in the base.

The first thing with the binding separation is allowed under GPL. The GPL gives users the right to see and change the code and include it in whole or in part in other things so long as the rest of the GPL is obeyed (and it was in this case). The GPL is a solution to restricted use of code -- which is what Murga wanted (and wants -- he's suggested that he wants to amend the license) to do.

The second issue with the demands is also central to the GPL. DSL didn't remove any attributions to Murga. In the process of resolving the issue, DSL even offered to go above and beyond what Murga had previously stated was required (his terms and copyright information are all very muddled -- another reason to consider avoiding using his code in the first place). DSL couldn't and wouldn't comply with giving him acknowledgments when lua and FLTK are invoked independently of his bindings. Those things belong to other people, not to John Murga. Credit should only be given to whom it's due, not to whomever demands it in such reckless fashion.

The third part with permission also is antithetical to the GPL. It's a PUBLIC license, not a PRIVATE license. It allows user A to give it to user B without developer Y meddling over the matter. As long as users comply with all the GPL's terms, and DSL did, then the developer is supposed to yield to the user -- not demand it be run in a certain way, be configured or compiled in a certain way, etc.

As things stand now, Murga appears to be offering "GPL but with conditions" instead of GPL. This, though, isn't GPL because it's not free and it restricts users with respect to what they can do with the whole or part of code under GPL.

Until Murga further clarifies (or gives up) his position with respect to the above points or changes his license to be more congruent to his dictatorial demands and novel conditions upon users, I think it's probably best for DSL and other projects to steer clear of his code or to fork the GPL'ed bindings between lua and FLTK. Anything this tainted, offered by someone so petty and emotive, is more of a hassle than it's worth -- as proven by the way he chose to handle it in such a spectacle.

And that's especially true when he chooses to renege on or demand more than the very terms he offered it in the first place. The GPL has specific requirements, not strings. Murgalua, unfortunately, has strings.

The first issue arose when someone posted links to his remasters of DSL. I was annoyed that he posted the same information twice in the forums, and in places where it wasn't really on-topic. I asked how I could get sources for GPL software he used. I reminded him of the judgment of the FSF/SFLC that downstream and/or derivative distros (like Knoppix, Mepis, DSL, Slax, Vector, etc.) had to maintain and provide sources regardless of availability of sources for unmodified binaries taken from upstream repositories. This led to some heated discussion (and also some productive discussion as well) about the whole issue and whether it was appropriate for distros to sell media with their sources.

This gets at the heart of many misunderstandings about GPL. It is NOT about free/no-pay transmission of software. It's about the freedom to see and change source code. As FSF very clearly says throughout the gnu.org site and elsewhere, you can charge a billion dollars for GPL'ed software. The only restriction is that you cannot charge an excessive amount to restrict access to the sources.

Second, DSL has another GPL controversy today. DSL had switched from using flua, lua with a set of FLTK bindings, to murgalua (which has FLTK bindings and a lot of other stuff thrown in) several months back. Unfortunately, murgalua requires the full runtime of lua and fltk and libz and sqlite and luafs and who-knows-what-else to be run all at once even if it's for a simple lua non-GUI task.

So DSL refactored the bindings so lua can be run on its own and FLTK and all the other bindings can be used independently as-needed -- something much more suitable for the needs of DSL and its users.

John Murga is the author of murgalua. He licensed his bindings under GPL even though the bulk of the parts of his runtime -- lua, etc. -- are under much more permissive licenses like LGPL, MIT-X, and BSD. Today he's posted a notice on his forum that DSL has transgressed the GPL and linked to another post he made on his forum in which he said (or suggests) he won't condone or support the re-use of his bindings apart from the runtime. He reiterated that

Either way I am unhappy with MY CODE being used in this way (if that counts for anything).

The GPL gives users freedom to change the code to suit their own needs so long as redistribution follows the rest of the GPL's terms. If Mr Murga has ANY objection to others using his bindings under the license he used, he should re-license it in manner which will give him as much control over how others use it as he wants. The more permissive licenses used by lua, sqlite, etc., certainly allow that.

Both issues relate to similar problems. First, most users and developers wrongly associate GPL with things it doesn't mean. It doesn't mean zero-cost, it means sources must be made available (directly or via normal computer-readable media) when distribution occurs. Second, it doesn't give anyone the right to determine how it's used on anyone else's computer. THAT IS WHAT THE FOUR FREEDOMS ARE ALL ABOUT -- the right to see and change the code as well as the right to redistribute it as it was received or as it has been changed. So, to Mr Murga I say: no, your feelings REALLY DON'T matter.

I'm not a fan of the GPL. I've written plenty of places here and in other places why I object to it. Some of its demands are onerous, such as the requirements that downstream derivatives maintain their own source trees for unmodified binaries, for requiring a hypothetical user who compiles an app for his friend or relative to make the sources available, etc. I've found that it appeals to two groups of people: one is the zealot who sees software as a political (or even religious) issue and the other is the uninformed who makes the false link between GPL and "free as in beer" with nary a thought about the actual meaning of the license. Sometimes the line is crossed and you have a hybrid -- you can find many instances of that in the Linux/FOSS advocacy with lists of reasons that give very little about "you can see the sources" (even if you don't know wtf it all means) and a whole lot about how your only costs for Linux is the CDs onto which you burn a zillion distros to try and find one that works for you.

These recent spats have only served to reinforce my objections to the GPL.

Son bastati un mese e mezzo di sviluppo e due Release Candidate (l’ultima 10 giorni fa) per far decidere ai programmatori di Damn Small Linux il bump alla versione 4.4.

Rispetto all’ultimo rilascio stabile 4.3 sono numerosi i cambiamenti, la maggior parte dei quali riguardanti l’aspetto grafico ed i file di configurazione di sistema. Aggiunto un nuovo visualizzatore di file Diff (fldiff) ed una nuova libreria per i programmi C/C++ (Fltk) mentre rsync risulta ora aggiornato alla versione 3.0.2.

Maggiori informazioni sui cambiamenti apportati in Damn Small Linux 4.4 sono disponibili dal changelog ufficiale.

[via: distrowatch.com || ossblog.it]

Damn Small es un pequeño live-cd de tan sólo 50 megas que nació como un experimento para comprobar cuantos paquetes cabían en un espacio reducido con el entorno más amigable posible. Su funcionamiento es óptimo, basado en knoppix (debian), usa fluxbox como entorno gráfico y es especialmente recomendable para arrancarlo en cualquier pc, por viejo o flojo que sea. Posibilita tanto su utilización desde cd, como su instalación en un lápiz usb o en el disco duro.

¿Qué novedades incorpora en la versión candidata? Las listas de cambios de las versión 4.4.

Para descarga: mirrors.

Enlace descarga directa: dsl-.4.4.

Damn Small Linux 4.4

• Arrancar desde un CD de formato tarjeta a un entorno independiente de su disco duro.
• Arrancar desde una memoria USB.
• Arrancar "dentro" de un S.O. anfitrión (por ejemplo, puede arrancarse dentro de Windows).
• Correr sin trabas desde una tarjeta Compact Flash IDE mediante un método llamado "instalación frugal".
• Transformarse en una distribución Debian tradicional tras instalarse en un disco duro.
• Mantener funcionando aceptablemente rápido un 486DX con 16MB de RAM.
• Correr completo desde memoria en tan poco como 128MB.
• Crecer modularmente.

¿Y qué tiene de nuevo esta versión? Principalmente mejoras en desempeño. Los detalles de cambios están aquí.

ZenWalk 5.2

ZenWalk es una mini-distribución de GNU/Linux, también para equipos de baja capacidad aunque es una distro no tan limitada como DSL.

¿Qué hay de nuevo? La versión 5.2 incluye casi 500 cambios a los paquetes de software, principalmente de actualizaciones y correcciones de errores. Los cambios más notables son la actualización del kernel de Linux y una nueva versión del escritorio Xfce. La lista completa de cambios está aquí.

Más información en:

• Damn Small Linux (DSL) en español
• www.zenwalk.org

Processador MMX 233 MHz / Memória RAM 64 Mb
HD IDE 3 Gb / Placas de Rede e Vídeo Offboard
Drive Gravador de CD LG 48x16x48 / Drive de Disquete
Mouse serial / Teclado DIMM / Monitor LG StudioWorks 15"
Sistema Operacional rodando: Damn Small Linux

Primeiro, foi feita uma tentativa de formatação com o Xubuntu 6.10, porém o instalador travou várias vezes, então concluímos que tenha sido por insuficiência de memória RAM. Pesquisamos um outro sistema mais adequado ao hardware e encontramos o Damn Small Linux 4.3.

"Damn Small Linux é um pequeno LiveCD com apenas 50MB que nasceu de um experimento para comprovar quantos pacotes cabiam em um espaço reduzido e com uma aparência mais amigável possível.

Seu funcionamento é ótimo, baseado em knoppix, (debian), usa fluxbox como gerenciador gráfico e é especialmente recomendado para ser usado em qualquer PC, por mais velho e desprovido de hardware que seja.

Possibilita tanto sua utilização direto do cd, como também sua instalação em um pendrive ou HD." (http://comunidade-linuxnarede.eti.br/modules/news/article.php?storyid=344)

Com 5 gabinetes vazios sob um madeirite, montamos uma mesa para esse computador. É uma ótima solução enquanto não tivermos uma mesa mais apropriada, pois os gabinetes estão em bom estado de uso, somente aguardando novas peças chegarem.
Se vc ficou tentando entender como é que fizemos uma mesa com 5 gabinetes e não 4, vou explicar. Foram 2 colunas paralelas, feitas com 2 gabinetes cada. Entre eles, ao fundo, colocamos um gabinete daqueles horizontais de bem antigamente (Itautec, que usava o disquetão, coisa de museu) para dar maior estabilidade à base da mesa. Desmontar este gabinete foi uma experiência inesquecível. O tamanho da placa-mãe, além do peso do disco rígido e da fonte...

(...)

Fizemos também um panfleto para a campanha de doações de computadores usados (Veja a imagem grande clicando aqui)

Vejam mais fotos no meu álbum de Metareciclagem no Orkut:
Meu álbum de Metareciclagem no Orkut

Envie um email: metarec.ba@gmail.com

Deixe um comentário aqui.

I'm writing this in response to every review or distro comparison that includes Damn Small Linux in the mix and tries to compare something intended to fit on a small CD or to be run off a small (64MB+!) USB thumbdrive to distros that require gobs of RAM, fast processors, and infinite storage space. I've addressed others here and on their own blogs or in the comments sections of their reviews about why that totally misses the boat.

I've also become more than a little impatient with those whose expectations include resource-hungry aesthetics, whether in the form of transparent menus by default, xft blurring of fonts, and (perhaps my biggest peeve) wallpaper that approaches measurement in fractional or whole MB increments rather than kilobytes.

One thing I've learned is that not many people share the same sense of aesthetics. Accordingly, it's perhaps the least valid standard upon which to judge Linux distributions -- or any operating system. As I've written plenty of times now, it can be ugly and rock stable or be beautiful and too buggy to use. Most reviews and comparisons now, unfortunately, are nothing more than beauty contests. Some reviewers are open and candid that they're more concerned about default themes than how distros do things differently, how that affects users, and why it should matter. Instead, though, we get inane bleating about GTK themes, something looking "old" or "like it was FLTK or something" or a bunch of whining about wallpaper. It begs the question, "Do you use your multicore computer as an expensive digital picture frame or do you run apps on it to make your life easier?"

I'm also addressing an issue that recurs too often in the DSL community. Some users, no matter how well they mean, make requests or suggestions for default features and settings with little thought about how they will affect low-end users.

The Difference Isn't the Aesthetics

Everything has its beauty but not everyone sees it.
- Confucius

My primary attraction to Damn Small Linux, the BSDs, and distributions like Slackware and Gentoo has been the freedom and flexibility afforded to end users with respect to defaults. With the exception of DSL, these allow users to start with a "clean slate" and configure systems per unique needs.

DSL is unique among these I just listed, and among other distros. It offers a "total package" with respect to utility, but it does so without any of the intense demands of multicore processors and RAM measured in gigs instead of megs expected of users who choose to try modern, updated Linux distros. In 50MB, users are given tools to handle many tasks -- word processing, spreadsheets, graphics, audio, browsing, file management, networking, and can even be used as a server. Its default apps may not be the latest, splashiest tools for their respective tasks but that's not the idea in DSL. DSL's approach is to pack the most utility in its 50MB ISO as possible. And it does. Some distros fail to do in 700MB what DSL achieves in 50 -- and those require hard drive installation to use, while DSL can be run from the CD, from USB, or be installed to hard drive.

There are no pretenses in DSL, no slavish fads to follow, no blind acceptance of bleeding edge applications. There's also less concern about default transparent menus, which use more resources than opaque, than there is about trimming default resource use.

That's not to say that DSL ignores aesthetics. I've written themes for jwm so that users can change to something else if they don't like a default. Others have added wallpapers. There are GTK theme packages and switchers in MyDSL. There's even been changes to use FLTK themes to improve appearances over default grey. There may be room for improvement, but not at the expense of additional RAM use or extra CPU cycles to carry it out.

Is It Beauty or Is It Bullshit?

Beauty is the purgation of superfluities.
- Michelangelo

But that's not where DSL will ever try to distinguish itself. It can't. It's goal isn't to win beauty contests at the expense of increasing resource demands or at the price of losing utility. Every other distro does that. They help make older computers more and more obsolete with each new release, despite all the Linux advocacy to the contrary. I've written about that many times here, even calling out the FSF for their blatant hypocrisy about it.

I'm to blame for the idea of not using a wallpaper in DSL 4.4 (and hopefully beyond). I made the suggestion on the grounds that we could reduce an initial hit on resources. I don't apologize for that, either. That's always been a goal of DSL and I just saw a way that we could continue to make DSL useful on older computers. I initially didn't even want to use a floating emblem atop the gradient -- just a plain gradient. I knew that would go over less well than the whole concept of no wallpaper (let alone a solid color) so I included it.

I wanted it to be clean and simple, just like DSL is supposed to be. Clear, pleasant colors with adequate contrasts and shades that weren't an affront to the senses. I also wanted it to be flexible. Accordingly, the jwm theme is a mild gradient which I've described previously as "alloy" and which should fit with a wide variety of wallpapers if users choose to use one. Finally, I also wanted it to be legible for our users who have vision problems. I hadn't taken that as seriously as I should've until one user noted he was color blind -- so I greyscaled screenshots until I found something that would be legible and not force changes of themes just to be usable.

I'd braced myself for the worst and was surprised by some of the initial feedback. It was positive. One even called it the best look for DSL yet. I was relieved, but I knew not everyone would appreciate the results. Let alone the goals that precipitated moving away from wallpaper in the first place.

Simply put: I was trying to create a pleasant, usable interface with the least possible demands. I was starting to think I may have succeeded in that difficult balancing act. Uh, no.

User Demands versus Resource Demands

Beauty is no quality in things themselves:
it exists merely in the mind which contemplates them.
- David Hume

Aesthetics is entirely subjective. When it's paramount, it puts utility behind beauty. This is why many reviews of DSL (and certain Slackware-based distros and anything intended to be used as easily by older hardware as for newer) totally miss the boat. It's also something that some within the community don't seem get. DSL isn't alone in this - Slackware 12.1 no longer has the default LILO interface. Now it has a flashy Slackware logo. And I heard in one podcast that more Slackware branding could be on the way.

One complaint about the new DSL look came yesterday along with three proposed wallpapers, the smallest of which was a quarter megabyte in size and none of which impressed me more than the default gradient. I quickly repeated the reason for the gradient and also vented my spleen about this obsession with making everything match. I edited my comments and used some hyperbole about that which caused someone else to call me a prick.

Consideration was given to make the jwm theme as generic as possible so it wouldn't be problematic if users wanted to change wallpapers or select other colors for their gradients. I think users are probably more inclined to leave jwm themes alone and change the background.

I don't care if someone wants to call me a sexist prick for trying to get resource use down or for my dishing out harsh criticism (I didn't call anyone a "prom queen" -- that was a simile -- and I toned down my allusion to socks matching berets so give me a little credit for leaving out underwear and bra references; that was about a peculiar obsession with making everything match) when it comes to things that increase demands for default themes. I also asked for better, prettier solutions if they had them and could keep default resource use down.

DSL isn't competing for users who want spiraling graphics. DSL should be usable by people with at least a 486 and 16MB of RAM. Many users are still getting life out of earlier Pentiums with DSL. All of that precludes bloated wallpaper which slows down other DSL users. And not all of them are going to like the bloated wallpaper more than they like the gradient. At least the gradient doesn't unnecessarily eat up their available RAM.

The absence of flaw in beauty is itself a flaw.
- Havelock Ellis

The reason I wanted a clean, simple, generic interface was to reduce demands: on RAM use, on CPU cycles to redraw windows (DSL uses pseudo-transparent aterms by default), on users who choose to use other wallpapers or colors, and so users would be less compelled to have to change other things. If the jwm theme works with color scheme X and Y, then that's one less thing for a user to have to mess with. The same goes for other parts of the system (which I didn't have a hand in choosing).

This is where my comments about interior decorators and getting gussied up like prom queens came from. I don't see coordination between different parts of the whole as either a good or bad thing. The more generic things are, the easier it all is to manage. If something obviously clashes, I agree it's problematic. But defaults shouldn't be so tied together that changing one thing necessitates changing everything. That might work in something as bloated as Gnome or KDE.

I don't think either RC of DSL 4.4 is aesthetically-challenged. I think the bigger issues for it and subsequent 2.4 versions are going to be practical matters. Like what can or can't be upgraded, and why. Not to mention fixing things and -- one of my favorite parts about DSL -- reducing default demands even further, if possible.

Beauty is Fleeting, Hardware Can Outlast Your Good Looks

Being thought of as "a beautiful woman" has spared me nothing in life. No heartache, no trouble. Beauty is essentially meaningless.
- Halle Berry

DSL's niche in the Linux ecosystem is unique. Reviewers need to understand that before comparing it and its mix of default apps to what comes in other distros. Users already appreciate the unique qualities of DSL.

DSL isn't a slave to fashion. Reviewers need to understand that and judge it on its own merits instead of compare it to every other distro that's abandoned the machines DSL continues to support. Users, no matter how well-intentioned, need to understand they have tools included in the base to change whatever they don't like about default appearances. Everyone needs to recognize that others have different tastes.

Everyone also has different goals. The thing that distinguishes DSL isn't its default themes (not even the ones I edited) and wallpapers but its core philosophy, its utility and pragmatism, and its ability to be used by computers whether they have little or lots of resources.

Even in a world of spinning window managers and multicore processors, some of us continue to see DSL's simple philosophy of pragmatism, accessibility, and usefulness as a thing of beauty. No matter how it looks.

• running gnu screen within X (kdrive from DSL)
• using vifm by itself and within vim
• elinks most of the time, Opera when I need graphics
• snownews for rss
• mplayer (no gui) to stream audio

This isn't my first time to enjoy the combination of vifm and screen. What's so special about it? By issuing the ":screen" command within vifm, it will open new "windows" in the current screen session. Click on a text file (or any file without an association in the configuration file) and it opens in vim or whichever editor you choose. Set up a MIME association and it opens the app in another screen window.

The "mplayer" tab was opened when I selected the highlighted PLS stream.

The best part of all of this: I was only using 53MB of RAM to run all the normal processes (default DSL 2.4.31 kernel, modules, basic services, sshd, etc.), X, dwm, screen, vifm, zsh, elinks (two tabs open including gmail), naim, and a high-definition audio stream.

mplayer is the pig, but it's still consuming a lot less resources than XMMS does. I can trim it all down further by running my custom kernel but I need to reinstall it (packaged from last hard drive install).

The console apps I selected give me just about every feature I could need -- except support for images and video (just haven't gotten that far with it yet). I compiled elinks with bittorrent and ftp. I also downloaded spidermonkey to add javascript support, so I'll have that when I recompile. Now I just need a better-developed console spreadsheet and I'm set. I'm not setting all this up for this particular computer. It's for something I'm taking on vacation this summer; I'll have more details shortly (and explanations for why it needs to use as little power as possible).

Even though it appears vifm is no longer being developed, it works very well if you're used to vi/vim commands. It's certainly not as feature-rich as midnight commander or other file managers. It does most ordinary file management jobs very well. It can launch executables or open them in vim (or your choice of editor). It can be set up with MIME types as noted above. It can sort files by all the usual variables like name, size, date, etc. It can even accept shell commands. About the only thing I don't like about it is the default white border and panel dividing the two panes (which can be set to one pane as well), which I set to black. Unfortunately, it only has eight-color support. I may see what I can do to get 256 (I need to update my version of screen.uci in MyDSL for that, too).

I like the combination of vim, vifm, and screen so much I compiled it as one UCI for personal use in DSL. I'm also considering using those as the basis of the user interface for my next DSL remaster, which is on hold until I get a chance to play with the next major version of DSL (2.6-based "tiny core") since that may serve my purposes even better than stripping X apps from the current base.

I initially went with a flat four color theme: black, green (for active), red (for inactive), and yellow (for defaults without active/inactive settings). The only exception was in the menu because I wanted yellow as its default. I'd post the actual theme but I just told you what it is. For the record, I don't have my tray set up with a menu button because I primarily use dwm and, in jwm I also use keybindings (and dmenu) to launch apps. That's why my tray looks like that.

This is the first attempt. Click for full 800x600 (these are small enough that I left them full scale).

I could see right away I needed to more clearly differentiate the pager (far left) and the task list. So I changed those just a bit and used some yellow in it as well. This is the second try.

I only switched colors for active so green is the background instead of foreground and used colors for the tray to designate active and inactive. In the last shot, the first virtual desktop is blacked out because my aterm setting is full screen (and black is inactive).

I know it's not eye candy; it's more like insulin. It's an antidote for clutter. It's the solution to worrying more about appearances than to actually using your computer to get stuff done.

It looks better (or should I say more console-like? I think that looks better than  wallpaper in many cases) with the tray on autohide, but that's my opinion. The only changes I'd consider making would be switching the default/inactive colors on the menu so it's not black on black while it's against the background. Maybe yellow on red and the active set to green on black? I don't know if it would hurt or help my "mock transparency" to add a darker grey (grey22?) in the gradient for the title bars. I really don't care.

I'm resigned that most people won't care for this kind of look or appreciate its simplicity when so many distros put more emphasis on appearances, transparency, etc., over stability and even long term support. The sad part about that is, it uses up resources without much benefit other than an "improvement" to aesthetics (which is very subjective). This is the only approach we can take with jwm to get a transparency-like effect with the window decorations, but it won't matter to users and reviewers whose demands include being able to see bits of 500kb wallpaper through the decorations and menus. Most reviews are -- and will continue to be -- little more than "beauty contests" rather than reviews of distros for their merits, stability, security, strengths, weaknesses, quirks, etc.

EDIT: I set up my dwm config.h with the same kind of color scheme. (My background was already black.)
EDIT2: And here's how my gtk theme looks (it's still a work in progress) to match this whole austere look.
EDIT3: I lightened up the backgrounds of the dwm bar. Note from pasting in commands (in vim, :r! ssh -V) that SSL has been updated to fix two vulnerabilities. Much more on this tomorrow or Sunday (always recompile OpenSSH against the new OpenSSL if you update SSL). Also, note that vim 7.1 has now crossed over the 300 patch level this week. I'll also have more about this shortly.

New this time around, we get a major improvement in the lua scripting which includes a refactoring of the FLTK bindings (thanks Florian) so that only the parts required by each script run at any given time load regardless of what the script does or needs (in contrast, murgalua offers a kitchen sink approach that requires a full runtime of lua, fltk, lua socket, lua filesystem, zlib, sqlite, etc., regardless of what any particular script needs). This change frees up FLTK for C/C++ programming in addition to lua (and possibly other languages?); it also necessitated rewrites of the DSL lua scripts. There's also an upgrade of rsync, the search engines for firefox have been restored, new system font (artwiz smoothansi), lower resource gradient (using xsri -- darkslategrey and looks like grey60ish, lightened from what I submitted) for background, and a few other tweaks.

I call the jwm theme "DSL light industrial." It's just a light alloy-like scheme that's easy on the eyes and shouldn't cause much strain. The background fits in with what I said I would do both here and in the Productive Linux podcast blog if I had my way: no wallpaper (though I did write I'd use a single color). There's just a small (6kb) emblem floating over the xsri gradient. It makes a noticeable difference on resource consumption compared to using a wallpaper.

My only change to the system defaults in this pic is changing the font for torsmo to smoothansi to match the rest of the system. I've submitted that the gtk theme can also be updated to match the colors in the theme a little more closely as well as to use smoothansi. My suggestion to use it as the font in Firefox' menus and popups by changing userChrome might not be as warmly accepted (maybe I should post screenshots of my browser with it and without).

Hát... az az igazság hogy a mai napról nem sok mindent tudok elmondani. Tegnap mondjuk jó volt, este megittam pár sört, aztán utána még codolni akartam, de rájöttem hogy az úgy nem fog menni :D Aztán most reggel elég korán felkeltem, már 9-kor :O Nem is nagyon tudtam magammal mit kezdeni, Kicsim is aludt vagy fél 1-ig kb :) Aztán csak b*sztam a rezet itt a gép előtt... Délután még ki akartam próbálni, hogy az OpenSolaris-ra fel tudom-e tenni a Kopetét, meg a webcamom... de nem sikeredett. Asszem hogy nem az én asztalom a java desktop-os szarság :D Még próbálkoztam a DSL-lel (Damn Small Linux) is, hogy be tudom-e állítani a repóját hogy menjen is... de nem sikerült, úgyhogy azt is feladtam. Pedig az elképzelés az nem rossz, 40 megát eszik össz-vissz a RAM-ból, ami iszonyat kevés :D
Aztán a mai napom az ennyiben ki is fulladt... tanulnom is kellett volna rendesen, de sajnos az sem jött össze :( Na nem baj, holnap meg holnapután ha törik ha szakad, már egész nap tanulni fogok. Muszály lesz a beszámolón átmennem kedden, és akkor szerdán le is zavarom gyorsan a vizsgát is... remélem sikerül :):)
Most meg éppen mindjárt lecsukódnak a szemeim. De még nem megyek aludni... ez az egyetlen este most egy jódarabig, amikor Cicámmal tudunk rendesen beszélgetni anélkül hogy az órát kéne néznie akármelyikünknek is hogy "te atya Isten, elalszok :O"... úgyhogy most ezt ki akarom én is használni :)

Na, jóccakát mindenkinek, Byez ^.^

Ma egy kicsit más témában írnék, és igazából nem megoldásokat mondanék, hanem kérdéseket fogalmaznék meg, hátha ráakadnak a blogomra olyanok akik tudják a választ, vagy használják is akár ezeket.
Tehát, az első amivel fontos dolgom volt, az a DSL (Damn Small Linux).
Ezzel nem egy gondom van. Szeretném, hogyha ezt elolvassa az a bizonyos valaki, aki ért hozzá, akkor elküldené nekem e-mail-ben nekem a teljes telepítést, és a következő kérdésekre a választ: hogyan lehet az apt-restore-t megcsinálni benne. Tudom, hülyén hangzik, de nem tudom milyen billentyűkombinációval lehet xtermben menteni amikor szerkeszt az ember valamit :) Illetve, hogy a webcam működik-e rajta? Ez a másik kérdésem. Mert hogyha megy akkor jó, ha nem, akkor milyen driverek lennének rá?
Következő rendszer amivel nagyon játszik az elmém, az az OpenSolaris. Ezzel kapcsolatban is nem egy kérdésem lenne.
Először is, ha valaki ért hozzá, írja le nekem legyen szíves, hogy hogyan lehetséges abban a rendszerben? :) Másik, ami még fontosabb talán, hogy hogyan lehet a webcamot abban is használni. Logitech Quickcam Express-t akarnék használni rajta, de olyat nem nagyon akar sajnos felismerni. Tehát hogyha valaki tudja rá a drivert, írja meg nekem honnan és hogyan lehet megszerezni.
Egyenlőre ennyi lenne. Remélem, akadnak majd olyanok, akik tudnak segíteni ebben a kérdésben :) Temrészetesen, akik megírják nekem a válaszokat, amikor közlöm őket a blogban, a nevükkel együtt fogom ezt tenni.

Előre is köszönöm mindenkinek, akik segítenek.
Sziasztok!

• Arrancar desde un CD de formato tarjeta a un entorno independiente de su disco duro.
• Arrancar desde una memoria USB.
• Arrancar *dentro* de un S.O. anfitrión (por ejemplo, puede arrancarse dentro de Windows).
• Correr sin trabas desde una tarjeta Compact Flash IDE mediante un método que llamamos "instalación frugal".
• Transformarse en una distribución Debian tradicional tras instalarse en un disco duro.
• Mantener funcionando aceptablemente rápido un 486DX con 16MB de RAM.
• Correr completo desde memoria en tan poco como 128MB (¡te asombrarás de lo rápido que es tu ordenador realmente!).
• Crecer modularmente -- DSL es altamente extensible sin necesidad de personalización.

DSL nació como un experimento: ¿cuántas aplicaciones de escritorio cabrían en un CD autoarrancable de 50MB? En un principio era sólo una herramienta/divertimento personal, pero con el tiempo creció hasta convertirse en un proyecto comunitario con cientos de horas de desarrollo en detalles como un sistema local/remoto de instalación de aplicaciones completamente automatizado o un sistema de copia y restauración de seguridad muy versátil que puede emplearse con cualquier medio escribible, sea disco duro, disquete o un dispositivo USB.

DSL posee un entorno de escritorio practicamente completo, junto a muchas utilidades de línea de comandos. Las aplicaciones son elegidas por su mejor balance entre funcionalidad, tamaño y velocidad. DSL puede también directamente desde un CD autoarrancable funcionar como servidor SSH/FTP/HTTPD. En nuestra cruzada por ahorrar espacio y a la vez tener un escritorio completamente funcional, hemos creado varias herramientas administrativas que son rápidas a la par que fáciles de usar.

¿Qué contiene DSL?

XMMS (MP3, CDs de música y videos MPEG), Cliente FTP, Navegadores Dillo, links y FireFox, hoja de cálculo, gestor de correo Sylpheed, corrección ortográfica (de momento inglés), procesador de texto, editores de texto Beaver, Vim y Nano [clon de Pico], edición y visualizado de imágenes (Xpaint y xzgv), Xpdf (Visor de PDFs), emelFM (gestor de archivos), Naim (AIM, ICQ, IRC), VNCviewer, Rdesktop, servidor y cliente de SSH/SCP, cliente DHCP, PPP, PPPoE (ADSL), servidor web, calculadora, soporte de impresora genérica o GhostScript, NFS, manejador de ventanas FluxBox, juegos, herramientas de monitorización del sistema, utilidades de línea de comandos, soporte USB, PCMCIA y parcial inalámbrico.

Web: http://www.damnsmalllinux.org/