Archive for the ‘bsd’ Category

Snobbery + Ignorance = Linux Advocacy

March 8, 2009

I’m not big on snobbery, especially when it’s packaged with an unhealthy dose of ignorance. I think that’s one of the reasons why I’ve always been put off by the lists put out by advocates of Linux — seems more often than not the lists contain things you can do in Windows, and often much more easily. To the Kool-Aid guzzling, true-believing advocate who gets a priapism when he sees a penguin, Windows is some maimed and dysfunctional computing ecosystem adopted through laziness and it, its creators in Redmond, and its users are to be mocked at all times. Never mind that Windows is every bit as capable of doing everything they say it can’t or doesn’t do, or that the applications they use in Linux also run in Windows. Linux advocacy suggests it’s contending against FUD when, in fact, it’s based entirely on FUD.

Linux advocacy is fundamentalism. The heretics and infidels continue to buy PCs with Windows licenses, so the jihad continues. And along with it is all the bullshit snobbery that “I can do this but you can’t.”

Oh really? 

The latest victim of my wrath example is Andrew Gregory at TechRadar, which is a site which bills itself as “deep into technology.” I was curious when I saw a feed truncated down to “Hack your Aspire One…” so I clicked it and saw the ellipse hid “Linux netbook interface.”


Oh joy. Not only do we get to see how easy it is to change appearances of the interface, we get a healthy dose of “can’t do this in Windows” bullshit. But you actually can, it just takes a little more effort because most Windows users use computers rather than cum all over themselves from playing with eye candy.

This article would be bad enough if it were just a how-to. Unfortunately, it includes fucking retarded crap about neighbors from Vista Manor asking questions about their Linux-based netbook after an asinine statement about “They just want something that works, and when they try [Linux on netbooks], they like it.” If it works, why are they asking you?

Right, it just works. Like when I ordered my Aspire One, the internal mic didn’t work in the Linpus model but it worked in XP; or how the multi-card reader worked in XP but not Linux; how suspend and hibernate worked flawlessly in XP but had some serious issues in Linux; how the XP model worked perfectly with external monitors and projectors but the Linux model was rather crippled to say the least; etc. Guess which model I ordered? Yep, the one that just works: XP.

Don’t give me that fucking bullshit that “Linux just works.” If it had, I wouldn’t be using XP on an Aspire One right now. The few problems the XP models had, such as issues with the Atheros wifi (which thankfully haven’t affected me), pale in comparison to the crippled-from-the-factory woes of those who bought Linux versions of the AA1. I don’t know why Acer would ship non-functional hardware or choose it without appropriate drivers, nor do I understand why people would buy it. Guess that’s reason #24 “why Linux rocks and Windoze sucks” — you can see the source and write your own fucking driver. Riiiight.

And if people really want Linux, how the hell do you explain the higher return rates for Linux netbooks or how Windows XP has so thoroughly eclipsed Linux on netbooks sold? I’ll have another entry shortly on that latter point. Suffice for now, XP models now account for 90% of US netbook sales. There is no momentum for  Linux on desktops or netbooks; no, sunshine, there’s tremendous momentum away from it with fewer and fewer Linux models being offered in large markets like the US and UK. Just as I wrote last summer would happen as the niche matures. That won’t stop the Kool-Aid crowd from toasting Tux.

Speaking of which, Mr Gregory eases the reader into the complexities of Xfce settings with the calming assurance that “you’re not a newbie: you’re a Linux guru in the making.” WTF? Can one really get the Platinum Certified Linux Guru (TM) card just by tweaking a few window manager controls now? I think they give you that for misspelling “windoze” or “micro$haft” and other signs you’re sipping the Kool-Aid with them.

Mr Gregory suggests, “If you’re used to Windows you’ll probably be surprised by the extent to which you can change the way the system works, but that’s part of what makes Linux so powerful.” If Mr Gregory could pull his head out of  his arse long enough to use Windows, he might be surprised to the extent to which Windows can be changed. It might also surprise Mr Gregory that what he’s configuring isn’t even Linux. It’s a friggin’ window manager that runs on the X Window System and, accordingly, isn’t a Linux hack.

