GNOME ORBit Ported To Linux Kernel 184
Lennie writes: "Some crazy people did this for fun; let's hope it stays that way. There is enough kernelbloat already (or have you been able to compile a 2.4 kernel as zImage?). Nonetheless, lots of fun I'm sure." Of all the ridiculous things, this has got to be at least three of them. Actually the worst part is that I kinda could see this as being useful. I think I'm broken.
Maybe I read a different article... (Score:3)
I'm not sure if I like it or not - the functionality is cool, but the possibility of destabilization is pretty high, and there are lots of security issues.
Re:now you can (Score:1)
Just because something runs in kernel space does not make it faster, it just means less latency between interrupt and application response. This is why microkernel design kinda sucks, if your NIC driver is in user space, then when an interrupt happens, the kernel has to switch to user space then back to kernel space and this is why performace is very bad.
Having GUI functionality in the kernel will not make the GUI any faster, it will just bloat(bloat==unneeded shit) the kernel and lead to frequent crashes. I do think that graphic card drivers should reside in kernel space though, that way they can handle dma/agp/interrupts without having a seperate kernel module and they don't have to worry about using a lock to make sure that only one application will use the graphics hardware at a time. I think that only the bare minimun functionabliliy to exploit the hardware is necessary though.
Matt Newell
Re:This is kinda cool... (Score:2)
Screw CORBA -- give me Java, and I can have RMI-IIOP, SOAP, etc., and much better security, portability, etc. And, it'd be something that no other OS out there has right now -- not Solaris, or the IBM *NIXes, or True64, or Win2k...actually, MacOS-X might have it; I'm not really familiar enough with its kernel architecture to be able to say how deep the Java integration goes.
Re:it's about time... (Score:1)
Mach-like kernels attempt to address this problem by dividing the kernel into "servers".
I love the idea of a microkernel, but it is innefficient by nature and this has been proven time and time again.
Other kernels address it by using languages that have better support for modularization (SML, Java, etc.)
Modularization can be done very efficiently and fairly easily in plain C. I think that C++ could be used in the kernel, but misuse of it's features would lead to disaster.
Matt Newell
It's called optimisation (Score:2)
Should NFS run entirely in user space as well?
In an ideal world, the pure Platonic form of the ideal kernel would not have HTTP. However, in the real world, where mundane things such as performance intrude, there are often good reasons for such compromises. A user-space HTTPD incurs a performance hit as data needs to be copied between kernel space and user space. A kernel-space HTTPD can just send the file buffers out through the network. (Which is why Windows NT is apparently faster than Linux at some web serving tasks.)
The only places where optimisation does not intrude on elegance are purely academic proof-of-concept projects, which never have to see the real world.
Re:Port what ever you frickin' please (Score:2)
You should then get your lilo prompt and be able to boot directly onto your ATA66 drive. Then go into root and hdparm your system til it bleeds
btw, my ATA66 hdparm settings for a Maxtor 30GB 7200RPM HDD:
hdparm -c1 -d1 -W1 -m16 -X68
(somewhat agressive, but it is a toy bp6 w/2x400 oc'd to 533
[root@server linux-2.4.0test10]# hdparm -tT
/dev/hdc:
Timing buffer-cache reads: 128 MB in 1.11 seconds =115.32 MB/sec
Timing buffered disk reads: 64 MB in 2.76 seconds = 23.19 MB/sec
(btw, the sensors package really rr00xx on the bp6...)
Your Working Boy,
Re:Kernel "bloat" (Score:2)
Regardless of what Win2K does, I have a problem with this idea of impeding technological progress by placing arbitrary limits on something like kernel size. Why is 15MB bad while some lesser amount is OK? All you're really saying is that from an economic perspective, right now, you consider that OS's should require less RAM for their kernel. Back in 1985, you would have presumably been criticising any OS that took up more than say 100K of memory, and I would have been similarly pointing out the flaw in your thinking.
Don't fall into the trap of spouting variations on the statement "640K should be enough for anyone!" (alleged Bill Gates quote.)
Re:This is actually pretty cool. (Score:1)
As for sound card sharing, while I haven't looked into this very much, it is probably not difficult to do it using the EsounD daemon [tux.org]. I think I may have tried this before using xmms to play across the network to a remote host. Quite cool if you ask me.
What's your problem? (Score:1)
On the contrary, you would have to grab the patch (since it's unlikely to be part of the kernel tarball), apply it, find the config option to enable it and rebuild. If you had done all that it is because you want to include it and probably with a very good reason.
Re:But is this really bloat? (Score:2)
Well, at least as it stands ...
Security is completely unimplemented. Someone could use corba interfaces to read any file on your system, for example (if the CORBA-FileServer module is installed). Thus, this is really more for prototyping and development than actual real world use.
I don't know how difficult it will be to secure this, but I suspect it will be a daunting task.
Re:why not? (Score:3)
Nothing, but they didn't bring an architecture to the kernel, they just ported ORBit to it. Grafted it in with duct tape and baling twine, really. I don't even see anything valuable coming out of this as a side effect, such as a generic userland/kernel IPC interface like STREAMS or FreeBSD netgraph, just some libc compatibility macro hacks
Oh well, everyone's entitled to their own fun projects.
--
More even! (Score:1)
mdmpoold simulates the serial port of your linux box as serial port of your windows box over a network. Therefore your windows programs can use all types of serial devices connected to or simulated by your linux-box.
Nifty!
MOD THIS GUY UP I'M OUT OF POINTS :-) (Score:1)
Re:This is kinda cool... (Score:2)
Heh!
But you've got it wrong - don't embed the JRE in the kernel. Rather, build the kernel on top of a VM. Of course, it would have to be a better VM than the JRE, otherwise you'd just end up with JavaOS - it would need better support for low-level operations, and a number of performance issues would have to be addressed - e.g. support for offset-based method dispatch a la C++ vtables, in addition to the more dynamic runtime lookup (for all I know, MS .NET does this - scary thought.)
When, in a few years time, you're running a 2GHz Crusoe using its native microcode with 1GB of post-Rambus high-bandwidth RAM, hooked to the Internet over gigabit fiber, this won't seem so farfetched.
Tell it ain't so (Score:1)
Well that sent me screaming and running..
Re:why not? (Score:1)
Re:This Is Actually Cool (Score:1)
You saying that "as long as the pieces are stable" is like saying "as long as people won't lie". An admirable goal but it won't happen.
Kernel should be small, clean and fast. That's the only way to make a stable system. Kernel should be only a very thin abstraction layer over the bare metal. All the rest of the OS (drivers, shells, GUI) should be in the user space.
Re:Kernel "bloat" (Score:2)
This could be useful. (Score:1)
This project is VERY interesting (Score:1)
Suppose system calls get standardized, like 'onclick' in HTML is standardized, it does mean that an Apple can communicate with a PC without much trouble.
CORBA at kernel/low level means new infrastructure, applications could come, and Linux becomes more scalable than it already is!
No, I don't think these people are crazy.
Wrong end of the stick (Score:1)
Right, and it's a good thing that this hack doesn't do that in any way, shape or form
huh? (Score:1)
Re:why not? (Score:1)
The horrible thing is... (Score:2)
Actually, the Hurd is disturbingly like that... it pushes all kinds of functionality traditionally relegated to the kernel into user space, so individual users can run their own filesystems and the like. I think RMS likes the idea because it allows users almost complete freedom to hack their environments, right down to the kernel itself. Personally, when it comes to OS fun, I'd much rather buy a machine of my own than time-share the Hurd with a bunch of maniacal user-space kernel hackers...
Vovida, OS VoIP
Beer recipe: free! #Source
Cold pints: $2 #Product
Re:Kernel "bloat" (Score:2)
Kernel Bloat == Bad (Score:1)
Anyone who's read "Secrets and Lies" knows what this is leading into. Linux becoming as bad as windows.
Cheers.
Re:But is this really bloat? (Score:1)
I have yet seen no good remarks why this wouldn't be a Great Way to get the kernel more modular. Someone have an answer?
On a side issue, I for one, would not hesitate to pay in speed if it means that the kernel becomes more flexible.
Of course, we could always base it on SOAP [microsoft.com] given that we already have such great http support in the kernel...
Re:Win2K memory use (Score:2)
well... (Score:1)
--
Excellent. (Score:5)
With this, and khttpd and the frame buffer support and just a few other patches, I might not have to run in userland ever again!!
Just like DOS!!!
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Re:This Is Actually Cool (Score:1)
That's true. Don't you love it when Java Swing causes your entire NT box to hang? Let's emulate that on Linux as well.
There's alot you can't do with a GUI in UNIX because of the rift between userland and kernelland.
Like what?? (besides another 3 FPS in Quake)
Re:Linux supports ATA/100 (Score:1)
Thanks!
Szo
Re:Corba != GUI (Score:1)
Re:This Is Actually Cool (Score:1)
Making life harder (Score:1)
Plus, since Linux (the kernel, yes) doesn't ship with a kernel debugger, how the heck can we expect people to submit bug reports?
Re:Kernel "bloat" (Score:2)
! Userspace (Score:1)
Re:why not? (Score:1)
mutter... OmniORB ... mutter.
-------------------------------------------
Non-C code in the kernel? (Score:1)
why not? (Score:5)
But then, i'm not a kernel hacker.
Now, now, no need to get snippy (Score:1)
I'm not saying this ORB-in-the-kernel thing is a good idea or a bad one. My point is that in open source aren't we supposed to be open minded and experiment with software, let it evolve, and use the best ideas to build a better system? Or do we want to stay in our little niches and iterate over things like the KDE/GNOME "war" a few thousand more times?
I'd much prefer to see some oddball projects like this one pop up, if only to make people think about other possibilities. I give the people on this project credit--I never would have thought of doing this with an ORB.
Re:huh? (Score:1)
Seriously it is a very hight speed implementation of the OMG CORBA specification, created to give the GNOME project a very fast CORBA implementation. You find more information on the RH Labs [redhat.com] homepage.
Re:Excellent. (Score:1)
make clean && make dep && make rbzImage (Score:1)
When will mozilla be included in kernel?
Re:HURD (Score:1)
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.
Re:next logical step (Score:1)
> showing any obvious reason, or what the benefit
> would be?
Err, joke?
Re:boo hiss (Score:1)
i don't see how the 2.2 kernel is more unstable than the 2.0 kernel or the 2.0 kernel is more unstable than the
it's gotten bigger, to better handle things like SMP, but i wouldn't call that being bloated. the solaris kernel is far bigger than the linux kernel and i haven't heard anyone say that's bloated. it's also far smaller than the win2k kernel.
i also don't see a lack of direction with linux, they keep making the kernel better for SMP, small appliances, workstations, networking, you name it.
just like windows.
WTF are you replying to? (Score:2)
Re:Excellent. (Score:2)
Re:Gnome... (Score:3)
"So, Gnome, what are we going to do tonight?"
"Same thing we do every night, Pinky, try to take over the kernel!"
We are all, in fact, dumber for having read that. (Score:2)
Are you on drugs?
No, really, what part of "i came to Linux to get AWAY from Windows" don't you understand?
Besides, not everyone wants to use GNOME. In fact, many, many people don't want to use GNOME. You know what else? Many people (brace yourself for this one!) use Linux purely in console mode.
Not to mention, the benefits of including GUI components in the kernel are unproven at best. While there may be some performance increase (though this will most likely be from taking cycles away from other things ie no net gain), there is the UGLY reality of having a kernel that will crash when the GUI screws up. Not to mention the problems with a larger kernel (ie not being able to use zImage, which means precluding a lot of architectures from using Linux).
So yeah, i paraphrase the movie "Billy Madison" when i say, "We are all now dumber for having read that."
-benc
Re:Excellent. (Score:2)
Re:Excellent. (Score:2)
The HURD is not designed for speed. That immedietly makes the OS crap in my view. I would really like it if the HURD was sort of like an OpenSource QNX, fast, robust, elegant, but its turning out to be decidedly not. That's why I don't really see what HURD brings to the table. Its not like no other OS runs drivers in usermode (several do), its not like no other OSs have a translator-like filesystem (Plan9 seems to), its not like no other OS offers UNIX compatiblity in a microkernel (take your pick.) What exactly does the HURD have that hasn't been done already?
Re:This is actually pretty cool. (Score:2)
Now it's up to the browser... (Score:2)
Kernel "bloat" (Score:3)
If there actually is bloat, in the form of unnecessary or poorly written code, that's unquestionably bad, but if there's simply a lot of cool things being put into the kernel, that doesn't strike me as bad. You can always recompile, thereby stripping your kernel down to just what YOU need.
I know, I know, the average desktop user isn't going to have the skills to recompile a kernel, but that's okay. Whether a user's kernel is 2 megs or 200 megs, they've probably got enough HD space to fit it. The situations where kernel size matters are probably going to be small devices (pda's, palmtops, etc.), and old devices (486). Small devices generally have customized OSes anyway, so you can expect that the manufacturers will take care of that. Old devices are probably better off running older software, so I'm not too worried about them.
I probably missed a few things, again I'm not a kernel expert. Plus, the security and stability issues are not trivial, and are a big strike against a project like this. But, any other reasons why this is bad?
Re:Time to read up on Operating Systems (Score:2)
This is no different than a TCP SYN attack. This ties up kernel resources for allocating connection overhead (see the TCP SYN-flood protection kernel option). Quite a few DoS attacks exploit communication stack errors, which are part of the kernel.
Re:Making life harder (Score:2)
I would just advise you that rather than bitch and complain, just don't run it. Problem solved, no need to get worked up.
Just how is X slow? (Score:2)
True: X has some brain damage when it comes to supporting complex shapes in the protocol. And certainly the current crop of free X servers need hardware accelerated alpha channel blending and font/glyph anti-aliasing. But that's not a problem with X inherently, and all these problems can be resolved by adding X protocol extensions.
There were certainly better network display protocol designs before X; NeWS comes to mind. Display Postscript is yet another, though that was released after X. Hardware accelerated anti-aliasing and alpha channel support I believe is slated to ship with XFree-4.0.2. Then the userspace widget libraries will have to support those features, which will probably take another year to sort out. On top of that we'll need better fonts designed, which is really the crux of the problem since the default fonts which ship with X are just terrible. Maybe by then the GnuStep team will have released their Display Ghostscript X extension, which IMO is the best way to go.
None of these solutions will have much impact on speeding up the core X protocol. Mostly because on a local system it's pretty damn fast.
Cheers,
--Maynard
now you can (Score:2)
What is bloat? (Score:2)
Certianly I would call inefficient coding, poor design, poor choice of algorithms, lack of performance tuning -- all bloat in my book. But bigness per se doesn't mean bloat.
One man's bloat is another man's feature.
But then on the other hand, I don't want 200 MB word processors either -- even if the word processor can do equation layout, image processing (ala. Photoshop), flowcharts, etc.
Re:next logical step (Score:2)
At least the people porting ORB into the kernel expressed some useful reasons for doing so (even if they are just for experimentation).
Re:Kernel "bloat" (Score:2)
I don't mean to flame you, but you sound like a PL/I or APL programmer thirty years ago. "I have a problem with this idea of impeding technological progress by placing arbitrary limits on the number of keywords a programming language should have."
Bigger ain't necessarily better, as every C programmer knows.
I still am. Seriously. 100kb is still too big, except possibly in the case of distributed operating systems where you usually need networking in the kernel otherwise the paradigm isn't practical. (More research should remove this requirement, though.)
The flaw in your thinking is the fallacy that more "technological progress" in operating systems requires more non-pagable kernel memory. Real technological progress requires working smarter, not harder.
This is actually pretty cool. (Score:2)
Here's a real life example of why this would be useful. I have a linux gateway in my house. It contains my only modem. I have three other PCs running a variety of OSes. From time to time, either the wife or I *have* to use Windows to dial in to work or to fax a word doc or whatever. I would LOVE to power up my windows machine, connect across the network to my modem in the gateway, and control it as though the device were local. Why is that a hideous hack thing to do? To me, it sounds like a natural extension of the shared, networked architecture of UNIX and X as they were intended.
Re:grr (Score:2)
And implicitly, I also mean, that has any actual resources committed to it?
Win2K memory use (Score:2)
Re:Kernel "bloat" (Score:2)
In any case, assuming the monolithic kernel survives the next decade or so, it's only a matter of time before ORBs, virtual machines and god knows what else make it in there, because everyone will be using them. The 90MB kernel isn't that far off, mark my words! ;)
Re:But is this really bloat? (Score:2)
Well, only because somebody hasn't thought of a good reason to have a web server in the kernel.
(Reaching WAY up into my rear end here) Suppose the Linux-on-a-chip people get really motivated and make a controller for devices in the home. With IPv6, every light switch and thermostat has this LinuxChip in it with khttpd. A central control (with more juice than the slave devices) pulls data from each device through a bastard child of wget, and you (at work) can browse to myhouse.com (or whatever) and see what the setting are, and change them if desired.
Taken to the next level, (taking into account here that I know next to nothing about CORBA), these chips also have the korbit compiled in as well. Now devices from different vendor can pass objects back and forth, with the master controller using that information to whatever end.
I dunno -- I hesitate to write it off as crackpot until I see what it can do. khttpd and korbit are pretty cool hacks, and now that they're "in the wild", we might be surprised at what comes of it. Maybe nothing, maybe the Next Big Thing.
(Regardless, looks like I need to look into this whole CORBA thing -- I thought it was a flash-in-the-pan, but apparantly a lot of people are taking it pretty damn seriously)
Re:Time to read up on Operating Systems (Score:2)
True, CORBA is not commonly in use today for these purposes, but that is not because it would be unsuitable for them; rather, the technology has simply not begun to establish itself at the LAN and workstation level as a viable option. Huge enterprise installations often rely heavily on high-performance, scalable ORBs to manage communications between legacy system, user applications, web applications, etc., and distributed computing is becoming more and more a point of interest on the desktop.
There are a number of things that the addition of (a later, more stable version of) kORBit to the core kernel distribution could offer: instant, painless cluster development; increased acceptance of Linux in enterprise-scale networks (now, your Linux router can scream through CORBA calls, as well...); and, as mentioned in the article, distributed hardware and resource access.
The world standardized around TCP/IP to satisfy the need for standard network connection and data transfer management, and CORBA looks to be a contender for that role in distributed service and resource management. Just as C++, Java, Perl, and other high-level languages are rapidly supplanting C for most application development due to their increased abstraction, programmer productivity, and portability (more so with Java or Perl, of course), CORBA could one day all but replace TCP/IP for the majority of network applications, since while the data being passed between network nodes will be more complex, access to it would be more general and flexible.
Please also note that you could replace the word CORBA in the above post with SOAP, or any other distributed network application protocol with sufficient momentum and protability to potentially become the standard. In fact, SOAP (or a twisted version thereof) is going to be a major component of Microsoft's .NET framework, which, for all the hatred and suspicion I have of MS, is likely going to do some fucking impressive things for distributed computing (at least, for those running Win2k and later). Right now, the capabilities of Microsoft software are not significantly ahead of the available free alternatives, but if MS gets a huge head start in this area, they just might be able to hold on to a new proprietary stranglehold on the business computing world.
We should encourage experiementation with projects like the one described in the article, as a means of keeping Linux and free software as a whole on the cutting edge. This is an area where no clear leader has emerged yet, and where an early lead by free software could make a huge difference years down the road.
Just my $2x10^-2
Sounds good for... (Score:3)
1. Remotely debugging device drivers
2. Security holes
Clustering... (Score:2)
Hmm, just what I need, another project.
HURD (Score:4)
A few clarifications about kORBit... (Score:5)
- NO, we do not expect this to go into any mainstream kernel any time soon.
:)
- YES, this is an awesome way to play with and prototype kernel functionality in user space.
- NO, this does not work with other OS's. Although, there is no fundemental reason why it cannot be ported... again.
- YES, this does mean that if it was ported to other OS's that you could trivially write portable drivers.
- NO, we are not planning on porting GNOME to the kernel.
:)
- YES, SOME user space code can do good things in the kernel, particularly network-centric code. Think kHTTPd or kNFS.
- NO, at least not without some redesign of GNOME, this will not make GNOME/bonobo faster.
- YES, security can definately be improved [err, well, ahh, be implemented?
;)]. We have one proposal from Miguel de Icaza on improving
the security to the point of NFS. Other schemes could definately be implemented, we just haven't started thinking about it.
- NO, this does not "severely bloat your kernel", it adds about 150k of space when compiled in debug mode. This is still a very alpha version, btw, and there is still a lot to reduce out.
- YES, you can now write your device drivers in C++.
:)
Anyways, if you have any other questions, feel free to contact us. [mailto]-Chris
Lots of time (Score:2)
The mainstream press could blow this totally out of context. Worse case scenario, the press says this is Linux's next kernel, which its not. Just an experiment that can be ported in future if they want.
Amigori
----------
Its alive!
Linux: it's not a microkernel (Score:3)
________________________________________
Re:Excellent. (Score:3)
Do you mean that they are not taking speed into account at all? Or maybe that they are completely ignoring any concerns for efficiency?
Or do you maybe mean that they simply are not making speed their number one concern?
Could it be that speed (or perhaps efficiency), while important, is not the only factor to consider (as so many here seem to think it is) -- that in some circumstances it might reasonable to sacrifice some efficiency for other factors such as maintainability -- ease of implementing new deamons, etc. The age old sacrificing some comptuer resources for human producitivity.
How much of a difference are we talking about here? A few (or some number of) percent, or an order of magnitude?
Distributed OS (Score:3)
cb
wouldn't it be better if... (Score:2)
We already have a web server, an nfs server, and others in the kernel...
We do this for performance reasons - a user land program can't get anywhere near the same perf. as being in the kernel...
But honestly, programs don't belong in the kernel! (I'm not even going to touch upon the possibilities of a program in the kernel had a sploit...) Why don't we just improve the methods of user land programs communicating with the kernel so they can have performance as good asor so-similarily-it-dosen't matter as being right in the kernel? In the long run, wouldn't this be a better way to go?
P.S.
I don't do kernel coding, so please don't tell me to do it myself. You really don't want me touching your kernel anyway! Or perhaps its just not possible, but then how does the hurd have acceptable performance? or does it...
Re:Excellent. (Score:2)
Re:This is kinda cool... (Score:5)
Um... Not really. It's almost trivial to put something inside of something else [indiana.edu], as long as you write good interfaces. And the more 3rd party code you accomodate, the more risk there is of unstable code crashing the system, or of security breaches.
If necessary, kernel interfaces to userland programs [linuxdoc.org] are probably the best way to go, but even then you're not necessarily safe [attrition.org]. Remember: try to run code as an unpriveleged user at first, then as root if necessary, but only in kernel space as a last resort.
Like Jini [sun.com]? I hope you're not suggesting we embed the JRE into the kernel! That would be grotesque, despite the niftiness... No! No niftiness! Don't tempt me! Back!
--
Re:grr (Score:2)
PS> If not better, then certainly as well.
Re:Making life harder (Score:2)
boo hiss (Score:3)
Corba != GUI (Score:3)
I shouldn't have to say this here, but CORBA has nothing to do with GUIs, except that it is a necessary service for Gnome's particular architecture.
This article is good news because it allows the ORB to be used in non-gui contexts. I'm not saying that it should be part of the kernel, but it should and can be decoupled from GNOME. Modularity. Reusability. Flexibility. These are all good things.
Re: (Score:2)
it's about time... (Score:2)
Mach-like kernels attempt to address this problem by dividing the kernel into "servers". Other kernels address it by using languages that have better support for modularization (SML, Java, etc.). Because the Linux kernel is monolithic and written in C, there aren't a whole lot of choices for how to achieve this. Exploring putting a system like CORBA into the kernel seems like a sensible approach. I don't think CORBA and kORBit is going to be the long term solution, but it may be a good testbed for these ideas.
Re:can someone please tell me... (Score:2)
what is CORBA anyway? I haven't been able to figure it out.
CORBA (Common Object Request Broker Architecture) is a method of decoupling "objects" (read: chunks of code) from their physical location, programming language, and implementation details. What this means is that I can have a CORBA object implementing a particular "interface" that is running on an iMac in London, England and use it just the same as if it were local to my box in Ohio, USA. Obviously there would be network latencies, but the functionality would be identical...
What's more, the module on the iMac can be written in Eiffel while my program (the one using it) is written in Smalltalk; CORBA doesn't care as long as both computers have a compatible ORB.
What this is supposed to enable is interchangeable software "parts". For instance, I have an email application that requires and "address book" CORBA object; I would query the local ORB and say "hey, I need an 'address book'". The local ORB would hand me whatever address book was available; it might not be the same address book you use, but if it exports the same interface neither of us has to care. The details are handled within the ORB.
All of this is very cool, but I'm not sure how much I like CORBA or not. :-)
Linux microkernel (Score:2)
If you think I'm wrong, look at NT... it's all abstracted. If you want NT you know where to get it.
Re:why not? (Score:2)
However, what makes Linux so great for this also makes it worse for other applications. FreeBSD, for example, is IMHO much better at being a server due to various technical features of its implementation, as well as the general feel of the OS. It's also probably better for non-hacker users who don't want to go pick out the best fingerd and ftp and whatnot for themselves.
I don't understand why people don't appreciate heterogenity. We had a DB guy at work complaining that Linux was "broken" because he was used to Solaris's memory allocation, and he thought that was the One True Way. Yes, Linux's memory allocation can cause kernel panics and OOM errors in a few extreme cases, but the vast majority of time it's more efficient.
If you don't like the way a system works and the situation isn't conducive to patches, fork it or choose another system. If you're looking for a microkernel, the Hurd [gnu.org] would probably be a better choice than Linux. And it'll be available for production use RSN!
The beauty of an open environment is that you can choose the system that best fits your needs, rather than being locked into one system.
--
User-space OSes and kernel-space applications =... (Score:2)
This Is Actually Cool (Score:3)
If more and more of the infrastructure of a desktop environment (like GNOME) could be moved into kernel space, it wouldn't be the first OS to more closely tie the GUI to the kernel. As long as all the pieces are stable and the whole operation was well thought out (admittedly, not a trivial expectation for Linux code) it would surely mean a more integrated (and speedy) desktop. There's alot you can't do with a GUI in UNIX because of the rift between userland and kernelland.
Imagine...GNOME/Linux on store shelves, with a custom kernel patched to take advantage of this. GNOME bigots, I can hear you gagging, but noone really cares
Mercster
Re:User-space OSes and kernel-space applications = (Score:2)
The sad thing is, I remember some of the old "performance tricks" we'd do in DOS.
Like, if you've got a tight loop that you want to run quickly, make sure you put some inline assembler around it...
cli
sti
That way, you aren't bothered by those useless "interrupts" that the Operating System is always doing. I mean, really, what good are those?
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
But is this really bloat? (Score:5)
In addition, it would allow for a much more robust and powerful way of extending the kernel. This is a Good Thing, because the componentized architecture makes sure that this can be done without introducing instability. This is less of an issue in an Open-Source kernel than it is in a closed-source one, of course, but it's still an important advantage that should not be overlooked.
ORBit itself has the advantage of being small. This is a big thing, since it minimizes size bloat. Its performance is also pretty good (though it could use some improvement), and would get faster in kernelspace. This is also a Good Thing. However, there's the distinct problem that it needs better testing for security issues; something of this complexity can't be allowed into the kernel until it's rock solid for obvious reasons.
But overall, I say go for it. The potential benefits of CORBA in the kernel are simply too great to ignore.
----------
Modern kernels (Score:2)
Linux is based on venerable technology -- but that technology doesn't account for new concepts and developments in software and operating systems.
A kernel should be small, concise, and to the point. It should be easy to hang device drivers and other "low-level" tools, while providing for extensions through a standard, well-defined object module.
An ORB should be part of the kernel; HTTP should not. HTTP support should be implemented as an object that is installed, as needed; the kernel should not need to be recompiled to change its functionality.
Re:why not? (Score:2)
Low-level CORBA (Score:2)
If CORBA is fast enough, you should then be able to start taking stuff out of the kernel, such as networking and file systems. This could make the system much more robust, and far easier to debug.
The big problem with CORBA is that marshalling, copying, interprocess control transfer, and unmarshalling is expensive. But it doesn't have to be; look at L4, EROS, or QNX, which can call from one process to another very fast.
Another big problem is figuring out a security model for this. CORBA's own security model hasn't been that useful in practice.
Still, all this is a step in the right direction. All the heavy thinking in OS design for years has been that systems ought to be more modular and more decoupled, but getting the decoupling overhead down is a problem.
Re:Linux microkernel (Score:3)
Well, NT used to be abstracted. NT is a sad story, really. Micros~1 got a whole bunch of top-notch engineers (Dave Cutler, the VMS guy, being probably the most famous one) and told them to make the next-generation OS.
The engineers were gung-ho about it, and designed it to be modular, abstract, and machine-independent. Management, however, was actually against these attributes and turned NT into something much less wonderful. NT used to run on x86, Alpha, MIPS, and PPC, but those were gradually killed off so that only Intel remains.
Heh, I got most of this info from a book I was browsing at the story but didn't have the money to buy. I wish I had; NT is one of the great tragedies of our day.
--
Re:Kernel "bloat" (Score:2)
I don't know or care whether Win2K is a good OS, but I don't agree that one can judge it on the basis of the size of its kernel alone. If it uses a different architecture, the kernel size may make sense in its context. Kneejerk "15MB is too big" reactions tend to relate more to currently assumed limitations, than to anything real.
The flaw in your thinking is the fallacy that more "technological progress" in operating systems requires more non-pagable kernel memory.
I didn't mean to imply that. I'm not saying that progress does or doesn't lie that way; only that it doesn't make sense to close off a particular direction for no good reason.
Perhaps message-passing microkernels will ultimately replace monolithic kernels, for example, but until that's actually happened (and Linux is a famous argument to the contrary), there may be real benefits to be had by including major additional functionality in a kernel. This kernel ORBit implementation is a good example: it's not so far fetched that in a few years time, an ORB in the kernel will be seen as a necessity.
It also isn't much of a stretch to imagine an OS built on top of an ORB (which in some respects, isn't that different from a message-passing microkernel model.) If that approach were desirable, the route from here to there might very well be to start out by building the ORB into the kernel, then slowly removing other basic services from the kernel and replacing them with external object implementations. (I can imagine a lot of knees jerking right around now.) Making such radical changes, however, doesn't happen easily when people allow arbitrary metrics to define the boundary of their world.
Linux in education (Score:3)
Re:Kernel "bloat" (Score:2)
This reminds me of a famous joke about the Titantic..
"So how was the trip, aside from the iceberg?"
Daniel