Posts Tagged ‘linux’

More Debian Squeeze Love: remuco

February 22, 2011

One of my favorite applications is remuco. It allows you to use Bluetooth headphones or similar devices to remotely control multimedia. For example, I can stop, pause, and change tracks with the controls on my headset. Volume control was already possible via pulseaudio (a2dp).

Debian packages are available to control various multimedia applications. I’ve installed it for all the multimedia applications I have installed with the exception of mpd.

p remuco-amarok - duplex remote control for media players -
p remuco-audacious - duplex remote control for media players -
p remuco-banshee - duplex remote control for media players -
i A remuco-base - duplex remote control for media players -
p remuco-mpd - duplex remote control for media players -
i remuco-mplayer - duplex remote control for media players -
i remuco-rhythmbox - duplex remote control for media players -
i remuco-totem - duplex remote control for media players -
p remuco-tvtime - duplex remote control for media players -
p remuco-vlc - duplex remote control for media players -
p remuco-xmms2 - duplex remote control for media players -

Configuration is pretty easy, as remuco functions as a plugin under totem and rhythmbox (which I rarely use). It requires a little more effort under mplayer but is straightforward. In totem/rhythmbox, go to edit-plugins and then click on.

Here’s the rhythmbox plugin dialog:

And for totem:

To reiterate, unlike DW reviewers, I’ve had no trouble getting things working in Debian out of the box or even with the most minimal effort. Audio on the Bluetooth headphones starts when I turn them on and direct the audio to it and stops when I either manually redirect audio or when I turn off the headphones.

Squeeze Hardware Love and SL6rc1 Tease

February 21, 2011

More fun with laptops this evening.

Squeeze Hardware Love

This follows up on what I wrote earlier about a DW drama queen’s reviewer’s complaints about Debian hardware support. Since that person didn’t elaborate much beyond a wireless card on what hardware was problematic, I wanted to give an indication of how easy it’s been to configure my own hardware.

Aspire One

First, I think everything except one of the card readers on my Aspire One worked perfectly out of the box (net install) when I ran Lenny on it. The only issue I had — which has occurred regardless of distro (but not in XP, except when rebooting from a Linux crash to XP) — was with the Atheros wireless card. It’s flaky. The camera, microphone, audio jacks, etc., all worked fine. If not for the wireless problem, whether it’s hardware or software, I would run Linux on that little netbook and be a lot happier with it.

Primary Laptop

My new-old laptop got a new wireless card that doesn’t require some kind of blob or quirky driver to work. It’s worked fine with every distro I tried. I used ethernet to set up Debian via net install. Everything on it’s worked flawlessly. That includes the peripherals and devices I plug into it.

Peripherals and Devices

I’ve used a couple different Bluetooth headsets with my laptops as well as phones. They’ve been easy to configure by editing .asoundrc to include a setting (e. g., for btaudio) to direct alsa to redirect audio to the headphones — pretty much the same as any other distro using alsa would require.

Debian has pulseaudio available, but it’s not default like in certain other distros. I’m not a big fan of it but it’s probably the easiest way to get a2dp working in Debian.

Speaking of Bluetooth, all my phones are able to send files (mostly pics) to the laptop via Bluetooth. Set up was easy using the default Bluetooth tools installed in a basic net install (Gnome is the Debian default). My USB Bluetooth dongle was detected from first boot and has had zero trouble.

My printer, a nifty all-in-one HP inkjet model released in the past 18 months, wasn’t supported by the CUPS and HPLIP versions in the SL5.{4,5} ecosystem. The printer worked when I updated certain packages, but I suffered breakage on the scanner side. I lived with that until I had to use that scanner. That’s a game-changer when it’s down to one choice. That’s when I reinstalled Lenny and then upgraded the system to Squeeze (which was still in testing) because a colleague had given me a thumbs-up on it.

My other printers are all supported. No issues.

My USB hubs, powered and unpowered, function properly. Someday someone will build a laptop with enough USB ports to plug all my stuff in at once, and I will buy it. Until then, my desk looks like a freaking spaceship with blinking green and red lights everywhere.

