I HATE APPLE

So in the processing of keeping up iTunes with my CD collection, I tried to rip Sunn O)))'s "Black One" about an hour ago. Now, my iBook won't spit the CD back out. It's little motor tries and tries and then gives up and re-loads the CD in iTunes. Fuck.

Already called AppleCare and they couldn't figure out anything. They just told me to either mail it in or take it to an Apple store. So, any tips before I make the long trek tomorrow morning? Sigh.

This CD won't fucking come out. Any other ideas before I take it to the shop?

http://discussions.apple.com/thread.jspa?messageID=1777942�

I know this sounds completely stupid but...

I tried to insert one of those small CDs into my iBook's drive hoping it would pull it in an read it like a normal cd by now its stuck inside. Should I bring it into the Apple Store to have it taken out or is there a much easier way for me to get it out such as tweezers or something? I really don't want to have to leave it at the store as I need it for school but I need the drive working. Thank you for any assistance!

For the record, I was not stupid enough to try putting an abnormally sized CD in the drive.

Ok oddly my father told me to hold it up, turn it sideways with the drive opening facing down and shake it once. The cd popped enough out to grab onto it and take it completely out. lWOw problem solved quickly hehe.

But this did work. I held the computer sideways and tried to eject it while shaking and it came right out. Man.

Because ext3 is better for the job, obv. It's more reliable than reiserfs, performs much better (IMX) on large files, and doesn't have much that reiserfs doesn't have.

I might consider using XFS if I had a system on a very reliable UPS that I was sure wouldn't go down unexpectedly. Not otherwise, though - if a machine gets turned off with XFS filesystems mounted, you *will* lose data. What other serious alternatives on Linux are there?

xpost!!

I've had severe performance problems with concurrent access to large files on reiserfs filesystems - "severe" meaning "causing processes to hang in the D-state for several minutes". These problems vanished when I moved the relevant files over to an ext3 filesystem.

Now, that's not going to be a problem for everyone. Not many people have databases with files over 4G in size, like we do. Nevertheless, Reiserfs clearly isn't up to the job for *that* task, and it doesn't have any advantages over properly-optimised ext3 for general fileserving.

I'm not going to get into an experience fight, but I *do* know what I'm talking about when it comes to Linux sysadmin stuff. Just to let you know.

Ext3 is a bag on the side of Ext2 which has been tuned the fuck out, but it is less than optimal design that needs to die.

Whatever the kernel version, I'm certainly not going to use reiserfs again where there is a risk of something like that happening. Yes, I could move off it - I did do - but that involves significant downtime.

Ext3 is a ... less than optimal design that needs to die.

It's fast, fully-featured, and very very solid.

What features does reiserfs have that ext3 doesn't? None that are worth trading the extra reliability for.

Compared to ext2 and ext3 in 2.4, when dealing with files under 4k and with tail packing enabled, ReiserFS is often faster by a factor of 10–15. This is of great benefit in Usenet news spools, HTTP caches, mail delivery systems and other applications where performance with small files is critical.

HAHAHA :(

I'd probably say reiser is ok for a dev workstation for these reasons, but yea, if you ran into those problems, avoid it. I had amazing performance with it being used to torrent tons of stuff while doing lots of huge compile jobs.

By contrast, ext2 and other Berkeley FFS-like filesystems simply use a fixed formula for computing inode locations, hence limiting the number of files they may contain.

A default ext3 filesystem, off the top of my head, has 1 inode for every 4k of disk space. Hence, if your average file size is under 4k then you'll run out of inodes before data blocks. I don't think there are many situations where that is likely to apply.

Most such filesystems also store directories as simple lists of entries, which makes directory lookups and updates linear-time operations and degrades performance on very large directories.

Ext3 doesn't have to, though - it can store directory contents either as a list or a b-tree.

Filesystem comparisons are hard to do, normally, because it's rare to switch between filesystems on one machine.

the gmail+growl site suggests some kind of weird shit is going down. it's been knackered for me since 9.30am BST today.

Also:

http://wizardishungry.com/lol/mail.png

Finally a PEEVE with Apple Mail -- Why doesn't each folder remember which columns you had turned on in it rather than the setup now where the columns are GLOBAL.

by the way, I LOVE TEKSERVE. hardware problem requiring new top casing & trackpad = fixed overnight.

Neither did I, until I started using Gmail. Conversations and fast-searching are such great additions to mail that I'm never going back. Spotlight can search -- slowly -- at home, but what about when I'm not? Mail.app and other clients have pissy little stabs at "threading", but they're all shit compared to conversations. And are useless away from home.

If only Gmail had IMAP, it would be the best of both worlds.