Archive for the ‘linux’ Category

Fun with Precompiled Binaries (Or, Why I Recompile So Many Things)

July 27, 2011

I often note that I find things in binary packages that irritate me. Sometimes it’s too much nonsense compiled in so that installation of a small utility requires massive dependencies to install. This means not just a lot of extra stuff taking up hard drive space, it means more packages that get updated and other inconveniences.

Sometimes I also notice little things that make me go hmmm. Today I was playing around with mocp, a curses-based server-client music program. There’s not yet a package for *el6 so I compiled it myself. I thought I’d hit up all the right things so that it would stream and play all common music codecs. Everything seemed fine with mp3, ogg-vorbis, and even an ASX stream. Then I tried an AAC stream and found I had more work to do.

No big deal. I searched to find out what I was missing. I found a suggestion that I should build it –without-aac (overriding the internal AAC decoder) so that AAC would be handled by the ffmpeg plugin. I tried that and it didn’t work.

So I decided to double check my ffmpeg version, which was installed from rpmforge. While it had faad and faac support enabled, I found something else that seemed a bit weird.

I know, I know. It’ll still work on other CPUs but it’s optimized for Intel Atom. Why? I’m not using this on my dual thread netbook, it’s on a dual core laptop. It could’ve (should’ve?) been compiled with -mtune=generic.

It’s stuff like this that drives me nuts and makes me start recompiling things or install something that I can optimize for my own use if the packaging (indiscriminately!) includes optimizations that suit particular hardware rather than generic. I thought that was the idea of pre-packaging binaries: so they could be used by a wide variety of common users.

For what it’s worth, the spec says:

Description: FFmpeg is a very fast video and audio converter. It can also grab
           : from a live audio/video source.
           : The command line interface is designed to be intuitive, in the
           : sense that ffmpeg tries to figure out all the parameters, when
           : possible. You have usually to give only the target bitrate you
           : want. FFmpeg can also convert from any sample rate to any other,
           : and resize video on the fly with a high quality polyphase filter.
           :
           : Available rpmbuild rebuild options :
           : --without : lame vorbis theora faad faac gsm xvid x264 a52dec
           : altivec

So it has faad/faac enabled. Should’ve worked, no?

I checked version information against what I have on my older laptop running Sabayon (with dwm). No extra c flags noted in the ffmpeg -version output but I’ll double-check that tomorrow:

ffmpeg version 0.7.1, Copyright (c) 2000-2011 the FFmpeg developers
  built on Jun 30 2011 12:51:22 with gcc 4.5.2
  configuration: --prefix=/usr --libdir=/usr/lib --shlibdir=/usr/lib \
  --mandir=/usr/share/man --enable-shared --cc=i686-pc-linux-gnu-gcc

I still didn’t get AAC working on m *el6 laptop with the ffmpeg-devel package from rpmforge, or even when disabling it and building against the -devel packages for faad/faac. I’ll mess with it again tomorrow.

By the way, with all the -devel packages installed and all the compiling I end up doing, I wonder why I don’t just install something that has the relevant headers (Slackware) or that I can optimize and set up the right way — my way — from the start (Gentoo). Days like this, I wonder if the multi-year support of the EL clones is really all it’s cracked up to be. In fairness, though, we’re talking about a third-party repository and not stuff in the base which seems to be put together with more care and diligence. Maybe my lesson is to build my own packages for things not provided in the CentOS/SL repositories; that would solve not only this kind of issue but conflicts when a third-party repository has a more recent version number of something provided in the base.

Advertisements

Banned from DW Again

February 21, 2011

I dared to respond this morning to yet another asinine “review” (using that word loosely) at a certain website. The comments I left were removed in quick order. Yes, Laddy, that was I who made the original #34 and one BTW comment. The comments were removed and my IP blocked. I’ve revisited the site several times since via proxy. Heh.

Here’s what was censored.