So this is his lame idea of power? Changing an interface so it’s more aesthetically pleasing, which is a personal preference and has ZERO to do with how the system (Linux, GNU, or anything else) actually functions? (Another warning about upcoming posts: I’m going to add another video to my youtube account shortly — hopefully — to demonstrate at least another of many Linux advocacy fallacies about resource use. “How the system works” goes far beyond tweaking user interfaces.)

I’ve been working with Linux for over a decade — servers, embedded, desktop, you name it. Before that, real Unix; currently, I’m using BSDs more than Linux distros. Prior to getting an Aspire One (XP model), I hadn’t done very much work with Windows since the late 90s with NT 4.01 (server and workstation). We have another XP computer, but I’ve rarely used it in the six years or so we’ve had it; it’s slated to become a file server in the near future. My beloved has a Vista laptop which she loves (she hates all Unix-like operating systems), but I’ve only used it a few times. But one of the things I’ve always appreciated about Windows is that it’s scalable and flexible and configurable — and very easily so despite the mindless FUD from little wankers who think Windows is preconfigured and you’re stuck with its defaults.

I know a thing or two about tweaking interfaces — I don’t consider it hacking at all because it’s so bloody fucking superficial. It doesn’t affect productivity (sorry, Nathan, it really doesn’t). It can be a fun diversion, but that’s about it. 

One of the biggest sources of hits to this blog is searching related to themes (not to mention links from DSL for the same) because I posted quite a few for jwm. Why did I do that — because I have some sick predilection for gussied-up user interfaces? No! I did it to shut people up by showing:

  • aesthetics is a very personal and subject area;
  • accordingly, no single distro can please everyone;
  • window managers aren’t inherently “beautiful” or “ugly;”
  • any window manager can be configured to please any user, from colors to controls;
  • people who whine about user interfaces are the very people distros should avoid welcoming to their communities because they tend to value style above substance;
  • most distro reviews are about two things: aesthetics and the incessant dick measuring contest of versioning numbers (“this distro has foo 4.3, which is behind the times because that distro released the same day includes foo 4.4rc2”); and
  • it doesn’t matter whether a distro uses fluxbox, jwm, openbox, kde, gnome, e16 or e17, or whatever else because it can all be gussied up to look pretty much the same but they ultimately provide the same or similar functions.

I was fucking tired of reading in the DSL forums that jwm was ugly. Or that it presented a barrier to wider adoption. So I did a lot of those themes to at least open minds, if not to change them. Some had even balked at the move from fluxbox as the default window manager to jwm, as if that’s what DSL was all about. So I showed how to set it up so it looked and worked (no menu on taskbar, only on right click) like fluxbox. Etc. The window manager doesn’t define what’s  under the hood. Nor does the way it’s painted.

Computers are tools, machines. It’s how they perform that should count. Not how they look. Or, a big peeve, when people try to tell me how something “feels,” as in, “this feels more {stable,vanilla,____(fill in the freaking blank with nebulous drivel)}.” How does “stable” or “vanilla” feel? Compared to what benchmark? Short of crashing or stuff not running correctly, I don’t know what the average user would notice about stable/unstable. Vanilla? That’s usually ascribed to Slackware to denote that it’s not filled with patched binaries or marked up with logos like other distros.

Which was more important with DSL 4: that it marked  a paradigm shift from previous versions’ focus on applications to being more data-centric with MIME-type associations on the desktop and with the new file manager OR that it had a certain “look”?

Every fucking review I read either skimped over the nuts and bolts or mentioned a lot more about the paint job (while occasionally mentioning the aforementioned dick-measuring version numbers for everything, of course) than the change. I usually stop reading or listening to reviews as soon as default aesthetics come up — that tells me about the reviewers sense of aesthetics, not qualities about whatever’s being reviewed.

So the same useless goddamn bickering starts between Linux advocates about Windows. More Linux advocacy lies to crush.

I’ve played this game before, and I win it every fucking time. There was the asshole who said that Linux rocks because it has tools like cron and a shell like BASH. So I showed him a batch script that accomplished the same thing, and that it can be run from Scheduled Tasks. Then there was the fucking idiot who said that Linux was superior because of the wide selection of open source applications; he was left stammering when I showed him that they all — every single one of them — also ran on Windows. Or the blowhard who prattled about proprietary software while I helped him configure ndiswrapper so his blob could run in his pure and  unadulterated open source operating system (I politely nodded my head; he was paying me to set up his certified easy-to-run and free-as-in-beer-and-speech distro).

