Slashdot Mirror
Ars Technica Interviews Robert Love
functor writes "Ars Technica has interviewed kernel hacker Robert M. Love of MontaVista/Ximian fame. He covers current and future developments in the Linux kernel and on the desktop, particularly concerning the Linux process scheduler and its enhancements for system responsiveness and also his work toward Project Utopia, an effort to make Linux's device management on the (GNOME) desktop transparent and seamless. (Robert Love is the principal hacker who worked on kernel preemption for the Linux 2.6 kernel.)"
One of the great things about Linux's scheduler is that it is O(1).
0(1) is a "term" from computer science. When applied to schedulers, it basically means that no matter how many processes there are to schedule, a 0(1) scheduler's overhead will not significantly increase.
Of course, with a small number of threads/processes to schedule, the Linux 0(1) scheduler will have greater initial overhead. It isn't until there are quite a few processes that it starts to show its power, and the more processes there are, the more useful it is.
On a busy server with 4+ processors and thousands of processes, a standard scheduler's overhead is so great that it often exceeds the overhead of most of the individual server processes.
With computer hardware more than anything else and computer software less than anything else, you get what you pay for.
>>esr>>
This terminology didn't originate in C.S.: it's been used in physics before the Eniac was even born and in maths even before that.
It's general meaning is that the entity described as being O(something) responds to a variation of "something" like "something"'s power that apears between the braces, i.e. here it's a constant, so the scheduler wont respond at all. You can have O(x), wich responds linearly to x's variations, O(x^2) wich responds quadraticly (non-linear comportements begin here), and so on...
Furthermore: it's not 0(1) (zero(1))... it's O(1) (O as in "Order of")
Dear clueless,
if you read the the evolution blogs and didn't get it that evolution is split into back-end server and client, then please stop reading technical stuff. Imagining you reading technical stuff is like reading following sentence:
hjsfhjf sjsdsj sjhfjsf jsjhj sfjh fjuusf sf jgjfsjugjsfgjhsfjh sfbjsfj sfh jsf hfjfhjfsdhfh
or better
reading OSnews.
Try installing evolution 1.5.2 (this is, dear clueless, the beta for evolution 2.0, whose back-end server is getting integrated in gnome 2.6)
Go to http://planet.gnome.org/ read "GNOME if you want to":
"GNOME 2.6 will also support Evolution Dataserver version 2.0, which provides real-time, read-write access to calendar and contacts data from the desktop."
Oh, wow.
/mnt/usb!" or "The user inserted an Audio CD". Bonobo is a cross-application component embedding system so that you can have the AbiWord viewer embedded into Evolution for inline-viewing of an attached word-processing document.
I'm not even a GNOME hacker and I can tell you you're pretty far off.
D-BUS isn't meant to replace Bonobo at all. D-BUS is a message bus architecture meant for passing messages between applications and the system - e.g. for the kernel to tell the desktop "Hey, I mounted a USB flash drive at
(FWIW, D-BUS is modelled heavily on DCOP, which we've had in KDE since KDE 2.0. D-BUS has both a system-bus mode and a session-bus mode, however, which DCOP does not, as DCOP is a session-bus system only. The current talk indicates that we'll be moving wholesale to D-BUS for KDE4.)
That's it. You don't need to do anything to make this work. Though, if you like you can rigth-click on the icon, select properties, and set things like "Auto-open Filemanager on insertion", which would give you a filemanager-window on the device automagically when the device is hooked up.
Yeah, Mandrake uses KDE by default (but includes Gnome and other WMs too.), my point is, what you want is *mostly* an issue of well thougth-out standard distro-configurations, and not really anything fundamentally new.
"I use KDE myself, and I haven't seen other projects use KDEs libraries. I'm not sure, but do KDE (or KDE afflicated) developers develop "external" libraries that is widely used?"
I use windowmaker, not kde, but because I have kde installed (including library), I have absolutely no problem using konqueror, quanta, kolf, kwhatever. Likewise I have gnome installed and have no trouble using most gnome apps. Interesting, as I'm not a huge fan of either kde or gnome as a desktop environment, but occasionally like some of the apps. konqueror is my man page viewer of choice, for example.
Perhaps one of the most interesting examples of kde code reuse in another context is Apple's Safari Browser which uses khtml .
It is true that hardly any GNOME applications use Bonobo. Its use is limited to Nautilus, AbiWord, and Gnumeric as far as I can tell. The Network Object Model was supposed to be a fundemental part of GNOME, but they really dropped the ball with it.
You see, Bonobo is based on CORBA. And CORBA, as I can tell you from working on a fairly large project using it, is a total piece of crap. Its a design-by-committe API that has no semblence of order, and requires a thousand page manual to describe a fundementally simple concept. Oh sure, CORBA is great in theory. Its platform independent, network transparent, feature-packed, well-supported by the industry, and with a good ORB (OmniORB or ORBit) can be quite fast. Its also an absolute bitch to program, and the API (especially the C++ one) is more horrid than even MFC!
When the component models of GNOME and KDE were being designed, I remember the debate between using CORBA and making something new. The GNOME people went with CORBA and stuck to it. The KDE people tried a CORBA-based system (OpenParts) realized how badly it sucked, and ultimately rolled their own (KParts). The GNOME people ridiculed them for going that route (reinventing the wheel, they said). Well, it is now 2004, and KParts is a phenomenal success on KDE, thanks to its simplicity and power. Meanwhile, Bonobo is pretty much marginal on the GNOME platform, even according to original creator.
A deep unwavering belief is a sure sign you're missing something...
For those who are interested (and happen to be in Brussels on October 21), Robert Love is one of the speakers at FOSDEM 2004.
He will talk about "The Linux kernel and the desktop".
KDE does not use libstdc++ either. They use Qt libraries. So instead of using string, pair, map, and map::iterator from the standard C++ libraries, they use QString, QPair, QMap, and QMap::Iterator from the Qt libraries.
Apple had to develop a compatabilty layer, called webcore, to get rid of KDE dependencies.
still reading?
I've run linux on the desktop for years now on all manner of hardware, and I tend to swap hardware like madman. Oddly enough, at least since RH 8.0 I haven't had to recompile a kernel EVER or manually edit anything to add USB devices. Hell, since Jan 1st I've upgraded to Fedora, put in a new motherboard/CPU (different chipsets for absolutely everything), added a USB CD burner, new network card, and swapped the ancient CD drive for a shiny new DVD drive. I didn't configure anything for any of it. It all just worked. Yes, Apple does it all very wonderfully. That's why I have a Mac also.
OK, I did have to actually install software to play a DVD, but big freaking deal, that's sort of expected.
this is getting old and so are you
blog
KParts isn't really anything like CORBA, it's far less ambitious for starters and is essentially little more than a glorified wrapper around a C++ class loader.
In particular, KParts must be written in KDE/Qt C++, ie they are tied at a fundamental level to KDE and Qt. You can write them in other languages if you can somehow export your languages classes via a C API (for instance Python) because you can write a code generator that builds a C++ wrapper around it, but if that isn't the case, for instance with Java/gcj, D, or whatever, then you're basically SOL. You have to be able to access your objects from C++ and you have to be able to link against Qt. It's obviously also in-proc only.
Now, for the purposes it was designed for, KParts has been a large success, but partly only because KDE has a tendancy to reinvent lots of applications internally to make them K enough, so obviously there are no problems using KParts.
Usage of KParts is non-existant outside of KDE apps, for obvious reasons, unlike Bonobo which is an optional dependency for some non-Gnome apps like AbiWord. That's not necessarily a bad thing, mind.
Having said that, I'm not sold that KParts is even a good thing. It was designed back when OLE and OpenDoc were fashionable, and a platform without the ability to do in-place editing of documents just wasn't cool. Since that time almost all major desktops have dropped or de-emphasised these features, except KDE. For instance, MacOS X doesn't appear to have one at all, and on Windows the traditional role of OLE has been blurred by initiatives like OLE Automation and ActiveX which bear little resemblance to traditional uses.
While KParts are used all over KDE, I see little evidence that this makes it a better, easier to use desktop. If anything it's harmful - Konqueror is the very definition of jack of all trades but master of none. In the few cases where document embedding is useful, specialist integration is the way forward for free systems I feel.