I'm pretty sure this was known since the early days of Electron. It was even one of the chief complaints about VS Code when it was first launched.<p>Electron's value prop has always been about having one team producing one app that is supported on multiple platforms with minimal additional effort.<p>This article does nothing to address that.
A huge pain of desktop development is managing dependencies particularly if you are coming from C++/Native code. Imagine you wanted to make a simple app in the 2010s that accesses the webcam for instance: If you use chrome you got the full html5 runtime, whereas with other tools you'd need bespoke libraries which your end user may not have.<p>The only way to ship the same code between linux, macOS, and Windows would have been to either use something like Qt or the JVM back in the 2010s. The JVM desktop stuff was super ugly and Java itself had become notorious (also if you wanted anything remotely interesting like webcam/microphone or multimedia access you'd still have to ship dynamic libraries). Qt required special packaging skills to ship to the end user especially if third party libraries were involved. Electron killed that by bundling chrome (and chrome has a huge api surface).<p>Today, I would argue the package management situation for a language like rust is a lot different. You dont have to cobble different DLLs together, you can just statically compile dependencies and cargo/rust do a pretty good job of making sure it's bundled with your app. Other languages also now have similarly useful tools.
But then the C++ libraries you mentioned also had the ability to statically link into a binary, which means you could statically link the webcam access in, in your example. So I don't see the advantage you're arguing for?
It comes down to package distribution.<p>Chrome had already solved the hard problem of "how do we support webcams on linux, windows, and mac" and you as the dev just needed to use the Javascript webcam api. ( <a href="https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/API/MediaDevice...</a> )<p>In C++ land, you are ultimately going to either need to cook up your own webcam library or look for a 3rd party (which, in 2010, likely didn't exist) to provide it.<p>Today, there are a few easy to discover rust crates which provide cross platform webcam apis. But further, rust does cross platform better than C/C++ IMO. It's really easy to change how code is compiled based on the target. That was all well thought out because rust was supposed to be a language for browsers.
Dynamic vs static linking is mostly a red herring for desktop GUI application development unless you want to integrate into something like Linux distro package managers, as dynamic libraries on Mac and Windows can be self-contained within the application bundle/directory with no disadvantage beyond marginally longer startup time, and you can do similar things with Flatpak and friends on Linux.<p>The real difference is that Rust provides a package repository with a unified build system that's as simple to use as NPM or NuGet.<p>vcpkg which is similar exists today, but it didn't in 2015 when Discord started, still isn't anywhere near as comprehensive as package repositories for languages where package management is part of the standard toolchain, and the underlying build systems are far messier under the hood.<p>It can also be helpful in development to use libraries built from source as part of the application's build process, at least as an easily-accessible option, which wasn't common practice in most C/C++ ecosystems historically where different libraries used different build systems and if you wanted to integrate them into something like a Visual Studio solution for easy reference to source code during development and debugging you were often on your own.
Java desktop was only ugly if you chose for it to be. It was pretty minimal effort to get native look and feel. Nothing built in electron looks native. If we're accepting custom interface using electron, that was doable with Java too.
Usually it is hard for those coming from scripting languages.<p>Strangely enough we managed to write portable code across platforms during the last century, and there were more than only three major desktop OSes.
The article at least indirectly addresses that.<p>At the time Electron came out, there weren’t as many cross-platform UI frameworks available that they could have gone with.<p>You can see this with the comparison chart. GPUI effectively replaced Electron so the desktop app UI works across platforms. React Native is replaced with WebAssembly so that Rust can be the primary language across all platforms including mobile.<p>It seems like the new situation for Discord is rather elegant, and that none of this would have been available when it first came out.
GPUI works well for Zed, but it's built for Zed's needs only. There is no official crates.io udates. Breaking changes land as Zed needs them, and outside PRs often get declined causing a mess of several forks.
I love when folks complain about C++ in stuff like Qt, and then write C++ addons on Electron apps, to make them actually get an usable performance.
Why <a href="https://gpui.rs/" rel="nofollow">https://gpui.rs/</a> doesn't have a single screenshot of how it actually looks?<p>The first thing anyone would want to know when choosing a GUI framework is how it looks by default. Every major GUI toolkit has screenshots on their websites.<p>This happens so often it makes me wonder if people just don't know how to take a screenshot and put it in a webpage with <img>.
The problem is that it made everyone's life worse.
Not mine. I loathe Electron like many people. But, as someone who is legally blind and has very limited vision, being able to have custom UI zoom levels, per application, has made my life much easier.<p>For a long time, and mostly out of frustration, I wanted to build my own stack of software around my vision. But the mammoth amount of effort it would require meant I never went through with it.
The electron hate train needs to pull in to the station and be retired. We can just admit that it was a good solution for the problems of its time just like JQuery. Electron was conceived over a decade ago and it was an imperfect solution, but there’s no denying that it <i>was a solution.</i><p>Election predates WebAssembly by 5 years and hit the scene only one year after Rust was first created.<p>And just like JQuery, its time is coming to a close as better frameworks are available now that weren’t available back then.
> We can just admit that it was a good solution for the problems of its time just like JQuery.<p>We would be lying if we did that. Electron was never, ever a good solution. It was something solely used by devs who prioritized their own ease of work over the actual user experience, i.e. bad devs.
I never thought election was a good solution for the problems of its time. Just call it a web app and don't lie to people releasing something "native" for them to download.
Discord actually launched as a web app, and then moved to adding a desktop app, which has quite obviously become far more popular than visiting discordapp.com and using it in the browser.<p>Why do you think that is?<p>I'll give you a hint: if I close my web browser, how do I get a notification that I got a new message? Make sure you also pretend it's 2015 (launch year of Discord) and that I might be using Firefox, Safari, or Edge.<p>The funny part about this complaint is that you can literally just use the web app if you hate the desktop Electron app so much. That's one of the main benefits of Electron!
Noone is claiming that, though.<p>Discord isn't packaged as an Electron app simply because it pretends to be native, but because it has an entire system integration layer that isn't available in the web version.
It was never a good solution and there is no reason to ever stop calling a turd a turd.
> Electron's value prop<p>"Now you can have the cross-platform compatibility of a single-page application just by bundling Chrome."
> The article does nothing to address that.<p>I dunno if you've been living under an enormous rock, but they used AI to make this.
Electron is pretty awesome in that it allows a small team to build a decent GUI app using their existing web skillset but it also feels like it's time for something better at this point.<p>With the ram prices as crazy as they are. It's pretty frustrating to have to run multiple GB eating applications just to do some basic tasks (90% is read and write messages, in the case of Discord). I understand that other people might use the more advanced features (voice chat, etc) but these could be loaded on-demand.<p>It's a bit crazy to me that I can comfortable run an entire Linux stack (+ Podman, monitoring, alerting and multiple services) in 512 MB ram (with 40% free, just checked!). However my Windows PC needs 5.5GB just to show the desktop! Realistically it needs somewhere between 8GB and 16GB for some basic web browsing and even then it can feel slow if you have a few apps like Discord running in the background.
Discord isn't really the model to follow here, IMO. They killed their native Android app and moved to React Native, and now they're dropping React Native (while mobile somehow keeps "native UI", according to their CTO's tweet). If they wanted to maximize code reuse and accelerate feature development, they should have instead considered Kotlin Multiplatform, then they could've skipped the React Native detour while actually building apps that are native to the platform. (Rust and its cacophony of UI frameworks are not really platform-native anywhere, as far as I'm aware. Maybe Pop OS, but I don't know anyone targeting that specifically.)<p>This bit is obviously subjective, but Rust as a language is simply not ergonomic enough for a lot of the use cases people are trying to apply it to, especially UI development. Most of the Rust UI libraries I've seen to date either use a more imperative style, or attempt to replicate more declarative approaches like Compose UI or SwiftUI, but without the nice language aesthetics that make it simple to read and write. And if the counter-argument there is for LLMs to be reading and writing this stuff, that's a whole other can of worms: (1) The subsidized inference era is quickly coming to an end and (2) if you're using LLMs anyway, why not maintain apps that are as native to each platform as possible?
I don't understand this idiocracy - it's super easy (I did myself alone many times) to have a single codebase in Qt for all OSes, even BSDs.<p>I think people become super lazy... "Ah, it's will ocupie a few hundreds of RAM, no problem, let's ship it."<p>They are companies with billions or even trillions shipping shit with Electron.
This is definitely true. It seems to be the modern approach that the less effort in development, the better!<p>I too had code that worked across 3 platforms with wxwidgets and a 3D game toolkit incorporated in opengl for visualisation, with most 2d controls being drawn using wxwidgets OnPaint handlers for custom controls rendered natively on that platform. I wrote this single-handedly, with another colleague handling the network code and firmware on the remote hardware devices.<p>Everything else is sheer laziness as far as I am concerned. There's even less excuse today with the rise of LLMs to do the majority of UI coding for you.
Not a front end developer but I’ve always assumed it was ROI - nobody felt a smaller memory footprint would drive enough incremental revenue to offset the costs, compared to the other things they could be doing.<p>What seems to have changed is the size of the costs - LLMs are really good at this - such that you can now say <i>“well, maybe the returns aren’t that big, in fact maybe they’re zero, but this is easy enough, so why not”</i><p>De minimus improvement has always suffered this problem - we’re all fairly sure it’s worth <i>something</i>. Maybe there’s even real perceptible value when you fix the whole basket. But making the case is hard.
> single codebase in Qt<p>Not if your promary UI is web.
We have gotten so used to slow app startup these days I believe. I have recently started using Task Slinger [1] and every single time I boot it, I get a feeling that it was already running and it's window just showed up. I wish all modern software were like this.<p>[1]: <a href="https://taskslinger.net/" rel="nofollow">https://taskslinger.net/</a>
The old System Shock 2 is an inspiration for my own loading times. Launching the game instantly shows the main menu with your last save paused in the background. Clicking Play actually unpauses the game. There's no loading time and no <i>process</i> as far as a player is concerned.
All modern apps are like this. It's Electron apps which are all legacy.
I've rarely liked any Electron apps, both for the performance and because it seems to encourage a feeling of bloatedness, for want of a better word. Tried VS Code, but dropped it when they started putting too much AI in it and too much complexity. Sublime is so much better.<p>I don't know...there seems to be something unpleasant about all Electron apps.
One nice thing about Électron is that it supports accessbility and non-english IMEs correctly, and thus all Electron apps have decent accessibility out of the box, comparable to web apps.<p>Most Rust GUI toolkits, at least in 2025, did not have that good accessibility or IME: <a href="https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-gui-libraries.html" rel="nofollow">https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-...</a><p>Hopefully this has gotten better and the new discord client isn't worse in that regard.
GPUI has a single-paragraph accessibility section in their guide that defers to AccessKit[1] for everything, and points to a raw RS file for more info.[2]<p>I haven’t tested it or written anything using GPUI, but I’d expect it to be considerably harder work, based on the maturity of the web stack in this area. My assumptions have definitely been proven wrong before though… Anyone from Discord working on accessibility want to chime in?<p>[1] <a href="https://accesskit.dev/" rel="nofollow">https://accesskit.dev/</a><p>[2] <a href="https://github.com/zed-industries/zed/blob/main/crates/gpui/src/_accessibility.rs" rel="nofollow">https://github.com/zed-industries/zed/blob/main/crates/gpui/...</a>
I'm 100% on this since Electron is probably the worst thing that happened to the desktop development.<p>Hiwever, I'd like to hijack this front page article to for a related concern/question I've got.<p>It seems that all (popular) opensource LLM harnesses are either in JS or python (pi, hermes, opencode, paseo). The same seems to be true for closed source harnesses that I have used (deepseek, chatgpt).<p>I'd really like to ask why? I mean why somebody would use technologies like JS or python to implement a harness application instead of golang or rust or even C? I understand that before 1 year JS or python would be tempting but right now? Especially the LLm related companies have unlimited tokens and re-writing the harness software to golang or rust should be trivial.<p>This would benefit so many people (especiall considering the prices and scarcity of RAM these days).<p>So, why nobody does it? This is an honest question, I don't want to offend interpreted languages but it should be a <i>universal</i> truth that a compiled language is faster and consumes less ram.
One good reason: extensibility. Pi is extremely malleable in ways that would probably be harder to achieve if it were in, say, Rust.<p>The resource usage of my harness is nothing compared to an electron app, and being able to easily customize it is more important to me than saving a few extra MB of ram.
Because most of the recent improvements on correctness and 'memory' are from harnesses, my guess is that you want to iterate and test quickly on the software that seems to improve the most and differentiate your brand best. Once a harness is 'complete' (which might happen for specific harnesses, but probably never for code), the team might start to optimise it with compiled languages.
One possible reasons is that all of those are compiled languages vs interpreted. It doesn’t sound like much but compiling your code for three plus platforms and distributing binaries adds just enough complexity and friction to make it feel a lot more difficult.
I agree with that yes but consider how many people would benefit. And how easy it should be for them to do the change (and compile). It's just tokens.
But "friction" is the job, and "complexity" is the job. That's why we're developers.
Because the (wall clock) execution speed / performance oft the harness is tiny compared to waiting for the LLM response.
Because it used to cost extraordinarily more money to build for a performance increases almost no one cares about.
Electron has always been about shipping cross-platform apps quickly, at the cost of higher memory usage and potentially worse performance. With or without LLMs, its core value proposition remains the same. LLMs simply amplify the framework’s existing strengths.<p>Raycast, originally a native macOS launcher, recently released v2 using a hybrid architecture. It’s not Electron, but it follows a similar approach to Spotify’s desktop app, using web technologies inside a native shell.<p>The memory usage is still pretty significant. It’s using around 350–450 MB at idle and can sometimes reach 1–2 GB depending on the workload. The upside is that they can now share most of their code across macOS and Windows and evolve beyond being just an app launcher.<p>It’s always been about trade-offs, and LLMs don’t fundamentally change that.
LLMs do change the tradeoff if you can now ship cross platform apps quickly, without electron.<p>GPUI is one example: some of the downsides of electron (UI is not native), but it solves memory and performance side, and shared codebase.<p>Just writing native apps because LLMs makes it cheaper is the other option. Shopify did this after years of react native.
> you can now ship cross platform apps quickly, without electron.<p>The opposite is also true. My argument is that you can also ship Electron apps with more features more quickly with LLMs.<p>You still have a finite token budget. With native apps, you have to split those tokens across multiple platforms, whereas with Electron, you can reuse most of the code.<p>Big companies have been going back and forth between native and cross-platform approaches even before LLMs. They generally have the resources (humans, tokens, compute) that small and medium-sized companies don’t have. So I’d take their rationale with a grain of salt.
I don’t doubt that this will be faster and smaller than the current app, but it’s slightly annoying to me that the new app is getting so much coverage with specific claims about speed and memory usage when it’s not actually feature-complete or released yet.
[delayed]
Is that a whole UI re-write in a native/non-web framework? Because in case that's not, this is still running in a browser, i.e. it stands at 80% or so of the bloat factor of electron, and what makes it faster is possibly (mainly?) that they haven't gotten yet to adding as much stuff as seen on the regular client.<p>Discord is a server-side protocol (the client isn't doing much besides displaying the server-prescribed state), there's very little logic/computation going on on there that should explain a world of difference.
They keep talking about 2 accounts logged in so that's why it's still high. But they've done nothing to defend that claim.<p>Also, pro tip, you can still just use it in browser. I hope that doesn't go away.
I’m disappointed to see the continued proliferation of JavaScript and TypeScript. I cannot fathom why people are using these garbage languages still when we have so much better options and code is essentially free now.
I think the reason why web technologies that are essentially being ported to desktop is not only because they provide cross-platform compatibility (still lacking a standardization on Linux), but they tremendously helped the hustle culture built around the motto of "ship it fast" by providing the fastest iterations and benefiting from already existing cheap pool of web developers, especially via outsourcing/offshoring.<p>Nowadays, AI (LLMs, genAI, call it what you will) has become so cheap to handle more than one codebase, they no longer feel the need for web only approaches.
Related:<p><i>Discord is ditching Electron and its new app uses less RAM</i><p><a href="https://news.ycombinator.com/item?id=50378625">https://news.ycombinator.com/item?id=50378625</a>
The barrier to entry for GPUI might be a bit high for some, but is there really any argument to be made against migrating to Tauri?
With Tauri you have to support multiple web engines. It uses webkitgtk on linux - which has its own set of issues, including being somewhat behind chromium/firefox in terms of stability/security/performance/features...
Tauri's value prop over EGUI and GPUI is that its syntax is familiar to web devs.
was wondering the same thing; my hunch-memory is that Tauri is not as performant on Windows. but that has not been my experience, Tauri seems great
[dead]
On my mac I’ve banned Electron apps, only native ones - Slack on Safari.
Let’s hope we see a new wave of desktop apps rewritten natively, thanks to LLMs. Whether they use Rust with GPUI, C++ with Dear ImGui, or something else entirely, that would be great. Personally, I’m so fed up with bloated UIs. Windows is full of them, and it’s a pity considering how powerful our CPUs are.
> C++ with Dear ImGui<p>it would be absolutely awful<p>compared to chromium, it's really limited, like it's just always a compromise with these<p>we should instead figure out a way to do electron but better and make it easier to do the things you can do with e.g. React with native languages and frameworks
The limitations are a large reason for why they're so resource efficient in the first place.<p>If you just reimplement Electron in a native language then you get... Chrome, which is already written in C++. The majority of RAM usage in Electron applications is from the native parts of Chrome itself and a decent ~40 MiB chunk for the Node.js runtime.
That’s what we’re trying to do with Slint (I work on it): a declarative, reactive UI like React, with the logic in Rust, C++, JS or Python. It needs no browser engine, so it uses a fraction of Electron’s memory.
QtQuick is quite good.
Are you a web dev?
I have had excellent results running a back-end Rust process that communicates with a C# Avalonia front-end via protobufs over named pipes on Windows and Domain Sockets on Linux and MacOS. With C# AOT I’ve been able to create self-contained apps that run incredibly fast despite the ipc between the front end and the rust core. I’m getting full 6 platform coverage too (Win/Linux/macOS on both x64 and arm64).<p>edit: Avalonia is quite mature, with accessibility to boot.
or Rust with things other than GPUI
Crux, lets you use native UI but Rust for business layer: <a href="https://github.com/redbadger/crux" rel="nofollow">https://github.com/redbadger/crux</a>
One thing Electron has over Tauri for Discords case is WebRTC. I tried making an open source alternative using Tauri and got plenty far, then I learned that WebRTC on Linux is not OOTB since its still experimental. Webkit on Linux requires WebkitGTK, so everything under the sun out there that had “webviews” cross-platform cannot do WebRTC ootb.<p>At least now Discord will consume your GPU vram while you game.
It's hard to say "Discord just showed why" before the product is in production and sees actual use. Promising initial statistics, but the transition is based on a lot of assumptions that won't really be proven until mass adoption and the software has seen long-term maintenance.
...exactly, and at some point you want to show inline animations or videos and all sorts of other media, show webpage previews, play audio snippets and all the other things things a webpage can do, and then you're back to either integrating a browser engine or attempt to write one from scratch (the browser engine can of course be provided by the system webview, e.g. what Tauri does).
I’ve programmed inline video players for 25 years. Same with audio and everything else. We had “accelerated” graphics back with winxp and gdi+ and of course OpenGL over ssh with x11. Browser preview pages in most apps are usually snippets of text and maybe an icon or pic. Not rendering a full page.<p>In a way, applications regressed a lot with react native and electron. I get it’s easier to develop but the apps are very bloated and underperforming even on computers with 10-100x more power.
For me the ugliest part of Electron is that it uses client-server model <i>inside</i> a program and includes both a browser and Node.JS. This is so stupid. If you love microservices so much why don't you put every React component in a separate process?<p>Also, browsers contain too much bloat, why do you need support for elements like "hr" or attributes like "cellpadding" in a modern app? Throw away all legacy garbage.<p>Also, immediate mode UIs (like Rust's egui) are even worse garbage than a browser. "Immediate mode" means that on every mouse move a function is run that re-draws whole window from scratch. I tried running PhotoCraft (uses egui) in a VM with no GPU and it felt like playing a game at 3 fps. The CPU is simply unable to redraw whole GUI with acceptable speed. It will be especially bad on 4K and 8K screens.
If LLMs are truly driving the cost of "writing code" down to zero, then we shouldn't need Electron anymore. The whining from developers about how it's soooooo hard to write and maintain N separate native applications is no longer valid. Point an LLM at your existing Electron code base and have it fork off a bunch of native ports of it. LLMs are surprisingly good at matching the functionality of existing software. Keep and maintain the Electron app as an internal reference design (your developers probably only know JavaScript anyway) and "build" all your actual production releases from that.
Just use the website. It's going to be a better experience than the vibecoded Rust approximation for the foreseeable future
So, it has always been a skill issue.
Signal is still dragging Electron, can't have a working FreeBSD port due to dependency hell. Also VSCode.
Hot take, but: love electron. Write once, runs anywhere. The majority of bugs aren't platform specific. Easy to get nice visuals that stay consistent across different OS. Yes, it's not native. I don't care. It's not a painting to be admired. The focus on looks and visuals versus usability and ux is a plague.<p>Yeah, it takes some extra ram. Fork my stuff and rewrite it in rust if you care. I don't. The few hot spots can be fixed by using a lower level language. Is vs code not zippy enough? I certainly haven't noticed the slowness. People keep complaining about unnecessary load as if hardware hasn't progressed since 2004. It's hugely important for things like your OS. A few apps you run twice a month? Who cares.<p>But what about software used by billions, asks a person angry about my electron project used by thousands? How many ages were taken up by the five second startup time when you multiply that by however many users (all this time would be spent curing cancer of course)? Sure, improve performance when needed. For the vast majority of projects it's not needed. The average computer isn't pi zero.
> Yeah, it takes some extra ram. Fork my stuff and rewrite it in rust if you care. I don't.<p>And that, right there, is why people hate apps which use Electron. You are spending <i>my</i> system resources so that <i>you</i> can be lazy and not have to program as much. That's not really acceptable development practice.
I literally just run another browser Window with discord on the web rather than the native app.<p>Discord is probably my least favorite thing to happen to chatting online, but for some reason it's what everyone wants to fucking use.
Discord is my favorite thing to happen to chatting online. It combined everything useful from IRC, Skype and TeamSpeak, in one application and with modern UI, and things we now take for granted like attachments and link embeds. And even 10 years later, there are still no alternatives that aren't just discord but worse.
Discord tab also uses 500-600MB of RAM. This is private resident bytes of the tab excluding browser and its helper processes.
Don't worry I'm sure they'll find a way to make the rust based client crawl too soon enough.<p>Slapping a few million lines of AI generated slop code ought to do it for instance.
On another note, Microsoft Teams and new Outlook use very little amount of memory on paper, because their main windows show up under the Edge name. It’s a Microsoft way of solving the high ram usage problem.
WebView2. Other applications can also use it but it seems like there's less out-of-the-box functionality than Electron
That’s also how Tauri claims to use so little ram.
By being dishonest and misleading?
When they can all share the same Electron implementation instead of individual copies it reduces memory quite a bit. I'm not trying to defend Electron way of development but I can see why they pushed WebView2.
By reusing the system webview? It's what web frameworks should've done.
When has Microsoft not been dishonest and misleading? Being dishonest and misleading has been Microsoft's entire game plan since all the way back into the Bill Gates era.
Rust to death i told them
I would not add alternative accounts to the account switcher, they've used these to coordinate bans ever since the account switcher's inception.
<p><pre><code> Discord’s new Rust client had its friends list loaded before the current Electron app could get past its loading screen, in a 15-second clip that we found on the X account of Discord co-founder and CTO Stanislav Vishnevskiy. The video had 2.3 million views at the time of writing, and Discord employees have confirmed that both apps were launched from a cold start.
</code></pre>
Crazy what passes for journalism these days.
Could they of used servo?
I hope they can do some work on a11y because it's bed. Not as bad as it was but still slow and clunky to use with a screen reader.
Great option for this that lets you use Rust along with real native UI for cross platform: <a href="https://github.com/redbadger/crux" rel="nofollow">https://github.com/redbadger/crux</a>
"cross platform" I just spent 10 minutes trying to figure out what it uses for native on Linux, and whether it supports <i>both</i> Qt and GTK. Turns out the docs don't even mention Windows? "Cross platform" is now just MacOS + iOS + Android + Web? I guess the thought is supposed to be that crux helps you port your app to Windows if you want to... but even the example applications only run on those four platforms.
I've not seen the performance deficits demonstrated in this article. The article also does not discuss the specs.<p>Not to mention Windows is a very heavy slow inefficient and poorly made OS.<p>You don't see these issues generally on Linux or macOS.
[flagged]
[dead]