Archive for the ‘slackware’ Category

Setting Up Desktop – Part 1

March 15, 2010

I won’t be using my desktop as a desktop very often but I need to get it up and running. After wavering between what to do with it, I started installing something today at lunch. I hope to have it finished by this weekend. Or sooner. I left in the IDE drives because the big honking SATA drive is being used for NAS until I find a big-enough replacement for that (original crapped out).

Yeah, I know. Geez. I didn’t want to do any work at all. I was going to do a minimal Debian net install and only set up what I want. Then I thought I shouldn’t waste anymore time since I installed NetBSD (and Scientific Linux on the secondary drive). Then I was going to just set up MicroCore with only the things I need it to have, and then do more later when I have time. I think, though, that I want a bit more flexibility than Debian and I want to avoid some of the hacky-ness of {Tiny,Micro}Core and have a full set of utilities instead of busybox. As much as I love the latter, it’s just a bit Rube Goldberg in setting up the way I want it to work (not to mention I’d have to compile quite a few things that I want/need which aren’t in the repository); the remaining Linux partition on my AA1 is TinyCore — which I could only use with a USB wifi adapter anymore since I have zero confidence in the Linux ath5k driver with wpa_supplicant — and by the time I add GNU core utils, compile libarchive, etc., I’m pretty close to a Debian/Slackware minimal install anyway. Aside from portage’s bloat, I think I can keep this pretty lean (which is more a goal than a necessity). If I end up regretting Gentoo, I’ll likely install MicroCore and then screw with it more when (if) I can find more time. If it goes as smoothly as it has so far, I could end up putting it on my laptop, too (I’ve aborted several entries I started about excessive dependencies…).

My kernel is still compiling now. I won’t have much chance to mess with it until later tonight (after 24 at the earliest) and probably won’t touch it again until Wednesday. Hopefully I’ll have a “Part 2” up in a timely manner. Haha.

New-Old Laptop Update – 20091106

November 6, 2009

I looked at Distrowatch to see what was happening with various distros and downloaded a few ISOs. Among the candidates for my new-old laptop were Debian (Xfce/lxde), OpenBSD 4.6, Slackware 13, and Mandriva-One KDE 2010. I narrowed it down after a little thinking and only burned the images for Slackware and OpenBSD. I was open to looking at KDE on this and wish I could live with it, but I think I’ll be happier without it.

I decided to install Slackware 13 on my laptop yesterday afternoon and did some minor tweaking and configuration while I watched Survivor. I only burned the first two images because I didn’t want to use KDE, but I did go ahead and install Xfce as my only desktop. I may eventually change that to either ion3 or ratpoison even though I have a lot more room on my desktop now (17″). 

In addition to installing Adobe Flash and something else I won’t mention, I compiled the most recent release of GNU emacs. I also installed slapt-get and gslapt though I’ve yet to configure for any repository beyond the defaults. I still have to compile mew, and I need to install my office software (I think I can get away with IBM Lotus Symphony now, else I’ll have to install OOo). At some point, I’ll compile a custom kernel. The big one from Slackware has xfs, jfs, and all kinds of other things built in it that I don’t need and I’d like to reclaim every little bit of RAM I can.

I’ve yet to test things like my beloved Samsung S3 (libmtp is installed) to see what’s working or not. I did a fast basic configuration to get wifi working and moved a few things over via SSH; I do know that audio and X are working without any additional tweaking. Hopefully I’ll have time soon to turn this into my primary computer, whether or not I sell the Acer Aspire One.

No time frame for anything but the office suite and mew (ASAP) because I still am catching up on work from September and October. And no screen shots because it’s just the vanilla Xfce desktop with a solid blue background rather than the default (but quite tasteful, I’ll admit) striped Xfce wallpaper — like it should be without someone else’s muddled idea of how it should be branded with a distro name (or worse). That’s one of the great things about Slackware. That and the fact it has some of the best documentation available so setting it up is straightforward (second in all respects only to OpenBSD in my book).

More when I get time.

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.

Update: First Look Fedora 11 Live CD/USB, Misc Thoughts, cheese Sucks

June 10, 2009

Just a quick update before I get on a conference call. I’ve now booted both the Gnome and KDE versions of Fedora 11 Live from USB thanks to this unetbootin recommendation from scottro. That (old) thread at FedoraForum includes other helpful suggestions netbook users can try if they get bogged down with Fedora images. (Edit: I used unetbootin to successfully get a bootable USB stick with Fedora 11 from within Fedora 10; haven’t tried in Windows.)

