creshal

"Industry hearsay" in this case was probably Sony telling game devs how awesome the PS5's custom SSD was gonna be, and nobody bothered to check their claims.

> executives conveniently stopped using the term "AGI," preferring weasel-words like "transformative AI" instead.

Remember when "AGI" was the weasel word because 1980s AI kept on not delivering?

But how much are you paying for these services?

See also, FreeBSD: Plenty of commercial offerings around it, no source for most of them, because the license doesn't require it. For example, there's no source for the Playstation kernels/userlands released by Sony. They only upstream some bug fixes that would be too onerous to keep in their private fork.

Why is this still not standardized?

Cisco, too. Whether or not you want to consider current Cisco a success model is... yeah

Was there an author involved at all, or did an AI write this summary?

Cool, then they can pool together and build a commercial station. There's now multiple companies capable of building them.

The ISS served all political purposes it could, and microgavity research can be served by private entities these days. (Especially considering that a Starship has half the internal pressurized volume of the entire ISS, at approximately one thousandth the cost.)

A permanent Moon base would allow research opportunities that private LEO stations can't: ISRU, low gravity research, the far side of the Moon offers unique opportunities for astronomy (any spectrum), etc. pp. Long term, who knows what additional opportunities it opens up.

If it works with only 2-3 wallets it can be lucrative enough.

File roller does use 7z internally, so no real surprise here.

But both implementations can be vulnerable to malicious exe files, so it's not a great idea to do this with a file you already suspect to be malicious.

And if you want the same disk from Dell (without any warranty or support), you take the highest price you can find and multiply it by five (after VAR discounts, ten without discounts).

Yeah, tape is alive and kicking for business use.

Automated tape libraries add a few grand to the total, but you get the added benefit of not having to change tapes daily.

My only concern is that tape speeds are stagnating around a terabyte per hour, while you can somewhat parallelize jobs with multi-drive libraries, it increases cost and complexity significantly.

Okay, that's cool for Java, but have you ever tried the absolute crap pyramid that is arduino's IDE? 2005 Eclipse would be a vast improvement in comparison. And Qualcomm never cares about anything that doesn't directly increase pforit margin, so "more money for better IDEs" with qualcomm in charge is just delusional.

VS Code has enough momentum by now that Microsoft couldn't kill it even if it wanted to. And a lot of the arduino-side work would involve creating/tweaking LSPs to their ideosyncrasies and making IDE-agnostic compilers... all of which is IDE agnostic and makes Arduino more useful to all users.

And, worst case, they could take it all to IntelliJ or other IDE vendors and quickly spin out an Arduino-branded IDE that isn't raw sewage.

Not sure why you're getting downvoted, considering how people torture themselves with calculating SSD cache sector offsets by hand so they can imitate 1% of ZFS's feature set with LVM2.

> Though any halfway competent Java developer following modern best practices will know to build systems that don't have these characteristics.

I'll let you know if I ever meet any. Until then, another terabyte of RAM for tomcat.

> It's usually not that much - typical executable is usually several megabytes in size and many processes can share the same code memory pages (especially with shared libraries)

Have a look at Chrome. Then have a look at all the Electron "desktop" apps, which all ship with a different Chrome version and different versions of shared libraries, which all can't share memory pages, because they're subtly different. You find similar patterns across many, many other workloads.

> But wouldn't it be better to avoid writing such programs?

Yes, indeed, the world would be a better place if we had just stopped writing Java 20 years ago.

> And how many memory such daemons can consume? A couple of hundred megabytes total?

Consider the average Java or .net enterprise programmer, who spends his entire career gluing together third-party dependencies without ever understanding what he's doing: Your executable is a couple hundred megabytes already, then you recursively initialize all the AbstractFactorySingletonFactorySingletonFactories with all their dependencies monkey patched with something worse for compliance reasons, and soon your program spends 90 seconds simply booting up and sits at two or three dozen gigabytes of memory consumption before it has served its first request.

> Is it really that much on modern systems?

If each of your Java/.net business app VMs needs 50 or so gigabytes to run smoothly, you can only squeeze ten of them in an 1U pizza box with a mere half terabyte RAM; while modern servers allow you to cram in multiple terabytes, do you really want to spend several tens of thousands of dollars on extra RAM, when swap storage is basically free?

Cloud providers do the same math, and if you look at e.g. AWS, swap on EBS costs as much per month as the same amount of RAM costs per hour. That's almost three orders of magnitude cheaper.

> When I program, my application may sometimes allocate a lot of memory due to some silly bug.

