Companies can also pay a one-time $60k fee and never deal with decoder royalties again. This is nothing for a company like AOL, who owns Nullsoft (WinAmp).
It's only going to hurt small projects who can't afford to subsidize the users, especially when there's a $15k annual minimum involved.:P
Sorry - but - I understand the advantage (for RedHat) of branding. But what's the point of uglifying the rest?
Is the Gnome desktop that ugly with RedHat?
This seems like a pitifully inept job, if not downright malicious. KDE and Gnome both look pretty slick in their default installs under other distributions. Why the difference?
So the OS was released yesterday despite pending security problems. Were buyers told that they should wait a day for a patch, or were they left running vulnerable systems overnight?
These sound like point of sale terminals or similar. Are these machines networked?
If so, then it shouldn't matter what filesystem you use, so long as you mount it read-only. Then, keep all writable data on a RAM disk (for/temp and friends) and on the network (for real data).
If the systems are new enough, I'd even consider booting from CD or network and doing away with the hard drives completely.
Security requires constant and immediate upgrading.
Updates come with the risk of new security problems. Debian's security updates have fixes backported to old versions to minimize risk. Reconsidering, that's probably what the original poster expected people were auto-installing from cron jobs. Still, it's much better to do this manually if at all possible. Debian is exceptionally good about making security problems known as quickly as possible, even prior to the fix being available so that users can disable services or take other precautions as is appropriate to circumstance.
Merely leaving a job in place which snarfs the newest code from security is debatably a sane thing to do, but it's certainly not even half enough. It's important that any Debian user monitor debian-security at the very least.
My big question is - when have case-sensitive filenames ever worked to your advantage?
I like the system "correctness" of different ASCII values being treated differently. But the practical value escapes me.
That said, a large number of systems would break if the scheme changed. Given that most users use GUIs and rarely actually type names, is there a good reason to switch at this point? The few places where I see a true advantage (Windows compatibility, for example) have already handled this at the application layer.
From my searching, DVD-R seems to have the edge on price, especially for the media.
Unless the prices were to suddenly drop on the DVD+R burners or media, it's hard to see DVD-R not winning.
Of note - while they don't quite drive the market, they do make a difference: The Apple SuperDrives are DVD-R. I'm not sure there are any Apple DVD+R offerings.
Also of note - I bought a DVD+R drive early on, not knowing any better. I wish I'd gone with DVD-R or waited for one of the few drives which handle both.
I know the following sounds a little undignified, but unfortunately, that's the nature of her disease.
Can she control her breathing?
If so, some sort of a whistle pressed into the nostril, perhaps fitted with a silicon mold (places that do custom ear plugs or hearing aids could probably do this) would seem cheap and natural. Then she only need blow to rouse her husband.
They all but give them away, hoping to make their money back on expensive cartridges.
Exactly. So if you can find a color inkjet for $49.95, buy a couple of them. If its $24.95 for the black cartridge and $34.95 for the color cart, then you'll be saving money. Not to mention the fact being a cheap low-end printer its probably better to replace it every couple of months anyway
Careful. The cartridges included with HP printers are only filled half way.
Actually, many HP units had (still have?) bags of ink inside, compressed by metal leaf springs. If you puncture the cartridge to attempt a refill, it won't work. If you puncture the cartridge and the bag inside, you're in for a surprise when the ink all comes squirting out the hole afterward.
Those units are just like the old Koala Pads. It's a grid array of wires, which make contact when they touch. This means they can only accurately detect one position at once.
I don't trust them because I don't know if they're recording a bitmap or vector/spline data. The former is okay, but the latter, if intercepted, can be used to make an infinite number of unique-looking but valid signatures. So, I usually make swirls with a fingernail while I sign, making a valid paper signature and a cloud of noise on the screen, since the pad can't tell which of four moving coordinates is the real active one when two different points are pressed at once.
I've only ever had one merchant actually look at the screen and ask me to sign again. (He thought it was the unit's fault.) The rest seem to believe that the pad is checking my signature, not just recording it.
The best part: They all agreed that IRC was the ideal way to chat on the road... but nobody remembered to bring ircd.
So they had ot use talkd! AUUUUUUUUUUUUUUUUUUGHHHHHHHHH!!!!!!!!!!
It's also amusing that they still bothered to use ssh between each other's machines. I say -- any cracker dude who figures out how to snoop on my 802.11b traffic at 85m/h deserves my respect and my passwords!
First, find the cheapest printer [salescircular.com] you can...Circuit City has the Lexmark Z25 for $39.99 after rebate this week, but a better deal is at Office Max...Hewlett Packard DeskJet 825C for $49.99 (no rebate required), plus it's USB and it also comes with a free USB cable ($15 value).
It's worth mentioning that you should do your refill research before you pick the printer. A few of the cheaper printers (and many of the more expensive HP ones) have chips or fuses in a circuit on the print cartridge which tells it to expect no more than a certain amount of ink to thwart refills, or that the cart should be invalidated permanently.
Remember that printer manufacturers don't make money on low-end inkjets. They all but give them away, hoping to make their money back on expensive cartridges. And they're going to do all they can to try and prevent you from going elsewhere for 'em.
If you buy an Epson inkjet printer, throw away the ink that comes with it. Generic ink cartridges for the Stylus series can be had for under $2 per cartridge (yes, even the color ones) with one catch:
Epson's ink congeals on contact with most generic inks and jams up the ink path, often irreparably. This problem is mega, since Epsons have the printing unit built into the printer, not the cartridge as with HP carts.
I've not had a problem with mixing different kinds of generic ink however, so as long as an Epson never tastes an Epson cart, you're good to go.
It's also worth mentioning that there are replacement assemblies available for the epsons, which use tubes going from specially modified print heads to individual pint-sized ink reservoirs which sit in a box beside the printer. If you get one of these, you can print something like ten thousand pages of color without refilling.
This reminds me of programming the DSP and GPU in the Atari Jaguar.
Many instructions didn't implement scoreboarding correctly, and their strange little multiply unit would take more cycles to multiply some numbers than others.
This meant that it was possible to have code that worked correctly for some values, then for certain larger values, to suddently end up using one of the two arguments of the multiply as the result. The multiply simply didn't happen in time, and since the scoreboarding was broken, there wasn't a stall if you tried to use the result of the incomplete operation. Even worse than getting the wrong result, you could even end up having the result stuffed in a register at a point where you were now using it for another purpose!
I was talking to a coworker while I wrote the above. I should have stopped to read or at least add a few points before submitting. I like sharing info, so I'll just continue in another post:
Some of you may not know the difference between a physical and logical address. The big fun in the case of the DMA ignoring the MMU above, is that each time you run a program on a system with virtual memory, your logical (application-specific) address is likely to map to a different physical (hardware) address. This is also why bad RAM can cause failures in seemingly random ways.
It's also worth clarifying that DMA ignores not only the MMU, but cache memory, going straight to physical memory. I've yet to see an architecture where that wasn't true. This is why the bit with the data cache above is so nasty, especially on machines with large caches. It can put a large chunk of time between your corruption and your crash, which makes it hideously difficult to pinpoint the cause.
Also, as DMA is generally tied to very time-sensitive code, it's also worth mentioning that most operating systems/architectures do little or no checking on DMA, instead kicking it off as fast as is possible. This is the reason it's so easy to cause DMA problems, and why they're typically such a hairy area.
Lastly, DMA runs asynchronously. DMA, the CPU and other subsystems can all be banging on memory at the same time, with the DMA or the CPU taking priority, depending on the architecture or the DMA options specified. This makes it as bad as thread synchronization issues in many ways as well.
As a game programmer, and as someone who's banged on device drivers, I have to say there's no contest: The most fun bugs result from errant DMA.
It's really easy to set up a bad DMA chain on most architectures, and when that happens, it can do wonderful damage that's tough to reproduce.
One of the more fun things about it is that DMA generally ignores the MMU completely, so you can consistently trash whatever's at some physical address time and again, ignoring all protection.
Even better, DMA doesn't cause hardware breakpoints, so even if your debugger/system are capable of watching for all writes to a given address or page, it'll still merrily corrupt it.
Even more fun if data has been corrupted, but the correct data is still in the data cache from a previous access, making failures even more unpredictable, often relying on an interrupt or other random bit of interference clearing the cache.
On top of all this, a bad DMA chunk may not manifest itself in an obvious way. The program may crash in random sections well before you realize that the DMA you intended didn't happen, or the program may just keep on running with a single fram graphic glitch or a brief bit of static in the case of DMA meant to go to video or audio hardware. That's easy to miss when you're focussing on the debugger and not the running program.
I've seen products ship weeks late just because of a single hard-to-find DMA glitch.
I don't think I caught the original article; this was a fun one though:
When we were working on a game title on the Nintendo 64, we were maintaining a parallel version for Windows, as it was substantially easier to develop for. Basically, we created some rendering, sound, controller and I/O code for Windows that duplicated what we'd created on the N64.
At one point, we were trying to find some problems with the camera behavior, so we created a flying camera object that coincided with the real camera. It looked like an old Hollywood camera, though the lens cap, reels, everything was just flat black. Then, we'd set up a fixed camera and watch what the game camera would be trying to do by observing where the flying camera went.
Time passed, and we'd forgotten about the added camera altogether. Then, as we were approaching a critical milestone, we went to bring the N64 build up to date... and the screen was black.
The game seemed to be playing, the menus were there, and the framerate counter was up, but - black. The Z-buffer had a constant value all the way across it, meaning there was some mysterious polygon that was exactly covering the screen all the time.
We were there until something like 2am, trying to figure out what the hell was going on. We were risking blowing this milestone, and with that, taking on a pretty hefty late delivery penalty.
We finally figured it out. Stepping back... well, the N64 engine didn't support back-face culling at that point, whereas the Windows engine did. So what's the upshot of the whole thing?
One of the biggest problems here is that so many companies are permissive with dhcp. If security is a real concern, you shouldn't be handing out IP addresses to unknown MACs like christmas candy. Having to figure out a safe/available IP address ahead of time at least makes this more difficult.
Slashdot Mirror
It's only going to hurt small projects who can't afford to subsidize the users, especially when there's a $15k annual minimum involved. :P
Is the Gnome desktop that ugly with RedHat?
This seems like a pitifully inept job, if not downright malicious. KDE and Gnome both look pretty slick in their default installs under other distributions. Why the difference?
So the OS was released yesterday despite pending security problems. Were buyers told that they should wait a day for a patch, or were they left running vulnerable systems overnight?
If so, then it shouldn't matter what filesystem you use, so long as you mount it read-only. Then, keep all writable data on a RAM disk (for /temp and friends) and on the network (for real data).
If the systems are new enough, I'd even consider booting from CD or network and doing away with the hard drives completely.
Updates come with the risk of new security problems. Debian's security updates have fixes backported to old versions to minimize risk. Reconsidering, that's probably what the original poster expected people were auto-installing from cron jobs. Still, it's much better to do this manually if at all possible. Debian is exceptionally good about making security problems known as quickly as possible, even prior to the fix being available so that users can disable services or take other precautions as is appropriate to circumstance.
Merely leaving a job in place which snarfs the newest code from security is debatably a sane thing to do, but it's certainly not even half enough. It's important that any Debian user monitor debian-security at the very least.
A typical Debian user would not do this. Good god, that's a recipe for disaster!
"Typical" Debian users are more concerned with stability than they are in "upgrading" constantly.
And for what it's worth, Slashdot's article selection has been nothing, if not pro-Apple.
Hey - The Register is just a tabloid. Slashdot is a well-researched news site! Also, I have a flying car.
I like the system "correctness" of different ASCII values being treated differently. But the practical value escapes me.
That said, a large number of systems would break if the scheme changed. Given that most users use GUIs and rarely actually type names, is there a good reason to switch at this point? The few places where I see a true advantage (Windows compatibility, for example) have already handled this at the application layer.
Unless the prices were to suddenly drop on the DVD+R burners or media, it's hard to see DVD-R not winning.
Of note - while they don't quite drive the market, they do make a difference: The Apple SuperDrives are DVD-R. I'm not sure there are any Apple DVD+R offerings.
Also of note - I bought a DVD+R drive early on, not knowing any better. I wish I'd gone with DVD-R or waited for one of the few drives which handle both.
Can she control her breathing?
If so, some sort of a whistle pressed into the nostril, perhaps fitted with a silicon mold (places that do custom ear plugs or hearing aids could probably do this) would seem cheap and natural. Then she only need blow to rouse her husband.
And instead of stabbing someone, we'll put them in a stabbing machine -- then we walk free and clear!
Careful. The cartridges included with HP printers are only filled half way.
Truth be told, I was just shooting for funny.
Actually, many HP units had (still have?) bags of ink inside, compressed by metal leaf springs. If you puncture the cartridge to attempt a refill, it won't work. If you puncture the cartridge and the bag inside, you're in for a surprise when the ink all comes squirting out the hole afterward.
I don't trust them because I don't know if they're recording a bitmap or vector/spline data. The former is okay, but the latter, if intercepted, can be used to make an infinite number of unique-looking but valid signatures. So, I usually make swirls with a fingernail while I sign, making a valid paper signature and a cloud of noise on the screen, since the pad can't tell which of four moving coordinates is the real active one when two different points are pressed at once.
I've only ever had one merchant actually look at the screen and ask me to sign again. (He thought it was the unit's fault.) The rest seem to believe that the pad is checking my signature, not just recording it.
So they had ot use talkd! AUUUUUUUUUUUUUUUUUUGHHHHHHHHH!!!!!!!!!!
It's also amusing that they still bothered to use ssh between each other's machines. I say -- any cracker dude who figures out how to snoop on my 802.11b traffic at 85m/h deserves my respect and my passwords!
It's worth mentioning that you should do your refill research before you pick the printer. A few of the cheaper printers (and many of the more expensive HP ones) have chips or fuses in a circuit on the print cartridge which tells it to expect no more than a certain amount of ink to thwart refills, or that the cart should be invalidated permanently.
Remember that printer manufacturers don't make money on low-end inkjets. They all but give them away, hoping to make their money back on expensive cartridges. And they're going to do all they can to try and prevent you from going elsewhere for 'em.
Epson's ink congeals on contact with most generic inks and jams up the ink path, often irreparably. This problem is mega, since Epsons have the printing unit built into the printer, not the cartridge as with HP carts.
I've not had a problem with mixing different kinds of generic ink however, so as long as an Epson never tastes an Epson cart, you're good to go.
It's also worth mentioning that there are replacement assemblies available for the epsons, which use tubes going from specially modified print heads to individual pint-sized ink reservoirs which sit in a box beside the printer. If you get one of these, you can print something like ten thousand pages of color without refilling.
Many instructions didn't implement scoreboarding correctly, and their strange little multiply unit would take more cycles to multiply some numbers than others.
This meant that it was possible to have code that worked correctly for some values, then for certain larger values, to suddently end up using one of the two arguments of the multiply as the result. The multiply simply didn't happen in time, and since the scoreboarding was broken, there wasn't a stall if you tried to use the result of the incomplete operation. Even worse than getting the wrong result, you could even end up having the result stuffed in a register at a point where you were now using it for another purpose!
I'd take that in a hearbeat!
Some of you may not know the difference between a physical and logical address. The big fun in the case of the DMA ignoring the MMU above, is that each time you run a program on a system with virtual memory, your logical (application-specific) address is likely to map to a different physical (hardware) address. This is also why bad RAM can cause failures in seemingly random ways.
It's also worth clarifying that DMA ignores not only the MMU, but cache memory, going straight to physical memory. I've yet to see an architecture where that wasn't true. This is why the bit with the data cache above is so nasty, especially on machines with large caches. It can put a large chunk of time between your corruption and your crash, which makes it hideously difficult to pinpoint the cause.
Also, as DMA is generally tied to very time-sensitive code, it's also worth mentioning that most operating systems/architectures do little or no checking on DMA, instead kicking it off as fast as is possible. This is the reason it's so easy to cause DMA problems, and why they're typically such a hairy area.
Lastly, DMA runs asynchronously. DMA, the CPU and other subsystems can all be banging on memory at the same time, with the DMA or the CPU taking priority, depending on the architecture or the DMA options specified. This makes it as bad as thread synchronization issues in many ways as well.
It's really easy to set up a bad DMA chain on most architectures, and when that happens, it can do wonderful damage that's tough to reproduce.
One of the more fun things about it is that DMA generally ignores the MMU completely, so you can consistently trash whatever's at some physical address time and again, ignoring all protection.
Even better, DMA doesn't cause hardware breakpoints, so even if your debugger/system are capable of watching for all writes to a given address or page, it'll still merrily corrupt it.
Even more fun if data has been corrupted, but the correct data is still in the data cache from a previous access, making failures even more unpredictable, often relying on an interrupt or other random bit of interference clearing the cache.
On top of all this, a bad DMA chunk may not manifest itself in an obvious way. The program may crash in random sections well before you realize that the DMA you intended didn't happen, or the program may just keep on running with a single fram graphic glitch or a brief bit of static in the case of DMA meant to go to video or audio hardware. That's easy to miss when you're focussing on the debugger and not the running program.
I've seen products ship weeks late just because of a single hard-to-find DMA glitch.
When we were working on a game title on the Nintendo 64, we were maintaining a parallel version for Windows, as it was substantially easier to develop for. Basically, we created some rendering, sound, controller and I/O code for Windows that duplicated what we'd created on the N64.
At one point, we were trying to find some problems with the camera behavior, so we created a flying camera object that coincided with the real camera. It looked like an old Hollywood camera, though the lens cap, reels, everything was just flat black. Then, we'd set up a fixed camera and watch what the game camera would be trying to do by observing where the flying camera went.
Time passed, and we'd forgotten about the added camera altogether. Then, as we were approaching a critical milestone, we went to bring the N64 build up to date... and the screen was black.
The game seemed to be playing, the menus were there, and the framerate counter was up, but - black. The Z-buffer had a constant value all the way across it, meaning there was some mysterious polygon that was exactly covering the screen all the time.
We were there until something like 2am, trying to figure out what the hell was going on. We were risking blowing this milestone, and with that, taking on a pretty hefty late delivery penalty.
We finally figured it out. Stepping back... well, the N64 engine didn't support back-face culling at that point, whereas the Windows engine did. So what's the upshot of the whole thing?
We'd left the lens cap on.
One of the biggest problems here is that so many companies are permissive with dhcp. If security is a real concern, you shouldn't be handing out IP addresses to unknown MACs like christmas candy. Having to figure out a safe/available IP address ahead of time at least makes this more difficult.