Slashdot Mirror
GNOME ORBit Ported To Linux Kernel
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.
This isn't an attempt to get orbit running faster by moving it into kernel space. This is a functionality hack - orbit won't run in kernel space, the kernel API will be made available to corba clients.
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.
You don't have a clue what you are talking about. This would make the servers even more slow than they already are when running in user space. The whole point of khttpd is to deliver static pages(usually cached) without context switches. This can be done in very little time and makes static serving much faster. Tux goes above and beyond this by allowing dynamic content to be generated by using cache objects(or something like that).
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
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.
I am beginning to hate technical discussions on slashdot because people read a few comments here and there and think that they actually know something.
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
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.
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.
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,
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.)
While this may not be exactly what you're looking for, you might try DS3 for modem sharing. Or, something that I suspect is more what you're after is MSREDIR, a serial port redirector that is designed to let multiple people share multiple modems (an implementation of RFC 2217).
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. 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.
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.
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.
> The initial reaction here seems to be that this is a bad idea. But what's wrong with bringing a object request broker architecture to an essentially monolithic kernel?
... *shudder*
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.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
Look, I even found more stuff for you! Check out mdmpoold. From the website:
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!
Please ;-)
http://Lenny.com
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.
You can now write device drivers in perl.
Well that sent me screaming and running..
hey! Can you see me through this thing?
How we know is more important than what we know.
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.
The theory about what to put into a kernel is "only what is completely necessary, and nothing more". The reason for that is that kernel code runs with special priveleges, and if it gets out of control it can take down your whole system. Therefore we want to put as little in the kernel so that we have less chance of the system crashing. So if something can be done in user-space, that's where it should be done.
Software sucks. Open Source sucks less.
You know, if we were all running the GNU Hurd and this was just another server, it would actually be pretty useful. :)
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.
Bizar technology?
Right, and it's a good thing that this hack doesn't do that in any way, shape or form
My Karma: ran over your Dogma
StrawberryFrog
What the hell is 'Gnome Orbit'?
Democrats or Republicans. They are both taking us to the same place and they are not afraid of us anymore.
so is OmniORB and TAO and Visigenic
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
640K for a kernel? That's huge! I'm not against progress. What I am against is putting features into the base system. The problem is that the kernel should only contain features everyone uses. I'm against putting stuff like NFS in the kernel (although that's probably the only place to put it) much less something like ORBit. Technological progress is fine, but do it in userespace.
A deep unwavering belief is a sure sign you're missing something...
Why put something in the kernel that doesn't need to be in the kernel, and is just going to open a bunch of security issues later on.
Anyone who's read "Secrets and Lies" knows what this is leading into. Linux becoming as bad as windows.
Cheers.
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 given that we already have such great http support in the kernel...
I have a cool sig too.
Damn, you're right. Win2K does use about 2MB of non-pagable kernel memory. I saw the 20MB kernel memory, remembered that BeOS and Linux kernel memory is nonpagable, and forgot that NT runs non-kernel apps in kernel space.
A deep unwavering belief is a sure sign you're missing something...
--
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
That is very cool.
;)
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.
pb Reply or e-mail; don't vaguely moderate.
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)
Give me some details and URLs, please!
Thanks!
Szo
Red Leader Standing By!
ORBit never has relied on GNOME. It uses glib, but that's it. It is already decoupled from any GUI. It is just a fast CORBA ORB.
BeOS has the GUI entirely in userspace. Hell, the better part of the driver runs in userspace. In QNX, the driver runs ENTIRELY in userspace, it's just another process. Userspace is not what is causing bad Linux GUIs, its the fundemental problems of X and non-user-oriented design. Before trying to put stuff in the kernel, think about how much faster stuff would be without X. About how much cleaner stuff would be if GNOME were designed to be simple rather than kitchen sink complex. The real problem is that Linux GUI's are doing "cool" things as opposed to useful things.
A deep unwavering belief is a sure sign you're missing something...
So what we're doing here is making life in userland harder... just because you're an OK app programmer doesn't mean you're an OK kernel programmer. It's this type of hackery that made NT4 so.. uh, stable. "Move it to the kernel!" We're on crack if we think Linux will be immune to the stability issues that Windows has just because we're open source.
Plus, since Linux (the kernel, yes) doesn't ship with a kernel debugger, how the heck can we expect people to submit bug reports?
The kernel is in non-pageable memory. As such, if you kernel takes up 20MB of RAM, that's 128-20=108MB of RAM that you actually have. It's scary, Win2K uses more than 15MB of non-pagable kernel memory. That's just wrong.
A deep unwavering belief is a sure sign you're missing something...
$ insmod gnome using module /lib/modules-2.4.0/gnome.o
$ insmod evolution
using module /lib/modules-2.4.0/evolution.o
"We can't all, and some of us don't." -- Eeyore
mutter... OmniORB ... mutter.
-------------------------------------------
This coming from a group of people who think C++ is too bloated for the kernel? Yes, I can see it now, the VFS written in Perl! Take that Verio.
A deep unwavering belief is a sure sign you're missing something...
The initial reaction here seems to be that this is a bad idea. But what's wrong with bringing a object request broker architecture to an essentially monolithic kernel? It seems to me that if it can perform well, the added modularity might actually be a huge step forward and might be a nice alternative next to the existing module architecture (sort of a primitive object request broker). One of the immediate advantages is that C is no longer required (but still allowed) for doing kernel programming.
But then, i'm not a kernel hacker.
Jilles
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.
Where rbzImage stands for Really Big zImage.
When will mozilla be included in kernel?
The opinions in this comment are subject to GPL, you can copy, modify and redistribute freely (as in speech).
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.
> You suppose that it should be done without
> showing any obvious reason, or what the benefit
> would be?
Err, joke?
linux isn't bloated. even if it is, you can unbloat it by not compiling what you don't need in. the kernel can be made realitively small. .99 kernel.
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.
bah. start over
Can't be my comment, because I didn't say anything that disagrees with what you wrote.
--
enterfornone - logging in for a change
The kernel's job is to be a manager. It is supposed to delegate time, memory, and hardware sharing to all programs that need/request stuff. The more stuff that is not essential to the delagation of those responsibilties, slows down the kernel to HANDLE those responsibilities. A word processor that was built into the kernel may be the best damn word processor in the world but it would slow down the kernel from doing its real responsibilities. YOU might not even LIKE the word processor (though it be the best in the world). You might like EMACS better and then you have a kernel that is running something you will never use but is slowing down the performance of what you ARE using. Almost any program in "userland" can be replaced with something else but a kernel can not be replaced. So we only want "essential/important" things in the kernel.
I miss the Karma Whores.
As the poster pointed out, it's a fine goal to make a "balanced" operating system as you've described. However, we already have literally hundreds of operating systems that do just that, and a much better job. So, again, what's the point of the HURD?
i could see this as a way to create a really high-performance application server, but the cost is the lack of protection the kernel barrier gives you. i would hate to have to reboot every time i found a bug in my app!
"So, Gnome, what are we going to do tonight?"
"Same thing we do every night, Pinky, try to take over the kernel!"
(currently testing something about signatures here)
As for code bloat...code is only bloated when there are many things in it that are not needed, not useful, or not efficient. This is definately useful. If you want to minimize code bloat, then strip out the code that you don't want and recompile.
-Mark
Ok, i'm gonna borrow a page from Linus' playbook and ask,
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
This can easily speed development for new and unique ideas, but at the same time it can be a pain in the ass to control.
I realize they say on their site that security is not yet implemented, but I'd venture to say that adding security to it will be a nightmare - if not nearly impossible.
The Linux kernel mode was designed to have 'kerenl space' and 'user space' seperation. As orbit is used with gnome, any user-space process can connect and perform actions in ORBIT. Now we've collided an 'assumed secure' environment (kernel space) with a 'known unsecure' environment (orbit). The security problems with colliding these assumptions are so bad that it may be impossible to think about every potential exploit.
This is exactly what microsoft did when they opened up their internal OS stuff to ActiveX instructions. This provided web developers with lots of functionality and neat features, but it also created weekly security exploits for windows/ActiveX.
ActiveX was supposed to be a competitor to Java, Microsoft has since ditched pushing ActiveX and moved to providing their own proprietary java environment instead.
--
Twivel
Those examples are pretty cool and I must admit, I had never heard of them when trying to solve my modem problem. However, they're still one-shot examples that solve a very specific problem (i.e., share a serial port with another machine). What I was wishing someone would address in a generic way of sharing *any* device remotely. The device driver interface is extremely simple (open, read, write, ioctl, close), so the technology needed to provide that remotely should be trivial. Loose ends would need to be tidied up (like locking devices that need to be locked and the such), but I'm *sure* it's a solveable problem. I think what this person has done is a step in the right direction towards making hardware as generic and universally accessible as anything else. But that's just my opinion.
(Hint: The entry you're looking for in that little drop down menu thing is "Troll")
-------------------------------------------
Right now a whole field is open to integrate such things as office applications and other stuff, tightly into the kernel. I advise to start with a browser. We glue it ot the kernel and give it to users. Users will have to use it no matter their likes or deslikes. And so we kill all this madness of distros, alpha-beta-gamma versions, several apps for one purpose. We will start to unify Linux into One Total System. And fight M$ for World Domination.
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?
"The question of whether a computer can think is no more interesting than that of whether a submarine can swim" -EWD
it wouldn't be the first OS to more closely tie the GUI to the kernel.... 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.
Ehm, I don't know much about this, but isn't even Apples' Aqua just a BSD app? Login as ">console" and that's all you get.
Oops: Fast Good
Sorry, Slashdot mungifier got to my text (I'm still waiting for an explanation as to why Plain Old Text understands HTML tags...not so Plain I suppose)
It's 10 PM. Do you know if you're un-American?
One of the big wars is monlithic vs micro kernel design. Both offer all sorts of interesting things.
I could really see some interest in a kernel level corba server...
Most specifically, something that hasn't really been looked at (or at least, in my lay research, i haven't found much about)...
A heavy micro kernel... Where there kernel is relatively robust, but maintains a richer interface for userlevel code... everything from device drivers to http servers.
Another interesting thing you could do here, is implement an LDAP server in corba to handle security... You could have a network wide user and resource directory, with organizational groups tied to machines...
This could bring unified ACL's and user/resource management across an entire network...
Just some (probably worthless) thoughts...
-T
Old truckers never die, they just get a new peterbilt
KDE is better. (ducks for fear of flying objects). On my system, GNOME has crashed the system twice, to the point where it is so slow that it is unable to switch to a VT. KDE, which I've run much more, has crashed twice also, but I was still able to switch to a VT and kill it.
Ashes of Empires and bodies of kings,
The truth about Michael
Hey, 1010011010: Make a refernce to "The Clapper" or the old Wendy's commercial "Where's The Beef" to score big time!
:)
"High in his tower sits the Lord; he is the Bell, the Clapper, and the Cord."
Or is that not what you meant?
________________________________________
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
However, in practicality I'd be much more comfortable with providing such extensions through a mach-like microkernel that keeps the core system functionality of the kernel clean (i.e. following traditional goals.)
Take a look at the number of defects that crop up with seasoned and well maintained TP monitors (Encina, Tuxedo/BEA), databases (Sybase, DB/2, Oracle, etc.), and with various network messaging and remote object services. I don't know about you, but I find the thought that such complex defect-prone software being part of the core kernel disturbing.
Right now if your ORB gets some variant on a DOS attack (say someone repeatedly sending bad or invalid requests), you can shut down that service module in the ORB. What happens when the ORB itself is part of the kernel and the entire kernel is getting beaten to death?
Perhaps there are solutions to these types of issues. Maybe kernel ORBs will be part of the future of computing. Traditionalist that I am, I'll always consider them a system service, rather than an OS service.
I do not fail; I succeed at finding out what does not work.
And the more 3rd party code you accomodate, the more risk there is of unstable code crashing the system, or of security breaches.
;P
Define '3rd party code'. Isn't that what most of Linux is, not to mention about half of all open-source projects?
What happens when the ORB itself is part of the kernel and the entire kernel is getting beaten to death?
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.
I'm not a kernel hacker, just a lowly multi-platform threads-n-sockets kinda guy.
If this thing is running as a kernel module, how well does it work & play with other processes? I know that's not the concern, since any box that needs this kind of performance for one "task" should be a dedicated machine... but once invoked, will this thing pre-empt at all?
I mean, that's kinda the point of the kernel, that anything that needs to be done right away (raw I/O, device control, memory & process management) happens more or less right away, and everything out in userland has to wait it's turn.
Does memory protection extend to kernel modules? What can a module trample?
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.
I don't recall calling it a "defining feature". I called it a "fundamental unit".
I don't know a lot about it
So perhaps you shouldn't be stating opinion as fact, hmm?
a) I didn't state anything as fact. b) you have chopped off the second part of the sentence to remove the context of what I am saying which is that CORBA would not suffice as a primary means of interprocess communication for an operating system.
but it has NOTHING to do with CORBA.
One can implement a microkernel using CORBA as the primary means of IPC.
You _could_ but I'm telling you that it would be unbearably slow.
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?
I'm spouting nonsense?! You obviously know nothing of CORBA. First of all it's founded on sharing objects. These are not simply structs but full blown objects as in Object-Oriented objects. Do you know what it takes to serialize an object for transmission over a network? It's slow. Even if they used shared memory to get around serialization of local objects there would still be many issues related to the dynamic binding of methods and other OO stuff that is invariably slow.
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.
Think about what your saying. You're going to run a CORBA ORB _in_ the kernel as the primary means of communication for an operating system?! I'll beleive it when I see it.
This post comes to you live from the newly installed Red Hat 7. Ahem, scoot over, there's another convert that's just walked in, thanks.
Many thanks for all of the replies. Here's what I did: I had an older generation mother board housing a piii 500. Well the bastards at G_t_w_y sent me a replacement motherboard with a PCI IDE controller card. Ultra ATA 66, to be exact. Chipset PDC20262. (for those who care to f around with this one). Well, I ripped that little bastard out of there and ran the IDE cable straight to the board. Okay so it'll drag a little performance penalty but I'll take that any day over not being able to run Linux at all. After some serious help from my friend Tim (who clued me in to all of this) we had the machine up and running in about an hour and a half with full sound card, network, and full voodoo support.
Boioioioioioioing!!!!!!!!!!!!!
a/s/l here. Sorry, adding domain tags to your s
The Alpha was launched in 1992, the Pentium Pro in 1997. i.e. comparatively recently.
As soon as any Intel chip was shipped, NT was doomed on it. Doomed to crash repeatedly, to FDIV incorrectly, to F00F itself into oblivion or whatever.
MS, a 2 letter abbrieviation for doom.
FP.
Also FatPhil on SoylentNews, id 863
I feel free to use the word Bastard a lot ;-)
a/s/l here. Sorry, adding domain tags to your s
Just how does squirting a serialized display protocol across a UNIX domain socket slow down X any worse than GDI (the Windows low level display protocol)? I can't speak for how Be handles display events, but if it serializes its display protcol it's no different.
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
You forgot the Fairchild/Intergraph Clipper which was also a Windows NT platform processor.
The reason Windows NT was killed off on those processors was that nobody bought them. In most of those cases (IBM, DEC/Compaq and Integraph for sure - I can't remember about MIPS) they were killed off by the hardware vendors who wanted to drop support costs for their almost totally non-selling products while Microsoft wanted to keep them going.
Oh, and I didn't get it from scanning a book. I was in that part of the industry at the time.
That's called backward compatibility. Windows 98 only does that if you have real-mode drivers and have them loaded in your CONFIG.SYS file with a DEVICE=xxxxxxxx.SYS command when you install Windows 98 and if Windows 98 doesn't have a replacement protected-mode driver that it can use. So if you depend on them you can still use them, if you don't then the boot sequences skips the real-mode driver load process.
Of course, that isn't true about Windows ME. By 2000 there were few enough users that still needed backward compatibility with their old hardware that Microsoft could drop the "real-mode pause" step. Back in 1998 there were too many. Oh, and there are users out there complaining about dropping the real mode driver support in Windows ME anyway.
Now everybody flames Linux because Linux is not microkernel like Win2k (with its 40 million lines of code -- 500% bigger than Linux -- and still called "micro"). Everybody wants microkernel this, microkernel that. Then after that, people mock Linux and say "Oh FreeBSD and OpenBSD is much better, it's l33t " but BSD is still monolithic too .
Be patient, will ya?
The fact that in its IPC, monolithic kernel design reduces overhead and is faster than microkernel because monolithic kernel doesn't require yet another second-third-fourth-etc-etc layer for messaging.
By the way, in case you've never heard of zero stack copy, Linux is much faster than BSD in that area.
My point is: No operating system is perfect, not Linux, not BSD, not Win2k.
write your web, nfs etc service as a corba control and let it run in userland.
--
enterfornone - logging in for a change
Reorder your list of platforms, put Axp first. That's how it was. It was supposed to be the joint flagship attempt. MS with theif flagship OS, DEC with their flagship Processor.
Even though I use Linux on my 21164, I never removed my NT boot partition - it's the _stablest_ version of any Windows I've ever seen. I still have I.E. 2.0 on it too - no JavaScript, no nothing!
A very sad story indeed. With a happy ending. I'm now running a Unix varient on every machine I own.
FP.
Also FatPhil on SoylentNews, id 863
Why not have the option available? I can see some uses for dedicated machines, possibly in embedded systems. This will increase the performance of the ORB quite a bit, and, IIRC, it's already one of the best-performing CORBA implementations out there.
Your CORBA calls on the Coke machine down the hall will be handled in a speedy, efficient manner!
Ah yes the English... I wish they were still here in Africa 'cause things were much better then than now!
You should go to Bidonville, capital of my proud country ( the southern part at least, damn these muslim rebels! ) and say that outloud!
But I still can't get Linux Red Hat 7 to boot because ther is a serious lack of drivers out there for the Ultra ata66/ ide controller. 36 hour installl and counting .l..
a/s/l here. Sorry, adding domain tags to your s
Just a slight correction here. It wasn't the poor design of NT that killed NT on these processors, it was market realities! Number of Intel processors shipped / number of Alphas shipped = near infinity! (no division by zero detected either...)
Have you compiled your kernel today??
Didnt someone say this already only with a little more on the end?
This is my favourite quote:
We can now write device drivers in perl, and let them run on the iMAC across the hall from you.
--
Patrick Doyle
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
maybe; i just pressed the scrollwheel and it pasted a crapload of text that seemed quite ontopic so i just deleted the incomplete last sentence and posted it...
any other questions?
Maybe everyone should first agree on what is bloat?
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.
I'll see your senator, and I'll raise you two judges.
You suppose that it should be done without showing any obvious reason, or what the benefit would be?
At least the people porting ORB into the kernel expressed some useful reasons for doing so (even if they are just for experimentation).
I'll see your senator, and I'll raise you two judges.
The HURD is apparently going to offer CORBA as the primary means of inter-proccess communication.
This is thuroughly false information. One of the fundamental units of a Microkernel architecture is a uniform network/port based communcations subsystem. I don't know a lot about it but it has NOTHING to do with CORBA. 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'm not sure what CmdrTaco's problem is, but this idea isn't all that bad. I'm not convinced this is the right approach yet (been burned by old CORBA stuff too many times), but the concept is definitely a step in the right direction. I've often wondered why nobody has done this before. By "this" I mean constructed a remote interface mechanism at the device level. There are higher level remote interfaces that allow sharing of "resources", but these are all too specific to be useful across the board. As an example, I can share my printer(s) with Samba or lpd but why can't I share my modem or sound card in the same way?
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.
Really? I think that most of the kernel in Win2K is pageable, and that it is only about 2 megs that is locked. I have a malfunctioning machine that forgets how much memory it has once in a while, and I've run Win2K on it when it thought it had just 16 megs. I was actually surprised at how well it ran; it wasn't until I opened Photoshop and loaded an image that I realized it had lost most of its memory.
If you are modding me down because you disagree with me, use the "Flamebait" category, not the "Troll" one.
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)
Potato chips are a by-yourself food.
Once again, the kernel tinkerers have provided us with another gem. This sort of experimentation with the core of an operating system is exactly the sort of thing that having the source code available encourages. While this implementation is probably not even safe to be considered beta software, it's good to see people playing with the boundaries.
To those who moan about code bloat in the kernel, they obviously haven't looked at how large the kernel sources are already - it's already huge. But this size doesn't matter - what matters is the code you choose to stick in your kernel - as almost all the peripheral code can be modularized or ignored, the core kernel loaded at boot time remains small and you can choose to ignore code you consider unnecessary or even dangerous, or put rarely used functions into modules to be loaded on a need-to-use basis, to be unloaded as soon as you are finished with that functionality.
So what possibilities does having the ORBit code in the kernel hold out in the future, for those who choose to make use of it? Faster, slicker handling of the CORBA transactions is the main one, and for those of us who might like to take the risk of destabilizing the system and experimenting with this stuff, we can.
It looks like they have latency problems with this code though - they should probably try integrating their code with Ingo Molnar's low latency kernel patches (average system latency under load down to 3ms - extremely nice for multimedia applications) and see whether their peak latency of ~1 second can be reduced. Oh - and by the way, those low-latency patches are not in the kernel sources, so you'll have to add them in yourself if you want to play with them. Much as you'll have to add the kORBit patches if you want to play with these either.
And finally, to those kernel hackers who do this sort of mad, mad, mad hacking, cheers!
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
Actually, the Linux kernel is pretty good about not making components depend on 'non-published' APIs too much. Most of the benefit I have seen from the linux kernel architecture comes from components not needing to talk through kernel components to other components (yay, ten context switches for a fork()).
There are two main reasons the kernel doesn't support 'standard mappings' of interfaces for drivers. First, it destroys the possibility of change. Even in the current kernel, old interfaces stay around way too long. Second, many fear it will promote binary drivers. Since there is no company which maintains all of the kernel, binary drivers provide a substantial disadvantage to the linux kernel (the architecture group can't examine or port drivers, because they do not have access to the source code or the hardware workings). A standard interface only promotes that: the current setup is that when a kernel interface changes, it is not their problem, and the third party company needs to update their code to match. Look around for quotes from the main kernel developers about them wanting binary-only module maintainers to 'wake up in a cold sweat every once in a while'
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
Win2k (with its 40 million lines of code -- 500% bigger than Linux -- and still called "micro").
40 million in the kernel, or the OS? The OS includes an awful lot of extra goodies beyond the kernel... IE, Explorer, Notepad, that crappy pinball...
"don't fall into the fallacy of believing that Perl can solve social problems. Maybe Perl 6 can, but that's a ways off"
This idea sounds good for:
1. Remotely debugging device drivers
2. Security holes
Hmm, just what I need, another project.
All CS departments should adopt Linux as the basis for their operating system courses since it allows exactly this sort of experimentation.
In some places it already has been. The story gives one example; also, Prof. Steve Mann at the University of Toronto has undergrad students under him do their thesis work in Linux, since that's what runs his wearcomp.
I find it quite appropriate that Linux is getting use in schools. Correct me if I'm wrong, but didn't Linux start in the first place as Linus' school project?
---Be gentle, it's my first post!
SIG: 11
Use your time better and make an ascii giver instead.
thttpd claims that it'll smoke the crap out of apache. I haven't had the time to test it, but I wouldn't be surprised. Apache is a busy program... it has a lot to do.
The HURD is apparently going to offer CORBA as the primary means of inter-proccess communication. And due the HURD's micro kernel architecture it can probably be done without the bloat of having an orb compiled into a monolithic kernel.
--
enterfornone - logging in for a change
- 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.-Chris
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!
"The quality of life is determined by its activites."--Aristotle
> You know, things like khttpd and that sort of
:)) GUI representation of that data.
> thing (I'm sorry, but a Web server is no more an
> integral part of the OS than a Web browser).
On the contrary, a web server has more in common with an NFS server than a web browser.
Let's think about what a web browser does. It opens socket connections, it sends requests/responses, it parses a data stream and transforms that parsed input into a visually pleasing (at least some of them...
Let's think about what a basic web server like khttpd does. I accepts socket connections, sets some variables, looks up local files and passes the file data through the client-initiated connection. Khttpd is unique in that it passes unrecognized requests to user-space (not rocket science).
Let's look at what NFS does. I accepts socket connections, looks up local files, handles file locks to avoid write contention, accepts file data sent to it, and sends file data to the client.
Both NFS and khttpd handle file I/O -- a duty generally attributed to the kernel.
> This is less of an issue in an Open-Source
> kernel than it is in a closed-source one...
#include <soapbox.h>
Open Source != less buggy. Open Source simply makes bugs visible to more people -- ESR's principle that "given enough eyes, all bugs are shallow." It is possible for a closed source alternative to be technically superior to an Open Source model. Haven't most poeple on Slashdot heard of BeOS yet!?
Microsoft did not kill (or heinously wound depending upon your point of view) IBM and Apple. Arrogance did IBM and Apple in. Microsoft was simply there to pick up the baton.
The worst thing that you can do for the Open Source (Free Software, Libre Software, whatever) movement is *assume* that the solution that you prefer is better simply because it is the solution that you prefer. This is the fastest way to become blindsided by the truth.
> 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.
Your statement is inflammatory for the following reasons.
1) At this point, there isn't much in the Linux kernel that isn't complex.
2) NOTHING should be allowed into the kernel until it's rock solid for obvious reasons.
3) Comparatively little IS allowed into the stable kernel proper until it's rock solid for obvious reasons.
I say BRAVO! to the authors of this kernel hack. If it turns out to be useful, horray for Linux because it is good. If it turns out to be crippled by design, horray for Linux because they could try.
How many great works throughout history have been squashed or postponed because others said it should not be done?
- I don't need to go outside, my CRT tan'll do me just fine.
... but it plays one on TV.
________________________________________
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
> The closer Linux gets to being more like windows
> the more bloated and unstable it becomes.
Bloated with what exactly? Bloated because it supports more hardware than ever before? Bloated because it supports more platforms that ever before? Bloated because it's faster than ever before? Bloated because it handles more drive space and RAM than ever before?
Or bloated because the codebase has grown due to the above reasons? You might as well call a trilogy bloated because the first book was good.
It's GPLed code. Don't want a lot of the "bloat?" Take it out and compile just what you need. Think that the previous versions of the kernel were better? No one's stopping you from using them. Don't like the rest of the trilogy? Throw away the last two books and simply re-read the first one.
And finally, if the Linux kernel is so bloated, than how did an IBM engineer port it to a wrist watch? Answer: He took what he needed and threw the rest away.
- I don't need to go outside, my CRT tan'll do me just fine.
It's an interesting experiment in creating a distributed operating system, but it's certainly nothing to put on your production system. Give it a few years (assuming people are willing to actually explore this) and it just might be something Tanenbaum would put in his next book (or maybe not). I also gotta wonder what the performance hit is, when the module you want is on the same machine requesting it, vs the non-Corba kernal (obviously if the module is on anther machine, you've got to deal with network latencies).
cb
cb
Oooh! What does this button do!?
It's pretty bad when no one "gets it" until comment #37... before this post I see people getting moderated up to +4 Insightful for completely idiotic pseudo-technical posts about making it faster.
There isn't really anything wrong with writing kernel modules in order to support appliances. It's probably going to be one of the biggest benefits of the Linux kernel architecture, but that doesn't mean modules like khttpd or ORBit should be part of the main kernel distribution.
If you know what you're doing and want to build a custom appliance (e.g. super fast web server), you can add in the modules you need. But by no means should this stuff be part of the standard kernel -- that just starts to smell way too much like Microsoft's "design", with all of the resulting interdependance and patch bloat.
And before you start claiming that you need the performance boost, take a look at how much it would cost to upgrade your CPU, add more memory, or otherwise boost your system. Is it really worth risking system stability to save those few dollars? If you need that kind of performance, aren't you probably in a commercial environment that can afford the hardware?
I do not fail; I succeed at finding out what does not work.
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...
SSL Certificate
Um... Not really. It's almost trivial to put something inside of something else, 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 are probably the best way to go, but even then you're not necessarily safe. 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? 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!
--
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
The closer Linux gets to being more like windows the more bloated and unstable it becomes. and yet even most Linux users must admit with every release of windows, windows suck less and less. Linux kernel hackers aka "people with too much free time on there hands" are only too willing to overload the kernel with unnessasary crap. i'll give credit where credit is due, MS knows that some think windows suck and they actively go out to make it work better. that takes direction, the kind that Linux currently lacks.
I agree!
> wouldn't be the first OS to more closely tie the GUI to the kernel.
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.
My Karma: ran over your Dogma
StrawberryFrog
Im pretty sure that the entire kernel muct fit inside real memory, it can't be paged out to s swap file / partition.
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.
the colonial powers left and we became independent.
Also, christianity mainly means killing muslims and not using condoms for most of us.
What would happen? Nude men with AK-47's would come and take you away.
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. :-)
--Fesh
--Fesh
Kill -9 'em all, let root@localhost sort 'em out.
The proper way to fix Linux is to fix Linux, not to hide all the broken stuff under a layer of latency-adding abstraction. Do you ever do performance tests on your ideas or do you just code with the force? Very non-obvious things can have huge impact on performance and therefore usability. Adding a layer of abstraction will not help.
If you think I'm wrong, look at NT... it's all abstracted. If you want NT you know where to get it.
Gnome ported to windows... Gnome orbit into Linux kernel... What's next? Gnome takes over the world?
So who's going to put Mozilla into the kernel?
-Chris
Can't wait for the mozilla team to finish those performance enhancements...
Opinions change daily as new information arrives. Stay tuned.
This reminds of a joke one of my CS graduate profs told about the "endo-kernel" (a pun on MIT's exo-kernel). The exokernel is an extreme microkernel operating system the provides direct hardware access for each application. The endo-kernel, however, runs its OS in micro-kernel userspace processes for protection and runs user apps in the kernel space for performance! ;-)
cpeterso
I know most people will shudder, but this is possibly great news for Linux on the desktop.
;-).
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
-- Merc "And you thought you were your own worst critic."
That actually *is* pretty funny. :)
;)
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.
pb Reply or e-mail; don't vaguely moderate.
Why every ridiculous post in Slashdot contains the words GNOME? Maybe because they don't know how to improve the desktop (o whatever they think it is) and spend their time doing useless ports and useless "projects".
This has happened at UCLA too. The OS course now uses linux for it's projects. Unfortunately, I took it a couple years ago when they were still using MINIX!
--
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
Like someone who says being beaten as a child did them no harm yanks like you can't even see that power is not perfection
.oO0Oo.
admittedly you have the skankiest crak houses in the world but it isn't much to talk about
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I don't think a kernel ORB would be bloat. If anything, it could lead to a [em]de-[/em]bloating of the kernel, because it would allow us to remove things that really don't belong in the kernel. You know, things like khttpd and that sort of thing (I'm sorry, but a Web server is no more an integral part of the OS than a Web browser).
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.
----------
"...or have you been able to compile a 2.4 kernel as zImage?"
Yes, I have. I needed to build a kernel for an IBM 730T (tablet computer with PCMCIA hard drive) which I could loadlin and fit on a ramdisk. Disable the extra features and you get rid of the bloat. It's really that simple.
Bow-ties are cool.
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.
All about me
sub Send_Packet { /f(irst\s)?p(ost)?/;
($data, $dest, $port) = @_;
if ($dest eq "slashdot.org" && port == 80)
{
return 0 if $data =~
}
# continue...
}
if only Red Hat would ship THAT with their default distro...
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.
That was a highly informative post, Mr. Anonymous Coward. Too bad only one moderator decided to +1 it up. What you describe could be done in BSD or Linux with a userland display service communicating to either the video metal or a kernel space frame buffer device, but it would have to be pervasively threaded along with all the application widget libraries, and it would be a completely different protocol and design from X. Actually, it sounds pretty cool. :-) Is it network transparent, and designed to be remote displayable?
Still, as far as a single serial event stream is concerned, I doubt X is any more faster or slower than most others. Though I have to admit, the design you describe (in only a few paragraphs) makes me want to take a closer look at Be, if only to get a basic understanding of it's underlying mechanisms. Given what you wrote, it appears different, and in certain circumstances, more efficient, than X. I'd be particularly interested to read any knowledgeable posts which contradict your post, in terms of efficiency (that is, I believe that what you wrote is technically accurate, but wonder if others contradict you on performance).
Thanks again for your reply.
--Maynad
What a great platform Linux is for as both an teaching aid and as the basis for experimental work. All CS departments should adopt Linux as the basis for their operating system courses since it allows exactly this sort of experimentation.
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.