Linked by Eugenia Loli on Fri 19th Dec 2003 02:30 UTC
Original OSNews Interviews Robert Love, well known figure for his kernel hacking, preemptive patch and his recent book (review), joined Ximian recently in an effort to improve the Linux desktop experience via kernel development. Today we feature a mini-Q&A with Robert about this new project.
Order by: Score:
Re: BeOS
by JBQ on Fri 19th Dec 2003 02:47 UTC

"That said, I think the reason BeOS is so often touted as being very responsive is that it was highly threaded and traded throughput for latency at many levels."

Latency vs. throughput is always a tradeoff (if you can win on both fronts, the original design was just bad).

I wouldn't list threading as a factor. In quite a variety of cases the OS felt very responsive even though the number of threads involved was not any higher than it would be e.g. between an X server and an X app.

One of the real reasons why the OS was responsive was that it had very few "giant locks".

Another reason is that the scheduler was aggressive. The heartbeat was set to 3ms but seldom triggered. Timers were extremely accurate, and the latency from IRQ to uses-space was very low.

Yet another reason was that the client-server communication was highly asynchronous.

And one last reason (the one that Eugenia invoked) was that several core user-space processes (and especially the app_server) were very careful to use the kernel in ways which were known to be effective (surprisingly, those ways mostly involved to try to NOT reschedule too often, so that a useless latency improvement wouldn't result in a visible loss of throughput).

by Freshman on Fri 19th Dec 2003 03:20 UTC

JBQ, in what ways was app_server different, and similar, to X?

re: JBQ
by blah on Fri 19th Dec 2003 03:23 UTC

today has been a great day because you have been posting on a lot of stories and it is certainly nice to have a truly informed person making comments on such things.

by SmallStepForMan on Fri 19th Dec 2003 03:24 UTC

It should be interesting to see how OpenBeOS behaves when it comes to perceived responsiveness. I still cannot uselinux as a desktop OS because it lags badly (haven't tried 2.6 yet). Since OBOS are trying to revive the BeOS look'n'feel, it will be interestnig to see how it behaves performance wise. Incidently, the OBOS app_server seems to be near alpha stage as we speak.

re: JBQ
by blah on Fri 19th Dec 2003 03:28 UTC

also, it would seem to me that Linux is moving in the direction of design that you outlined BeOS to have had.

by blah on Fri 19th Dec 2003 03:29 UTC

try fedora, it is very responsive.

by Eugenia on Fri 19th Dec 2003 03:34 UTC

>try fedora, it is very responsive.

After doing some stuff on Gnome, try clicking the hat menu. It gets unresponsive for about 3-4 seconds. This (bug? I am not the only one seeing it) only started happen with Fedora, and it doesn't happen on other distros. Probably some of the patches Red Hat added creates this specific unresponsiveness which is pretty irritating.

v Summary
by Anonymous on Fri 19th Dec 2003 03:58 UTC
Sorry, quote is in this post
by Anonymous on Fri 19th Dec 2003 04:00 UTC

We should be doing cool stuff, like asking the user if they want to copy their photos to a new album.

There we go.

Pretty Responsive.
by Anonymous on Fri 19th Dec 2003 04:00 UTC

Linux is pretty responsive for me. More than any OS I've used(XP, OS X). But I'm sure Gentoo had a part to play in that. A few apps take for ever to load and are just outright sluggish, though. (OOo anyone?) Others take a while to load, but once loaded they are responsive. Others just load fast and respond equally well. Then 2.6 changed that all. :-)

by blah on Fri 19th Dec 2003 04:05 UTC

no worse than Windows XP. I get lags like that with my menues in XP so I do not really care as much.

by DrLinu on Fri 19th Dec 2003 04:28 UTC

no worse than Windows XP. I get lags like that with my menues in XP so I do not really care as much.

I thought I was the only one getting those lag under Windows XP.

by Anonymous on Fri 19th Dec 2003 04:52 UTC

My dual boot with suse 9 is faster then windows XP. Perhaps because suse is able to use much more of my ram then xp, even dipping into swap at times.

Re: @Freshman
by JBQ on Fri 19th Dec 2003 05:03 UTC

"in what ways was app_server different, and similar, to X?"

Well, those are two totally different beasts, actually. X is a standardized and fairly rigid generalized protocol with many different implementations. The app_server on the other hand used a custom and ever-changing specialized protocol.

I can't talk in detail about any X implementation, the only one I ever had a remote look at was a basic port of XFree86 to BeOS (probably around 1999, and it was not even a current version), and at the time it looked quite primitive and looked more like a reference implementation than like optimized production code (I don't mean to offend anyone, but sometimes you need to do a few ugly things in order to squeeze performance out of your code).