So now ya say Windows XP can’t be dressed up? Yeah, it’s XP. I can’t take credit for it, even though I have several of my own themes. I did the background myself — all 40.1kb of it. The theme itself is genuine Microsoft, available if you search for it (“signed embedded theme xp” seems to work), signed and all so it didn’t require any DLL hacking.


I need to throw in an image showing window decorations. Because we all know how important that “Piranha” look around all your windows is to getting things done.

Guess that’s what separates me from Linux advocates. I actually use my computer to get things done, whether it’s while using Windows, Linux, or one of the BSDs. I have digital picture frames for when I want to admire pretty stuff.

You know what, I think I’m like most people that way. Maybe that’s why Linux advocacy isn’t working.

Edit: Here’s the lowly window decorations for the embedded theme. Maybe not spiffy enough for l33T Xfce-tweaking Linux gurus, but it does clear up the lie that Windows can’t be themed apart from the classic or XP looks. Twats.


edit 2: Here’s Microsoft’s Zune theme (also signed — no dll hacking required — and available if you search for it) on my netbook, again with a quicky homemade background (I’ll tweak the colors later). Also edited content above.


Linux Audio versus Everything Else

October 4, 2008

I had a chance yesterday to read Linux Hater’s post about problems with Linux audio drivers and APIs. The post is about pulse audio’s inclusion in Fedora, which led to broken audio for many Fedora users. Like lemmings, other distros decided if it’s good enough for Fedora then it’s good enough for them. Tumbling dominoes…

The issue reminded me of problems I’ve had at various times with applications in Linux. Pulse audio is hardly alone in issues related to Linux audio. One of the things that’s caused me more trouble than it’s worth has been getting mplayer to play nice with ALSA. The mplayer front page says ALSA is supported so I didn’t know what the problem was:

A little background. I hadn’t bothered to use mplayer in Linux at all; I stuck with default apps — typically XMMS, xine, etc. — that shipped with the distros I used. I first started using mplayer in FreeBSD a couple years ago and grew to appreciate it. So much so that I decided to use it when I switched back to using DSL last year. I also installed it in a few other distros I tried on both laptop (before ditching multimedia altogether on it) and desktop.

It had always worked fine in FreeBSD — and also in OpenBSD (which has become my operating system of choice) — but it totally sucked in Linux, especially synching audio and video. I thought it was maybe due to the binary packaging of the distros on which I’d tried it. I decided to compile it myself and got the same wretched results. Then I wondered if my hardware was the problem, but I reinstalled my BSD hard drive and quickly knew that everything was fine in BSD. So I looked for help on the mplayer site to see what the problem was with using it in Linux.

One of the first things I looked at was the following section in the documentation:

Ahh, well, that first sentence certainly clears it all up: “Linux sound card drivers have compatibility problems.” No shit? I’d run into problems before with the OSS driver in DSL playing single-channel audio at double speed. I’d also noticed other anomalies — at least I thought they were anomalous — using ALSA in other distros. Not only that, the problems weren’t always isolated to mplayer. One of the reasons I wanted to use mplayer in DSL was because XMMS was butchering things.

So I had plenty of reason to take the mplayer developers at their word. Things that “just worked” in Solaris, Windows, and the BSDs could be a total abortion in Linux. Different drivers. Solaris and BSD have Sun audio, Linux doesn’t.

The next section notes that ALSA 0.5 has buggy OSS emulation and causes mplayer to crash. That’s not fun.

Yes, both of those documentation sections provide workarounds. They also explain the reasons why workarounds are needed: immature, buggy, and/or shoddily-written drivers and emulation layers. In short, the problem is on the kernel side and not the application side. I know the application “just works” in BSD; I also know it doesn’t in Linux, at least not as it’s supposed to (why should I have to maintain two sets of scripts, one of which only employs workarounds for buggy drivers, to use the same app?).

I’d presumed — quite wrongly — that Linux would have better audio support than the BSDs on the dual grounds that Linux development tends to be more cutting-edge than the BSDs and Linux has been promoted harder as a desktop system. Lesson learned.

the smarter solution

the smarter solution