First, I took issue with the whole focus on aesthetics in reviewing a stable-oriented distro like Debian (the unfortunate subject of the misguided review). I pointed out that such distros like Debian-stable, RHEL, even Tiny Core, and so on, won’t measure up on the basis of aesthetics because that’s not their goal. They focus instead on providing a secure, stable environment that a user can install once and rest assured that he or she won’t have tons of crap breaking in an insane pursuit of having the latest version numbers of everything.

I pointed out that reviews might be more useful if they focused on other issues, like security and stability: How easy is it to keep patched? How easy is it to upgrade? Will future major, or even minor, upgrades require completely reinstalling? My follow up noted that my update from Debian Lenny to Squeeze required only changing one word in my sources.list. Does that simplicity count for anything when reviewing a distro? I also noted that the reviewer’s comparison of Debian to its prodigal offspring ignores the fact that many of them still piggyback on Debian for security and other patches. That counts, too.

The crappy little review was more about aesthetics than anything. AS USUAL. The reviewer dissed Debian for having a graphical installer that looked a bit old — like RHEL’s from ten years ago. I wanted to know how many times a user interacts with a freaking graphical INSTALLER anyway. OMFG. How dare they set up their system via a series of pages instead of a one-click installer without any options.

I closed by asking what specific hardware problems, other than lack of an available wireless driver, the reviewer had issues with. She also mentioned problems booting, though not with this particular release. What problem(s) did she have and how did she resolve them? I pointed out that it’s not fair to blame the distro if the reviewer manually edited her computer’s existing GRUB/LILO and screwed up. Those were just BS things mentioned as a reason for not recommending Debian.

Seriously, why the thin skin over there? My critique of the review was civil and fair. It was also spot on.

That’s something you people could learn from me. Your loss.

Judging Books by Their Covers – Follow Up to This Morning’s Post About Distrowatch Reviews

April 26, 2010

People are funny critters. You can dress up an inferior product in fancy wrappers and most people will insist it’s superior to something in a more plain wrapper.

That’s true if your Linux distro is being reviewed by Distrowatch. What counts more than performance and stability there is how it’s dressed up. If your default theme and iconset is eye-catching, you get a positive review. You get brownie points, too, if you set up all kinds of RAM-clogging shit to give users desktop “effects” by default.

That’s also true of your website. I noted earlier the review of Scientific Linux remarked about the, umm, spartan features of the project’s website. The reviewer wrote that the SL “website is a simple display of black and white in a Wiki style” and “is fairly quiet, almost sparse in its presentation.”

I’m not sure what the reviewer was expecting. It’s clear and concise. As it’s not targeted to a wide audience (meaning hobbyists), there’s no wacky appeals or enticements. There also aren’t any unreasonable roadmaps attaching the release cycle to some other project. The design of the site reflects the kind of user it seeks to attract — no BS, just the facts.

I wondered to myself, How does SL’s website compare to others? I’m quite familiar with a few projects and some of them haven’t changed their websites in years. Some are also “simple” and “black and white.” Even “sparse” seems to fit.

How has the austerity of the Slackware site hurt it? Patrick and Company churn out a fine distro and focus on stability. The site is clear and easy to use. Only recently (version 13) have they plagued the distro itself with a logo, and that was for LILO splash. It went away when I installed and configured GRUB. It remains the oldest continually developed Linux distro.

Some of us, though, don’t see things the same way others do. Beauty is in the eye of the beholder. I wrote extensively about this regarding DSL a few years ago; not only that, but I took a ton of crap for daring to find ways to trim resource demands while trying to spiff up the aesthetics (to no avail: for every positive comment, there seemed to be three negative ones because it wasn’t in the same class as other distros). No two people see things the same way. Where one review complains about simplistic icons or an absence of them, people like me see less system overhead consumed by default — something which is much more beautiful than colorful icons anyway. Likewise when it comes to wobbly windows and other gimmicks which do nothing to enhance getting work done on a computer.

Thing is, so much is focused on catching others’ eyes that too much substance gets lost in the shuffle. Like I wrote at the start of this, most people are drawn to how something is wrapped up — whether it’s default Gnome/KDE themes or even how projects set up their websites. Is that really the best way to judge books — by their covers?

