Have you ever hurt yourself from your own code?
blog.nikitas.link
blog.nikitas.link
One day I had some friends over for a glass of wine, and wanted to show off my creation. I invited them into my "lab" and placed my wine glass down on the desk so I could type a few commands with both hands.
My rudimentary software had some motion smoothing once it was up and running, but upon initialization, if the arm was significantly displaced from where it had been when it was turned off, the PWM board would instruct the motor to immediately "be" in a position that required the arm to travel clear across the desk in effectively as little time as possible.
In this case, where it had been previously happened to be where my wine glass was now, and the flimsy aluminum at high speed was enough to shear the stem from the glass and explode the bulb. Luckily the wine didn't get in any sensitive electronics, but I learned a valuable lesson about the difference between messing around with hardware vs software.
One key observation, though, when working with code is that the machine becomes so close to predictable that it's more dangerous than if it were unpredictable. A cordless handheld drill is hardly a tool that most people would call 'hazardous'. You turn the trigger, the thing rotates, grab the chuck and you can likely stall it. But that much energy in something driven by code is extremely dangerous, it's waiting for any of who knows how many conditions to take off, a common one is that putting your hands in/on something that seems to be not moving can 'make' a sensor and the machine will take off.
There are definitely two kinds of safety domains, one applies to manually operated tools where the operator of, say, a knife is responsible for their own safety - if they cut themselves, they're at fault, not the knifemaker. There's another kind of safety engineering where if the machine takes off 'by itself' while an operator is in the way it's the machine designer's fault for not stopping that from happening, the operator can't be expected to know what's going on.
The latter should become more common as computers continue to permeate everything we use - that cordless drill is no longer controlled by the operator with a trigger switch that connects power to a DC motor, it's a brushless motor driver with an analog input sensing the position of the trigger and the EMF of the motor, and the charge state of the batteries, and who knows what else. Bump a sensor and it might take off, you don't know why it does what it does.
I'll continue to make my automated cells as safe as I can, but don't trust code that's not so simple you can be confident of how it works.
A friend needed a valve cover gasket changed on his Honda, and his wife needed to use the car for her Uber runs that night. He came over and instead of our usual hand tools I put a socket adapter on my 20V drill to speed up disassembly. I handed the drill to him and told him "start on the lowest torque setting, and move up in small steps."
I turned around to grab more tools from the toolbox. A minute later, I heard a loud noise. I turned to see the car's windshield cracked and a shocked look on my friend's face.
My friend was used to his renter's power drill. He hadn't anticipated how much torque a modern contractor's drill outputs and set the torque to the maximum setting. On the third valve cover bolt, the drill had caught on the bolt head and spun my friend around, smashing the battery into the windshield.
There's a piece of paper taped to me toolbox called "List of things <friend's name> may not attempt unsupervised." It gained a couple of entries that day...
Relevant old article: http://www.team.net/mjb/hawg.html
But that same drill might be asked to bore a large hole in a piece of wood, and the user would anticipate the amount of leverage they need to control it. Two hands, arms close to body, etc.
That is often the difference between home and tradesman tools. A tradesman can reasonably be expected to handle a bit more responsibility from their tools than the home handyman.
For a continuous drilling operation the torque is totally fine, the problem is abrupt changes in torque because of something catching. On drills without this feature that's what the torque limiting clutch is for.
We actually had an older drill with the mechanical clutch with a stripped high gear that we kept around for driving screws instead of tossing because the new one was so bad.
A lower power (e.g. 300Nm max) battery driver is great for when you have to undo lots of lower sized bolts, while it would be a little bit underpowered for wheel nuts or motorcycle fork retaining bolts.
They're supposed to tentioned correctly with a torque wrench, usually between about 110 and 120Nm.
Edit to add a reference, just random from a search: https://www.barum-tyres.com/car/expert-advice/safety-driving...
And for that purpose, it does seem appropriate.
However my point still stands, somewhat: if 300Nm is insufficient to undo your wheelnuts, they're way too tight.
Ducati single-sided swingarm nuts can be similar, but I have not yet owned a Ducati.
You should image-search the term "radial drill" sometime. ;)
$21: https://www.amazon.com/Irwin-Tools-Drill-Press-226340/dp/B00...
$25: https://www.harborfreight.com/4-inch-jaw-capacity-drill-pres...
You don't need a high-dollar Kurt milling vise for a drill press, and you only need to constrain the part in one degree of freedom (rotation about Z axis). Just put a single fastener in your table and drop the slots in that vise over it. Gravity and quill pressure hold it in Z, the table holds it flat against rotation about X and Y, and you want it to have the ability to slide a bit in X and Y to let the drill find the center of your punch/pilot hole. If the drill catches, the torque will push against the stud and it can't move.
Back in 2002, I was getting a package with a brand new Pocket PC (smartphone without the phone, running Windows). And I really wanted to know when it was delivered, but the UPS guy would regularly leave packages on the porch without ringing the bell or anything.
This was before you could get delivery alerts or anything like that. But I had a spare laptop with an integrated webcam (wow!), and I'd figured out how to make it run actions on motion detection.
My plan was to point the laptop at the door, and eject the CD drive when it detected motion. The tray of the drive would push a water bottle off the table. That would land on a seesaw, which would launch a deck of cards in a hard plastic case at the door and make a very loud noise.
It's unclear why I couldn't just play a really sound on the speakers instead. Anyway, I tested the program by standing in front of the laptop and waving my hand.
It worked perfectly! The CD tray ejected, and I watched as the water bottle slowly rolled off the table. It dropped onto the seesaw...... and instantly launched a hard plastic deck at my face and got me right between the eyes.
Never again have I been in so much pain and also so excited about my code working perfectly at the exact same time.
Also I like that even after you came up with "knock something off the table" you felt you needed a seesaw catapult thing and didn't just knock something off that could make the actual sound like a cake tin or bell or something.
It totally doesn't make any sense! I think I might have been fascinated with the idea of Rube Goldberg machines or something at the time. Or maybe I thought I could build a "security system" with it? Also it was summer and I was a bored teenager.
I used to have multiple clamps around the controller, message bus, the firmware and also a physical barrier, and yet would not feel safe with my fingers or person around moving parts.
It’s weird how even ordinary things can be dangerously loud.
There was an absolutely almighty BANG, of the 'an explosion has just occurred' variety that made me very glad I wasn't actually cutting metal at that precise point in time. His g-code had an off-by-one error (I think) and it had dutifully picked up a ~20 cm HUGE flycutter, spun it at the speed of of a ~5 mm bull nose cutter, and driven it directly down into a piece of aluminium. The flycutter had broken and effectively welded itself to the aluminium, which had sheared down the middle, spun out, and hit the protective guards that completely encompass the machine. The person driving it (either a postdoc or graduate student) was maybe 40 cm away and saw this ~2 kg piece of metal bounce off a thick reinforced poylcarbonate guard directly at the level of his head.
Safety equipment saves lives.
It was close to lunch, so I kept eating.
The finale was a jar of mayo spilled into the guts of a 50k server. Best mayo I ever had.
Anyway, try out a Point Chaud. Same overflowing sandwiches.
I once bought one, I walked out the shop and 45 meters later the sandwich literally went through the paper bag and fell down on the ground.
Or a dental x-ray machine has the final "run" button in the hallway so the nurse taking x-rays must go there to do it, so they don't get repeated exposure.
You're supposed to turn off the circuit breaker and lock it with your own personal lock that only you have the key to. That way no one can turn it on even if they wanted to.
I've heard no one, under any circumstances is allowed to take the lock off. If the person leaves after their shift and forgets to take it off for example, they have to come back in the middle of the night so to speak and take it off.
It's not only electricity that needs to be isolated and locked out. A lot of machines use air pressure to operate moving parts, so in that case you'd have to isolate all electrical sources as well as the air. The machines I usually mess with require 2 locks. Some of the machines I've seen can require 6 or more locks to be fully locked out and safe to work on.
A typical maintenance period might require 100 or so separate tagouts, each of which could require anywhere from one to dozens of tags. Each duty watch was required to show up early enough to go through the entire tagout book and at least know the gist of what was in progress.
Finding a loose tag was an automatic all hands all work stoppage, until it was tracked down and resolved. No questions, even if your work was in a different compartment, or had no logical connection to what he tag was for.
Each new tagout request had to be signed off on by at least three people, sometimes all the way up to the captain and not just a foreman or supervisor but one or more shop heads.
Seawater system tagouts on a floating sub were serious business.
Sadly the inventor couldn't convince the tablesaw manufacturers to use his invention for cost and/or liability reasons so he had to make his own. Their tablesaws themselves are relatively expensive but cost per accident is $100 for the charge plus whatever the blade costs, so basically $200 to prevent serious injury or death.
So on a worksite if you are using lumber that hasn't had adequate time to dry the saw stop would trip even without any limbs being in danger.
Each time it would destroy itself, you would have to take the saw apart and change it which would cause a work stoppage.
What irks me the most is that the SawStop owner tried to create legislation that would have required companies to use his product.
The lobbying is off putting, yes, but at least his greedy self-interest would do some actual good instead of extracting evermore capital from everyone. Powertools inhabit this uncanny valley of dangerous equipment where they're cheap and accessible enough to the average joe (compared to CNC machining centers or forklifts or whatever) yet powerful enough to do some real damage. My understanding is that the primary reason the major manufacturers didn't want the SawStop wasn't cost but the fear that it would expose them to more liability by making the tools seem less dangerous. I really wish it achieves mass adoption so that the price drops even further.
The problem with causing $300 of destruction and lost work time vs possibly saving a limb is there's no fine woodworking operation or framing carpentry operation that requires a table saw. Technically if you feel unsafe working with a table saw you can do absolutely everything very slowly and tediously with a router or router table or bandsaw, or manual tools like a chisel and hammer. Anyone concerned about safety doesn't use a saw stop, they use an entirely different technology than a table saw. If you make a table saw too safe or too expensive to actually use, people will simply use something else. The death toll may or may not be lower...
From a marketing perspective, the people most likely to buy a saw stop because they're scared of table saws will save a lot of money by not buying either sawstop or table saw, and they'll cut dado slots using a hand held router (more dangerous in a different way) or break down plywood using a tracksaw (unholy expensive and many crushed foot injuries) or cut beveled edges on a router table or zillions of alternatives. Meanwhile the people who don't care about safety because they're not drinking on the job or they actually use the substantial amount of safety gear that makes a table saw perfectly safe OR they only do operations on the table saw that are inherently safe by nature (as opposed to relatively low risk operations, and some very high risk operations that people do anyway), will continue to save a lot of money by the combo of not being dumb and not buying sawstop. Finally the real dumb woodworkers who get drunk and get hurt or simply don't care, will continue to not care and not buy sawstop and will not live too much longer in a world either with sawstop or without table saws anyway, so its not like the world will net improve, the Darwin award winners will continue to win Darwin awards. So sawstop is a VERY hard sell.
A similar problem is well manufactured table saws are safer than homemade table saws. The concept of "put a round blade on a motor" is too simple to legislate out of existence. So making table saws illegal wouldn't eliminate table saws it would just mean the homemade ones will make table saws, on average, more dangerous.
Arguably, radial arm saws are more dangerous than table saws and "the marketplace" effectively eliminated those decades ago, so its not like the marketplace dislikes safety or whatever.
> Meanwhile the people who don't care about safety because
> they're [never doing unsafe things]
This sounds an awful lot like suggesting that skilled users of firearms don't care at all about safety because no one's going to deliberately do stupid stuff. It seems farcical to me. Just as with firearm safety rules, they're there to protect people from the rare moments when we are inadvertently NOT careful. History has shown that people DO do stupid stuff because they were thinking about something else, or were tired, or distracted -- hence why every firearm is treated as loaded, even if you unloaded it, and why weapon safeties exist.For table saws, having a sawstop helps prevent situations that you don't have fill control over from having bad consequences. Of course you'd still use all the same safety measures you normally would without one.
There's another class of accident involving equipment. Some people do not store firearms with trigger locks or unloaded in safes or whatever. Likewise there's an analogy with table saws where I don't rip small boards without a nice featherboard, riving knife, and some really nice plastic pushsticks. If as you claim my mind drifted, this time by use of tools it would still be physically impossible to hurt myself.
There is a class of inherently dangerous operations where no safety tools exist but the table saw is so versatile and flexible people can successfully do the operation... most of the time. My point is instead of spending more money to build a "better" tablesaw to do something dumb, simply invest the money in a COTS bandsaw or track saw or jigsaw hole cutting jig or chainsaw or planer or whatever crazy risky thing there's a better, faster, safer tool. You can do dangerous things with a table saw but there's always a better safer faster way to do it with a different tool. Taking away money by making the required table saw more expensive just means the woodworker will not be able to afford the superior even safer tool for the job.
All the evidence I've found is super cloudy, but early reports indicated Bosch's variant predated SawStop's release.
Luckily SawStop's patents expire in a few years so hopefully we'll see other safety mechanisms similar to SawStop without the downsides and greed.
[1] https://www.youtube.com/watch?v=NV6Jhw0hhBI (at ~3 min)
Not everybody's cup of tea, but our ability to be 'present' is highly variable, both person-to-person, and one person over time. I'm a somewhat daydreamy sort of person, so I work to bring focus when I'm using power tools. As a hobbyist I walk out of my shop when I get tired, emotional, or otherwise distracted, but that's not an option for everyone.
Is there any proof of this? From my understanding, that's a myth. Demonstrated here at about 3:00 https://www.youtube.com/watch?v=NV6Jhw0hhBI
It's also saved a few legit fingers, so it's still a net win, but you've got to have pretty deep pockets to cover all the false trips.
You’d be surprised at the number of materials you might want to cut on a table saw that are unexpectedly conductive.
Every tablesaw injury I remember hearing about involved the operator failing to follow some of those guidelines.
Of course, the weakness of a system like this being if middle management is demanding unachievable timelines and/or people in the shop are willing to cut corners, someone can leave a box of heavy stuff on the pressure pad to "save time." Absolutely right that all these systems need to be resilient to operator tiredness etc
What does this mean?
I'm just glad that ultimately he was the only one who faced physical consequences for his poor choices. And thankful that the consequences weren't that bad at the end of the day; a broken arm is way better than a cracked open skull.
That made me actually lol.
I would assume he'd be the poster-child for following safety protocols after that. But I'm still learning a lot about human nature.
Is he next to the malfunctioning robot?
In other words, some person did something very stupid, while thinking he is clever.
Back when I was doing some hands-on practical training in electric engineering school, we had to design a control circuit on some breadboard, the kind that in high school would lit a couple of leds, and maybe make a light fade, but here it was driving a big-ass train engine boxed in a 1.5m x 1.5m x 3m steel cage, right next to the bench where we pieced the control device together, barely arms length away.
While conceptually the same, "theory" vs "practice" and "command" vs "power" suddenly takes a whole new meaning where you're suddenly pushing several orders of magnitude more power than a puny 9V battery could. The buzzing of a hundred amps ready to flow inches away was chillingly ominous. You get a strange urge to triple check, quad check even, design and calculations before flicking the switch.
As we all successfully started up our bench, the rumbling of a dozen of these bare protomachines revving up in a hangar was eerie. The thought of them sucking in such an amount of overall power from the grid dizzying. I rarely get cold-sweat and goose bumps, but this was one of these days.
She mentioned that this had happened to a v high end CNC machine the cutting tool after a power cut went straight to the home position very $$$$$$$
At my place we had a computer controlled wave tank and as the guy I shared an office with said you could program the ram to go full travel in zero time which would have flooded the lab.
Tesla Autopilot developers should read this.
The motors were quite powerful and there were a few close calls which really made you think.
It used to twitch violently as it was calibrating on initializing. Once, it reset and did that while testing. Luckily the person holding it managed to get his hands out of the handles on time.
Another tim the tip of one instrument had broken off and during initialization there was an error in the force applied in the direction along the shaft. It flew out like a rocket.
The way I got my notice of termination was while I was running some tests on the production database and needed a "negative" so I searched for a userid that was not present in the database: my own.
When I saw my name in the list I called my manager and asked him what was going on.
He said "Alex, why don't you head on home for the day and I'll call you there"
I wouldn't say "hurt" though. Nortel went bankrupt and I got a great severance package.
“Some say Alex is still collecting a check to this day.”
Everyone who worked on the machine are now gone, yet it continues to do what it was designed for. That is until I found myself on the path of the machine...
Just kidding, but it would make a great origin story to this: https://news.ycombinator.com/item?id=17350645
As non-native English speaker this expression really puzzles me.
'Head on home' is a real expression. Similar ones are 'head over there', 'head to ...', all of which just mean 'go to'.
I can't find the etymology beyond words meaning the body part or "primary"/"main". There's no direct equivalent in German for example despite the shared etymology for the other meanings.
I would guess that it is related to the body part in a figurative sense in the same was as "face" (i.e. turn your body in a specific direction) though I have no idea how "put your head there" would come to me "go there". I wonder if this was before or after "heading" became a thing for ships (which generally move in the direction they "face", so the "heading", i.e. how the "nose" is aligned, could go on to become a verb).
EDIT: I'm not sure it's pars pro toto because I'm not sure it directly refers to the "head" in the sense of the body part rather than the "heading" which is not directly related to the actual body part when talking about vehicles like ships.
Both people presumably do know what's really happening, and this is exactly why it's seen as unnecessary (and inconsiderate) to actually say it. There's no reason to call extra attention to something unpleasant.
"Hey, bud. Why don't you pick up those two plastic containers and follow me."
"OK, but dad, it really confuses me when you say that. Can't you just say 'please pick up those containers'? It sounds like you're giving me an option but you're really not."
Until he said that, I had never given it a thought. But he takes things very literally, so I can see how it's confusing even though he knows what I mean.
I think English littered with these suggestive polite negation statements.
As others have said, it's definitely a 'softening' of a request to make it more polite ('Go home' vs 'Would it be possible for you to go home?').
But I think there are some status games going on here, too. A subordinate would never use that phrasing with a superior.
While the phrase uses conditional language to 'soften' the request, it's also an imperative (an order) that's made to look like a request.
Try to imagine the boss saying this. How would they have said it - with an upward inflection at the end, as in a question like this one? Definitely not! The phrase would definitely end on a downward inflection, as in an order like 'Please go home'.
It's a curious turn of phrase that I'd suggest is particular to managers, parents, and other authority figures that need to maintain a veneer of respect for their subordinates. It also strikes me as uniquely American; I couldn't imagine a Brit or an Australian saying something like this (but happy to be corrected).
https://en.wikipedia.org/wiki/%C2%BFPor_qu%C3%A9_no_te_calla...
(I don't know whether it has exactly the same set of connotations in Spanish as in English, but it doesn't seem like the king expected Chavez to do something other than comply.)
Work for a company for what you get from them, not for what you can give them!
I worked for the Australian subsidiary in the 90s when they had "Vision 2000" of becoming the world's third largest telco by 2000.
Off to Aliexpress and Banggood I went. I ordered a carbon-fiber chassis, big strong motors, ESCs, 3-inch propellers, a FrSky receiver, a Devention transmitter, an STM32-based controller, giant li-poly batteries, and all the cables and fasteners I needed. Over the coming weeks the parts trickled in. Finally once the whole kit had arrived, I assembled everything, connected the TTL serial, built the firmware, downloaded it to the controller, and like the brilliant software engineer I am, plugged in the batteries on my bench at home.
Nothing happened. Those of you who have blown off fingers wondering why the firecracker under the Coke can hasn't exploded yet can guess what I did next.
I examined the chassis closely and began fiddling with the cables and connectors. Again, like the brilliant software NOT HARDWARE engineer that I am.
Evidently, I fixed the problem. Which caused four gigantic propellers to begin whirling around my hands and face. And four brushless electric motors to emit their usual high-pitched whine, which today I instinctively hear as them saying to me "You god damned idiot. You are so ours."
I was not injured. But that evening, I came close to slicing at least a couple things off my body. I hadn't appreciated the scale of the thing I was building, or the inherent risk in debugging it once I'd slapped it all together. I shelved the project for years, eventually giving it to someone at work who claimed to know his stuff when it came to drones. I hear he's doing fine.
Disclaimer: this story isn't about code or my own code. But I think it fits here because I approached dangerous hardware with the "build, run, see what happens" mindset of a software developer.
But really I'm pretty sure if for example civil engineers could build a bridge in an hour and load it up consequence-free they'd do it too.
The fact that we do it isn't bad at all, but yeah it's easy to not realize when you've exited the realm of consequence-free testing.
A crane is just a bigger print arm :)
You type in your commands and then magic happens and something is build (after a while). Nothing to be done by hand (ideally)
But I would love to play with a fully automated remote controlled printer the size of an crane, though.
But then there should probably be no humans around.
Made me very nervous for a long time, especially the first few flights (or attempt at flight).
Now I twitch whenever I connect the battery and the FC makes them jerk a little. I know they aren't armed and failsafe is active and all, but you bet yer tuchus that I'm super careful connecting!
Glad you didn't shred anything.
(It was some faulty hardware. Dont remember the details; it was a non obvious issue with one FC. Wasn't worth fixing the hardware, I discarded it.)
I had a similar scenario with the same preconditions. In this case, one of the propellers came off and barely missed a face.
This was a 10 inch hard plastic prop with some sharp edges. It could've taken an eye out. It could've caused serious cuts. It could've been a carbon fiber prop and caused _serious_ cuts. Of course it could also have been a soft plastic, round edged prop that would've done less damage. It missed, and nothing happened.
In this case, the cap on the mount wasn't tight enough - complete negligence; preventable. But what bothers me it that it is not possible to completely prevent that kind of mistake. Mount caps _can_ shake loose under vibration - with some features (spin reversal) there is no one safe screw direction. Also, mounts can break. More importantly, prop blades can break. Some prop mounts only use rubber loops to secure the props - they props are _meant_ to fly off off in that case. A prop could be inverted, or the PID controller could diverge, potentially sending the entire copter into your face. Probably everyone should wear safety goggles. But nobody does, and things rarely go wrong. At the very least, please do not have your head on _or above!_ the propeller's plane. Search Youtube for "quadcopter hand launch" for an appreciation how often this rule is broken as a matter of normal, routine operating practice. Often the person holding is not the pilot. That's some trust, when a small inadvertent finger movement on the pitch axis could permanently injure.
What also bothers me is that the people who should and do know best often ignore safety the most. Ever seen a group of copter devs scramble as the noise of the copter thirty feet overhead cuts off? Ever seen the same group charge a few dozen lithium polymer batteries that have survived more than a few crashes, unattended, with no fireproof bags, with no fire extinguisher, in someones room? Nothing ever went seriously wrong. But everything could have. And dont get me wrong - these are smart, safety minded people.
Along the same lines, if you are ever near someones DIY lasercutter, say in a hackerspace/makerspace... do _not_ assume it is eye safe, no matter what they claim and what laser safety certs they claim to have. In particular, do _not_ ever assume it is eye safe when you look at it from an unusual angle, like when you bend down, kneel, or when small people, children or pets are present. I have seen multiple DIY lasers get the top cover right (easy - any thick plastic sheet will block stray light from a CO2 laser), and completely and utterly fail to close small holes in front (air vents, or lid not closing perfectly, ...). There's a back of the envelope calculation that looking at the diffuse (not even reflected) spot (invisible! - and there might not be secondary light) a 100W CO2 laser (a typical size for ambitious hobbyists) creates on a surface can cause permanent eye damage if viewed from 1 meter away.
Believe it or not, but you can find YouTube videos where the two are combined.
well, some of us do, it's called 'FPV'.
I soon realised my electric soldering iron wasn't powerful enough so I nipped out and bought a miniature blow torch. The kind which are basically a big cigarette lighter. Having got it home I tried igniting it a few times and nothing happened. I held it up to my ear to try to hear if there was any gas coming out, sure enough there was gas coming out, which in that instant ignited beautifully into a 700 degree flame pointed right at my ear.
Sliced it pretty good! Honestly, if I had just touched it closer to the center it probably would have been okay...
I still remember an EE lab professor saying one day "get in the habit of using red wires for Power and black for Ground. That way, when you have your first accident, maybe it won't be too bad."
Or a technician I used to work with who would quote his tech school instructor daily, "NO, no loose conductors on the test bench."
All the nail heads on my work bench are covered with electrical tape. I try to use red wires for + and black or green for - whenever possible. I learned to think about what could happen before I flip the power switch (first power up use the lab supply with current limited to the absolute minimum the circuit needs), or when I hit F5 in the debugger (does anyone have their hands in the machine?).
I've still set things on fire, still broken expensive pieces of equipment because I had the wrong sign on a variable, still made loud banging steel-on-steel noises because I didn't calculate an offset correctly etc.,
At the end of the day, if everyone goes home with all body parts intact, we'll call it good.
I eventually figured out I'd shorted and destroyed the 7805 regulating the DC input to 5v. My first in-the-field electronics repair was to remove it, bodge it, and live with a USB-only Arduino. I still have that Arduino; it's a reminder of the first time I let out the magic smoke.
Dropped to 10 meters, set the datum and started swimming, going well until I crossed into a negative quadrant. My beautiful track went haywire/dead.
Then I swam around trying to get back "into" the positive quadrant, I couldn't find it and consequently couldn't get back to the datum. When I surfaced I couldn't see the dive boat!
After some time contemplating my life/coding choices for literally jumping in without thorough testing, I heard the Zodiac inflatable buzzing around the rising waves looking for me.
Back on the boat I discovered that I had only coded it to work in the positive axis from the datum. In the other axis the location was undefined.
What kind of devices are involved in scuba tech like that?
For similar reasons I usually dive with an analog backup gauge.
I put the headset on, and quickly noticed things weren't working right. I was walking around, trying to figure out what the issue was. Trying walking back any forth looking at a wall in front of me, I felt terrible pain. Something about the left and right eyes seeing movement in different directions across their entire field of view really breaks the brain. It was very sharp and localized too.
The brain's perception system is weird.
I spent maybe 20 seconds in VR with skewed floor and it felt horribly wrong. And the whole evening my sense of ballance and perception was broken not to be the point of falling over but the real world around me felt wrong. Only after I slept my brain fixed itself.
This kind of unconstrained motion is notoriously hard on VR players, and I felt a bit uneasy the whole time when I was navigating this way, but then I made a mistake. I wanted to rotate myself, so I instinctively grabbed two handles and made a sideways hand motion, sending myself into a fast spin. I almost puked, and even after taking the VR headset off, I kept feeling nauseous for the rest of the day. Like in your case, my brain fixed itself when I fell asleep, and I woke up feeling fine.
Since the brain and the body are wired up pretty closely - this is not so weird at all.
The funny part is: I didn't shock myself, I punched myself.
I had the electrodes connected to my pectoral muscle and I was adjusting the levels while holding up my arm with my hand to the side of my head. A random current change translated to a huge voltage boost, the pectoral twitched hard, and BLAMMO, punched myself in the bridge of the nose.
At least I think that's what happened. Could have been changing skin conductivity, but I like to think my Teensy code hurt me. (I eventually removed the MCU and just used two comparitors with a voltage-controlled duty cycle oscillator... much easier.)
For the first integrated test on the robot, I high-centered it on some bricks so the wheels would turn freely, on the bench. Didn't want to deliver too much torque with wheels up, so asked for 1% PWM duty cycle. The robot leaped into the air, tearing off its umbilicals, hit the floor spinning and generally smashing shit up, including bits of me.
Debugging revealed that the output PWM duty cycle was inverted when commanded <2%, so my 1% command was 99% power. My breadboard tests had never gone below 3%, which I guessed was the minimum to overcome stiction on soft ground. Poor robot. The chunks out of my hands were the price I paid to learn to test important corner cases.
Some hardware implementations are notoriously weird on edge cases. Some manufacturers built PWM modules so 0 setting on the on-time register means “no signal”, while for others it means “minimal on-time” (no signal is achieved by turning off the module).
The other bad handled case is when going above period (if period is set at 210 clocks but on time is set to 250). Some implementations wrap around, some get locked in “always on”.
> CAUTION: macOS system volume doesn’t effectively limit audio applications’ maximum volume. Extra care has to be put in working on this platform, especially with headphones, because programs can produce unexpectedly loud sounds regardless of system volume settings, potentially causing ear damage.
1) system volume level pretty down (usually 30%) 2) headphones volume in the middle 3) when testing something really broken I have my headphones not on the ears but on the neck
However I use that 30% system volume for my day to day usage. When needed, I can always bring volume up.
It's absurd that there are no safety mechanisms implemented in hardware.
A friend of mine once gave me an old computer (I don’t remember exactly but it was some random Compaq running Windows 98 and this happened in ~2010). I installed some distro in it but tbh, it was barely usable.
I decided it was a great opportunity to see with my own eyes what would happen when you intentionally « sudo rm -rf /* ».
Well, no surprise, it erases everything. Conscientiously. Recursively. Including the mounting point of the USB hard drive where I stored my hobbies projects. Including the network share of my other computer’s /home.
No real harm if you don’t account the dehydration from sweating.
The most painful part was the hundreds of photos I just had finished scanning. At least I got quite good at scanning photos..
TIL network shares also get deleted in recursive deletions.
Unfortunately I had busybox rm earlier in my $PATH and it started chugging through my files.
And then there was that one infamous time in Debian libc broke in Testing/Unstable. Suddenly literally every application, minor or big, was broken (everything used libc).
I was building a UI element which used a single slider to both control the output of the light and show its current position. First attempt had a bug which caused an infinite loop of the UI setting the light to 100%, then the light setting the UI to 0%, and back and forth.
The light was on my desk in an otherwise dark room. I (thankfully) don't suffer from epilepsy, but the the rapid, constant changing from incredibly bright to near darkness made me dizzy to the point where I couldn't really move.
Luckily a breaker tripped after a few minutes.
Since many of these robots use ultrasound locators based on echolocation to find other robots, we want to eliminate those from detecting us. One of the strategies we wanted to try, was to generate sound at the right frequency ourselves, which should completely ruin those sensors, thus making us invisible for no apparent reason.
So I bought a transducer used to clean ships, which was rated for use around the correct frequency. I connected it to a signal generator at an ultrasound frequency and wanted to test its effect on the echo sensor.
Now, I am doing this sitting in a noisy lab with a bunch of noisy instruments, robots whirring and computer fans. Some other people in a corner chatting away.
I put the transducer in front of the distance sensor, set up the program to print the distance measured, turn on the signal generator, and the whole room goes eerie silent.
I turn it off, and luckily the sound comes back immediately. It appears that if you pump 100+ decibels of ultrasound in a room, it actually drowns out other noise! This thing was quite powerful. After all, it was made for cleaning ships from foul.
At that point, I do realise I have no idea whether this is a safe thing to do for my hearing (and that of the audience), and shelve the idea. But I remember the split second where I thought I made myself and everyone else in the room deaf.
Obviously, we did not shelve it right away since there seemed to be no permanent effect. Some people were really creeped out after they had been exposed in my first try. But this is an engineering lab, so soon enough the lab was filled with cowboys wanting to experience it and trying to figure out how it works. Meanwhile, the more safety minded people took a short break and went for some air outside.
We stopped after the professor figured out something odd was going on on his floor.
Let's hope your PhD wasn't imaginary either, cue "science reproducibility crisis".
I am not sure what causes the other sounds to sound dampened, I figured it had something to do with how the ear works, that the sounds were physically still there.
But it is easy enough to try. Get a speaker or transducer rated for ultrasonic frequencies, and pump it with enough power that would make a real speaker sound painfully loud.
This is important, but more broadly, practice good sound hygiene: wear headphones them around your neck until you know for a fact that it's safe to put them on your ears. Additionally, never play "new" sounds without remembering to set audio output to a tiny fraction of normal and increasing it after the sample is deemed safe.
Musicians have this drilled into them because it involves their daily work, but this is good advice for everyone. Damage to ear drums can be permanent.
I hate to guess how many kids are giving themselves tinnitus right now. It's just not possible to communicate the seriousness of long term problems to kids, they have no context for what long term really means yet.
They are pricey, but such a good investment. Way better than anything else I've tried, more comfortable for extended periods of use and most importantly they attenuate the sound fairly evenly across the spectrum.
My only advice is to get the string attachment option, so that you can't accidentally lose one of them!
I ride a motorcycle and needed something to make sure I don't lose my hearing from the wind noise/exhaust noise (it's stock, but still 85 dB when the throttle is open).
They are also great for concerts and live music events where the speakers are generally cranked up to 90 - 95 dB.
I got the 27 dB version, and it allows me to hear what people are saying above the the music but really cuts out the painful parts.
They are not cheap, but I already have tinnitus, so I want to make sure it doesn't get worse.
It was finally fixed a couple updates ago, I think around when they introduced the health feature to track whether you've been listening to music too loudly. Go figure. It had been getting frustrating enough that I was ready to write a blogpost wondering how much cumulative hearing damage had occurred across the iPhone userbase as a result of that bug.
I once had someone leave me a message on my desk phone referring to one of these comments verbosely, and I happened to be listening to my messages on speakerphone as the day was almost over and we were all doing our little ritual tasks before we walked out the doors for the evening. So, this comment starts being read and all my neighbors are packing up their lunchboxes or tidying papers on desks, etc. As the message went on, I could hear the silence enveloping me, because of course it was wildly heinous, and I just froze up and let it play out. It wasn't that I couldn't have jumped over there and hung up the phone but it was so casual that it just caught me off guard that someone would read that awful crap I wrote right into my voicemail! I remember the end being sorta like "anyhow, that's not a very good practice, so don't write them like that anymore". I don't really even remember exactly what happened next other than leaving with my tail between my legs. I don't think anybody mentioned it to me. I guess it seemed worse in the moment of it.
This was well over 20 years ago now, I was basically brand new to everything. That was a turning point, thankfully enough.
Reading open source has exposed me to a LOT of different commenting practices. I don't really think about it often enough, but the human on other side is always the most important consideration.
Yes, I have Crohn's and I do not like to take the meds or listen to the doctors. This is NOT AT ALL SOMETHING I RECOMMEND, PLEASE DO NOT ATTEMPT IT.
Crohn's is an auto-immune disease and the main class of drugs that is used to treat Crohn's like mine (long term) are called TNF inhibitors or TNF blockers.
TNF alpha triggers the production of several immune system molecules, including interleukin-1 and interleukin-6. I realized I can track this with basic inflammatory marker test, I also realized that I could use diet to impact my markers. So instead of taking what is referred to as a Biologic e.g.: Adalimumab, Certolizumab etc... I started using NIO to try and get the same effect.
I got a pill making machine, and learned how to make supplements but they were not working well enough so I knew I needed something stronger. Then I found this article: https://pubmed.ncbi.nlm.nih.gov/32311496/ I think it was on HN but I do not remember for sure. I order some modafinil and worked it into my mixture.
I do not manually create my mixtures because I do not want to know which version I am on, I want my symptoms to go away and that should be the trigger to tell me if its working. So I have a 14 vile setup with an audrino all wired into my press and based on my food diary (e.g.: nutrient intake) it decides how much of what should go into a run. e.g.: how much burdok, tumeric, serrapeptase etc...
I got something wrong and ended up adding far too much to a run of pills, I didn't realize this until i started ti see floaters in my eye and I checked to see how much moda was left and it was far less than should have been left.
Then i did some reading and a side effect of taking too much moda can be detached retnas, since I have all the symptoms: Floaters, stars and peripheral flashes I am assuming that based on the timing I now have detached retnas, I also found my mistake and essentially no matter where my markers were I was getting about 600mg of moda per day. Which is far more than should be taken. This was for about a 1 month period.
I have fixed the issue now and I have a much more sophisticated pipeline but I will have to get this fixed.
NOTE: I am not a doctor, I have no college education or anything like that. I just like bio-hacking and decided to pursue my moonshot during the pandemic. I can explain more or provide pics and vids to explain further if you like, email in profile.
I am currently writing up a 100% independent non peer reviewed case study to document everything I have done and the results.
Since you seem to be into experimental treatment, have you ever tried helminthic treatment?
I was running an outpatient program for alternative therapies before I knew that you cant just do that, you need insurance and stuff. So now I am making my own Medicare/Medicaid and hope to bring all of my work into a single payer system. There is no way I can pull this off, my only hope is to attract the attention of some really smart people that will tell me why and how I am a moron and how to fix it, lol.
I would love to talk about my work with someone but i'm kind of still scared because its not in a state that is 100% ready for end users and I know everyone is just going to laugh at me, lol. Hell I laugh at me. But I worked at goop and i know more than everyone there so i'm kind of like ... fuck it. Just code / Fierce Nerd blah blah <insert-some-rationalization-here>.
Right now I am having fun exploring the world of BHM HMS modules, its far less regulated than I thought it would be which might not be a good thing, but we will see. I am going to do a "Show HN" soon but I want to publish feedback from my active patients and providers first.
In preparation for my big launch I needed to test the "do they care" theory so I literally did 2 press releases.
1 targeted directly at the D.C. area and one nationally, every contact they have made with me has been a positive interaction.
https://www.kpvi.com/news/national_news/award-winning-progra...
I paid for someone to handle this for me, really embarrassed by the title but in their defense I have won 7 health hackathons; much of that work inspired what I am doing here.
Ideally I get to a point where my systems are so much better than theres that I can promote services from .dev to .gov, I really have not thought that far ahead but I would love to discuss.
https://trademarks.justia.com/890/00/medicare-89000008.html
Just because you haven't run into a trademark issue yet doesn't mean that you will not in the future. And I don't think I'd want to be fighting the US Army lawyers for the naming rights.
I love your initiative, but you may want to look into the naming issue a bit further (since this is what trademarks are explicitly designed for, to prevent confusion about one product/service doing the same thing under the same name).
This i why I use medicare.dev and medicaid.dev and NEVER just use the naked terms.
This is also what I have seen everywhere else, can you point me in the right direction on this? I really appreciate the input.
I wouldn't be comfortable without some sort of closed loop to be reasonably confident it was dispensing what it claims. Also helps to have the active ingredient pre-diluted so you are mechanically capped at a certain volume.
I do not I do not even know who I would send it to honestly. I am obsessed with this work now which is why I am expanding my provider network to other countries.
I found that things I think are "experimental" are much more common overseas probably due to a lack of regulatory controls but the result is that there are really smart people with a plethora of knowledge about these things as where my western doctors were not that knowledgeable or willing to really listen.
If you have any suggestions it would be awesome if you could email me.
Worst case you could have physical guardrails such as "can't take more than x mg per week" in the form of only supplying a certain amount of raw materials and topping off intermittently. If you run out you find out sooner instead of a month later.
Double blind testing, in the "now unable to see in both eyes" sense?
(For the "era of higher risk tolerance", the good old "Ignition!" by John D Clarke is a fun read from the era when the official US rocket fuels programme consisted of just lighting stuff on fire and seeing what happened)
The CEO/Founder at my old job used to kind of check-in on me from time to time via slack, she thought my work was cool which kind of helped me keep going once I was no longer at the company.
In that case hurting yourself trying to find sth. cheaper is not worth it, because: a) it is bad for you b) it doesn't help others either, since even if your special cocktail ends up working for you it will most likely not work for others.
I would focus on making tnf-a blockers cheaper, probably by circumventing or straight out ignoring the patents. This stuff is not rocket science anymore.
Have you researched the prices in other countries? Looks like in Europe its below 2k€ per month but more around 20k in the us? Whats the price in India?
OK, lets start with just the official stuff that they actually admit.
HUMIRA can cause serious side effects including hepatitis B infection in carriers of the virus, allergic reactions, nervous system problems, blood problems, heart failure, certain immune reactions including a lupus-like syndrome, liver problems, and new or worsening psoriasis.
Do you see a trend here? Auto-immune treatment causes more auto-iummune diseases. Thats real sus to me.
> I would focus on making tnf-a blockers cheaper, probably by circumventing or straight out ignoring the patents. This stuff is not rocket science anymore.
You are actually trained at this and I am not but I do not understand why youy would focus on alpha when beta is far more cytotoxic. Like I said, I don't have your training but that seems odd given the rate of colo rectal cancer in Crohn's patients.
Given that the entire family of drugs refers to Cytokines which is cell-death it seems a bit asinine to focus on alpha.
> Have you researched the prices in other countries? Looks like in Europe its below 2k€ per month but more around 20k in the us? Whats the price in India?
India does not sell the name brand I am familiar with; they have Zydus' Exemptia and its around $4,500 USD.
> What do you mean by scale?
I mean scale. Given that N patients have Crohn's and wish to treat themselves with Z. If Z is a finite resource what are the obstacles to Z being produced and distributed at a "scale" great enough to reach each patient, for life.
> it doesn't help others either, since even if your special cocktail ends up working for you it will most likely not work for others.
Please provide some form of empirical evidence to support this position, I was saying in private because I have actual clinical outcomes that i can report form myself and a number of others, but doing so publicly is not ethical or legal; HIPPA and all.
Can you expand a bit more on what you meant when you said you were a researcher? Possibly point me to a white paper or jupiter notebook, anything so that I may get a better understanding of your work.
I do not even know how to begin to address the reductive nature of pharma disco and production "not being rocket science" other than to state the obvious, yes it's not rocket science its bio chem.
I am sure i'm just missing something given that you work professionally in the field.
FYI: It has nothing to do w/ the price at all, even on the worst medical/medicare plan humera is only 250 for 2 viles and it was less, now it just has the extra lux tax.
https://www.google.com/search?q=DDP+drug+discovery+pipeline&...
Back in the ancient days, my friends and I would meet every Saturday and go to an Internet cafe for a few hours of playing multiplayer games over LAN. Mostly StarCraft: Brood War, with a mix of Unreal Tournament and Quake 3 Arena. During the week, we'd all play these games alone, in single player, figuring out new tricks to unleash on each other the next time we met.
One of these weeks, I've learned how to properly play Terrans against the Zerg, and was about to demonstrate my knowledge by steamrolling my friend with an army of Marines and Medics[0]. In that game, my friend went for his usual tactic of harassing me with Mutalisks[1] - an effective technique, as long as he avoided the main body of my army. Well, on that day, he wasn't careful enough.
At one point, he accidentally flew his entire (by that time pretty big, I think 24+) swarm of Mutalisks straight into my M&M army, which was just staging to launch an attack. My units took about 5 whole seconds to destroy most of his force - but the overlapping audio of dying Mutalisks pretty much saturated my headphones with high-amplitude noise. This was so unexpected that I wasn't able to comprehend what's going on around me (both in-game and in real life) for good 30 seconds, my vision blurred and my head was spinning.
Having wasted his entire army, he lost that match. But I keep thinking that this could have been a viable stratagem. If he sacrificed half of his army like this to break my focus, he could've crippled me with the other half. And ever since that day, I kept my headphones at half the volume.
--
[0] - M&Ms, aka "bio", was the usual Terran army composition against Zerg players in Brood War. Zerg armies consist mostly of weak but cheap units - compensating individually low DPS and health with quick, mass production. Terran Marines are also cheap and low DPS, but in 2:1 ratio with Medics, they're healed faster than Zerg units can kill them, so a big ball of M&Ms is unstoppable to an inexperienced Zerg player.
[1] - Weak, cheap, annoyingly fast flying units. Perfect for distraction, but their low DPS makes them completely useless in a straight fight against Terran "bio" army.
The sonic weapon, while accidental, feels similar to tactics used to disrupt concentration and logical thinking. E.g. taunting, trolling, cheese strategies, or your opponent getting tilted from something you didn't intend to annoy them with.
Often think of how keeping a cool head is incredibly important in games like this, specifically for the pros. IdrA comes to mind as a technically gifted player who was often his own worst enemy due to his temper. He never did crack into the top of the pro scene (hard to do as an American in general) but felt like he really held himself back.
Yes, we did plenty of that.
Between Internet cafe days and high-school SCBW matches, I think I've got a dozen people to fall for the simple trick of writing "[a bunch of spaces to manually center the message] nuclear launch detected" on chat[0]. Most of the times it only caused a laugh from everyone, but once I actually won a game this way.
It was the late phase of a match, myself and my opponent were in a sort of stalemate - his army held a strategic position; we both knew it, so he just held position, and there was no way I could get through[1]. Not sure how to solve this tactical riddle, I just pressed ENTER and sent the " nuclear launch detected" message. It caught him off-guard, and in a moment of frantic confusion, he decided to move his army elsewhere. Of course, there was no nuke, but I suddenly had an opening I could exploit and win the match.
EDIT: I miss the tactical depth of SC:BW. I haven't seen any other game that came close. Not even StarCraft 2. In particular, all the cheese strategies we tried against each other. Most of cheesing happened early-game, but I was particularly fond of creative abuse of Terran Science Vessels in mid-to-late game...
--
[0] - For non-SC players: Terrans have tactical nukes in their arsenal. Launching one causes a warning message (and audio) to appear for every player, which gives the opponent a few seconds to try and figure out where the nuke will land, and either kill the unit that's laser-guiding it in, or evacuate from the area. People who played SC a lot develop a habitual reaction to this message, overriding whatever they were doing and thinking for a moment.
[1] - I unfortunately don't remember the details about the tactical situation and composition of armies. All I remember is that I was playing Terran, like I almost always did.
Somewhere in the range of 10-15 years ago I played Guild Wars somewhat competitively. I was in one of the top-20 PvP guilds, and most of the top PvP guilds were pretty friendly with each other. Very rarely, we'd be good enough friends with an enemy guild that we would know their Teamspeak or Ventrilo server credentials.
So one day, we're doing our nightly battles like always and we get matched up against one of our rival / best friend guilds. A couple minutes into the fight, one of our Mesmers says
"Hey uh guys. So.... This might be a bit much. But I know their Voice Chat login. I could spam their server right now."
"Do it."
So we all hear the "user left" voice thing, 20 seconds later, "user joined". And apparently what he did was open the text-to-speech tool, meant for users without microphones, and entered "!@#$%^&*()_" except copy pasted a thousand times.
Which means the other guild heard from the robotic text-to-speech: "user joined. User Ha Ha Got U says Exclamation Mark, At Symbol, Pound Sign, Dollar......."
They're talking trash about how could we sink so low in the global chat in-game when suddenly we hear "user joined. User Ha Ha Got U Back says Exclamation Mark, At Symbol, Pound Sign, Dollar......."
There was a way to disable the text-to-speech on your client, but none of us knew that at the time. The text-to-speech rambling continued the entire night on both our servers and neither guild was able to speak. Both guilds thought it was hilarious but agreed never again.
Skin/eyes: experimenting with high-brightness LEDs. These can become pretty hot in no-time. I was trying to do my own LED driver (regulating a PWM signal from voltage/current sensing), on an LED without heatsink. Because of buggy code, it started to burn my table, and by reflex I tried to pull it up with my hand....
Not to mention the countless times a white spot remained in my vision for hours, after looking at such bright LEDs (buggy PWM signal regulation algorithm that kept going from dim to super bright randomly).
Ears: every time I write a driver for an amplifier/DAC with headphones output. No matter how many precautions I take. It is going to happen anyway (wrong register configuration, the default volume was too loud, etc.).
Also while listening to mic recordings done with a buggy/incomplete software.
Implemented a basic HTTP server that'd dispatch commands with a simple access control and permission system, messed up the rate limiting, big mistake.
PS: I don't have a dog.
We were commissioning a rather large food processing facility and had already verified that our PLC->Motor Starter wiring was all valid, but at some point the client decided they're ready to run a production line without testing the Motor Starter -> Motor wiring (bump testing the motors).
Normally you'd have people away from the equipment, proper lockout, people with radios verifying operation, all that jazz, but the client decided to go around us and just start turning things on.
Well when they went to turn on motor in section A, a drag in section B started due to some mistakes by the electricians. Section B's motor just happened to be straddled by a welder who was standing over it to do some work on an upper walkway when the thing fired up beneath him. Understandably he was pissed.
I've never had an injury on the job (thank god) in the 9 years I've been doing this, but there's been a handful of close calls. 100% of the time its because people skip safety procedures and think it'll be fine.
The client never did learn their lesson I'm guessing. We went home for the weekend, "Days since last work stopping injury" was reset when we returned Monday. Not sure what happened there.
What does CoreAudio do if your floating point audio buffer is filled with random numbers? That's right, it plays random noise at the maximum possible level, bypassing the system volume setting.
Why ear infection? I have no idea, but my GP explained that it's quite possible even if the eardrum doesn't get damaged. Which in my case thankfully it didn't.
but why bypassing the system volume? It does not make sense to me.
I guess safe volume control should ideally limit the output energy. Energy is proportional to square (or so) of frequency, so ideally it would take that into account as well. That rules out simply hard-clamping sample values because that creates high frequency / energy distortions. Not trivial, especially if low latency is also required.
So random FP noise clipped is still random FP noise at maximum level.
And if the controller is not properly initialized, the stick will slam left and back, hitting the leg of the guy in the pilot seat. For men, it can be much worse...
Another bench had a real aircraft gun mounted on a turret that is also controlled by software. No ammunition of course, but it is still a big metal pipe swinging around at great speed, thankfully, that one was fenced because that's the kind of thing that can easily break bones, maybe even kill you on a bad hit.
When the laptop the debugger was running turned off, it also stopped the code from running on the microcontroller, leaving the heater on without adding any new controls.
It was a good learning to make sure there's a watch dog circuit, and that the microcontroller is much less trustworthy than the fpga
However, I've read about the same thing happening to a couple guys testing a tank turret rotation controller. Controller is paused at a breakpoint, but a hardware counter is still accepting error pulses. Start running again and the error built up enough to command a full speed slew, sending the engineer who was sitting on the turret slamming into the wall, breaking a few bones.
Yes.
The bug was a feedback loop in the volume control code that somehow ramped the volume up without any way to stop it. After that I always tested with a physical volume control later in the audio chain, with the volume set to a medium level.
e.g.
- could cause this one page to fail to display - be ready to roll back, open the page asap once deployed
- could bring down the entire website - be ready to roll back, maybe try running this during off hours
- could delete the entire database - be ready with a backup to restore, maybe make sure your whole team is oncall at the time
- could cause ear damage - maybe play it with the headphones sitting next to you first
Examples could be spilling a poorly placed can of paint all over the carpet, or having a nearly unobtainable fastener fall somewhere inaccessible (or where it can do damage).
I was taking a class in software security and had a homework assignment to demonstrate a buffer overflow. For extra credit, we could have our exploit play music without invoking exec. My approach to this was fairly straightforward. Using ffmpeg I converted the audio to raw 16bit little-endian PCM. Then I appended this data to the end of my exploit. When my exploit runs, it sets some ioctls on /dev/audio then starts copying the data from the end of the file to /dev/audio causing sound to play.
As you might have guessed by reading the article, I had an off-by-one error, causing the music data to be misalligned and loud static to play. Fortunately, my system volume was not particularly high, and I was happy to even get sound to play. I never figured out where I made an off-by-one error, since I had just assumed that the static was caused by an alignment issue that could be "fixed" by adding a 0 byte to the start of the audio data.
I drilled down on the offending database record, looking in the demographic data to see if something was wrong. After staring at it for a few moments, I realized that the demographic data looked... familiar. And then it hit me: my own enrollment record from that day had been left in an inconsistent state in the database that my program was pulling the study data from, due to the failure to collect a blood sample. This resulted in my program crashing on the inconsistent data. So I had to add a special case to my program to handle my own failed study enrollment from earlier that same day.
I always keep the volume low enough that a full-amplitude noise wouldn't be anywhere near physically painful to listen to, but then again most of the stuff I listen to is ultra-compressed already...
Of course, the actual bug is that the audio is in units of samples, which are only 1 byte in the case of mono 8-bit format, so treating the file as being 8bps mono when it could be 16bps mono, 8bps stereo (far more subtle difference in the case of byte misalignment), 16bps stereo, or any of a number of other formats is always going to lead to cases where this could occur.
It's tethered to a test-stand now.
My favourite near-miss was the result of a dumb EE experiment, not really code: I had built an 8kV surge generator to test against IEC 61000-4-5, and needed to test the generator itself. We spent an afternoon finding interesting components to blow up, at first under a shield, but the good ones would just make a satisfying snap or pop - not too exciting from a kinetic perspective. Then, I noticed a DVD... The surge through the foil in the DVD made one of the loudest bangs I've ever heard - easily louder than a gunshot - the foil vapourised and sent plastic shards all over the office.
The surge generator itself was a glorious hack; it used a neon sign transformer to generate the HV, and the main switch was a trigatron I made from a couple doorknobs from a home recyclers in the same industrial park.
There is usually an aptitude test for machinists. Not everybody can do it fast enough safely.
I'm a software developer who has had occasion to program a CNC mill and lathe over the past few years. The relative banality and physically harmless nature of software bugs made in my normal job made the stakes seem so much higher by contrast, when touching machine tools. I partly credit this "culture shock" in helping to keep me safe and the equipment undamaged - apart from a trio of snapped endmills on Day 1 (F100 instead of F10).
I can definitely echo that the ability to work safely, quickly, is one thing that sets the pros apart. I'm glad I have the luxury of time that light production affords.
The most consistently hurting project was a plotter that printed images with milk (don't ask why), it used a heating part to reveal the drawing. When a paper jam creates a fire you sure want to be near during a print job ! Plus burning my fingers a few times (lost some parts of my fingerprint on one of my thumbs).
One example that stands out is a case where we had a heating element to seal plastic bags. It turns out those heating elements get ridiculously hot and only need to touch the bag for a fraction of a second. Naïve me felt that 3-4 seconds was a "reasonable" amount of time for a first attempt...it caught on fire.
The story is we were testing some autonomous code I wrote and it stopped moving because it was hanging waiting for on some sensor data. Without remembering to disable the robot first, I walked over to it and found the sensor wasn’t plugged in properly. Plugging it in, the code started running again and proceeded to drive up and on to me...
Nowadays that I work with industrial robot arms (specifically ones with 24,000 RPMs of death on the end of them) I am very aware of how important safety practices are knowing how easy it is to slip up.
I had a row of dots tattooed on the ball of my thumb for a year or two afterward.
After running the code, the CPU started making a super loud high frequency noise. The code was a super tight infinite loop, co CTRL-C did not work to make it stop. Hell, even power button of the laptop didn't react! Everything was completely unresponsive.
It was middle of night and my laptop was about to wake the whole neighborhood, and the only solution I found quickly was to remove the laptop battery.
Luckily I had a removable battery in my laptop back then!
Turns out debugging audio code and wearing headphones is a bad idea when your code sometimes randomly generates sample value changes from -1.0 to 1.0 :o
Incomprehensible shrieking. Later that year, someone posted about the thing that would become the Internet phenomenon called 'Anonymous'. I am certain that idea was birthed from the wailing portal of hell I summoned that day.
In one of the labs, we were doing audio processing to filter out noise from the audio and listening on the headset. Towards the end of the session, we were messing up with the code to see what else is possible.
Anyways, I accidentally set the gain so high somewhere, while wearing the headphones still and played a tone. I almost got deaf. It still gives me chills to think about it.
The fields the diagram in the article marks as “big endian” are ASCII text— four-byte strings with specific content (“RIFF” for the first ChunkID, “WAVE” for the Format, etc.). If you wanted to treat those as integers in your code, you’d need to treat them as big-endian so their byte order doesn’t get reversed, but they’re really four-byte sequences, not numbers.
We had a feature where user can scan whole books just by turning pages and save them as audiobooks or txt with "audio tags". Basically the device records you saying the title saves it as metadata, and later you can browse the list of books listening to yourself saying their titles.
Sadly our hardware had mic near power lines and there was a lot of interference and the volume was pretty low, it was barely usable. So one of my tasks was to boost the volume and remove noise. I tried to write something to this effect, tested a few libraries, and eventually settled on just running sox in the background with several plugins and noise sample collected on our device under different loads. Works like a charm.
The best thing - a few years later I google how the devices are doing on the market and I've found a podcast by a blind guy reviewing it, and he mentioned how good the audio tag feature is :) It wasn't the best paying job but no B2B job gives you this kind of feedback.
iPhone has an option to enable this protection for all headsets, but it doesn't work properly. For example, when answering a FaceTime Audio call with Bose SoundSport, the "call connected" tone often plays at max volume and is staticky. This is with the latest firmware and iOS.
macOS has no over-loudness protection.
Bose's expensive noise-cancelling headphones do complex audio processing but fail to protect users from over-loudness. I think the company has lost its ability to focus on user needs. Over the last 10 years, only their noise-cancelling function has gotten better, but other aspects of their headphones have gotten worse. Features I want in my next headset:
- active noise cancelling
- loudness protection
- swappable battery
- physical buttons
- mic windguard
- stowable boom mic so I can talk quietly on a call and still be heard
- an option to automatically pause music when I take off the headphones and resume when I put them on
- an option to automatically enable or increase noise cancelling when the environment becomes noisy and disable it again when in a quiet space
- Automatically detect me speaking and pipe my voice through the headset so it feels natural, even when not on a call.
- Work properly in extremely noisy environments. When I wear my Bose QC25 noise-cancelling headphones while riding the BART subway in San Francisco, the headphones emit painful crackling sounds when the train noise is very loud. I don't expect the headphones to block extremely loud sounds. They should not make the noise worse. Bose's headquarters is in downtown SF. I expect some of the firmware engineers ride BART every day. Does anyone know why they haven't fixed this in 7 years?
When seeing the graphic of the wav file header I immediately recognized the same graphic I used in that paper.
Sometimes it's funny how memory works :)
Also interesting for how long content can stick around.
Still, this is how we learn. We make some ridiculously bad choices and we hope to learn from those.
I guess what I am saying is: if you are looking at past work and feeling bad/embarrased, likely you have gotten better.
Decades ago I had a Original Commodore PET 2001. It could only display white text/characters on a black screen. Foolish me having read a Byte magazine describing how a black & white colour wheel could make you see colours see: https://archive.org/details/byte-magazine-1977-02/page/n45/m... so I tried to get my PET colour to display colours using this method.
Trying different timings, all the while staring at the screen. I did this all day looking at flashing lights all the time. Afterwards it turns out I could not see properly for hours.
We have a project that tries reify live objects into human readable form. Final representation is so complicated with lot of types and the initial representation is less complicated.
In order to make it readable, if there is any common or similar data nodes, we have to compare and try to combine them i.e. find places that can be made into methods and find the relevant arguments for all the calls (kind of).
Initial implementation did the transformation into the final form first, and then started the comparison. So, the comparison have to deal with all the different combinations of the types we have in final representation now, which made the whole thing so complex and has been maintained by generation of engineers that nobody had clear idea how it was working.
Then, I read about hashmap implementation later (yep, I am that dumb) and it was a revelation. So, we did following things:
1. We created a hash for skeleton that has to remain the same through all the set of comparisons and transformation of the "common nodes", (it can be considered as something similar to methods or arguments) and doing the comparison for nodes with matching skeletal hashes and
2. created a separate layer that does the comparison and creating common nodes on initial primitive form and then doing the transformation as the second layer (so you don't have to deal with all types in final representation) and
3. Don't type. Yes. Data is simplest abstraction and if your logic can made into data or some properties, please do yourself a favor and make them so. We found lot of places, where weird class hierarchies can be converted into data properties.
That did not just speed up the process, but resulted in much more readable and understandable abstractions and code. I do not know, if this is widely useful but it helped in one project. There is no silver bullet, but types were actual problem for us and so we solved it this way.
Edit : new lines and some typos
I've worked on embedded software for solar powered race cars, rockets and spacecraft, self driving cars, and most recently UAVs and corresponding high power motorized ground systems.
You gotta take safety procedures seriously when testing out electro-mechanical systems strong enough to injure you. One memorable bug discovered in testing in the last few years I labeled "ninja assassin mode"...
Context: building an avionics test set with an integrated loads and measurements capability and complex relay switching network to allow different things to be switched to different loads and voltage drops measured. During software/hardware integration testing (first time that the hardware had been driven full speed) we found a bug in the CPLD that resulted in 28V being sunk into a 2A resistive load over a couple of PCB traces specified for 10mA; resulting in a large amount of magic smoke being emitted.
Many years ago I was working on a mobile outdoor hobby robotics project (RoboMagellan) and had two glitches in parallel. One was the software controlling the robot, the other was in a microcontroller in the kill switch mechanism.
The main computer was reset by a brown out which also caused the uC listening for inputs from the radio used as the "enable" switch to lock up (with the motors enabled) and I hadn't yet learned about hardware watchdog timers.
Drove straight into a river.
this is extra funny if you work in automotive functional safety.
the collection of anecdotes in this thread makes me wonder if an intro to functional safety could be standard curriculum.
the approach of Nancy Leveson is not only very accessible but also very accessible, freely so:
As for the harm, well ... that code led to a marriage which catastrophically failed. Lesson learned: keep code and emotions away from each other.
Silence is when the value doesn't change, no matter what it is. Noise is when the values change, the more they change - the louder the sound.
So a wav file filled with "ffff" is just as silent as one filled with "0000".
And a wav file filled with repeated "00003333" is louder than one filled with repeated "eeeeffff".
> Look at an audio file's waveform before playing it at max volume.
That’s always good advice.
Think about how many times you hit compile and there were mistakes vs. perfect code? To err is human nature, that's why it's so important to set up safety nets for ourselves when dealing with dangerous things. Wear your digital PPE :-).
One day I thought it would be a cool hack if I could rig up an Xbox controller to send movement commands. Long story short I managed to snap the bit by moving too much after a plunge cut. No safety glasses or anything; but a day or two later I did find some shrapnel from the bit embedded in a piece of foamboard I had near the machine, so that was cool...
Once, due to a logic error on my part the heater was triggered in the middle of the summer while I was out of town. The internal temp got up to well over 100°F.
I was able to have a friend come over and disconnect things for me, but I could have killed a pet, at the least, if not some more sensitive hardware.
https://en.wikipedia.org/wiki/Therac-25
TL;DR: Software race condition caused radiation doses several hundred times higher than intended, killing several patients.
...otherwise: https://en.wikipedia.org/wiki/Boeing_737_MAX
One time I was writing a little emacs lisp module to automatically reconnect me to #emacs on freenode, but it was buggy, but it was still in my .emacs at the time, so when i restarted emacs, it started running, and I didnt notice it.
fast forward a little bit, i notice the irc buffers open in my list of buffers, and lo and behold, my code was constantly disconnecting/reconnecting in #emacs and it was spamming the channel with those messages. They banned me (briefly) so it would stop.
It was just funny to see like a flood of connects/disconnects in the chat log, and people being like "whats going on" and "must be a bug in something".
There are perfectly good library functions (in python, and I assume in C) for loading a wav file into a simple array of values, and writing an array back into a new wav file... Load the data, skip the zeros, and write.
Didn't go right.
I had to work all the week after 10 hours per day just by fixing a lot of data I messed up on several clients.
Yeah, I feel I've been there.
They kill people [citation needed] due to off by one errors.
N00b.
3D printering has also led to some pinching and burning here and there. Worth it!
If you meant conceptual injury, I try not to dwell on it, but I once wrote a makefile that “clean”-ed up all the source code, source control, and the backups...just a cut and paste error, but soured my original exuberance about make. For life.
As for me... I've certainly made it so things that shouldn't be hot to the touch are hot to the touch.
A customer with a dedicated server called in one day. I knew him well, and he I. It was that kind of company and I loved it. Anyhow, he called in and said "I've been hacked!" I asked him to explain the problem and he said that his server wasn't working right and wouldn't reboot. I looked into it, and a ton of things were missing from the file system. /bin, /boot, /dev, etc. Gone. So I did a restore of the server and got it back online.
He called me up an hour or two later "I've been hacked again!" Same problem. Same solution.
An hour later he called me up, sheepish. "I think it might be ME. Every time I think it's happening every time I run this command." I managed to get him to email me the command he was running, verbatim (he was copy/pasting it into the shell) and it looked like this:
rm -rf /home/user/file; rm -rf /home/otheruser/directory; rm -rf /home/foo/thing; rm -rf / home/bar/otherthing; rm -rf /home/didyouseeit/thing3
The other harm was my own. I was budding system administrator tasked with designing and deploying dedicated servers (this is before VPSs were a thing, and way before cloud computing). I challenged myself to learn Perl because the greybeard admin (who cut his teeth on PDP-11's) was a master at it and I could benefit from his tutelage. But I didn't. Instead I got the SAM's book on Perl and started learning. Having an interest in security, I decided that I'd write a simple Intrusion Detection System for our dedicated server products.I don't have the code, but it's irrelevant. A the time one of the bigger problems was servers getting rooted due to various exploits. The attacker would rewrite /bin/ls with their own version that hid their executables. The solution (obviously right?) is to look at the md5sum of /bin/ls, and if it changes, the server must be rooted, right? So I wrote code that would shut down sshd, close the port, and display a message via `wall` that said something very much like:
System Modification Detected! Shutting down system and alerting security staff. YOU HAVE BEEN CAUGHT! BUH BYE!
I was very pleased with myself. I couldn't understand why the aforementioned greybeard didn't revel in my brilliance. sigh I deployed the script on a cron job and felt very satisfied with my good work. Until a call came in. "Yeah, I ran a yum update, got some message about being caught, and now I can't get into my system."Yeah that's right. I'd hard coded the md5sum for /bin/ls and had no means of updating it. I've since forgotten Perl but I never forgot this lesson: Take everything into account. Spend less time coding and more time thinking about what you're building and how it'll affect others. Since then I've written several utilities that are/were in use at the hosting companies I work(ed) for and I saved people countless time, effort, and trouble. But it sure didn't start out that way!
Had 10+ stitches from bad tuning of a PD controller (and me not taking proper safety measures).
So the director of said IT center, seeing me how I dabbled in all kind of stuff with latest and greatest technology asks me "can you create a copy protection?". Nowadays I see this kind of question as a job on my freelancer marketplace and I always say to the potential customer "impossible, and if anyone else says otherwise are either incompetent or just want to hustle your money" but back then? my naive brain said "sure I can".
The IT center just acquired, at around 4000 USD each, a brand new line of 486 DX2 at a whooping 100 MHz which came with latest and greatest Windows 3.1 for Workgroups. Around 20 of them for all their design engineers to use ACAD at a faster pace. Serious business required serious tools. So I enter the scene with my protection. Which was a wrapper around the protected "exe" that on launch would ask for password, 3 tries and you're out. If password was provided then it would unwrap the good exe and launch it, otherwise the protection would kick in.
And oh boy, what a marvelous protection I wrote. First step - overwrite MBR with zeroes, you can guess to what goal. Second step - well, this one is a bit complex. You see back then you could directly access graphic cards DMA channel and write your own graphic driver inside your application because, well, DOS was like that. And poor Win 3.1 was no different either. And because of a physical layout that majority of board back then employed all the same you had an electrolytic capacitor near (like 2 mm only) a pin. Which said pin could go to up 25 KV if you were driving a certain pattern on your graphic card. Which would result in a shortcut between the pin and the capacitor. Which would ignite the resin that was there. Which would set your computer on fire. Third step - restart the PC.
So I am there with the director, head of designers and a bunch of other people to test my copy protection. I explain to them in what the protection consist of, and we test it. They wanted to test it on "acad.exe", so I wrap it up in my protection, delete the original and the new exe is launched. All good, password prompt, get in, Autocad is launched, they can do the work in peace. Except the director asks "and if I launch this wrapper tool separately, what happens?". "Nothing, it's just a tool and if you don't supply a parameter will simply exit". So the director does that, except he supplies a bogus parameter, by mistake, and not any parameter but ^U...you know, the combination that a Windows user will see at a command prompt when he does a mistake and presses CTRL+Z (Undo in Windows), because he pressed space and then wanted to back it off..and muscle memory for that action is CTRL+Z. And happily my tool tries to wrap around a file called ^U, but for some reason that file instead to be "not found", because I had this coded, was treated at "launch the protection". So here a little bug, launched my protection on a $4000 brand new machine. Of course MBR was zeroed instantly and then we see some stuff scrambled on the screen (protection no 2) and puff!! we're at BIOS reset. No fire!!! Why? because protection no 2 should've run for 10 seconds to allow the buildup of those 25 KV, but I was lucky because my dead ass brain introduced another bug and I was triggering the reset immediately.
I spent the next 3 days, me and the head of designers, rewriting the MBR by copy/paste via eyes and hands, using a hexeditor, by reading the MBR from another 486, and I was lucky since they all had identical configuration. That protection scared off the director, he never use it. And my ass hurt from the stick because $4000 during that time would've been both my parent income for an entire year.
My story: I physically broke an indoor bike trainer by writing a mobile app.
I was fed up with the rent-seeking subscription-based app that the vendor provided for the machine, and wanted to write a simple app to be able to change the training parameters over Bluetooth. It worked via a standard BLE fitness machine protocol, so I’ve spent a few hours creating a prototype iOS app for interacting with it via the CoreBluetooth framework, based on the free docs from Bluetooth.org.
Everything worked wonderfully, up until the point of adding a slider to the UI for changing the “hardness” parameter of the current session. You see, changing the hardness parameter adjusted an electromagnetic braking mechanism inside the machine, and the slider I’ve put on the UI was set to its “continuous” mode, which meant that it was generating a steady stream of change events while dragging, basically at the framerate of the phone (60 fps). The designers of the machine probably didn’t anticipate that someone would be flooding it with 60 “set hardness” commands per second, and the actuator doing the adjustment simply broke from the overload after a few seconds of me dragging the slider…
I’m not sure exactly which part broke, but there was a loud crack from inside, and the braking power could no longer be adjusted at all. I could have disassembled the machine, but it wasn’t even mine (it was lent to me by my brother-in-law to try it out), and was still under warranty, so I gave it back and told that it spontaneously broke :^)