j4k0bfr

I'd like to live in a world where an LLM can exhaustively verify all C++, and where porting C++ codebases is safe and easy. However I'm not fully confident we're there yet.

Plus, there are a lot of pros to C++ which aren't so easily waved aside. The breadth and duration of support makes it almost impossible to kill quickly, imo. If a magical LLM bullet shot C++ dead tomorrow, many established orgs and projects would keep it rolling. It also sits in a funny spot where you can get pretty good performance from not-great code. And it is incredibly fun to write! Reading it is... another matter ;).

Edit: I'm sure dumping piles of money into abliterated models can get you quite far. ROI and correctness are the parts I'm still sus about, however I hope to be proved wrong.

Gadzooks! I must launch my homelab into LEO, stat!! Quick <local LLM>, start me a space program!

> Surprisingly, I haven’t found a solid answer.

God, what a good pun.

I agree, organisational creep can kneecap a lot of different projects.

However it's my (mostly vibes-based) opinion that it impacts software more than most. Imo, disciplines with more stability benefit from knowing how many people are needed for specific roles, and probably don't step on each other's toes so much. Software projects often end up sharing so many interface points between devs. I can't imagine the amount of headaches a 100 strong org would generate when someone breaks CI, lol.

Coupled with the speed at which our industry changes (game engine updates, hardware evolution, new language hotness etc etc), it feels like there's no time to find the 'best' organisational strategy yet.

Ah I see. Yeah looks like it's pretty much just RCS for cars. Space landing systems are pretty well understood from the rocketry side afaik. The hard parts seem to really be around autonomous landing site selection [1][2] in novel environments. We'll have to see if the Roadster can do significant in-flight landing manoeuvrers.

[1] https://en.wikipedia.org/wiki/IM-1#Lunar_landing [2] https://en.wikipedia.org/wiki/Hakuto-R_Mission_1#Landing_att...

Unfortunately, it's impossible for us to verify what parts of the demo are 'realistic'. Did they use assisting technologies (e.g. a wire rig)? Is anything repeatable, or are the components one-and-done?

The software industry has taught me how sneaky a demo can be ;). That's without considering Tesla's history of bonkers claims and sus demos (anyone else remember the bulletproof windows?).

Edit: Removed a rhetorical question about the demo. Apparently there was a live audience, so they couldn't have just made a very tiny Roadster haha.

It's only incredible engineering once it performs in the hands of buyers. It's an incredible demo until then.

I feel like it's also crazy irresponsible to sell this deathtrap to the public, since it's pretty much guaranteed buyers will joyride this on public roads.

- The cold-gas only version will shotgun debris into onlookers, and possibly yeet anyone behind it.

- Active suction is very cool until a rock punches through your intakes.

- Lithium batteries and pressurised tanks in the same package, yippee!

Thank god it'll take them years to manufacture this thing.

Very cool stuff but all the "extra-terrestrial" stuff is complete bunk. This thing wouldn't survive Max-Q, let alone any kind of landing that isn't on a clean slab of concrete. It's a cool rich person toy, no other notes.

I'm happy to admit I don't really know what I'm talking about with this bug, however the ability to leak memory is pretty demonstrable, no? The OP's example of using a global cache with Drop seems a bit gross... but that hasn't ever stopped C devs lol (as a proud C dev myself).

I guess my take is that I'd rather assume this is exploitable in the wild until sufficient time has passed. Would be cool to see clippy pick up on this bug in older versions!

Took me a good couple minutes to wrap my head around. Man, what a nasty bug. I guess this specific use-case is rare. Time to see if any of the big libs are affected...

I'd assume that most datacenters use evaporative cooling, since it does consume water directly and is pretty cheap. Some web searches on the topic were swamped with companies trying to pitch their solutions (as if I'm in that market??) but this[1] link looks... slightly less suspicious.

Dealing with waste hot-water sounds like a PITA. Piping it straight back to the reservoir would need a dedicated pipeline, probably with insulation so you don't bake everything around it. Harnessing the excess heat on-site would be awesome, although I'm sure datacenters would already doing this as best they can to recoup electricity costs.

[1] https://www.datacenterknowledge.com/cooling/evaporative-cool...

I wouldn't be surprised if many of the motorsport software engineers you mention come from mechatronic/electronic/aero backgrounds. Don't get me wrong, I've seen an analog electronic engineer perform software wonders; 10,000+ lines of bash, custom C macro libraries, and a PHP runtime older than I am have taught me that programming can be closer to art than science. But relying on that cursed bundle of chaos felt deeply violating and unsafe lol.

Nowadays, I mentally place any engineer without production software experience into a 'research' box. Any resulting code may break the laws of physics, and should be tested as such ;).

Edit: It's also a minor crime to look down on automotive software engineering! The stakes of mass-manufacturing have forged some seriously awesome software. Top-of-mind for me is CAN support in Linux and safety-critical contributions going into ROS2.

With something safety-critical like an ECU, I'd be surprised if they left formal proof out of their software design and testing. This would make unexpected hardware behaviour much more likely imo. I guess I'd get around it by setting up automated hardware-in-the-loop simulators for testing every possible environment and input. Surely the cost would be worth it for F1 as a whole.

At a startup I worked at, we jerry-rigged Pi 5's with commercial of-the-shelf environmental sim software to achieve this. Very cost effective, lol.