This isn’t isolated to mplayer and pulse audio, offerings in which users may expect a little imperfection due to the ever-changing nature (or is it chaos?) of open source development. It also affects how things like Flash, which isn’t open source, operate within Linux. Many users fault Adobe for the unpredictable performance (i. e., crashing) of Linux Flash. The problem, which Adobe has pointed out, lies in the diversity of APIs (ALSA versus OSS, which ALSA has won as far as Adobe is concerned) and UI tools in the Linux universe — qt versus GTK+, etc. Things are much easier in a proprietary environment like Windows because the libraries and drivers are unified and homogeneous. Microsoft doesn’t have myriad distributions with unique configurations. What works right for one Linux distro often doesn’t work across the board — something which has been true for a lot of things beyond audio because there’s no standardization.

There are many things Linux does exceptionally well. Audio processing really isn’t one of them. This is one area in which the bazaar isn’t going to supplant the cathedral anytime soon. Where Windows users take audio performance for granted, Linux users take audio bugs for granted. It’s yet another reason I doubt Linux will make a significant dent in Microsoft’s desktop market share.

More Thoughts on Linux Security

August 20, 2008

One of the reasons I took strong exception to Linus Torvalds’ recent comments about security is because there’s no longer a separate kernel line for development, as there were in earlier versions with an odd numbered line (e.g., 2.3 and 2.5) for development and even for stable. For all intents and purposes, the 2.6 mainline is serving dual function for development and stable (though “stable” here is very much open to debate).

While this may be practical for many things, security isn’t one of them.

I added an image in the right side panel on this blog to keep track of security issues arising in the 2.6 kernel. These aren’t the “less important” issues like wonky drivers crashing, these are issues that lead to system compromise via local and/or remote vulnerability.

Don’t get me wrong — I do agree with Linus that all bugs are serious and merit consideration. Where he’s wrong is in his suggestion that OpenBSD’s coding paradigms ignore “less important” issues in the interest of security, as though those are separate issues. In OpenBSD, the primary focus is on doing things clearly and cleanly. If you do it right, you’re a lot less likely to need to revisit it because it opens holes to remote or local exploit or because it crashes (if it even works again).

This was evident recently with the effort by Reyk Floeter when (re)writing drivers to include newer hardware and assuring they don’t break backwards compatibility. The call went out to test his diffs on older hardware before sticking it into a release. That’s not primarily security-oriented, but it does demonstrate the differences between Linux’ and OpenBSD’s focuses. In Linux, such a driver would be thrown into a minor version and repeatedly patched for fuck-ups in subsequent versions; in OpenBSD, there’s a concerted effort to get it right the first time. Maybe Torvalds and the Linux 2.6 developers could learn a thing or two about not breaking stuff when adding new features or new drivers, masturbating monkeys or not.

While BSD development does have its ups and downs, those things are generally done distinctly from -release/-stable trees. The idea is for stability and security — not separately because each is in some measure a function of the other. So you don’t often see new drivers thrown in capriciously the way you see done in Linux. And that’s become even more startling with the move to simultaneous development/release in one kernel line.

For example, it’s increasingly common to get security advisories affecting kernel versions going back 8-10 releases like this one I got in my NVD feed:

CVE-2008-3276 (Kernel)
Integer overflow in the dccp_setsockopt_change function in net/dccp/proto.c in the Datagram Congestion Control Protocol (DCCP) subsystem in the Linux kernel 2.6.17-rc1 through allows remote attackers to cause a denial of service (panic) via a crafted integer value, related to Change L and Change R options without at least one byte in the dccpsf_val field.

So that affects (some) Linux users way back to 2006 to current. Linus deems it as trivial as any other bug. Maybe that’s why it’s a couple years old and present in so many kernel versions.

I think Linus can’t have it both ways. You can’t merge or run -development and -release in the same tree and expect it to be secure. When you add the mix of bits and pieces without much consistency between the myriad distros — except the crazy race to release versions of everything with the highest release number — you have a general climate of insecurity. The pace of Linux development and the tendency to use latest release versions is such that this is probably the tip of the iceberg with Linux insecurity.

I wrote on another blog the other day in a thread about Red Hat and their primary markets that a distro like Ubuntu doesn’t stand a chance in enterprise use because it’s too bleeding edge and too unstable for most businesses to take it seriously. I don’t think Ubuntu is alone in this regard (more about the consequences in a moment). One of the reasons Ubuntu and its offspring have stormed ahead of Debian is because a certain class of user, having a very different set of demands than enterprise users do, have further driven the momentum towards unstable app, insecure kernel, and buggy toolchain releases. This fills a niche that Debian-stable has left unfufilled (and rightly so!) and spawned parallels among other Linux distros (i.e., bleeding edge sub-distros) but it’s also ensuring that most Linux distros are unviable options for enterprise desktop use.

