The CPU in Centrino machines is a Pentium M, which is basically a souped-up Pentium III (includes SSE2 instructions, for example). It is not in the same family as the Pentium 4. I got a Centrino laptop for my dad (Dell Inspiron 500m), and while I was setting it up for him, netbooted NetBSD and ran some benchmarks and compiles to get a feel for the performance. I was impressed by the speed and battery life; it's a bit faster than the PIII per clock, but has much lower power consumption. I had expected it to be in the P4 family, with the associated low instructions-per-cycle, but was pleasantly surprised. I wouldn't mind having a desktop machine with a Pentium M processor... I'm not a gamer and don't need a superfast CPU; I'd be happy with a slower CPU that didn't need to run its fan all the time.
Huh? I guess you didn't realize that Apple credited @stake for reporting the vulnerabilities? They're fixed in Panther because @stake told Apple about them during the Panther beta. We didn't hear about it until now because @stake agreed to wait until Panther's release before disclosing the vulnerabilities.
I believe the code was part of detection routine to see if the drives supported writing (packet based writing specifically).
No, take a look at the source code (this is Linux we're talking about here; source is easy to get:)--look for the callers of pkt_flush_cache() in drivers/block/pktcdvd.c and you'll see that FLUSH CACHE is issued to flush all pending writes when the CD device is closed. Unfortunately, it's being called even if the drive doesn't support writing.
I'm curious why people think it was used to detect whether a drive supported writing or not; I've seen that same speculation from a few other people. Perhaps leonbrooks's highly-scored post is the source of this misinformation? (And I still don't see why he continues to think that something needs to be done to enable packet writing on a read-only CD-ROM drive... Oh well, I guess for him, Mandrake can do no wrong).
A matrix? The "squares" you move on aren't even square (or rectangular)... No, it's like what Illbay was describing... Here's a link describing the history of the game, and they even have a scan of the rules online.
I miss the good ol' game...
I think it's still being sold... you can be a winner at the game of life!:)
If you get this many complaints that your submission was poorly written, then face it: it was poorly written. In the future, I suggest you stick to a concise description of the story, and resist the urge to add a sarcastic editorial of your own.
In the US, there's no nationwide standard for voting equipment. Each county (a subdivision of a state) can do things their own way. Where I live, we use paper ballots where you use a pencil to fill in an oval next to the name of the person you want to vote for. The ballots are then run through a scanning machine to automatically count the votes, but the original paper ballot is available for inspection if needed. This seems like a good method to me; I hope the local government doesn't decide to switch to some electronic voting method like some other counties in the state have.
No, it's not an upgrade price if someone who doesn't own any version of MacOS (say, a Commodore 64 user) can buy it for the same price. The concept of an "upgrade price" is that someone who has paid full price for an earlier version of the software is entitled to a discount on a newer version. I see no discount here.
I've got Jaguar right now, and while Panther does have some interesting new features, they're not worth $130 to me. Apple needs to offer upgrade versions... 50% off if you own 10.2, 20% off if you own 10.0 or 10.1, or something along those lines.
No, UTSL. pktcdvd.c unconditionally calls FLUSH CACHE to make sure all pending writes are written to the disc before the device is closed. It is not used to determine whether a drive is a writer or not--the real way to do that is to get the capabilities mode page from the drive. It'll tell you what media it supports reading from, what media it'll write to, the read and write speeds, etc...
Huh? Where did you get the idea that the FLUSH CACHE was used to determine whether or not the device was a writer or not? Look at pkt_flush_cache() in drivers/block/pktcdvd.c... it's used to flush the cache of pending writes when closing the CD device.
I saw Juan Quintela's message to the list too, but I get the impression that he's just speculating that LG treats FLUSH CACHE as UPLOAD FIRMWARE; it's not like we've got any official word from LG other than "we don't support Linux." All we know is that for the drives in question, FLUSH CACHE renders the drive inoperative. Note that the ATA standard defines a "DOWNLOAD MICROCODE" command for uploading firmware. Juan's message mentions that the -21mdk kernel fixes the problem... looks like the fix was just to remove the packet writing support.
Anyways, don't use FLUSH CACHE to determine whether a device is a writer or not--that's a lame way to do it. Writers these days support the MMC command set (and the old ones that don't aren't gonna do packet writing anyway)--get the Capabilities and Mechanical Status mode page instead; it'll return bits saying whether the drive supports writing to CD-R, CD-RW, DVD-R, etc...
They were talking about flushing the READ cache, iirc
Well, they shouldn't be expecting undocumented, nonstandard behavior then. As I said in my original post, the ATAPI FLUSH CACHE command flushes the write cache. See section 8.12 of the ATAPI specs. I don't think there's any standard ATAPI command to flush the read cache.
The thing which kills the drives is - wait for it - setting them up for packet writing.
Why would you want to set up a CD-ROM drive for packet writing. CD-ROM drives can't write--that's why they're called CD-ROMs and not CD-Rs or CD-RWs.
The hackers who made the patch to do this (included starting with Mandrake 9.2rc1) may be able to figure out a way to do it without triggering LG's bug
I got an idea... how about don't try to enable packet writing on a CD-ROM drive!
Why is Linux trying to send a flush cache command to a CD-ROM drive in the first place? That's a stupid thing to do. The ATAPI FLUSH CACHE command tells the device to flush its write cache to the media. A CD-ROM has no write cache, and can't write to any media. Of course, it's even more stupid for a drive to self-destruct when it gets a flush cache command...
No, that's not what "standard" means. Being a standard command means that when you send that command to the drive, the drive will perform a specific, documented action. If the command in question is the "flush cache" one, as some have said, the documented action is "... to flush the write cache. If there is data in the write
cache, that data shall be written to the media." [ATA draft spec]. If a drive destroys itself when it receives a flush cache command, it's not following the standard. Of course, one wonders why Linux is trying to flush the write cache of a read-only CD-ROM drive, but that's beside the point.
Anyway, a standard command doesn't mean that every OS is required to send that command; it means that if an OS sends that command, it can expect a certain result.
The question is why doesn't the printer do flow control? My first printer, a Star Gemini 10X from around 20 years ago, knew how to tell the computer to stop sending data when it couldn't take anymore. Why can't a modern $1000+ printer do the same thing? Maybe you should just get a Zebra label printer instead or something... save you the time and expense of trying to make the Intermec work.
iron, gold, and silver are translations... ferrum, aurum, and argentum are the Latin names (which is why the symbols for those elements are Fe, Au, and Ag). The "um" ending just sounds traditional and Latin...
Yeah, I have a few of the Thai 50 baht notes that were printed in Australia, and they're pretty nice. You can scrape the ink off though; is that still a problem with the modern notes?
Put a quarter and a saajuea in your pocket and try to tell which is which. How would blind people tell the difference?
I suggest you actually try this, instead of posing the question on Slashdot. The quarter has a reeded edge, whereas the Sacagawea dollar is smooth. It's trivial to tell the difference without looking.
Obviously you don't own an Xserve, a PowerMac G4, or use any Bluetooth devices, for starters.
Well, I own a PowerMac G4 (dual 500MHz). No problems with the 10.2.8 update that I know of--maybe I lost 10BaseT support, but my LAN's been 100BaseTX for a few years now.
Yeah, I goofed on the PAL30 thing. I agree that most PAL sets support PAL 60, but I think you're overstating it when you say that 99% of TVs in Europe support NTSC. This list shows which formats various TVs support, and while just about all of them support PAL and PAL 60, only a few also support NTSC.
And I do think PAL is superior to NTSC both in terms of resolution and color quality, but the 50Hz bothers me. I almost always see flickering on TVs when I go to PAL countries... but maybe I've only been seeing crap TVs:) (and it's been about 5 years since I last saw PAL... will be going overseas in November though, so perhaps I'll get to see some modern sets). I haven't seen a PAL 60 signal yet...
Yes, there is a difference in resolution, but this is compensated for in the player.
What about the frame rate? That's not something that can be easily compensated for (at least not if you want good video quality). You mentioned playing NTSC discs on your region-free player on a PAL TV set, so you're lucky that your set can display so-called PAL30 signals--a signal with the PAL color encoding scheme, but 30 frames per second. In the US, regular TVs only display standard 30fps NTSC. If you put a PAL region-free disc in a standard US region-locked DVD player, it'll play, but the player outputs NTSC at 25fps, and the TV can't synch up to it. You'll see a picture, but it flashes and jumps around vertically. Some region-free players will do the right thing and play PAL DVDs at 30 fps. This speeds up the video slightly, but isn't noticeable unless you're actually timing the thing.
But the point is, contrary to your claim, discs are labelled NTSC or PAL, and it does matter which it is.
Slashdot Mirror
The CPU in Centrino machines is a Pentium M, which is basically a souped-up Pentium III (includes SSE2 instructions, for example). It is not in the same family as the Pentium 4. I got a Centrino laptop for my dad (Dell Inspiron 500m), and while I was setting it up for him, netbooted NetBSD and ran some benchmarks and compiles to get a feel for the performance. I was impressed by the speed and battery life; it's a bit faster than the PIII per clock, but has much lower power consumption. I had expected it to be in the P4 family, with the associated low instructions-per-cycle, but was pleasantly surprised. I wouldn't mind having a desktop machine with a Pentium M processor... I'm not a gamer and don't need a superfast CPU; I'd be happy with a slower CPU that didn't need to run its fan all the time.
Huh? I guess you didn't realize that Apple credited @stake for reporting the vulnerabilities? They're fixed in Panther because @stake told Apple about them during the Panther beta. We didn't hear about it until now because @stake agreed to wait until Panther's release before disclosing the vulnerabilities.
No, take a look at the source code (this is Linux we're talking about here; source is easy to get :)--look for the callers of pkt_flush_cache() in drivers/block/pktcdvd.c and you'll see that FLUSH CACHE is issued to flush all pending writes when the CD device is closed. Unfortunately, it's being called even if the drive doesn't support writing.
I'm curious why people think it was used to detect whether a drive supported writing or not; I've seen that same speculation from a few other people. Perhaps leonbrooks's highly-scored post is the source of this misinformation? (And I still don't see why he continues to think that something needs to be done to enable packet writing on a read-only CD-ROM drive... Oh well, I guess for him, Mandrake can do no wrong).
I miss the good ol' game...
I think it's still being sold... you can be a winner at the game of life! :)
If you get this many complaints that your submission was poorly written, then face it: it was poorly written. In the future, I suggest you stick to a concise description of the story, and resist the urge to add a sarcastic editorial of your own.
In the US, there's no nationwide standard for voting equipment. Each county (a subdivision of a state) can do things their own way. Where I live, we use paper ballots where you use a pencil to fill in an oval next to the name of the person you want to vote for. The ballots are then run through a scanning machine to automatically count the votes, but the original paper ballot is available for inspection if needed. This seems like a good method to me; I hope the local government doesn't decide to switch to some electronic voting method like some other counties in the state have.
What, this? I don't know if he's gotten rich off of it, but at $70 a pop, he's probably turned a profit.
No, it's not an upgrade price if someone who doesn't own any version of MacOS (say, a Commodore 64 user) can buy it for the same price. The concept of an "upgrade price" is that someone who has paid full price for an earlier version of the software is entitled to a discount on a newer version. I see no discount here.
I've got Jaguar right now, and while Panther does have some interesting new features, they're not worth $130 to me. Apple needs to offer upgrade versions... 50% off if you own 10.2, 20% off if you own 10.0 or 10.1, or something along those lines.
No, UTSL. pktcdvd.c unconditionally calls FLUSH CACHE to make sure all pending writes are written to the disc before the device is closed. It is not used to determine whether a drive is a writer or not--the real way to do that is to get the capabilities mode page from the drive. It'll tell you what media it supports reading from, what media it'll write to, the read and write speeds, etc...
I saw Juan Quintela's message to the list too, but I get the impression that he's just speculating that LG treats FLUSH CACHE as UPLOAD FIRMWARE; it's not like we've got any official word from LG other than "we don't support Linux." All we know is that for the drives in question, FLUSH CACHE renders the drive inoperative. Note that the ATA standard defines a "DOWNLOAD MICROCODE" command for uploading firmware. Juan's message mentions that the -21mdk kernel fixes the problem... looks like the fix was just to remove the packet writing support.
Anyways, don't use FLUSH CACHE to determine whether a device is a writer or not--that's a lame way to do it. Writers these days support the MMC command set (and the old ones that don't aren't gonna do packet writing anyway)--get the Capabilities and Mechanical Status mode page instead; it'll return bits saying whether the drive supports writing to CD-R, CD-RW, DVD-R, etc...
Well, they shouldn't be expecting undocumented, nonstandard behavior then. As I said in my original post, the ATAPI FLUSH CACHE command flushes the write cache. See section 8.12 of the ATAPI specs. I don't think there's any standard ATAPI command to flush the read cache.
Some drives can, but no CD-ROM drives can. This problem only affects LG plain CD-ROM drives.
Why would you want to set up a CD-ROM drive for packet writing. CD-ROM drives can't write--that's why they're called CD-ROMs and not CD-Rs or CD-RWs.
The hackers who made the patch to do this (included starting with Mandrake 9.2rc1) may be able to figure out a way to do it without triggering LG's bug
I got an idea... how about don't try to enable packet writing on a CD-ROM drive!
Why is Linux trying to send a flush cache command to a CD-ROM drive in the first place? That's a stupid thing to do. The ATAPI FLUSH CACHE command tells the device to flush its write cache to the media. A CD-ROM has no write cache, and can't write to any media. Of course, it's even more stupid for a drive to self-destruct when it gets a flush cache command...
Anyway, a standard command doesn't mean that every OS is required to send that command; it means that if an OS sends that command, it can expect a certain result.
The question is why doesn't the printer do flow control? My first printer, a Star Gemini 10X from around 20 years ago, knew how to tell the computer to stop sending data when it couldn't take anymore. Why can't a modern $1000+ printer do the same thing? Maybe you should just get a Zebra label printer instead or something... save you the time and expense of trying to make the Intermec work.
iron, gold, and silver are translations... ferrum, aurum, and argentum are the Latin names (which is why the symbols for those elements are Fe, Au, and Ag). The "um" ending just sounds traditional and Latin...
Yeah, I have a few of the Thai 50 baht notes that were printed in Australia, and they're pretty nice. You can scrape the ink off though; is that still a problem with the modern notes?
I suggest you actually try this, instead of posing the question on Slashdot. The quarter has a reeded edge, whereas the Sacagawea dollar is smooth. It's trivial to tell the difference without looking.
Modern hard drives park themselves when power is removed, or when they're told to spin down via software.
Well, I own a PowerMac G4 (dual 500MHz). No problems with the 10.2.8 update that I know of--maybe I lost 10BaseT support, but my LAN's been 100BaseTX for a few years now.
And I do think PAL is superior to NTSC both in terms of resolution and color quality, but the 50Hz bothers me. I almost always see flickering on TVs when I go to PAL countries... but maybe I've only been seeing crap TVs :) (and it's been about 5 years since I last saw PAL... will be going overseas in November though, so perhaps I'll get to see some modern sets). I haven't seen a PAL 60 signal yet...
Whoops, the 30fps PAL is known as PAL60, not PAL30... 60 fields per second.
What about the frame rate? That's not something that can be easily compensated for (at least not if you want good video quality). You mentioned playing NTSC discs on your region-free player on a PAL TV set, so you're lucky that your set can display so-called PAL30 signals--a signal with the PAL color encoding scheme, but 30 frames per second. In the US, regular TVs only display standard 30fps NTSC. If you put a PAL region-free disc in a standard US region-locked DVD player, it'll play, but the player outputs NTSC at 25fps, and the TV can't synch up to it. You'll see a picture, but it flashes and jumps around vertically. Some region-free players will do the right thing and play PAL DVDs at 30 fps. This speeds up the video slightly, but isn't noticeable unless you're actually timing the thing.
But the point is, contrary to your claim, discs are labelled NTSC or PAL, and it does matter which it is.