Slashdot Log In
Ars Technica Interviews Robert Love
Posted by
CowboyNeal
on Fri Jan 23, 2004 04:37 AM
from the getting-to-know dept.
from the getting-to-know dept.
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.)"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Gnome is more then creating a desktop (Score:4, Interesting)
>A GNOME spreadsheet you want Miguel? Don't worry. The way things are
>looking, I can hack one out in a few days. We will borrow from X, Y, and Z
>projects since they have most of the functionality we need. It will be a
>matter of fitting them all together."
I find it always funny that KDE supporters always list re-use of existing libraries as a big minus point of Gnome, as if it is a bad thing to re-use and adopt none-Gnome supporting libraries,
It is my vision that this is one of the great strengths of Gnome. In Gnome the supporting libraries are almost never Gnome dependent they often use already existing libraries or help to modify them too their needs, without Gnome-ifying them. When they create a new one for use in Gnome they tend too make it as generic as possible, With this sort of philosophy you create functionality that is easily adopted by other projects or was already in use or planned to get used. Things like Cairo (X-server), Fontconfig, ATK, etc. This is exactly why this functionality is popping up everywhere in open-source land. Which makes the KDE supporters scream that Gnome is taking everything over. This isn't true, but Gnome by using the above philosophy, doesn't alienate itself from other Linux/*nix projects in stark contrast too KDE. Gnome is not only about building a great desktop, it is about building modular desktop technology that can be used and reused by more projects then Gnome only, which make Gnome more cooperative too other projects then KDE.
As example below a quote from Robert Love (from kernel fame) in a interview too Arts-Technica developing for Ximian about his project Utopia:
[Begin quote]
Love: Project Utopia's goal is to fully integrate the Linux system, from the kernel on up the stack, through the GNOME desktop, its applications, and finally to the user. Therefore, Project Utopia is very GNOME-specific.
But Project Utopia is composed of many small components, and each component is intentionally being developed separately and abstractly. Thus, a GNOME desktop (or any desktop) is not required for much of the functionality and another desktop environment could (and should!) provide the missing pieces.
The system is architect-ed in such a way that the only components actually at the desktop layer are policy mechanisms, such as gnome-volume-manager, and glue layers/libraries, such as any forthcoming notification system.
Components such as udev and hotplug are obviously entirely agnostic to the rest of the system, as they are (or will be) required pieces of nearly any Linux system. Other components, such as D-BUS and HAL, can likewise fit into any system. I very much hope that both of those projects find wide adoption.
In response to your example, I think that a server with no desktop environment would still benefit from this work. In fact, it would just use Project Utopia as far up the stack as needed, definitely making use of udev, D-BUS, and HAL.
[End Quote]
Now do you think that at KDE they will be glad to get such technology? Oh sure they will take it and probably "adapt" it (like the Borg that is) into there desktop, but for sure the work they will put into it will only benefit KDE and while this is happening they will scream and whine till the end that Gnome is about adopting and Gnome-ifying (giving project Utopia as example off-course, because the technology will get adapted in lots of non-gnome projects), while little somebody else can use is coming from the KDE community (it is all of the KDE or die, look at Red-hat and user-Linux how KDE treads other visions).
The question is: Do you want a *nux/Linux community desktop which takes from (Fontconfig, Cairo, librsvg, etc) and gives too (Project Utopia, GTK+, Freedesktop.org, Gstreamer, ATK, Pango, etc) other projects (Xfree86, XFCE4, etc) without making everything it touches Gnome or do we want the none-*nix/Linux philosophy of one big API in the form of a win32 clone which alienates everything no
Re:Gnome is more then creating a desktop (Score:5, Funny)
Parent
Re:Gnome is more then creating a desktop (Score:2, Informative)
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 l
Re:Gnome is more then creating a desktop (Score:3, Informative)
Re:Gnome is more then creating a desktop (Score:3, Interesting)
KHTML depends on Qt, mostly QString, one class. Apple wrote a wrapper so they wouldn't have to bundle Qt with their web-browser.
I know little about Gecko, but would be amazed if it has no dependencies.
Re:Gnome is more then creating a desktop (Score:2)
Re:Gnome is more then creating a desktop (Score:5, Insightful)
1) KDE, as a project, is not Borg-like. We like to use other technologies when they work, and we use (and/or invent) better ones if the existing things don't work properly. (See CORBA.)
2) While it's nice to leverage existing technology and architecture, if you make use of too many existing projects it becomes an absolute nightmare to build everything from scratch. Even installing from binary packages is a huge pain - there are literally dozens of packages, and getting the dependency order correct is just insane. Can you tell me off the top of your head which libraries gdk-pixbuf, gtkglarea, ORBit, and libzvt depend on? I didn't think so.
3) Using all sorts of different projects means that you have different APIs for every library. One of the really nice features of having KDE based on Qt is that Qt provides a very nice, sane, predictable API for all sorts of different things - the same methods are available whenever they make sense. And since all of kdelibs is distributed as one package, and developed as one large package, the entirety of the API is much more cohesive than the ORBit API plus GTK+ plus libxml plus libsoup plus any other independently-developed libraries that you might need to include to get the functionality you need.
KDE and GNOME are evolving to serve very different markets and that's ok. I'm a KDE developer and I'm excited about everything in Project Utopia, even the GNOME-specific parts, because it gives me a chance to see what they do that I like and what they do that I dislike in their GUI and I have the opportunity to do things differently without duplicating the entirety of the Project Utopia tree. To use a very common analogy, it's much better for someone to reinvent the hubcap on the wheel than to keep reinventing the entire wheel every time.
Parent
Re:Gnome is more then creating a desktop (Score:2)
You point an interesting example in that it, too, shows little more than differences in development philosophy. Below I'll represent the respective team's decisions as I understand them.
KDE: "Oh no, CORBA is bad, we don't grok it, the existing free implementations suck, we don't like its exceptions, we don't like inout parameters. Let's sit and hack together our
Re:Gnome is more then creating a desktop (Score:2)
I couldn't tell you off the top of my head what libraries the KDE libraries depend on either (and I'm a KDE fan). Besides, that's what ldd is for (please excuse the crappy formatting):
Re:Gnome is more then creating a desktop (Score:5, Interesting)
---
It is at once a strength and a weakness. By reusing existing libraries, they gain interoperation and speed up development. However, at the same time, they give up any semblence of a highly architectured, well-integrated platform. KDE has an extremely high level of integration and consistency precisely because the KDE project has an habit of making sure that anything that goes into KDE fits naturally into the desktop. One of GNOME's principle weaknesses is that its usage of external libraries tends to destroy integration within the desktop. In KDE, pretty much everything uses the same text-editing component. You write a text-editor KPart, and it'll work in KMail, KWrite, Kate, KDevelop, etc. In GNOME, pretty much everything uses a different text-editing component. When the Kvim KPart was developed, all of the above mentioned apps automatically got support for editing text with Vim. When Evolution got vim mail-editing support, gedit and anjuta didn't automatically get it. When GNOME's HIG adopted a new Okay/Cancel button order, apps had to change their code to adopt to the new format. In KDE, if the developers wanted to change the button order, they'd change a single line of code in a library!
Now do you think that at KDE they will be glad to get such technology? Oh sure they will take it and probably "adapt" it (like the Borg that is)
---
That really doesn't make a whole lot of sense. Most of Project Utopia is desktop agnostic. Its like the Linux kernel, or glibc. KDE will "adapt it" as much as they "adapt" any other low-level API. They'll write a KDE wrapper for it and be done with it. (Without the KDE wrapper, it'd be C code, and C++ programmers don't want to use C libraries any more than C programmers want to use C++ libraries.) I don't really understand what's so borg-like about using APIs that were meant to be used in the first place?
into there desktop, but for sure the work they will put into it will only benefit KDE
---
Its hardly KDE's fault. They are building a well-integrated platform. They make extensive use of code-sharing because that is good software design, not because of some political reason. Anybody is free to use KDE's technologies, just as much as one is free to use GNOME's technologies. If people don't want to use C++ code, or depend on Qt, that's really their problem. I mean, the GNOME project seems to have no problems spreading the glib dependency all over the place.
Project Utopia
---
Most of this project (udev, hotplug, d-bus, HAL, etc) is not under the GNOME umbrella.
GTK+
---
Qt is there, and has the same number of dependencies as GTK+. And its GPL to boot. What's the problem here?
Freedesktop.org
---------
Freedesktop.org is *not* a GNOME project. None of the freedesktop.org software projects are related to GNOME. Enchant is the closest, because it comes from AbiWord, which has a GNOME version... Hell, KDE has more representation on freedesktop.org than GNOME does, because D-BUS is directly modeled on DCOP, and is a key component for freedesktop.org.
Gstreamer
---
Again, not a GNOME project. It uses glib, but then again, so does aRts! What gives people the idea that these things are GNOME projects?
ATK, Pango
---
These *are* GNOME-related projects, though Pango is more GTK+ related than GNOME-related.
other projects (Xfree86, XFCE4, etc) without making everything it touches Gnome
---
The GNOME project seems to have a tendency to push the idea that all the software it "adopts" is related to GNOME. Key example: many people now think that OpenOffice is a GNOME app, because it is part of "GNOME Office." Its absolutely ridiculous!
one big API
---
KDE actually has a highly modular API. Try developing for it sometime. Its very complete and very consistent, but that doesn't mean
Parent
Re:Gnome is more then creating a desktop (Score:2)
Re:Gnome is more then creating a desktop (Score:2)
Re:Gnome is more then creating a desktop (Score:3, Interesting)
That's a straw-man argument. KDE supporters don't "always list re-use [...] as a big minus point."
The same is true of KDE.
I th
Re:Another example (Score:3, Insightful)
And if you think that Novell will pay for Ximian developers to program something that will take away their Groupwise market, I want some of what you're smoking.
Also, I would love to know how exactly anything in the KDE API looks even remote
Re:Another example (Score:4, Insightful)
The example you are pointing to is in fact one of the best examples you could have given that you are completely wrong with your reasoning.
The KDE Groupware project builds on Kolab
http://kolab.kde.org/
The Kolab Server has been a KDE independent project from the start in 2001. You don't need _any_ KDE libraries to use it and it's not built on top of anything that would be KDE specific. It was intentionally built this way to make it possible for other projects to _use_ it as well. It has been finished and stable since more than 8 months ago.
Still I don't see Ximian using it - Instead they seem to reinvent their own wheel from scratch now
And as you would find out if you were more open minded this isn't the only example where KDE creates technology which has never been KDE specific and which is has been discarded by other projects just to reinvent their own wheel.
So much for the pot calling the cattle black
Regards,
Torsten Rahn
Parent
Kernel Preemption... (Score:5, Funny)
I was on this mailing list... (Score:4, Funny)
Must.... Read... Headlines (Score:5, Funny)
Oh well, back to my deranged little world...
Re:Must.... Read... Headlines (Score:5, Funny)
Parent
Strange (Score:5, Insightful)
Linux already works fine as a desktop; what most potential switchers need are a few good apps to fill the role of Quickbooks, Exchange, iMovie and a handfull of other programs. They're happy with any schedular as long as their ogg/mp3 player doesn't skip while loading a big spreadsheet.
As to GNOME and KDE? Well, they're fine if you think all Microsoft's HCI mistakes are outweighed by the need to make it easy for their users to switch to an equally badly designed system. I don't and so I couldn't care less about what the programmers on these projects are wasting their time on this week.
My wish list for the desktop is: a decent file system which stores meta-data beyond the file name and date stamp, a program which decodes the data in Quickbook files so I can import into Gnucash, and a single, working, font system. None of these are very urgent but they're all more urgent than anything mentioned in the article.
TWW
Re:Strange (Score:5, Insightful)
Linux already works fine, as long as you are a Linux guru, or if you never need to change the hardware configuration at all.
Would you like to read CompactFlash cards? Okay, plug a CompactFlash reader in to a USB port. Let's say your kernel was set up correctly, and lucky you, you don't need to run modprobe or edit modules.conf. But you still need to (for KDE) manually create an icon for the desktop to let you mount the CompactFlash reader, or (for GNOME) edit
The stuff that RML is working on right now would make it work like this:
You plug in the CompactFlash reader to a USB port, and it appears on the desktop. If your system is set up for it, GNOME then asks you [ximian.com] "Would you like to import these photographss into your photo album?"
This is the sort of ease-of-use that Apple brags about. And I think it's really cool.
steveha
Parent
Re:Strange (Score:2, Informative)
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 wh
Re:Strange (Score:3, Informative)
Linux Guru? (Score:3, Funny)
Don't sabotog your argument with such language.
I can show you a whole bunch of people who use Linux as a desktop and aren't computer experts. The bulk of the Slashdot userbase.
I'm not a Linux guru but I certanlly use it for my desktop. Cmdr ("Do I LOOK like I could make a Linux Destro?") Taco is yet annother example.
It dosen't take a computer expert to pull up a shell SU into root start up the Linux config tools and recompile the Linux kernel.
Nither dose it take a Lin
Re:Strange (Score:2)
Gnome then asks you...
Wow, does it come with a cute cartoon paperclip too?
How much of this is ready for use? (Score:5, Interesting)
Is udev ready for use by typical Linux users (as opposed to kernel hackers)? How about sysfs -- that is just part of 2.6 and is completely ready, right? How about D-BUS?
Meanwhile, on a flamefest^H^H^H^H^H^H^H^H^Hdiscussion about KDE and GNOME, I saw a claim made that "hardly any GNOME applications use Bonobo". Is that true? If it is true, is it changing? (Wasn't a Network Object Model one of the fundamental things about gNOMe?)
I browsed RML's blog, and some [ximian.com] of the screenshots [ximian.com] look really cool [ximian.com]. I'm really looking forward to this stuff.
steveha
Re:How much of this is ready for use? (Score:2)
Although some Gnome applications, use Bonobo, I think their USE is fairly limited. Only in Nautilus (previews of files etc.) is is actually used. Oh, and some people use VIM in Evolution, why is beyond me (what's wrong with mutt?).
Clearly if KDE and Gnome use the same mechanism for embedding (D-BUS?) things would be better.
D-Bus is not kernel functionality, but userland. Further I suspect sysfs is usable and udev not.
Re:How much of this is ready for use? (Score:5, Informative)
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.)
Parent
Re:How much of this is ready for use? (Score:2)
http://www.advogato.org/person/murrayc/diary.ht
Re:How much of this is ready for use? (Score:2)
At the moment all IPC in GNOME generally goes through bonobo. For simple IPC that's fairly wasteful. D-BUS is a lighter solution for these cases.
OTOH, I think the only thing you need to do cross-component embedding is a way of telling the program which X plug to use. And that's _all_ that goes through bonobo. It could be done very simply through D-BUS too.
Re:How much of this is ready for use? (Score:5, Informative)
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.
Parent
Limited to Nautilus, Abiword, Gnumeric (Score:2)
Re:How much of this is ready for use? (Score:2)
Dom Lachowicz, Gnome Office Maintainer
Re:How much of this is ready for use? (Score:3, Informative)
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 c
Misread Headline (Score:3, Funny)
Cheers,
IT
Re:Misread Headline (Score:2)
"Hello. You are listening to a Donald Love media station.
Enjoy."
=tkk
Microsoft Bob (Score:5, Funny)
Just thought you'd find this interesting ehhe
Robert Love at FOSDEM 2004 (Score:2, Informative)
He will talk about "The Linux kernel and the desktop".
Re:Robert Love at FOSDEM 2004 (Score:2)
Ask him about leaving West Wing... (Score:2)
Re:The most important question (Score:2)
Re:I appreciate his work on the scheduler (Score:2, Funny)
Are you sure it's a "term"? I could have sworn it was just a term.
Re:I appreciate his work on the scheduler (Score:3, Informative)
Period.
Calling it anythign else is the kind of marketing deception that OSS is supposed to free us from.
Re:I appreciate his work on the scheduler (Score:4, Interesting)
This is just demonstrating the universal tradeoff in algorithm design: faster add vs faster access (see INSERT vs SELECT in DBs)
Parent
Re:I appreciate his work on the scheduler (Score:5, Informative)
Parent
O(1) (Score:3, Informative)
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...
F
Re:O(1) (Score:4, Informative)
Parent
If you'd look closer.. (Score:2)
Tra la la.
Re:I appreciate his work on the scheduler (Score:2)
Second, any running linux system is likely to have at least 50 or so processes running at any given time (of varying priorities) and at that point the O(1) scheduler has already "started to show its power." For all practical uses (desktop or server) the O(1) scheduler is superior to the previous 2.4 scheduler.
Jeremy
A few things... (Score:2)
A O(1) scheduler may very well be increasing, as long as it is bounded by a constant C. Think e.g. of a function approaching a line asymptotically.
The total overhead is not so different from past schedulers, the difference is in the distribution. Before, you'd have a good case where next task is scheduled = O(1), and a bad case where you need to recalculate the schedule