The future of SkyOS, the closed-source alternative operating system, had been hanging by a thread for a long time now. Barely any releases, until they came to a grinding halt altogether and Robert Szeleney explained he was pondering the future of SkyOS, and where to take it from here. One of the main problems was a lack of driver support which really made development difficult. Well, this is a problem Szeleney might be able to fix.
In an announcement posted on the SkyOS website, Szeleney writes that he is experimenting with replacing the SkyOS kernel with either the Linux of the NetBSD kernel. The idea is to let the SkyOS APIs run on op of the Linux or NetBSD kernels, so you get the SkyOS user experience, but the hardware support of either Linux or NetBSD. This would enable Szeleny to focus on the userland, instead of having to devote a lot of time to getting hardware support up to par.
To achieve this, Szeleney wants to move the SkyGI (graphics layer) part that currently resides in the SkyOS kernel into userland, in a manner similar to appserver. “Only the linux kernel will be used. No textmode. From a user point of view no difference should be visible between the current SkyOS kernel on this proof of concept linux kernel,” Szeleny writes.
He is using a Linux From Scratch kernel, version 2.6.27.4, and only uses the absolute bare necessities, so just the actual kernel – not even the text mode. “Based on the results of these proof of concepts (e.g. performance, user experience, etc.) further decisions regarding the SkyOS future can be made.”
This actually sounds like a very promising path to explore for SkyOS, and I hope the results will be encouraging.
Rare: I recommended one of my own items. A great move by Robert, and it sounds like it could lead somewhere good.
Hats off!
I agree, this is definitely an interesting experiment.
By taking nothing but the kernel, SkyOS will not be just another linux distro (or netbsd derivative).
This might actually also benefit the Haiku/BeOS guys. If Robert wants to use SkyFS partitions, the kernel will need proper support for that (instead of the experimental bfs driver).
I also think this is a reasonable move to make. SkyOS will benefit immensely from this. There is still hope. SkyOS/Linux!
It’s pretty astounding (and somewhat appalling) that this old OSNews.com headline http://www.osnews.com/story/8162/Why_you_Shouldn_t_Write_your_Own_K… still proves correct.
Anyway, there’s not much more that the SkyOS author could do instead, and it is of course much better than letting the OS die completely.
Now I’ll have a reason to call GNU/Linux GNU/Linux. If he makes SkyOS with a Linux kernel, then saying “Linux” won’t be sufficient to get across what OS you use. It will by Sky/Linux or GNU/Linux
. Of course, I don’t think this will actually change anything…
Edited 2009-06-08 22:00 UTC
There already was another reason: Android! It is Linux, but decidedly and intentionally not GNU.
Not that I care, or that I should.
Detlef Niehof: Definitely. Just look at how long it took the BSD derivatives & Linux kernel to receive enough contributors and support to make keeping up-to-date with hardware possible. This is such a large task for smaller operating systems and isn’t practical unless they are designed for specific hardware rather than generic x86 platforms with unending possibilities of hardware advancements.
As I said on the SkyOS website, other projects are starting to ‘give in’ to this fact, and there is Anubis – a fork of AROS which is looking into building AROS and her API on top of the linux kernel but remaining native (Not to be confused with AROS being hosted within a Linux env as-is
.
Although it’s sad, it’s only logical that serious, modern-OS projects go down this route if they want a realistic chance of being usable on a multitude of hardware. Times are changing, and having a BSD or Linux kernel beneath the API of a desktop/workstation OS really isn’t such a bad thing – if anything, it should allow better productivity within the unique features of an OS.
i hope he well help haiku
at least both projects have the same goal
might I sugest QNX?
You work out the royalties to QNX (clue: expensive)
And QNX hardware support is probably also very mediocre.
Edited 2009-06-09 05:57 UTC
Why would a ‘proprietary commercial’ (project goals) OS want to use an open source GPL licensed linux kernel? NetBSD would be a better bet so they do not become tied up with the GPL. FreeBSD even better.
Would Darwin be an option?
(Is it BSD Licensed?)
QNX or Darwin are great kernels, but neither one would be a good choice for this project (yes i am revoking my own prior comment as well). the goal is for broad hardware suport. The linux kernel has that in spades, and well NetBSD runs on anything, so naturaly they are the best choices. I hope they go with NetBSD, as it would be great to see a desktop OS with NetBSD at it’s core. Good luck Robert, glad to hear things are moving again.
NetBSD runs on any processor, but I doubt that it has such a great peripheral support. Wifi and 3D support, for example, are probably not great. With no nVidia or ATI drivers, your desktop will look pretty bad.
There’s no licencing conflict as SkyOS is userland (ie runs outside of the GPL Linux kernel)
If Robert was to adapt the Linux kernel to better host SkyOS’s userland (which I’m sure he will), then he’d have to make the kernels source available (albeit, at the very least, by request).
But the bulk of the OS can still remain closed source as it only “talks” to the kernel.
Edited 2009-06-09 07:35 UTC
indeed, nothing proprietary is being linked to the kernel so I don’t see any problem with that.
So does this mean a Linux/BSD kernel without X.ORG? If yes, that’s great! It will be like what Apple did with Mac OS X (except for the command line).
Edited 2009-06-08 23:11 UTC
Mac OS doesn’t use Linux or BSD kernel though.
Darwin is a BSD kernel used by Mac OS X.
Edited 2009-06-09 00:55 UTC
Actually: “Darwin is built around XNU, a hybrid kernel that combines the Mach 3 microkernel, various elements of BSD (including the process model, network stack, and virtual file system)”
http://en.wikipedia.org/wiki/Darwin_(operating_system)#Kernel
So the Kernel in Darwin is the Mach Microkernel.
Unless you mean BSD as the license, the Mach kernel used in Darrwin and the BSD kernel used in BSD OS’s are two different things.
It is debatable as to whether XNU resembles anything like that of a Mach kernel given the massive changes Apple have made. Its pretty much become a hybrid (although heavily leaning towards monolithic).
Very true.
Um, no. Like you mention in very own post it uses the XNU kernel:
And XNU, per http://www.usenix.org/publications/library/proceedings/bsdcon02/ful… is not a microkernel:
Well to settle this lets look at what Apple it’s self has to say:
http://developer.apple.com/referencelibrary/Darwin/
Darwin is the UNIX technology-based foundation of Mac OS X. Darwin integrates several technologies. Among the most important are 4.4BSD-based operating-system services (built on the Mach 3.0 microkernel), the I/O Kit, networking facilities, and support for multiple integrated file systems. Developers can use Darwin to port UNIX/Linux applications and create kernel extensions.
Useful Mac OS X Terms: What is Darwin?
http://support.apple.com/kb/TA25634
Darwin 1.4.1 is the UNIX-based, open-source foundation of Mac OS X. It is based on FreeBSD and Mach 3.0 technologies and provides protected memory and pre-emptive multitasking. This release corresponds to the release of Mac OS X 10.1.
Useful Mac OS X Terms: What is Mach?
http://support.apple.com/kb/TA25632?viewlocale=en_US
Mach is part of the underlying technology of Mac OS X. It is a UNIX technology developed at Carnegie-Mellon University in the late 1980s and 1990s. It is a robust, “open source” operating system, which is used to provide memory and task implementation services. Darwin uses Mach 3.0. Mach provides memory management, memory protection, process scheduling and interprocess communication services. Mach, together with BSD, forms the heart of Mac OS X, known as Darwin.
The funny thing is that you look all through Apple’s site you don’t see really see Apple refer to the OSX Kernel as XNU much.
But it does say here is that XNU is the combo of the Mach Kernel and BSD userland. And that is also what makes Mach not the normal Mach implementation. Because Apple doesn’t use the Mach userland.
http://developer.apple.com/DOCUMENTATION/Porting/Conceptual/Porting…
The core of any operating system is its kernel. Though Mac OS X shares much of its underlying architecture with BSD, the Mac OS X kernel, known as XNU, differs significantly. XNU is based on the Mach microkernel design, but it also incorporates BSD features. It is not “technically” a microkernel implementation, but still has many of the benefits of a microkernel, such as Mach interprocess communication mechanisms and a relatively clean API separation between various parts of the kernel.
Why is it designed like this? With pure Mach, the core parts of the operating system are user space processes. This gives you flexibility, but also slows things down because of message passing performance between Mach and the layers built on top of it. To regain that performance, BSD functionality has been incorporated in the kernel alongside Mach. The result is that the kernel combines the strengths of Mach with the strengths of BSD.
How does this relate to the actual tasks the kernel must accomplish? Figure 9-1 illustrates how the kernel’s different personalities are manifested.
XNU personalities
The Mach aspects of the kernel handle
Memory management
Mach messaging and Mach inter process communication (IPC)
Device drivers
The BSD components
Manage users and permissions
Contain the networking stack
Provide a virtual file system
Maintain the POSIX compatibility layer
So in the end according to Apple its still Mach just using the BSD userland.
Maybe you should look and see who wrote the paper I linked to.
You could also stop misinterpreting stuff from the links you provided. Having a kernel based in part on Mach does not mean your OS is using the Mach Kernel. It means it is using a kernel (XNU) based in part on Mach, and “BSD-Lite2 kernel source, as well as source that was developed at NeXT”
Darwin is not the Mach Kernel and BSD userland. It is XNU kernel (Mach plus BSD kernel stuff plus NeXT stuff) and BSD userland. The BSD stuff is not limited to the userland, and the kernel is not just Mach. It is a monolithic kernel, which Mach certainly is not.
Again, no.
Once more, from your very own post:
When they say “Mach aspects of the kernel” that implies that there are other aspects of the kernel. Whatever could they be?? Why, they tell you a couple lines down! “The BSD components”! And you quoted that to convince me that the kernel is just Mach? WTF
That section is not talking about the division of responsibilities between the Mach Kernel and BSD userland. That is talking about the division of responsibilities between the Mach aspects of the kernel, and the BSD components of the kernel. The kernel is Mach + BSD (plus NeXT stuff) in a monolithic package (and yes, there is also a BSD userland in addition to BSD parts of the kernel)
Edited 2009-06-10 12:25 UTC
You two should get a room.
Yes there are handfuls of kernels SkyOS could use but seriously, for the best hardware support Robert cannot go past a Linux Kernel. I’m glad the SkyOS crew have finally come to their senses. No more re-inventing the wheel and keep working on the userland. Apple did it and succeeded (kind of – reasonable hardware support). Looking forward to the next iteration.
Uhhhh, it IS re-inventing the wheel. Just another *nix kernel with a different GUI on top. Can anyone say OSX?
That’s just what the *nix community needs, another distro to confuse the hell out of people. What made SkyOS attractive was that it WASN’T just another *nix distro.
In fairness, wouldn’t someone who gets confused by yet another *nix distro also be confused by yet another alternative OS anyway?
BSD is a *nix variant. What the hell, what’s another *nix distro when we already have several hundred variants floating around out there. A *nix kernel will be the death of SkyOS if it isn’t already dead. People were attracted to it becaause it WASN’T a *nix, BSD, Darwin, et. al. ad nauseum……
Just going to the Linux kernel isn’t going to get you support for all the hardware a Linux distro supports. All of the support for hardware graphics acceleration lives in the X server. You could include the X.org, but then you’re well on your way to just being another Linux distribution. There’s DirectFB, but it doesn’t support nearly as much hardware.
I believe USB hotplug support requires some userland support as well.
The Linux kernel does give you support for lots of other hardware, though at least for a while FreeBSD had better WiFi support (or so I heard, I’ve never messed around with WiFi on FreeBSD personally).
All of the support for hardware graphics acceleration lives in the X server. You could include the X.org, but then you’re well on your way to just being another Linux distribution. There’s DirectFB, but it doesn’t support nearly as much hardware.
Nor does it support any of the extra features of the hardware, like acceleration or such.
I believe USB hotplug support requires some userland support as well.
The kernel can handle loading any necessary modules automatically, you only need userland if the hardware requires any extra operations. Though, just having the driver up isn’t much..
The Linux kernel does give you support for lots of other hardware
There’s still a huge streak of work to do to be able to use much of it, though.
Darwin would be a terrible choice. It’s driver base is limited and writing drivers for it is easy but it’s non-standard compared to other BSDs.
QNX will cost you money and it’s driver range is good, but nowhere near as good as Linux.
I’d like NetBSD’s kernel. Many drivers (many, many) and BSD licensed.
Personally I’d go for OpenSolaris or NetBSD; with OpenSolaris you inheret ZFS plus lots of other goodies – and the hardware isn’t as bad as some try to make out. There is NetBSD with the benefit of a multiplatform outlook so if you are looking at beyond the x86 world then maybe NetBSD is the solution.
The benefits to both are stable API’s, both kernel and user, and a large community; I would love to see SkyOS take one of these as the basis for a NetBook operating system which focuses on a niche market that is growing and something SkyOS can cash in on given the very small number of hardware needed to be supported.
I for one wish Robert all the best of luck; I truly am in awe when I see people putting a heck of a lot of effort into projects, doing things that I could never in a million years able to accomplish.
Note that there are ongoing efforts to port ZFS and NILFS for NetBSD.
Glad to see Robert isn’t giving up on SkyOS. It will be interesting to see which kernel he decides on. If he goes with the Linux kernel I wonder how much of the OS he’ll have to open up without breaking the GPL.
Anyways good luck to Robert and I can’t wait to start testing his OS again!!
As much as I like Unix or Unix-ish operating systems, I really want to be familiar with different non-Unix operating systems besides Windows.
SkyOS should be fully open sourced or sell it to a company. I don’t want a Unix-ized SkyOS.
Or another way around, bring back the original BeOS for the sake of minimal healthy diversity.
You should look into Haiku, their goal is to be fully compatible with BeOS R5. I’ve been testing it for 2 years and it’s looking very promising.
http://www.haiku-os.org/about/faq
Edited 2009-06-09 03:35 UTC
Using a minix-clone Kernel won’t make SkyOS “unix-y”.
People often confuse userland tools with the kernel, but essentially all the kernel is, is an interface to the hardware.
Everything on top of that (from the command line to directory structures to GUI server, etc) are userland tools (in most *nix anyway – some OSs load the GUI server into the kernel).
So ALL SkyOS will be inheriting is driver support for (what you and I know as) SkyOS to talk to the hardware.
BeOS was more “unix-y” than SkyOS is!!!
Edited 2009-06-09 09:06 UTC
That’s the problem. SkyOS and its userland are based on non-Unix dynamics. I don’t think superimposing a Unix-ish component is a good idea.
So does Amiga and not many people relate BeOS to Unix dynamics.
I think you’re needlessly segregating things there.
These days the difference between the majority of PC kernels isn’t all that significant. Plus it’s not as if key functions from SkyOS’s kernel can’t be integrated into Linux (so long as the code is GPLed).
Linux has proven itself to be an adaptable kernel as it’s been used on everything from servers to desktops to mobile phones to a whole plethora of other integrated devices.
And it’s not as if this is the 1st occasion 2 different OSs have been mixed up like this.
The kernel is pretty irrelevant to the user experience. In an alternate reality Microsoft could be using the Linux kernel for Windows yet it’d still look and feel the same as it does now.
If he stays away from X.org he can still be more than “just another Linux distro” but if he goes with it he’ll get even better driver support but will become less distinct, but not by much.
Edited 2009-06-09 03:27 UTC
If he were to use the Linux kernel, could he make the drivers installable like in Windows? I’d hate yet another OS where you have to recompile the kernel when some driver is not built in …
Not likely without some heavier modification or without freezing the OS on particular kernel level for a very long time. NetBSD kernel would however accomplish this, so I personally hope he goes with that. BSD license would also suite him much better.
Linux drivers can be installable like in Windows. Stop spreading FUD.
hats off to Robert for taking a responsible direction with the project, I hope it all works out.
I am very happy to see this story. Glad that SkyOS isn’t going away but going to be changed for the better. I would say go with th kernel that would be the easiest to get working with SkyOS, but I am bit partial to NetBSD simple because there are so many Linux distro out there, and this would be a bit different. Good luck, will be looking forward to the new SkyOS.
SkyOS v5 has an advanced multiuser and security model with extended acl’s and a set of (if i remember correctly) 128 system privileges – quite “non unix-ish”, and a bit on the NT side – how would it fit with the linux kernel, its unix derived “all or nothing” default implementation, and the patches (and theinfrastructure to accomodate them, lsm) made to overcome its limitations?
then again if i remember correctly, SkyOs had a clean and lightweight (and suitable for a desktop) process model and thread-native scheduler, that accounts for a desktop responsiveness nearly on par with haiku’s and beos’
desktop responsiveness on linux otoh, still is a sort of holy grail, that developers aim to reach by throwing hard – realtime concepts (as in, “when the kernel becomes a hard RT suitable one, it will also allow for responsiveness” – or, “responsivess requires hard realtime support” – which in itself is a grave misunderstanding of what a hard- rt system is for and is made of…) at what was born as, and still is, a server oriented kernel that has no real means (other than io heuristics), to distinguish gui threads from service or background ones …
although possibly in the miinority, people believing, not that sofware is good when it works well enough, but can never work well enough *unless* it’s good (ie well designed and implemented ) exist, and they’d likely favour quality over quantity (ie an os with an elegant and efficient architecture running on selected hw is preferable to a mediocre os with drivers with random and exotic crap)
they’ll likely also wish robert had at least open sourced skyos’ kernel, as this would have fostered the interest of community volunteers and would have allowed him and others to reuse (port) linux driver code – instead of considering the cration of actually another linux distribution (albeit not a gnu/linux one)
PS :
@ the one who said that “the kernel is just a layer between applications and the hardware”
no, the kernel is primarily something that arbitrates access to the HW resources, AND provides core services to running applications
and since the way it does so, under waht conditions, and how to interact with the kernel at the binary level, is all determined once by the one who designs the kernel, its operating models and its api’s –
the kernel is actually an entity that enforces semantics on the system
netBSD would suit SkyOS more because of license (people have been already attacking SkyOS because of bits of GPL code SkyOS uses)
But yes, to end user it would mean very little what kernel SkyOS would use and only thing that would really matter to them would be that it runs on their hardware.
Having Sky/linux would keep the GNU folks on their toes though, it’s funny in a sense that the people sworn to fight monopolies hold monopoly in so many things Linux.
… is what you called all this experimenting just a few months ago, see
http://www.osnews.com/story/20880/SkyOS_Chasing_Butterflies_UPDATED…
And now you are all in excitement over the announcement of yet more experiements?
I’d go with Linux, lots and good hardware support, better performance, and once Btrfs gets released ZFS wont matter any more.
So let me get this straight: once Linux gets a new file system, file systems used by other operating systems are not relevant any more?
How insightful.
We here at OSnews truly love different operating systems.
SkyOS, ReactOS…..xxxxOS, honestly, does anybody expect those creations to become relevant operating systems some day, or, just to reach some near-release status ?
Well, I don’t.
SkyOS is actually very stable and responsive system, only thing that has been holding it back is lack of drivers…which in itself is mission impossible.
You’re missing the point by a mile. People code these things because they want to, it’s an excellent way to learn stuff and hone your skills.
Oh, and yes, atleast ReactOS will be relevant as soon as it can use most of the Windows-drivers and supports 3D acceleration. It’s a great alternative for XP and is being actively improved all the time, unlike WinXP.
Think of it this way. With the growth of Linux, there are many opportunity for FOSS presented right now. It also makes next-gen Unix-ish operating systems in the future as the C language is still alive and kicking and bringing more appropriate standards today.
I don’t think Linux will be that great in the future, but it’s a catalyst for next-gen post-Linux Unix-ish systems.
SkyOS likely contributes importance of non-Unix FOSS, despite there are tons of disuptes in the development of SkyOS.
Overall, you have to look at it in a big picture.
…except for that it is not FOSS but proprietary, closed-source software, taking advantage of FOSS, but not contributing anything to it.
This was why I said likely.