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.

Framework laptops have a little physical switch to turn off the camera / mic when you don’t want them.

The original SGI webcams, some of the first that ever existed, actually had a physical plastic cover that you could slide over them when you didn’t want the camera on. “No, I don’t trust your hardware any more than your software. I shouldn’t need to. Stop looking at me when I don’t want you to, and prove to me that you are not, or else I will be suspicious.” Back in those days that was sort of a universal point of view among internet people, I think…

A buddy of mine was leaning towards joining the military, and it was interacting with the recruiters and observing that they seemed miserable that changed his mind about it.

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.

Certainly possible

I’m also genuinely a little bit alarmed looking back now at my pre-LLM code and seeing the quality vs. the with-LLM code.

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 feel like in a few years when literally nothing works or is maintainable, people are going to have a resurgent realization of the importance of reliability in software design, that just throwing bodies and lines of code at the problem builds up a shaky structure that just isn’t workable anymore once it grows beyond a certain size.

We used to know that, and somehow we forgot.

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.

Yeah, exactly. If you read the Snowden leaks to learn the details of what some of their actual capabilities are (smuggling flawed keys into the DH exchange for most major web browsers for example), it makes this stuff look like kids in their basements fucking around.

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.