> Lets throw away the last 20 years development on the linux kernel by thousands of people, and rewrite our own.
> How much will it cost?
> Ooh - I dunno - If you lend me 1000 engineers, we should be done in about 10 years, cos we're really smart and don't need to implement legacy SCSI support...
Good thing it's funded by someone who has lots and lots of money!
> Lets throw away the last 20 years development on the linux kernel by thousands of people, and rewrite our own.
To suggest that linux is as good as it gets is a mistake. Operating systems are challenging to write, but certainly not impossible. If you're Google, you see big security risks involved in Linux's design. Google tries to mitigate some of those by funding oss-fuzz and a ton of other great options that narrow the opportunity for exploits. But what if you could write your own OS and make particular security guarantees as a design goal?
Google has already designed and/or reimplemented almost every aspect of the OS excluding the OS kernel.
The biggest drawback for starting a new OS is generally the cost of porting existing software to the new OS.
Making something better than Linux in some way isn't hard. Making something consistently and sustainably better in enough ways, at the rate Linux moves, is a very hard task.
On top of that, Linux essentially sucked all the air out of the UNIX development space by killing off all the commercial UNIXes. Carrying Linux forward rests largely on the shoulders of the kernel team and whatever contributions other businesses feel like making.
So where is the next major OS coming from? Google and Microsoft are the last two companies with the talent to build a future OS and enough resources and clout to push it enough to get traction. (In theory, it could also come from the community but people like Linus only come along once in a generation.)
Only because they have done a really good job.
(Don't get your knickers in a knot. I'm not banging on Linux.)
From the 1980s to 1993 there were:
v7 ports: Microsoft Xenix (later became SCO), Venix, Coherent
System III ports: PC/IX (later 386/ix)
SVR3 ports: official Intel, ESIX from Everex
SVR4 ports: Dell UNIX, Novell UnixWare, MicroportEDIT: Yes, Linux has its origins sooner, and if you want to know why Linux beat the BSDs to mindshare, what was going on in 1993 is very important. But Linux wasn't competing for mindshare with Xenix, it was stuff like Solaris (which did have an x86 port, but was mostly running on SPARC), AIX (which was mostly IBM big-iron and POWER), HP-UX (which was PA-RISC and IA-64), etc.
AT&T was suspicious, but even after a careful investigation by Dennis Ritchie himself, they couldn't prove any of their code had been copied.
Given both the V7 source code and Coherent source code have now been released, you can compare them yourself and form your own opinion, if you'd like.
V7 source code: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7
Coherent source code: http://minnie.tuhs.org/cgi-bin/utree.pl?file=Coherent4.2.10
OS/2 was, in fact, created to be Microsoft's Xenix replacement (and then when Microsoft fell out with IBM, we got NT as Xenix's replacement's replacement).
They not only kept supporting it via SCO Group but even used that company to bankroll an attempt to kill Linux in court. IBM, dependent on Linux, promised a billion dollar battle. Company eventually went bankrupt but its "real UNIX" is still in use by Fortune 500 companies as legacy systems. That they sold inventory-management solutions on top of SCO Server means quite a few are mission-critical. That money coming in is probably why they keep fighting over whether it should stay bankrupt or not.
https://en.wikipedia.org/wiki/SCO_Group
Microsoft truly abandoned UNIX when they went with OpenVMS:
http://windowsitpro.com/windows-client/windows-nt-and-vms-re...
Note: Fun to remind UNIX/Linux users about that when they joke about an OpenVMS desktop. One dominates the market. ;)
I think it won because it offered neutral grounds (a place where lots of players who don't have huge market power can meet without fear of being swindled) and, partly, out of luck (you could call it 'good timing', but I don't think Linus considered that)
For good reason too. The commercial UNIXes were absurdly expensive, and they were all incompatible with each other too. There's a reason all the software developers abandoned UNIX and went to Windows. UNIX killed itself with ridiculous license fees and fragmentation. Linux saved it by making it free, open-source, and unifying it and using common standards instead of a bunch of vendors trying to make their own hoping to gain marketshare and ending up losing everything to MS. Of course, this hasn't prevented Linux from having its own share of fragmentation (the different DEs chiefly), but it's nothing like the UNIX Wars of the 80s.
Continuing on with audio, virtually everyone uses pulseaudio. JACK is pretty much reserved for audio production and is its own animal.
The majority of configuration files are similar/the same, most differences are minor. For good or ill most distros are adopting systemd.
Window managers or desktop environments are just components virtually all of which are able to be run on any distribution.
Got any more?
Plus someone has to keep track of those instructions for every single distribution.
Finally, supporting the same format isn't enough, for example a RPM for SuSE isn't the same as a RPM for Red-Hat.
Well, apparently you forgot there are people still using ALSA and OSS.
When doing desktop applications anyone that cares about UI/UX of the respective users wants to integrate with the menu system, notification on the toolbar, context menus, drag-and-drop of the window manager, printing,....
So it isn't just components.
Of course, if the goal is to have a plain twm experience, then forget about what I am saying.
Your valid issues are pretty much limited to the fact that software must be packaged for several distros in order to be suitable for distribution on even most systems and file manager integration is still something that requires you to integrate with gnome AND kde to support most users.
That's not an opinion necessarily shared by others who worked on UNIX and still do in some cases.
Certainly, there are commercial UNIX releases today that have relatively recent innovations and capabilities that still aren't available in other operating systems.
I think that is a stretch. Apple has significant investment in Darwin and are a huge contributor to LLVM. Also, don't count out Amazon ... they have their fingers in so many pies these days ...
I don't mean to bash Amazon. They do well what they do, at the scale they have. I only think the project would not fit the company as it is now.
Amazon doesn't waste money just because. But if they saw the potential return in developing an OS (say they decide that having a custom OS as their base for AWS) they are absolutely the type of company that would pursue it.
That said, I'd like to note that a custom OS for AWS (servers), and a user OS (desktop or mobile) are extremely different things.
Apple could make the next OS for Apple (presuming they were willing to take the leap to do something other than incremental improvements to their existing stable of OSes), but they aren't likely to make OSes for anyone else, so they aren't really relevant to the discussion.
> Also, don't count out Amazon ... they have their fingers in so many pies these days ...
Amazon seems to be pretty consistently plucking the low-hanging fruit from their current position. They might have the right talent to build a future OS, butz for a slightly different reason than Apple, it doesn't seem to be consistent with their orientation.
Amazon does release a modified Android. They could probably spend the money and get there.
Doesn't oracle do a fair bit of linux work?
Red hat as well. Building a new OS they do have the knowledge at least.
IBM?
You do not want these companies involved in your operating system.
The support I've had from companies like Red Hat is unparalleled.
Android is maybe using 10% of the functionality in the linux kernel but is paying all the overhead and friction of maintaining a branch for each and every device.
I think google wants to heavily encapsulate the hardware vendors drivers and customizations and provide a stable API so google can pretty much update devices with on its own without much interaction with the hardware manufacturers. (Which are very complacent about their updating)
There's only two ways around this: 1) somehow force companies to open-source their driver code, or 2) have a static, unchanging (or at least very backwards-compatible) ABI for device drivers, and then just suffer with shoddy drivers written by vendors which cause all kinds of glitchy behavior, as Windows was infamous for for so many years.
This doesn't happen with the mainline tree because it's all open-source and gets debugged and inspected by others, but that just doesn't happen with the cellphones/Android.
I'm not going to defend the vendors (much). But it's not free to upstream your code. It's work. And I'd argue that it's an investment that will pay off, but you can't fault others much for seeing it differently.
There's no guarantee some unpaid volunteer is going to do this kind of work for your company, but the chances are much higher if it's some kind of popular device.
And how is Fuchsia supposed to help that?
That model is not perfect, but it worked for MS -- and Google is in a similar enough position.
Unless there's some legal requirement, it's going to be the same fragmentation
FreeBSD will break ABI every major version, roughly every 2 years.
https://wiki.freebsd.org/VendorInformation
OpenBSD even goes so far as to break the user-space libc ABI in minor releases:
Besides toying around with FreeBSD in the late 90's, I never used it properly.
https://homes.cs.washington.edu/~levy/capabook/Chapter8.pdf
OpenVMS gave customers binary translation tools plus let clusters run with multiple, CPU architectures. That migration wasn't as painless but at least happened. Microsoft eventually applied this strategy at application level combined with OpenVMS's cross-language programming in the form of .NET CLR. It can work at much lower level as IBM showed in the 70's or 80's, though.
The reason this is possible on the PC and not on phones is because there are more standard hardware interfaces that don't exist in the ARM world. The lack of that is why the phone vendors need to do a lot of custom work.
Right now you can bootstrap a ROM because the manufacturer has to OS their kernel (GPL).
Now, with the kernel being proprietary, getting a custom ROM will probably be as hard as getting android to work on iPod.
Correct, they don't:
> From piecing together information from the online documentation and source code, we can surmise that Fuchsia is a complete operating system for PCs, tablets, and high-end phones.
Their baseline isn't hardware from 40 years ago, it's that of today and only a subset of it. That means that you can forego an enormous amount of things which are all potential sources of problems. The world has evolved a lot, new theories around OS design and security have come and gone.
Just because Linux serves us well doesn't mean we shouldn't explore other options, or that those other options need to support every old data exchange format and hardware port.
Chrome has more code than the Linux kernel.
The numbers I see for 2012 (way back) are: "4,490,488 lines of code, 5,448,668 lines with comments included, spread over 21,367 unique files."
Linux, on the other hand, was ~ 200K lines of code for the kernel (the rest is 7 million for drivers, about which the new OS doesn't need to concern itself, as it will on custom hardware) and 2 million lines for various architectures (ditto).
Don't overestimate the complexity of building a complete kernel -- even teams as resource lacking as NetBSD can do it.
And with other parts of the stack, they already have tons of experience (e.g Skia for graphics etc).
Your argument could have been used against almost every project Google's worked on. Email, search, Go, phones, Chrome, maps, etc. all had established proprietary and open source competitors.
It might be expensive, but it's cheaper, more practical, and more likely to succeed than something like self-driving cars or Google Glass.
Someone in a comment above noted that Rob Pike thinks Unix is obsolete. But then he was probably thinking about Plan9 which was indeed better than UNIX -- because it even more unixy. Filesystems all the way down.
Capabilities are the first new abstraction I have heard of that really go beyond the Unix model.
For starters, read the headlined article that observes that capabilities pre-date the UNIX model.
Even the "classic authorities" on this stuff, including Bach, Comer, Deitel, and Tanenbaum, pointed to many things that went beyond the UNIX model. And this was almost thirty years ago.
There is a wealth of experimentation and diversity that already exists and that has been done over the intervening many years. In addition to the operating systems already mentioned on this very page, there's Helios which was a capability-based system with a POSIX layer on top from the late 1980s/early 1990s. The BSD 4.4 Log-Structured Filesystem had global wear levelling in the filesystem in 1990. OS/2 1.0 went beyond terminal escape codes and multiple mouse protocols to a device-neutral video, keyboard, and mouse paradigm for TUI applications in 1987. People have done operating systems where everything really is a file, "object oriented" operating systems, network distributed operating systems, microkernel operating systems with multiple "personalities", ... all sorts.