In terms of protocols, the app_server relied heavily on two mechanisms, shared heaps and kernel-level message queues. It couldn't have worked without those. Once, for the sake of the experiment, we tried to serialize parts of the app_server protocol through a byte pipe (similar to what X does) and the performance was so poor that we gave up before even making bitmaps work.

Oh, and there was some behind-the-scenes black magic with the way scrollbars were handled (anyone who tried to inherit from BScrollBar would have noticed). At some point some other types of views were handled entirely inside the server, including the Terminal (but very few people used versions of BeOS where that was the case).

HAL and D-BUS...
by \k on Fri 19th Dec 2003 08:12 UTC

Don't make me puke!

The perfect interface was invented *long* ago:
The File System

Fix Linux to support the most basic features a sane OS needs:
1) Per-process namespaces(already in 2.6, thanks Viro!)
2) (l)user-space filesystems(otherwise (1) is quite useless)
3) 9p support for transparent filesystem access

As for threading, if someone got a clue and did a useful threading system like Plan9 has had for ages; in most other OSes threads are just process with shared mem and some extra useless complexity thrown in, talk about idiotic ideas, for that you should add extra flags to fork() to indicate if you want shared mem, shared namespace, etc. you don't need the added complexity of threads for that.


by Anonymous on Fri 19th Dec 2003 08:50 UTC

I can confirm that we have very bad responsiveness on XP here in the 3 computers we have in my company:
- start menu is very slow, it lags when opening some submenus
- sometimes, the explorer does not respond for several seconds (does not display the disk content, even when only 1-5 files in the directory), most often via the network, but also often on the local hard drives. (systems are two P4 3GHz and 1 centrino 1.5GHz).

Linux unresponsive
by stopdabombing on Fri 19th Dec 2003 09:00 UTC

I'm sure I'll get flamed for saying this, but I am really tired of the wide variation in responsiveness of linux depending on distro, hardware etc. I mean, with XP, I pretty much know what to expect with a given set up - memory amount and kind, hard drive speed, video card etc. I can look at a specs of a system and pretty much predict how XP will behave on that system (and that includes various tweaks).

Now, that simply is not the case with linux - you can have exactly the same OS version (same distro, same kernel, same everything) and yet, there is no way to say how this will behave on any given system - other than *maybe* extremely general stuff like "more ram, faster" (and even that is not dead certain sometimes).

