31–40 of 256 posts
if machine-learning can find all these holes why can't machine-learning write a product from scratch that is flawless?
Whatever the answer to that conundrum might be, LLMs are trained on these patterns and replicate them pretty faithfully.
How bad is it if someone infects my home router using such a thing? They can MITM non-encrypted requests, but there are not a lot of those, right? What else can they do, assuming the computers behind the router are all patched up.
Earlier quoted context omitted.
No, that's exactly the thing to complain about. That whole model dates to before automated testing was even really a thing, and no one knew how to do QA; your QA was all the people willing to run your code and report bugs, and that took time. Not to mention, you think the C of today is bad? Have you looked at old C? And the disadvantage is that backporting is manual, resource intensive, and prone to error - and the p…
> That whole model dates to before automated testing was even really a thing, and no one knew how to do QA; your QA was all the people willing to run your code and report bugs, and that took time. That's not what it's about. What it's about is, newer versions change things. A newer version of OpenSSH disables GSSAPI by default when an older version had it enabled. You don't want that as an automatic update because it…
So when you do update and get that GSSAPI change, it comes with two years worth of other updates - and tracking that down mixed in with everything else is going to be all kinds of fun.
And if you're two years out of the loop and it turns out upstream broke something fundamental, and you're just now finding out about it while they've moved on and maybe continued with a redesign, that's also going to be a fun conversation.
So if the backport model is expensive and error prone, and it exists to support something that maybe wasn't such a good idea in the first place... well, you may want something, but that doesn't make it smart.
How bad is it if someone infects my home router using such a thing? They can MITM non-encrypted requests, but there are not a lot of those, right? What else can they do, assuming the computers behind the router are all patched up.
if machine-learning can find all these holes why can't machine-learning write a product from scratch that is flawless?
I never understood why some projects get extremely popular and others don't. I also suspect by now that the reports by tools that are "too dangerous to release" scan all projects but selectively only contact those with issues, so that they never have to admit that their tool didn't find anything.
Earlier quoted context omitted.
> That whole model dates to before automated testing was even really a thing, and no one knew how to do QA; your QA was all the people willing to run your code and report bugs, and that took time. That's not what it's about. What it's about is, newer versions change things. A newer version of OpenSSH disables GSSAPI by default when an older version had it enabled. You don't want that as an automatic update because it…
You're going to have to update production at some point, and delaying it to once every 2 years is just deferred maintenance. And you know what they say about that... So when you do update and get that GSSAPI change, it comes with two years worth of other updates - and tracking that down mixed in with everything else is going to be all kinds of fun. And if you're two years out of the loop and it turns out upstream bro…
Earlier quoted context omitted.
No, that's exactly the thing to complain about. That whole model dates to before automated testing was even really a thing, and no one knew how to do QA; your QA was all the people willing to run your code and report bugs, and that took time. Not to mention, you think the C of today is bad? Have you looked at old C? And the disadvantage is that backporting is manual, resource intensive, and prone to error - and the p…
If you want that, you don't want Debian. Other people do. Some people will even run Debian on the desktop. I would never, but some people get real upset when anything changes. Debian does regularly bring newer versions of software: they release about every two years. If you want the latest and greatest Debian experience, upgrade Debian on week one. From your description, you seem to want Arch but made by Debian?
Isn't that essentially Debian unstable (with potentially experimental enabled)? I've been running Debian unstable on my desktops for something like 20 years.
Maybe this is the kick in the ass Debian needs to upgrade the embarrassingly ancient dnsmasq in "stable" because while I can't think of any new features, the latest versions contain many non-CVE bug fixes. But I doubt it, they will lazily backport these patches to create some frankenstein one-off version and be done with it. Before anyone says "tHaT's wHaT sTaBlE iS fOr": they have literally shipped straight-up broke…
Earlier quoted context omitted.
> That whole model dates to before automated testing was even really a thing, and no one knew how to do QA; your QA was all the people willing to run your code and report bugs, and that took time. That's not what it's about. What it's about is, newer versions change things. A newer version of OpenSSH disables GSSAPI by default when an older version had it enabled. You don't want that as an automatic update because it…
You're going to have to update production at some point, and delaying it to once every 2 years is just deferred maintenance. And you know what they say about that... So when you do update and get that GSSAPI change, it comes with two years worth of other updates - and tracking that down mixed in with everything else is going to be all kinds of fun. And if you're two years out of the loop and it turns out upstream bro…
One is security updates and bug fixes. These need to fix the problem with the smallest change to minimize the amount of possible breakage, because the code is already vulnerable/broken in production and needs to be updated right now. These are the updates stable gets.
The other is changes and additions. They're both more likely to break things and less important to move into production the same day they become public.
You don't have to wait until testing is released as stable to run it in your test environment. You can find out about the changes the next release will have immediately, in the test environment, and thereby have plenty of time to address any issues before those changes move into production.