What modern features are you looking for in a say, document editor? My experience with LibreOffice Writer and Calc has been excellent. I'm happy there is no modern AI or cloud integration noise or ribbon bars with excessive whitespaces.
For starters, universities and government offices should not expect a proprietary format. Everyone should accept OpenDocument Format (ODF) or a similar FOSS format. MS Office, LibreOffice, OpenOffice and whatnot can compete in editing and rendering open formats.
Come to think of it, this is a good proposal for EU, thanks for the USB-C, by the way :)
Can't speak for every graduate program or every school, but when I was in grad school at University of York, we actually used Overleaf with LaTeX a lot, since it allowed shared collaborative editing.
The problem with this is Microsoft foresaw it and pushed (bribed?) OOXML through ISO and now there's no standing on "forcing" an open standard without OOXML being one.
how about requiring the format to actually be specified? Isn't ooxml filled with tons of chunks saying "and then this will behave like word 95 did" and not specify what tat is
Tangential, but does anyone know why in 2026 and on Debian 13, my machine still hangs when some process exhausts RAM?
Is there really no higher-priority kernel process to prevent total freeze of the system and send a SIGKILL to the culprit process when such a scenario happens?
I wish there was an easy way to configure it to say "target user processes first, specifically java (or these days python)" as in my experience they are always the culprits. Processes owned by system accounts or root should be the last ones killed.
Similarly, in the past I have wished for the ability to exempt a process from the oomkiller. I've run servers where the top memory user was also the server's entire reason for existence, and if that process gets killed the server may as well be down. It would literally have been better for any other process to get killed, but it was always the application process because of the memory usage.
> First off, this is exactly how systemd-oomd is supposed to behave under memory pressure. The documentation is specific on this; systemd-oomd itself says:
> > [...] If the configured limits are exceeded, systemd-oomd will select a cgroup to terminate, and send SIGKILL to all processes in it. [...]
> By having the [email protected] template be enrolled in systemd-oomd, Fedora made the cgroup that systemd-oomd would select to be killed be all of your processes (across all of your sessions, if you have more than one). ...
Maybe *Fedora* has fixed or improved in the last 4 years. Or maybe they don't run Fedora.
User-space OOM killers never really worked for me and imo are not a proper solution anyway. This option instead lets you make the kernel OOM killer actually work for desktop use.
Currently have it set to `1000` and it works very well for me (don't remember the last time I had a full system freeze due to OOM).
It's because linux is a toy OS. Specifically, it overcommits memory in the hope/assumption that it won't all be used at once, but doesn't have a way to gracefully degrade when applications collectively want to use more memory(+swap) than it actually has. You can turn off overcommit, but applications are designed with the overcommitting feature in mind, so your experience might not be as good as you were hoping for.
Making a massive swap space helps a little bit. It's better to just never let your actual memory usage go above 85% to 90%. It's fine to go above if you're trying to optimize a server with a specific set of processes to wring every last bit of efficiency out of it, but not for general desktop computing.
If it really bothers you OpenBSD (edit: thanks for the reminder TimTheTinker) and Illumos don't allow overcommit at all and Windows handles this situation much more gracefully, so WSL is an option too. If you don't mind Oracle (i do), solaris also doesn't allow overcommit.
You're right. I'm glad the very next sentence in my comment landed.
The problem with turning it off is that the system and applications have been architected assuming that it will be on, so things like fork/execing a memory heavy processes or allocating memory inside a cgroup (which still pretends overcommit is enabled and there's still no way to disable that assumption) that used to work fine might break with no good way to get them to work again. This comment (and siblings) have more specifics: https://news.ycombinator.com/item?id=27794237#27795199
the system will kill whatever it damn well pleases. You can tune it with priorities to ask it to try to not kill that, and once it kills your sshd once, you'll probably configure it to exempt sshd from being OOM killed at all. That doesn't fix the memory pressure or hanging or stalling, but you'll at least be able to log into the box still instead of dragging out a serial cable.
In a nutshell, overcommit. It's more or less broken by design but it's also incredibly practical so pretty much everyone does it.
Couple that with the fact that it's difficult bordering on impossible to correctly determine the culprit. If you've got 16 GB RAM and the user launches 3 processes each of which attempts to use 8 GB who should you kill?
Notably windows doesn't use overcommit, and degrades much more gracefully under memory pressure. The biggest tradeoff is the amount of disk space consumed by a page file that also has to reserve space for unused pages that have been allocated but never been swapped in. On linux you can turn overcommit off, but there's too much software written around the assumption that overcommit is on
Is that still the case today? Notably (IIUC) overcommit is required for certain security measures. I believe it was chromium that I noticed mmaping somewhere north of 1 TB of memory on startup so that it can do (again IIUC) something akin to ASLR internally.
On Windows you can achieve something like manual overcommit by calling VirtualAlloc with just MEM_RESERVE. That gives you a continuous space in your process's virtual address space, without actually backing it with any physical pages. Kind of like what a malloc does on linux
But where linux would automagically back those pages once you use them, Windows requires you to actually ask for those pages to be backed by something (physical memory or page file) by calling VirtualAlloc with MEM_COMMIT on the range you actually want to use
At a glance that seems like a much more sensible design. I guess it's dead in the water for posix on account of fork being CoW? This is quite the rabbit hole. I wonder if programming languages ought to be designed in such a way to accommodate a preemptive signal indicating allocation failure in place of a page fault? Rather than malloc returning null or etc.
> I guess it's dead in the water for posix on account of fork being CoW?
If that's the only issue, it's avoidable for most use cases. Lots of processes that fork are doing fork/exec to run a helper program. If they know they will do that and that they will be a large process, it's often useful to setup a fork/exec helper in early application startup.
However, there are some applications that use CoW more intentionally. Lock -> fork -> (unlock in parent / persist coherent snapshot in child) is a common pattern; I believe redis uses thst pattern and I've seen it mentioned in discussions about MMO servers. I believe postgres uses fork and CoW for transaction isolation ... but postgres also runs on Windows so there must be another way or I don't understand.
For the persist case, you could imagine some sort of flag to fork to allow overcommit and maybe even to let CoW requests stall in the parent rather than fail... the child is expected to do its work and exit in a limited time.
Windows also does a neat trick Linux lacks: automatically adding more swap, up to a limit. Systems with loads of RAM barely lose any storage to swap, but once they do get hit, they can get many gigabytes of swap space without user interaction. I believe macOS does it too, of course.
I'm sure there are many reasons why Linux can't do that by default, but it's a real shame.
> Windows also does a neat trick Linux lacks: automatically adding more swap, up to a limit.
Given that one can have swap files, and can also use LVM LVs for swap, and given that userspace OOM killers that work way better than the built in one -for some workloads- exist, I see no reason why you couldn't have this on Linux. This comment [0] mentions a project that claims to do just that -and seems to use swapfiles to do it-, but I don't have any experience with it.
FWIW, I did find the README by the original author [1] far more informative than the one written by the new maintainer.
I assume that's primarily because the stance of most distros would require something like that to be strictly opt-in. I don't know if it's possible to trigger a service based on overall swap usage? But given that the oom killer exists I don't see why it couldn't be trivially repurposed to add swap files on the fly.
> Couple that with the fact that it's difficult bordering on impossible to correctly determine the culprit. If you've got 16 GB RAM and the user launches 3 processes each of which attempts to use 8 GB who should you kill?
In all cases, yes, in some cases no, you can make some heuristics for common use cases
For example, if I have 3 process hogs, on desktop I'd rather have my dev containers be killed, than anything I'm using.
Or on server, I'd rather have anything else but SSH/VPN software killed, because that's needed to debug the problem.
With some workarounds, I've put chrome and slack into the same RAM-limited cgroup - no more whole system freezes. From my anecdotal evidence, this also answers the question "who should you kill" :)
A strange behavior I sometimes run into with earlyoom is that I try to start up some buggy software of mine and it seemingly never starts.
It took a long evening to figure out that it gets earlyoom'd immediately because it tries to allocate too much. Previously the very familiar hitching and freezing was a very easy sign of what kind of issue I was dealing with
It does not if you switch swapp off and use zram instead. I am typing right now on such a setup wityh 16 GiB ram and it occasionally, once a week or so, kills my firefox due to oom.
If you are you using disk swap - not sure why would if you have a SSD, but I once heard some justification for doing that - then install early OOM.
Ah nice. I was dealing with that in one of our environments where a security update ended up causing apt to use more memory than usual so the oom killer nuked our elasticsearch process to "free up some memory".
And since that happened on all nodes around the same time, it took out the entire cluster. If you are not familiar, random, uncontrolled node restarts in any kind of multi node database or search product are a great way to trigger outages. So, not great.
I've had quite a few encounters with the oomkiller killing processes that were important and didn't need killing. Or as I like to phrase it "killing the one reason this server exists".
These days the way to size a server is "have enough memory to run whatever you need running + at least half a GB for whatever apt might randomly demand at any point". And guess what, memory tends to be expensive in cloud environments so people tend to get vms with as little as half a GB of ram.
I couldn't find any information about that. Do you have something to back it up (news articles, changelog entries), or was it just your subjective experience?
I had a 1GB Debian VM which started freezing (requiring a hard reboot) after a routine aptitude upgrade to apply security patches. It was indeed caused by low memory, but not out of memory as there was still enough swap space remaining.
The culprit turned out to be the kernel itself, and rolling back to a 6.1 series kernel made the problem go away. I see that Linus's love for vibe-coding is already paying dividends.
It's all fine and dandy until marketing bros decide to shove all kinds of shady modals into that JS file. The JS side is not exclusive to trivial interactivity.
It's open source software. You can see what it does, and you just put it on your server. We're talking about pre NPM javascript here, no continuous deployment, everything is vendored and local and no one is going to change that file without your knowledge and permission. And if someone does, you have much bigger problems on your hands.
What you can't own and control is the browser vendors and how they choose to implement things, or not to. You can edit a JS file to your specific needs, but you're stuck with whatever the browser decides.
My point was, people block js of websites by default. Why? Cause website devs abuse js and don't exclusively use it for basic interactivity of stuff like sorting table columns.
There is an incentive to use HTML for common interactivity purposes.
Isolation is a pretty standard requirement for lots of networks, especially gov. AWS provides isolation domains, and used to have a unidirectional cross-domain service called AWS diode. Or you can just configure your gateways properly / buy data diodes. Lots of possible solutions.
They can't have it both ways. You don't get to tell the media your product is more dangerous than nuclear weapons for precisely this reason, and then do less to secure it than an off-the-shelf AWS product that predates LLMs.
No, I'm saying that you're conflating current LLMs with future ones. The 2018 date was an indication that Musk wasn't referring to any specific already-existing LLM, since there were no LLMs in 2018.
“Isolation” can mean the network hardware has no direct connections to an extranet. Data is transferred manually by physical media (USB, DVD, etc.) with logging and dedicated transfer stations.
“Isolation” can mean a VLAN on equipment which has also has extranet access, creating a logical isolation rather than physical (to reduce cost). Data can be transferred manually or through diodes.
And then there’s “isolation” which is a joke: machines technically able to access the internet but require proxy configuration (which isn’t set but can be easily derived).
I wonder about Japan and Europe these days. Back in the 80s, when Japan was pursuing the "Fifth-Generation Computers", EU and US scrambled to compete with Japan. Like, it was a big deal for strategists and decision-making high-level politicians of that era.
Now in 2020s, it seems only China is tailing US and in turn, US is wary of China. What gives?
Do you think Japan and the EU would be better off if our/their economies were centred around trillion dollar companies that make a product that is 20% better than the Chinese models at 1000x the cost?
The reality is LLMs are just tools, and not even close to as revolutionary of tools as computers themselves. Even Chinese companies understand that. It is the US alone that is in machine god mania, gambling their economy on this idea that the next model will let them rule the world if only we give it three more months.
>Do you think Japan and the EU would be better off if our/their economies were centred around trillion dollar companies that make a product that is 20% better than the Chinese models at 1000x the cost?
Why Japan and Europe don't develop a model that is 20% worse at 0.001x the cost?
Chinese companies have at least three major advantages:
1. Price of electricity is low because of China's excellent energy policy. Admittedly this should absolutely be a priority of Japan/EU, but it isn't, so first you'd have to start there...
2. Because of #1, China already had massive infrastructure in place for eg. crypto mining that was readily repurposed. Japan/EU never engaged in this fad, so they have to start effectively from scratch in building out the GPU infrastructure.
3. Chinese talent is relatively isolated from the US economy. US-aligned economies must compete with the US for talent. It's hard to develop technology at a reasonable cost when all of your top talent is leaving to get paid 10x as much by speculative gamblers. If you don't have a very good reason to believe the gamblers are making a good bet, it's better to wait for them to go bust.
Added on to all of that... where is the upside? Chinese models are open anyways. There is nothing that merits this being a matter of urgent government intervention at all, it's basically pure downside.
US has really cheap energy and far more compute by a very large margin.
The real reason is chinese gov wants to crush US ai industries and own the market. Same thing they have successfully done multiple times in other industries now the difference is this time the US isn't seeming to back down.
I'm talking about EU/Japan. I'm aware the US also has cheap energy and loads of compute.
I have yet to see any credible evidence that the Chinese government was involved with either the creation of DeepSeek or the open publication of it, in any way. Seems like usual yellow scare discourse, attributing everything to the bogeyman.
> in the 80s, when Japan was pursuing the "Fifth-Generation Computers"
“The Fifth Generation Computer Systems…was a 10-year initiative launched in 1982 by Japan's Ministry of International Trade and Industry (MITI) to develop computers based on massively parallel computing and logic programming” [1].
It's never "just working", you'll still have to debug the vibe-ported apps. And you won't be good at it if your devs don't actually know the target platform.
All that to say, I don't think that vibe-porting will give you more than cross-platform. With cross-platform, at least your engineers understand the codebase.
What modern features are you looking for in a say, document editor? My experience with LibreOffice Writer and Calc has been excellent. I'm happy there is no modern AI or cloud integration noise or ribbon bars with excessive whitespaces.
reply