Does Linux have an Amiga feel?

[vidarh]

If you want an OS to actually do stuff, you know productive stuff like video editing and music production you're looking at Mac or Windows.

So "actually do stuff" == "productive stuff like video editing and music production"? That's a ridiculously limited view. I've made my living for the last 17 years "actually doing stuff" almost exclusively on Linux machines. No, I don't do video editing or music production.

Put me in front of a Windows machine, and it feels like you've chopped off my hands. OS X is better, but for my needs I'd still rather have a recent version of Ubuntu any day.

[vidarh]

But for $30 i upgraded an old XP Tablet PC laptop to Windows 8 and it wipes the floor with previous Ubuntu 9.10 in terms of performance, installation time and 100% working hardware and a gazillion quality software options that a double click of the Install icon will achieve.

It is a bit ridiculous to compare the newest Windows with a 4 year old completely outdated version of Ubuntu.

[vidarh]

Windows has a better shell than Linux.
 
http://en.wikipedia.org/wiki/Windows_PowerShell

You can get object oriented shells for Unix-y OS's too. Nobody tends to use them because they are generally way too verbose to be worth it compared to the standard shells, so "better" is definitively debatable.

Notice how PowerShell syntax has gradually moved towards the brevity of Unix/Linux shells over time..

[vidarh]

unfair or incongruous yes, but ridiculous? Probably not.  But in reality 12's not gonna do much more for you than 9.  Same legacy driver challenges will be there, or settling for NdiSwrapper madness. For me family time is more important now. Maybe when I retire. It's a good OS for Octogenarians, nice and steady and smells like moth balls. Will go nicely with my beige cardigan with the vinyl elbow patches.

My experience with 12 is that I've had some problems with one obscure Chinese scanner, but on the other hand Ubuntu supports my printers right out of the box, while Windows requires a 250MB download to get one of them set up.

Drivers was a big deal 5-10 years ago, or if you pick up no-name unknown hardware from China or something released in the last week without checking if it's compatible first.

Other than that, driver support is often *better* than Windows these days, especially for older hardware.

[vidarh]

All linux versions are outdated, they all feel like a 70's OS compared to any AmigaOS flavour

Frankly, while there are still lots of things I love with AmigaOS and miss in Linux, this is a downright ridiculous statement to make. It takes a *huge* amount of tweaks to AmigaOS to get a system that is anywhere near as usable as most modern Linux distro's, and you'll still have huge holes.

Already in '89 or so while using AmigaOS extensively, my system was tweaked beyond recognition to get to the experience I enjoyed, and it was still in most ways substantially inferior to most modern Linux distros.

Invest the same effort in tweaking a Linux distribution now, and you end up with something vastly more polished. And if you like you could end up with something substantially closer to an Amiga experience.

Sure, there are still things modern mainstream OS's lack, or are just "reinventing" now (the parallel between workspaces and increasing use of fullscreen apps to screens for example, is quite amusing and satisfying; and Ubuntu's switch to a global menu bar likewise), but the pale in comparison to the features that are lacking, such as proper memory protection and full support for virtualization (I have a dozen or so lightweight virtual machines running on my home machine) or full fledged package management.

I'd love to be able to use a more Amiga-ish OS as my main OS, but before that can happen, either AROS or AmigaOS would need to take a lot *more* stuff from Unix/Linux, or more Amiga-like features would need to be ported to Linux; there's no way I'd be able to go give up all the things I've come to expect in an OS after using Linux.