All the rest of my USB plug-in stuff has worked flawlessly or with what I consider minimal configuration. That includes cameras, ZIP drives, external hard drives, and so on.

SL6rc1 Tease

I decided to install SL6rc1 on my Aspire One tonight. I know I wrote earlier that I’ll have more on my testing, and hopefully I’ll get around to that by the weekend. I’ll also have a few words (and a screenshot!) to say about the installation — which would probably upset that little weenie over at DW because the graphical installer didn’t launch from the icon so I did it text-style.

It went fairly smoothly, I updated the system, added some software, and had to add a few seconds to GRUB so I can choose between SL6 and Windows XP (didn’t have to but wanted to).

Anyway, this is just a tease. I’ll write a proper review shortly and load a few screenshots.

Misc Update 20090806 – TinyCore Audio Fun

August 6, 2009

Just had a little more time to boot into TinyCore.There’s nothing wrong with the screenshots. TinyCore’s tiny X server only does standard VESA resolutions and netbooks have this odd 1024×600. What you see is 1024×768. You have several options for full X if seeing 1024×768 crushed into 1024x6oo is too off-putting. I only had a few minutes so it’s not life-threatening.

This time I decided to play with audio. I’d used the OSS extension before and this time I wanted to set up ALSA instead. No problems. Loaded the modules and dependencies, ran alsaconf to set up my card, and preliminarily checked settings with alsamixer.


I set up my usual mplayer-pls script to run from ~/bin. Then I went to shoutcast, found a stream, clicked on the link, aterm opened and the cache filled, then I heard Iron Maiden. Perfect!


Then I tried a few more streams to make sure everything was correct (of course it was). One thing the ALSA extensions have over OSS is automatic muting of the speaker when headphones are plugged in; the OSS extension has a command line option to set that to true, but the default is to not mute the speaker. No biggie but go figure.

Now I’m going to decide if crunchbang gets my current /home partition or the smaller / partition. {Tiny,Micro}Core gets the other.

I’ll have a list of stuff I’m compiling soon. I thought I was going to have time this weekend (and beyond…) but it looks like I’ll be heading back to take care of family for a while again. This time shouldn’t be as long or soul-crushing time-consuming.

Update: Hmmm, was it using oss instead of alsa? I’ll look again later and set up my script with -ao alsa to make sure defaults are overridden.

Thoughts on ath5k, Stability, and Linux (In)Security

August 3, 2009

I’ve continued to have serious issues related to Linux ath5k wireless so I’ve decided that I’ll upgrade my netbook to Windows 7 when it’s released. I was hoping that recent improvements in the ath5k code would fix what had plagued me before with frequent loss of detection of the Atheros card itself, which, as I’ve described before, continues even after rebooting into either Linux or Windows. That alone tells me something’s really, really bad with it.

I’ve been kind of restraining myself from going beyond that particular point about the gravity of the problem or what it potentially means. As I’ve already written, loss of detection of the card even after rebooting leads me to have concerns about physical damage to hardware. In case you haven’t noticed, every distro comes with a disclaimer that you’re on your own and developers take no responsibility for damage to your hardware. That’s always so comforting to know, that these people promise you the world but can’t stand behind their code.

The problem is capricious and can’t be tied to one event. That makes it difficult to initiate some specific sequence of events on my netbook to replicate the issue. At least that would give some guidance on what not to do — whether it’s a certain application, hitting certain sites, using a particular encryption protocol, etc.

Here’s what I haven’t said thus far. I wonder if it might actually be easier to recreate the issue outside of my netbook than on it.

Where there’s a “bug,” there’s often a vulnerability not far beneath. With the frequency of loss of wireless with this particular driver-card combination on my netbook, I wonder how difficult it would be to cause DoS (edit: whether limited to the wireless device, extending to the whole OS, or even pwnage/arbitrary execution) on the same network or even outside of it. If so, then there’s a much bigger and potentially more serious problem than instability.

This is only something I’ve pondered so far. I haven’t done anything (yet) to see if this is possible. It may not be any easier to cause the DoS externally than to set up a situation where the card panics and the OS no longer detects it. Either way, Linux is not proving a rock-solid option on my AA1.