I really think that is due to something inherent in a combination of non-optimized drivers, various combinations of DE stuck on top of the kernel each responding differently and apps which in linux rarely seem to be written with responsiveness in mind (mind you, I'm not talking about different distros that mix and match and patch and hack their own brews). It's a mess. It's a bigger mess than XP or OSX.

I don't know about others, but to me personally, responsiveness is very important, and I am amazed at how many linux users are so willing to put up with absolutely dog slow performance - stuff that raises my blood pressure instantly. I don't know if there is even a cure for linux possible... sure 2.6 might be faster, but boy that's only ONE of a dozen factors... it's like pushing on a string. The worst thing is that you can spend weeks tweaking your system, and it still will suddenly and inexplicably go into "slow mode". Say what you will about the XP cow - at least it is consistently mediocre. Rant over, flame away.

by Anonymous on Fri 19th Dec 2003 09:32 UTC

A kqueue implementation for Linux seems like a nice way for delivering arbitary kernel events to userspace. Better than having X diffrent notification schemes for diffrent devices/subsystems, and much better than polling ,say, files in /proc/ .. Any thoughts ?
Oh, read

v Re: HAL and D-BUS...
by Luke McCarthy on Fri 19th Dec 2003 09:32 UTC
RE: Latency
by smoke on Fri 19th Dec 2003 09:53 UTC

I thought I was the only one getting those lag under Windows XP.

no youre not. i had stuff like explorer crashes (filemanager and desktop crashes and reloads and stuff - apps who dont want to start because theyre crap - norton security bla for example A LOT) luckily not on my computer, but on some others.

windows people just reinstall everything then, if they care about performance, update to the latest internet worms etc.

Re: Linux unresponsive
by smoke on Fri 19th Dec 2003 10:00 UTC

it really depends also on what you do to "optimize" your system. some jerks just break more, and some supposed low latency patches make the desktop even more sluggisher. i stayed since 2.4.18 with debians default binary kernel, and i have no ui-lag or similar.

and yea i can wait for some app to load. but never longer than some seconds. (you dont expect gimp to spring up in one second - nor do you expect that from photoshop - rhythmbox also loads as fast as itunes)

one thing bugging me at the moment are some bugs in gnome-theme-manager, but i think when i apt-get the new ones it might well be fixed.

I disagree
by Dekkard on Fri 19th Dec 2003 10:14 UTC

The perfect interface was invented *long* ago:
The File System

The thing is, as I understand from Robert Love's answers, right now in order for the desktop to detect an usb hard disk being plugged you need to make polling.

Also think that to get hardware stats on linux you do things like catting /proc, and so on.

Filesystem abstraction is nice, but I guess a message passing system for hardware notifications is a necessary step for the desktop. Unless you want to poll the filesystem to detect changes (not very optimal, IMO).

RE: Linux unresponsive
by Anonymous on Fri 19th Dec 2003 11:02 UTC

I am the one who posted the comment with mentions of 3 computers under XP.
I am sorry you feel wounded by the fact that several Windows user compare their experience about the lack of responsiveness of Windows XP.
As for Linux, using Mandrake since 7.0 (kernel 2.2) and having used Debian Slink (2.0) before (kernel 2.0), I have always have acceptable responsiveness with it. Kernel 2.4 is a wonder in my opinion. I have a 600 MHz PC at home, and have never experienced latency problems (mouse jumping or xmms skipping) with it, even when I compile scribus or gimp (this can be a 1 hour task on my computer) and have other tasks on.
This maybe related to my light DE configuration (Rox-Filer + Enlightenment), but I have consistently a responsive desktop under heavy load. At work, I can hang (no answer for 10 seconds) XP when Matlab or other soft are computing heavily. Never on Linux.

Sorry if you do not appreciate my experience, but I am no liar and you will have to live with this fact.

PS: by the way, the 3 PCs I mentionned previously all are installed by Professional Windows administrators, not by me.

No, thanks
by Drazen Gemic on Fri 19th Dec 2003 11:09 UTC

That will turn Linux in some kind of windows on Linux
kernel, and might even compromise kernel operations.

I like small and simple UNIX philosophy, I do not mess with
KDE and Gnome.

I hope it will never happen. Otherwise I wold have to
migrate to FreeBSD.


v Re: Filesystems are crap
by Anonymous on Fri 19th Dec 2003 11:14 UTC
Re: No, thanks
by Michele on Fri 19th Dec 2003 11:31 UTC

> I hope it will never happen. Otherwise I wold have to migrate to FreeBSD.

You should've years ago then.

Go Robert !
by anonymous on Fri 19th Dec 2003 11:34 UTC

Oh yeah !

Why the file system is the perfect interface?
by \k on Fri 19th Dec 2003 11:34 UTC

"All resources in Plan 9 look like file systems. That does not mean that they are repositories for permanent files on disk, but that the interface to them is file-oriented: finding files (resources) in a hierarchical name tree, attaching to them by name, and accessing their contents by read and write calls. There are dozens of file system types in Plan 9, but only a few represent traditional files. At this level of abstraction, files in Plan 9 are similar to objects, except that files are already provided with naming, access, and protection methods that must be created afresh for objects."

"... file systems and name spaces offer an effective model around which to build a distributed system. Used well, they can provide a uniform, familiar, transparent interface to a diverse set of distributed resources. They carry well-understood properties of access, protection, and naming. The integration of devices into the hierarchical file system was the best idea in UNIX. Plan 9 pushes the concepts much further and shows that file systems, when used inventively, have plenty of scope for productive research."

about winxp
by Anonymous on Fri 19th Dec 2003 12:08 UTC

it's slow. but

Windows server 2003 is very fast.


Congratulations Novell/Ximian
by cwoelz on Fri 19th Dec 2003 12:32 UTC

If this is the direction Novell/Ximian is going, to improve linux desktop in general, not focusing only in one part of the community (the GNOME part), but providing integration and general improvements, they truly deserve my sincere thank you.
RH and SUSE were already going in this direction. There is no reason a GTK/GNOME app could not feel at home in a KDE desktop and vice versa.
Sharing common infrastructuro only make things better.

Re: Dekkard
by tuttle on Fri 19th Dec 2003 12:51 UTC

If you want to find out when a file has changed without polling, there should be a very fast and low-level mechanism to get notified for file changes, like there was in BeOS. In linux there is the dnotify system call, but it is only useful for single directories, and not for whole directory trees. This is an area that definitely needs improvement.

In windows, there is an API that lets you watch a complete directory tree for changes of a certain kind. I would love to see something like this. Things like live queries would be very easy to implement given efficient file systems like reiser4 and file change notification.

Not a mess...
by Bryan on Fri 19th Dec 2003 14:23 UTC

"not talking about different distros that mix and match and patch and hack their own brews). It's a mess. It's a bigger mess than XP or OSX. "

Nope. Strip out everything but an equivalent amount of barebones "comes with the OS" software, like Notepad equivalents (Kedit, kppp, etc.) and you would find that they are just about all the same speed. Load a bunch of stuff on windows and you get varying degrees of load times and responsiveness as well. Try bearshare if you want slow.

v Wow
by PC Gremlin on Fri 19th Dec 2003 15:32 UTC
re: Stopdabombing
by samb on Fri 19th Dec 2003 15:42 UTC

I'm sure I'll get flamed for saying this, but I am really tired of the wide variation in responsiveness of linux depending on distro, hardware etc.

I strongly suspect that a lot of the bad responsiveness people report is due to harddrives not being in DMA mode. Way too common, unfortunately.

by Rayiner Hashem on Fri 19th Dec 2003 15:42 UTC

They do have something like that, its called imon/FAM. Both GNOME and KDE use it.

by fubler on Fri 19th Dec 2003 15:54 UTC

imon only works for the node you told it to watch, it doesn't recurse into subdirectories. So if you are monitoring a directory and you add files to a subdirectory of that directory you will get no event from FAM or imon. You have to manually set up your query to do that, no big deal really but it isn't equivalent to BeOS or Windows.

BeOS and node-monitor/queries
by JBQ on Fri 19th Dec 2003 17:14 UTC

As far as I remember BeOS can't node-monitor an entire hierarchy (the name "node-monitoring implies that you can only monitor one node), and I'm sure than queries can't search on the path.

by tuttle on Fri 19th Dec 2003 17:17 UTC

I know about FAM. But unfortunately it is just a library that does its own polling. This works just fine when you want to watch for the properties of a folder to change to display the changes in a file manager such as konqueror (and that is in fact what it is designed for).

But if you wanted to do something like using tiny files on reiserfs as extendable attributes and doing live queries on them, this would be way too slow. There really needs to be a fast low-level mechanism for watching for file changes in whole directory trees.

Unfortunately I have no idea how to implement something like this. I asked hans reiser about such a feature, but he answered that such a feature would best be implemented in the linux VFS layer.

I have no detailed knowledge on how the VFS layer works and wether it is capable of handling extremely small files, so I can not implement it myself.

But I still think such a feature would be great. You could represent arbitrary attributes as tiny files in a directory, so you would get all the advantages of live queries without breaking the simple unix principle of "everything is a file"....

by tuttle on Fri 19th Dec 2003 17:24 UTC

I do not know how live queries were implemented in BeOS. Obviously you are way more qualified to answer this :-)