I don’t think so. I still prefer to surf the web in elinks or w3m-mode (in emacs). All websites look similar when I do that. Scientific Linux…

…and Slackware…

…look an awful lot like Fedora…

…and Ubuntu…

…and even Distrowatch!

Links function the same way whether you’re in a graphical browser or a text browser. With a text browser, though, you can assess the content of the site a lot better. Substance always trumps style in elinks, lynx, w3m, et al.

Function and substance should always outweigh eye-candy, especially when the subject in question is an operating system. Developers should spend more time fixing their broken, buggy systems with bloated and improperly-patched and/or -compiled packages instead of trying to cover up the whole mess with fancy graphics and gimmicks like wobbly windows (the same is true for dressing up websites). Users, whose senses of aesthetics are often as dubious as developers’, can dress their desktops to suit their own tastes. Developers should know the difference and be able to overlook aesthetics to get to how systems perform and why they perform the way they do. To concentrate or be swayed by icons or themes or version numbers (barring some serious, legitimate issue in which things are going unpatched — a security issue rather than a version issue) is to miss the forest for the trees and to misguide readers about the virtues of what’s being reviewed.

Books shouldn’t be judged by their covers. Neither should Linux distros.

Distrowatch Reviews Suck A$$

April 26, 2010

It’s sad to see how far the standards at Distrowatch have fallen. I didn’t always agree with Caitlyn Martin (particularly her views for Vector and against Slackware — I realize new users want to be able to install without reading any documentation but Slackware isn’t difficult, burdensome, or too nerdy to install) when her reviews would appear at Distrowatch, but at least her standards went beyond appearances, themes, and other trivialities.

Today’s review abortion doesn’t disappoint if your primary criterion for a Linux distribution is style rather than substance. The target is Scientific Linux, which I’ve recently written a good bit about because I was testing it out on my Aspire One.

The reviewer started with some prattle about his presumptions about (against, rather) SL and that it’s a niche/specialty distro. That couldn’t be further from reality. It’s simply recompiled from RHEL sources — much like CentOS is — but with more of an emphasis on packages relevant to research. That’s to be expected as it’s the product of FermiLab, CERN, various universities, etc., where end users are less concerned with games, default themes, and so on, and more on applications relevant to their work.

The reviewer then notes SL’s “website is a simple display of black and white in a Wiki style” and “is fairly quiet, almost sparse in its presentation.” Yes, and what’s wrong with that? It’s very straightforward and informative. It’s not put together to entertain prospective users or “reviewers” who are drawn to aesthetics over performance.

It doesn’t take long for the reviewer to fall into his own tedious comfort zone in how he rates distros:

The theme is really where the system shows its roots and its age. The distribution is, after all, sitting on a 3-year old platform. Some may find this an unpleasant trip into the past while others will probably enjoy the comfort of familiarity.

In fact, he later in the review adds, “The version of GNOME which comes with Scientific is 2.16, which is a few years old. This may be good or bad, depending on one’s point of view.” Why the hell would it be bad if it works, doesn’t crash, doesn’t hog up too many resources just to make stuff wobble, etc.? This whole issue is moot to enterprise users — remember, the release and support cycles for RHEL (and its clones) are measured in years rather than months. This distro can be used on newer hardware but is still a valid and working solution for hardware being used at the time of the 5.0 release — as well as older hardware. Most distros consign older hardware to the scrap heap, which is why businesses and researchers don’t use them in production. Why the hell would they want to use something which makes 2010 presumptions (multicore CPUs with GB of RAM) for 2005 hardware (which may not even have 512MB of RAM)?

The reviewer’s mindless obsession about default themes is a common thread in the reviews he’s had at Distrowatch. He doesn’t seem to appreciate the distinctions between an enterprise-grade distro and all the other bullshit he’s attracted to because of “pretty” themes with bleeding-edge versions of every possible piece of software. Never mind those other distros are buggy as hell and unsuitable for use in environments where RHEL, CentOS, SLED, and SL are going to be used.

