pepoluan

What's so bad about Python's virtualenv? It's a good way to have an LKGC (Last Known Good Configuration). When a CVE happens, you spin up a new venv and do smoke test, canary test, blue/green deployment, and so on.

If the update breaks things, you go back to the old venv. If the update goes well, then you just delete the old venv.

Not implementing security updates the right way is just human laziness and has nothing to do with the language in use.

You know, with all the babysitting needed, I wonder if effort is not better spent in just, you know, writing code.

Can you actually quantify the time & effort 'saved' letting LLM generate code for you?

True words.

I'd say "the fastest" is a side effect of "allowing one to tune their systems to their utmost liking." -march=native, throw away unused bits and pieces, integrate modules into the kernel, replace bits and pieces with faster -- if more limited -- bits and pieces. And so on.

Gentoo is LFS but with the interdependence between packages mapped out for you (all hail the USE flags!) Or, alternatively, Arch with even more customization knobs to twiddle.

I have had Gentoo in at least one nearby system (physical and/or VM) since about 15 years ago. It's always a blast interacting with it.

Safe and living also doesn't match.

Why, you want to buy a new printer?

If you want inkjets, buy those with ink tanks. More expensive up front, but operating cost is so cheap. And no more "you have to replace a whole cartridge just because Magenta is low"; if Magenta is low, buy a bottle of Magenta, and fill.

For laser printers, buy those whose toner cartridges are separate from the drum, and those whose toner cartridges can be reset mechanically. And refillable.

My go-to brand for printers is Brother, btw.

Type hints are 100% optional, though.

And to be honest when you start using it, even just for simple things such as function signature, with the proper IDE it helps you catch mistakes.

So. Another regex problem?

I am one of the maintainers of aiosmtpd [1], and the largest PR I ever made was migrating the library's tests from nosetest to pytest. Before doing that, though, I discussed with the other maintainers if such a migration is welcome. And after getting support from them, I made the changes with gusto. It took weeks, even months to complete and the PR is massive [2]

But still the crux of the matter is: Massive changes require buy-in from other maintainers BEFORE the changes even start.

[1] https://github.com/aio-libs/aiosmtpd [2] https://github.com/aio-libs/aiosmtpd/pull/202

LLM will guiltlessly produce hallucinated 'review', because LLMs does NOT 'understand' what it is writing.

LLMs will merely regurgitate a chain of words -- tokens -- that best match its Hidden Markov Model chains. It's all just a probabilistic game, with zero actual understanding.

LLMs are even known to hide or fake Unit Test results: Claiming success when it fails, or not skipping the results completely. Why? Because based on the patterns it has seen, the most likely word that follow "the results of tests" are the words "all successful". Why? Because it tries to reproduce other PRs it has seen, PRs where the PR author actually performed tests on their own systems first, iterating multiple times until the tests succeed, so the PRs that the public sees are almost invariably PRs with the declaration that "all tests pass".

I'm quite certain that LLMs never actually tried to compile the code, much less run Test Cases against them. Simply because there is no such ability provided in their back-ends.

All LLMs can do is "generate the most probabilistically plausible text". In essence, a Glorified AutoComplete.

I personally won't touch code generated wholly by an AutoComplete with a 10-foot pole.

The statement preceding your quote is more telling:

> as long as the code generation doesn’t use too much energy or cause unforeseen problems.

A badly-written code can be a time bomb, just waiting for the right situation to explode.

And also, using LLM to generate garbage requires so much energy.

If the submitter is sloppy with things that are not complicated, how can one be sure of things that ARE complicated?

"AI has a deep understanding" is very oxymoronic, especially if the "AI" being used was an LLM.

Or maybe just don't use LLM.

LLM is just a tool in the A.I. world. There are lots of other A.I. tools, such as Neural Network, Fuzzy Logic, Genetic Programming, and so on.

Not ALL automation can be more efficient.

Just ask Elon about his efforts to fully automate Tesla production.

Same as A.I. Current LLM-based A.I.s are not at all as efficient as a human brain.

Can be mitigated to a degree by separating the (cheaper) sensors and the (pricier) logic.

But then it will become a tradeoff of complexity vs longevity.