But having a way to monitor an entire filesystem hierarchy for changes would be immensely useful. It would not be simple to implement (all sorts of nasty race conditions when querying a constantly changing file system), but it would be a very simple interface.

It can not be too hard to do this, since NTFS supports it. You can e.g. watch for changes in all files named "test.txt" in your entire C: tree, and it does not even slow the system down noticeably.

RE: BeOS and node-monitor/queries
by Bruno G. Albuquerque on Fri 19th Dec 2003 17:24 UTC

Yep, BeOS can not monitor entire hierarchies. OTOH, you can monitor a directory and get notified about entries added/removrd to it and, with that info, start monitoring the new entries.

Also, yes, you can't do path-based queries. They're always system-wide. You can, of course, programatically filter the query results to only display the results that match a specific path.


by Bruno G. Albuquerque on Fri 19th Dec 2003 17:28 UTC

Node monitoring is not really the same thing as queries. You *CAN* ask the system for all files that match "*.txt" and then get notifications about files that match it being created or removed anywhere in the hierarchy. That works pretty weel, in fact, when you consider BFS. OpenBFS even has improvements on this (like searches on non-indexed attributes).


Re: Bruno G. Albuquerque
by tuttle on Fri 19th Dec 2003 17:40 UTC

Getting changes for all files matching a certain pattern on the whole directory tree is not as good as what NT provides, but it would work well enough. Is this possible under linux, or are you talking about BeOS?

