Slashdot Mirror
New Operating System Seeks To Replace Linux In the Cloud
New submitter urdak writes "At CloudOpen in New Orleans, KVM veterans Avi Kivity and Dor Laor revealed their latest venture, a new open-source (BSD license) operating system named OSv. OSv can run existing Linux programs and runtime environments such as a JVM, but unlike Linux, OSv was designed from the ground up to run efficiently on virtual machines. For example, OSv avoids the traditional (but slow) userspace-kernel isolation, as on the cloud VMs normally run a single application. OSv is also much smaller than Linux, and breaks away from tradition by being written in C++11 (the language choice is explained in in this post)."
No security either.
It boggles the mind that anyone would suggest something like this and then use the excuse of "well we only run on app on a box". That's such amateur hour nonsense. It's like running your cloud apps on classic MacOS or an Amiga.
Just because you've only got "one app", it doesn't mean that you've only got one process.
It sounds like running your 2013 server apps on an OS from 1985 but "in the cloud".
[shake head]
A Pirate and a Puritan look the same on a balance sheet.
This is a language-support library. It replaces the C runtime system, and the bottom levels of the Java runtime system. For environments where a virtual machine is running one program, or a family of tightly related programs, that's all you really need. The real operating system is the hypervisor underneath and the remote management tools that run the cluster.
Linux, with millions of lines of code, just isn't doing much inside a VM. It's not managing the memory. It's not handling real devices. It's not handling real interrupts. It may not even be managing any file systems - in cloud environments, those are usually out on some storage area network. It's just a big fat pig of an OS that needs to be fed patches and attention to keep it going, while not doing any useful work.
Within the virtual machine, there are no security boundaries. This may be a problem if more than one application is running in the VM. But if you only have one big program with many threads running, the OS isn't doing anything for you in security anyway.
When a particular choice of programming language makes the resulting work easier for others to understand and maintain or modify, simply because things have been expressed in a manner that is more natural to understand with relation to what is actually being done, "just syntax" makes a HUGE difference.
File under 'M' for 'Manic ranting'
Where are they "badmouthing" Linux? All they said was that Linux is over-kill for running a single application within a VM. Linux and OSv are different tools for different purposes.
Fortunately, with C++ you aren't required to use any particular feature, and don't pay a penalty for anything you don't use.
Furthermore, the alleged performance penalties that a lot of C programmers think exist in C++ actually don't.
Given that this is a special-purpose OS, intended for one-app per VM situations I think it is a perfectly reasonable assumption to make.
Yes, but not in a way that promotes growth. The BSD license is a trap for the grumpy kids who don't want to share their toys at recess.
BSD: You can do whatever you want with your modifications to this code, including close them.
GPL: You can do whatever you want with your modifications to this code, except close them.
One of these creates a positive feedback loop in which small, incremental improvements from coders who share increase exponentially. The other creates a negative feedback loop in which the improvements from those who don't share are locked away and lost. I'll leave it to you to figure out which is which.
We don't have a state-run media we have a media-run state.
I'll take my server OS tried-and-tested, thanks.
Even moreso - I prefer my server OSes to have that kernel/userspace separation. Sometimes that's the last line of defense against a fully-compromised system (see also, say, the typical crappily-coded PHP "application" that has the typical great big security hole (or four) in it...)
I get the drive for making the OS as thin as possible, but sometimes folks need to stop and think it through a little before they commit to doing it at all costs.
Quo usque tandem abutere, Nimbus, patientia nostra?
One of these creates a positive feedback loop in which small, incremental improvements from coders who share increase exponentially. The other creates a negative feedback loop in which the improvements from those who don't share are locked away and lost. I'll leave it to you to figure out which is which.
The problem with this claim is that you're simply lying by omission. (Well, there's another problem: hyperbole. "Exponentially"? Hah.)
GPL: the positive feedback loop is damped by the unattractiveness of the license to many potential contributors, particularly GPLv3. Fewer participants equals less resources spent developing the project.
BSD: the claimed negative feedback loop almost doesn't exist. Many of the entities (the same ones who have issues with GPLv3) whom you GPL zealots assume would just take everything private actually tend not to. Why? Because the reason they're using open source in the first place is to reduce their own workload, and maintaining a private fork of a public codebase turns out to be a lot of work. If you want to take changes from the public version, you're in permanent merge hell (because nobody in the outside world knows or cares about your local changes). If you want to fully fork and ignore the public version, now you're responsible for maintaining everything on your own. In most cases it's substantially less work to contribute your changes back to the public version.
Basically the only time this actually happens in the BSD-licensed world is when someone decides "to hell with it, we don't care how much we have to spend, we're going to go all the way private".
(All of the above is equally true of GPL-licensed code. GPL zealots are only assuming that their preferred license is required to create sharing. In reality, productive sharing is always an outcome of shared interests between all the parties involved, not the license.)
Then explain why would you use C++ instead of C? If you are just going to cut it down to things C does? If you are going to do things C can't, then you will have the performance penalities. Your statments are not really valid.
Because there are cases where you are manually creating a construct in C, that is handled automatically by the compiler in C++.
Take virtual methods for example. The linux kernel is chuck full of structures filled with function pointers. That is a virtual method in C++, except in C++ you don't have to worry at runtime if the function your calling is NULL because the compiler assured that during compile time. This allows micro-optimization, and more natural error handling. Plus, the syntax is standard, so that every 3rd driver writer isn't creating their own version of the same thing.
Then there is generic data structure management. The kernel is full of macros for RB trees, linked lists/etc. Using templates for this allows better micro optimization without the programmer having to get involved.
There are a lot of reasons, and most of the negatives can be answered with, a the simple statement, don't use that feature.
And you've set your entire argument up in a biased fashion too.
A claim which is possible but largely lacking in evidence.
Additionally unfounded. Given that BSD sources can be downloaded, modified, and their changes never see the light of day the loss of information is virtually guaranteed. Not to say it doesn't happen with the GPL, but it's actually a legal risk to allow it to happen.
And yet there are plenty of vendors who would do just that if it suited their purposes. Your argument for staying upstream is entirely logical, but then, many corporations are not run in a logical fashion.
Would you ever know?
Nothing worse than responding to a reasonable post with an invective.
But only so far as it suits their business interests. The GPLv3 was created to further advance its goals which have always been to ensure the software is free and that the recipient of the software is never encumbered by whomever they receive it from.
http://www.cvedetails.com/vulnerability-list/vendor_id-802/product_id-2219/Argosoft-Argosoft-Mail-Server.html
http://www.cvedetails.com/vulnerability-list/vendor_id-31/Sendmail.html
http://www.cvedetails.com/vulnerability-list/vendor_id-86/product_id-143/Dan-Bernstein-Qmail.html
http://www.cvedetails.com/vulnerability-list/vendor_id-1565/Mailenable.html
That's not including the anti-virus that commonly scans the email transversing the system.
It was also single-user, was it not?
That is correct. Single-user designs were the norm with personal computers of the era. There are some ways around this (, for example) but they're sort of limited.
The lack of memory protection is due to the first models being designed around the plain Motorola 68000 CPU, which lacks a memory-management unit (MMU). Later models were available with beefier and more feature-rich processors from the 680x0 series, some of the including an MMU. You could also buy add-on “turbo cards” (processor cards taking over the functions of the main CPU, effectively replacing it with a faster one.) But by then it was too late. The OS relies heavily on shared libraries and message passing in flat, shared, unprotected memory space.
Otherwise, the Amiga hardware platform and AmigaOS – the first model/version having been released in 1985 – included concepts such as preemptive multitasking, windowed GUI toolkit in the system ROM (no “text mode” at all), overlapping “screens” in different resolutions and bit depths, hardware blitter and DMA-based I/O (including multichannel sampled stereo sound), drivers for devices and filesystems, the “AutoConfig” system for add-on devices (fulfilling the same role as PnP did later in the Wintel world), 8-bit ISO Latin-1 character encoding as standard, windowed command-line shells, shell scripting, inter-process scripting (ARexx), an OS-provided framework of multimedia “datatypes” (handlers/decoders/players for common file types), scalable fonts, clipboard, speech synthesizer as a standard OS feature, etc.
Ignoring Linux and OS/2 for a moment, in some ways it felt the Wintel camp only caught up ten years later when Windows 95 was released to the masses, and at that point, both the OS and the “IBM-compatible” PC hardware platform were still missing some key features and novel ideas that made the AmigaOS so great and elegant in its day.