I think it’s a vicious cycle. Kernel development no longer has a -development tree but is all-in-one. The most popular distros increasingly are those with the latest releases — which is sometimes a good thing when an older version has security issues but not good if the latest (and untested) version has even more. There’s less and less sanity between releases as developers race to add features, which correlates (sometimes it seems exponentially) to new vulnerabilities. So my security feeds have mushroomed so that each day I have a mix of updates for various things.

Guess which distros have the most reports and updates. The ones that tend to focus on the bleeding edge. Including the Linux kernel. Yet these are the ones touted as “Windows killers” or somehow being appropriate for desktop adoption in enterprise. They clearly aren’t.

I’ve written several times why I still prefer to use the 2.4 kernel over 2.6. Not only is it smaller and lighter on resources (simplicity is a beautiful thing!), it’s been much more stable and secure. That’s in some degree because it benefited from having separate -dev trees (2.3, 2.5) and backports from 2.6. Yet there’s little active development in 2.4 anymore and most distros have totally abandoned it.

As long as Linus insists on running -development and -stable in the same tree, he should expect — and receive! (which is where the whole discussion about masturbating monkeys originated) — flack about security. As long as advisories are released on as frequent a basis as they are, and often without much disclosure when patches are released to signify their gravity, he should expect and receive complaints.

And as long as Linux (in the broader sense of distributions) is peddled with bleeding edge applications and utilities — and yes, also kernel versions — users shouldn’t wonder why companies are loath to run it on their desktops. You may not care if you’re pwned at home or if your kernel breaks support for some device that worked before you updated your kernel, but others who rely on computers to run their businesses do.

Security and other issues do matter, and they go hand in hand. Rather than suggesting others don’t get that, maybe Linus should practice what he preaches. Then he might applaud and even try to emulate OpenBSD development rather than attack it.

It’s Linux, Not GNU

August 19, 2008

I’m not a fan of using additional syllables where they’re not needed. I’m sick and bleeping tired of twits who insist I call every Linux distro “GNU/Linux.” Not every Linux distro uses GNU utilities. And many users’ experiences center on X, KDE, and other parts in userland that aren’t GNU or even GPL’ed.

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.

Miscellaneous Thoughts: DSL, OpenBSD, ‘core

August 6, 2008

This is fairly DSL-specific, but the generalities apply to other distros and operating systems. I was going to address something earlier today as a rambling, separate tangential issue apart from the broader issues (and a specific one) raised in a post about updating and upgrading the bits and pieces in DSL.

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.

Linus Equates Security Issues with Other Bugs

July 17, 2008

I saw a link in my feeds list this morning about Linus Torvalds’ “opinion on BSD.” The link went to a small article that concentrated on one small quote from a posting in which Linus dismissed the focus on security at the expense of other bugs.

Security people are often the black-and-white kind of people that I can’t stand. I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them.

Certainly interesting and colorful fodder for discussion on many levels. It’s lost, though, in the context of an important discussion about security.

It comes in a discussion about transparency of the way Linux developers handle security issues. The person to whom Linus was replying is a security specialist who releases the grsecurity patches and PaX, which is a kernel-level security implementation that restricts address space read-write access. In recent months, grsecurity has taken the position that Linux developers “hide” too much when releasing security updates; the concerns about issues in kernel 2.6 have led grsecurity to advise against using 2.6 if possible:

Due to Linux kernel developers continuing to silently fix exploitable bugs (in particular, trivially exploitable NULL ptr dereference bugs continue to be fixed without any mention of their security implications) we continue to suggest that the 2.6 kernels be avoided if possible.

It is not clear if the PaX Team will be able to continue supporting future versions of the 2.6 kernels, given their rapid rate of release and the incredible amount of work that goes into porting such a low-level enhancement to the kernel (especially now in view of the reworking of the i386/x86-64 trees). It may be necessary that grsecurity instead track the Ubuntu LTS kernel so that users can have a stable kernel with up-to-date security fixes. I will update this page when a final decision has been reached.

