Fedora 14 64-bit Flash Problems
Its rather old news, but rather new to me. There is a known bug with the 64-bit Flash plugin when used in Fedora 14. When playing back certain Flash videos, the bug produces regular high-pitched beeping noises, as though there is some odd clipping issue. The culprit of the bug is a recent upgrade in glibc's memcpy(). I'm seeing a few hacks and patches being thrown around in the bug report, but for now, I'll probably just stick to running 32-bit Flash in a wrapper.
And again, here's the bug report.
Mirror, Mirror, Who’s the Oldest of Them All?
I'll admit, that my Arch updates haven't exactly been occuring with religous regularity, but I never allowed more then a month at most to pass between full system updates on my Arch machines". But today, when I decided to do a full update I was surprised to find that all my packages were already update. Especially since I remember seeing the same message on the last update. Some digging through my log files revealed that the last time one of my system updates actually updated something, was in August of last year. Which means that four months have passed without my system actually being updated. Oh sure, I issued a system update command pretty regularly every few weeks, but no packages were ever updated.
This is Not Good.
Some more digging was required, and it was revealed that the mirror I've been using, mirror.cs.vt.edu/pub/ArchLinux, hasn't been synced to the Arch repository in a very (very) long time. This is also Not Good. But perhaps even more worrying then Virgina Tech's laxness, is my laxness and unawareness. How could I have not notice that various programs on my laptop were several versions old, or that my system upgrades were never doing anything!
So I am doing a massively huge upgrade right now, and I fully expect it to wreck serious hell on my system. But at least that's better then walking around completely oblivious to the various known security holes on my laptop.
My Time with Arch
I've been a proud and content Arch Linux user for a little over one year and nine months now, far longer then I've spent with any other Linux distribution. Arch put a happy end to my constant distro-hopping lifestyle, and I've been so pleased with its simplicity and performance that I've spared nary a glance at any other distribution over these past 21 months. But in more recent times, I've been having some disagreements with my Arch system and so I've slowly started reverted to frequenting the old haunts of my distro-hopping days (i.e. distrowatch.com, and other such distro news sites).
Stability has always been a much touted feature of Linux in general, but some distributions lay a greater claim to that attribute then others. Arch in particular has tended to be slightly more bleeding-edge then other distros, sacrificing stability for the newest features; packages are updated in the repository as soon as new versions are released and with a relatively minimal amount of time (extremely minimal compared to other Linux distros like Debian) spent in testing in an Arch environment, just enough to ensure that the packages don't completely break the system. While this strategy has its benefits, namely that it allows users to get the latest and greatest software right when it comes out, it comes at the cost of stability (and security to some degree). And the more packages that I've added to my system, the more I've started to notice just how unstable Arch can be.
I generally run "pacman -Syu" to do a full system update at least every week, and I try not to let my system stay without an update for three weeks at the longest, so in general I'll stay pretty well up-to-date. But it has not been uncommon, that after performing a full update, that my system completely locks up or goes completely nuts. Take for example, just a few weeks ago, when a full system update made my Arch Linux partition completely unbootable and required that I boot a live CD and futz around in the configuration files. When my laptop was finally usable again, I had to mess around some more with my wireless drivers to get them working again. And lately, after my most recent system update, I've been having some problems where my laptop will occasionally freeze up and become totally unresponsive to everything except a hard reboot, and system logs show no behavior to be out of the ordinary. Of course, not all of the breaks in Arch have been this bad. About four months ago, a system update made it so that I could no longer hibernate, a problem which was easily remedied by a quick visit to the Arch wiki and a few short commands. Sadly, the list of weird errors goes on (although its not that long).
Two years ago, when I was moving off of Debian testing, Arch's bleeding edge packages were quite welcoming, but not that I've matured a little bit, I don't care as much about the latest features (Lets face the facts, the programs I've been using the most these past few weeks, have been vim, GCC, SVN, and Zoom). My first priority these days, is getting shit done. And if my laptop decides to go bat-shit-crazy now and then, it seriously hampers my ability to work properly. I don't mind a few bugs now and then, and I could probably even live with a rare kernel panic, but sometimes I get the feeling that Arch is maybe just a little too bleeding edge for me.
I mentioned earlier that another one of the costs of having the latest and greatest software, is security. A lot of the newest software releases tend to be not as well hammered out and therefore are slightly more prone to have security holes. I'm only a slightly paranoid Linux user, so while the lack of security is a little worrying to me, its not a huge deal breaker. Arch's lack of solid support for more powerful RBAC security modules like SELinux or AppArmor has also been a little worrying to me. I would love to be able to slap on some powerful RBAC policies on my laptop to give me greater piece of mind, but Arch's normally awesome wiki is a little lacking in help (although it seems that reccently, the SELinux page has gotten a little more meat to it).
This next point is a rather silly and illogical thing to hold against a distribution, but I feel that it needs to be said because its entered my thoughts a few times in the past year. Whenever I go in for an interview, I generally try to play up my Linux expereince (which is not incredible, but still fairly impressive enough). The logical question for an interviewer to ask of course, is "what distribution(s) do you use?" As soon as the words "Arch Linux" comes out of my mouth, I can see the interviewers knocking some points off of my interview. People always assume that Arch is just another one of those random "edge" distros that is basically just an Ubuntu/Fedora knockoff with some sparkles thrown in, and no maybe how much I explain it to them, I know that they don't respect an Archer as much as they respect a Slacker. So yeah, I'm a little shallow, but I do care about what people think about me, especially in interviews. A part of always wishes that Arch was just a little more mainstream and a little more well known.
So I've taken some pretty mean shots at Arch, but my comments shouldn't be miscontrued to indicate that hate I Arch. Quite the contrary in fact, I've loved using Arch. My old Arch review enumerates out more clearly the points of Arch that I really like, but I'll list them out here quickly.
- Fast! - Compiled for i686 and lightweight with no extra cruft thrown in
- Clean - there is nothing on my Arch system that I didn't put there
- Simple - things tend to be very straightforward and elegently simple
- Awesome documentation and user community - Arch's comprehensive wiki is in my opinion, one of its strongest selling points, also the forums are quite helpful.
- Rolling updates - its nice not to have do some big update every six months...
All the reasons that I first came to love using Arch still hold true, its simply that as time has worn on, I've changed a bit: I don't care as much for bleeding edge features, stability and security have become bigger issues, and I've started caring about what other people think about me. So I've been asking myself, "is Arch still for me?" And I think the answer might be no. I purchased a used IBM Thinkpad reccently, and I don't think Arch is going to be my first choice for it.
It seems like its time for Arch and I to "take a break" in our long relationship. But don't worry Arch, its not you, its me.
Network Timeouts in C
Reccently, while coding up some P2P sharing software for class, I came across a problem that really got me stuck. (Note, that I forked different processes to handle each upload and upload.) When reading data from another peer, my peer would generally have to block until the other peer responded, since with network programming we can never expect all of our requests to return immediately. The problem was that occassionally, the other peer would decide to die entirely and I was left with a process that would block essentially forever since the signal it was waiting for was never going to come. Now the great thing about blocking reads is that they don't burn CPU time spinning around in a circle waiting for data to arrive, but they do take up space in the process table and in memory. And of course, if my blocked reading proccesses stayed around forever, it would be very simple for a malacious peer to bring my OS to a grinding halt. Essentially, what I needed was a way to make read() timeout. Now anyone vaguely familar with using internet browsers and other such network-reliant programs are probably familar with timeouts, but I had no idea how to implement it in C.
My first thought, was to use setrlimit(), a Unix function that allows the programmer to set the maximum amount of system resources (CPU time, VM size, created file sizes, etc., for more use "man 2 setrlimit"). When setrlimit() is used to set a maximum amount of CPU time, the process will recieve SIGXCPU when the CPU time soft limit is reached, and then the process is killed when the hard limit is reached. At the time, I was a bit groggy so setrlimit() seemed like a great solution, but of course anyone with half a brain (which I apparently didn't have at the time) will realize that setrlimit() is definetely not the solution to this problem. A blocking process doesn't run and therefore doesn't consume CPU time, so setting a maximum CPU time does pretty much nothing to the blocking process; it'll still keep blocking forever.
After a little bit of trawling the internet, I finally came upon the perfect solution: alarms! When alarm(unsigned int seconds) is called, it will raise SIGALRM after so many seconds, realtime seconds mind you and not CPU seconds consumed by the process, even if the process that called alarm() is blocking. I set the alarm right before I began a read() and used signal() to bind a signal handler to SIGALRM, so that when the alarm went off my signal handler could gracefully kill the timed-out download process!
GNU Readline
I reccently wrote a shell for a project in my CS class. One of the advanced features that my partner and I implmented in the shell, was tabbed completion, and in order to implemet this extremely useful shell feature, we used the GNU readline library. The GNU Readline library is a beast, and not in the good way. Its a great hulking pile of code and documentation, intended to provide a ton of features for reading typed lines. Once you figure out what all the function pointers, bindings, and generators in the Readline library are supposed to do, things become much more straightfoward, but it doesn't negate the fact that initially figuring out Readline is a bit of a pain in the butt.
The first thing I did after we were told that the Readline library could make our project easier to design, was to pop open a terminal and type "man readline". What I got was a basic summary of Readline, so in order to get the full library manual I had to resort to Google. I did however, happen to see this at the bottom of the manpage:
BUGS
It's too big and too slow.
Now if even the guys working on the Readline library think thats its too big and too slow, we may have a potential problem on our hands.
One of the plus sides of however Readline's enormity was that it does offer a whole slew of features, like a kill ring, and generators for tab-completion of filenames and usernames. It would be very nice though, if all these features could be implemented without the need for a manual that probably took me longer to read, then it did for me to code up a generator for command line completion.
Goo on Linux
Several weeks ago, I saw an article on digg about World of Goo being ported to Linux. My roommate happened to see it too, and knowing that I was a Linux user, told me that I should download it and give it a try since it apparently gained a good reputation on the Wii. I have to admit, I was a little excited to give it a try, especially because the Linux world isn't exactly overflowing with a wealth of good games (seriously, Sudoku and Mahjong don't really count).
I'm not exactly sure why 2D Boy, the makers of World of Goo, decided to port their funky game to Linux, but I'm not complaining. One thing that people should note however, is that although Goo is DRM free (yeah!!) it is not totally free, getting it legally will cost $20 (US). I know that there are a few Linux users that turned to Linux specifically because it is free, and they expect that all their software should be totally free and open source. Unfortunately, the two guys at 2D Boy have to make a living, and since they've managed to make a good product I have no qualms forking over a small fee to play the whole game.
If you're not quite ready to put some money down (like me), you can of course download the trial version (like I did), which will allow you to play through the first level (which I did). The Linux version comes available as debs, RPMs, or just good-old tarballs (and Arch user that I am, I went with the tarballs). I was expecting that Goo wouldn't work right out of the box and would require some tweaking to get it to work, but surprisingly all I had to do was untar and run the binary inside, and Goo was up in an instant. So props to the developers and testers for a job well done. And of course, the game was actually surprisingly fun, despite the fact that on first impressions it looks like a cheesy, kiddy game. I'd highly advise that Linux users give World of Goo a shot.
Linux and Me
I was first formally introduced to Linux during my junior year in high school by a friend who had seen someone else run it. At this in my life, I considered myself to be a geek and computer lover, but in reality I knew very little about computers; my experience was limited to some Microsoft Windows XP, C++ and HTML, and building my own computer. I became interested in this "new" operating system, entranced by the idea of free and open source software and jealous of the high geek status granted to Linux gurus, for it seemed as though all the "cool" people ran Linux.
I borrowed some Mandriva CDs from my friend, used Partition Magic to resize my Windows NTFS partition, and installed Mandriva Linux. The experience was nowhere as delightful as I would have liked; my ATI Radeon graphics card failed to mesh properly with Xorg and instead of booting into a cool new glossy interface, my computer dropped to a shell, spat cryptic error messages to the screen, and then calmly prompted me for a login name. I spent the next few days shifting from my parent's computer to my own, trying to find a way to fix X and boot into something that I might be able to understand. I typed into the shell dozens of commands, scrounged from various forums and install guides, hoping that one of the seemingly random strings of characters would be my savior. But my attempts were futile, I had no idea what I was doing, and didn't even bother to try to understand what was going wrong. Eventually, I got so fed up with Mandriva that I gave up and went back to using XP.
I spent the next few month with Windows, sometimes scrolling through random threads in Linux forums and reading little tidbits about the operating system that had failed me, when I decided that perhaps it was time to give Linux another chance. At that time, Fedora and Ubuntu were the user-friendly distributions of choice, and so I spent a few days debating between the two. I ended up downloading Fedora simply because at the time, I thought Fedora Core was a much cooler name then Ubuntu. Maybe it was because the version of Fedora I was using had a newer kernel then the Mandriva CDs my friend lent me, but Fedora installed and booted without a hitch. I was cruising the web and ripping music almost immediately, and it didn't take long for me to discover the wonders of Beryl and the spinning desktop cube. It was hard not to fall in love with Fedora. It was faster and lighter then Windows XP, could do things that Windows wouldn't even be able to compete with for a few more years, and it improved my geek cred immensely.
HFS+ and Linux
In a talk that Linus Torvalds gave in February this year (2008), Torvalds claimed that Mac OS X's file system is "complete and utter crap, which is scary." That was the first time I ever heardabout Mac OS X's file system.
One of my roommates is a Mac user and is quite ignorant of almost all things technical. Recently, his hard drive crashed and he had to send his shiny Macbook Pro to a company that specialized in data recovery, and so he is currently without a computer. He does however still have a working external hard drive that contains a plethora of videos, and so yesterday I asked him if I could borrow his hard drive and look through some of his videos. He told me that I wouldn't be able to use his hard drive on my computer because one of his roommates last year, "reformatted it in a special way so that only Macs could read it."
Having read a little into Apple's file systems, after Torvald's comment earlier this year, I hypothesized that my roommate's hard drive was using Apple's HFS+ file system. Linux has surprisingly good support for various different file systems, even Microsoft's proprietary NTFS, so I knew that it was extremely likely that there existed a HFS+ driver for Linux. So I told my roommate, "don't worry, I don't have a PC, I'll be able to read it just fine." It was a little presumptuous of me to think that I wouldn't encounter any issues with mounting a HFS+ drive, but I have great faith in the Linux community.
I plugged his hard drive into my laptop, turned it on, opened xterm and typed:
fdisk -l
Fdisk listed his hard drive as /dev/sdb, but it also said that the drive's file system was unrecognizable, which I rather expected. A five-second Google search revealed that the modules for HFS and HFS+ are called "hfs" and "hfsplus." So I went into xterm again, and tried:
modprobe hfsplus
mount -t hfsplus /dev/sdb /media/hd
And the drive mounted without a problem.
According to SourceForge the hfsplus module offers full support for HFS+ file systems. So, yeah! Go Linux!
Categories
- Computers (27)
- Daily Log (18)
- Gadgets (5)
- Linux (34)
- Literature (20)
- Out Doors (23)
- Polyphasic Sleep (6)
- Programming (31)
- Random Stuff (47)
- School (43)
- Site News (26)
- Software (16)
- Stocks (6)
- Uncategorized (3)
- work (4)
Archives
- February 2016 (1)
- August 2014 (3)
- October 2013 (1)
- June 2013 (1)
- May 2013 (4)
- May 2012 (1)
- March 2012 (3)
- August 2011 (1)
- June 2011 (1)
- January 2011 (2)
- December 2010 (2)
- October 2010 (1)
- September 2010 (2)
- May 2010 (2)
- April 2010 (3)
- January 2010 (4)
- December 2009 (1)
- November 2009 (4)
- October 2009 (2)
- September 2009 (5)
- August 2009 (6)
- June 2009 (1)
- May 2009 (5)
- April 2009 (4)
- March 2009 (9)
- February 2009 (7)
- January 2009 (6)
- December 2008 (6)
- November 2008 (3)
- October 2008 (7)
- September 2008 (6)
- August 2008 (11)
- July 2008 (25)
- June 2008 (12)
- May 2008 (7)
- April 2008 (12)
- March 2008 (5)
- February 2008 (5)
- January 2008 (7)
- December 2007 (2)
- November 2007 (6)
- October 2007 (4)
- August 2007 (3)
- July 2007 (6)
- June 2007 (2)
- May 2007 (10)
- April 2007 (7)
Comments
- on Miyata Alumicross
- on Miyata Alumicross
- on Miyata Alumicross
- on Why I Hate Remote Working
- on My Old Trek 820
