Slashdot Mirror
SkyOS Now Runs Linux Binaries Natively
Gunder123 writes: "A new (open source in the past, but not anymore) operating system, SkyOS, in its latest version can run Linux binaries unmodified, without the need of a recompilation, enriching its own application base this way. Their Linux emulation layer lies inside the SkyOS kernel, I wonder if there are any GPL violations going on here. Their future plans involve also an emulation layer for Windows applications, pretty much what ReactOS tries to do for the last few years for the WindowsNT model."
from the SkyOS website:
>Emulation layers
>
>Linux
> 6% of all linux syscalls implemented
> Support for static linked ELF i386 binaries only
Well I guess any binary using any of the remaining
94% system calls will not work... hmmm....
I wonder if it's the spiffy GNU hello.c which includes its own email client.
Seriously, they only support a very small subset of calls thus far.
"Their Linux emulation layer lies inside the SkyOS kernel, I wonder if there are any GPL violations going on here."
That has to be one of the rudest things that I have seen on Slashdot in years. To suggest that just because some Linux binaries can run on another OS with no evidence is absolutely disgusting.
Of course, even more disgusting is that Timothy posted it, but I think everyone realizes Slashdot has a pretty fucked up editorial policy so I shall not continue.
From the status page , it says only 6% of all linux syscalls are implemented...
main(i){(10-putchar(((25208>>3*(i+=3))&7)+(i ?i-4?100:65:10)))?main(i-4):i;}
I'm having a hard enough time getting our office staff to switch to KDE. Why would I want to mess about with SkyOS? Does anyone know?
--
Socrates was asked where he was from. He replied not "Athens," but "The world."
than any other emulation (other than this is integrated in the kernel)? WINE runs Windows apps and I don't hear many complaints about license violations there.
SmashTech - No smashing of tech involved
1. Write free software.
2. ???
3. Profit!
Solaris 9 (the beta is out) runs linux binaries.
:) )
Pros: its got good backing (who else puts the DOT in dotGone
Cons: erm.. availability of code
----- Whats wrong with this picture? http://www.revoh.org:1234/whatswrong
one of the freedoms is the "freedom to read/modify and learn" from the source. If he is just learning from the source and reimplementing it, there is no problem.
Is wine in violation with microsoft copyright?
Fighting for peace is like fucking for virginity
Future conversation...
Geek acolyte: Whatcha runnin'?
Elder Geek:I've got SkyOS emulating Slackware, with WINE layered over that so I can use all my l00t wArEz.
Acolyte:Cool! How'z Mozilla run on it?
Elder: Still a little buggy -- but imagine a beowulf cluster of these...
"It was a summer's tale: Just a boy, his Linux, and a head full of dreams..."
In all likelihood, the Linux ABI will become a standard for all non-Microsoft x86 operating systems. It is simple and legal to implement, and very robust and powerful.
-CT
>I wonder how it's possible to write a "Linux Emulation Layer" without using the Linux source in a way that violates the GPL.
Same way as Compaq did it to "clone" the IBM BIOS. Poke stuff in, see what happens. Read technical manuals deviod of code. Get engineers in that haven't already written GPL code (untainted).
Running (basic) Linux binaries will be easy in comparison to hacking a copy of a BIOS without any idea of what it does -- or so I'm thinking.
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
the point is, it's *his* waste of time.
Regardless of the licensing terms, this guy seriously doesn't expect to do anything truly useful with this OS.
Remember that Torvalds initially didn't use the GPL for the kernel.
Also note that Caldera has a 'distribution' that doesn't even use the kernel but rather reimplements a 'personality' -- I mean, even Unisys likes it !(I'm being sarcastic)
Understand, though, I am not criticising his intent -- he has an itch; he wants to scratch. At least he's pursuing his own muse.
========================================
Death will come, and will have your eyes
-- Pavese
Taken from and interview on OSnews ( www.osnews.com ), here's the answer to your question:
Robert Szeleney: Until version 3.0, SkyOS was open source. But now, I don`t want SkyOS to be open source. I put so many work into this project, that I don`t want to give to source away. But I accept project members. If someone want to code for SkyOS he can have source. Also, I accept source codes and bugfixes for SkyOS. I don`t put restrictions for coding style. If someone coded for example a new driver, I will change the code to fit into the whole SkyOS coding style.
For those who doesn't know, Robert Szeleney is the man behind SkyOS.
I just want to point out that ReactOS is NOT just aiming for application compatibility (as is suggested by the submitter). We're also looking to support NT/2K/XP drivers and we're modelling the entire kernel and subsystems around the way NT works. Sure we'll do things differently where there won't be a huge compromise in compatibility and we can make something better.
- Jason
"Linux" now runs Linux binaries natively, without even a recompile! It seems that those wacky "Linux" kernel guys have managed to emulate 100% of Linux system calls. It's really slick -- they just run the user-level code in the binaries natively and then dispatch to the right part of the "Linux" kernel when a trap occurs, via an advanced mechanism called the "system call table" which maps Linux system call numbers to "Linux" system calls. Word on the street is that nerds everywhere are ecstatic at being able to run their Linux binaries on their favorite "Linux" system.
---
I guess that running Linux binaries is a pretty good way to get some applications on your hobbyist operating system, but does this young, closed-source OS have anything to offer us besides the retro Amiga-esque GUI and an emulation layer for 6% of Linux system calls?
Fork the code. Reimplement new fetures. That is what should be done. When people asked about Mozilla reay being open source the response was that you are always able to "do what is right, fork the code" This is the best thing anytime someone trys to take source away mid project. It would be one thing if this was closed from the beginning, but making major license changes like this is asking for trouble and upset developers. OpenSSH vs SHH anyone? Yes thats BSD. People say GPL projects can't be forked but they certainly can be and there are some examples of that as well. I believe OpenRacer vs Tux Racer is one. There was another having to do with file systems. Anyone remember what that one was called?
Think about how that kind of emulation works, you just do system call translation. What on earth code would you steal? This is code that, by design, HAS to be original.
Slashdot's editors truly need to be more careful, and they need to issue an apology to SkyOS for making such an irrational accusation.
Nathan
That's completely backwards. When writing an emulation layer (I speak from experience...if you ever ran a System V 286 binary on a System V 386 Unix or an SCO Xenix 286 binary on a Systemv V 386 Unix, you were using the emulation layer Darryl Richman, Carl Hensler, and I wrote when we worked at Interactive), you do not want to use actual code from the OS you are emulating. That code doesn't work like your OS works (if it did...you wouldn't need an emulation layer...you'd just need some argument munging and other trivial stuff).
The hard thing about an emulation layer is finding out just what the thing you are emulating does. An emulation layer has to not just follow the written spec (if there is one), but also has to implement the same bugs as the thing you are emulating, and follow the same choices where there was leeway in the spec, or you might break binary compatibility.
When emulating something that is open source, like Linux, you have the documentation you need: the source code. You read it to find out what the real behaviour is, and then implement that in a way that fits in with the way your OS works. It simple is almost never going to be faster to rip the actual code and try to use it.
When emulating a closed source thing like Windows, however, finding out the actual behaviour you need to emulate (remember...gotta match the actual behaviour, not just what the spec says) can take much experimenting and disassembly. It is much more temping (because it can actually save a lot of time), to rip some DLLs from Windows, and cobble together a framework to run them under your system.
So, just from a "what might developer's do" point of view, it is actually more likely a Windows emulation project would use parts of Windows they should not use than a Linux emulation project would use parts of Linux they should not use.
I have nothing against open or closed source projects. What bothers me is when open source projects become closed source without the approval of 100% of those who contributed to the development.
If a developer gives his time because he believes in the principles behind open source, he should not see someone else declare that the project on which he worked is now closed source.
I do not know if this is the case with SkyOS and do not mean to imply that it is.
OtakuBooty.com: Smart, funny, sexy nerds.
Compare the immediate reaction of "did they violate GPL" with a absolutely no basis, in the face of the fact that it would be *more* difficult to get appropriate code from linux than from bsd, to the "wait and ask why" reaction to theft of bsd code by linux a couple of weeks ago.
Then let's all head down to the High Church of Emacs and sing the hymn, "GPL, GPL, uber alles" . . .
hawk
Actually, adding native linix binary support was something I recommended to Microsoft years ago. Call it Winux. Implementation would be equivalent to the horribly lame OS/2 or POSIX subsytems.
.supported by the mighty MS. And finally, they could be sure that the Linux apps would run at a disadvantage because of the extra overhead in the translation layer. They could even charge a few bucks for Winux -- people would be lining up to pay for it. Just consider the success of the MKS toolkit & even Interix
Windows would gain the availability of many programs that do not have equivalents in the windows world (plus for MS users) Downside would be cost to support Winux (not large compared to cost of developing NT, linux is much less complicated then windows APIS). 98% of the Linux API is easily matched to the kernel, the 2% leftover would not be too challenging (e.g. cygwin or VMWare could be bribed into completing the job or licensing the base to MS)
The linux kernel & device drivers would not be supported directly by Winux, but by mapping to windows equivalents. Linux kernels and drivers would not be functional under Winux, but MS could build the most commonly needed drivers and document how to add your own. This would be way better than Interix because of the simple -- just copy the binaries around.
MS would be able to claim you could have you cake & eat it too, reduce the risk run Linux Apps and NT and don't get locked out of the use of Word & Excel. They could even claim the advantage of a O/S
Linux would gain exposure by Windows users. They would see advantages and disadvantages of Linux software firsthand without a major investment of time to install Linux, esp. the headaches of dual-boot setup to try. Many open source projects seem to have a Windows option, save time & stop supporting that since Winux would avoid the need for such. Finally, Linux lovers would still be able to say just how bad, unstable, limited, etc. Winux is and that any right-minded person would just use the real thing. And for the coup-de-grace, Linux viruses, trojans, etc. would then be able to bring down Window too.
True believers of either side could ignore the other side, flame about it, or even cooperate with it as suits them personally.
Consumers could buy MS and have a choice as to what kind of software they use.
This obviously made so much sense that it did not stand a chance.
And all these emulations are very fast, because they are hooks to native OS functions. They aren't 100% emulation, like VMWare. I use Linux binaries daily on OpenBSD and FreeBSD, and I can hardly find any significant slowdown between a native BSD application, and the same application compiled for Linux, and run with emulation.
So can we imagine that Linux binaries could become a de facto standard for executables?
We would get something similar to Java, but yet more powerful (no tie to a specific language nor a specific API) . Ok, x86 binaries would only run on x86, but the same binary could run on 95% of the computers, regardless of their operating system. Any sort of application, low-level or high-level. GUI or daemon. And always fast, wrapping native system calls.
The nasty drawback is that people would release more closed-source software.
But OTOH, if you can take all your current applications and easily migrate to any operating system by just copying everything, including binaries, you can save a lot of time. You can also develop applications for customers even if you don't run a similar OS.
Would it be a dream, or a hell?
{{.sig}}
OK, since my post was from a marginally-educated guess standpoint and you sound like you've actually had experience with the topic at hand, I guess I stand corrected.
But just this once!
Don't think I'll back down so easy next time! 8-)
___
The way to see by faith is to shut the eye of reason. --Ben Franklin
Your posting is mediocre because you provide no justification whatsoever for your claims. For example, you could have said that the Linux SCSI implementation is very poor, or that it's based on the 30-year-old Unix paradigm. And in the case of SCSI, you would have been right, in the case of Unix, you would have had to demonstrate how something else works better, which would not have been easy, and too many people who try only show their lack of grounding in operating systems design. But you didn't even try.
Bruce
Bruce Perens.
That's LINE, http://line.sourceforge.net/
(Pedantic mode off)
Comment removed based on user account deletion