> Plan 9 front is my daily driver

If emacs, SBCL & Firefox ran on Plan 9, I would see no reason to bother running Linux on hardware. But they don’t, and they probably never will.

Maybe when I retire I’ll have time to work on porting them, but I have a long time until then!

Those are orthogonal problems to plan 9. tl;dr all this runs in vmx(3), though it is still in its infancy and slow as molasses but working good enough to scrape by.

Emacs is a poor fit as it already is an OS. plan 9, an operating system which encourages programs to talk to each other, offers no advantages to a monolithic text editing operating system. You're better off learning sam or acme and learn how they interact with the platform which is where their power comes from. That's how you use plan 9, you work with it, harness it. It's a kind of "be one with the os" zen thing.

SBCL I have no experience with but my guess is all the tooling and libraries are built around a 50 year old operating system. Porting languages isn't that big a deal, we have a buch like ocaml, python, Go, pforth, and maybe hugs/haskell among others. The issues are libraries which assume some unholy assortment of unix/posix/linux/whatever bindings and dependencies. plus we have no c++ because few at bell labs thought much of it even though they spawned it. Tells you something.

Firefox. The big one. The modern web browser is a primitive document viewer from the 90's which borrowed ideas put forth some 25+ years earlier by Ted Nelson and others in the 1960's and demonstrated by Doug Englebert in the MOAD. Now it can run computer code while displaying video, audio, text and images on your already existing computer. In plan 9 we would use separate tools to accomplish these tasks. A web browser would at most need to render html, ccs and handle basic javascript. The more complex stuff like pdf, audio and video should be plumbed to external programs which can be removed or swapped out as needed.

> You're better off learning sam or acme

I beg to differ. Emacs is an excellent text-based operating environment, simply the best, without peer. I’ve used sam & acme, and they don’t compare.

> SBCL I have no experience with but my guess is all the tooling and libraries are built around a 50 year old operating system.

Some of the hairiest bits of Lisp (e.g. the pathname abstraction) are due to the fact that it doesn’t assume Unix.

Regardless, while I would prefer to boot directly into some sort of 21st-century Lisp OS which takes a lot of great ideas from Plan 9, that doesn’t exist; Plan 9 does. And if I ever get the spare time I intend to port Emacs & SBCL. And hope someone else will port Firefox.

> Windows 7 still powers my gaming rig by it most likely will move to Linux because Steam.

There are some kinks to be worked out. I'm seeing the following scenario:

I have Ori and the Blind Forest installed through Steam on Ubuntu 18.04. Attempting to play it through the steam client causes a crash. Navigating to the install directory in a terminal and running the simple command `wine oriDE.exe` runs the game with zero apparent problems.

Of course Steam isn't using the local wine installation, but... still? The game works flawlessly with the absolute bare minimum of effort. What's Steam doing instead?

(I tried watching the startup process in the Steam console, but it appears to be committed to printing only uninformative messages.)

> or poorly designed desktops made by people who obviously don't use them.

Do you mean the design part or the coding part? From my limited experience desktops are made by contributors and volunteers work on whatever affects them the most or some might work on cool stuff. It is what it is, without someone with money hiring a large dev team and foucssing on user tickets it will never change. As a developer I prefer something customizable like KDE where I can fix a crash in an app if I hit it over a Windows like experience where important apps like the screen magnifier had hard coded shortcuts and you could not customize them.

Both. glibc... No. And without boring you with anecdote I can sum it up by saying: Linux DE's feel like cheap Windows XP or OSX knockoffs. What's worse is every DE and their forks have their own duplicate DE companion programs such as explorer and notepad clones. I liken them to a Potemkin village; well polished but once you start looking behind things...

If your complaint is that you dislike clones of Windows and Mac, then the combination of tiling window manager, shell, tmux, and vim/emacs is usable and provides an experience that is completely different from those other operating systems. That didn't go away on Linux. There is also plan9port too.

No, the problem is that people keep reinventing the wheel over and over again, instead of picking one app and improving it so that their efforts are cumulative.

Being able to recompile from source to change hardcoded values isn't actually any better in my opinion. Especially given how much of a pain it can be to get a build environment set up for many projects.

I know, but for me accessibility tools are a must, if needed I will compile, use wine or write my own because i need them. But from my experience (with KDE at least) you can customize every keyboard shortcut with a GUI and I could submit patches for issues I found and fixed. If you use a distribution like Debian or ubuntu then installing the required development libraries and rebuilding a package is simple enough in most cases.

I understand why compiling sucks though and this is why I am considering to use Python for a program I want to make and open source despite the fact I dislike it's syntax.

You might want to look at something like GNOME Builder, which is designed to make it easy to contribute to existing projects and will clone the project and setup the build environment for you.

I'd rather just use software that isn't so inept or controlling as to hardcode values in the first place. Probably why I don't use GNOME.

All software has to hardcode something at some point, this is unavoidable. I don't use GNOME either, but they do make it very easy for newcomers to contribute and to change anything they want. It's open source after all, the control is in the hands of the user.

> It's open source after all, the control is in the hands of the user.

That's true of proprietary software to roughly the same extent: if I don't like how things are I am free to make my own or just not use it.

I don't follow. In my experience setting up a build environment and changing a couple lines of code provides a lot more control (and is a lot easier) than rewriting the whole thing from scratch or ditching it entirely for something else. If your distro's package manager supports source builds then you probably don't even need to use tools like GNOME Builder to make quick modifications.

If you find setting up a build environment to change a few lines of code more reasonable than switching to software that wasn't so boneheaded as to hardcode the value in the first place, then good for you I guess. I personally don't have much patience for it.

There is no need to set up a build environment. GNOME Builder does it for you, for GNOME packages. For other packages, on my distro (Debian) the package manager does it for you. It's 4-5 commands to download dependencies, download source, rebuild and reinstall ANY package. Comparatively, the cost of switching can vary wildly depending on the software and available alternatives.