So, two rookie mistakes. The actor for entering an unsafe situation, and the operator not making the area safe.
Three mistakes. Whoever designed the door obviously doesn't have any experience with production automation, and didn't have an automated stop to prevent the door from closing if someone wasn't where they were supposed to be. Light curtains, pressure mats, whatever.
"Andrew Marshall, prosecuting, said the breaches had caused a “risk of death” and that if the emergency stop had not been pressed in time
Why was there only a manual E-stop on it? Something that big and heavy should also have had hidden light curtains or other automated means of stopping it.
I'm still not seeing what a Class D amp has to do with this - you can't feed digital data to such an amplifier and expect to get anything but noise out of it. DACs and amplifiers do totally different things, and too many people are under the impression that Class D amplifiers have something to do with digital when they don't. It's just a very efficient, somewhat complex, and completely analog amplification method that works similarly to a switching power supply. Modulate an analog signal such that you're only dealing with two voltage levels, amplify the modulated signal, and filter out the modulation frequency to end up with a higher-voltage/current copy of what went in.
Five, ten years from now, I anticipate we'll all have USB-C headphones (except Apple users, who might have something non-standard), and there will be USB-C ports everywhere, and we'll look back at this thread and laugh.
I don't think so. Comparing the 3.5" TRS connector to USB is apples and oranges - there are a LOT more devices that use the TRS connector for various and sundry things, and those devices aren't going to move to USB-C. This is a smartphone-specific issue with very little overlap elsewhere, and the rest of the world isn't going to standardize on a connector that's far more expensive to implement, doesn't offer any articulable benefits to them, and is often an inappropriate choice.
I really can't see how that passed muster, but then, who am I...
If you mean as far as why they released the source listing, then it's probably because that's what lots of manufacturers did back then. Apple also made a fully commented ROM listing for the Apple II available. Even if the listings weren't available, disassembling and figuring out how 8K of assembly code works isn't rocket science.
The BIOS did more than just booting the OS (provided disk access, serial/keyboard I/O, basic screen handling, etc.), and decompiling (disassembling, actually) wasn't necessary because IBM published a fully commented source listing. A detailed functional spec was derived from this listing, which was then used to clean-room the code.
Most devices made between 1980 and 2005 use really large mechanical 3.5mm jacks that are only secured by solder, so the problem you are describing is exactly that, where the solder joints have been cracked on the PCB jack mount itself.
And this could have been easily avoided by fastening the connector to the board with epoxy so that *it* absorbs the strain instead of the solder joints.
But I know that I find it weird to look at it the other way around. I want to know if the result was successful, not if successful was the result. Maybe it's an english thing.
I find it kinda weird too, but IMO it's a small price to pay for avoiding bugs that are sometimes pretty difficult to track down. I also tend to add parentheses where they're strictly not needed because I don't count on everyone knowing the rules of precedence. I've seen people get bit by something like "if( i & 0xff == TRUE )" before because they don't remember that in C/C++, "==" is evaluated before bitwise operators.
Requiring all definitions at the top of the module requires the reader to flip back-and-forth
This is true, but if you define the variable in the middle of something, and it's used somewhere other than just after the definition, you can end up playing hide and seek trying to find the definition, and can sometimes encounter unexpected scoping issues if you're not paying attention. I would probably say that it's better to define them at the beginning of the scope in which they're used.
With the annoyingly loud valve chatter of a diesel, but a modern gasoline engine idles nearly silent, and someone in front of a car will not be able to hear the exhause.
This is even true of my 14-year old pickup with a 4.8L gas engine and 135,000+ miles on it. From 20 feet away, practically all you hear of the engine is the fan. Standing at the rear, you can hear a low rumble from the exhaust, but you have to be right on top of it.
Driving to conditions means taking into account the ability for someone to dart out into traffic and slowing down to a point where you can see unexpected events with enough notice to safely stop.
Practically speaking, that would mean an implicit speed limit of 10mph or less anywhere there's on-curb parking. Even at 10mph (15 feet per second), if someone walks out in front of you a car length ahead, you're still pretty likely to hit them.
That means you have to examine how it works. In order to do that, you must get past the DRM. According to the DMCA, that's illegal.
The reverse engineering clause in Section 1201 *may* make that statement incorrect. The DMCA does include language specifically intended to allow circumvention in order to enable interoperability. Whether you could successfully argue that in court would likely depend on how big of a legal fund you have.
No argument there, but I would think that most people would attempt to steal from a store rather than a residence, and around here we hear about just about every shoplifting incident (what can I say, it's a smaller town that likes to know everyone's business, and we have an unexpectedly high homeless population). You're pretty much guaranteed not to get shot stealing from a store even if you're caught, whereas a lot of people will take violent action when they find unexpected visitors in their home. I do agree that the theft of food from a home isn't likely to see much benefit from calling the police, except maybe to make them aware in case it happens again in the same neighborhood. Like you, I wouldn't get too worked up about someone stealing food and nothing else, although I might get a little cranky if they stole the ribeye steaks and left the bread, milk, frozen dinners, etc.
Most people don't realize that there is a 15% tax on there wage in addition to a 15% tax that is hidden because your employer doesn't tell you that you would have otherwise made another 15% hadn't the government stolen it from them.
Most people realize that Social Security is 6.2% and Medicare is 1.45%, plus a matching 6.2% + 1.45% paid by the employer (or you if you're self-employed). Altogether 15.3%, not 30%.
This. You don't read about a large number of Jean Valjeans stealing bread. There's the occasional mom that you read about shoplifting staples for her kids at the grocery store, but those are few and far between.
However, a larger percentage of crime is to score money for drugs/alcohol. Ensuring the most basic of bills are paid (housing, food, etc.) might result in fewer people turning to chemical means to make their lives more bearable (and a consequent drop in drug-related thefts), but I have no facts to argue either way.
The only worthwhile thing it gives you is a filesystem. A filesystem that doesn't work on modern machines (disks above 2GB, GPT partition tables, UEFI, sectors bigger than 512 bytes), gets corrupted on a crash, suffers from a ridiculous level of fragmentation, has bizarre limitations on file names (8.3, all caps, half of ASCII banned), and so on.
All of which are usually not necessary on an embedded system that needs to fly fast and likely doesn't even need a filesystem. The point of my original post wasn't to say that DOS was the do-all and end-all of operating systems. Rather, it was to highlight the fact that on severely time-constrained systems, DOS will often "beat the pants off" a full OS like Linux. All of the support for different filesystems, USB, etc. are useless if I'm burning holes in stuff because I can't maintain a consistent 750 ns update window for a pair of laser galvos. Even RTLinux couldn't come close to that kind of guaranteed latency.
Well, more properly until you call something in DOS or the BIOS that turns interrupts off or masks off the one you're interested in - if interrupts are enabled and you're not already servicing one at a higher priority, the processor will yank you right out of whatever was executing and drop you into the handler no matter what either you or DOS was doing at the time. If DOS still manages to interfere with you, you can always change the offending interrupt vector to point to your own code.
Practically speaking, DOS is so simple that there's not much that it could do that couldn't be easily worked around.
Slashdot Mirror
I imagine you'd get fired/blacklisted just as quickly if your set design kills or maims an A-list actor.
So, two rookie mistakes. The actor for entering an unsafe situation, and the operator not making the area safe.
Three mistakes. Whoever designed the door obviously doesn't have any experience with production automation, and didn't have an automated stop to prevent the door from closing if someone wasn't where they were supposed to be. Light curtains, pressure mats, whatever.
"Andrew Marshall, prosecuting, said the breaches had caused a “risk of death” and that if the emergency stop had not been pressed in time
Why was there only a manual E-stop on it? Something that big and heavy should also have had hidden light curtains or other automated means of stopping it.
I'm still not seeing what a Class D amp has to do with this - you can't feed digital data to such an amplifier and expect to get anything but noise out of it. DACs and amplifiers do totally different things, and too many people are under the impression that Class D amplifiers have something to do with digital when they don't. It's just a very efficient, somewhat complex, and completely analog amplification method that works similarly to a switching power supply. Modulate an analog signal such that you're only dealing with two voltage levels, amplify the modulated signal, and filter out the modulation frequency to end up with a higher-voltage/current copy of what went in.
Five, ten years from now, I anticipate we'll all have USB-C headphones (except Apple users, who might have something non-standard), and there will be USB-C ports everywhere, and we'll look back at this thread and laugh.
I don't think so. Comparing the 3.5" TRS connector to USB is apples and oranges - there are a LOT more devices that use the TRS connector for various and sundry things, and those devices aren't going to move to USB-C. This is a smartphone-specific issue with very little overlap elsewhere, and the rest of the world isn't going to standardize on a connector that's far more expensive to implement, doesn't offer any articulable benefits to them, and is often an inappropriate choice.
Speakers only need 2 wires and you can add a third for a mic.
If you want stereo, you'll need three wires and four for a mic.
I really can't see how that passed muster, but then, who am I...
If you mean as far as why they released the source listing, then it's probably because that's what lots of manufacturers did back then. Apple also made a fully commented ROM listing for the Apple II available. Even if the listings weren't available, disassembling and figuring out how 8K of assembly code works isn't rocket science.
The BIOS did more than just booting the OS (provided disk access, serial/keyboard I/O, basic screen handling, etc.), and decompiling (disassembling, actually) wasn't necessary because IBM published a fully commented source listing. A detailed functional spec was derived from this listing, which was then used to clean-room the code.
Audio producing gear is analogue (yes even class D amps ultimately move a simple speaker coil back and forth)
Of course they do - Class D amps are fully analog switching/filtering circuits with no digital logic within the amplifier itself.
Most devices made between 1980 and 2005 use really large mechanical 3.5mm jacks that are only secured by solder, so the problem you are describing is exactly that, where the solder joints have been cracked on the PCB jack mount itself.
And this could have been easily avoided by fastening the connector to the board with epoxy so that *it* absorbs the strain instead of the solder joints.
Like, e.g. USB micro.
For sure. USB mini is far stronger mechanically, and for me, having a phone that's a millimeter thicker is a small price to pay for reliability.
But I know that I find it weird to look at it the other way around. I want to know if the result was successful, not if successful was the result. Maybe it's an english thing.
I find it kinda weird too, but IMO it's a small price to pay for avoiding bugs that are sometimes pretty difficult to track down. I also tend to add parentheses where they're strictly not needed because I don't count on everyone knowing the rules of precedence. I've seen people get bit by something like "if( i & 0xff == TRUE )" before because they don't remember that in C/C++, "==" is evaluated before bitwise operators.
Requiring all definitions at the top of the module requires the reader to flip back-and-forth
This is true, but if you define the variable in the middle of something, and it's used somewhere other than just after the definition, you can end up playing hide and seek trying to find the definition, and can sometimes encounter unexpected scoping issues if you're not paying attention. I would probably say that it's better to define them at the beginning of the scope in which they're used.
With the annoyingly loud valve chatter of a diesel, but a modern gasoline engine idles nearly silent, and someone in front of a car will not be able to hear the exhause.
This is even true of my 14-year old pickup with a 4.8L gas engine and 135,000+ miles on it. From 20 feet away, practically all you hear of the engine is the fan. Standing at the rear, you can hear a low rumble from the exhaust, but you have to be right on top of it.
Driving to conditions means taking into account the ability for someone to dart out into traffic and slowing down to a point where you can see unexpected events with enough notice to safely stop.
Practically speaking, that would mean an implicit speed limit of 10mph or less anywhere there's on-curb parking. Even at 10mph (15 feet per second), if someone walks out in front of you a car length ahead, you're still pretty likely to hit them.
Not "breaks" (a verb)
"Breaks" can also be used as a noun in slang, as in "them's the breaks". But yeah, it's grating whenever I see "breaks" used when "brakes" was proper.
Just FYI - the link in your sig is dead.
That means you have to examine how it works. In order to do that, you must get past the DRM. According to the DMCA, that's illegal.
The reverse engineering clause in Section 1201 *may* make that statement incorrect. The DMCA does include language specifically intended to allow circumvention in order to enable interoperability. Whether you could successfully argue that in court would likely depend on how big of a legal fund you have.
Yes, it is correct.
Firstly, few individuals report a theft of food.
No argument there, but I would think that most people would attempt to steal from a store rather than a residence, and around here we hear about just about every shoplifting incident (what can I say, it's a smaller town that likes to know everyone's business, and we have an unexpectedly high homeless population). You're pretty much guaranteed not to get shot stealing from a store even if you're caught, whereas a lot of people will take violent action when they find unexpected visitors in their home. I do agree that the theft of food from a home isn't likely to see much benefit from calling the police, except maybe to make them aware in case it happens again in the same neighborhood. Like you, I wouldn't get too worked up about someone stealing food and nothing else, although I might get a little cranky if they stole the ribeye steaks and left the bread, milk, frozen dinners, etc.
Most people don't realize that there is a 15% tax on there wage in addition to a 15% tax that is hidden because your employer doesn't tell you that you would have otherwise made another 15% hadn't the government stolen it from them.
Most people realize that Social Security is 6.2% and Medicare is 1.45%, plus a matching 6.2% + 1.45% paid by the employer (or you if you're self-employed). Altogether 15.3%, not 30%.
This. You don't read about a large number of Jean Valjeans stealing bread. There's the occasional mom that you read about shoplifting staples for her kids at the grocery store, but those are few and far between.
However, a larger percentage of crime is to score money for drugs/alcohol. Ensuring the most basic of bills are paid (housing, food, etc.) might result in fewer people turning to chemical means to make their lives more bearable (and a consequent drop in drug-related thefts), but I have no facts to argue either way.
The only worthwhile thing it gives you is a filesystem. A filesystem that doesn't work on modern machines (disks above 2GB, GPT partition tables, UEFI, sectors bigger than 512 bytes), gets corrupted on a crash, suffers from a ridiculous level of fragmentation, has bizarre limitations on file names (8.3, all caps, half of ASCII banned), and so on.
All of which are usually not necessary on an embedded system that needs to fly fast and likely doesn't even need a filesystem. The point of my original post wasn't to say that DOS was the do-all and end-all of operating systems. Rather, it was to highlight the fact that on severely time-constrained systems, DOS will often "beat the pants off" a full OS like Linux. All of the support for different filesystems, USB, etc. are useless if I'm burning holes in stuff because I can't maintain a consistent 750 ns update window for a pair of laser galvos. Even RTLinux couldn't come close to that kind of guaranteed latency.
Well, more properly until you call something in DOS or the BIOS that turns interrupts off or masks off the one you're interested in - if interrupts are enabled and you're not already servicing one at a higher priority, the processor will yank you right out of whatever was executing and drop you into the handler no matter what either you or DOS was doing at the time. If DOS still manages to interfere with you, you can always change the offending interrupt vector to point to your own code.
Practically speaking, DOS is so simple that there's not much that it could do that couldn't be easily worked around.
Ah, yes. I managed to get 634K free base memory after tweaking settings to get everything loaded high on QEMM. Took some doing.
DEVICEHIGH/LOADHIGH, how we loved ye...