My curiosity, though, is piqued by the possibility that I may be able to at least cause DoS through the instability of this driver (or the Linux 802.11 stack?). I’ve never been one to presume that Linux is inherently more secure than any other operating system. I’m certainly not going to start lying and join in the lie that it’s more stable than any other operating system. That’s especially true when it comes to my Atheros card: flawless and no crashing under Windows, unpredictable and buggy as hell under Linux.

One of the things I wrote last summer when Linus Torvalds mocked the OpenBSD people for their attention to security is that the OpenBSD team focuses on correctness of code because that makes security-related issues easier  to find. Where Linus is more concerned about fixing bugs, the OpenBSD team is concerned about doing things correctly from the start so there aren’t myriad little bugs to find because of sloppily-submitted code. One’s “bug” is another’s hole to pwn en masse.

I’ll probably continue looking to see if there are changes to the ath5k code and/or 802.11 code in Linux. I’ll also see if I can find another card with a better track record under Linux. Barring any changes, though, my Linux days are numbered.

Productivity: Setting Up at in Crunchbang

July 27, 2009

I needed to set up something to start at a time certain last night in what used to be crunchbang (considering I replaced over half the stuff in the default base, it’s not so much crunchbang anymore). That means using the at command; cron is a great tool for things that need to repeat on a schedule, but at is the tool to use for “one shot” events.

I entered “at 22:00” and wasn’t too surprised it threw out an error when I hit return. I looked in /etc and saw there was only the at.deny file but no at.allow. So I quickly added my username to at.allow. Then running at again showed that a certain file didn’t exist. Again, no big surprise — I openly admit a bias against Ubuntu because it uses shitty graphical utilities rather than setting up standard tools. So my next step was to setting up (touch) the file .SEQ in /var/spool/cron/atjobs.

% sudo su
root@pluto:/etc# cd /var/spool/cron/atjobs/
root@pluto:/var/spool/cron/atjobs/# touch .SEQ
root@pluto:/var/spool/cron/atjobs# ls -al
total 8
drwxrwx--T 2 daemon daemon 4096 2009-07-26 21:27 .
drwxr-xr-x 5 root   root   4096 2009-06-30 05:53 ..
-rw-r--r-- 1 root   root      0 2009-07-26 21:27 .SEQ

Uh oh, that won’t friggin’ work — it’ll result in denial of permission (unless you run as root, which isn’t necessary):

% at 21:30
warning: commands will be executed using /bin/sh
Cannot open lockfile /var/spool/cron/atjobs/.SEQ: Permission denied

The file needs daemon-daemon ownership. This is very easy to fix. See how easy it is, boys and girls?

root@pluto:/var/spool/cron/atjobs# chown daemon.daemon .SEQ
root@pluto:/var/spool/cron/atjobs# ls -al
total 8
drwxrwx--T 2 daemon daemon 4096 2009-07-26 21:27 .
drwxr-xr-x 5 root   root   4096 2009-06-30 05:53 ..
-rw-r--r-- 1 daemon daemon    0 2009-07-26 21:27 .SEQ
root@pluto:/var/spool/cron/atjobs# exit

Once I had that set up, I could test it to play a file (I wrote this Sunday night).

% at 21:30
warning: commands will be executed using /bin/sh
at> ogg123 ~/audio/fuckinaye.ogg<EOT>
job 2 at Sun Jul 26 21:30:00 2009

The EOT at the end of fuckinaye.ogg is just ctrl-d (remember that from when mail was a true commandline program?). At 9:30pm, I heard the test ogg file.

Now with it properly set up, I can use it to launch individual tasks when I need them and I don’t have to run X to do it from some stupid box with dials and buttons.

Thoughts on PCLOS Schism, Tiny Core on AA1

April 3, 2009

First, sorry to hear about the shake-ups in the PCLOS community. Unfortunately, the Linux world is filled with people who would rather make rinky-dink changes to things and “fork” trivialities. I realize some of the issues relating to the PCLOS schism are a bit deeper than that and go to the expected pace of development, but that’s hardly new to anyone who’s been involved in similar situations where a certain (lower!) class of user clamors for the latest versions to the point that you get forks based on developmental branches of distros — such as all the freaking Ubuntus and sub-Ubuntus, Sidux, etc. Fewer and fewer users appreciate stable releases and there’s an ignorant dash to anything featuring the newest — and least tested — verisons of every possible package. I’ll have another entry about this problem shortly, including something I read about PCLOS in particular.

