Wait... did you just put forward the case for having lots more world wars using conventional weapons? Because that's kind of the direction it looks like you're going there.
I witnessed this hack multiple times as a youngster on commercial construction sites.
Rather than removing it from the saw, the framers would wire it into the open position because it allowed them to cut measured lengths of lumber much quicker.
Yep. But it's possible to make those things not be so much of a hindrance (I've definitely used some that were so smooth you wouldn't even know they're there). Making it less annoying is one of the best ways to reduce instances of people circumventing it.
I take it you've never worked on safety critical software which had to meet a certain standard of development and testing, e.g. mil 882 or iso 26262? For that stuff you'd have to have willfully malicious management for bad code to slip through in such a way that it could cause issues (and then they'd sure as shit be liable for it since the whole point of those standards is to leave a paper trail).
Bypassing safety for convenience is a common thing unfortunately, but so are badly designed safety systems that fail to meet the regulations.
I feel like if a safety system is commonly bypassed for convenience, it's a badly designed system. Firstly because it's annoying someone enough that they feel it's worth risking life and limb to circumvent, and secondly because it's easily bypassable.
The blade guard on an old circular saw I once had comes to mind as a good example. It was clearly thrown on as an afterthought of the design, and as a result tended to catch on the wood, screw up cuts, and generally just be a horrible nuisance (I've used other saws in which the guard worked a lot smoother). Eventually I just removed the thing altogether and jammed the interlock.
There are tons of factors that could make it all kinds of different peoples responsibilities. That's why generally with lawsuits like this it's common to fire from the hip and name anyone who could possibly be involved, then let the accused fight it out as to whose fault it is.
If people are doing their job, the robot software team should be able to produce documentation showing what safety went into the code (redundant sensors, secondary processor constantly checking the first one, etc.), the robot hardware team should be able to show that their interlocks and failsafes actually work, the factory management should be able to produce documentation showing proper lockout tagout training, the safety admin types hsould be able to produce documentation showing that those procedures were followed, etc. As a result of that, we'll probably see the case dismissed vs a good number of the accused parties and it'll likely come down to just one or two of them left (the ones who didn't have a paper trail to cover their asses) doing a lot of mutual finger pointing.
I rarely watch a movie more than once but I listen to the same songs rather often. I don't care for concerts, so I'm afraid I cannot relate on that matter.
That's probably why we differ. For me the streaming model is perfect because while I don't necessarily object to listening to the same song multiple times, what I like and don't like will vary depending on situation, mood, and circumstances. Sometimes I just want semi-rhythmic noise to block out other sounds, sometimes I want something that I can zone out to while programming, and sometimes I want to discover new music that sounds like some other song I heard and liked. I've also found that music I liked 10 years ago I can't stand now, and I don't have any particular loyalty to any particular song or band. As such, I'm more than happy to stream music on a temporary basis (disclaimer: I haven't once paid for a streaming service and probably never will). I feel no need to archive it for later use since there's a 50-50 chance I won't enjoy it anymore anyway after a few years.
Wait until it's your turn and we turn the cold shoulder to you when you can't afford your medications when you're 65+ and we tell you "well you should have made better business investments to cover for your retirement shouldn't you have?"
tbh I'd be fine with that, unlike a lot of people I'm capable of planning ahead and saving money. In this hypothetical, my complaints would stem from the fact that I'd spent the last 45 years paying to subsidize others who were incapable of planning ahead and was then told that as a reward for my good planning I'm ineligible for any assistance.
I'm really curious about that use case actually. Do you pick stations just based on "bands I liked at some point in time", or do you actually try to build them around a theme?
Mostly asking because I almost never find myself having to skip songs. The only times I ever run up against the skip limit was when I first create a new station and haven't yet dialed it in to play the kind of music I wanted it to play. If the station is playing stuff that fits within the station but isn't what I want to hear at the time, I realize that I'm on the wrong one for my current work and/or mood and just switch stations to something more appropriate.
How much energy does it take to create that vacuum under 1 atmosphere? Are you attempting to claim that the laws of energy conservation don't exist when it's a rich guys pet project?
You keep saying this, but I don't think you understand the difference between a sudden release of energy in the space of a few microseconds and the gradual release of energy over the course of multiple seconds. Re-pressurizing a long tube from one end can't happen instantly, so it will most definitely not be the same as releasing whatever amount of energy you think is stored in 1atm of pressure differential all at once.
If you don't believe Thunderf00t's science, try Mythbusters who did something similar with a rail car tanker.
If you're going to cite mythbusters, might I point you to the other test they ran in which they poked a hole in the side of a pressurized aircraft body and nothing much happened? No metal peeled back, no explosive decompression, just a fast air leak until the pressure equalized. It's been a while since I saw that episode, but iirc they eventually had to put explosives on it to actually make the sudden change in pressure actually do anything catastrophic.
I'm not unfamiliar with linux. Over the last 15 years I've tried redhat (back in the days before fedora was out), gentoo, fedora, ubuntu, and debian. Of those, I ran ubuntu and debian fairly consistently on my laptop all throughout college. Whichever linux installation I was using tended to shit itself about every 6-12 months, so I basically ended up having to do a clean reinstall at the beginning of each semester. I never once had an installation of a new version go smoothly (there was always a weekend of googling to fix whatever nonsense happened during the installation), and I was never able to have an install in which everything worked. There was always some niggling little annoyance e.g. the wireless wouldn't come back after entering sleep mode, monitor brightness wasn't adjustable, touchpad scroll zones wouldn't work, etc.
I know at this point you're either going to say it's because I didn't know what I was doing (maybe true), or shrug and say it's just anecdotal. But if it was really just a one-off thing where I've somehow consistently never been able to have a smooth linux experience, I suspect that desktop linux would have a much much bigger market share at this point in time.
Sounds like you played a little bit too much in the system files without knowing what you were doing.
In the case of SteamOS I had the sheer audacity to install chrome and then occasionally drop to desktop mode to watch streaming content. I know I know. The OS isn't really designed for that level of tampering by a user and I probably shouldn't be blaming it.
I also (as many do) tend to reuse passwords with minor variations. Most of my passwords (even in the file) are "shorthand" passwords that wouldn't work as listed in the document.
I don't understand why more people don't do this. It's easy to come up with a suitably long and random base password that you can then add minor variations to based on some algorithm to make it unique per website or service. e.g. if P@ssword1 is your base password, your slashdot login might be sP@sslword1a (sticking the first three letters of the site into the beginning, middle, and end of the password). Assuming you use an actually random base password and do something a little more sophisticated to mask where you're getting the variance from (e.g. rotate the site initials based on the value of the first one) no one is going to be able to figure out your other passwords based on seeing just one or two in the event a database with your plaintext credentials gets pwned.
Obviously that's not the be-all end-all of password security and you'd want to use truly unique passwords for important stuff (bank, email, etc.), but it works great for the 100s of unimportant/semi-important passwords that you use on a semi-regular basis without putting all your eggs in one basket like with a password manager.
I've read your comment and I could respond it by copy-pasting the last one I've wrote. Did you really read my comment?
I've read your comment and I could respond it by copy-pasting the last one I've wrote. Did you really read my comment?
Let me ask you something else then. Are you 100% certain that it's absolutely impossible (even in a millennium) to design a safety measure that will safe all passager that are alive in a plane (to discard to one that have been killed by a bomb or something) before it's inevitable crash?
In this way lies madness. It's the "if it saves just one life" argument I was referencing in my previous post. You might as well be asking why we can't just build the aircraft out of the same indestructible material the black box recorder is built from (har har). Here, I'll make one more attempt at explaining this to you before I give up:
I think it's fair to assume that parachutes will be useless during takeoffs and landings, which account for >50% of all fatal crashes of commercial airlines according to the stats I could find. Ruling out terrorism and pilot error is also fair (in all of those cases they'd have manually overridden the ejection system anyway), which drops those numbers even further. I don't have the time to comb through plane crash databases for the remaining ~35% that happened at altitude, but it's safe to assume that a lot of those were a total loss and would not have been able to deploy a parachute (e.g. midair collision completely destroying both aircraft).
Now you have to analyze the parachute system itself. We've established that a very small percentage of deadly incidents could have been salvaged via parachute. Considering that there less than 200 deadly incidents per 10 years (and that number has been dropping steadily), we're talking like 30 accidents where a parachute system might possibly have saved someone. Now can you say for 100% certainty that a parachute system isn't going to introduce additional failure modes that didn't exist beforehand (including failure modes that we won't know about until they happen and kill people)? e.g. decreased structural integrity, increased weight making the aircraft harder to recover from an engine loss event, failure of the system itself causing unnecessary ejection of passengers, increased maintenance complexity (more opportunities for human error) etc? It won't take more than one or two before any gains from having such a system will be completely negated.
My point here is that your time and effort is better spent on finding ways to keep human error from causing problems. Rail about economics all you want, but ultimately that's what system safety comes down down. You have to weigh the risks vs the cost of the mitigation (cost being defined as performance loss, additional risk, and of course actual additional cost) and decide if it's worth it. In the case of airliner ejection systems, the use case is just so niche that you're making a very hard sell.
You're neglecting to calculate how often a condition will happen in which a parachute will be able to save more people than a controlled crash. System safety 101 tells us that risk = severity * probability. Not running the probability numbers means you're only getting half the picture. It'll very quickly lead down the road of "if it saves just one life...", and the only thing you'll find there is madness. My argument is that the probability of conditions occuring in which a parachute would be beneficial is so small as to be basically zero. You'll get greater return in terms of lives saved per unit of engineering if you spend it elsewhere (e.g. adding more redundancy to the aircraft, safer airframe design, smarter health monitoring, etc.).
One of the other things that goes along with safety analysis though is looking at both the consequences of some failure as well as the probability of that failure happening. There are so few instances of commercial aircraft going down in such a way that ejecting passengers would have saved more people than attempting a controlled crash landing that it's a safety system that just doesn't make sense. Even if you could implement it for free, on the (incredibly rare) instances it would have to be used everything would be so far out of operational parameters that it probably wouldn't accomplish much.
That's not been my experience. Yes it's miles better than it used to be 10-15 years ago, but I've yet to install linux on a computer where everything just works out of the box. SteamOS came close, but small things kept breaking every few months until eventually it just sort of self destructed after an update and refused to boot anymore.
If all (or even just some significant number of) homeless people were only homeless because the president forgot to pull the "more jobs" lever at his desk that morning then you might have a point there. Problem is that if you put a typical sampling of homeless people together in a home, what you basically get is an insane asylum. There's no problem with that if you're willing to call it (and provide the resources for it) for what it is, but from your level of rhetoric I suspect that you aren't.
Oh sure, I understand the reasoning (I just wish the urbanites could understand that their little 10 mile commutes aren't the only use-case for cars). My main point was just that for electric vehicles the inconvenience factor goes exponential pretty quickly as soon as you leave the (relatively narrow) window of convenient operation.
Which is great if you have supercharging stations spaced 150 miles apart. The issue pops up when one is just a bit further away than is convenient and your wait time suddenly starts scaling exponentially.
I actually hadn't considered those, my only experience with pool filtration is the cheaper end of the consumer level stuff and I just sort of assumed big community pools were the same but on a larger scale.
This is utter bullshit, and I'm a (nuclear) scientist that does give presentations. No venue yet has had an issue with me bringing my own machine with whatever opsys etc I want on it to plug into their AV system.
Nuclear is pretty unrestricted as far as IT goes. I work in the defense industry, and we confiscate all of your electronic devices at the gate. If you're presenting something, you transfer the ppt file ahead of time (they're super paranoid about usb sticks). You're stuck using whatever system IT has configured.
Slashdot Mirror
Wait... did you just put forward the case for having lots more world wars using conventional weapons? Because that's kind of the direction it looks like you're going there.
but it is a continuation that can not possibly be mistaken for a remake.
How can you make that claim when the characters from episode 6 all had amnesia as to the events that unfolded then?
I witnessed this hack multiple times as a youngster on commercial construction sites.
Rather than removing it from the saw, the framers would wire it into the open position because it allowed them to cut measured lengths of lumber much quicker.
Yep. But it's possible to make those things not be so much of a hindrance (I've definitely used some that were so smooth you wouldn't even know they're there). Making it less annoying is one of the best ways to reduce instances of people circumventing it.
I take it you've never worked on safety critical software which had to meet a certain standard of development and testing, e.g. mil 882 or iso 26262? For that stuff you'd have to have willfully malicious management for bad code to slip through in such a way that it could cause issues (and then they'd sure as shit be liable for it since the whole point of those standards is to leave a paper trail).
Bypassing safety for convenience is a common thing unfortunately, but so are badly designed safety systems that fail to meet the regulations.
I feel like if a safety system is commonly bypassed for convenience, it's a badly designed system. Firstly because it's annoying someone enough that they feel it's worth risking life and limb to circumvent, and secondly because it's easily bypassable.
The blade guard on an old circular saw I once had comes to mind as a good example. It was clearly thrown on as an afterthought of the design, and as a result tended to catch on the wood, screw up cuts, and generally just be a horrible nuisance (I've used other saws in which the guard worked a lot smoother). Eventually I just removed the thing altogether and jammed the interlock.
There are tons of factors that could make it all kinds of different peoples responsibilities. That's why generally with lawsuits like this it's common to fire from the hip and name anyone who could possibly be involved, then let the accused fight it out as to whose fault it is.
If people are doing their job, the robot software team should be able to produce documentation showing what safety went into the code (redundant sensors, secondary processor constantly checking the first one, etc.), the robot hardware team should be able to show that their interlocks and failsafes actually work, the factory management should be able to produce documentation showing proper lockout tagout training, the safety admin types hsould be able to produce documentation showing that those procedures were followed, etc. As a result of that, we'll probably see the case dismissed vs a good number of the accused parties and it'll likely come down to just one or two of them left (the ones who didn't have a paper trail to cover their asses) doing a lot of mutual finger pointing.
I rarely watch a movie more than once but I listen to the same songs rather often. I don't care for concerts, so I'm afraid I cannot relate on that matter.
That's probably why we differ. For me the streaming model is perfect because while I don't necessarily object to listening to the same song multiple times, what I like and don't like will vary depending on situation, mood, and circumstances. Sometimes I just want semi-rhythmic noise to block out other sounds, sometimes I want something that I can zone out to while programming, and sometimes I want to discover new music that sounds like some other song I heard and liked. I've also found that music I liked 10 years ago I can't stand now, and I don't have any particular loyalty to any particular song or band. As such, I'm more than happy to stream music on a temporary basis (disclaimer: I haven't once paid for a streaming service and probably never will). I feel no need to archive it for later use since there's a 50-50 chance I won't enjoy it anymore anyway after a few years.
Wait until it's your turn and we turn the cold shoulder to you when you can't afford your medications when you're 65+ and we tell you "well you should have made better business investments to cover for your retirement shouldn't you have?"
tbh I'd be fine with that, unlike a lot of people I'm capable of planning ahead and saving money. In this hypothetical, my complaints would stem from the fact that I'd spent the last 45 years paying to subsidize others who were incapable of planning ahead and was then told that as a reward for my good planning I'm ineligible for any assistance.
skip counts being a big one.
I'm really curious about that use case actually. Do you pick stations just based on "bands I liked at some point in time", or do you actually try to build them around a theme?
Mostly asking because I almost never find myself having to skip songs. The only times I ever run up against the skip limit was when I first create a new station and haven't yet dialed it in to play the kind of music I wanted it to play. If the station is playing stuff that fits within the station but isn't what I want to hear at the time, I realize that I'm on the wrong one for my current work and/or mood and just switch stations to something more appropriate.
How much energy does it take to create that vacuum under 1 atmosphere? Are you attempting to claim that the laws of energy conservation don't exist when it's a rich guys pet project?
You keep saying this, but I don't think you understand the difference between a sudden release of energy in the space of a few microseconds and the gradual release of energy over the course of multiple seconds. Re-pressurizing a long tube from one end can't happen instantly, so it will most definitely not be the same as releasing whatever amount of energy you think is stored in 1atm of pressure differential all at once.
If you don't believe Thunderf00t's science, try Mythbusters who did something similar with a rail car tanker.
If you're going to cite mythbusters, might I point you to the other test they ran in which they poked a hole in the side of a pressurized aircraft body and nothing much happened? No metal peeled back, no explosive decompression, just a fast air leak until the pressure equalized. It's been a while since I saw that episode, but iirc they eventually had to put explosives on it to actually make the sudden change in pressure actually do anything catastrophic.
I'm not unfamiliar with linux. Over the last 15 years I've tried redhat (back in the days before fedora was out), gentoo, fedora, ubuntu, and debian. Of those, I ran ubuntu and debian fairly consistently on my laptop all throughout college. Whichever linux installation I was using tended to shit itself about every 6-12 months, so I basically ended up having to do a clean reinstall at the beginning of each semester. I never once had an installation of a new version go smoothly (there was always a weekend of googling to fix whatever nonsense happened during the installation), and I was never able to have an install in which everything worked. There was always some niggling little annoyance e.g. the wireless wouldn't come back after entering sleep mode, monitor brightness wasn't adjustable, touchpad scroll zones wouldn't work, etc.
I know at this point you're either going to say it's because I didn't know what I was doing (maybe true), or shrug and say it's just anecdotal. But if it was really just a one-off thing where I've somehow consistently never been able to have a smooth linux experience, I suspect that desktop linux would have a much much bigger market share at this point in time.
Sounds like you played a little bit too much in the system files without knowing what you were doing.
In the case of SteamOS I had the sheer audacity to install chrome and then occasionally drop to desktop mode to watch streaming content. I know I know. The OS isn't really designed for that level of tampering by a user and I probably shouldn't be blaming it.
I also (as many do) tend to reuse passwords with minor variations. Most of my passwords (even in the file) are "shorthand" passwords that wouldn't work as listed in the document.
I don't understand why more people don't do this. It's easy to come up with a suitably long and random base password that you can then add minor variations to based on some algorithm to make it unique per website or service. e.g. if P@ssword1 is your base password, your slashdot login might be sP@sslword1a (sticking the first three letters of the site into the beginning, middle, and end of the password). Assuming you use an actually random base password and do something a little more sophisticated to mask where you're getting the variance from (e.g. rotate the site initials based on the value of the first one) no one is going to be able to figure out your other passwords based on seeing just one or two in the event a database with your plaintext credentials gets pwned.
Obviously that's not the be-all end-all of password security and you'd want to use truly unique passwords for important stuff (bank, email, etc.), but it works great for the 100s of unimportant/semi-important passwords that you use on a semi-regular basis without putting all your eggs in one basket like with a password manager.
I've read your comment and I could respond it by copy-pasting the last one I've wrote. Did you really read my comment?
I've read your comment and I could respond it by copy-pasting the last one I've wrote. Did you really read my comment?
Let me ask you something else then. Are you 100% certain that it's absolutely impossible (even in a millennium) to design a safety measure that will safe all passager that are alive in a plane (to discard to one that have been killed by a bomb or something) before it's inevitable crash?
In this way lies madness. It's the "if it saves just one life" argument I was referencing in my previous post. You might as well be asking why we can't just build the aircraft out of the same indestructible material the black box recorder is built from (har har). Here, I'll make one more attempt at explaining this to you before I give up:
I think it's fair to assume that parachutes will be useless during takeoffs and landings, which account for >50% of all fatal crashes of commercial airlines according to the stats I could find. Ruling out terrorism and pilot error is also fair (in all of those cases they'd have manually overridden the ejection system anyway), which drops those numbers even further. I don't have the time to comb through plane crash databases for the remaining ~35% that happened at altitude, but it's safe to assume that a lot of those were a total loss and would not have been able to deploy a parachute (e.g. midair collision completely destroying both aircraft).
Now you have to analyze the parachute system itself. We've established that a very small percentage of deadly incidents could have been salvaged via parachute. Considering that there less than 200 deadly incidents per 10 years (and that number has been dropping steadily), we're talking like 30 accidents where a parachute system might possibly have saved someone. Now can you say for 100% certainty that a parachute system isn't going to introduce additional failure modes that didn't exist beforehand (including failure modes that we won't know about until they happen and kill people)? e.g. decreased structural integrity, increased weight making the aircraft harder to recover from an engine loss event, failure of the system itself causing unnecessary ejection of passengers, increased maintenance complexity (more opportunities for human error) etc? It won't take more than one or two before any gains from having such a system will be completely negated.
My point here is that your time and effort is better spent on finding ways to keep human error from causing problems. Rail about economics all you want, but ultimately that's what system safety comes down down. You have to weigh the risks vs the cost of the mitigation (cost being defined as performance loss, additional risk, and of course actual additional cost) and decide if it's worth it. In the case of airliner ejection systems, the use case is just so niche that you're making a very hard sell.
Oh wow, I wish I had mod points. This is exactly the kind of post I read slashdot for.
You're neglecting to calculate how often a condition will happen in which a parachute will be able to save more people than a controlled crash. System safety 101 tells us that risk = severity * probability. Not running the probability numbers means you're only getting half the picture. It'll very quickly lead down the road of "if it saves just one life...", and the only thing you'll find there is madness. My argument is that the probability of conditions occuring in which a parachute would be beneficial is so small as to be basically zero. You'll get greater return in terms of lives saved per unit of engineering if you spend it elsewhere (e.g. adding more redundancy to the aircraft, safer airframe design, smarter health monitoring, etc.).
One of the other things that goes along with safety analysis though is looking at both the consequences of some failure as well as the probability of that failure happening. There are so few instances of commercial aircraft going down in such a way that ejecting passengers would have saved more people than attempting a controlled crash landing that it's a safety system that just doesn't make sense. Even if you could implement it for free, on the (incredibly rare) instances it would have to be used everything would be so far out of operational parameters that it probably wouldn't accomplish much.
That's not been my experience. Yes it's miles better than it used to be 10-15 years ago, but I've yet to install linux on a computer where everything just works out of the box. SteamOS came close, but small things kept breaking every few months until eventually it just sort of self destructed after an update and refused to boot anymore.
If all (or even just some significant number of) homeless people were only homeless because the president forgot to pull the "more jobs" lever at his desk that morning then you might have a point there. Problem is that if you put a typical sampling of homeless people together in a home, what you basically get is an insane asylum. There's no problem with that if you're willing to call it (and provide the resources for it) for what it is, but from your level of rhetoric I suspect that you aren't.
Oh sure, I understand the reasoning (I just wish the urbanites could understand that their little 10 mile commutes aren't the only use-case for cars). My main point was just that for electric vehicles the inconvenience factor goes exponential pretty quickly as soon as you leave the (relatively narrow) window of convenient operation.
Which is great if you have supercharging stations spaced 150 miles apart. The issue pops up when one is just a bit further away than is convenient and your wait time suddenly starts scaling exponentially.
I actually hadn't considered those, my only experience with pool filtration is the cheaper end of the consumer level stuff and I just sort of assumed big community pools were the same but on a larger scale.
solutes don't generally separate from the solution via filtering unless you precipitate them out first.
This is utter bullshit, and I'm a (nuclear) scientist that does give presentations. No venue yet has had an issue with me bringing my own machine with whatever opsys etc I want on it to plug into their AV system.
Nuclear is pretty unrestricted as far as IT goes. I work in the defense industry, and we confiscate all of your electronic devices at the gate. If you're presenting something, you transfer the ppt file ahead of time (they're super paranoid about usb sticks). You're stuck using whatever system IT has configured.