RE: Re: Bruno G. Albuquerque
by Bruno G. Albuquerque on Fri 19th Dec 2003 17:56 UTC

I am talking about BeOS.


"Processing overeating"?
by Anonymous on Fri 19th Dec 2003 18:11 UTC

If your processor is overeating you've got more problems than just responsiveness in your GUI... or maybe it's grown too lethargic from all that overeating....? :-) time to put the P4 on a crash diet.

I believe FAM only resorts to polling if there is no kernel level mechanism present.

However, if imon or dnotify (the linux equivalent) are patched into the kernel's VFS, you get very efficient behavior, without polling. dnotify is standard in the kernel since somewhere in 2.4.x.

I wish more people knew about this. It's such a good way of doing things.

re: MarkWPiper
by tuttle on Fri 19th Dec 2003 21:41 UTC

Yes, you are right. FAM uses dnotify if available. But since dnotify can only query a single directory it is basically useless for anything more complicated than a file manager. BeOS live queries or even the NTFS mechanism (whatever it is called) are way ahead of this.

Re: Linux unresponsive
by W Tarchalski on Fri 19th Dec 2003 21:46 UTC

<quot>one thing bugging me at the moment are some bugs in gnome-theme-manager</quot>

done with the 2.5.0

Bogging down...
by Mark Potochnik on Sat 20th Dec 2003 03:37 UTC

In previous versions of Mandrake when I moved large numbers of files, the system would bog down, and stall.
In the latest MDK 9.2, I did the same tasks without any problems. This was a VERY noticeable improvement... They probably backported stuff from 2.6 to 2.4 for MDK 9.2...

