This calculation does not apply to modern ,"inktank" printers, which are replenished by buying ink bottles and pouring the liquid ink into the reservoir in the printer. They print considerably more than cartridge based inkjets.
I have a completely opposite perspective to you on this. I find the peanuts very poignantly captures the frailities of the human condition in a humorous manner.
Both Billy Bud and Bartleby are very focused on the human drama. If you are more interested in the sea rather, I'd suggest Typee and its follow up Omoo.
There use to be a set of games which were available for SunOS and may be Solaris, including a flight simulator with wired frame graphics, and Sun even had released a book about these games at that time(may be early 1990's).
Are they also covered by these? Anyone remember a flight simulator with wireframe graphics available Unices?
Hello, I am the author of the article. I did not know of those games you mention at the time. We used to play conquer at the AIX (Unix) that our computer labs provided for all the alumni. I have only tracked conquer's authors to obtain their permissions to relicense and preserve in a way that others could study and build upon.
I bought a copy of Aviator by Curt Priem and Bruce Factor, that ran on my SS2 pizzabox's GX "LEGO: Low End Graphics Option" SBus card (an 8 bit color + 2 bits monochrome overlay plane graphics accelerator):
>Bruce Factor and Curtis Priem developed a flight simulator called Aviator for Sun's S-Bus GX graphics accelerator. I had one of them on my SS2, and owned a copy of Aviator on CDROM, and loved to play it. [...]
I feel much of the knowledge and experience in the industry is simply lost because it isn't widely documented and studied. There needs to be detailed histories of major software development projects from the industry, in book form for people to learn from, in the same way as histories of military campaigns and railway projects.
It not widely done, and we end up with mere "Software Archeology", where we have artefacts like code, but the entire human process of why and how it reached that form left unknown.
This is actually one of the things I struggle with the most.
Even small scale apps are mysterious to me, I have no idea how to build, deploy and maintain an app correctly.
For context, I work for a startup as solo dev and I manage 5 projects ranging from mobile to fullstack apps.
I am completely overwhelmed because there basically does not exist any clear answer to this. Some go all in on cloud or managed infra but I am not rich so I'd highly prefer cheap deployment/hosting. Next issue that idk how to fix is scaling the app. I find myself being stuck while building a ton as well, because there are WAY too many attack vectors in web development idk how to properly protect from.
Doesn't help not having any kind of mentor either. Thus far the apps I've built run fine considering I only have like 30-40 users max. But my boss wants to scale and I think itll doom the projects.
I'd wish there were actual standards making web safe without requiring third party infra for auth for example. It should be way easier for people to build web apps in a secure way.
It got to a point of me not wanting to build web stuff anymore because rather than building features I have to think about attack vectors, scaling issues, dependency issues, legacy code. It makes me regret joining the industry tbh.
Agreed. I really appreciate the documentaries by CultRepo and the "Architecture of Open Source Applications" books, but there's still a ton of info that hasn't been documented. Some of the FAANG blog posts also help, but they're usually very scant on details.
I feel that the last added book in one's list seem to have more influence on the recommendations, which results in a rather similar type of recommendations.
This is a result of the use of positional embeddings, which typically results in the final item being weighted very highly. The problem is that this information is shown to be very relevant to the task of predicting the next item interacted with. If you add more books the effect of this is somewhat diluted.
While I still use emacs, I find that that despite the "batteries included" narrative about emacs, the things which are not included are causes of major frustration.
Such essential functionality like grep-find and LSP servers which is required for out of the box auto complete are not bundled with emacs. Most modern IDEs/editors have these functionality baked in.
If you install emacs for windows you find that grep-find doesn't work, because it depends on support from environment. A full text search should be built into the editor.
I don't think lsp servers should be bundled, they're often huge, and e.g. for haskell you need the one that matches your ghc version, so you'd need ..all of them? and they need to be kept up-to-date etc. There is an emacs LSP server package manager at https://github.com/deirn/mason.el though – maybe something like that could be included, and Emacs could suggest how to install an appropriate LSP server (and enable eglot). I know many of the old hackers bristle at this, but I think it should be possible to do some kind of helpful but non-intrusive hinting for new users (one can always `setq clippy nil`)
They could at least change the default theme to one of the already-bundled modus-themes or something.
Once we get a modern IDE like PyCharm or Intellij Idea, the auto complete is essentially built in, without needing to deal with installing LSP servers, clients, and their dependencies.
Out of the box, project and context aware auto complete is an essential feature in a modern IDE.
Last I checked, an IDE like Android Studio (based on IDEA) needs to download a hogshead of java before it can even begin to build anything. And if you switch compiler versions, it needs to download even more. Sure it makes installing java as easy as clicking a few buttons, and it'd be great if Emacs made it as easy, but still: it doesn't bundle every version. No one would have the drive space for that.
And now consider that emacs has support for not just java/kotlin, but pretty much every programming language in existence..
Emacs is not a “modern IDE” and expecting it to be one is a recipe for not only confusion and irritation but also for watering down the goodness that it really is.
I've never used grep-find or LSP, despite using Emacs for 32 years. Maybe I should; is grep-find better than M-x grep?
Apparently I've sometimes improvised an equivalent: "Run grep via find, with user-specified args COMMAND-ARGS. ...
This command uses a special history list for its arguments, so you can easily repeat a find command."
My out-of-the-box autocomplete is M-/, which works in environments where LSP doesn't, like writing English. It works sort of poorly in all of them, but I write production code slowly enough that my typing speed isn't close to being a bottleneck. It's more of a bottleneck when writing English, but even there, generally any of my good writing was good rewriting.
Where I've found LSP-like functionality really useful in the past in IDEA and later Eclipse was not autocomplete, which is mostly an annoyance, but in automated refactoring (extract variable, extract method, inline method) and in rapidly iterating through the implementors of a method whose semantics I'm changing.
That seems reasonable, yeah. ripgrep, etc., are definitely faster.
Somehow I never twigged that you wrote Ardour and JACK. Thanks for JACK! (My audio editing needs are very modest and so I haven't actually tried Ardour.)
I customized grep-find on my setup. I have a shell script so that it does the following (in typescript-mode)
first search ts, tsx, js, jsx files in the current project. Exclude .git, node_modules...
then search node_modules with the ts.. extensions, still exclude .git
finally search the whole tree for .py files still exclude .git, /dist...
This is coupled with consult-find-grep. I basically want to find a string in the most relevant file type. I never want a result from node_modules first in the results. It took some work, but the results are quite nice!
Oh, yeah, I wrote some Emacs Lisp that did that kind of project-specific thing for a Perl project I was working on for a couple of years in 02003 and 02004. One function key would search the whole project for occurrences of the identifier under the cursor, and another one would search for definitions.
And, although that approach does work (and maybe even that script will work without any bug fixes) it probably goes a substantial distance toward showing why fd was written.
Doing the three searches separately and exiting after one succeeds is only slightly more code.
I don't think I've ever heard emacs described as "batteries included" -- maybe more like "batteries available." If anything it has the opposite reputation, that doing anything requires extensive and continual config adjustments, which isn't accurate either.
There are plenty of emacs "starter kits" that do aim to provide more of a batteries included experience. My favorite is doom, it's worth checking out and does setup all the features you mention.
Pointing new users at those more advanced default configs as an option would be pretty helpful, I think.
Tbh even though I got my start with Emacs Live I really do think at this point the simplest way to get started is to start vanilla and stay as vanilla as possible as you slowly build up your config based on simple and straightforward examples. The main problem is the utter lack of such examples in the community. I had to figure it out for myself for the most part. KISS!
Emacs isn’t battery-included. It’s a platform for textual interfaces with a focus on text editing. It may not includes some tools, but if the tools works with text (at least on the standard in/out) hooking it in emacs can be done really quickly. More so if it’s something that:
- have result that can be formatted in a tabular fashion
- do stuff with files then present some diagnostics (especially if errors and warnings are related to the files)
- Have an REPL interface
It’s not preconfigured like VS Code, but it’s much more versatile. Cursor having to fork VSCode is one such example. In Emacs, anything is just another package.
I think the mistake is looking at Emacs as an editor. It's an Emacs Lisp VM, and the editor that comes bundled with it is good, but not great. Fortunately there are many ways to improve it, and make it go beyond what other editors can.
WSL2. While it's a fair criticism, the underlying issue here is that there aren't enough Windows users who program and upstream things for individual users to get support. Lean on the Linux ecosystem and things are fine.
The reason there aren't programmers targeting the large market is a tangent into why I'm building PrizeForge, but the answer now doesn't change.
parent is talking about the external dependencies, grep.exe and java and jdtls etc., and in particular how they need to be installed separately from Emacs
Do other editors and IDEs bundle-in these external language servers? I don't think so, unless they are specifically tied to the language like Eclipse or PyCharm
Emacs in its half-a-century existence afaik never had "batteries included" narrative. Whatever comes bundled in Emacs, either practical or not so much (e.g. tetris) - are recipes and guides for extending it.
Given that was in 2008, I would update his remark from Netbeans, to any of JetBrains products, Eclipse or whatever.
In any case, you can get those features using Windows Resource Toolkit on the old days, a mix of findstr and other similar improvements on Windows NT linage, nowadays Powershell will be enough.
Calling Gosling "the father of Emacs" is pretty inaccurate. What Gosling did was create the first UNIX version of Emacs, and while that predates RMS' GNU Emacs, Emacs was originally a series of macros created by RMS for the TECO editor running on ITS (Emacs originally meant "editor macros"), so RMS is clearly the father of Emacs.
The criticism makes sense when you consider that yeah, while posix tools are okay, needing them everywhere means you have something wrong in your programming ecosystem, and Elisp has many things wrong.
Emacs can easily work with non-posix tools. Many people use ag, ripgrep, or ack in lieu of grep. You change the command string Emacs uses for finding and grepping to your tool of choice.
For most modern programming languages, LSP servers are trivial to install. You can usually get them through your language or distro's package manager in one command line invocation. Considering that there are sometimes multiple servers with their own pros and cons for a language, this can be kinda nice.
The only one I've ran into that is different is Java, but considering how underdeveloped Java LSP servers are, you probably don't want to be using emacs for Java development.
XEmacs only came about because Lucid needed a front end to their IDE, Energize, which was extremely comprehensive and could even do "edit and continue" style development of C++ on Unix but, as jwz has it, the Unix community preferred its stone-knives-and-bearskins approach with command line tools.
Yeah, Solaris and NeXTSTEP were the only UNIXes that had an IDE tooling story from the vendors.
Thanks to its origin, XEmacs also had for several years many graphical capabilities, that if I am not mistaken only landed on main Emacs during the late 2000's, by then I was back into IDE land.
Color emoji was deliberately disabled on macOS (2016): policy first, parity later.
Emacs 25 turned off multicolor fonts on the Cocoa port even though they worked, with a NEWS note saying they’d be re-enabled "once it is also implemented in Emacs on free operating systems." This was widely read as a political parity requirement that penalized macOS users for years.
"Prefer GNU/GNU-Linux" development time: an explicit guideline.
GNU’s own standards advise spending time on features "useful on GNU and GNU/Linux, rather than on supporting other incompatible systems." That guideline has often been cited in Emacs discussions to argue against platform-specific work that would land only on macOS.
macOS-only features face extra process friction, or must be generalized.
The "send-to" (macOS Sharing) patch was finally merged in 2025 -- but only after a lengthy debate and a rework into a cross-platform framework to satisfy GNU policy concerns about adding features that target a non-free OS first. (The end result is good! -- but the path illustrates the extra hurdles for macOS-first work.)
Long-running reliance on mac-specific forks to get a polished UX.
For years, many mac users have depended on Mitsuharu Yamamoto's Emacs Mac port (emacs-mac) or distributions like Aquamacs to get native scrolling, gestures, font/rendering tweaks, and other integrations that either lagged upstream or weren’t accepted. The continued popularity and active maintenance of these forks reflects a gap in first-party mac attention.
Recent high-profile macOS performance pathology highlighted as "non-primary platform" pain.
In 2025, a widely-read analysis ("Emacs: The macOS Bug") traced severe jank/memory growth to how Emacs drives Cocoa’s runloop (e.g., NSApp run usage inside the select/IO path), arguing that historical architecture -- plus macOS not being a primary target -- left deep issues unaddressed for years. Follow-on bug threads on emacs-devel discuss memory fragmentation and event handling. This is more engineering history than politics, but it shows practical consequences of platform de-prioritization.
FSF position on non-free systems frames the culture.
FSF materials repeatedly emphasize using and prioritizing free systems. Even where they explicitly say they didn’t drop support for non-free OSes, the values signal still affects triage, reviews, and what maintainers feel comfortable merging first. This shapes outcomes like color emoji support and the review friction in the "send-to" patch.
2008–2010, the long, bumpy road to a native Mac port:
During Emacs 23’s cycle the old Carbon port was "completely broken ... for almost a year," and was ultimately removed when the new Cocoa/Nextstep port was merged. For years many Mac users relied on forks (Aquamacs, Mitsuharu's "Emacs Mac Port") for a smoother experience, reinforcing the "not a first-class target" vibe.
RMS isn't only against Emacs on Macs and Windows. He also has some strong opinions about UniPress Software, who sold a version of Gosling's Emacs for Gosling's own NeWS window system, Apple Lisa, Mac, MS-DOS, Amiga, Xenix, SGI IRIX, Intergraph, xePIX, Northern Telecom, Cadmus, DEC Rainbow, VMS, VAX BSD, DECWRL Titan, TI Professional, Masscomp, Apollo, HP, Stride, AT&T 3B, System V, Gould, NBI U! ("Nifty Box"), Pyramid, Perkin-Elmer, Cray UniCos, and many other proprietary Unix systems.
>I worked at UniPress on the Emacs display driver for the NeWS window system (the PostScript based window system that James Gosling also wrote), with Mike "Emacs Hacker Boss" Gallaher, who was charge of Emacs development at UniPress. One day during the 80's Mike and I were wandering around an East coast science fiction convention, and ran into RMS, who's a regular fixture at such events.
>Mike said: "Hello, Richard. I heard a rumor that your house burned down. That's terrible! Is it true?"
>RMS replied right back: "Yes, it did. But where you work, you probably heard about it in advance."
>Everybody laughed. It was a joke! Nobody's feelings were hurt. He's a funny guy, quick on his feet!
Wow that's a wall of text proving pretty much nothing, other than that RMS is an out of touch goofball.
As I and others have noted, actually using emacs on a Macintosh is dead easy. MacOS ships with an older terminal version, so you don't even have to download anything if you're fine with that distro. OTOH, multiple native build distributions exist and are a click away.
I spend a good chunk of my day in a native build between text, scripting, and Orgmode, and, again, it's just not a problem. It's far easier, in fact, to use emacs on a Mac than on Windows precisely because MacOS is a unixy environment.
It only proves nothing if you didn't bother reading it (which you words "wall of text" imply) and didn't check any of the links proving what I said. Instead of dismissing everything by handwaving, please tell me which specific points I made that you disagree with, and what is your evidence?
How long have you been using Emacs, yourself? If you just got started a few years ago, then that excuses your ignorance of history (but not your unwillingness to learn), but there is a LOT of well documented history about Emacs on the Mac, and all those links you didn't bother following prove it.
You can't win an argument by being ignorant of history, claiming tl;dr, and refusing to look at the evidence. That's just conceding my points by default. Can you do any better than that?
It feels like this changed roughly in the last five years. That's about how long I've been using Emacs on Mac.
I'd mostly been using Sublime / Atom / Eclipse / Vim before that (and a long list of other IDEs and editors going back to Turbo Pascal 3.0 on IBM XTs). So perhaps I've not felt the same pain.
I'm glad I can use Emacs at work (on Macs) and at home (on Linux). The funny thing is it's been easier to get Emacs up and running on Mac than on Linux. To get the latest stable Emacs I had to pull the source and build it myself (Ubuntu repos had old versions). On Mac it was just finding the right cask in Homebrew.
The point is that you came in here with a pasted wall of text with a whole bunch of urls claiming emacs users on MacOS are somehow 3rd class citizens because ... of things from long ago, I guess.
My point, Don, is that these long-ago issues are now irrelevant. Your position here runs utterly counter to the lived experience of Mac emacs users.
I don't care what RMS did in 2005. It's not relevant to using emacs on a Mac in 2025.
I don't even need to care about the history of emacs on the Mac, or whatever other ill-advised chicanery the FSF has committed on this or any other point (and, not to put too fine a point on it, but at 55 I've seen plenty of goofy own-goals from that crowd).
What matters now is "gee, how easy is it for a Mac user to access and use emacs productively?" That answer, for at least the last 8 to 10 years (which is also the answer to your gatekeepy question), has been "very!" You open terminal and type "emacs," or you download a build that runs as a gui from any of several maintainers. You're done.
It's about as simple as it is to run it on a Linux box (which I also do), and far simpler than getting it to behave under Windows (and I have those scars, too).
My thoughts too. I've never had any real problems running it on Windows myself, but it doesn't feel like Mac users are any worse off.
I've been using Mac Emacs since about 2010, so perhaps I dodged some of the worst stuff, and it's always felt - for good or for ill - very much the same as using it on Windows or Linux/X-Windows, both of which I've been using since 2005 or so.
I've always used the standard GNU version rather than any specific Mac port. Over the years I'll have done some mix of downloading prebuilt binaries, building it from source, or getting the MacPorts version.
Perhaps I have missed out on some Fancy Extra Mac Stuff, the sort of thing that would come as standard with any project that took the platform seriously, but it's never really felt like a problem. And indeed, I figure if I'm happy enough with it running on X-Windows and on Windows, why wouldn't I be just as happy with exactly the same thing on macOS too? A consistent (or near enough) cross-platform experience is part of why I use Emacs anyway.
This isn't much of an argument, Don. Just being condescending may be charming somewhere else, but here it just looks like you're being a jerk -- and a jerk without much that's relevant to add to the conversation.
Do you really believe that RMS has suddenly done a 180 and changed his core beliefs and philosophy about Apple and Macs and non-free operating systems?
Do you even know him, have you ever talked with him about free software or copyleft, have you ever even read anything he's written? Are you brand new to this whole "free software" thing, and it's a total shock to you that RMS has a long standing opinion about supporting Macs and other non-free operating systems?
It's obvious you haven't read any of the links to evidence I posted, or even anything RMS has written about the subject, but you really should do some research before jumping to such historically uninformed conclusions.
Parading your self cultivated ignorance and unwillingness to read, enumerating things you don't care about, and refusing to indicate what I wrote that you disagree with or provide any evidence to the contrary after I asked you to, just isn't a good look, and won't win any arguments that I have nothing to add to the conversation.
One more time: what evidence I gave do you disagree with, and what evidence do you have than RMS has done a 180 and abandoned his long held principles? Do you even know what those principles are?
RMS is functionally irrelevant to the experience of someone on a Mac who wants to use emacs, because -- Again! -- all you have to do is download a build and you're off to the races.
That's the end of the discussion. It doesn't matter what RMS' position is. (And yes, I know what those are -- and no, I've never spoken to him, because I tend to avoid creeps.)
emacs is free software that, once released to the world, will find its way into many places perhaps its most famous proponent would prefer it not. And this happens because his opinion is irrelevant. This has happened before. This will happen again. RMS being a sad puppy about Macs and Windows doesn't change the fact that many, many folks have productive emacs-centered computing experiences on those platforms. He can die mad about it.
You posted a shitton of material, but none of it addressed the simple fact that using emacs on a Mac is approximately as easy as using it on (e.g.) Debian. There's no real difference for most use cases.
I'm not in the habit of taking homework from gish-galloping boomers hell bent on missing the point, so I'm not going to answer any of your questions. I will, however, note that I'm far from the only person in this thread looking at you and thinking "what the hell is this guy on about?"
Your litany of butthurt actually bolsters my opinion of the bozos at emacs-devel, who I've long criticized for hypocritically advancing emacs on proprietary os's despite their ostensible mission to destroy them.
You seem to think there is only one version of Emacs, and that its entire monolithic developer community is totally unified in its opinion and philosophy and mission, so you can accuse the entire community of being hypocritical if there is any dissent or diversity or competition.
I just wrote a long list of proprietary operating systems one version of Emacs ran on, and even linked to the source code proving it, which RMS opposes so vehemently that he calls it "Software Hoarder Emacs", and jokingly accuses its developers of burning his house down.
If you really think RMS's mission to destroy all non-free operating systems is "ostensible", you definitely don't know him or his reputation.
>ostensible /ɒˈstɛn(t)sɪbl/ adjective: stated or appearing to be true, but not necessarily so.
You're overcomplicating this. If RMS and his lackeys were so hellbent on ridding prop OS's from the world, they could move marginally closer to that goal by simply deleting w32* ns* and android* from GNU Emacs. That they instead collectively spend several man-months per year stressing about their upkeep means they care more about expanding their userbase than any bullshit notion of "freedom."
I've got another one for macOS. It's not as significant as what you listed, but it was extremely annoying for me.
When using homebrew, the default package for emacs is version 30. However, that version on macOS was compiled with an outdated tree-sitter version (v14). If one tries to install a tree-sitter parser for a particular language it will not work with emacs 29 or 30 on macOS (or at least not that I could figure out). I tried the D12Frosted version and some of the alternatives for macOS (I forget the names).
The current tree-sitter project is on v15+, so in order for it to work, one has to go through the commit histories for each language and find when the tree sitter's parser version was last compatible with v14. To my knowledge, this was not clearly listed in all the git commits in a nice clean manner.
One alleged workaround was to install everything via RedHat OS and move the installed parsers over to macOS since their version of emacs and the tree-sitter parsers are still compatible. However, I was not interested in doing this.
Interestingly enough, Neovim does not have this issue on macOS to my knowledge, but I could be wrong.
Now, this is not entirely an emacs issue, but it does introduce an interesting issue. If emacs has to be compiled with a particular tree-sitter version, then it makes things quite difficult to maintain. The maintainers apparently are discussing various options on how to handle this going forward, but there isn't a clear way to work around this.
Now, I do believe if one builds emacs from source, he or she can work around this issue to some degree, but I was also not interesting in doing this because one loses out on some of the nice features that the macOS focused emacs versions come with. I also did not want to install all the dependencies required to build from source since those dependencies are not something I have any other use for other than building emacs.
So, I just gave up on the tree-sitter. Though, I think emacs 31 has this fixed until it happens again, but I also encountered a lot of other bugs when trying other use it since it's a prerelease version anyway.
This was all months ago, so maybe things have changed. I haven't kept up. I can live without tree-sitter for the time being.
"Czech conservation authorities praised the beavers for their unexpected yet effective environmental work. Bohumil Fišer, head of the Brdy Protected Landscape Area, stated that the beavers "built the dams without any project documentation and for free", and achieved the desired ecological outcomes "practically overnight"."
reply