I think what’s more interesting — and disturbing — in the whole discussion isn’t Linus’ likening OpenBSD developers to “masturbating monkeys” but rather his view that all bugs are equal.

They aren’t.

While it may be a hassle to have quirky or erratic behavior because of a particular poorly-written module, it pales in comparison to vulnerabilities allowing remote or local system compromise. Speaking of comparisons, here’s the same historical data as in the two previous links for OpenBSD 3.x, OpenBSD 4.0, OpenBSD 4.1, and OpenBSD 4.2 — not exactly apples-to-apples since BSDs are a bit more than a kernel.

This isn’t immediately about protecting the kind of twats who play with desktop root-only distros like Puppy (separate issue aggravated by sloppy permissions abuse and the ridiculous belief that they’re invincible because they’re not using Windows) because such isn’t the most lucrative market for Linux. It could have grave consequences for enterprise users, including government agencies, with sensitive information to protect. You may not care if someone on your network can cause a DoS or if pictures of your kittens are pilfered, but you should care if your Social Security number or health information is easily accessible to those who shouldn’t be able to access it. It can very adversely affect your privacy and your future. And you should care if you run servers and they’ve been herded for criminal activities (such as to manage a “kennel” of a botnet of Puppy machines).

I accept and appreciate Linus’ point that all bugs are serious and that everyone who fixes a bug is deserving of praise. I disagree, though, that having eyes focused on security is a hindrance to getting “smaller” issues resolved. That certainly hasn’t been the experience in OpenBSD, whose developers have on more than one occasion been months ahead of the curve on all manner of bugs plaguing other operating systems (including Linux). OpenBSD’s strict coding practices are set in place specifically to make auditing code for all bugs easier.

Security is generally only as strong as the weakest link: the user. You can have a tight operating system like OpenBSD and open it all up so that it’s insecure. Or you can take an “insecure” OS and tighten it up so that it’s very safe. That’s why I roll my eyes when I read some gullible fool prating about being more secure with Linux than Windows, whether it’s a Puppy user (root only and usually running very vulnerable software) or the guy who boasted about running DSL in QEMU in Windows at Internet cafes or someone who doesn’t realize his fresh install of ___ (whatever distro) has several processes running that expose him to the world. That’s all what users do with what they’re given. Users can be responsible or irresponsible with it.

Developers can make it easier or more difficult to keep systems secure. It’s disconcerting that Linus would be so dismissive of the attention security gets. In that same thread, the person to whom he made the “masturbating monkeys” comment pointed out that other Linux developers have leveled the same complaints about the nature of security issues and the lack of disclosure in addressing them. He linked to one of Willy Tarreau’s (Tarreau is now the 2.4 maintainer) comments on LKML:

I don’t like obfuscation at all WRT security issues, it does far more
harm than good because it reduces the probability to get them picked
and fixed by users, maintainers, distro packagers, etc…

What’s really worse, being likened to “masturbating monkeys” or being called an obfuscator when it comes to the way security issues are handled? And what of all the Linux advocacy that mentions open source being inherently more secure because it’s “open”?

Maybe that’s not really a selling point after all.

(Edited to include Secunia links for comparison purposes.)

Trimming Initial Resource Drain in DSL

July 8, 2008

This is using the stock DSL 2.4.31 kernel, which is more bloated than my custom per-machine kernels.

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

Experimenting with mksh in DSL

July 6, 2008

I’ve been experimenting with shells (which will be the subject of my next productivity tip) while playing with DSL and dslcore. I’m looking for something that’s still responsive and “snappy” while providing more features than ash. Nothing against ash. It’s functional. Minimally functional.

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.

Thoughts on Freedom and Free Software

June 30, 2008

As I’ve written in various places, many users of open source are clueless when it comes to what various licenses are all about. Today, one hapless and muddleheaded chap decided to try and stir some shit and gave us prima facie evidence that users are confused over what “free software” — as defined by the Free Software Foundation — is really about.

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.

Vim 7.2 beta testing

June 26, 2008

After 330 patches for vim 7.1, Bram Moolenaar has posted an announcement inviting brave users to participate vim 7.2 beta testing. ” It’s quite stable, but we want to make sure it’s perfect.”

We’ll see. I decided to build via CVS on OpenBSD:

VIM – Vi IMproved 7.2a BETA (2008 Jun 24, compiled Jun 26 2008 18:31:41)
Included patches: 1