I can't compare to Win because I've been windows free for 46 months!


live queries
by on Sat 20th Dec 2003 03:46 UTC

"BeOS live queries or even the NTFS mechanism (whatever it is called) are way ahead of this."

Who cares? Copying, moving, creating, and unlinking files on unix way, way, waaaay faster than on BeOS and NTFS - why do I or the kernel need to know what is happening with files "live"? "Live queries" sounds like a pathetic hack to overcome bottleneck elsewhere that no one using Unix (or Plan 9) is even thinking about because it's a non issue.

BeFS was horribly slow (try tarring/untarring and rm -rf ing the kernel source tree on a BeOS). Smart admins know that if they want to do lots of queries they can run a DB server. Come to think of it ... never did see a lot of Oracle deployments on BeFS so what good is it for real "queries"?

Re: live queries
by timecop on Sat 20th Dec 2003 05:15 UTC

> Who cares? Copying, moving, creating, and unlinking files on unix way, way, waaaay faster than on BeOS and NTFS - why do I or the kernel need to know what is happening with files "live"? "Live queries" sounds like a pathetic hack to overcome bottleneck elsewhere that no one using Unix (or Plan 9) is even thinking about because it's a non issue.

Hello idiot.
Sometimes, you want to know when a given file in a directory changes (= log file updated, new file arrived by file transfer, etc) and you don't want to "ls" that directory every second to find out. It would be a lot easier if the kernel told you "file blahblah located in /blah/blah changed size".

Now, go back to compiling your shit and leave desktop for Windows XP.

RE: Re: live queries
by Kevin on Sat 20th Dec 2003 09:50 UTC

Getting a tad touchy there aren't we?

Come on people, this is a discussion place. Not a battlefield. An OS is an OS and we *all* know that Windows XP isn't exactly a shining example of what's best.

by tuttle on Sat 20th Dec 2003 10:03 UTC

I know that creating and changing files under Linux (especially ReiserFS) is way faster than on NT or BeOS. But I was talking about *watching for file changes* in a directory tree. And that is way, way, waaaay slower under linux than under BeOS or even NT.

I would like to combine the advantages of Reiser4 (excellent performance especially with small files, ***transactions***) with the nice features of BeOS (very fast change notification) to create something really advanced on par or better than the Longhorn WinFS.

Reading your post I get the impression that you do not even understand the problem...

2.6.0 vs. 2.4.22
by Emil 'opi' Oppeln Bronikowski on Sat 20th Dec 2003 11:52 UTC

Well, I like the interview. And speaking about Linux being unresponsive I must disagree. My KDE under 2.4.22 was very reponsive and with full release of 2.6.0 it rocks. I would like to say: ,,Go and make it better than ever'' to Robert Love. And thanks for all the good work.

No new monopoly
by Chreo on Sat 20th Dec 2003 12:36 UTC

From the interview:
"I am very stoked -- world domination has never been so attainable."

This is what keeps me away from deploying Linux on my home systems. We would never want to replace the Windows monopoly with a Linux one. We want a healthy competition (not quite there yet) that spurs development. That such a prominent Linux developer says this is to me very disturbing

Linux can and should be so much more. I'll stick with *BSD until something radically changes in the Linux community
*flamesuit on*

Unhappy binary drivers
by Rich Lewine on Sat 20th Dec 2003 17:57 UTC

As a business/personal user, I'm disturbed by Robert's answer to Eugenia's question #7.

"Robert Love: There is definitely no plans to make binary drivers happier. Linus has made it clear: he and many other kernel hackers just do not care about them. I don't mind that, either!"

We, the users, just want to get our work done. Sometimes, that requires installation of a device that requires a driver. We don't want to recompile anything, just have the device work the way it's supposed to work. Binary drivers help to make that possible for the non-techie.

Not caring about the user's experience is a sure way to inhibit "world domination." MS now dominates because they understand and cater to the "unsophisticated users" that comprise well over 95% of the computer users of the world.

