You claimed the runtime saves you, I argued that it doesn't unless you take special measures to make it save you. I can take such measures as well in C as in C++.
You are apparently only aware of one convention. Other documentation speaks of sectors and considers blocks a hard drive thing.
Sounds more like you're butthurt that I called you on saying something silly.
The mapping only changes when a logical block is written OR a sufficient number of logical blocks are invalidated in the sector.
Nobody who wasn't recently kicked in the head by a horse if going to put the drive's firmware somewhere where it will be moved around and re-written. Beyond the many other problems, How do you think the processor is going to find it on start-up?
I think most telling was a test where a group of fingerprint analysts was given a fair number of samples to analyse. Some of them were duplicates. The finding was that they not only disagreed with each other, they sometimes unknowingly disagreed with themselves.
That's just crappy design. It should be able to hold an hour of programming in RAM and so never touch the disk unless you actually use the rewind feature.
Right, but what of the cells that aren't yet failed? Why not allow them to be read to see what you can salvage? The ones that degraded and lost data will fail a checksum. With any luck, the most critical data is still there and passing checksum unless the drive sabotages you by not letting you even try to read it.
My concern is that they brick. I understand that a newly written sector may fail miserably and that if it cannot find a functional empty sector it may lose that sector entirely, but why can't it allow the existing successfully written sectors to be read off in a read only mode?
Not really. I plug in a USB drive, I have another drive. I don't really have to do anything much about that. I add an external monitor, I MIGHT want to switch to it, but I can already do that. I plug in a sound card, I can play sound. If not, I can't. What's to *DO* about it?
If anything does need to be done, I can have the old init launch a monitor program that controls the dependent program. Or the dependent program itself can sign up for notifications.
If I want a crashed program to be restarted, I can stick a restarter in front of it. But note that silent restarting is bad if it crashed because someone tried an exploit on it. If it restarts right away, they can keep trying until it works.
The same goes for power levels. A monitor program can renice or stop a daemon until the power level changes again.
The whole thing could have been accomplished with a few simple utilities and nobody would have been upset at all.
There was no need to create a truly dizzying mess of 'no really, it's not a script' control files based on the proven sound 'come from' operator to accomplish that. Have a look in/lib/systemd or/etc/systemd or/var/lib/systemd or wherever it might be hidden and figure out how to tell it that you REALLY REALLY want the thing to boot with a degraded RAID if necessary. Then tell me how complicated the init scripts are. Good luck.
Any percentage you pick can and eventually will be wrong. You just have to look at their overall contribution vs. resources used. The guy that contributes one line a year but it's obviously correct once you see it is contributing. The guy whose actual code is crap but has a talent for sparking discussions that lead to important advances is productive. Keep him too.
OTOH, the guy who contributes an average amount of code but typically creates a mess where someone else becomes non-productive fixing the missed corner cases may not be worth keeping.
The odds of any arbitrary percentage of some cobbled together metric getting it right are close to nil.
The alternative to not firing a developer is allowing anyone at all to check any change in that they care to and to spew any crap they want on the mailing list or whatever medium the project uses.
If you won't commit their crap code and you moderate their ranting posts away, they are effectively fired no matter what you choose to call it.
The runtime test doesn't necessarily save you. If the only option at that point is to crash, you haven't been saved. Thinking you are somehow safe because you used dynamic_cast is part of the problem.
If the code is well thought out enough that it can salvage itself at that point, the programmer probably already thought the cast over three times before using it.
Again, not saying it's necessarily bad, but there's no point in claiming type safety there.
They link and unlink prev/next pointers built in to the objects. Since those pointers are type specific, you will get warnings/errors when you compile if you try to link the wrong thing into the container.
So a foo_t struct will have prev/next pointers defined as pointer to foo_t. So if we have b, a pointer to bar_t and try to do insert(foo_head, b), the types mis-match.
Slashdot Mirror
To be fair, UPS and FedEx are equally dependent on USPS for some of their 'last mile' deliveries.
Oddly, in my area electricity is so over-priced compared to gas that it's cheaper to run the gas auxiliary heat than the heat pump even at a COP of 4.
"Rough service" bulbs are exempt, so they will remain available for quite a while.
Remember how when we were kids a dropped fever thermometer was no big deal and your mom's primary concern was that you might step in the glass?
A CF has much less mercury in it than that.
Look up "scrubbers". Unless you are in China the mercury is all in the ash dam.
And then on to the local river and the aquifer.
You should definitely not snort goofballs.
You claimed the runtime saves you, I argued that it doesn't unless you take special measures to make it save you. I can take such measures as well in C as in C++.
Who's moving the goalposts again?
And prohibition held back the licquor industry, but what does that have to do with common carrier status? (the topic at hand, that is)
RAM isn't all that expensive these days. As for the rest, like I said, crappy design.
You are apparently only aware of one convention. Other documentation speaks of sectors and considers blocks a hard drive thing.
Sounds more like you're butthurt that I called you on saying something silly.
The mapping only changes when a logical block is written OR a sufficient number of logical blocks are invalidated in the sector.
Nobody who wasn't recently kicked in the head by a horse if going to put the drive's firmware somewhere where it will be moved around and re-written. Beyond the many other problems, How do you think the processor is going to find it on start-up?
I think most telling was a test where a group of fingerprint analysts was given a fair number of samples to analyse. Some of them were duplicates. The finding was that they not only disagreed with each other, they sometimes unknowingly disagreed with themselves.
Yes, the 1935 law absolutely blocked innovative package delivery services such as UPS and FedEx from even getting start..... Er, wait a minute!
NAND also comes in sectors that are physical. Several logical drive sectors are mapped onto a physical NAND sector.
The physical NAND sectors the firmware is stored on shouldn't be altered once the drive leaves the factory.
Consider, does your BIOS in flash wear out?
That's just crappy design. It should be able to hold an hour of programming in RAM and so never touch the disk unless you actually use the rewind feature.
The solution is actually to read and check the ECC. If you get an error, re-construct with the ECC and reallocate the sector.
Right, but what of the cells that aren't yet failed? Why not allow them to be read to see what you can salvage? The ones that degraded and lost data will fail a checksum. With any luck, the most critical data is still there and passing checksum unless the drive sabotages you by not letting you even try to read it.
But those sectors shouldn't have seen a write since the factory, why should they fail?
My concern is that they brick. I understand that a newly written sector may fail miserably and that if it cannot find a functional empty sector it may lose that sector entirely, but why can't it allow the existing successfully written sectors to be read off in a read only mode?
Actually, on my media box I killed pulseaudio because it made all of my movies look like martial arts movies.
Not really. I plug in a USB drive, I have another drive. I don't really have to do anything much about that. I add an external monitor, I MIGHT want to switch to it, but I can already do that. I plug in a sound card, I can play sound. If not, I can't. What's to *DO* about it?
If anything does need to be done, I can have the old init launch a monitor program that controls the dependent program. Or the dependent program itself can sign up for notifications.
If I want a crashed program to be restarted, I can stick a restarter in front of it. But note that silent restarting is bad if it crashed because someone tried an exploit on it. If it restarts right away, they can keep trying until it works.
The same goes for power levels. A monitor program can renice or stop a daemon until the power level changes again.
The whole thing could have been accomplished with a few simple utilities and nobody would have been upset at all.
There was no need to create a truly dizzying mess of 'no really, it's not a script' control files based on the proven sound 'come from' operator to accomplish that. Have a look in /lib/systemd or /etc/systemd or /var/lib/systemd or wherever it might be hidden and figure out how to tell it that you REALLY REALLY want the thing to boot with a degraded RAID if necessary. Then tell me how complicated the init scripts are. Good luck.
If a giant mess that doesn't work is bad, why systemd? Out of the frying pan and into the fire.
Any percentage you pick can and eventually will be wrong. You just have to look at their overall contribution vs. resources used. The guy that contributes one line a year but it's obviously correct once you see it is contributing. The guy whose actual code is crap but has a talent for sparking discussions that lead to important advances is productive. Keep him too.
OTOH, the guy who contributes an average amount of code but typically creates a mess where someone else becomes non-productive fixing the missed corner cases may not be worth keeping.
The odds of any arbitrary percentage of some cobbled together metric getting it right are close to nil.
The alternative to not firing a developer is allowing anyone at all to check any change in that they care to and to spew any crap they want on the mailing list or whatever medium the project uses.
If you won't commit their crap code and you moderate their ranting posts away, they are effectively fired no matter what you choose to call it.
The runtime test doesn't necessarily save you. If the only option at that point is to crash, you haven't been saved. Thinking you are somehow safe because you used dynamic_cast is part of the problem.
If the code is well thought out enough that it can salvage itself at that point, the programmer probably already thought the cast over three times before using it.
Again, not saying it's necessarily bad, but there's no point in claiming type safety there.
They link and unlink prev/next pointers built in to the objects. Since those pointers are type specific, you will get warnings/errors when you compile if you try to link the wrong thing into the container.
So a foo_t struct will have prev/next pointers defined as pointer to foo_t. So if we have b, a pointer to bar_t and try to do insert(foo_head, b), the types mis-match.