He then notes the live CD’s installer “may seem primitive compared to other installers” — even though the installer for the real CD set uses anaconda, the same installer used by RHEL, CentOS, etc. Maybe if he’d read the site instead of criticizing its lack of entertainment value he’d know the difference and maybe chosen to do a conventional install rather than use the live CD (though I’m quite content and satisfied with the live CD’s installer myself).

The review drones on to note that a default user account — which happens to be sluser — is set up. The reviewer didn’t note that the tools are in place from the live CD/install to manage multiple user accounts, including removing sluser. Instead, he criticized the version numbers of the applications: “Most of the applications are fairly standard, though their version numbers tend to lag a bit behind the latest and greatest.”

What this dumbass doesn’t realize is that those “version numbers” include patch level numbers. So that kernel 2.6.18.xxxx has had many improvements backported from official versions >2.6.18. The same is true of many of the applications included. In addition to security patches, there are legitimate feature patches. Does that mean everything is bleeding edge? No. But people who need an enterprise-grade operating system aren’t looking for bleeding edge — they only want stability and security. An enterprise distro — SL/CentOS/RHEL/SLED — delivers stability and security without pretenses or without delusions that the most recent version of anything is necessarily “the greatest” version of it.

The review continues with high praise for inclusion of YUMEX (a graphical front-end to yum; I’m not going to be as judgmental as I should be about preference of using such things over command line tools), Flash, and various audio codecs. He regrets certain video codecs aren’t included. The reviewer also left out the fact that anything else a user may want can often be found in third-party repositories; one of the benefits of being (mostly) binary-compatible with RHEL 5.5 is that there are alternative repositories that will (mostly) work in CentOS and SL just as they do in RHEL. Perhaps he just didn’t know any better. Regardless, that’s something which other users might consider noteworthy. (The qualification of “mostly” is warranted since packages between repositories can be built with different dependencies which will break when using too many repositories. Two can be too many if their bases and dependencies are unmatched. There are ways to manage conflicts via yum. The point remains that users can set up additional repositories for SL and thereby access a wider selection of software packages.)

He winds down his review by not being able to find many flaws aside from its age:

The only drawback, so far as I can see, is that some of their key components are getting out of date. Usually this isn’t a problem, except perhaps, when using software like OpenOffice.org and Firefox. Those projects which put out major releases once a year or more will appear dated.

This ignores the fact that relevant patches are given for security and to fix issues as warranted. That inlcudes OOo and Firefox. Enterprise users aren’t going to care that the distro in question — RHEL, CentOS, SL — is tied to release cycles for various projects the way, for example, Ubuntu is tied to Gnome’s release cycle. To enterprise users, the difference isn’t measured in release numbers of software included in a base or repository but rather in the stability of the whole paradigm. Using such a benchmark, Ubuntu is not even comparable. That explains why so few businesses, researchers, government units, etc., use Ubuntu but do use RHEL, SLED, or the clones of those.

I noted in one of my own posts about SL, “I’ve gone back and forth between OOo 2.x and 3.x recently and, aside from formatting changes in 3.x that don’t work when backing down to 2.x, I don’t think enough of 3.x to demand that whatever distro I use have it available.” I really don’t think most users would even know any difference, particularly since few users will avail themselves of any features contained in the newer versions. What’s left is being on the cutting edge for the sake of being on the cutting edge.

That’s fine for some people. But I think Linux reviews shouldn’t try to fit every distro in that same basket. A reviewer should actually understand the underlying paradigms of a distro and judge according to those rather than to “it’s too old” or “it’s not pretty enough” sham criteria. It’s a disservice to readers — not to mention to the developers working on their distros — to lump them all together and, by way of flawed benchmarks, make them rise or fall according to aesthetics and/or version numbers.

Distrowatch’s reviews are utterly predictable because they focus only on those two elements. If you use a flashy theme and enable wobbly windows by default, you’re likely to get a good review. If your distro requires more than clicking buttons to do things, isn’t terribly flashy, or is targeted at stability rather than being on the cutting edge of application release cycles, you’re going to be compared to the distros with paradigms 180-degrees from your own.

