One of the wireless devices I needed to talk to in order to figure out what was going on had crappy serial port driver hardware for its debugging interface. It wouldn't drive a cable long enough to reach the base of the rooftop, too many transmission glitches to work right.
The router worked fine on the bench; only acted funny when connected to the antenna on top of the building, on the wireless grid at that point. Had to debug the problem live to see it.
I once had a job at a wireless ISP where I would regularly troubleshoot disfunctional rooftop routers located on an antenna mast. This sometimes left me balancing my laptop on top of a ladder in order to connect to the crashed device, which was particularly fun on high buildings during windy days. Every tried to troubleshoot and fix a kernel panic by tweaking kernel driver source code in a situation where you could fall to your death if you lost your balance? It would make an awesome geek extreme sport.
There's been plenty of speculation that Sun was interested more in MySQL from the sales side of things than from the technology one. MySQL had figured out how to sell open-source solutions to people for money successfully, something Sun would like to do more of. The high-profile engineers can jump to other projects on a whim, that doesn't necessarily mean they've lost what they wanted out of the purchase.
The Oracle pl/SQL -> PostgreSQL pl/pgSQL link you suggested was from PostgreSQL 7.1, pretty ancient at this point. PostgreSQL 8.3 Porting from Oracle is a current resource.
If a system gives memtest86 errors, I break it down and swap components until it doesn't. The test pattern it uses can find subtle errors you're unlikely to run into with any application-based testing even when run for a few days. Any failures it reports should be taken seriously. Also: you should pay a attention to the memory speed value it reports, that's a surprisingly effective simple benchmark for figuring out if you've setup your RAM optimally. The last system I built, I ended up purchasing 4 different sets of RAM, and there was about a 30% delta between how well the best and worst performed on the memtest86 results--correlated extremely well with other benchmarks I ran too.
At the same time, I've had memory that memtest86 said was fine, but the system itself still crashed under a heavy Linux-based test. I consider both a full memtest86 test and a moderate workload Linux test to be necessary before I consider a new system to have baseline usable reliability.
There are a few separate problems here that are worthwhile to distinguish among. A significant amount of RAM doesn't work reliably when tested fully. Once you've culled those out, only using the good stuff, some of that will degrade over time to where it will no longer pass a repeat of the initial tests; I recently had a perfectly good set of RAM degrade to useless in only 3 months here. After you take out those two problematic sources for bad RAM, is the remainder likely enough to have problems that it's worth upgrading to ECC RAM? I don't think it is for my home systems, because I'm OK with initial and periodic culling to kick out borderline modules. And things like power reliability cause me more downtime than RAM issues do. If you don't know how or have the time to do that sort of thing yourself though, you could easily be better off buying more redundant RAM.
You are still vulnerable to power-supply failures etc. even if you have a UPS.
And to UPS failures. The batteries in those typically die after some number of years. I guess you can then add "monitor the UPS battery quality" to the list of stuff to do, that might get you another fraction of a percent improvement in reliability here.
I just buy a good disk controller with a battery-backed write cache when I care this much about getting reliable write caching.
A look at the man page suggests that POSIX_FADVISE_DONTNEED mainly impacts the caching behavior associated with the file only after it's been written. The suggestion in order to get the behavior it helps with as early as possible? Use fsync...
Last week I helped someone fix the stuttering sound on their PC. Cause: an IRQ conflict. Ended up moving the sound card to another slot after reading up on which IRQs got assigned to which slots with their motherboard. Nobody else they'd consulted had the slightly clue what was going on. The ugliness of PCI hardware hasn't gone away, it's just become less likely to bite you.
Similarly, the other example given, using "old-school DOS hacks to get something to work in Windows XP", still happens too. Last time I got pulled into one of those it involved writing a DOS batch file to fix something as part of a network login script. Maybe I could have used the newer Windows shell instead, but good old command.com was still the easy way around the problem they were running into.
The amount she's due is actually quite small, and doesn't impact her medical treatment--just her dignity as it leaves her relying on others for money more than she'd like. As someone who only worked sporadically before and after raising children, the monthly amount she's entitled to is approximately one week worth of what you get when collecting unemployment benefits for example. I can't decide if that makes that her case has been floating around for so long more or less outrageous.
When you file for long-term disability with Social Security, they need to grab all of the recent medical records from your primary physician and all the specialists you're seeing. This process takes a long time, generates a ton of redundant paperwork (many dupes of lab work and such that went to multiple places), and isn't very accurate. I went through this a few years ago with my mother. One of the physicians didn't respond in time to the request they sent for more information, stuff that was pretty critical. We believe that was one of the factors causing her initial claim and first appeal to be denied.
That was over four years ago; her case is just coming up for the final review now. That's how big the backlog is here, and medical records processing time is one of the big drivers to the process.
At the point where you're applying for Social Security disability, your medical records are no longer really private anyway. They're going to scour everything available to confirm that what's happened to you is both permanent and real.
I had a silent wish Tso would increase the default commit interval to 10 minutes when the first defenders of the KDE bug started squawking, but he's was too gracious for that.
Exactly; the code as written right now has an ugly race condition in it. The best thing you can do when you have one of those is make the conditions under which the problem occurs much more common, so that you get the right feedback for fixing it correctly.
There is no such thing as an atomic disk write operation, so your proposed step (3) is working on a bad premise. "One operation immediately followed by the other" is no help either--you have no way of knowing which bytes out of those two writes will and won't be there if there's a crash in the middle of that write.
Let's say you queue writes to two 4096 byte sectors. The power goes out. What made it to disk? Just one sector? Both? The first half of the second one, because the drive reordered the writes based on where the disk heads were at, and it got half the sector written before the capacitors in the drive fully discharged? You have no idea at all what you got, which is why filesystem designers avoid even thinking like this.
The only thing you can do is provide a mechanism to confirm whether a write was successful or not before moving onto a second one. fsync provides such a mechanism, which is why discussion of this issue invariably wander into talking about it.
It's good to see something involving Romania and security that's positive for achange. Wait, do we know where the authors of Conficker came from? Hmmmm...
If your battery-backed RAID controller ever fakes a fsync it is fundamentally broken or misconfigured. When the cache is filled with a write backlog and you try to write something else, that write will block until there is free space. Same as any other write cache that fills up.
When cache space is available to cache the write again, the data goes into there, and then a fsync request after it can then return success.
The alternate version of "Working Man" was used in order to generate some cross PR for Rush and Rock Band fans. They followed putting it into the game with releasing it as a new single track via iTunes; see http://www.rush.com/low/news.php?year=2008 for details. That was pure marketing, they could have used the original one had they wanted to, but knew that picking the alternate take would add some buzz via Rush fans who want copies of everything.
Jimmy Buffet did something similar by re-recording some of his old songs for exclusive Rock Band versions. Forces all the Parrotheads to get Rock Band if they want to hear them.
Yes, the software was named "Anthem". If you wander to Google Book Search, you can find the initial description of it on page 29: "if you wanted your company accounts represented as a piece of music, it could do that as well...it produced lots of cheery company anthems".
You know, females, the connectors that don't have any pins sticking out. Since music was mentioned, I can only assume he was talking about the female mini-plug socket or RCA connector.
I name all my systems after favorite albums, which makes shared KVM use easier--just make the background wallpaper the album cover and you can always tell which system you're logged into.
Slashdot Mirror
Been done. I heard something about it being so nasty that several of the programmers involved got a STD.
One of the wireless devices I needed to talk to in order to figure out what was going on had crappy serial port driver hardware for its debugging interface. It wouldn't drive a cable long enough to reach the base of the rooftop, too many transmission glitches to work right.
The router worked fine on the bench; only acted funny when connected to the antenna on top of the building, on the wireless grid at that point. Had to debug the problem live to see it.
I once had a job at a wireless ISP where I would regularly troubleshoot disfunctional rooftop routers located on an antenna mast. This sometimes left me balancing my laptop on top of a ladder in order to connect to the crashed device, which was particularly fun on high buildings during windy days. Every tried to troubleshoot and fix a kernel panic by tweaking kernel driver source code in a situation where you could fall to your death if you lost your balance? It would make an awesome geek extreme sport.
There's been plenty of speculation that Sun was interested more in MySQL from the sales side of things than from the technology one. MySQL had figured out how to sell open-source solutions to people for money successfully, something Sun would like to do more of. The high-profile engineers can jump to other projects on a whim, that doesn't necessarily mean they've lost what they wanted out of the purchase.
The Oracle pl/SQL -> PostgreSQL pl/pgSQL link you suggested was from PostgreSQL 7.1, pretty ancient at this point. PostgreSQL 8.3 Porting from Oracle is a current resource.
If a system gives memtest86 errors, I break it down and swap components until it doesn't. The test pattern it uses can find subtle errors you're unlikely to run into with any application-based testing even when run for a few days. Any failures it reports should be taken seriously. Also: you should pay a attention to the memory speed value it reports, that's a surprisingly effective simple benchmark for figuring out if you've setup your RAM optimally. The last system I built, I ended up purchasing 4 different sets of RAM, and there was about a 30% delta between how well the best and worst performed on the memtest86 results--correlated extremely well with other benchmarks I ran too.
At the same time, I've had memory that memtest86 said was fine, but the system itself still crashed under a heavy Linux-based test. I consider both a full memtest86 test and a moderate workload Linux test to be necessary before I consider a new system to have baseline usable reliability.
There are a few separate problems here that are worthwhile to distinguish among. A significant amount of RAM doesn't work reliably when tested fully. Once you've culled those out, only using the good stuff, some of that will degrade over time to where it will no longer pass a repeat of the initial tests; I recently had a perfectly good set of RAM degrade to useless in only 3 months here. After you take out those two problematic sources for bad RAM, is the remainder likely enough to have problems that it's worth upgrading to ECC RAM? I don't think it is for my home systems, because I'm OK with initial and periodic culling to kick out borderline modules. And things like power reliability cause me more downtime than RAM issues do. If you don't know how or have the time to do that sort of thing yourself though, you could easily be better off buying more redundant RAM.
And to UPS failures. The batteries in those typically die after some number of years. I guess you can then add "monitor the UPS battery quality" to the list of stuff to do, that might get you another fraction of a percent improvement in reliability here.
I just buy a good disk controller with a battery-backed write cache when I care this much about getting reliable write caching.
A look at the man page suggests that POSIX_FADVISE_DONTNEED mainly impacts the caching behavior associated with the file only after it's been written. The suggestion in order to get the behavior it helps with as early as possible? Use fsync...
Last week I helped someone fix the stuttering sound on their PC. Cause: an IRQ conflict. Ended up moving the sound card to another slot after reading up on which IRQs got assigned to which slots with their motherboard. Nobody else they'd consulted had the slightly clue what was going on. The ugliness of PCI hardware hasn't gone away, it's just become less likely to bite you.
Similarly, the other example given, using "old-school DOS hacks to get something to work in Windows XP", still happens too. Last time I got pulled into one of those it involved writing a DOS batch file to fix something as part of a network login script. Maybe I could have used the newer Windows shell instead, but good old command.com was still the easy way around the problem they were running into.
Help introduce more female she-devils of course.
Wait, did you want a serious answer? How about Save the Tasmaian Devil.
The amount she's due is actually quite small, and doesn't impact her medical treatment--just her dignity as it leaves her relying on others for money more than she'd like. As someone who only worked sporadically before and after raising children, the monthly amount she's entitled to is approximately one week worth of what you get when collecting unemployment benefits for example. I can't decide if that makes that her case has been floating around for so long more or less outrageous.
When you file for long-term disability with Social Security, they need to grab all of the recent medical records from your primary physician and all the specialists you're seeing. This process takes a long time, generates a ton of redundant paperwork (many dupes of lab work and such that went to multiple places), and isn't very accurate. I went through this a few years ago with my mother. One of the physicians didn't respond in time to the request they sent for more information, stuff that was pretty critical. We believe that was one of the factors causing her initial claim and first appeal to be denied.
That was over four years ago; her case is just coming up for the final review now. That's how big the backlog is here, and medical records processing time is one of the big drivers to the process.
At the point where you're applying for Social Security disability, your medical records are no longer really private anyway. They're going to scour everything available to confirm that what's happened to you is both permanent and real.
I had a silent wish Tso would increase the default commit interval to 10 minutes when the first defenders of the KDE bug started squawking, but he's was too gracious for that.
Exactly; the code as written right now has an ugly race condition in it. The best thing you can do when you have one of those is make the conditions under which the problem occurs much more common, so that you get the right feedback for fixing it correctly.
There is no such thing as an atomic disk write operation, so your proposed step (3) is working on a bad premise. "One operation immediately followed by the other" is no help either--you have no way of knowing which bytes out of those two writes will and won't be there if there's a crash in the middle of that write.
Let's say you queue writes to two 4096 byte sectors. The power goes out. What made it to disk? Just one sector? Both? The first half of the second one, because the drive reordered the writes based on where the disk heads were at, and it got half the sector written before the capacitors in the drive fully discharged? You have no idea at all what you got, which is why filesystem designers avoid even thinking like this.
The only thing you can do is provide a mechanism to confirm whether a write was successful or not before moving onto a second one. fsync provides such a mechanism, which is why discussion of this issue invariably wander into talking about it.
http://www.fastcopyinc.com/orionpress/articles/trouble_with_flat_tribbles.htm
It's good to see something involving Romania and security that's positive for a change. Wait, do we know where the authors of Conficker came from? Hmmmm...
If your battery-backed RAID controller ever fakes a fsync it is fundamentally broken or misconfigured. When the cache is filled with a write backlog and you try to write something else, that write will block until there is free space. Same as any other write cache that fills up.
When cache space is available to cache the write again, the data goes into there, and then a fsync request after it can then return success.
The preference was for a 128Kbps MP3 rip, which is abysmally low quality and sizzles like bacon.
If you think that interface is ugly, you should see the hookers.
The alternate version of "Working Man" was used in order to generate some cross PR for Rush and Rock Band fans. They followed putting it into the game with releasing it as a new single track via iTunes; see http://www.rush.com/low/news.php?year=2008 for details. That was pure marketing, they could have used the original one had they wanted to, but knew that picking the alternate take would add some buzz via Rush fans who want copies of everything.
Jimmy Buffet did something similar by re-recording some of his old songs for exclusive Rock Band versions. Forces all the Parrotheads to get Rock Band if they want to hear them.
Duh, because Hooker had that obvious car hood humping fetish; what did he need women for?
It's good that someone is finally selling a product specifically targeted at female Star Trek fans.
Unfortunately, it seems the first obvious need they found in that demographic was for something to improve their smell.
Yes, the software was named "Anthem". If you wander to Google Book Search, you can find the initial description of it on page 29: "if you wanted your company accounts represented as a piece of music, it could do that as well...it produced lots of cheery company anthems".
You know, females, the connectors that don't have any pins sticking out. Since music was mentioned, I can only assume he was talking about the female mini-plug socket or RCA connector.
I name all my systems after favorite albums, which makes shared KVM use easier--just make the background wallpaper the album cover and you can always tell which system you're logged into.