Archive for the 'damn small linux' Category

More DSL Hard Drive Fun

April 29, 2008

I decided to recompile my DSL hard drive install kernel while watching the Hornets beat down the Mavericks. My goal is to get it even smaller and faster.

Ten megabytes (plus some marginal amount cached) while running X and several other processes (I took the screenshot in console while ssh’elled in and then used sshfs to convert the image from a raw X dump to png on the laptop). Take a look at the torsmo shot in my ‘dsl hard drive’ page for comparison. I’m getting there. Now I need to see why hotplug-knoppix loaded fat/vfat modules (which were loaded when this shot was taken)…

As for the rest of the stats:

% du -h –max-depth=1 /lib/modules/
20M /lib/modules/2.4.31 (default)
1.7M /lib/modules/2.4.36.3-mini (first try)
1.2M /lib/modules/2.4.36.3-miniM (current)

984K linux-2.4.36.3-miniM (current)
988K linux24-31 (default)
My other one was 1.2MB but it was a case of ‘better safe than sorry.’

I’ve yet to run into any issues. :-)

DSL Hard Drive Install Page

April 28, 2008

I’ve added and linked a shorter version of my Damn Small Linux “hardening” guide, which focuses on some of the changes I make immediately upon installing DSL to hard drive. Some of what I’ve added is security-related. After all, everyone thinks Linux is inherently more secure than Windows — so make sure it is. Other parts, such as recommending kernel recompilation, are less urgent. The gist of my opinion: it works and works well, but it’s easier using a distro that’s intended to be used for hard drive installs if you want to set it up correctly and safely.

The link is here and on the top under “My Pages.” I also hope to have the “MyDSL Pages” available soon, which will also have a link to it.

Additional note: I’ll recommend to Robert that zlib, ssl, and ssh be updated (or use dropbear, which hopefully is updated). If not, I’ll try to submit what I use as dsl/unc.

JWM Contrast Theme

April 23, 2008

This is my first accessibility mod. It’s a fairly high contrast theme for jwm. I’ve refrained from gradients and used only three colors/shades of grey: black, medium grey, white. Adjust the font to suit your needs.

<JWM>
<!– dark contrast theme: flat, no gradients; black, white, medium grey –>

<WindowStyle>
<Font antialias=”false”>fixed</Font>
<Width>4</Width>
<Height>18</Height>
<Active>
<Text>white</Text>
<Title>black</Title>
<Corner>grey50</Corner>
<Outline>white</Outline>
</Active>

<Inactive>
<Text>grey50</Text>
<Title>black</Title>
<Corner>grey50</Corner>
<Outline>black</Outline>
</Inactive>
</WindowStyle>

<TaskListStyle>
<Font antialias=”false”>fixed</Font>
<ActiveForeground>black</ActiveForeground>
<ActiveBackground>white</ActiveBackground>
<Foreground>grey50</Foreground>
<Background>black</Background>
</TaskListStyle>

<!– Additional TrayStyle attribute: insert –>
<TrayStyle>
<Font antialias=”false”>fixed</Font>
<Background>grey50</Background>
<Foreground>white</Foreground>
</TrayStyle>

<PagerStyle>
<Outline>black</Outline>
<Foreground>grey50</Foreground>
<Background>black</Background>
<ActiveForeground>black</ActiveForeground>
<ActiveBackground>white</ActiveBackground>
</PagerStyle>

<MenuStyle>
<Font antialias=”false”>fixed</Font>
<Foreground>white</Foreground>
<Background>black</Background>
<ActiveForeground>black</ActiveForeground>
<ActiveBackground>white</ActiveBackground>
</MenuStyle>

<PopupStyle>
<Font antialias=”false”>fixed</Font>
<Outline>white</Outline>
<Foreground>white</Foreground>
<Background>black</Background>
</PopupStyle>

<!– end dark contrast scheme –>
</JWM>

Here are two thumbnails showing contrast in menu and in other decorations (click for 800×600 view):

Maybe it would work better with the window decorations matching the task list colors — black on white — and then use the white on black for inactive windows. Please provide me feedback here or in the DSL forums, especially if it needs adjustments for more clarity (or if the use of grey is a problem and it needs to be black and white only).

DSL 4.3 Released

April 22, 2008

DSL 4.3 is out. Perhaps the most noteworthy change is the upgrade to Firefox 2.0 GTK1 (Bon Echo rebranding) from Firefox 1.0.6. Edit: There are other changes that deserve comment. The browser for MyDSL is now very much improved. The noicons cheatcode will now boot jwm without icons (in addition to not starting dfm on the desktop); this speeds things up quite a bit even though it’s primarily targeted at vintage low-RAM computers.

There are some things about it I don’t like. The first is something subjective and very easily changed: the default theme and wallpaper are too freaking dark. I’m also not a fan of black and white, and that’s essentially the color theme for jwm. This is a shot with Firefox opened all the way hiding the background save for the overlaying aterm. I’d already made some changes to remove the icons from the tray buttons and moved the tray to the top when I took the shot.

My biggest peeve of all is the search engine choice. Not choices, choice. It’s a Google search through DSL’s site. How many concerns do I have about that?

  1. Privacy - are click-throughs being recorded? What’s John’s privacy policy for both DSL and Google searches through DSL?
  2. Given DSL’s recent downtime and slow responses (see two or three entries ago), will this mean users will ultimately have to type google.com in the URI box anyway just to use Google?
  3. Why should users have to go to the Firefox add-ons site to get standard choices for search engines?

Like I’m about to add in the DSL forums, that’s going to be easy enough to fix because I’ll download the GTK1 build of Firefox 2.0.0.14 anyway and just start with a fresh profile. But I think it sucks that someone would direct my searches through his site first. See what I wrote about Vector’s default settings so that every new browser installation or upgrade hits their website. Boo.