I saw that happen with DSL. I’ve seen it happen with Slackware, TinyCore, and OpenBSD. Now I see it with CentOS and SL, too.

Sadly, Distrowatch is among the worst at pulling that crap and reviewing every distro according to one slovenly-conceived set of criteria. Reviewers whose focus is on style rather than substance don’t seem to have much substance themselves.

UPDATE: Surprised at the traffic this post is generating since it hasn’t been linked anywhere (by me anyway). Yes, it’s the same hare-brained reviewer mentioned in other posts in my Scientific Linux and OpenBSD categories regarding GnoBSD who complained that the BSDs don’t automount every freaking piece of storage you insert in your USB ports by default and that the process in BSD is  difficult. I responded to that in another post here. I don’t know why any Linux distros include man pages since the vast majority of users — and especially distro reviewers — obviously can’t bother reading them.

In any event, I noted only two pieces of software in the SL base (from the CD) that I’d update: emacs and hplip. The reason I’d update hplip is so my printer would work. The reasons for updating emacs are probably more selfish: I don’t want to track down packages like org-mode and others which are now included in emacs and so I wouldn’t have to change anything in my .emacs file. But like I wrote in one of my SL-related posts, I’d be just as happy using emacs 21.x (again). Either way would take some effort on my part — either I compile emacs (trivial) or I hunt down the things I currently have set up in my .emacs and set it all up again (less trivial but acceptable). Big freaking deal.

Finally, I need to clarify that SL’s repositories — and the install CDs — have a wide variety of software beyond scientific/research kinds of applications and third-party repos aren’t necessary to use SL as a “normal” distro. You don’t have to enable third-party repositories to have a usable system. The software contained in the live CD (Gnome version) is adequate for most users with an adequate mix of commonly used software including browser, e-mail client (thunderbird), file manager, media player, and so on.

UPDATE 2: I meant to add above that SL (and RHEL and clones) is hardly alone in using “old” release numbers. I’m currently using my laptop at home which has Debian Lenny installed on it. My OOo version is almost as ancient as the one used in SL. Not complaining — WorksForMe (and odds are it would work for everyone else whose not too obsessed with version numbers to actually get stuff done).

Blimey! I don’t see an expiration date on it! Maybe the dipshits at Distrowatch will give Debian a crummy review because its stable branch doesn’t have the “latest and greatest” version numbers like Fedora or Ubuntu. Whatever. At least it works and the developers aren’t pissing people off by little things like moving buttons around. The result is that Debian-stable is stable while Ubuntu seldom is. That’s the price users have to pay for being wedded to bleeding edge software and the ever banal paradigm that places style over substance. And for relying on Distrowatch reviews for accurate and fair reviews.

DSL and ext4 filesystem

April 18, 2010

Did that title get your attention?

Just a quick note based on something I’ve been seeing a lot more of lately in search engine hits to this blog. I’m getting daily hits for at least three of the four words in the title of this entry. Some days it’s just one or two. Some days it’s quite a bit more.

First and foremost, Damn Small Linux is dead. It has not been updated in over a year despite the founder’s claim in December of 2008 that he was looking into how he was going to move forward with development. Second, I don’t think ext4 is even supported in kernel 2.4. That means you’ll more than likely need to upgrade kernels (even if 2.4 does have support for ext4 now). If you have to upgrade to a 2.6 kernel, you’re probably still screwed because it’s not as simple as swapping out kernels. That’s probably more true for something like DSL which really needs some freshening up in the base anyway.

I don’t know if people are looking to mount existing ext4 partitions as ext3 under DSL or if they want to use ext4 as a filesystem for DSL. In my opinion, either way is foolish. DSL had very limited filesystem support in the base and beyond a few filesystem tools extensions. Regardless, you’re probably better off looking for more sensible alternatives that wouldn’t require the work DSL would just to handle ext4 partitions.

Update 20100130: Musical Hard Drives, NetBSD, Scientific Linux

January 30, 2010