Impressions? Well, the KDE version seems more stable than I recall from the prerelease image I ran a couple months back. I didn’t do much with it except look to see which apps it comes with — KOffice and other K-apps instead of OpenOffice. I then booted the Gnome version and it’s not too different from the Fedora 10 selections: AbiWord, evolution, cheese, totem, rhtythmbox, etc. That’s good because I don’t like radical changes. There’s still no hotplug support for the SD card reader (the one on the left side of the AA1 — haven’t tested the multi-card reader yet) unless you boot with a card inserted; I did see that the jmb* module loaded when I later inserted a card after (cardless) boot, it just doesn’t work yet. Beyond that, things seem to be working fairly well.

I was more inclined last night to run a KDE-based system over Gnome, but both are a bit more cumbersome and bloated than I really desire. It’s not so bad with a GB of RAM but I think people delude themselves that Linux is inherently better than Windows on low resource hardware — I think XP’s performance is still a lot better on this AA1 than Linux 2.6, especially with the chronic polling and shit that Gnome does (and KDE, too). That’s why I may go ahead and do a minimal install of something whether it’s Fedora or Debian or Slackware and then install more or less only what I want.

That last point, as it relates to default selections of software, reminds me of how many things I switched around in Fedora 10 on my AA1. I installed OpenOffice.org to replace AbiWord (because I use it at work and I needed Calc and Base as well), mplayer from rpmfusion in place of totem and cheese (see below), mksh (left bash installed in case any important scripts are full of bash-isms or call directly to /bin/bash), emelfm2 in place of whatever retarded file browser was the default, and a variety of small-ish apps I like to use. And bigger apps like Skype, which works very well now that the microphone is working.

This “cheese” webcam studio or booth thing fucking sucks. I read the FAQ and whatever else I could find to try and get it to record video without stuttering — or even minimal stuttering — but it was still so fucked up even with the smallest possible resolution I could set that I abandoned all hope for it. It basically freezes for a few seconds at the start of a capture and never really gets its shit completely together after that. Looks like the developers were more interested in useless shit like the nifty count down timer and “flash” thing that goes off (not to mention all the “effects”) than getting legitimate core features — like smooth video with properly synced audio — to work correctly. In a way, it’s typical of GNU/Gnome projects where people “major in minors” and the more important things never get finished or it’s a half-assed unfinished project that never fulfills its stated objective (see guile, which was supposed to take on TCL/TK but has languished in near obscurity behind other newer and more relevant languages).

Fortunately, there are things that work a lot better even at the higher resolutions the cam is capable of using. Here’s my alias for recording from the webcam using mplayer/mencoder.

alias record_stream='mencoder tv:// -tv \
driver=v4l2:width=320:height=240:device=/dev/video0:forceaudio:adevice=/dev/dsp \
-ovc lavc -oac twolame -lameopts cbr:br=64:mode=3 -o '

Change the encoders to suit what you have on your system. Type/tab complete the alias in a terminal and add a filename with format type (e. g., record_stream ~/Videos/today01.ogv) after record_stream and use ctrl-c to stop recording. Is it as fancy as something with buttons and can you see yourself? Nope (though it’s possible to run mencoder/mplayer so you can see what you’re recording). The captured video (and synced audio) is of much better quality than I was ever able to get from cheese.

