What makes the Samson option different is that Israeli leaders have expressed the intent to take out the entire world if Israel was ever facing total annihilation.

I think that's true, functionally speaking, of basically any thermonuclear-armed state.

I don't believe the OP is at all claiming that if anyone tried to enact sanctions, arms embargoes, ICC warrants against Israel, or otherwise interfere with the genocide, Israel would immediately *nuke the world. It specifically claims Israel would respond in this way "if cornered". In this context, I interpret "cornered" as in backed into a corner with no way out, by an aggressive party who seeks Israels destruction.

Read the second paragraph again. OP is claiming that Western leaders are not sanctioning Israel in the fairly mild ways described because they're afraid of nuclear war.

I do think that without Western military assistance (and more to the point deterrence), Israel with its current course of conduct might be destroyed by its neighbors. But that and "stay the course" aren't the only two options. I actually think that it would be way safer, in terms of global nuclear security, if Western countries forcibly stopped the genocide Israel is conducting. As it is, that scenario where Israel is getting overrun by regional enemies and throwing nukes (at them or at other targets) sounds not too unlikely as years go by and things change, with everyone remembering what they did. And so I interpreted OP as saying that if someone tried for the enforced peace agreement, or the war crimes trials, nukes.

I do think that fear of Israel getting overrun is the source of some of that unwavering military and deterrence assistance that keeps them alive and safe to do whatever they want. I don't think it is what is stopping Western leaders from punishing Israel for their current genocide. I think they just don't want to (or don't have the political will embedded in their systems that it would take to get it done), honestly.

Here's the pinout for the webcam component: https://github.com/FrameworkComputer/Framework-Laptop-13/tree/main/Webcam

Unfortunately it isn't really clear whether the switch positions are in the pinout because it's the mainboard's job to implement shutting off the camera when it's off, or just as information with the webcam module responsible for shutting it off in hardware. I have no idea which it is, but it wouldn't be super-hard for someone capable with EE to take off the bezel and fool around with it and see which it is (or just pay $19 for the magic of buying two of them, if you didn't want to take apart your own laptop for it.)

They say they provide full schematics on demand to repair shops (https://knowledgebase.frame.work/availability-of-schematics-and-boardviews-BJMZ6EAu). I'm not sure why they don't want to just post them publicly, so in that sense you might be right, but they also don't seem like they are trying to keep them or the interface details of the webcam module fully top secret either.

They do seem like they publish enough information that someone could figure out the answer if they wanted to. (People in the forums have fooled around with them and seem to be convinced that they are actually hardware switches: https://community.frame.work/t/how-do-the-camera-and-microphone-switches-work/4271 IDK whether that's accurate, but that's what the forum people think.)

No idea why you're trying to lecture me from this position of authority about taking apart PCBs and whatnot. Anyway, that's how it works, hope this is helpful for you.

I sort of suspect that the wiring is in a diagram somewhere. I could be wrong, but that would be my guess. It's not in a PCB, that's up in the bezel where it's just wires and stuff.

!experimentalfilm@sh.itjust.works

The pay is closer to $43k.

Oh, well in that case

I thought I had it worked out, how to sort of strike a balance so I can keep my focus intact and let it be helpful without wasting time constantly correcting its stuff or shying away from actually paying attention to the code. But I think my strategy of "let the LLM generate a bunch of vomit to get things started and then take on the correct and augmentation from a human standpoint" has let the overall designs at a high level get a lot sloppier than they used to be.

Yeah, you might be right, it might be time to just set the stuff aside except for very specialized uses.

IDK, I just popped open a project from 10 years ago and it's perfectly clean, it's actually better than some of my modern code because it's not LLM-ified to save time.

I think it has a lot more to do with whether it was made in that "kind of crappy IDK what I'm doing" phase of programming. Some of your old stuff is going to be in that category sure. As long as you're out of that, however long it took you to get there or however far away it was in time, your code should be good.

Yeah, that sounds about right lol. All my python projects for years were basically writing C in python. It actually took me all the way up until I got to look at the code ChatGPT likes to generate that I learned idiomatic python. My first database project was based on the Unix philosophy, where everything was strings (no ID keys, no normalization), because Unix is good.

The client wasn't happy when they looked at the DB code lmao. Whatever, it worked, they still paid us and I didn't do it again.

Am I the only one who likes looking at my old code? Generally I feel like it's alright.

Usually the first project when I'm learning how to use some new language or environment is super-shitty. I can tell it's very bad, usually I don't like interacting with it if I have to make changes, but it's still not overly painful. It's just bad code. And that one exception aside I generally like looking at my code.

Yeah. I have no idea what the answer is, just describing the nature of the issue. I come from the days when you would maybe import like one library to do something special like .png reading or something, and you basically did all the rest yourself. The way programming gets done today is wild to me.

I sort of have a suspicion that there is some mathematical proof that, as soon as it becomes quick and easy to import an arbitrary number of dependencies into your project along with their dependencies, the size of the average project's dependencies starts to follow an exponential growth curve increasing every year, without limit.

I notice that this stuff didn't happen with package managers + autoconf/automake. It was only once it became super-trivial to do from the programmer side, that the growth curve started. I've literally had trivial projects pull in thousands of dependencies recursively, because it's easier to do that than to take literally one hour implementing a little modified-file watcher function or something.

I feel like this is kind of the amateur-hour stuff. It's certainly dangerous, but in comparison to a lot of state-actor activities (or even committed-amateur activities), this kind of supply-chain attack is pretty blatant and easy to spot. Which doesn't mean it's easy to spot -- I just mean would be trivial to volunteer and contribute some minimal fixes and enhancements to some open source project, and then at one point smuggle in a zero-day that will basically never be detected unless someone detects the intrusion itself and then works backwards from there with a ton of time to spend on it.

If you've ever looked at the obfuscated C contest it should be obvious that this kind of thing can be made completely invisible if you know what you're doing. Some of the interactions and language features that lead to problems are basically impossible for a casual viewer to see, even if they're paying attention, and the attack surface is massive and the amount of attention that goes into checking it for weird subtle vulnerabilities is minuscule.