One of the fundamental units of
a Microkernel architecture is a uniform network/port based
communcations subsystem.
That's one way of implementing a microkernel, but it's hardly the defining feature.
A microkernel is simply a system in which only minimal functionality is placed in the kernel. As a result, you need a better IPC mechanism than is present in most monolithic kernels, but as long as it's effective, it can take any form.
I don't know a lot about it
So perhaps you shouldn't be stating opinion as fact, hmm?
but it has NOTHING to do with CORBA.
One can implement a microkernel using CORBA as the primary means of IPC.
Certainly CORBA services might run as any other Microkernel service but this would be hurrendously slow to use_as the primary means of inter-proccess communication.
I suppose you can provide us with a link to a paper where this has been thoroughly examined? Or are you just spouting nonsense again?
If the ORB is in the kernel (if it's not, then it's not really the primary means of IPC now, is it?) and designed to take advantage of that situation (through the use of virtual memory manipulation and direct access to the address space of both processes) then it should be able to provide adequate performance, and a small performance loss can easily be made up for with a dramatic increase in flexibility.
Even if you don't want to use RPCs, you can still use things like CORBA to formalize the structure of the messages that you pass and abstract the details away from the programmer.
The exact range of char, short, and long can
also vary. The numbers you quote are *almost*
the minimum ranges specified by C99 (not sure about
C89), except that you need to add one to the lower
bound of the signed types, as ANSI C does not
assume two's complement.
However, implementations are free to use any
larger range. For instance, on 64-bit platforms,
long is usually 64-bit.
I'm not sure if it's allowed by ANSI C or not,
but with gcc (and probably any compiler that
does not have an integrated preprocessor) you
can #define reserved words. Go ahead and try it.
The only problem I can think of when installing
software outside the package management system
(such as from source) is that the package
manager won't know it's installed, so it
may overwrite your version if a packaged
version gets installed (possibly by upgrading
an older version that was installed with a package).
If no older version of the package was installed,
the dependency won't be satisfied if you try to install a package that depends on it.
In the former case, you can hold the package so things like apt-get won't automatically upgrade it. In the latter, you can install anything that depends on it from source, force the dependencies, or create a dummy package that provides the package you installed manually.
It's redundant because the same IBM PS/2
comments have been made in *every single
playstation 2 story on slashdot*. It
was funny the first time. It isn't funny
anymore.
You can be as pissed as you want, but those
two hands are generally not going to do you
much good when you're being assaulted by someone
that does have a gun, and doesn't care that
it is illegal.
The only case where compilation time isn't constant would be a solution to a problem where you're generating code for
each instance of the problem, and the size of the code varies with the problem size. That's pretty unusual though.
You must not have seen the International
Obfuscated C Code Contest winner that solved
the towers of hanoi using the C preprocessor.:-)
Whether it can achieve that rate depends
on how much local parallelism exists in the code;
it does not depend on whether the
instruction scheduling is done by the CPU or
the compiler.
Copyright law doesn't really recognize the sort of derivative work that RMS was trying to encourage, though - normally you can't take someone else's book and fix typos, add footnotes, or move chapters around and then publish it yourself.
If copyright law didn't recognize that sort of derivative work, you could make and distribute those modifications. Copyright law is the only thing that forbids it.
Plus, what if the BSD licensors wanted to use a different definition of
"derived"?
Too bad. The definition of a derived work has little to do with the permissions granted by a license; it determines whether the license applies to begin with. However, I doubt the BSD licensors really care about it the way Stallman does.
Is
the whole "libraries are derived works" thing an edict straight from RMS
Yes. I'm sure that if RMS had his way, it would be illegal to
connect to a non-GPL server with a GPL client (or vice versa)
unless a compatible and functionally equivalent GPL server exists.
The reason that it is RMS that decides what is and what isn't a derivative work under the GPL is that RMS wrote the
GPL and has the power to change it.
But RMS does NOT define copyright law,
which is what gives him the right to impose the restrictions in the GPL to begin with. A license can certainly waive exclusive rights which the law reserves to the copyright holder, but it cannot claim exclusive rights that the law does not permit it to claim. The closest it can come is denying other rights (such as the ability to distribute the GPLed library along with the non-GPL product) if such provisions are contained in the license.
There are plenty of other companies that charge you for
the privilege of linking against their libraries.
Does the linking that requires royalties involve
distributing the library in any way, either
statically linked or as a bundled component?
Or do these companies require a contract that mandates royalties before the library is given to the developers?
Fair use is not a loophole! It is a necessary restriction on the privilege of copyright.
Besides, fair use does not make the sort of
infringement that commonly occurs on Napster legal.
This is were we got the DMCA from.
Which is why it is such a bad law. Without fair
use, the copyright holder has far too much power
over the use of the work. The purpose of copyright is to provide an incentive to people to create works; once sufficient rights are reserved to establish that incentive, it is not in the best interest of society to reserve more rights.
if your program depends in large part on
functionality provided by a FSF-provided library, how can you really say the ultimate operation of your program is not
a derivative of the FSF's work?
The operation of the whole may be derivative, but
in the case of dynamic libraries the whole does
not exist until the user runs the binary. IANAL,
but I can't imagine how simply adhering to an interface makes software derivative of the implementation of the interface. If there's actual code in the header files, though, that would be different, but that is often not the case.
The defining line that RMS has chosen to defend the GPL at seems to be the boundaries of one process
Although shouldn't it be copyright law, rather than RMS, that dictates what is and is not a derivative work? What if Microsoft slipped something into the Windows EULA saying that all programs that call the windows DLLs are derivative of those DLLs, and thus royalties must be paid to Microsoft for the distribution of the "derived" work?
How do buffer overflows create security problems anyway? Doesn't the program just segfault?
If you overflow the buffer with random
data, then yes, it just segfaults. If however,
you fill it with the right data, you can
manipulate the return address of the function
and thus run arbitrary code on the remote machine.
Bzzt. First, 11.8 million cubic inches is around 6800
cubic feet. You need to divide by twelve *cubed*.
Second, the typical roll of dimes is $5, not $10,
so the total (assuming a roll of dimes is a cubic
inch) is around 13600 cubic feet. Still a lot,
but nowhere near 916000. Pennies, on the other
hand, would require ten times as many rolls, and
each roll would be larger.
I'm plenty familiar with UNIX filesystems, Thank You Very Much.
Yes, sockets have file descriptors and can be operated upon with many of the same system calls, but that doesn't mean a damned thing when it comes to security, since they don't exist in the filesystem namespace (other than UNIX domain sockets, of course, but that's not particularly relevant to this discussion).
So please, if sockets are "just more files in UNIX",
tell me how I can set permissions such that a given process can not create one at all? I can do that with files. As for "everything is a file", see my prior post for a list of things which are NOT a file in any UNIX I've seen.
Oh, and exactly what UNIX-like system differentiates between text and binary files at the filesystem level?
Oh? So where do I set file permissions on IP sockets? They behave like files in some ways, but not in others (in particular, they are not initially accessed via the filesystem namespace). And how exactly are things like semaphores, message queues, memory (other than raw physical or kernel memory), processes (/proc doesn't count), threads, signals, the scheduler, or higher level items such as user-interface widgets in any way represented by a file in UNIX or UNIX-like systems? They aren't. And even of those things which are files in UNIX, except for genuine files the protection mechanism is often far too coarse-grained to accomplish certain tasks. How, in UNIX, would I give a process the right to read raw data off a CD without giving it the right to make noise if an audio CD happens to be in the drive, or vice versa?
How much is the version of Solaris you would use on a Workstation? I'm sure that more than $189 which after all is a
recommended retail price. Prices for OEMs are much lower.
Actually, it's $75 for media, which you can
install on as many machines as you like (as long
as none of them have more than 8 processors, which
is a reasonable assumption for a workstation).
Or even design an OS with networking and multiuser access in mind? (Wow, that sure would be awfully
tough...fifteen years ago, before it had been done almost every one of the flavors of UNIX.)"
Sorry, but UNIX (at least, most of them) can't
do what was suggested, which was to completely
deny networking, or impose limits on networking,
to specific applications. UNIX security is primarily
concerned with files, and if it's not a file, unless
a special hack has been provided, you can't protect access to it. For true flexibility in these matters, you need to turn to a capability-based OS.
show the judge a
pile of press releases from companies like Microsoft,IBM,Corel etc. saying how they are at the forefront of the open
source movement
Umm, how exactly is Microsoft in any way
involved with open source (other than competing with it, of course), let alone "at the forefront of the open source movement"? Granted, they've absorbed some BSD code here and there, but they're not exactly public about it, and AFAIK they don't release any of their own products as open source.
Debian *potato* uses 2.2. Debian *slink* uses 2.0. Potato should be released Real Soon Now, and has been usable for a *long* time. The user has a choice whether to go with the latest software or to go with a thoroughly tested system; this is a good thing, not something that qualifies it as a "grave".
That's one way of implementing a microkernel, but it's hardly the defining feature. A microkernel is simply a system in which only minimal functionality is placed in the kernel. As a result, you need a better IPC mechanism than is present in most monolithic kernels, but as long as it's effective, it can take any form.
I don't know a lot about it
So perhaps you shouldn't be stating opinion as fact, hmm?
but it has NOTHING to do with CORBA.
One can implement a microkernel using CORBA as the primary means of IPC.
Certainly CORBA services might run as any other Microkernel service but this would be hurrendously slow to use_as the primary means of inter-proccess communication.
I suppose you can provide us with a link to a paper where this has been thoroughly examined? Or are you just spouting nonsense again?
If the ORB is in the kernel (if it's not, then it's not really the primary means of IPC now, is it?) and designed to take advantage of that situation (through the use of virtual memory manipulation and direct access to the address space of both processes) then it should be able to provide adequate performance, and a small performance loss can easily be made up for with a dramatic increase in flexibility.
Even if you don't want to use RPCs, you can still use things like CORBA to formalize the structure of the messages that you pass and abstract the details away from the programmer.
However, implementations are free to use any larger range. For instance, on 64-bit platforms, long is usually 64-bit.
I'm not sure if it's allowed by ANSI C or not, but with gcc (and probably any compiler that does not have an integrated preprocessor) you can #define reserved words. Go ahead and try it.
In the former case, you can hold the package so things like apt-get won't automatically upgrade it. In the latter, you can install anything that depends on it from source, force the dependencies, or create a dummy package that provides the package you installed manually.
Umm, how exactly is Debian a luser distro?
It's redundant because the same IBM PS/2 comments have been made in *every single playstation 2 story on slashdot*. It was funny the first time. It isn't funny anymore.
Actually, it's "10/19/00" in the USA, not "10.19.00".
You've got yourself a nice little contradiction there... :-)
You can be as pissed as you want, but those two hands are generally not going to do you much good when you're being assaulted by someone that does have a gun, and doesn't care that it is illegal.
You must not have seen the International Obfuscated C Code Contest winner that solved the towers of hanoi using the C preprocessor. :-)
Whether it can achieve that rate depends on how much local parallelism exists in the code; it does not depend on whether the instruction scheduling is done by the CPU or the compiler.
--
If copyright law didn't recognize that sort of derivative work, you could make and distribute those modifications. Copyright law is the only thing that forbids it.
Plus, what if the BSD licensors wanted to use a different definition of "derived"?
Too bad. The definition of a derived work has little to do with the permissions granted by a license; it determines whether the license applies to begin with. However, I doubt the BSD licensors really care about it the way Stallman does.
Is the whole "libraries are derived works" thing an edict straight from RMS
Yes. I'm sure that if RMS had his way, it would be illegal to connect to a non-GPL server with a GPL client (or vice versa) unless a compatible and functionally equivalent GPL server exists.
--
But RMS does NOT define copyright law, which is what gives him the right to impose the restrictions in the GPL to begin with. A license can certainly waive exclusive rights which the law reserves to the copyright holder, but it cannot claim exclusive rights that the law does not permit it to claim. The closest it can come is denying other rights (such as the ability to distribute the GPLed library along with the non-GPL product) if such provisions are contained in the license.
There are plenty of other companies that charge you for the privilege of linking against their libraries.
Does the linking that requires royalties involve distributing the library in any way, either statically linked or as a bundled component? Or do these companies require a contract that mandates royalties before the library is given to the developers?
--
Fair use is not a loophole! It is a necessary restriction on the privilege of copyright. Besides, fair use does not make the sort of infringement that commonly occurs on Napster legal.
This is were we got the DMCA from.
Which is why it is such a bad law. Without fair use, the copyright holder has far too much power over the use of the work. The purpose of copyright is to provide an incentive to people to create works; once sufficient rights are reserved to establish that incentive, it is not in the best interest of society to reserve more rights.
--
--
The operation of the whole may be derivative, but in the case of dynamic libraries the whole does not exist until the user runs the binary. IANAL, but I can't imagine how simply adhering to an interface makes software derivative of the implementation of the interface. If there's actual code in the header files, though, that would be different, but that is often not the case.
The defining line that RMS has chosen to defend the GPL at seems to be the boundaries of one process
Although shouldn't it be copyright law, rather than RMS, that dictates what is and is not a derivative work? What if Microsoft slipped something into the Windows EULA saying that all programs that call the windows DLLs are derivative of those DLLs, and thus royalties must be paid to Microsoft for the distribution of the "derived" work?
--
If you overflow the buffer with random data, then yes, it just segfaults. If however, you fill it with the right data, you can manipulate the return address of the function and thus run arbitrary code on the remote machine.
--
--
So please, if sockets are "just more files in UNIX", tell me how I can set permissions such that a given process can not create one at all? I can do that with files. As for "everything is a file", see my prior post for a list of things which are NOT a file in any UNIX I've seen.
Oh, and exactly what UNIX-like system differentiates between text and binary files at the filesystem level?
--
--
Actually, it's $75 for media, which you can install on as many machines as you like (as long as none of them have more than 8 processors, which is a reasonable assumption for a workstation).
--
Sorry, but UNIX (at least, most of them) can't do what was suggested, which was to completely deny networking, or impose limits on networking, to specific applications. UNIX security is primarily concerned with files, and if it's not a file, unless a special hack has been provided, you can't protect access to it. For true flexibility in these matters, you need to turn to a capability-based OS.
--
Umm, how exactly is Microsoft in any way involved with open source (other than competing with it, of course), let alone "at the forefront of the open source movement"? Granted, they've absorbed some BSD code here and there, but they're not exactly public about it, and AFAIK they don't release any of their own products as open source.
--
--