(If you must see yourself before recording you can add an alias like “stream_test=’mplayer -tv driver=v4l2:fps=15 -vo xv tv://'” — you can also add whatever you need to listen to yourself if you need to test the sound, too, but that’s a system setting that you should set to work without constantly screwing around with it.)

I realize people drawn to Puppy and Ubuntu will throw up their hands and yell “WTF” at that, but script it through zenity or something if you think you need a fucking button to click just to do a simple task like capture video from your webcam. It’s easier my way. Really. And you can use whatever codecs you have installed — mpg, mp4, avi, mov, wmv, ogg, whatever.

Anyway, still not committing to Fedora 11 yet because there’s nothing in it that I don’t have working in 10 — just newer version numbers of the same stuff. The only reason I may install it sooner than later is because I want to reclaim space used in various other Linux partitions for one unified install, which kind of mitigates against installing from the live CD anyway because of the quirky requirement that / be ext4 and /boot be ext3, etc. Now that I’ve slept on it, I’m more convinced I want something a bit more conservative with a longer support cycle than Fedora offers. May have more time later to do something.

Still on my to-do list and coming soon: Updated DSL hard drive guide in PDF, even though DSL is pretty much dead. Could have it posted by the end of this weekend.

Delay and Site Update

May 27, 2009

Today was much more hectic than I anticipated so I didn’t get to finish the update on my resolved hardware issues under Linux on my AA1. I’ll try to finish that before this weekend. Most of the text is ready, need to take a couple screenshots, etc. I just need a little time to finish it and get it all together and uploaded. Not sure if I can get it posted by tomorrow, but should have some time Friday.

I also have a post coming soon that takes a look at how people are finding this blog. This interests me because I’ve not done much SEO or whoring this blog with links everywhere I visit. It also didn’t help that I was unable to blog much during those three or four months when I was caring for my family. I won’t give anything away here now, but some of your search terms make me snicker. (Hello to the person searching “dynebolic fucking help.” Nice to see I’m at the top of Google with those words.)

I also was asked a few months ago to do a printable version of the DSL hard drive page. Let me quickly address the future of DSL. DSL is dead; I don’t think John Andrews is going to be able to get it updated/freshened up or maintain development on his own. The old DSL ISOs don’t have expiration dates on them even though DSL is dead and I realize a lot of people continue to use DSL for older hardware. I’ll finish the printable page (PDF) with some revisions and additions by this weekend and get it linked. The PDF link will be on the right side of the home/front page (click on the lucky13 logo at at the top if your search engine brought you to a single entry) in addition to making an entry here and adding a link on the hard drive page itself.

Speaking of the right column, I see I have some broken feeds and links to clean up. I’ll get those straightened out in the coming days. Sorry, I didn’t get some of those messages in elinks.

Finally, I’ll probably have another post or two about what I’ve been doing while I consider running Fedora 11 when it’s released next week, Tiny Core, Slackware, or whatever.

Stay tuned…

UPDATE 28 May 2009 06:15 US/Central: I didn’t run this morning so I had some time to edit a few things. After going through the DSL hard drive guide to get it formatted for the PDF (the old USB stick with the org-mode version is FUBAR so I’m doing this in OpenOffice.org instead of emacs), I’ve decided to make some serious revisions. I’ll probably get rid of the online version rather than edit in the changes I make. May have more time later but probably will be tomorrow before I get everything finished and posted.

editing-hdig-01

UPDATE: 30 May 2009 12:16 US/Central: Delayed again due to other commitments (work, family, etc.) and wifi problems. Looking at ath5k-related problems and bug reports now to see if it’s software or hardware. This is from dmesg before it gives up:

ath5k phy0: gain calibration timeout (2412MHz)
ath5k phy0: unable to reset hardware: -11

The reason I’m concerned it’s hardware, even though lspci shows the device, is because I was unable to detect any wireless signals in either Linux or Windows. I also thought it might be the router but my network printer is working and I can still connect with other devices through it.

Ironic that I was about to post a lengthy list of what’s working and how well under Linux and then here comes a big problem with something that hadn’t given me any trouble before today. Really pisses me off (now I need to read the fine print to see if I’m still under warranty after installing Linux).

Anyway. I’ll get the stuff mentioned in the original part of this post up ASAP.

De-Bloating PCLOS on AA1

March 23, 2009

I’ve been a lot busier today than I was supposed to be so I didn’t have time to make a bigger dent in the overhead that’s part of a PCLOS install. That didn’t deter me, though, from setting up a very nice and light runlevel 3. Still have a lot left to unbloat, but I’m making a little improvement on a daily basis.

The pay off for my efforts? I’m only using about 50MB at boot into console with ksh as my shell. It’s a bit over double that after startx into ratpoison, starting aterm, and executing free. That sets me up using about 10% of my RAM at the start of a session, which is similar to my old DSL setup on my desktop

This is likely all for naught. If I can get more than a few minutes here and there, I’d really like to install something that gives me a clean slate to buld upon rather a bunch of extraneous stuff for me to remove, shut off, or recompile. Can’t wait to see how screwy things get when I start removing KDE stuff. I’m still considering  FreeBSD and NetBSD, but leaning more towards Slackware-current. Wish I had more time now but morning will be here too soon.

Edited 20090324: Boring screenshot.

screenshot-20090324041208

Added Smaller Window Managers on Aspire One

March 21, 2009

Continuing to configure PCLOS on my AA1, still some hardware issues to iron out. Still trying to reduce system overhead. Had one total lock up earlier when trying to get the card readers to work; also failed to successfully recover from suspending last night. Way to go, Team Linux. Wankers.

Oh yeah, I also found a newer toy of mine that will not work under Linux. I’ll have a separate post about that tomorrow or Monday. It’s a Windows world, baby. Get over it.

Tired of hardware issues — thankfully, XP works fine — so I’m moving on  to less serious things. I really like KDE but I think it’s a bit much. PCLOS doesn’t have much besides KDE, Gnome, Xfce, fluxbox, windowmaker, and OpenBox in their repositories. Gotta take matters in my own hands. I installed X lib headers. Compiled jwm, dwm, ratpoison. Added kdm desktop session files for each. Need to make jwm menu and add some of my old tweaks. Running ratpoison now. Freaking COOL — ratpoison on an Aspire One with its puny keyboard:

screen-20090321173903

Also compiled emacs, naim, and tmux (BSD-licensed alternative for GNU screen) from source. I have to say tmux is more than a BSD-licensed alternative to screen — it seems to better execute the whole multiplexing concept and it’s a lot smaller.

I’m using pdksh from the repositories (because I saw it listed). Default terminal in ratpoison is Eterm (also from repositories). What else? Dillo from the repositories is going to be replaced by dillo from source and patch for tabs.

I mentioned my aggravation at the way this was configured via the automatic set up and that I could end up doing something drastic. I’m not going to add much more since I have the things I want and need (OpenOfffice.org, mplayer for multimedia, browsers, etc.), and I’m probably going to start removing a bunch of stuff in the interim. Longer term, I’m leaning towards a much leaner install of Slackware or NetBSD. That will have to wait at least another week. Just not enough time to deal with it now.

Edit20090322: Just have a minute to update this. I ditched Eterm for aterm, recompiled ratpoison accordingly (it allows compile-time setting of default X terminal). Here’s a shot of a tmux session and a ratpoison window listing.

screenshot-200903220738351

One of the cool things about tmux is that it automatically updates its bottom title bar with the current process’ names. So I could stop top in the fourth (3) instance and its title would change back to ksh.

I compiled elinks unstable branch yesterday. I’ll probably revert to stable sometime this coming week.

BTW, I really hate the wallpaper (five minutes wasted in GIMP) and that font sucks. I’ll install terminus when I get a chance. No time now.

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.

Reconsidering Vector

April 21, 2008

I noted in my entry yesterday that I’m thinking of doing a low resource slackbuild. Part of the reason for that is my experience with both Slackware and Vector Linux. Not to mention my experiences with Damn Small Linux in both traditional and frugal installs.

Now that I’ve had a few months to use Vector, I’ve found several things that cause me second thought about recommending it. I’ll check the Vector forums later today to see if these are issues others have dealt with. Last time I went to the Vector site, it had been hacked (search my vectorlinux category for screenshots).

(Edit noon CDT: I’ve been to the Vector forums and I’m awaiting approval to post in their forums.)

First, upgrade options in gslapt have been disabled. This means users are unable to upgrade their systems using the default package management system’s GUI. I haven’t found out yet if it’s still possible via slapt-get or other parts of pkgtools. I can’t blame Vector for conflicts due to using different repositories, but Slackware and slacky.eu repositories are NOT suitable across the board for use in Vector. I found this out when trying to update OpenSSH and getting an error from SSL not matching the version against which SSH was compiled. Easy fix to revert to the older version. I still haven’t found the security update for OpenSSH in Vector’s repositories, though. Which is the underlying issue for me — security and upgrade-ability.

Second, the base packages are very bloated. I appreciate the desire to make the system usable by everyone without having to add font packages, but the tools for using the included Ethiopian fonts aren’t included. If you’re not going to include the tools to use the fonts, don’t bloat up users’ hard drives with 50+ MB of fonts! Geez. Add to that the dependencies which many packages have been compiled — e.g., requiring samba to run mplayer. Little thought given to users who may not install/keep samba. Like the security issue noted above, that means more work compiling myself. And I was trying so hard to not do that on this ancient laptop.

Also, the included wallpapers and icons aren’t what I consider light or fast. They’re pretty heavyweight compared to other options. This is noteworthy when considering the 82 lines in .jwmrc with icons — some of them being scalable, some of them being quite large, and the menu icon itself being over 40kb. All of that crap loads to RAM and causes performance issues as jwm has to scale the various and sundry icons. I realize my own jwm configuration is spartan and probably not to most users’ tastes, but there has to be a reasonable approach to this. And I’m not arguing for removal of all icons from .jwmrc, just use sensibly-sized icons that don’t cause users to use the same amount of RAM to use jwm as they use for Xfce!

Third, there are several bugs to be sorted out. For example, the setconsolefont script is broken (line 41):

/usr/bin/setconsolefont: line 41: $REPLY: ambiguous redirect
putfont: KDFONTOP: Operation not permitted

While that’s not particularly serious (setfont /path/to/consolefont), I’ve had several getty issues on my laptop. Suspend/tuxonice doesn’t work and causes me to lose all video whether in X or console if I go idle. If I kill X, I don’t get any video input — just a blank screen. I can blindly type “startx” to get back to X but can’t view any console output.

Fourth, another sort of minor thing that isn’t very minor: I also noticed that my wireless router light would continue to flash for a few minutes after I shut down. I found that /etc/wireless/interface.conf listed INTERFACE=”wlan0″ instead of eth0, which is where my interface was set up using VASMCC — Vector’s own tool.

There are a few other issues that I’ve wrestled with but these are the ones that come to mind. While I still think Vector is commendable and headed in the right direction, I can’t recommend it to inexperienced users. I also think in some ways experienced users wanting a Slackware-based desktop would be better served using Slackware in the first place. The packages are going to be about the same. I’ve already recompiled more things than I wanted to, and here I am thinking of removing X altogether and rebuilding the system to pare down the bloat. I just think Slackware’s minimal install with a few select packages is a more sensible choice than Vector for someone wanting a low-resource system.

I intend to check out Vector’s lighter project soon. Maybe that will be better, maybe not. I don’t think it’s adequate to offer jwm and/or fluxbox and call it “light.” There’s more of a need for a paradigm shift to it than merely remixing apps and window managers. Anyone can do that and the world doesn’t need more sub-distro remixes masquerading as “new” distros. Will it actually use distinct, separate packaging with minimal associated bloat? Or will someone ostensibly update to full-blown Vector when installing something from the repo because the apps aren’t compiled with forethought to keeping the system as small and unbloated as possible?

If it’s the latter, no deal. If not, there won’t be any need for me to continue with my low resource slackbuild. Or to be a little more cautious about recommending Vector without qualifying it.

EDIT: I resolved the issue with losing ttys after killing X by modprobe vga16fb (I don’t need framebuffer before X but I do after?). I’m still sorting out tuxonice. Or giving up on it. I’m also still waiting for activation for the Vector forums. Registered once, just hit my second ‘resend activation code’ button today.

Various Updates and Thoughts

February 26, 2008

A few quick updates…

BSD
I updated my BSD blog this weekend. I learned DragonFlyBSD has and OpenBSD will have bwi, a BSD-native Broadcom wirecutter-like module. So I’m at least going to test it out on my laptop and see how well it works. I’m most likely transitioning back to FreeBSD or OpenBSD (maybe DragonFlyBSD), but I’ll continue to do a few things with Damn Small Linux so I’ll keep a few partitions available for that.

TRADEMARK INFRINGEMENT
I downloaded Damn Small Solaris, which infringes on at least two trademarks so I’m striking it out. Why can’t people come up with unique names if they’re going to copy everything else another project is doing? Same apps, roughly same size, and then taking their name as well. I guess some people just lack the ideas and originality to innovate or differentiate at all. Damn Small Linux is trademarked. So is Solaris — maybe someone should’ve noticed Sun’s clear notice about use of their trademarks, which has led to OpenSolaris projects with very unique names like Nexenta and Belenix. Sun has a legal team. I hope John of DSL does, too.

LAPTOP – KDE – VECTORLINUX
Back to my laptop. I’ve been running KDE 3.5.8 on it the past week. I need to compare the configuration used by VectorLinux to what I’m using on my desktop because it’s not using as much RAM as I feared it would (an issue with the laptop since it’s “challenged”). I prefer KDE to Xfce. I’m using less RAM when KDE loads than when Xfce loaded. Even with my choice of apps, I’m using less RAM with KDE.

Needless to say, though, RAM use with KDE is about triple after login what JWM requires. I wish there was a way to get KDE’s (start up) RAM use to about 100-120MB. I would use it all the time.

DEBIAN
One thing I like better about Debian compared to Vector/Slackware is the application packaging. Debian’s repositories aren’t just more prolific, Debian allows a bit more flexibility with respect to meta-packaging. For example, I wanted a specific K application. With slapt-get, I had to take it as part of a larger package with stuff I didn’t want; Debian had it by itself.

REMASTERING
I spent some time working on stripping down and updating things in Knoppix to see how small I could make it. I can get it comfortably under 100MB, but I’m leaving in a few things that wouldn’t come with DSL (no, not KDE!). I may get to work on it again later this week. I have the things I want to work working already. The rest is fluff.