pharrington

These days if a program is made with Electron, I'll either just use the hosted website version (ie discord.gg), or not use the program at all. 120mb+ releases for this program isn't an argument in Electron's favor.

Assuming the power management is correctly setup, yes.

Have you heard of what ICE has been doing for the last six months? And that Trump has militarized Washington DC?

lmfao yeah I heard about this!

As others have noted, the bad thing about social credit is that any one particular institution does it - its that the social credit is mandated by unaccountable entities with lopsided amounts of power. It doesn't matter if its a government that's doing it, or a company, or a cabal of companies, or even if it was literally a single person - the undue coercion is the problem.

You literally need calculus to understand dosage response curves.

This was my first thought too, but the largest corporations are way too large any healthy society.

Without having evidence, for or against your point, I'll confidently say both that you're wrong (about the just for nerds/academics thing), and that mainstream computer use makes demanding full ownership even more important.

The formfactor is the biggest, possibly only, factor. The handheld formfactor works way better for most people than a huge (or even small) stationary brick, or even a laptop.

This doesn't stop with handheld computers. If Google will be able to get away with it on phones (which is FAR from guaranteed atm), they will do it on Chromebooks. Microsoft will do it on Windows. Apple will do it on Macs. Then the hardware manufacturers will only allow "trusted" developers via TPM.

Full ownership of all our computers must be norm again. It's fine if tech companies want to charge extra to sell walled gardens and market it as extra security. But they must sell computers and software that the buyer actually owns.

There are billions of computer users across the world, but only 100 or so technobarons who want full control over our computers. Full ownership absolutely can happen. It was the standard for a couple decades in the past, and it can be the standard again in the future.

Why is it weird? You install software on your computer. You install software from your app repository. You install software with your package manager. You install software on your server. You install software on the computers you administrate. "Sideload" was always the weird, Orwellian term.

(editted to add repository and package manager points)

Nope. Its time to have full ownership over our handheld computers.

Call the library's shutdown procedure before you dlclose. A dynamically linked library is a resource like any other. Ya gotta close it properly.

Of course, if the library doesn't probably attempt to close libraries it's responsible for during its shutdown procedure, that's another can of worms.

Yeah I think you're spot on with the compatibility issues. Obviously YMMV depending on the languages and libraries in question, but yeah there's no one size fits all solution, and writing boilerplate code is the most boring thing in software development.

That's the big thing that's warmed up to programming languages with good macro systems in the past few years (and I absolutely LOVE Zig's comptime paradigm). At the same time, I've got serious questions about the programmers who dismiss macros as overkill for their needs, but then immediately pull out the LLM.

My #1 issue with AI for programming is that while I do trust it to produce OK boilerplate code, I can also just download that boilerplate code, if I haven't already written it myself. Free software is the answer.

Creativity absolutely has not been solved. Theft, however, has been solved.

Agree, with caveat - Obey the law, unless that law is made by a tyrant!

Gotcha. Apparently Intel's marketing's gotten to me. I haven't really been keeping up with this stuff, so whenever I read about P & E cores in the past, I think I just assumed that was a thing both Intel & AMD were doing, without considering the source material too closely.

did you mean to link to https://github.com/semgrep/semgrep instead?

I'd assume both GMP and any CPU intensive game just prefer the performance cores.

You are allowed to read Cargo.toml.

You're confusing compile-time with build-time. And build time code execution exists absolutely exists in go, because that's what a build tool is. https://pkg.go.dev/cmd/go#hdr-Add_dependencies_to_current_mo...

Yeah. The blogpost reads like a confession. It's very strange.

Honesty would be Anthropic paying the 1000 alpha testers a fair wage for their very dangerous QA work.

I don't know, but I suspect the builds of the programs you're using play a huge factor in this. Depending on the Linux distro and package management you're using, you just might not be getting programs that are compiled with the latest x86_64 optimizations.

Yes. I guess what I meant is that cathedrals are a complex system that we know how to do, and still they take ages to build properly.

I'm not a Zig developer, but I imagine one reason why the Zig documentation is so spartan is because the language is still young and constantly evolving. It's really hard to devote the time and energy to writing documentation when you know that what you've written will just be wrong at some uncertain point in the future.

There is no benchmark. As a species, we don't even know know what a good programming language is, let alone how to reliably develop one. This stuff takes time, and we're all learning it together.

I like to compare this to real world cathedral building. There are some cathedrals that are literally taking centuries to build! It's OK if the important, but difficult thing takes a long time to build.

It makes the cheats more valuable on the black market. I'm fairly sure the only people cheating in the major competitive games with anticheat are whales and extremely unethical pro players.