I agree with your first paragraph, a majority of corporate programming jobs probably suck. However I'm not convinced that AI will reduce demand for these positions to in a major way. It will instead change the required workflow. I've got a couple of industrial revolution points I'd like to share; The Jevons Paradox addresses demand concerns. Software is now theoretically faster and cheaper. More projects are now financially viable, since total unit costs are down! The other side is the Automation Paradox, where now even more specialised knowledge is required to fix and maintain AI systems.

Your disenfranchisement is valid, however fortunately (or unfortunately?) do-nothing soulless corporate programming jobs have a good chance of sticking around, if in a changed way.

Comparing programmers to farriers is definitely strange on the surface. However I think it's quite unfair to reject the authors premise due to the ephemeral nature of some software. And I think it's downright arrogant to assume moving from horses to cars wasn't seriously challenging for his ancestor. But yeah, I would love to chat with the old man about what that transition looked like.

Also, AI adoption might look like it's moving fast for individuals, however I see many companies struggling to actually utilise it effectively. Business processes are slow moving political machines. Sure a large part of the software industry is ephemeral, indirectly providing capital value. However many jobs are still very tangible; embedded, backend web systems, networking etc etc. Instability in these systems absolutely results in tangible loss of value.

It will absolutely take decades before we figure out 'correct' AI usage at an industry scale. Heck, even frontier labs are still undecided about best practices.

P.S. ty for the article link, will read!

What, it's a good analogy for this audience. I know enough to have an opinion though. You'll never see me using a thread to locate a part. And I know taste isn't the only difference between red and blue loctite!

If you think my reply was off-base, give me a bit more than this mate.

I agree that any military on equal standing would blast the SR71++ to smithereens. But how many wars does the US fight against equals? And on the reconnaissance side, there are pros and cons to satellites. They're hard to replace and easy to track & destroy. Plus even the best space sensors lose quality due to distance.

Do I think an SR72 is a good idea? Hell no, but I don't think like the US military haha.

Agreed, I can't imagine much scientific/engineering value that NASA would get from restarting the SR-71A by itself. There's an easier way to simulate the Blackbird's flight characteristics without having to magic the damn thing back into the sky.

I reckon it's much more likely to be used as part of a training program (maybe related to the shiny new F-47?) or for destructive/non-flight testing and research.

Not a mechanical engineer here, but I reckon close to a decade would be pretty realistic for full operational restoration. Even a small amount of lost critical maintenance knowledge could cost the whole airframe.

I'd compare it to a really old codebase. Sure, our modern tech is much better. But if you need to make an old, top-secret COBOL program work as-is, you're in a pickle. Sure, we could rewrite it in Rust and make it way better, but management sees it as more cost-effective to just "turn the old one back on, it worked great!". And unlike software, it's pretty hard to comprehensively test a plane in a non-destructive way. Bolt falls off turbine while in flight, etc etc. Losing even a single SR-71A airframe would be a massive headache, methinks.

This is a bit surprising to me, considering how much AI companies love to hoard data. Especially since some of these ad companies are direct competitors!

My best guess is that these ad mechanisms are a bit rushed and/or that investor demands for profitability are fighting against company self-interest.

Edit: I guess some data will always need to be leaked for AI chat ads to be most effective. But I imagine AI companies would rather deliver the targeted ads themselves rather than letting competitors do it for them. It would be scary to see AI companies become ad companies too (instead of just hosting them).

Please educate me on what other options are viable for keeping kids off social media.

This "ban all kids" kind of take is bananas to me. It implies you either A) believe we should trust famously secure and benevolent tech companies with government ID or B) believe parents have the time or technical know-how to exhaustively monitor the internet access of kids. Even as a software engineer, I've found it insanely tiresome to try operating half-assed parental controls across devices.

Mostly vast amounts of sexism, but I also see racism, antisemitism and islamophobia waaay too much. The 'isms' tend to glom onto certain posts and go nuts. Algorithmic feeds at their finest, I guess.

You can enable viewing dead comments in your settings.

It's a bit frustrating to see this video immediately sniped while Meta continues to host some of the most insidious content on the internet.

It actually scares me that kids can read IG comment sections.

Agreed! Although I like the idea of considering each logical branch added to my programs. It kind of forces me to think through how variance is being treated in my call stack.

I've never done workload optimisation myself, but have looked into it just-in-case. It's a really interesting field and unfortunately, you need to know about both your compiler and target CPU/GPU to get the big gains. I believe most modern CPUs have registers for cache use. You have to do some guesswork to get IPC numbers, since core frequency can vary.

Increasing instructions-per-clock is all about minimising program branching (essentially 'if' statements). Because a CPU core can execute instructions faster than main memory can fetch em. It's a fun game to look at an 'if' statement and figure out how you could instead make it an arithmetic operation :).

Maximising cache hits is all about how you structure and access data. For example, if a cache entry is n bytes long, you want to ensure your struct is smaller than n bytes. Having very consistent access patterns can also help (e.g. arrays-of-structs vs structs-of-arrays).

This field is super deep, it's very fun to learn about!

Same, from Chrome on Android

That got a chuckle out of me too. When state secrecy and systematic incompetence get in bed together, a lot of things end up being 'decided' lol.

Edit: as a massive fan of industrial and engineering history, the spotty nature of good Soviet documentation does my head in!