(I say *more* stuff would need to be taken from Unix/Linux, because already with the first handful of Fish disks in the 80's we were getting a steady stream of Unix ports)

[vidarh]

Pretty much the same thing, actually. It IS open source, but they're still tied to legacy stuff for the GUI like X Windows, which goes back to 1984.

That is a rather comical complaint to see on an Amiga forum... It is also inaccurate at best - pretty much no modern X client software is able to run on an X server from 1984, or even from 2000 - there's very little in X of today that has much to do with X of 1984 other than the core protocol.

 All the things you complain about (i.e. user interface stuff) run in user mode and have to go through that arcane monstrosity to do anything.

That "knowledge" is more than a decade out of date. In this paper from *2001*, Keith Packard on the XFree86 Core Team outlined a redesign of X that introduced the XRENDER extension:
http://keithp.com/~keithp/talks/usenix2001/xrender/

As it happens, the X11 protocol is very simple. The complexity was in implementing the drawing model with good performance, which by 2001 was quite outdated. Incidentally much the same drawing model that AmigaOS provided, where the OS is called to draw primitives like rectangles etc., but with the added cost and complexity of doing it over a socket that could potentially be on the other end of a network and so needed to also carry things like all fonts etc.

XRENDER instead let the client render directly into buffers that is then composited. Combined with two shared memory (supported by virtually all X servers since long before XRENDER) and DRI where the client now pretty much renders directly into buffers that can be composited straight to the display buffer using hardware acceleration. All of the complexity of serializing resources over the socket, and of having the server keep up with whatever support the client would like to have to efficiently render went away.

Post XRENDER, and subsequent rounds of updates, pretty much no Linux + X setups have "gone through" any "arcane monstrosity" to do much of anything - X is largely used to negotiate the options that both client and server supports, and unless the client is ancient (pre 2001 or so), the result will be a much simplified stack. If the client *is* ancient, then the old rendering commands might end up getting used, but we're talking a few hundred KB of code at most to support those commands, and pretty much nobody runs that code (just like not much code targeting AmigaOS uses plain Intuition gadgets any more)

Compared to e.g. Windows, the legacy junk carried around for GUI's on most Linux systems is tiny.

Though X of today is vastly cleaner than "old X", these changes are some of the main drivers behind "Wayland" and "Mir" the two next generation display servers for Linux set to replace X entirely (you can run X on top of them, but most regular users rarely will, as the main toolkits are getting direct supports for them): There's not all that much left of X that is actually needed in a modern system, so creating display servers free of legacy stuff and layering X on top as an optional component has become "easy" and attractive as a way of cleaning up the systems further.

[vidarh]

So if you are running some software natively, you can customise its look and feel, but then if you run something remotely it will run according to the settings on the remote machine. What you get is the Window Manager running locally (the X Server end), and the GUI toolkit running at the other end of the connection (the X Client end). So bye bye any hope of visual consistency, and you can forget accessibility (which nobody thought of until years later). X Windows doesn't know anything about what your on screen widgets actually do.

This is inaccurate. The window manager can, and usually *does*, run exactly where your other client software runs. It is extremely rare to run the window manager tied to the X server - that most commonly happens on "second class" X environments like rootless servers Windows or similar. And the X server has very minimal control over the visuals of the clients (if it behaves according to spec anyway).

It is in any case moot, as other than really advanced users, most users will tend to run the X server, window manager and clients on the same machine, under control of a desktop environment that controls the settings.

And in anything resembling a "modern" X based stack, X acts as a resource arbitration and compositing mechanism and the desktop environment running on top takes care of the rest - you're attacking X as if it's the whole stack, when in reality, almost no Linux desktop has been "just X + window manager" for a decade or more.

This means your application has no control whatsoever over where your window goes. You just have faith that the window manager knows what to do with it. Which isn't usually a problem. But it means it's impossible to do "nested windows" in client areas like Windows NT has.

Thank heavens.  There's a *reason* why most people who have experienced it hates that with a passion.

It'd not be difficult at all to create an X extension to allow X window managers to reparent lower level windows on request of the clients, but thankfully very few people would be insane enough to try.

X has instead different workspaces to keep your windows separate and grouped, so your WM typically just opens every new window on whatever workspace you're currently on. (There is a feature in the protocol to set a window's group ID but it doesn't have any defined purpose or consequences so nobody uses it.)

I think you have cause and effect backwards here. There are tools to do this, but they're largely not very user friendly because most users don't use workspaces much - it's an "advanced user" feature that is rarely enough requested that there's not been much push to simplify it.

As much as I love screens on the Amiga, it's also pretty clear that until recently "regular users" haven't been very understanding of why this would be a good idea, and the tools that do exist are good enough for advanced users.

 This is a bit like the Amiga's method of using multiple screens, except in X you can't make your own workspace and put your own windows in it. You just get four* of them. And that's it.

Of course you can make your own. Generally *applications* won't do that as it's not considered the applications place to do it, and there's no *standardized* API across window managers to do it as far as I know, and that's one thing I do miss from the Amiga. But adding more workspaces is a couple of button presses away on most Linux distro's.

[vidarh]

I don't know who "they" refers to in this case. I'm not aware of anyone touting "Linux" as a user-friendly desktop OS.

As the old quip goes: "Unix is user friendly. It is just picky about who its friends are". Same with Linux on the desktop. My current Ubuntu setup is for me the most user friendly OS I've had. It's by no means perfect, but it's still a great step in the right direction.

It's not by coincidence that it's also the closest any mainstream OS has gotten to an "AmigaOS feel". Including a global menu (of course OS X has had that for ages), and good support for running apps in full screen modes that feels sort of like screens.

[vidarh]

And THAT is why amiga next gen machines are just novelties at this point.

But I still HOPE... :pint:

The problem is attracting developers to plug all those holes... For my part I contributed some console improvement for AROS two years ago or so, but I just haven't had time since, and that's still lagging behind and that's just one tiny area. Hoping to finally do some hacking again, and now I at least have AROS running side by side with X so even if AROS is insufficient for me as a main OS, I'm only a keypress away, and I'm hoping that'll give me an incentive to try to fix some of the things keeping me from spending more time on it.

I think running AROS "on the side" like that, plus things like AEROS with support for spawning Linux apps from AROS or vice versa, is the only viable way for quite some time. Of course there'll be some people that can do just fine with what is available, but meanwhile hybrid approaches offers some way of spending more time in Amiga-like environments than we otherwise would (I have my Minimig and intend to get a FPGA Replay board etc. too, and when finances improve I still want an X1000, but having to switch machines still creates a much bigger  barrier to regular usage)

[vidarh]

It's irrelevant whether they are unpopular on Unix-y OS or whether you think they are also taking features from Unixy shells.
 
To me it sounds like Microsoft are the first to produce a shell that has the best bits from all the different shells out there and are pushing to make it the default shell on windows. How is that not a good thing?

It can't possibly be worse than their old shell, and it certainly is an *improvement*, but to a large extent they have missed the point. There's been *numerous* attempts of doing similar shells with types streams and rich meta-data embedded on the Unix side, and all of them have stranded on a few very important things:

 * Simplicity. The Unix shells are successful because you can whip up trivial scripts down to "one liners" that can parse and produce data that can be pipelined trivially with other applications. Whenever typed streams have been tried so far, it's failed over this.

 * Power of the combined ecosystem: A Unix shell is only a tiny part of the package. The bigger deal is the dozens of Unix commands with several decades of history that people know how to interact with. And not specialised tools like large applications, but fundamental composable components that acts as "power multipliers". There are probably hundreds of "standard" invocations of sets of Unix utilities that I use regularly yet don't bother to script because they are short and simple. E.g. "uniq -c | sort -n" to count the number of unique input strings and sort them by number of occurrences; prefix "grep" to get the number of occurrences of strings matching (or not matching) a specific pattern. And so on.

The experience from that is 40 years worth of experience about what manipulation people need to do manually often, and a toolchain that behaves accordingly, and even more importantly: A toolchain where the basic subset is available "everywhere", ranging from my Android phone, to my OS X box at work, to my home Linux laptop, to my home server, to the hundred+ work VM's, to super computers, to my WDTV set-top box, to the router my cable TV provider sent me... to, infact, Windows if you install Cygwin or alternatives.

If people don't need to do manually, it doesn't need to be done from a shell, and so while much of the PowerShell functionality might be neat in a scripting language, it is then no better off than the dozens of object oriented languages out there.

 * Failing to distinguish between the terminal application and the shell. In the Windows world this is frequent. In the Unix world, like on the Amiga, a shell and a terminal/console are two different things, provided by different pieces of code. One can be exchanged without exchanging the other. Unix users frequently switch shells because we want different command line handling or scripting, for example, while we may switch terminal apps because we want different window handling.

For most Unix/Linux users, the shell *must, must, must* be available "everywhere" - I access shells on about ~20 different machines, and 100+ VM's. I don't want to have to deal with different shells on remote machines than on my local machine, for example, so I want

If I want to be able to pass structured data between scripts, I output and consume JSON or similar, or I simply dip into "pry" - a Ruby "shell" and/or write scripts in Ruby or whatever other language is suitable for the specific problem.

Most dynamic languages have their own alternative to "pry" (Pry, like Ruby in general, steals a lot of ideas from LISP and SmallTalk, that took this to the extreme much more so than PowerShell even). But structured data bring with them different tradeoffs and complexities, and almost always ends up being more verbose because they need to support wider functionality (though people have tried to emulate Unix shell syntax in Ruby too, just like Microsoft have tried with recent versions of PowerShell).

The irony is that Windows is that OS.

Eww.. No, it really isn't. Whenever I have to use a Windows box, I am quickly reminded at how much I detest it and feel tied up and limited by the OS instead of empowered by what functionality it makes available to me, and you can still see the heritage of the abominations that were earlier versions of Windows. They can't make Windows into what I described without ripping out large parts of what makes it Windows.

[vidarh]

The core protocol is kind of significant though.

From the Wayland FAQ:


http://wayland.freedesktop.org/faq.html#heading_toc_j_6

Well, yes, and no. They are confusing two issues for simplicity:

To be an *X server* you need to implement a ton of functionality, yet nothing that can't be implemented in a couple of hundred KB of executable, which is a rounding error in a modern system, and it is code that is already written. Most of this functionality can be implemented using libraries that are going to be on any Linux system anyway, so the impact is even smaller.

To speak the *X protocol* you can get away with implementing the core protocol, and just supporting the calls that are spoken by modern clients and return errors for everything else. This would break stuff like "xeyes" and old xterm and other decade+ old X software. I've written an implementation of the core protocol, and it's easily doable in a couple of days.

Much of the motivation for Wayland is exactly that modern clients use only this little subset of X, and so while they could just ditch the rest from the X server, call it X12 and be done with it, because the subset is so small and the two dominant GUI toolkits on Linux (Qt and GTK) both support different rendering backends (GTK can even render to HTML+JS so you can spin up a web browser and get to your applications that way - don't know about Qt), there's a golden opportunity for a clean slate.

So it's not so much that the core X protocol and the subset of calls that must be supported for modern clients is so bad, but that once you ditch the goal of being a fully compliant X server, what is left is so compact that there is little reason to be an X server at all vs. throwing out the legacy and taking the best pieces and lessons from it.

Wayland (and Mir) has become a realistic option (unlike, say, Berlin, Fresco, GGI, DirectFB or Y-Windows - various projects that hoped to unseat X over the last two decades or at least eat substantially into the user base) *because* the interface to X that is actually required has become narrower and narrower, and localised in fewer and fewer places (few client applications use Xlib directly any more, for example - a decade ago that wasn't true).

[vidarh]

I wonder why Android guys decided to choose Linux... any other BSD would have allowed easier upgrading, at least drivers API is more or less standarized.

Google has massive amounts of Linux experience *and* the number of people who know how to work with the Linux kernel is tens or hundreds of times larger than for BSD, for example. That's presumably important for them in order to keep development pace up.

The difference in driver API's is pretty much irrelevant - it's not the driver API's that are tricky, but how to interact with the hardware. Writing Linux drivers is easy enough. The "upgrade problem" does not have anything to do with difficulties updating the kernel.

I also wonder why they decided to choose Java since it devours cpu time and memory, causing battery drain. Everyone is using ARM and Google phases out mobile phones pretty fast anyway (due to not choosing a decent kernel for their OS).

I sort of agree with this question, as I dislike Java, but note that there are MIPS and x86 Android devices too, and Google (or Android - prior to being bought out) might have looked at it as a way of leveraging existing mobile development experience and keep their CPU options open in case they'd end up having to ditch ARM.

The kernel has more or less wide driver support but being monolithic (and not having a proper standard for modular drivers) it's the worst kernel you could choose.The GNU part of the OS is also horrible, unusable outdated 70s style. It's like painting your old car with some modern patterns and claiming it's modern. Some eyecandy won't modernize it, just like some eyecandy suddenly won't modernize Linux 70's design.

That "70's design" is what pretty much the entire internet runs on, for good reason: It works, is well tested, and people know how to deal with it. But that is irrelevant to Android as most Android applications don't see that interface at all, anyway. Google could switch to the Windows kernel or BSD or, hey, even AmigaOS and most Android applications wouldn't even notice.

The Linux underpinnings of Android are great for people who want to hack Android and/or root their devices (I have my home server log in to my phone regularly when it's connected to my wifi to do things like sync files automatically, for example), but it's not particularly visible in any other circumstances.

Android doesn't use a GNU userland (though you can install one) anyway. You might be thinking of POSIX aka "Unix style". The GNU tools are just one of many implementations.

[vidarh]

But Workbench 2.0 came out in 1990, and System 7 came out in 1991. (And if I'm reading up correctly, Linux didn't even get X until XFree86 in 1994, by which time Windows 3.1 was well-established and 95 had been seeing betas released to preview customers since 1993.) There were already well-established lessons in good desktop design in every major corner of the personal-computer market,

Have you actually *used* those systems you compare X to? In '95 I started an ISP. We had Amigas in the office (A3000's with Picasso's - yay), as well as a number of 486's running Linux with X, and one of my co-founders insisted on Windows and installed '95 immediately when it arrived. We also had to support MacOS and Windows 3.x, and a friend of ours frequently brought an OS/2 box over.

X compared just fine with all of them, and tacked on some functionality none of the others had. Very few people at the time with any computer experience would pick Windows over X if they got to spend any time with them side by side.

Sure, there were awful looking X apps, but there were also Windows 3.x style apps around for many years in most companies. Sure X could look awful, but it took about 30 minutes to get FVWM and various tweaks installed, and what mattered a lot to Linux users was that we could tweak it in every way possible - we even got "Amiga-style" screen dragging with Enlightenment a couple of years later. People who got to see what X was capable off were often stunned at the time.

At work we for example quickly got a 120MHz Pentium machine with 128MB RAM that 5 of us would run applications on at the same time, with the display on our 16MB 486's - with X that was trivial, and that functionality was a big deal for a lot of developers.

At university, similarly, I'd run applications on any of the machines available (or more than one at a time) and run my display on the sleek new Silicon Graphics Indy workstations (remember the 3D file manager in Jurassic Park? That's a real, though toy, file managers that shipped with Irix - SGI's Unix), and Windows had nothing in comparison.

What Windows had was applications, not a UI people badly wanted. It did have some features that people wanted to copy - like the start button. But it took on the order of *weeks* before window managers with support for Windows95 style start buttons arrived, and we got FVWM95 for those who wanted an easy way to get a Windows 95 look-alike (hey, there's an AmigaOS lookalike WM too).

System 7 was not something most people wanted to copy much at all. I remember thinking it looked dated and clumsy at the time in terms of UI.

There were certainly flaws in X, and most of them have been fixed in time. But most of what Linux *users* see as flaws in X follows directly from *functionality* (such as network independence) that were actually important *features* at the time. Low latency, for example was pointless - we did not have fast enough internet connections or fast enough machines to start streaming high quality live video on most machines until much later, and so "nobody" would want to ditch network support - which was extensively used - for a lower latency graphics path.

The choice of X also gave us access to a lot of Unix applications that could be easily ported - if a GUI had to be written from scratch, there might have been a GUI for Linux in '94, but with no applications it'd have been useless for several more years.

People did know better in 1991, or if they didn't they should've. Linux could have chosen to build something better.

You are confusing things. Who are "they"? There is not a single group here. A large number of the Linux kernel developers have little interest in Linux on the desktop, so for many of them, a GUI is not priority at all. And even for those who do like Linux on the desktop: The kernel is not the place for it.

The people who are working on GUI's for Linux have always been a separate set (though with some overlap) from the people working on the Linux kernel, or on other aspects of Linux distributions. Many of them have worked on different ideas of what a GUI for Linux *ought* to look like.

We have X today because X is what Linux users adopted.

Unlike Windows or OS X, no single authority gets to choose what we use. The Gnome project, for example, exists because a bunch of people didn't like what the KDE guys were doing, and built their own thing. XFCE exists because those guys didn't like either Gnome or KDE. As it is, there's at least half a dozen different desktop environments that see some degree of use, and hundred plus distributions with their own take on how things should be set up.

Many of these have conflicting goals, because different users wants different things.

What almost all of them have in common is that they don't want Windows or OS X.

 But they don't believe in that over there, they believe that "worse is better"

"Worse is better" simply means that delivering 80% now is better than delivering 100% ten years from now. It isn't excuse for not delivering a good product eventually - it is a reason for not overdesigning a system so that you never ship anything until it's obsolete. More should learn from that, given the number of great projects that turn to vapour because people overreach (I'm as guilty as the next one..)

So instead they just reimplemented the flawed system instead of trying to fix the flaws - which basically sums up the whole project.

Again, who are "they"? Over the last twenty years, there's been probably a dozen or so different groups implementing alternative GUI's for Linux to make them better. Many of them were very interesting, with long lists of advanced features. I've used a few from time to time.

Yet X has continued to prevail until the last year or so. You know why? Because despite all the whining, X has kept providing a good enough foundation for most people that the competing alternatives have not been able to show compelling enough reasons to switch (though some, like DirectFB, have gotten decent levels of usage in various niches), and *have kept improving*. X of today is totally different from X of 1994, or X of 2000, as is the entire Linux desktop stack.

[vidarh]

Linux with its monolithic kernel seems to be the past. It's nowhere as extensible as AmigaOS was in its first day. Any BSD seems much more evolved and advanced than Linux, at least in extensibility.

What part of Linux exactly is it you think is hard to extend?

The rest of the OS (GNU) is not my cup of tea, starting from the lack of coherence between its parts (core and GUI) and all the heterogeneous and badly integrated apps.

The lack of integration we can agree on - it's one of the things I miss from AmigaOS, as I see the same lack of integration on OS X and Windows.

Linux is slow, no matter what you do. Any AmigaOS flavour runs rings in terms of speed.

That's true, if you can run them on the same hardware. AmigaOS also does far less. Your comparison is like saying a Ferrari will outcompete a tank on speed. Of course it does - it has no armour to drag along, nor a heavy cannon, and it's not built to handle terrain. Great, until you're on a battlefield where someone fires shells at you. The problem is very few users and applications are consistently well behaved, unless you spend a lot of time teaching users by making their machine crash when they make mistakes, and selecting applications by rejecting anything that isn't close enough to perfect.

Users overwhelmingly opted for armour over raw speed and elegance back in the 90's.

It's also true that there are certainly aspects of Linux that could be made faster, or at least *more responsive to user input*. OS X and Windows have the same issues where the OS does not do nearly enough to favour user input and. Part of the problem is simply that hardware is "fast enough" to mask most of the effects, and secondly that Linux users and developers, like Windows and OS X users, have grown up expecting that this is what computers are like, and don't know any better.

All the rest of OSes: OSX, Windows, BeOS... are far more integrated, intuitive and usually faster.

I don't know where you get that idea. I use OS X at work. It regularly freezes up for me - I have to reboot at least once a week (vs "never" for my Linux laptop at home). It's slow. It's bloated. Whenever I have to use Windows, I cringe at how horribly it performs on hardware hundreds of times faster than hardware I used to comfortably use Linux on. The only machine I regularly use that performs well runs Ubuntu.

These days Linux sometimes even beat Windows on games performance, which has traditionally been a problem due to generally lagging in 3D driver support.

AmigaOS flavours are already enjoyable out of the box, these are already fast, no need to waste hours tweaking them like Linux.

Are you serious? I spent hundreds of hours tweaking my Amiga systems back in the day, and by modern standards what I ended up with was still primitive compared to what I get out of the box with Linux. I still love Amiga, and the overall feel is still great, but a bare bones AmigaOS system is extremely primitive.

Amigans enjoy tweaking their systems but it's not mandatory at all.

Perhaps not mandatory, but I would be unable to use one productively for more than five minutes without tweaking it.

Android apps suddenly die and leave your phone frozen and you have to reboot it. It's funny because Android devices are the perfect example of Linux: these require incredible high amounts of resources to do stuff that would work much better on AmigaOS. And memory protected or not Android apps crash and slow down your phone so much that you have to reboot it. I have to reboot phones with "memory protection" much more often than I have to reboot AmigaOS flavours just for the simple fact that Linux is coded like memory was infinite and never exhausted.

How often do you think what crashed was the Linux kernel as opposed to the Android framework on top? This is like complaining that application X crashed, so Windows is ****.

My bet is the crash is caused by the higher level frameworks 99.999% of the time, given that I have Linux boxes at work that regularly handle far more crap than any of us throw at our phones for 5+ *years* without crashing (or rebooting) a single time. With the right software you can even upgrade the running kernel without rebooting.

Linux is also not coded like memory is infinite and never exhausted, either. It offers fine grained control. You can choose whether or not to use swap (try that on OS X, and you'll see "fun" stuff happen - I tried recently and soon had the kernel use 100% CPU). You can switch off overcommit (in which case applications will get errors when trying to allocate too much, just like on AmigaOS). And if you don't, and the system runs out of memory, the kernel will kill processes for you to reclaim sufficient memory to ensure the system as a whole can keep running.

Regardless of these settings, the Linux *kernel* will not crash because you run out of memory. It will kill applications if necessary in order to keep as much as possible running, and it is very good at it. It may become unresponsive for ages if there's much swap space and applications are poorly written, but the kernel will survive and the system will pretty much always be able to recover even in the face of the most brutally abusively written application (in terms of memory allocations)

That said, I don't like the default choices (and I don't like them on Windows or OS X either), but the irony is that the reason I don't like them today is that I rarely run into memory limits, and so it is almost always a failure situation when I run out of memory to the extent that I now finally do prefer the Amiga-way of forcing applications to deal with failing memory allocations.

Most of stuff that comes with these OSes that take gigabytes of space is rubbish or are 14 outdated GUIs for a cli tool that got recently updated and crashes and burns.

None of which you *need* if you don't want to. If you don't want a wide selection built in, get a minimal distro and you get one that fits in a few MB. Most Linux users see this as a *feature*: Start the installer, pick the package subsets you want, and have almost every piece of software you want already installed when you're done. But you're not forced to do that. Conversely, I have built Linux installs for embedded devices with 4MB of total storage - it's not hard.

All in all: when Linux crashes and burns you always end up having to edit weird config files located at random paths, instead of having a GUI emergency boot that boots with basic VGA modes and 640x480 I guess it's much more intuitive for these bearded kernel hackers.

This is ca. a decade out of date for most situations. Or you've tried a distro aimed at hardcore users.

I don't even remember where the X config is on my Ubuntu machine, as I've never had a reason to look at it.

If I wanted to run all that GNU apps I would run them on a unix environment (but a more modern one that use microkernel, not a monolithicly obsolete one like Linux).

Monolithic kernels are so 70s...

Which "modern unix environment" is it you have in mind? If you're thinking OS X, think again. While Mach (that OS X's Darwin kernel is based on) did eventually evolve into a microkernel system, the Mach version OS X is based on is not.

You could run it on Hurd. Say Debian/Hurd (Debian is mainly a Linux distro, but they ship experimental versions using a Hurd kernel, as well as a FreeBSD version).

But as it stands, in almost every respect, Linux is the most modern unix environment out there, and most of the "real" Unix versions have pretty much died off as Linux has become pretty much the standard. For good reasons. The only real alternative with an actual Unix license is Solaris and derivatives (OpenSolaris, Illumos, SmartOS), but these are almost exclusively used on servers.

Or, I guess, you could run it on Linux/L4 - a Linux version that runs parts of the Linux kernel on top of the L4 nano-kernel. It's even more buzzwords compliant than a microkernel, and has some intriguing properties. In fact, using Linux to kickstart micro-, nano- and exo-kernel projects is pretty much its own research field these days, because Linux provides a huge array of device drivers and a lot of other useful code (like filesystems), so many microkernel (take it to include nano- and exo-kernels) projects use parts of Linux to bootstrap their systems, and so there's a number of solutions for "wrapping" various parts of the Linux kernel, such as network or filesystem drivers to let them run on foreign kernels, or simply run the entire Linux kernel on top of the research-kernel du jour.

It's also worth considering that while the Linux kernel is monolithic, it is not much more monolithic than AmigaOS is: That is, the entire kernel runs in the same address space, without kernel-threads being protected against each other. But at the same time, you can load and unload kernel models with the same ease as you can load libraries and device drivers on AmigaOS (or most other modern OS's).  It is not monolithic in the "old" sense of a kernel built as a single unit. Linux has done that since the 90's. The core of the Linux kernel - the bits that absolutely must be built into a single unit - is tiny (it'd fit nicely in a later kickstart ROM...).

There are lots of things about the Linux kernel design I don't like, but it is also nothing like a 70's kernel. There are sources for both available - why don't you take a look.

[vidarh]

I don't know what you are talking about here. I have absolutely NEVER heard of client software running through a client-side window manager. How would that even work? Every time you ran software on a different client you'd have to start another window manager on it. And then every window might look and behave differently, which would be insane!

I am running out of the office now, so I can't reply to rest right now, but what you describe is simply not how X window managers work. X Window Managers connect to the X *Server* like another client, and use special commands. Clients connect to the X *Server* as well. Your client doesn't even need to know that a window manager is running.