bayindirh
However, while Testing is "relatively secure", it's never "Server secure". I'd never use testing or testing packages in stable or any server for that matter.
That's interesting, can you give an example? Asking as a curious Debian user.
Again. Stable is for servers, testing is for personal use.
I never argued otherwise, ever.
If you want real testing, you should run "unstable". If you're in for fun, try experimental.
Running Testing on my desktops and stable on my servers since forever. None of them broke, none of them created problems.
I don't care Stable running 6.x.x. It gets security updates in less than 24h, and is applied automatically before I wake up, and doesn't ship coreutils with 104CVEs, just because it's Rust.
Debian used to move a bit slow in terms of userspace, and that's true, but for servers, that's a non-issue for the last 20 years or so (from my experience).
On the Desktop side, Fedora and Ubuntu moves faster on the userspace front, but if your system is behind a NAT, and you know what you're doing, Debian Testing is just as good, more stable and it's rolling (except when it's feature freeze, but a stable workhorse is better than a shiny but breaking one).
Debian allows me to sleep well at night, provides guaranteed updates, and works rock solid all-round, so I won't be touching Ubuntu for the foreseeable future. Esp, with controversial choices like uutils, etc.
Also, extensive commenting inside codebases is useful documentation, incl. these kinds of incidents. Good code documents the how, but not why. Comments shall also include the "why" where applicable.
I have reduced my social media to two sites: Here and Mastodon (with a very limited follow circle). I don't follow tons of ad-ridden websites. I have a self-hosted RSS reader, following 10 feeds. Instead of following junk tech news, I read LWN.
Next step might be enabling antiproc on HN to reduce my time here, since I added time limits on applications on my phone and love that artificial limit.
I have limited energy and I want to focus it instead of spreading it around. Otherwise progressing beyond a certain point becomes impossible.
Also, I also agree that people optimize without proper testing and profiling. If there's a real bottleneck here, trying to optimize it is the right call. OTOH, optimizing without profiling opens a lot of unnecessary cans.
Lastly, Go doesn't like constant allocation and deallocation of variables, that's true, but I believe knowing this and optimizing hot-loops for that goes a very long way as a start.
I'm on $20 Claude plan, and it's also ample for my needs, for now.
True, I use LLMs as glorified search engines to unearth material to read myself, but Gemini is much more useful if you decide to learn yourself. It also offers interesting expansions to your questions.
While I don't offload my work to LLMs (e.g.: Write this project, I'll be watching TV), I find them useful for closing my knowledge gap by collating information, and Google's Gemini is good at that.
Better yet, they confessed it: "Microsoft exec called AI scraping 'the largest theft of labor in human history'" [0][1]
[0]: https://news.ycombinator.com/item?id=49752056
[1]: https://techcrunch.com/2026/09/17/microsoft-exec-called-ai-s...
If it was, impersonating home users en masse to scrape the whole web to train models would result in lifetime in prison. Now we call it fair use.
Debian has an extensive toolchain to check things. Having a set of deterministic tools which feed LLM with data can be beneficial, though.
Again, I'm not defending the LLM here, just want to show how hard the problem is to begin with.
While I'm perfectly on the same page with the critics of the LLM generated summaries, I'm a bit torn on the issue.
For anyone not familiar with Debian ecosystem, there's a helper tool called Lintian. Lintian does all kinds of checks from package formatting, licenses to dependency management (which can detect both unnecessary yet included and necessary but missing dependencies via static analysis of your tool if necessary).
It's expected that your package to be "Lintian clean" to be able to included in Debian with minimum friction and wait. Even though it's Lintian clean, your package also checked by teams which are severely understaffed, and composed solely of voluntary people.
NEW queue also receives tremendous influx of packages (which can be considered a torrent, even). Since noon, there are 10 more ITP (intention to package) bugs open in my inbox.
As a result, at one hand, these people need every help they can get because getting new trainees and getting them to learn the intricacies is hard, on the other hand LLM generated text rightfully generate negative reactions from people. However, giving developers an automated check of what looks right and what looks wrong is helpful, in my perspective.
I wonder what people would have said it was a deterministic tool generating these reports and sending people these summaries as a "hey consider this feedback until a human has time to see your package".
This is a hard question and we need to think before impulsive reactions. I even don't have all or any of the answers, but at least I have some insight why this is there.
I probably shot less than 100 frames in full auto mode with that D70s, rest was apeture priority or full manual. The reason I still love my D70s is it behaves like an analog camera very much, from its light meter correction needs to ISO response of the sensor.
When compared to it, shooting with A7-III still feels like cheating sometimes. Maybe I should get the Pentax fixed or start playing with the Canonette 28 I have.
It depends on the calculator and task at hand. Consider graphing, integration or any programmable needs, and they might converge. ALU of a processor is pretty efficient at what it does.
> The app is less efficient only in an abstract, impractical way.
Again, depends, as I said above. You tend to brush efficiency away because you only mentally measure time to completion, only, which is understandable.
Effectively instant means nothing, since everything is fast for small n. I love to give this example from a codebase I have worked on during my Ph.D. The problem which took half an hour under Matlab was done in ~40 seconds with mine, however, a thousand-step version of the same problem would take 11 hours. Saving a single second from that 40 second loop would shave my work by ~20 minutes, and this will compound for bigger problems still.
Just because we see the results instantly, doesn't mean it's fast or efficient by any means. It means we might forego optimizing it for sufficiently small n, if we don't care about that part of the code. That's all.