I’d alluded last weekend that I’d installed NetBSD on a spare hard drive in my new workstation. That drive was the last (I think) OpenBSD 4.3 install I had before I had to go care for family in 2008. Hard to remember anymore, I only know that when I ran last it showed my last reboot was a couple days after I returned last year. Anyway, I’d already installed Scientific Linux 5.4 on another spare hard drive I put in the workstation and set up separate partitions on it. My only nitpick about SL’s installer on the live CD version is that it doesn’t allow many options as far as partitioning or filesystems but that’s not a big deal to set up afterward. (Note: the full install/net install CDs use anaconda.)

I switched drives around so my old OpenBSD 4.3 one would be master. Once I logged in (after finally remembering my root password and changing my user password), I looked around and saw a few things I wanted to make sure I backed up before using that drive for something else. I added entries to my fstab for the other drive so I could copy them to my user account on it (that drive is eventually going into another computer; sorry about image quality but I didn’t have the computer networked when I set up).

I recently said some unkind things about the reviewer of a NetBSD-based live CD on a certain website because he complained that it didn’t automatically mount things for him. The BSDs — excluding possibly desktop-oriented projects based on any of the BSDs — don’t enable such things by default. I also recall in a simulated install of KDE packages one time that directions flew up my screen about enabling various daemons to get it all working if so desired. It’s just a different perspective on things. The BSDs are true to their Unix roots, and Linux distros by and large are true to their “GNU’s Not Unix” (heavy emphasis on “not”) roots. Let me be a little more constructive than I was at that website and show how easy this stuff is (especially if you bother to read the documentation).

I installed NetBSD from CD. The installation took a few minutes. Granted, it’s not like installing the average Linux distro — it doesn’t have a graphical installer, it doesn’t have all kinds of apps to install. It’s pretty basic, but you add what you want on top of it instead of whatever some developer decides to include. It’s fast, it’s easy (RTM), painless. It takes a bit of time to configure and set up but it’s a blank slate and you’ll know exactly what’s going on because you’re the one turning all the stuff on that you want to be on.

I wanted to get my files I copied over to the SL54 drive from the OpenBSD install so I decided to set up /etc/fstab to include my SL54 drive. The first command I ran was dmesg | grep wd1 to make sure the drive was detected as wd1 (the next step would tell you the same thing but I usually look at dmesg first). Then I did disklabel wd1 to get information (man disklabel if you want specific options) about the partitions on that drive.

Once I had that, I could edit fstab accordingly and/or mount the partition I need. In this case, the partitions I wanted were g and i and I needed to make directories (mkdir /mnt/wd1{g,i}) for them and then mount them. Then I was able to get my stuff I’d copied from my old OpenBSD install as well as the few things I’ve had time to get on the other SL54 drive. Hardly a hassle.

I haven’t had time to do anything else with that drive (meaning with NetBSD) yet because things are hectic with family and work. Funny how that works out sometimes — get a new computer, fiddle around with a couple of hard drives, and then have to get back to them in a week or two or three (I’ve only been using SL54 on it). For what it’s worth, I’m very pleased with Scientific Linux 5.4, which is compiled from RHEL5 sources. I’ll write a review of it soon — and probably before I get back to setting up NetBSD.

Microsoft Profits Stun World, Still Year of Linux Something or Another?

January 28, 2010

Microsoft posted a 60% increase in profits in the final quarter of last year over the same period a year ago. This was on record revenue and due in large part to strong sales of Windows 7.

No word yet if certain geniuses still think Steve Ballmer needs to leave the company.

Meanwhile, SJVN has declared 2010 the Year of the Linux Desktop Tablet GPS Some Fucking Device. Dude is like a damn Energizer bunny rabbit when it comes to the year or future of Linux. I see I beat his comparison of Apple’s new iFad to the iPod Touch by about five hours. Niiiice!

Freedom, Security, and Lacking Credibility

January 22, 2010

This is in response to something on another site.

Just a quick note to the whiny little fucktard who wanted to lecture me on another site about credibility: screw you.