v Rich Lewine go to hell
by \k on Sat 20th Dec 2003 21:54 UTC
Binary/closed source/module/blaha
by Peppo on Sat 20th Dec 2003 23:09 UTC

By Rich Lewine (IP: - Posted on 2003-12-20 17:57:31
As a business/personal user, I'm disturbed by Robert's answer to Eugenia's question #7.

You understand that binary drivers (modules) are just fine? They're talking about closed-source drivers/modules. nvidia's stuff is even worse since it's non-standard junk all over.

RE: Binary/closed source/module/blaha
by Rich Lewine on Sun 21st Dec 2003 01:17 UTC

No, I didn't realize that closed source was the object of his comment. Perhaps if I were a programmer it would have been obvious. That just makes my point. Assumptions seem to be made about users capabilities, from both a knowledge and skill perspective.

I do, however, now better understand their position (Linus, Robert, et al); an open source OS should have open source drivers/modules. So the challenge appears to be getting nvidia, etc., to agree and comply. Apparently, not an easy task, even getting them to open their source for others to do the work.

I'm still troubled. OSS leaders seem to be as intransigent as the proprietary bunch. Unless there is a meeting of the minds, a commonality developed, This standoff could go on interminably. The users are the losers. . .and that's who this stuff is for. Linux is no longer a hobby OS.

dnotify and multiple directories
by Warren E. Downs on Sun 21st Dec 2003 06:54 UTC

The design of Unix is to have few and simple kernel calls which can be used in powerful ways. dnotify does just one thing and does it well. If you want to monitor an entire tree, write a recursive descent function which sets up dnotify for all nodes in the tree. Then, if notified of new directory creations, add dnotify for that directory. No need to make a simple system call complicated.

Yes, it adds a little more code on your part, but only if you need it, not for every programmer who doesn't need it.

And, efficiency wise, it will be just the same as if you had a single system call to notify on changes to an entire tree.

RE: Binary/closed source modules
by Warren E. Downs on Sun 21st Dec 2003 06:58 UTC

I agree, it is disturbing to see the standoff between OSS leaders and hardware companies developing proprietary drivers.

Fortunately, there are a few distribution companies that are making that effort for users, but unfortunately, each one solves the problem incompletely, and in their own way.

Hopefully, someone will be big enough to see beyond their own turf, and solve it for all of us.

Re: dnotify and multiple directories
by diego on Sun 21st Dec 2003 14:14 UTC

the problem of dnotify is that it *needs* a file descriptor per file monitored, as file descriptors are limited this makes monitoring a whole tree o subtree impossible.

Linux SE can do this without the need of keeping a file descriptor per file, maybe in 2.7 we will hace a solution based on the hooks provided by Linux SE.

RE: Binary/closed source/module/blaha
by LinuxLobbyist on Mon 22nd Dec 2003 00:54 UTC

I really don't get why people consider this a "standoff" between OSS leaders and hardware companies. I think it was Wired that interviewed Linus recently where he indicated that though it is a problem today, it's not likely to last.
It used to be like pulling teeth to get specs for various SCSI cards from hardware vendors, much less actual open source drivers. Now since Linux is so big on the server side of things, these vendors fall over each other to make sure their devices work with Linux and have no problem releasing code or at least specs for them so that Linux can have fully GPLed drivers for them out of the box.
I (and Linus, as it seems from his interview) believe this will happen with Nvidia and ATI and any other vendors who product binary only drivers for devices geared toward the desktop. Eventually. To make it easier for these vendors to NOT release their code will ensure that they will never release their code.
Given how often new graphics cards, in particular, are released, the argument the vendors use about preventing people from using the code to reverse engineer the card and produce a clone is bogus. Has anyone successfully reverse engineered quickly changing hardware using source code for drivers in an economical way and survived as a business? That's an honest question, but I'm guessing the answer is no.