This distinguishes it from COM/CORBA where objects must be "marshalled" and "demarshalled" (i.e. serialised and deserialised) when communicating
between different languages, even on the same machine.
As far as COM goes, this is in error. Marshalling is only necessary for inter-process calls. For intra-process calls, there is no marshalling, and very
little COM overhead - even if the language is mixed.
Thanks for picking the nit.
Incidentally, I have no reason to disbelieve you (I'm sure you know more about COM than I do), but I'm puzzled: How do you mix C++ and Java data types (to pick two examples) without marshalling?
It's only a conspiracy theory, of course, but the suggestion was half serious.
CE is the only operating system that Microsoft has worked on (unless you count OS/2) which could be called truly "innovative". The only way that you can get Office (even if it is the cut down edition) to run on a palmtop is to use an OS with almost no bloat. CE has almost no bloat. All you need is a bloatless OS and the CLR and you have a nice framework for a new OS.
Besides, the issue as I see it is not "CE to replace NT", but "something new to try to kill off competing OSes". It might not be CE. CE would, after all, need some extensive modification (at the moment it is targeted to architectures without MMUs, for example) to compete. They might decide it's better to buy a company with a suitable microkernel.
Disclaimer: I'm a former Mercury developer. I left the project before Microsoft approached the Mercury guys, but after a fairly scary dinner with James Plomondon, whose job title at the time was "Principal Java Evangelist, Microsoft Corporation". It's a long story, which can be told some other time.
Anyway,.NET has, as part of the system, a common language runtime (CLR) for different programming languages (and I mean very different programming languages; C++, ML, Perl, Haskell and Mercury are about as mutually different as languages can get). This distinguishes it from COM/CORBA where objects must be "marshalled" and "demarshalled" (i.e. serialised and deserialised) when communicating between different languages, even on the same machine. With.NET, different languages use the same binary layout and so can just share the memory.
This represents a unique opportunity for language researchers to get their language used. Software is increasingly being written based on a component model, but implementations of technologies like COM and CORBA impose a significant overhead when moving from one language to another. The.NET system means that you can mix and match languages without the associated performance impact. If you think it's easier to write your GUI in Java, your AI engine in Mercury and your time-critical data logging stuff in C++, you can do that, and you don't pay such a huge price for the mix. This means that programmers can try out new programming languages in their projects without having to go "all the way".
The Open Source community must take note of this! Admittedly we haven't seen much in the way of actual technical detail about.NET yet, and Microsoft's implementation might turn out top be hopeless, but the CLR is a good idea.
And now, the obligatory conspiracy theory for the day: As operating system kernels get smaller, moving data between OS components efficiently becomes trickier. The Hurd uses the Mach IDL, which is not unlike the CORBA IDL only much more lightweight, to marshall and demarshall data for the various components, for example. The CLR might represent the first part of a new operating system from Microsoft; one which will eventually replace NT, because it provides a way to build an object oriented OS in multiple languages without the serialisation costs.
Microsoft already has a suitable microkernel which could support CLR. It's called Windows CE.
They also have a motive. As we all know, Microsoft only "innovates" when they're trying to kill off competition. (For example, IE to kill off Netscape, Win9X to kill off OS/2, NT to kill off Netware and other similar systems.)
A lot of/., k5, advogato etc readers are not US citizens, and so can't really comment in that kind of forum. In addition, there is the IANAL problem. Many of the submissions (e.g. Time-Warner) contained legal argument (a lot of which turned out to be wrong; read the submission from the Copyright Office to see one example). The average geek cannot be expected to reply to such an argument because they don't know how. I'm sure that more than one bowed out precisely to improve the quality of the submissions past "Uhm... uhh... it's wrong! I don't know why, but it's just WRONG!"
Sometimes people reason, rightly or wrongly, that it's easier to leave this sort of thing to the experts.
I have a copy of the source of glibc-2.0.105 sitting on my hard drive. In inet/rexec.c (amongst other files) what do I see but a file under the BSD licence including the advertising clause. Clearly I have no rights to this code since it cannot be distributed under the GPL.
Thankfully, in 2.1, the advertising clause has been removed. But nonetheless, I expect a full apology from the FSF for breaking the terms of the original BSD licence and forgiveness from the Regents of the University of California so that I can be assured that I may use glibc2 without let or hinderance.
Dear obviously you don't get the point about the GPL.
I get the point totally. That wasn't my point. My point is that the GPL has some controversial bits (e.g. RMS' preferred definition of a "derivative work" or "work based on the program") which have not been tested in court. A judge, given argument by lawyers acting for those with less respect for the wishes of the author than you and me, might decide that those terms mean something different than what RMS thinks.
That "someone" would now use and link to software which he didn't even make, and later clame that he doesn't want to respect wishes of authors of that free software. That is
criminal, as "someone" would be out of exchange. He would be taking something without giving, what is expected, back.
It would not be "criminal", as copyright is a civil matter. I dop agree it would be morally reprehensible to effectively steal from the community in this way. Whether or not it's legal is another question, and it's a question that won't be closed until it's tested.
The thing about linking with GPL'd libraries rests on RMS' interpretation of what constitutes a derivative work. He thinks that a program that uses a library is a derivative work of that library. He has received legal advice that this is the case, but it's far from clear and certainly untested, and may vary from country to country. I respect his wishes, because I'm a nice person like that, but someone with fewer manners and more lawyers may be able to challenge this successfully.
One other point which is occasionally raised is that when including a library, the header file which is included forms part of the code which includes it. I think that's a red herring, because C and C++ stand alone as languages which use this mechanism, and the strength of the GPL should not depend on the programming language used.
...as is BeOS, and as should every desktop and server operating system, but that's another rant...
[...] and the Be kernel lacks 80% of the function and features of a Linux kernel. It's not exactly a fair comparison or even a valid one.
But that's the point! You don't need all that bloat in the kernel. You might argue that unlike some OSes we won't mention, you don't need your GUI in the kernel, and I'd say you were right. But you don't need USB support, file system drivers, device drivers, networking or swapping in there either. That 80% (in the case of QNX it's probably more like 95%) can be implemented in user land.
Or, to turn the argument around: Do you really want to have to reboot to install a new networking protocol? Is it any different from having to reboot to install an application?
The source for POVRay is freely available, right? Then it's open source.
I don't think you're being helpful with the terminology. The term "open source", "opensource", "Open Source" or however you spell it is universally understood by slashdotters to mean that its licence complies with the Open Source definition. POV-Ray does not comply, therefore it is not open source.
Yes, POV-Ray's source is "freely available" for some definition of "freely" (that's a can of worms in itself, so let's not go too farther down that track). So is PGP's source, but you wouldn't call PGP "open". Merely being available doesn't make it open. In particular, it's not open if it discriminates between commercial and non-commercial redistribution.
If you mean to say the source is available at no cost, say that. Please don't confuse well-understood terminology by redefining it.
Others have mentioned MkLinux, which is a version of Linux which runs on top of the Mach microkernel. By modern standards, Mach isn't so "micro". On my Hurd partition, the gnumach executable weighs in at 726kb compressed, and about 1.6Mb uncompressed. Compare with ntoskrnl.exe, which is 907kb on NT 4.0 enterprise server. Both of these are comparable with the size of an average linux or BSD monolithic kernel, which sit around the megabyte mark uncompressed.
The QNX kernel, on the other hand, is something like 8kb in size, which fits in the cache of a 486. Even the BeOS kernel is only something like 78kb compressed. Not that size is the only concern (so my wife keeps telling me), but in general, the less code that runs in the kernel, the easier it is to say something about how secure it is. Also the easier it is to change things while the system is running.
I hate to sound like Andrew Tanenbaum, but MkLinux and the Hurd are now obsolete too. Mach belongs to the old school of microkernels which were popular 10-15 years ago, but with the benefit of hindsight, we know better. Nowadays, for example, we know that you don't even need to do VM swapping inside the kernel.
There are some projects of note which may result in a product which is cleaner and better designed than Linux. Here are some suggestions:
chaos, which has a very clean, pragmatic design without sacrificing its microkernel philosophy
I have to put in a plug for Discipline Global Mobile, which has signed a lot of progressive rock greats (Robert Fripp/King Crimson, Bill Bruford, Peter Hammill and Tony Levin to name but a few). Check out their business aims to get a feel for their attitude towards the recording industry.
From their FAQ:
Q. Do you have anything to do with the mainstream music industry?
A. Yes, but more so in performance than records. And even there a lot of my performance
activity is independent.
Once my view was to work for change from within. But at EG over a period of 21 years I
became marginalised and sidelined to the partners' main interests, and my affairs were closely
managed, even controlled. Now, I work alongside.
One day the dinosaurs will fall into a tar pit. There has to be a structure to carry on at that
point. Mammals didn't kill off the dinosaurs: the weather changed. There are some people in
positions of power who see that the weather is changing, and some of them are taking what
they can for themselves before things collapse. This is short-sighted: we all breathe the same
air and drink the same water.
The most rigid, inflexible and controlling structures are the first to go when the ground shakes.
Discipline is flexible, adaptable, transparent, responsive and participatory.
Looks like someone hasn't read the licence. POV is not even close to being open source. In fact, there's almost nothing that you can do with it apart from use it or patch it.
Just look at some of these bits of the licence:
These archives must not be re-archived using a different method without the explicit permission of the POV-Team. You may rename the archives only to meet the file name conventions of your system or to avoid file name duplications but we ask that you try to keep file names as similar to the originals as possible.
[...]
You must distribute a FULL PACKAGE of files as described in the next section. No portion of this package may be separated from the package and distributed separately other than under the conditions specified in the provisions given below.
[...]
Any bundling with books,magazines or other print media is permitted if the total cost of the book or magazine with CD is less than the $48.00 limit. Bundling with more expensive publications or distributions should use the commercial rules.
[...]
A "custom version" is defined as a fully functional version of POV- Ray with all existing features intact. ANY OTHER USE OF ANY POV- Ray SOURCE CODE IS EXPRESSLY PROHIBITED. The POV-Team does not license source code for any use outside POV-Ray. No portion of the POV-Ray source code may be incorporated into another program unless it is clearly a custom version of POV-Ray that includes all of the basic functions of POV-Ray.
[...]
Vendors wishing to bundle POV-Ray with commercial software (including shareware) or other distribution not already described above must first obtain explicit permission from the POV-Team. Such permission is rarely granted. The POV-Team will decide if such distribution will be allowed on a case-by-case basis and may impose certain restrictions as it sees fit.
I should also note that POV-Ray is fairly feature-free from the point of view of the entertainment industry. Its filtering is poor and it has no support for features demanded by the high-end such as custom illumination models. Besides, it's a ray tracer and therefore slow.:-)
This probably won't get read, since this article is down the list a bit, but here's my own unscientific test to have a go at the truth or falsity of this claim:
They claim this will save 80%-90% hard drive space. I'm very skeptical of that, even if it is all they are claiming it is.
Just to check it out, I performed the following test on my linux workstation. It's a fairly vanilla Debian distro with KDE and lots and LOTS of source code. Oh, and I also have a minimal Debian GNU/HURD partition mounted. I cleaned out/tmp before I started, as I had been running some custom code which filled it up recently. I hope this doesn't skew the results too much.
Here's the output of df:
Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda2 5431591 2293311 2857049 45%/ /dev/hda6 1016880 29781 934559 3%/gnu
The test I performed was:
Produce an MD5 hash of every file on the filesystem, excluding symbolic lists. This command does the job: find / -fstype ext2 -type f -exec md5sum {} \; >/tmp/md5sig
That takes a while, so in the mean time, write a small perl script which parses the output of that and spits out filenames for which there is already a file with the same hash. (Easy to write. Left as an exercise.)
Add up the sizes of the files which result. This incantation will do the job: perl coalesce.pl </tmp/md5sig | xargs wc --bytes
Most of the duplicate files are in/usr/share/{zoneinfo,locale,doc} (no surprises there; I have two OSes with the same Debian infrastructure!). There is some duplication in/usr/share/apps thanks to KDE (lots of duplication in the i18n stuff). There's some duplication in the perl libraries between/usr/local/lib/site_perl and/usr/local/lib/i386-linux/. Interestingly there was some duplication in my Netscape cache. I also discovered that I still had an old kernel in source form sitting around, so all of the headers were duplicate.
Including all that, the final result is... 162536752 bytes, or 6.8% of used space. I therefore conclude that while it may help a little, the true savings are nowhere near 80-90%.
I can see that this is a good idea... however, it seems to me that generally you want to provide the best QOS you can.
Generally, yes. For some applications, you want guaranteed QoS for some services and the best that you can get for everything else.
The point is to give certain processes QoS guarantees in the presence of other processes which might be scrambling for the CPU. The point is not to deny QoS needlessly, though you could certainly implement a scheduler which did that if you wanted to (a generalisation of setrlimit). If a process is granted 20% of the CPU bandwidth, it might get more, but it will get at least 20%, guaranteed.
One example is that of serving streaming media, where the data must be delivered at the correct rate. "The best QoS you can" just isn't good enough. You need real guarantees otherwise the application is useless.
Some routers (e.g. ATM switching) have very similar constraints. Indeed, if you've ever tried to burn a CD and found it ruined because you couldn't keep the writer's buffer full (maybe a cron job started running part-way through the process), start campaigning for QoS guarantees in your favourite OS now.:-)
I'm curious exactly what it means for an operating system to be object oriented.
Think of a CORBA ORB. That's the kind of picture you should have. An operating system kernel really should just pass messages around from processes to other processes or to devices or to system services, maintaining security policy along the way.
Encapsulation is a snap for any OS worthy of the name. For files, you can work at the file descriptor level or the file handle level. Very few applications work by device registers these days. Unix does a nice job of stretching the file abstraction fit over things like serial ports.
Linux doesn't provide encapsulation at the kernel level. A file system driver or network card driver, for example, is allowed to peek inside the scheduler under Linux. That breaks encapsulation.
Inheritance is a tricky one.
Linux (like all modern OSes) provides inheritance, as it must. Whenever you say "serial ports are a kind of char device" you are invoking the idea of inheritance. The Hurd makes this a bit more explicit, thus making it theoretically possible to add new kinds of devices without having to add functionality to the kernel. It's also theoretically more secure (and I stress the "theoretically") since less things have access to the kernel's internal data structures. There have been some attacks in Linux based on this weakness of loadable kernel modules (the heroin attack springs to mind) which the Hurd should not have.
I thought that "real-time" had to do with getting raw access to resources. This way, I can know *exactly* when data arrives at my serial port, for example.
Raw access to resources is a speed concern, not a real-time concern. If there is a guaranteed maximum time that you have to wait between sending data to the serial port and it arriving, then that is a real-time operation, no matter how long that guaranteed time is.
Of course, speed will probably make the difference between choosing one real-time system over another, but it's the guarantee which makes the system real-time, not the speed.
The EROS FAQ mentions that there is no such thing as 'root'; there is no user who has total authority. This is a double-edged sword. While the absence of root makes compromising a system difficult (since there's no Obvious Target to gain access to), it also prevents a legitimate user from manipulating or killing processes that simply refuse to grant the capability.
EROS has no concept of root because the kernel has no concept of a user at all. In a capability-based OS with POSIX, users are part of the executive (or the Hird of Unix-Replacing Daemons). There's no reason why the executive can't implement a root user, i.e. one with the capability to do anything.
One benefit of using capabilities rather than users and groups is that it's possible to restrict your own access. Suppose I want to run a program which I don't necessarily trust. I can drop myself into a "sub-user" with all my previous permissions, except that I have no rights to write to the file system, and run it safe in the knowledge that nothing is going to be trashed. Just like chroot() only much more flexible.
Finally, a free realtime OS which is useful for more than embedded applications. I've been waiting for something like it for a couple of years now.
BeOS has shown us all that realtime quality of service guarantees are important for modern media applications, which sadly is something that other free OS projects haven't realised. (Not a criticism of them; it's also important to achieve lots of raw speed in web and database serving. At least their approach is better than Microsoft's. "Multimedia performance not good enough, eh? Let's just stick the GDI into the kernel. It still counts as a microkernel if it's 14Mb in size, right?")
Maybe finally I can use a free OS to burn a CD and watch an animation while waiting for that compile to finish without fear of the CD being ruined. Maybe finally I can use a free OS to mix 16 channel audio. I can hardly wait for EROS to get POSIX support.
This is probably flamebait, so take it for what it's worth.
Does anyone else feel kinda uneasy about this?
The US government (and the US sheeple too) seem to base their idea of what constitutes good policy around revenge. "You step on our toe, we kick your ass." In fact, that's a pretty good summary of US millitary policy for the last 250 years - or at least it sums up how all the battles/wars which the US has fought started. Wars which the US has lost (e.g. 1812 invasion of Canada, Vietnam) are probably remembered differently with hindsight.
Disclaimer: It would be very easy for me to say how proud this makes me feel to be an Australian, but let's be honest. Any nation who adopts the position of "most powerful nation on Earth" (however that is defined at that point in history) would have done the same. That's human nature.
Now don't get me wrong here. I'm as concerned about Micros~1 as the next person (and on Slashdot, it's a pretty safe bet as to what the next person thinks about this!), and to say that I'm annoyed as to what they have done to the software industry is an understatement at best. It just leaves a bad taste in my mouth when the wolves start baying for blood. The only thing I can think of that's worse than a software industry being controlled by the likes of Micros~1 is a software industry being controlled by a lynch mob. I can almost see the pitchforks and flaming torches being handed out as we speak...
Slashdot Mirror
Thanks for picking the nit.
Incidentally, I have no reason to disbelieve you (I'm sure you know more about COM than I do), but I'm puzzled: How do you mix C++ and Java data types (to pick two examples) without marshalling?
BTW, did you get a trip to Redmond, Tyse? :-)
It's only a conspiracy theory, of course, but the suggestion was half serious.
CE is the only operating system that Microsoft has worked on (unless you count OS/2) which could be called truly "innovative". The only way that you can get Office (even if it is the cut down edition) to run on a palmtop is to use an OS with almost no bloat. CE has almost no bloat. All you need is a bloatless OS and the CLR and you have a nice framework for a new OS.
Besides, the issue as I see it is not "CE to replace NT", but "something new to try to kill off competing OSes". It might not be CE. CE would, after all, need some extensive modification (at the moment it is targeted to architectures without MMUs, for example) to compete. They might decide it's better to buy a company with a suitable microkernel.
Disclaimer: I'm a former Mercury developer. I left the project before Microsoft approached the Mercury guys, but after a fairly scary dinner with James Plomondon, whose job title at the time was "Principal Java Evangelist, Microsoft Corporation". It's a long story, which can be told some other time.
Anyway, .NET has, as part of the system, a common language runtime (CLR) for different programming languages (and I mean very different programming languages; C++, ML, Perl, Haskell and Mercury are about as mutually different as languages can get). This distinguishes it from COM/CORBA where objects must be "marshalled" and "demarshalled" (i.e. serialised and deserialised) when communicating between different languages, even on the same machine. With .NET, different languages use the same binary layout and so can just share the memory.
This represents a unique opportunity for language researchers to get their language used. Software is increasingly being written based on a component model, but implementations of technologies like COM and CORBA impose a significant overhead when moving from one language to another. The .NET system means that you can mix and match languages without the associated performance impact. If you think it's easier to write your GUI in Java, your AI engine in Mercury and your time-critical data logging stuff in C++, you can do that, and you don't pay such a huge price for the mix. This means that programmers can try out new programming languages in their projects without having to go "all the way".
The Open Source community must take note of this! Admittedly we haven't seen much in the way of actual technical detail about .NET yet, and Microsoft's implementation might turn out top be hopeless, but the CLR is a good idea.
And now, the obligatory conspiracy theory for the day: As operating system kernels get smaller, moving data between OS components efficiently becomes trickier. The Hurd uses the Mach IDL, which is not unlike the CORBA IDL only much more lightweight, to marshall and demarshall data for the various components, for example. The CLR might represent the first part of a new operating system from Microsoft; one which will eventually replace NT, because it provides a way to build an object oriented OS in multiple languages without the serialisation costs.
Microsoft already has a suitable microkernel which could support CLR. It's called Windows CE.
They also have a motive. As we all know, Microsoft only "innovates" when they're trying to kill off competition. (For example, IE to kill off Netscape, Win9X to kill off OS/2, NT to kill off Netware and other similar systems.)
Watch carefully.
A lot of /., k5, advogato etc readers are not US citizens, and so can't really comment in that kind of forum. In addition, there is the IANAL problem. Many of the submissions (e.g. Time-Warner) contained legal argument (a lot of which turned out to be wrong; read the submission from the Copyright Office to see one example). The average geek cannot be expected to reply to such an argument because they don't know how. I'm sure that more than one bowed out precisely to improve the quality of the submissions past "Uhm... uhh... it's wrong! I don't know why, but it's just WRONG!"
Sometimes people reason, rightly or wrongly, that it's easier to leave this sort of thing to the experts.
So? Your point is?
Bleah. Glibc was of course distributed under the LGPL. Let me try again.
What I have is no rights to distribute code in binary form that uses glibc-2.0.105 under the terms of the GPL. Hope this clears things up.
I still want the apology, though.
I have a copy of the source of glibc-2.0.105 sitting on my hard drive. In inet/rexec.c (amongst other files) what do I see but a file under the BSD licence including the advertising clause. Clearly I have no rights to this code since it cannot be distributed under the GPL.
Thankfully, in 2.1, the advertising clause has been removed. But nonetheless, I expect a full apology from the FSF for breaking the terms of the original BSD licence and forgiveness from the Regents of the University of California so that I can be assured that I may use glibc2 without let or hinderance.
I await my apology.
Haven't you read RFC 1437?
I get the point totally. That wasn't my point. My point is that the GPL has some controversial bits (e.g. RMS' preferred definition of a "derivative work" or "work based on the program") which have not been tested in court. A judge, given argument by lawyers acting for those with less respect for the wishes of the author than you and me, might decide that those terms mean something different than what RMS thinks.
It would not be "criminal", as copyright is a civil matter. I dop agree it would be morally reprehensible to effectively steal from the community in this way. Whether or not it's legal is another question, and it's a question that won't be closed until it's tested.
The thing about linking with GPL'd libraries rests on RMS' interpretation of what constitutes a derivative work. He thinks that a program that uses a library is a derivative work of that library. He has received legal advice that this is the case, but it's far from clear and certainly untested, and may vary from country to country. I respect his wishes, because I'm a nice person like that, but someone with fewer manners and more lawyers may be able to challenge this successfully.
One other point which is occasionally raised is that when including a library, the header file which is included forms part of the code which includes it. I think that's a red herring, because C and C++ stand alone as languages which use this mechanism, and the strength of the GPL should not depend on the programming language used.
...as is BeOS, and as should every desktop and server operating system, but that's another rant...
But that's the point! You don't need all that bloat in the kernel. You might argue that unlike some OSes we won't mention, you don't need your GUI in the kernel, and I'd say you were right. But you don't need USB support, file system drivers, device drivers, networking or swapping in there either. That 80% (in the case of QNX it's probably more like 95%) can be implemented in user land.
Or, to turn the argument around: Do you really want to have to reboot to install a new networking protocol? Is it any different from having to reboot to install an application?
I don't think you're being helpful with the terminology. The term "open source", "opensource", "Open Source" or however you spell it is universally understood by slashdotters to mean that its licence complies with the Open Source definition. POV-Ray does not comply, therefore it is not open source.
Yes, POV-Ray's source is "freely available" for some definition of "freely" (that's a can of worms in itself, so let's not go too farther down that track). So is PGP's source, but you wouldn't call PGP "open". Merely being available doesn't make it open. In particular, it's not open if it discriminates between commercial and non-commercial redistribution.
If you mean to say the source is available at no cost, say that. Please don't confuse well-understood terminology by redefining it.
Others have mentioned MkLinux, which is a version of Linux which runs on top of the Mach microkernel. By modern standards, Mach isn't so "micro". On my Hurd partition, the gnumach executable weighs in at 726kb compressed, and about 1.6Mb uncompressed. Compare with ntoskrnl.exe, which is 907kb on NT 4.0 enterprise server. Both of these are comparable with the size of an average linux or BSD monolithic kernel, which sit around the megabyte mark uncompressed.
The QNX kernel, on the other hand, is something like 8kb in size, which fits in the cache of a 486. Even the BeOS kernel is only something like 78kb compressed. Not that size is the only concern (so my wife keeps telling me), but in general, the less code that runs in the kernel, the easier it is to say something about how secure it is. Also the easier it is to change things while the system is running.
I hate to sound like Andrew Tanenbaum, but MkLinux and the Hurd are now obsolete too. Mach belongs to the old school of microkernels which were popular 10-15 years ago, but with the benefit of hindsight, we know better. Nowadays, for example, we know that you don't even need to do VM swapping inside the kernel.
There are some projects of note which may result in a product which is cleaner and better designed than Linux. Here are some suggestions:
I have to put in a plug for Discipline Global Mobile, which has signed a lot of progressive rock greats (Robert Fripp/King Crimson, Bill Bruford, Peter Hammill and Tony Levin to name but a few). Check out their business aims to get a feel for their attitude towards the recording industry.
From their FAQ:
Looks like someone hasn't read the licence. POV is not even close to being open source. In fact, there's almost nothing that you can do with it apart from use it or patch it.
Just look at some of these bits of the licence:
[...]
[...]
[...]
[...]
I should also note that POV-Ray is fairly feature-free from the point of view of the entertainment industry. Its filtering is poor and it has no support for features demanded by the high-end such as custom illumination models. Besides, it's a ray tracer and therefore slow. :-)
This probably won't get read, since this article is down the list a bit, but here's my own unscientific test to have a go at the truth or falsity of this claim:
Just to check it out, I performed the following test on my linux workstation. It's a fairly vanilla Debian distro with KDE and lots and LOTS of source code. Oh, and I also have a minimal Debian GNU/HURD partition mounted. I cleaned out /tmp before I started, as I had been running some custom code which filled it up recently. I hope this doesn't skew the results too much.
Here's the output of df:
Filesystem 1k-blocks Used Available Use% Mounted onThe test I performed was:
Most of the duplicate files are in /usr/share/{zoneinfo,locale,doc} (no surprises there; I have two OSes with the same Debian infrastructure!). There is some duplication in /usr/share/apps thanks to KDE (lots of duplication in the i18n stuff). There's some duplication in the perl libraries between /usr/local/lib/site_perl and /usr/local/lib/i386-linux/. Interestingly there was some duplication in my Netscape cache. I also discovered that I still had an old kernel in source form sitting around, so all of the headers were duplicate.
Including all that, the final result is... 162536752 bytes, or 6.8% of used space. I therefore conclude that while it may help a little, the true savings are nowhere near 80-90%.
Generally, yes. For some applications, you want guaranteed QoS for some services and the best that you can get for everything else.
The point is to give certain processes QoS guarantees in the presence of other processes which might be scrambling for the CPU. The point is not to deny QoS needlessly, though you could certainly implement a scheduler which did that if you wanted to (a generalisation of setrlimit). If a process is granted 20% of the CPU bandwidth, it might get more, but it will get at least 20%, guaranteed.
One example is that of serving streaming media, where the data must be delivered at the correct rate. "The best QoS you can" just isn't good enough. You need real guarantees otherwise the application is useless.
Some routers (e.g. ATM switching) have very similar constraints. Indeed, if you've ever tried to burn a CD and found it ruined because you couldn't keep the writer's buffer full (maybe a cron job started running part-way through the process), start campaigning for QoS guarantees in your favourite OS now. :-)
Think of a CORBA ORB. That's the kind of picture you should have. An operating system kernel really should just pass messages around from processes to other processes or to devices or to system services, maintaining security policy along the way.
Linux doesn't provide encapsulation at the kernel level. A file system driver or network card driver, for example, is allowed to peek inside the scheduler under Linux. That breaks encapsulation.
Linux (like all modern OSes) provides inheritance, as it must. Whenever you say "serial ports are a kind of char device" you are invoking the idea of inheritance. The Hurd makes this a bit more explicit, thus making it theoretically possible to add new kinds of devices without having to add functionality to the kernel. It's also theoretically more secure (and I stress the "theoretically") since less things have access to the kernel's internal data structures. There have been some attacks in Linux based on this weakness of loadable kernel modules (the heroin attack springs to mind) which the Hurd should not have.
Raw access to resources is a speed concern, not a real-time concern. If there is a guaranteed maximum time that you have to wait between sending data to the serial port and it arriving, then that is a real-time operation, no matter how long that guaranteed time is.
Of course, speed will probably make the difference between choosing one real-time system over another, but it's the guarantee which makes the system real-time, not the speed.
From the FAQ:
Admittedly this point is not stressed on the EROS web site nearly as much as the capability system is.
EROS has no concept of root because the kernel has no concept of a user at all. In a capability-based OS with POSIX, users are part of the executive (or the Hird of Unix-Replacing Daemons). There's no reason why the executive can't implement a root user, i.e. one with the capability to do anything.
One benefit of using capabilities rather than users and groups is that it's possible to restrict your own access. Suppose I want to run a program which I don't necessarily trust. I can drop myself into a "sub-user" with all my previous permissions, except that I have no rights to write to the file system, and run it safe in the knowledge that nothing is going to be trashed. Just like chroot() only much more flexible.
Finally, a free realtime OS which is useful for more than embedded applications. I've been waiting for something like it for a couple of years now.
BeOS has shown us all that realtime quality of service guarantees are important for modern media applications, which sadly is something that other free OS projects haven't realised. (Not a criticism of them; it's also important to achieve lots of raw speed in web and database serving. At least their approach is better than Microsoft's. "Multimedia performance not good enough, eh? Let's just stick the GDI into the kernel. It still counts as a microkernel if it's 14Mb in size, right?")
Maybe finally I can use a free OS to burn a CD and watch an animation while waiting for that compile to finish without fear of the CD being ruined. Maybe finally I can use a free OS to mix 16 channel audio. I can hardly wait for EROS to get POSIX support.
We were discussing you --not me.
This is probably flamebait, so take it for what it's worth.
Does anyone else feel kinda uneasy about this?
The US government (and the US sheeple too) seem to base their idea of what constitutes good policy around revenge. "You step on our toe, we kick your ass." In fact, that's a pretty good summary of US millitary policy for the last 250 years - or at least it sums up how all the battles/wars which the US has fought started. Wars which the US has lost (e.g. 1812 invasion of Canada, Vietnam) are probably remembered differently with hindsight.
Disclaimer: It would be very easy for me to say how proud this makes me feel to be an Australian, but let's be honest. Any nation who adopts the position of "most powerful nation on Earth" (however that is defined at that point in history) would have done the same. That's human nature.
Now don't get me wrong here. I'm as concerned about Micros~1 as the next person (and on Slashdot, it's a pretty safe bet as to what the next person thinks about this!), and to say that I'm annoyed as to what they have done to the software industry is an understatement at best. It just leaves a bad taste in my mouth when the wolves start baying for blood. The only thing I can think of that's worse than a software industry being controlled by the likes of Micros~1 is a software industry being controlled by a lynch mob. I can almost see the pitchforks and flaming torches being handed out as we speak...