Does Linux have an Amiga feel?

[ElPolloDiabl]

There is agreement. Linux is the bloated, hard to customise free alternative.

There is one thing, I have never gotten WINE (windows compatibilty) to work. Actually I last downloaded the beta version by accident. Not one of the PC programs I tried worked. Not interested in trying again.

I'm afraid no option is a satisfactory replacement from where OS3.1 left off. There are no paid/full-time programmers to make AmigaOS a lean, snappy, plus optional features, plus modern programs OS. It's a case of 2nd best for the moment.

[Mrs Beanbag]

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.

The core protocol is kind of significant though.

From the Wayland FAQ:

The problem with X is that... it's X.  When you're an X server   there's a tremendous amount of functionality that you must support   to claim to speak the X protocol, yet nobody will ever use this.   For example, core fonts; this is the original font model that was how   your got text on the screen for the many first years of X11.  This   includes code tables, glyph rasterization and caching, XLFDs   (seriously, XLFDs!). Also, the entire core rendering API that lets   you draw stippled lines, polygons, wide arcs and many more   state-of-the-1980s style graphics primitives.  For many things we've   been able to keep the X.org server modern by adding extensions such   as XRandR, XRender and COMPOSITE and to some extent phase out less   useful extensions.  But we can't ever get rid of the core rendering   API and much other complexity that is rarely used in a modern   desktop.

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

[Mrs Beanbag]

Anyway, you can make the argument that Linux was never intended to be a user-friendly desktop OS. Looking at it I'd be inclined to agree with you. (Certainly it's better as a server OS than it is as a desktop OS.) But if that's the case, they certainly shouldn't have promoted it as one.

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. That's what Ubuntu and its variants try to aim for, but that's just the aim of that particular (relatively new) distribution.

Windows aimed for that explicitly in the first case, so things that came so naturally to Linux with its Unix roots, such as the multi-user network based environment, in Windows seems kind of tacked on as an afterthought. Which of course it is. Although they've got it tacked on quite well now. It's nice at the front end but if you're an advanced level user you can tell it's a bit of a mess underneath, which is kind of the polar opposite of Linux. Linux is neat underneath and a mess on the top, which is why it's so good at being a server.

One day someone will make a modern OS that is neat at both ends, that nobody can find anything to complain about, and the Universe will end.

[polyp2000]

One day someone will make a modern OS that is neat at both ends, that nobody can find anything to complain about, and the Universe will end.

Even if someone did - there would still be zealots and those not open to change that would still claim their OS du jour is superior for a bunch of reasons that will change depending on the context. We all have reasons for our choices and mine are based on what i feel comfortable with and what my needs are.

Somewhere in this thread someone noted that Android was "well regarded" yet later on claimed that Linux was no good due to various desktop / user interface issues. On one hand accepting that Linux is just a kernel and on the other citing Linux is both kernel and userland stuff - depending on which argument it serves most best at the time. Its hard to take those kind of arguments seriously. Someone else was complaining about the size of the source code but conveniently forgot that that source code supports a huge range of architectures and hardware configurations and bears no reflection on the size of a kernel.

This thread has turned into a real flame bait situation and i think its about time it was put to bed as the discussion is going no-where.

Whatever your operating system preference is - be happy that you have found something that suits your needs. Its ok to see the negative side of things but never forget that your own preference probably has its negatives to someone else. And most of all be happy!

[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.

[Crumb]

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. 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).

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.

[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.

[Mrs Beanbag]

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.

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!

Granted in normal desktop use the server and client are the same machine, but philosophically it's still unpleasant, and it means maintaining two different sets of settings. Having some other program on top that abstracts that process for you might make it seem neat and tidy, but it isn't.

And the X server has very minimal control over the visuals of the clients (if it behaves according to spec anyway).

That's precisely the problem. I note you didn't answer my points regarding accessibility.

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.

I know this. Well let me bring another player onto the field as well if you want, wow a third completely independent set of settings, great.

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

Um no, there's a *reason* why most people who have experienced the GIMP hates it with a passion, it's because it opens several windows and they spill out all over the place, not being grouped together in any way. The usual answer from the Linux crown - that's what workspaces are for. Pretty much every Windows application I've ever used uses client areas to good effect. I have not heard anyone complain about it. Likewise everyone breathed a sigh of relief when it became normal for web browsers to have tabs, which is almost the same thing only more limited.

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.

Oh I know, I am that insane and I did it with Fluxbox, well I made it so I could nest the windows manually, creating an X extension is rather pointless without applications that use it. I suppose there aren't many people as insane as me, though.

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.

Precisely my point. If you want another workspace you have to make it yourself. "A couple of button presses away" is really "changing your window manager settings" which is not something I want to do every time I open another application. I have to go into Settings - System Settings - Workspace Behaviour - then change the number of rows or columns. Yuck.

[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.

[Mrs Beanbag]

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.

That's exactly what I'm saying. The window manager connects to the X server. It doesn't communicate with the other clients (i.e. your applications) that use the GUI toolkits. So there is a barrier there between the toolkit and the window manager and there is no way to ensure consistency between them. Your client apps can't know anything about the window manager's settings and your window manager can't know anything about your GUI tookit's settings, unless they do happen to run on the same machine and have been programmed specially to get on with each other, but there is no guarantee of that. X windows makes no distinction regarding exactly where, physically, a client program is running, which is part of the beauty of it. The problem is that it does so in such a dumb way.

Wayland integrates the window manager with the X server. What I'm suggesting is really needed, is to integrate the toolkit with the window manager. Which currently would be very difficult to do, because X only has the concept of a top level window, and nothing else.