What's "correct" for you might not be "correct" for others. Furthermore, your owb definition of "correct" changes depending on circumstances; sometimes you want it hotter, sometimes you want it colder. Sometimes you want to change it partway through.

How do you calculate for that?

Back in the 90s, Fuzzy Logic was thought to be the solution. In a way, yes, but only for niche/specialized purposes, and they still have to limit the variables being evaluated.

Or, maybe, just not use LLMs?

LLM is just one model used in A.I. It's not a panacea.

For generating deterministic output, probably a combination of Neural Networks and Genetic Programming will be better. And probably also much more efficient, energy-wise.

The situations you described reflects a System that has changed. And if the System has changed, then a change in output is to be expected.

It's the same as having a function called "factorial" but you change the multiplication operation to addition instead.

The issue with not having something deterministic is that when there's regression, you cannot surgically fix the regression. Because you can't know how "Plan A" got morphed into "Modules B, C, D, E, F, G," and so on.

And don't even try to claim there won't ever be any regression: Current LLM-based A.I. will 'happily' lie to you that they passed all tests -- because based on interactions in the past, it has.

I think some software -- FLOSS or otherwise -- tries to do this by hiding functionalities behind an "Advanced Mode" toggle.

Which kind of fulfills the best of both worlds: Welcoming for beginners, but full-powered for advanced users.

More software should be designed this way.

I made some open source software myself and my desire is to see my code used as widely as possible.

So the ONLY reasonable choice for me is to release my code with a non-viral license. A copyleft license is TOTALLY UNREASONABLE for me because it limits the reach of my software.

(My license of choice is MPL-2.0)

Some of us in the Enterprise and Governmental sector try hard to avoid software with viral licenses.

We sigh in relief every time we see a software that we rely upon changes/adds non-viral license such as MIT, Apache, MPL, BSD, and so on.

And how many software are compiled with zero warnings?

And how many C programmers ignore such warnings because they are confident they know better?

But how many C programmers actually use that 'ability' to 'trivially' detect indentation errors?

And how many C programmers just ignore the warning while thinking, "I have decades of experience the compiler is just blabbering false positives"?

Rust forces some things preventing the bypass of guardrails.

The "rust is better" point is always "prevent memory-related bugs from happening".

Memory-related bugs is, like, 70% of bugs found in programs written in C and C++.

So, by rewriting in Rust, you prevent 70% of new bugs from happening, because a whole class of bugs just cease to exist.

And how do you define "backwards compatible"?

How can you be sure that something is "backwards compatible"?

By running tests. And as it happens, the original coreutils did not have a test for this particular edge case.

Now that a divergence of behavior has been observed, all parties -- the coreutils devs and the uutils devs -- have agreed that this is an unacceptable regression and created new test cases to prevent the same misbehavior from happening again.

I don't think run0 uses the same configuration syntax as sudo, so it's a no-go from the start.

sudo-rs can be a drop-in replacement for sudo for at least 95-99% of deployments, without any config changes necessary.

Now the rewrite in Rust is important because it greatly prevents appearance of new, memory-based bugs. Which might inadvertently happen if, say because of fixing a logic bug in one of sudo's more complex usages (and thus, less traversed code path), the maintainer introduced a memory bug.

This resistance, IMHO, is moot anyways since the sudo maintainer himself is in support of sudo-rs and actually helped the project in a consultancy capacity (as opposed to directly contributing code).

doas is too much of a difference from sudo. For instance, it uses a completely different syntax for its config.

sudo-rs is designed to be a drop-in replacement for maybr 95-99% of people who have been using sudo.

(I do use doas on my own systems though)

It's not "naive". That is the nature of Open Source software. Everything is in the open.

Especially because people will not use a pre-compiled binary, but compile the software themselves (e.g., Gentoo users). So there must be no 'secret' tests, to guarantee that whoever compiles the software, as long as the dependencies are met, will produce a binary with the exact same behavior.

In fact, as an Open Source software, the test suite of the original coreutils is part of the Source package. It's in their (that is, coreutils' maintainers) interest to have the software tested against known edge cases. Because one day their project will be picked up by "some lone developer in Iowa" who will add new features. If there are 'secret' test cases, then the new developer's additions might break things.

This incident is merely coreutils happening to produce correct results on some edge case for uutils.