Problems with DSL Forums

April 21, 2008

This has been occurring with great frequency the past week, and it totally sucks…

If it’s not one thing, it’s another…

Taken within minutes of each other.

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.

How I Roll: sshfs

March 24, 2008

I’m not exactly a road warrior, but most of what I do is in the field. I’ve written in various forums that there are a few applications and utilities essential to me and “how I roll.” One of them is GNU screen. Another is SSH. These two allow me to work from the same session anywhere without ever stopping.

I’m also a huge fan of sshfs. This is a FUSE filesystem that allows a user to mount a remote home partition via SSH as though it were local.

Here’s a little tip if you’re working on a laptop in a situation where you have limited space on its hard drive, or if you’re in an area where there’s significant risk of losing your data through computer theft or some kind of disaster. It’s also cheaper than buying a new laptop hard drive.

Let me give an example. Let’s say you’re on your laptop at the university. There’s significant risk of theft of laptops and everything else. You need to work on your project but you want to insure you don’t lose all your effort in case your laptop “disappears,” if it gets dropped, whatever. You can lose an entire semester’s (or longer) work if something bad like that happens.

WIth sshfs, you can keep your work on your desktop (or server) computer at home. It doesn’t end up on your laptop’s hard drive, but you still have the easy and fast access as though it were because it uses the Unix idea of “everything as a file” in joining remote to local.

You would only need to run ssh on the computer at home so that you can access it remotely (and as securely or insecurely as you desire). On the laptop, you would run the fuse module and then enter the command:
% sshfs username@path.to.desktop.or.server: laptop.mountpoint/

So if your account name at home is “lucky” and you want to set a mount point (directory) on the laptop for “remote” it would look something like this:
% sshfs lucky@my.home.network: remote/

You’re asked to enter the password for user lucky and then that mounts the entire /home/lucky directory on the other computer to ~/remote on the laptop. Once you do that, you can transfer files back and forth as though it were all local — the same as any other files or filesystems mounted on your computer.

If you have a similar/compatible set of applications on both computers, you can also just get with it and use your remotely stored data files with your local applications. If you’re using Open Office’s calc or Gnumeric for your spreadsheets, you would just open whichever files from the remote computer on the local one. Then when you save, you’re saving remotely.

This minimizes the need to sync files between laptop, desktop, and/or server or keep up with multiple versions of the same data because you can use the same version universally. You can get by with less space on your remote/laptop hard drive if you have large files to work on. Just use your larger (cheaper) hard drive on your desktop/server for all your storage.

When you’re finished and want to unmount the remote system and terminate SSH, you enter:
% fusermount -u ~/remote/

Since it uses SSH, it’s more secure than a lot of other options including keeping data on tiny USB devices that can disappear even easier than laptops. And while there can be risk of theft of your desktop computer while you’re away, that risk is much lower if you use a bulky old (cheap) computer for such purposes. The more stuff you put in it to weigh it down (six combined floppy and optical drive slots don’t have to be filled with working — or even connected — drives), the less likely a thief will be interested in carrying it. Instead of adding another working computer (or broken floppy and Zip drives) to your local landfill, why not put it to good use?

It doesn’t need to be bleeding edge, you just need to be able to shell into it to access your safe data and have enough storage to make it worthwhile. It also doesn’t have to be big and heavy as described above — you could carry a “craptop” on campus and leave your good laptop in the safety of your home. Whatever you use can serve other duties as well if you put your mind to it.

And you can get by without ever touching your laptop hard drive (or needing one). Some Linux live CDs, including Damn Small Linux, come with FUSE and sshfs. Since DSL contains extensions like Open Office, Abiword, Gnumeric, etc., it would be quite easy to work remotely like this.

Both FUSE and sshfs are available with nearly all Linux distributions or should easily be added if not, as well as for FreeBSD and NetBSD (possibly other smaller ones, but not to my knowledge in OpenBSD). More FUSE fun soon.

Wrapper Script 101

March 11, 2008

This is in relation to something at the DSL Forums. Sometimes applications need a little help to “automate” things, work in the desired manner, or to use configurations other than default without having to switch from default settings. In this case, it’s just a simple shell wrapper to open a terminal and use mplayer to stream audio. Below is the resulting output from 181fm Classical Guitar (nice work music) and the simple wrapper script.

I put it in xterm because that’s my “floating” terminal — aterm and mrxvt are maximized without border or title in jwm. I set that wrapper as my run action in rox for PLS streams — click, open, it plays (kills with q, ctrl-c, or closing the window). Not fancy but at least it’s easier on RAM than xmms.

EDIT: Here’s another shot with the same wrapper as my default PLS application in firefox:

JWM on Debian

March 5, 2008

Just a quick shot before I go to bed. I didn’t get a JWM entry for kdm when I installed JWM from Sid repository so I added my own link to the Jwm.desktop file. Made a few quick changes to get away from KDE apps. Konsole sucks outside of KDE so I added mrxvt — I get the tabbed terminal without the bloat. Set it same as I run terminals in DSL (no title or borders, maximized). Spent a little time tonight editing a menu and looking at what to leave in, what to add, and what to remove.

That’s right. Boring! Just the way I like it. Default colors for jwm, solid grey22 background.

There’s a lot I want to do to pare this system down further; even with GTK2, I think I can get it down so I can get a sub-80MB ISO. KDE is going this week — not so reluctantly even though I appreciate it enough to install it on my bigger hard drive and faster computer. I want a few apps familiar to DSL users like emelfm(2) and sylpheed (maybe mutt instead).

BTW, previous uptime was 32.5 days. Down because of power failure during excessively windy conditions (40+ mph) last night.

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.