I have a cheap, bog standard LG brand SATA drive that seems to do OK. I don't rip audio CDs very often, but last time I did (I just do "cdparanoia -B") it didn't seem to take long.

Here's my output of "cdparanoia -A" (I did this three times with similar result)

This is on Linux 3.6.5 on x86_64.

grogan@getstuffed:~$ cdparanoia -A
cdparanoia III release 10.2 (September 11, 2008)

Using cdda library version: 10.2
Using paranoia library version: 10.2
Checking /dev/cdrom for cdrom...
                Testing /dev/cdrom for SCSI/MMC interface
                                SG_IO device: /dev/sr0

CDROM model sensed sensed: HL-DT-ST DVDRAM GH24LS50 YP01

Checking for SCSI emulation...
                Drive is ATAPI (using SG_IO host adaptor emulation)

Checking for MMC style command set...
                Drive is MMC style
                DMA scatter/gather table entries: 1
                table entry size: 524288 bytes
                maximum theoretical transfer: 222 sectors
                Setting default read size to 27 sectors (63504 bytes).

Verifying CDDA command set...
                Expected command set reads OK.

Attempting to set cdrom to full speed...
                drive returned OK.

=================== Checking drive cache/timing behavior ===================

Seek/read timing:
                [74:21.35]: 62ms seek, 0.32ms/sec read [41.8x]
                [70:00.32]: 56ms seek, 0.32ms/sec read [41.5x]
                [60:00.32]: 57ms seek, 0.35ms/sec read [37.9x]
                [50:00.32]: 61ms seek, 0.37ms/sec read [35.7x]
                [40:00.32]: 58ms seek, 0.41ms/sec read [32.8x]
                [30:00.32]: 61ms seek, 0.45ms/sec read [29.7x]
                [20:00.32]: 62ms seek, 0.51ms/sec read [26.2x]
                [10:00.32]: 73ms seek, 0.58ms/sec read [22.9x]
                [00:00.32]: 71ms seek, 0.74ms/sec read [18.1x]

Analyzing cache behavior...
                Approximate random access cache size: 16 sector(s)
                Drive cache tests as contiguous
                Drive readahead past read cursor: 234 sector(s)
                Cache tail cursor tied to read cursor
                Cache tail granularity: 1 sector(s)
                                Cache read speed: 0.14ms/sector [94x]
                                Access speed after backseek: 0.71ms/sector [18x]
                Backseek flushes the cache as expected

Drive tests OK with Paranoia.

I didn't say it could randomly load arbitrary code. The grubx64.efi (whether it's actually grub to be chainloaded or something else renamed) gets signed when the user imports the key from disk, so if it's maliciously replaced after that, it would fail to load. I actually did read the whole article (I did try to explain why I think MS won't like this), and all of the comments including new ones that appeared later and I do understand how this works and what it implies. I assumed that I didn't need to parrot the article or comments, because you would have read them too.

The author doesn't believe that they will do so (nor do I) as proper procedure was followed and it's non malicious, but it is acknowledged that it could be pretty short lived if Microsoft blacklists the key.

It was not a compromise between agreeing humans, the signing process is (mostly) automated but yes, I am sure they are aware of it now. We'll see what is said about this.

Yes, you're correct about this particular signed shim being x86 only. But it will be tried for ARM as well, you can bet on that. It is on ARM where something like this will be most needed. We'll see if an ARM bootloader shim survives this signing process.

MS isn't going to like this. Whether they would try to stop it, or could get away with it is another matter. I'll be more curious to see what happens with ARM.

The signing process is relatively mechanical... Joe Blow could do it (with the proper notarization) and there is no way they can consider the full functionality of the binary that you upload to be signed. You put your credentials on the line, you pay the money, you get your binary certified. If it's bad, then there is someone to go after. The way they have set this up, it can only be reactive.

The implications of this will not make them happy. I'm betting that you would realize that this is being done for more than just our "safety". They want to make it a pain in the ass to use anything else, especially with Windows RT on ARM (where you can't allow secure boot to be disabled if you want your shiny Windows 8 compliance sticker), where they think they can seize control now at this crossroads. Windows 8 is designed to steer everyone towards the Microsoft Software Store.

This signed Grub shim is a wildcard, and it only needs to be done once. A barrier has been removed, that will rightly enable others to skip the BS.

You're right though, given that they followed due process and are not malicious, Microsoft will not be able to do anything about it. It is, however, my opinion that they will complain, as this was not the intent of the signing process.

Here's what's funny. The chainloaded "Grub" boot loader is actually circumventing the secure boot, because it has its own "OS kernel-like" functionality until it passes control over to the kernel components that it's booting. Grub was used to circumvent Microsoft's DRM, and now it will be used to circumvent their secure boot nonsense. I love it.

