I have just discovered that my flavors.me page has traffic generating from links to posts I had on an old, old blog. However, since I am such a nice guy, I used the wayback machine to retrieve those posts in the hopes that people find them on here.
I saw this post on Lifehacker a few weeks ago but never got chance to set anything up. I really liked the minimal look and started playing with some of the widgets to see what I could do. Then, this weekend, I set up some home screens.
I have been using Swype for the last few weeks but I decided to give SwiftKey a go. I’m not entirely sure I’m using it correctly, it seems pretty weird. So, the idea is that instead of typing most words manually it tries to predict what you intend to type? Odd.
Another recent developer bug bear was the fact that Arch installs files to /lib instead of /usr/lib. This needed fixing, seriously, people were losing sleep over it.
So, that was fixed, in every single package, without Announcement.
How the hell are people that maintain AUR packages supposed to know? I know because I read the arch-dev-public mailing list (what doesn’t get auto binned that is).
This, as with the evil Udev symlinks, broke something too but since that only happened by chance, no-one seemed to think it was important.
It’s a simple “bug”: the Udev rules owned by device-mapper moved. As a result packages that used those udev rules when installing mkinitcpio hooks (like lvm2) got updated to point at the new location. Perfect.
However, the linux package rebuilds the initcpio immediately. If, like me, you got unlucky and lvm2 installed after linux then mkinitcpio ran a broken hook install file and didn’t create the initcpio file properly.
Re-running mkinitcpio -p linux once pacman has finished updating fixes the problem.
However, if you don’t scrutinize your pacman.log for such errors, you could easily miss this and have an unbootable system.
Tough shit for not paying attention is the official response.
Another thing that broke in my Arch install was my /dev/dvd /dev/cdrom symlinks.
However, this was an intentional “development” decision. This was the reason and I think the Arch KISS principle was the justification.
Quite how removing something that provides seamlessly functionality without adequately publicising that you have made that change keeps anything simple is beyond me.
What would be simple is to typing up a News post and slapping it on the Arch Linux frontpage – how long does that take? Adding a message to a .install script is not enough.
Wait, I’ve just had an awesome idea…
Oh, by the way, the fix I used, in case you end up here looking for one is:
#!/bin/bash
#
# /etc/rc.local: Local multi-user startup script.
#
symlinks=(cdrom cdrw dvd dvdrw)
for device in "${symlinks[@]}"; do
[ ! -h /dev/$device ] && ln -s /dev/sr0 /dev/$device
done
Since I’ve missed 5 years of Linux advances I figured it would be better to get caught up before I started installing Arch on my Netbook.
I decided the best way to do this was just update my Arch desktop and fix whatever broke. Turns out it wasn’t all that much.
Muting with unexpected results
Sound died on my Arch desktop sometime ago. Since I have an onboard and separate SB card I thought maybe it was a driver conflict. I spent several evenings, already exhausted from work, tinkering with various things but after much googling and reading of the Arch Wiki ALSA page I was still clueless. Then, I cracked it.
This breakthough was achieved through poise, precision and audacity. Basically, I sat down one night and said “Right, I’m fixing the sound tonight.” Starting from scratch I opened the Arch Wiki ALSA page and read it from top to bottom, word for word, no skimming.
I very quickly spotted this:
Some cards need to have digital output muted/turned off in order to hear analog sound.
For the Soundblaster Audigy LS mute the IEC958 channel.
Weird. My previous investigations had reminded me of the make and model of my card and I’d also read about what all the various channels are for. It’s worth noting that at one point I was paranoid I had my speakers plugged into the wrong jack so I check all that out too.
Anyway, this sounded promising. I launched alsamixer, previously in which I had diligently unmuted ALL my channels, and looked for what might be a digital channel. There was one called PDIF. I tabbed over to it and pressed “m”.
Success.
I am not an elephant
I use mpd to play music. I like the simple interface and lack of super bloat. I like Sonata as a front end. I installed Rhythmbox recently and the dep list gave me the 🙁
Once sound was working again I tried to use mpd to play some songs. Nada.
This time, though, having learned from my previous mistake I went straight to the wiki and read carefully.
The stock Arch mpd.conf had been heavily modified since I set it up so I migrated my settings to the new file format while following the wiki. I quickly realised that at some point in the past I’d deleted the ALSA output section in favour of an http streaming section. Genius. I later realised I’d done this remotely via SSH from work to get some Firefox extension working or something. I have a very visual memory, which explains why I had no recollection of ever having touched it at home.
Last but certainly not least
This pissed me off. This is typical developers sticking to “rules” when it seems to suit them even if it contravenes reasonable expectation or logic.
I won’t tell the whole story but basically I wanted to mount partitions in Thunar. Permission to do this is controlled by udisks (I think) and managed thorough policykit now. Arch ships with great polkit defaults that most people won’t need to change.
However, the rule that allows any user to mount a partition requires the user to give a password. You may know that for polkit to ask you for that password you need something called a User Authentication Agent. There are two main ones: polkit-gnome and polkit-qt.
Obviously, the basic installs of gnome and kde depend on these packages respectively. Not so with XFCE! Oh, no, no! Even though it means that Arch’s perfectly sane polkit defaults are impossible to implement without it, the dependencies for Arch’s XFCE packages do not include a User Authentication Agent.
What’s worse is that you have an Arch Dev on the forums basically telling people they’re retarded whenever they can’t get this to work and smugly telling them to install polkit-gnome.
The Policykit package should depend on a User Authentication Agent. That’s a simple fact. However, because there is a choice of two and Arch would never be partisan, it depends on none.
There’s not even an .install script to warn you. Instead polkit-gnome is an optional dependency for Thunar…
I don’t spend loads of money on myself. I’m the sort of person that hates to spend money on something I later regret.
This worked out well recently when it allowed us to buy a house. Not out right. Just most of the deposit.
So, since it’s been a pretty full on six months I treated myself to an Asus eeePC 1015PX.
My main reasoning behind this was I spend about an hour on a train a day and a Netbook seemed a good way to maybe do something productive.
Needless to say I wiped Windows 7 off of it and installed Arch Linux.
At the moment it is set up just a basic XFCE desktop environment but I hope to switch to something like Awesome for true portability. Touchpads and trains don’t get on.
I’ve basically spent the last few weeks trying to get to grips with power management and drivers. Riveting, eh?
You might have noticed some pictures of a hairy guy with a small baby boy on the blog recently. That’s me and that’s my son.
His arrival has been a life changing experience and, like all life changing experiences, people tell you it’s life changing till they are blue in the face but you never really realise how life changing it is until it happens to you.
Up until just before our boy was born I plowed about 80-90% of my life into MMOs. That started in about 2007 when I took a break from playing with Linux, which had been my main hobby from about 2003. At that point I was very active in the Arch Community and had just been accepted as a developer. Odd time to walk away!
Anyway, I barely touched my Linux installs in the intervening 5 years but my interest has been rekindled, my boxes have been pacman -Syu’d and a brand new netbook has been saved, in everyway, from Windows 7.
My return to the world of Linux has quickly proved to be all to familiar. By turns hugely productive and rewarding yet also face punchingly frustrating.
So, because Linux would literally be nothing without the Internet to support it, it’s incumbent upon me to share my experience in the hope of saving someone else an enormous ball ache.
I love this cartoon. It makes a great point really simply.
However, it’s a bit, well, misleading…
The cartoon suggests that Tr0ub4dor&3 is massively more susceptible to an attack than correcthorsebatterystaple because of the difference in entropy.
Assuming the math is sound (I calculated using actual password space rather than entropy) I still have a problem with how it might be interpreted.
In the cartoon Tr0ub4dor&3 loses entropy points because it’s based on a non-random word with substitutions. Ok, that’s fair enough. Lots of people do create p4ssw0rds this way so it seems reasonable to punish this with lower entropy.
In short, this password is punished because the format is predictable.
However, if we punish that password for a predictable format, it’s also fair to say that correcthorsebatterystaple is thus susceptible to a dictionary attack. Conversely, Tr0ub4dor&3 is entirely secure against such an attack.
A pure brute force attack against Tr0ub4dor&3 with a 1000 guesses a second would take 180 billion years.
The same attack against correcthorsebatterystaple would take 7.5 billion billion years.
The difference is so gigantic it’s almost inconceivably massive.
However, if we consider a dictionary attack using 860,000 words against correcthorsebatterystaple at 1000 guesses a second we’re looking at 17,345 billion years.
Suddenly, correcthorsebatterystaple is a lot less strong.
In fact, if you add a single _ to the end of Tr0ub4dor&3 it now takes 17,134 billion years to brute force. That’s very comparable.
To batter the correcthorsebatterystaple example even more we could alter our dictionary attack and remove all the words that are shorter than 4 characters from the 860,000 total. This would be reasonable as you would want your four word password to be at least 16 characters long.
However, I can’t deny that a pure brute force attack on Tr0ub4dor&3 would take less time than a full dictionary attack on correcthorsestaplebattery and the latter is much easier to remember.
So it’s still an amazing bit of work – it just helps to understand the details.
So… what?
Well, basically, two things.
1) using a format that helps you remember your passwords is a good idea – whether you combine 4 random words or use substitutions – the weakness comes when someone PREDICTS the format.
For example, using 4 random dictionary words AND making a single typical substitution of an alpha char for a numeric char (e.g. substituting a 0 for an o) secures it completely against a dictionary attack and the hacker would have to resort to a brute force attack. However, if the hacker KNOWS that you did this, they know they can modify their dictionary attack instead.
2) there is no substitute for length when it comes to passwords.
For example, take a simple 8 char lower case password. Changing one of those 8 chars to a number means it takes 10 times longer to brute force. However, adding another lowercase char would take 26 times longer.
That’s a generous example but it makes the point. Having a short but complex password like #9Nj and then typing it 4 times is extremely resilient against a brute force attack.
Just make sure no-one is looking over your shoulder…