This “if it’s not the latest version-number it’s too old” issue again came up in the context of the latest Distrowatch Weekly which was kind of dismissive of the version numbers in Tiny Core’s repository even though the review was positive. It’s as if “old” software is like food past its expiry dates and either won’t run after a certain date or should be thrown out.

how old is your software?

how old is your software?

Alas, such drivel is what seems to drive Linux distro releases nowadays. Too much shite clutters sites like distrowatch, where there’s increasingly less novelty let alone good ideas. Rather, someone takes a popular distro, switches a few things around like enlightenment in place of Gnome and slaps a ton of bloated eyesore wallpapers propagandizing the “new” distro, and gets some face time on distrowatch and similar sites. In reality, the “new” distro is just the old one — all too frequently with only minor changes. It’s all about control and version numbers anymore; gone is the whole esprit de corps that open source was supposed to be about where people cooperated. So now Ubuntu has fractured into countless little fiefdoms, some of which are run by the most clueless of the serfs. It’s now all about competition — not the kind that matters or makes things better but petty contests over who has the newest stuff whether it’s safe or stable or even usable.

This is why I quit tracking what other projects were doing: they’re often too predictably stupid and almost always way too much style over substance. There’s been very little (if any) innovation among new distros for some time. The few rare exceptions don’t get the same press that some sub-sub-sub-sub-Ubuntu version gets; instead, the real innovators are treated as minor curiosities worthy of a quick glance, but quickly forgotten if they can’t (or — damned heresy! — won’t) match the bloat and eye-candy of the masses of distros.

There were more novel changes a few years ago, when Klaus Knopper took Debian and created a live CD based upon it. Or even how others could take such a product (Knoppix) and innovate upon it in some unique way, such as happened with DSL or Knoppmyth. Those kinds of projects added real value beyond the originals, they didn’t merely change graphics or window managers.

Today’s distros’ lineages read like generational lists from the Pentateuch, where this bloke begat that one and so on down the line. Fortunately, there are  no sheep, cattle, or servants to ennumerate. I suppose it would be worthwhile if the third generation twice removed from Debian were actually doing something differently other than mucking around with untested software releases that require users to update software on schedules that make Windows users wonder why anyone would use anything so unstable. Or, even worse, that only changes the window dressing of the second generation twice removed merited an acrimonious fork (let alone a fork at all).

Among the more novel approaches today is Tiny Core Linux. I have to qualify what follows because I was initially involved with the development and I happen to like a lot of the people still developing it. Unfortunately, my schedule precluded doing much with the development team beyond burning a couple early ISOs and running it from USB. I also created the logo for the project. I dropped from the development team because I just didn’t have much time to work with it. I don’t now, either, but I’m making more time for it (if it comes down to a choice between pkgsrc in either Linux or BSD, Gentoo, or building from scratch, I’d just as soon use this as a modular starting point since I share a common vision with its developers — I’m giving up on finding a “ready to roll” option).  

I decided to boot Tiny Core on my Aspire One this morning. I mounted the latest release image and copied the bzImage and tinycore.gz to the root of the 4GB former swap partition PCLOS set up for me (that’s the last freaking time I’ll let anything automatically set itself up). Then I edited my menu.lst so I could boot it and rebooted. Since I didn’t have any extensions for anything else, all I got was a fast X session with jwm and wbar (which is something I would’ve lobbied vigorously against including in the base).

I’ll try to work with this some more this weekend and get it set up right (meaning reconfiguring my Linux partitions to more sensible sizes). I’ve not checked yet to see how many people are using Tiny Core on AA1s or if there are hardware issues beyond those I’ve encountered in PCLOS. If  it’s no worse, I’ll probably stick with Tiny Core and try to get around to submitting extensions again (not to mention more artwork I promised RS).

Various Updates and Thoughts

February 26, 2008

A few quick updates…

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.

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.

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.

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.

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.