Grub is way more complex, knowledgeable (figuratively speaking... it's got high level filesystem drivers etc.) and functional than any bootloader Microsoft would envision. They'll be crying foul. Not only will this be used to boot Linux, but it will also allow booting any other OS without signing.

... and fuck you small minded twats with moderator points. I'm tired of being admonished by people who don't know what they are talking about.

Dell does NOT manufacture the hardware, they pay companies like FoxConn to make the boards, and of course the chipsets and onboard devices are made by their respective manufacturers, even if the firmware identifies "Dell".

The Linux community writes kernels components and drivers that DETECT the hardware and probe for settings. This way you don't need a specific ".inf file" definition (windows terminology) because it identifies itself as a "Dell wireless adapter" (for example) and they changed a few parameters to make it different than a bog standard Atheros device.

It is certainly NOT Dell that provides any sort of "Linux compatibility". They don't write the drivers for Windows either!

Fuck off... Dell doesn't manufacture hardware.

The Linux community does the work to ensure that the kernel and userspace driver frameworks can work with existing hardware on the market. Not "Dell engineers". It's not difficult to choose Linux compatible hardware. I do it before purchasing any hardware/computer/laptop and I haven't led myself astray yet.

No, it won't be worth it to me in the long run. (only in the short term... it might save me some work if I actually liked Ubuntu, which I don't. I'd be blasting that in favour of a distro that I like better anyway)

Linux is free... if they can't sell a laptop with a free OS on it, for at least the same price as the shitware load, then something is rotten. It's probably more like the lack of kickbacks from the shitware vendors. Also, Microsoft practically gives Windows away to OEMs (usually with strings attached) to maintain their stranglehold.

I would not reward Dell for their whoring.

"Buying" (you don't really own fuck all when you pay for content) a movie doesn't entitle you to go and download it from whatever source you wish. You will still be subject to the same legal perils as everyone else. In fact under Canada's new copyright provisions, being disallowed to break digital locks (DRM) trumps all other provisions of fair use and it's going to be illegal to even make a copy of a DVD. In fact software that circumvents the CSS will no longer be legal to distribute in Canada.

It remains to be seen what they are going to enforce, but think before casually accepting "this law". You can bet that if laws are written in the books a certain way, the copyright creeps will be lobbying, demanding that they be enforced to the letter, to their benefit.

You people are so full of shit. There's more to it than just memory use. (I don't give a fuck anyway, my browser can have 8 Gb of RAM if it will take it)

Browsers are one of thing things that DO benefit from a 64 bit build because they handle relatively large amounts of data and can do it with fewer clock cycles.

Stop spreading FUD, you apologist for lazy cunts.

... and here I used up all my mod points. I don't know what their problem is, it surely can't take much to keep it compiling for x64 under Windows.

I can almost understand why it took them so long to come out with a 64 bit flash plugin (for either platform) though. Imagine what a fuckstick mess that code base would be. It's proprietary, changed hands so many times, and the result is a 10 megabyte+ monstrosity of a library (my current 64 bit libflashplayer.so is 18 megabytes, lol). It was probably a bitch bastard to get to compile at first.

Firefox has no excuse for not having 64 bit builds available. (Yes, binaries. It's a different environment. More homogeneous, which makes it easier for them, but it's also not so easy for Windows users to set up a build environment to compile their own)

What? Fuck off... that's the browser I use to check my forums etc. in Windows (because it's a 64 bit build). Like I'm going to stay with alpha quality code that's no longer updating.

Oh well, if I have to use a 32 bit browser I guess it will be Google Chrome. (I don't use Firefox in Linux anymore, I do Chromium builds once a week or so)

I don't have a build environment in Windows, that's such a pain in the ass. I just have Windows for gaming, so I don't do that stuff.

I'm pretty much all out of uses for Mozilla Firefox. I don't even like it anymore, with the stupid things they've done and the user interface etc. They even keep removing about:config options.

If I wanted something, I'd already have it. I don't go to feeding frenzies to compete with humanity just to save a few bucks. My time is worth more to me.

I also really dislike crowds and queues etc. I can control it (I'm not going to flip out) but I do get angry and something like (but not the same as) claustrophobic when in crowds.

You would have to be a "full time stoner" (regular user) to understand it. It affects people differently (that's where I will agree that there is some danger) but generally, a long time, experienced user is not intoxicated or significantly impaired by moderate cannabis use. It's more akin to having a cup of coffee than an intoxicant and that's the mindset of most chronic users.

I think observation (did the driver actually do anything wrong?) and field sobriety tests should be given more weight than drug testing for the presence of cannabis metabolites. This method would also catch people who are sleep deprived, or trying to function while ill when they should have stayed home. (Such people should be warned, not charged though. You have to draw the line somewhere. We can't possibly forbid driving for all conditions where people aren't at their best)

I've been smoking it several times a day, for 35+ years now and I have friends in their 70's who have been smoking it for 50+ years. However, a novice user tripping out on potent cannabis certainly would be impaired. Unlike alcohol (which lowers inhibitions) though, they would probably themselves be scared to drive. They would most likely FEEL inhibited and say "I'm not goin nowhere!" (an actual quote that I will always remember, from someone in that very situation. It was funny to me at the time). I have seen this many times. Go smoke someone up before we go somewhere and have them realize they are now too messed up. Some people won't even go out in public, let alone drive.

So no, I don't believe it is as dangerous as alcohol. It can't be ignored, but it also isn't appropriate to treat it the same way as alcohol "DUI".

I'm in Canada, by the way. It's a bit more tolerated by folks here (I don't mean government or law enforcement, it's illegal and criminal to possess or drive under the influence) and it's not so stigmatized. So users can lead perfectly normal lives.

Of course, anyone whose career depends on drugs being illegal is going to lobby against even one inch of compromise. It is disingenuous for that U.N. drug watchdog cocksucker to even comment on the issue.

That's why you never ask police their opinion on things like this either. (and yes, I know of L.E.A.P. but they are a very small minority). Their unions would forbid them, even if they wanted to be honest and objective. Anything that reduces the need for more policing would be against their interests.

The prison industry was one of the biggest lobbyists against legalization, during the California cannabis referendum.