Yeah, that's on you. Many, many mechanism let you limit the per-process memory consumption.

But as TFA tries to explain, dealing with this situation is not the purpose of swap, and never has been. This is a pathological edge case.

> almost all used memory is now in swap and the whole system works snail-slow, presumably because kernel doesn't think it should really unswap previously swapped memory and does this only on demand and only page by page.

This requires multiple conditions to be met

- the broken program is allocating a lot of RAM, but not quickly enough to trigger the OOM killer before everything has been swapped out

- you have a lot of swap (do you follow the 1990s recommendation of having 1-2x the RAM amount as swap?)

- the broken program sits in the same cgroup as all the programs you want to keep working even in an OOM situation

Condition 1 can't really be controlled, since it's a bug anyway.

Condition 2 doesn't have to be met unless you explicitly want it to. Why do you?

Condition 3 is realistically on desktop environments, despite years of messing around with flatpaks and snaps and all that nonsense they're not making it easy for users to isolate programs they run that haven't been pre-containerized.

But simply reducing swap to a more realistic size (try 4GB, see how far it gets you) will make this problem much less dramatic, as only parts of the RAM have to get flushed back.

> I a hypothetical case without swap this case isn't so painful. When main system memory is almost fully consumed, OOM killer kills the most memory hungry program and all other programs just continue working as before.

And now you're wasting RAM that could be used for caching file I/O. Have you benchmarked how much time you're wasting through that?

> I think that overall reliance on swap is noways just a legacy of old times when main memory was scarce and back than it maybe was useful to have swap.

No, you just still don't understand the purpose of swap.

Also, "old times"? You mean today? Because we still have embedded environments, we have containers, we have VMs, almost all software not running on a desktop is running in strict memory constraints.

> and kernel code may be simpler (all this swapping code may be removed)

So you want to remove all code for file caching? Bold strategy.

> Also, as a BSD mainly person, I think the differences stand out. I haven't noticed an OOM killer approach on BSD.

BSD allocators simply return errors if no more memory is available; for backwards compatibility reasons Linux is stuck with a fatally flawed API that doesn't.

Welcome to the wonderful world of Java programs. When your tomcat abomination pulls in 500 dependencies for one method call each, and 80% of the methods aren't even called in regular use except to perform dependency injection mumbo jumbo during the 90 seconds your tomcat needs to start up, you easily end up with 70% of your application's anon pages being completely useless, but if you can't banish them to swap, they'll prevent the code on the hot path from having any memory left over for file caching.

So even if you never run into OOM situations, adding a couple gigabytes of swap lets you free up that many gigabytes of RAM for file caching, and suddenly your application is on average 5x faster - but takes 3 seconds longer to service that one obscure API call that needs to dig all those pages back up. YMMV if you prefer consistently poor performance over inconsistent but usually much better performance.

I wish people would actually read TFA instead of reflexively repeating nonsensical folk remedies.

> I've always created swap of 1.5x - 4x RAM size on every Linux computer I've had to manage and never had any issues with it.

That's a couple terabyte of swap on servers these days, and even on laptops I wouldn't want to deal with 300-ish GB swap.

You should get more cameras and run one of them as load balancer in front of the others!

The distributed development model makes it tricky, because distributions themselves aren't necessarily the developers of sandboxing solutions, there's multiple approaches, many are incompatible with each other, none are fully mature and support every tool users could realistically want to run.

Same with selinux/apparmor/competitors, they're all mutually exclusive to some degree and have different pros and cons. RHEL shoves selinux down everyone's throat without caring how well that works in practice, and coincidentally 100% of RHEL systems I've interacted with have it disabled.

Until there's solutions that are mature, the best solution for distros is still to let users choose the lesser evil for their specific use case.

Memory buses are negligible, compared to everything else going on. Especially in a SoC that has not just a CPU, but 20 other devices as well.

From a developer's perspective, yes.

From a user's perspective, they just keep working.

> I think that there is a shitload of old desktop and laptop computers from 10 to 15 yrs that are still usable only with a linux distribution and that will not be true anymore.

For mainstream laptops/desktops, the 32 bit era ended around 2006 (2003, if you were smart and using Athlon 64s instead of rancid Pentium 4).

Netbooks and other really weak devices held out a few years longer, but by 2010, almost everything new on the market, and a good chunk of the second-hand market, was already 64 bits.

> both of which would reverse if my first wish is also granted

But why? The brilliance of 8601/3339 is that string sorting is also correct datetime sorting.

We've come full circle and reinvented PHP