Every time you asked a question or made a point, I gave a rational and coherent explanation. That includes my own example of why someone wouldn’t necessarily want to automatically run a server despite installing such software. That includes the issue of blind trust via social engineering that could lead someone to install something which unknowingly could present an issue with respect to something on a USB stick “automagically” starting without your knowledge or consent or interaction. Etc.

Oh, but it’s Linux! No fucking worries here. Ever!

That site has become something of a joke, especially the distro reviews (where did Caitlyn go?!). I pointed out that BSDs are not Linux only to get a response from the author about “old ways” as if some isolated KDE-oriented sub-project supersedes the one on which it’s based. You know, as if an exception overshadows the norm. Last time I checked, not one of the three major BSDs sets up automounting by default (and why the fuck should they? certainly not to match the Linux world by starting extraneous processes by default). That “last time” was yesterday when I installed NetBSD 5.0.1 on my new workstation. Works the same as it always has: insert USB stick, console messages (haven’t set up X yet) show me it’s there, “disklabel  /dev/point” shows me what partitions are available on it, then it’s straightforward to mount it and/or add entries in /etc/fstab. Duhhh. But probably not so straightforward if you expect it to work like Linux Windows without ever reading any documentation. Just burn the image, boot it, and wonder why you have to set up something because some developer didn’t do it for you.

By the way, the “Linux way” the author prattled about in his review used to be the “BSD way”: users were given control of what gets mounted and when rather than developers taking it upon themselves to dumb everything down so Windows converts would feel more at home. The “Linux way” is an anti-Unix way, it’s really the Windows way. And it’s apparently a flaw if a reviewer has to ever RTFM to learn that he has to manually add extraneous filesystems to his computer. Let alone manually mount something in the first place.

Unix isn’t Windows. I loathe those who demand making Unix more like Windows. It won’t attract more users. It hasn’t thus far. All it does is piss off people who have to go undo things that shouldn’t be done in the first place for a wide variety of reasons (yes, fucktard, including security — no matter how remote the risks might be, as I pointed out at least twice).

Auto-mounting is not a “feature.” I accept many users may indeed want it — we’re talking lowest common denominator and that’s going to be a lot who don’t bother or want to RTFM. That doesn’t mean it should be configured without user interaction of some sort.

If Linux and open source is ultimately about freedom, then stop forcing users to accept myriad running services in the background until they realize they have a lot of bullshit to undo and instead offer them opportunities to start what they want/need at install. Some distros do this, but most don’t. Isn’t it telling that the distros most popular among Windows users and converts give less freedom at install than Windows itself does? And isn’t just as telling that the Linux distros and BSDs that want the end user to have the most freedom and flexibility are the ones that give users a blank slate and tools upon which to build what they want/need and also seem to have an eye on things like stability and security?

But never mind my lone opinion. As the aforementioned fucktard suggested, nobody can take me seriously. I lack credibility because I think users should decide when things start or mount or are added to any system rather than a developer taking such liberties. Go read the lame reviews, pat the author on his buttocks, and wonder why more distros aren’t just like Windows — or wet your pants over the ones that do take all the decisions out of your hands… while you probably write snotty things about Microsoft for doing that very thing. Putz.

AA1 + madwifi-hal + WPA = FAIL

August 27, 2009

I’ve started another video but need to edit it together and this time there will be voice-over (oh dear). For now, here’s a couple screenshots to show that the problem isn’t going away with madwifi-hal. Happened a couple hours ago. See the “stream” aterm listed on my tray? That’s mplayer with a stream. It disappeared right after I took this screenshot. And the page I was trying to load in Opera wouldn’t.

screenshot_0827085133

The first thing I did was attempt to ping out. No luck. Then I looked to see if dmesg had something revealing, and it did.

screenshot_0827085903

I rebooted into TinyCore and immediately checked to see if the card was detected. I was pretty sure it would be just like the timeouts with ath5k and that I wouldn’t even appear to have a wireless card. Being right all the time is more a curse to me than to everyone else around me. Believe it or not.

screenshot_0827090157

