swells34

I'm very confused about your comment; putting Trump in office is the nation-scale version of choosing to have brain damage. Why would any intelligent person think anything good or efficient would come out of that?

I wouldn't take this line of thinking too much to heart. At some point, a piece of technology is too complex for a person to parse what it means without sufficient background in this space. The "buzzwords" simply aren't buzzwords; you are using real words that accurately describe the project. People look at them, and either don't have sufficient knowledge to parse them in context, or are used to seeing them co-opted for use in low-effort marketing. I have some experience in this space (not a whole lot), and I was able to understand.

I like where you are going with the graphics in the readme; I'd spend some effort on creating "intended usecase" scenarios, scenarios that highlight situations where the project is the perfect fit. Using a few of these to highlight very different applications give people a good mental map of where this project would fit well for them.

"John is looking for a way to provide access to an internal tool to work-from-home colleagues. This isn't simple to do because [...]. Octelium is a good fit because [...]. Here is how John would set it up: [...]"

> I doubt there is any specialised hardware on the Windows 95 machines, the specialised hardware is likely connected to something else.

Based on my experience with older government systems, this is likely an incorrect assumption. It was extremely popular in the 90s to create custom hardware that integrated directly to windows machines. I've had to reverse engineer so many drivers to upgrade old bespoke equipment to integrate with newer OSs

The focus here on "tariffs good vs tariffs bad" is missing the point. Tools can be used in a productive way or an unproductive way. I think anyone with even a basic understanding of global economics knew what the outcome would be when he started putting out blanket tariffs for no fucking reason, and the way he did it is objectively unproductive; we will live with the damage from this action for decades.

This is a good representation of my experience as well.

At the end of the day, this is because it isn't "writing code" in the sense that you or I do. It is a fancy regurgitation engine, that will output bits of stuff it's seen before that seem related to your question. LLMs are incredibly good at this, but that it also why you can never trust their output.

Isn't code review the one area you'd never want to replace the programmer in? Like, that is the most important step of the process; it's where we break down the logic and sanity check the implementation. That is expressly where AI is the weakest.

It does strike me that the purpose in attending college is the credential you get; education is a far second.

In my experience, complex tools encourage fluffy programming. You mention a generic container; if I were using C, I just wouldn't use a generic container; instead, I'd specify a few container types that handle what needs handled. If there seem to be too many types, then I immediately start thinking that I'm going down a bad architecture path, using too many, or too mixed, abstraction layers, or that I haven't broken down the problem correctly or fully.

The constraints of the tool are inherited in the program; if the constraints encourage better design, then the program will have a better design. You benefit from the language providing a path of least resistance that forces intentionality. That intentionality makes the code easier to reason about, and less likely to contain bugs.

You do pay for this by writing more boilerplate, and by occasionally having to do some dirty things with void pointers; but these will be the exception to the rule, and you'll focus on them more since they are so odd.

I used it quite a bit early on during military operations. The ability to see the timing component was key; not only would you plot the purchase locations, but you could play the timeframe of records, work out the timing so you knew the order in which they visited the locations, where they must have stopped for gas along the route. In a classic workflow, you'd then investigate the gas stations, attach them to the event with confidence intervals, pull CCTV footage, see if you can get a payment receipt, and enter all of that data back into palantir. A few days of doing this, and you can build up all a map of every aspect of the drug run; the who what when where and why. It's a fantastic organization system.

In the world of content moderation, we refer to this as constructive friction. if you make it too easy to do a thing, the quality of that thing goes down. Difficulty forces people to actually think about what they are writing, whether it is germaine and accurate. So generative AI, as you point out, removes all the friction, and you end up with bland soup.

Curious, could you not calibrate using a force sensor, then include the output as a learning parameter. This seams a naive approach, which likely means it has been tried early on with other low hanging fruit, but I'm curious what the analysis of that approach is. Is there a fundamental reason this wouldn't work?

Those three and REAMDE (which I'm currently rereading) are just fantastic. Snow Crash was very stylized; too much for some tastes, not enough for others.

I imagine the flight planning software they use was affected (so their ability to coordinate with other airport's ATC), but not their radio systems or aircraft radar (nearly all radar systems I've worked with are run on Linux, and are hardened to the Nth degree). Been out of the game for 12 years though, so things have likely changed.

I assume if you weren't running crowdstrike, you would have still had logging/alerting systems set up, no?

I've run into #3 quite often in embedded Linux projects, especially when dealing with the Jetson ecosystem where upgrading to a modern Python is a nightmare due to all the specialized hardware. Glad to see I'm not the only one who runs into this.