It's a concept called defense in depth, and perhaps also defensive programming. It's good practice. You do not want to hold things off at the gate exclusively, because that relies entirely on your gate defense. This shouldn't be a difficult concept to understand.

Yes, it's potentially more difficult to exploit, but if it's known, a clever exploit can still be fashioned to expose it. This is being seen increasingly with AI driven exploits. You don't need a kernel RCE to gain full system access - you need 3 or 4 small privilege escalation bugs (theoretical problems) in different packages that are commonly used.

You're viewing the waves for the ocean.

There's also been recent research that shows that plasma actuators or electrohydrodynamic (EHD) flow control effectively eliminate drag. I'm not sure why this specific TFA gained publication but the ionic charge did not.

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Flink.springer.com%2Farticle%2F10.1007%2Fs40430-026-06357-y

"the people who have to review code"

That doesn't exist as a meaningful or useful discipline anymore, except in niche development roles.

Sorry, no. Your code review isn't useful. It's probably not even thorough.

We're well into the "code review should be done by agents" phase of things.

Yes, FreeBSD has most of the headaches of Linux in 1996 (mainly around package management, compatibility, and hardware support). Other than all the important things to an OS, it's great.

If you use debian based distros, the answer is 'yes'. The size of the package repository is excessive, and it's markedly cleaner to install sidecars on Linux than it is using the ports tree (or rather, adding packages which are not in the ports tree, because that happens a lot too).

Frankly, in 2026, this is inexcusable. You can easily and trivially build high quality documentation using AI (assuming the underlying project is of high quality).

FreeBSD is a non-starter for anything beyond hobbyist or large fleets of generic boxes due to its shortcomings in package management. It hasn't meaningfully changed in 30+ years.

You've got pkg and you've got ports - and neither provides an adequate means of keeping systems up to date en masse, by itself or in aggregate.

pkg (and related tools/repo) is severely limited - it doesn't really do security updates. It's not meaningful beyond the quarterly updates; it's a base working set.

The ports tree is another problem entirely. It's workable for one system as a hobbyist where uptime and consistency isn't important, but instantly requires secondary independent management to keep things up to date. It's just one big rolling release with no apparent controls for quality.

Perhaps it's just me, but the only way I found to maintain 2+ FreeBSD systems consistent is to keep an independent ports tree on ZFS (for snapshots you keep indefinitely) and a dedicated build box (instance). The resulting packages then get distributed to all the machines. The alternative is to have updates fail fairly regularly due to ports not being thoroughly vetted - unbuildable versions of the packages or security issues that weren't properly addressed from upstream. Then, you've also got to hunt down the upstream releases on occasion when the ports maintainers... haven't. You end up needing to run a full package vetting environment for your production systems and the QA burden is much higher than running your own eg. apt or yum mirrors + testing environments. I did this for years and it was horrible busywork.

In short, there's nothing on freebsd that's comparable to apt/yum/slpkg and package management is stuck in the 1990s. It's the only ecosystem I'm aware of which hasn't modernized to use cohesive and coherent package management.

Unless you're doing an extremely minimalist system, or building appliances, I see too many significant downsides to using FreeBSD. Better to use DragonFly, or Gentoo.

Star Wars is increasingly targeting children with its stories and characters. The plot and moral theme (what little of it there ever was) suffers as a result. Grogu is a massive hit with children, so they're monopolizing on that.

They're clearly trying to hide the fact that the pilot was of a specific ethnic classification, one which is already well known for causing a very large percentage of road accidents with tractor trailers.

In other words, it's like saying someone violated copyright by making a MIDI version of a popular song.

No, they did not release audio.

A spectograph is not audio, it's an image of the timing, signal, frequency of a signal.

The fact that it could be reverse engineered into coherent audio is not consequential.

That's like saying that someone released public source code to a program when all they did was release the binary. Or, more accurately, released a use video of the software, which someone then reverse engineered.

Please sar remove the audio spectograph sar it's very important sar

There's another way to mitigate this, and it's ideologically difficult for a lot of Open Source people to accept... but you'll have to diverge from the tried and true path. AI makes this much easier: instead of using $popular_thing_everyone_uses, you use something else - either COTS or roll-your-own. Yes, it might be bugs, and yes, they might be security bugs, but unless they're painfully obvious issues where you didn't do your due diligence, it's going to be a more obscure target which will require more targeted attacks.

No, this doesn't solve anything and it's 100% "security through obscurity". Perhaps I'm just missing something, but it seems like sound practice.

So, basically what you could do in W95.

What you describe is basically cron + freebsd rc or classic linux init.d

Systemd over engineered everything to better support corner cases, which ultimately doesn't work as well at the core functionality and causes systemic stability and security problems.