I went ahead and ran my script to connect to my home AP. No surprises. Can’t connect with what’s not there. Or what’s not recognized.

Movie version later. I’ll try to keep it rated no worse than PG-13.

(edited mildly)

20090823 Update: AA1, Linux Security, TinyCore, Etc.

August 23, 2009

Quick personal follow up to my previous post about the latest, and probably most extensive yet detected, vulnerability in the Linux kernel.

I’ve been using my own kernel under what used to be CrunchBang. I can’t blacklist certain modules (e. g., bluetooth and IRDA) because I built them into the kernel rather than as modules. Yuck. Back to using the big-ass kernel from the repository if I’m going to use Linux. At least if I’m going to use my ex-CrunchBang install (it’s no longer even close to being what it was originally — from the window manager to the applications to my own kernel and so on).

I haven’t even booted into Linux since last week when my wireless crapped out under Linux again — I’ve had a busy week and this next one will be even more hectic. Right now, I’m not sure if I’ll bother upgrading again because I’m completely fed up with losing wireless and not being able to get it back without rebooting several times. As I noted, the crash and resulting videos came as I was making a screencast explaining why I dislike binary-based distros and their packaging and why I was more likely going to start using TinyCore more often.

Problem is, the same thing occurred one time under TinyCore. The ath5k time-out thing is not a distro problem. It’s a problem somewhere between the kernel/module, possibly WPA, and possibly a couple other things. So I have more than a reason or two to reduce my use of Linux on my AA1. I’m most likely reclaiming the larger partition I have set up for /home under CrunchBang for use under Windows (probably as an encrypted partition) and then using my 5GB partition for {Tiny,Micro}Core.

I’ve settled on another laptop and should have it next week. It’s not new — I don’t think I’ll ever again buy anything new enough that running Linux will be such a pain in the ass as it’s been with the AA1. The more bleeding edge the hardware, the more quirks and utterly stupid bullshit there will be with getting its glorious open source drivers to function properly and in some sort of stable manner. I checked all the specs to make sure Linux will have better support for the next laptop than I have on my AA1 now.

Right now I’m debating between Slackware (13 is almost ready) and CentOS 5.3, both of which have modern-enough kernels to support the hardware in the laptop. The reasons I’d install Slackware are for its lengthy support cycles and so I don’t have to download miscellaneous headers to (re-)compile anything. The reason for CentOS is to have an enterprise-grade distro with enterprise-grade support cycles (as in seven years). After all, I have to use this for my work. I can’t afford to randomly lose wireless (especially if it requires several reboots to get it functioning again) or to have to deal with freezing up when disconnecting the laptop from a projector.

I’m open-minded beyond those two distros. Even source-based since I’m going to have a few days around Labor Day weekend where I can leave it to compile all day long and let it catch on fire or something.

Back to the security issue affecting eight years’ worth of Linux kernels. Is {Tiny,Micro}Core a better solution for problems like this particular vulnerability? In some ways, it may be. It doesn’t come with a full set of modules. You have to install things separately because the whole concept is more modular. The kernel is read-only and in RAM. If someone were able to pwn at the kernel level, you can reboot into a fresh environment because the base system isn’t writable.

The counter to all that is, the more persistency you have for your installation the more vulnerable you are. Most of your configuration files are stored either in /opt or /home, which are read-write. Depending which extensions you use, you may have the same kind of exposure you’d have under any other distro.

And, most importantly, the weakest link in security is almost always the user. You can’t underestimate the problem users cause from clicking on links to opening things to setting up files so that anyone (aka “world” in Unix terms) can write or execute them. Some people ignore permissions altogether or set them up for the sake of convenience — such as other small/live distros that run only as root. I’m not saying that {Tiny,Micro}Core is inherently safer with its use of sudo (I wish more users would accept a default scheme which sets a random password so even running off the live CD or USB would require entering a password before mounting and erasing a drive, etc.).

So add TinyCore to the list with Slackware and CentOS. That may be the fastest way to get it up and running anyway. And TinyCore may be the last remaining Linux distro on my AA1 whether I run Linux on it again or not.