Re:MySQL is a poor choice to store important data.
on
Why Not MySQL?
·
· Score: 2
I fail to see how Berkeley DB is any better than MySQL.
Berkeley DB already supports transactions and ACID properties. MySQL doesn't. That makes Berkeley DB more solid at the low level. It doesn't support the high level. That's why neither is a complete substitute for Oracle.
Re:Why is MySQL more popular than PostgreSQL?
on
Why Not MySQL?
·
· Score: 2
I believe MySQL is so popular because it's simple, really fast, and very easy to work with. And not everybody really understands about the database integrity dangers inherent in MySQL's approach, or why they should even care.
I've often wondered if the MySQL frontend could be merged with a Berkeley DB backend... (There is an older version of MySQL that has been re-released under the GPL...)
Re:Is there a full-featured open source RDBMS?
on
Why Not MySQL?
·
· Score: 2
As a professional IT consultant working for one of the top names in the software industry I am working on a detailed report into the "open source" phenomenon (thanks to various people for pointing out that it is not freeware per se) as started by Linus Torvalds with his Linux operating system some six years ago. I browse this forum for insights into the Linux user and developer communities.
Allow me to correct you a bit further. "Open Source" is essentially a marketing program (on practical grounds rather then idealogical) for "free software". Richard Stallman started the free software movement when he started the GNU Project in 1984 with the aim of creating a freely-distributable reimplementation of Unix.
Linus Torvalds significantly popularized free software with Linux (which he started in 1991). Linus provided the last missing piece of the hitherto incomplete GNU system -- the kernel. It's a critical component, but bear in mind that without the prior work of the GNU project, Linux wouldn't be where it is today.
The "Open Source" movement was created in response to Netscape's announcement in January 1998 that they would release the source code to their browser. The relabeling has been very effective, as can be seen in events of the past two years. Netscape's source code release has been viewed by some as less successful, but Mozilla is alive and well, and has made very significant progress since the original source code release. Jury's still out on this one; my personal belief is that Netscape will be making a comeback in the browser marked based on the Mozilla efforts.
Anyway, my question is, is there a fully-featured open source RDBMS out there? Your help is appreciated.
You might want to check out PostgreSQL. It's an object-oriented RDBMS with SQL support as well as transactional integrity. It used to be considered only suitable for academic use, but much work has been done in the last 5 years, and from what I've heard it's one of the most solid free databases out there...
MySQL is a poor choice to store important data.
on
Why Not MySQL?
·
· Score: 4
I would never trust the master copy of any critical data to MySQL. It's a nice little database, simple and very fast. However, without transactions or journalling, there's no way to trust completely that the data is safe. I would use MySQL as a high-speed cache, but not as a master repository; you may need to rebuild the database at any time if it becomes corrupted.
Berkeley DB is one of my favorite databases, because it is also small and fast. Unlike MySQL, it does support ACID properties, transactions, journalling and rollback, etc. However, it doesn't support a schema layer or a SQL processor. It's designed for embedded applications.
Neither MySQL nor Berkeley DB is a substitute for a real SQL database. Berkeley DB at least has a solid foundation that could be extended to become a full SQL database, should someone write the necessary code. MySQL, on the other hand, has fundamental deficiencies that are hard to correct. (On the bright side, that's why MySQL is really fast.)
Is the user "Deven" so stone cold stupid that he falls for the "IT Consultant" troll bait?
It doesn't matter one bit that it was troll bait. Adding irrelevant stuff to the kernel is a bad idea, and even a troll could get other people thinking that maybe it's a good idea. The last thing we need is thousands of people clamoring to put every application into the kernel. (Sure, they wouldn't be heeded, but it would be a distraction nonetheless.)
Or is the user "Deven" actually a sophisticated troll herself?
Bzzt. Wrong on both counts: (1) I'm not trolling, and (2) I'm male.
Sure, it starts out as simple "sponsorship" messages. Right now it's only a minor nuisance. Later (as another poster mentioned), the output could start getting more and more gaudy and intrusive as in the world of DOS TSR's.
Eventually, it could degenerate as much as PBS has. PBS claims to be "commercial-free" public television, yet more and more of their programs have a professionally-produced 10-20 second piece from the sponsoring company, indistinguishable from any other commercial on television, except in that it's more likely to be a soft sell. What happened to simply announcing a list of names of companies and individuals? When did it become necessary to show company logos and finally full-motion professional video clips?
I'm not as concerned with the current messages so much as what this could become...
Why have you gotten so offended? If you don't like what I have to say then at least be polite, after all, it only reflects badly on you and hence Slashdot as a whole. I have commonly found an amazing resistance to different opinions amongst the "open" source community, which seems to me to be the antithesis of what you stand for.
Comments such as "XML should be in the kernel" betray a lack of understanding as to the proper function of the kernel. Worse yet, (unlike, say, khttpd), putting an XML parser in the kernel wouldn't provide any benefit. All you're doing is encouraging the kind of useless feature bloat that Microsoft is rightly loathed for. That's why people get upset about remarks like this; they don't want this attitude to spread further than it already has.
Anyway, what you are clearly unaware of is that the perception of performace and stability is far more important in the corporate domain than the actuality of the situation. By integrating XML into the kernel, you have provided Linux with a major marketing point for the people who are actually in charge of what their company uses.
You won't be able to maintain the perception of performance and stability if the actuality is the opposite. Even Microsoft, with its legendary marketing might, has begun to pick up on this fact a little. (Note how stability has become a marketing point for them; why would it need to be, but for the constant crashing of their existing products?)
The exact breakdown of an operating system varies from one OS to another. In general, the purpose of any "operating system" is to arbitrate and manage hardware resources. Anything else is basically fluff. XML parsing is an application support issue, and detracts from the core function of managing hardware resources. Occasionally, an application function may be put in the kernel for good reasons, usually related to huge performance advantages gained by an in-kernel implementation. (khttpd is an example of this.) Even this is resisted strongly, because it "pollutes" the most critical code in the entire system, and poses an inherent risk to the stability, integrity and maintainablility of the system as a whole.
Basically, to add an application-specific function to the kernel, you had better have a really good reason to be suggesting it, one that can be justified (and defended) on a technological basis. If Linus were to allow marketing considerations (such as this) to drive kernel development, not only would he lose the respect of most of his supporters, but the end result would be just as crappy as Windows, sooner or later.
Given that Linus himself has talked about "world domination", doesn't it seem short-sighted to ignore a major selling point in favour of your petty-minded arguments?
Keep in mind that "world domination" remarks are somewhat tongue-in-cheek. Yes, he's half-serious, but only half. He wants people to use Linux over Windows because it's a better system. It wouldn't remain better if this approach to kernel development were adopted. Keeping the kernel pure isn't a "petty-minded argument"; it's a critical element of good design.
All that said, you would have received a much different response had you suggested that Linux systems (as a whole) start integrating XML support , use XML for system configuration and provide XML services for applications. There's a good argument to be made for that, and the marketing value should be similar. There's also technological arguments to be made in favor of it. The distinction here is that this support would all be in "user space" rather than the kernel, even though it might be an integral part of the operation of the system as a whole. The kernel is the core of the system, and the idea of integrating XML into Linux does not imply that it belongs in the kernel.
Making the stack non-executable can intefere with valid code (e.g. signal handlers, nested function calls and trampoline functions) while leaving other stack-smashing exploits open to exploit. The libsafe library comes with an example exploit that will give you a shell despite a non-executable stack. Using libsafe will protect you from this attack without harming valid code. Making the stack non-executable remains vulnerable to this attack while breaking otherwise-valid code; the Linux kernel folks were right to reject the non-executable-stack "fix" to the problem.
I downloaded the code and looked through their whitepaper and the source code a bit. Here's the basic technique:
Install the libsafe library in/lib/libsafe.so.1.3. (Red Hat Linux 6.2 users might want to get the RPM.)
Set the environment variable LD_PRELOAD to point to the libsafe library. (The RPM installs shell init scripts into/etc/profile.d for Red Hat 6.2 shells to do this.)
Calls to "unsafe" C library routines (e.g. strcpy(3)) will be trapped by libsafe, which will figure out the size of the stack frame and reimplement the "unsafe" function safely (e.g. with memcpy(3)).
If the program attempts to overflow the stack frame (presumably from a stack-smashing attack), a message is logged with syslog (into/var/log/secure) and the process group is killed with the SIGKILL signal.
This interception is done at runtime, and works without source code or recompiling
This technique can guard against stack-smashing exploits that haven't even been discovered yet. (And might even help discover them earlier!)
There are a few caveats here:
There is a performance impact, but the overhead appears to be relatively low.
Since this technique relies on the dynamic linker (ld.so) to intercept the unsafe calls, statically-linked programs cannot be protected with this technique.
If LD_PRELOAD is used, setuid programs will not be protected because ld.so (properly) doesn't trust the environment variables when running setuid, and thus ignores LD_PRELOAD.
For system-wide protection, it is safer to use/etc/ld.so.preload instead of LD_PRELOAD; it will apply to all (dynamically-linked) programs, including setuid programs, and cannot be accidently lost from the environment.
To the packager of the RPM: how about using/etc/ld.so.preload instead of LD_PRELOAD? Maybe in libsafe-1.3-3.*.rpm?
I am not a lawyer. But I found an archived Slashdot article that discusses these issues. In the main article, Bruce Perens notes that the issue is a little more complicated because the GPL combines copyright law with contract law. Later in the comments (look for comment #45), an actual intellectual property attorney weighed in on the matter. Worth a read.
If linking is creating a derivative work, don't link. Let the user do the linking.
This has been discussed in the past, and I believe the concensus was that the application would still be a derived work by virtue of being intended for use with that particular piece of code. (Same goes for libraries that are only available in GPL form.) On the other hand, this theory may not withstand a legal test...
I don't think function names are copyrightable at all. Otherwise projects like WINE would be in a big trouble.
This is a good point. If Microsoft can't stop us from imitating their APIs (and I'm sure they would if they could), why should we expect to be able to protect our APIs? I don't know what the answer to this is...
Would you like to see more free software kernels out there, which could be used as part of a GNU system, as the Linux kernel is currently used? Would you like new kernels to be able to compete on a level playing field based on quality, technology and other merits? Would you like to eliminate a major barrier to entry for alternative kernels, including the HURD?
Enough of the rhetorical questions; here's the real question: Would you reconsider supporting Project UDI, so that developers don't have to waste time duplicating effort supporting the same devices in one kernel after another?
Yes, I know you've already addressed this question, but I believe it bears revisiting. Here is a quote from your opening:
If we imagine a number of operating systems and hardware developers, all cooperating on an equal footing, UDI (if technically feasible) would be a very good idea. It would permit us to develop just one driver for any given hardware device, and then all share it. It would enable a higher level of cooperation.
Isn't this exactly the sort of cooperation that free software is intended to encourage? Can't we work towards the ideal you've described? Must we shackle ourselves to poor legacy practices merely because proprietary interests could benefit? The free software community has a lot to gain here in the long term, and it may help us more than the proprietary interests in the end...
At risk of making this posting way too long, let me briefly respond to some of your objections:
"People could run free GPL-covered Linux drivers with Windows systems." If the GPL-covered drivers are dynamically loaded, this is probably true. However, the cat's out of the bag on this one; the proprietary company could always port the GPL driver to UDI themselves.
"It would not directly hurt us, either; but the developers of GPL-covered free drivers could be discouraged to see them used in this way, and that would be very bad." Look at the flip side; developers of GPL-covered free drivers might be very encouraged to see their driver used on a wide variety of free kernels, knowing that their efforts have been leveraged to increase the greater good. (This could outweigh the downside of possible use by proprietary systems, couldn't it?)
"People could run non-free Windows drivers on GNU/Linux systems." The cat's out of the bag on this one already also; since Linus has declared the API between the Linux kernel and device drivers to be public, and not covered by the GPL, it is already possible to distribute proprietary drivers for Linux. (One might try to argue that this is still improper under the GPL, but Linus would have to enforce it, and it appears that he won't.)
"To the extent that the community began to accept the temptation, we would be moving to using non-free drivers instead of writing free ones." This is a user/developer education issue more than anything. It is important to help people understand the value of freedom for its own sake. Many people have trouble with that concept (witness the struggles of the Libertarian Party), since too many people are willing to sacrifice liberty for convenience. This is an ongoing battle, with or without UDI.
"But why encourage the community to be weaker than it needs to be? Why make unnecessary difficulties for the future of free software? Since UDI does no good for us, it is better to reject UDI." Having a lack of stable APIs for device drivers makes us weaker. (Look at how often Linux drivers have needed to be recoded to adapt to kernel architectural changes.) Having incompatible drivers between different free operating systems (e.g. Linux, FreeBSD, NetBSD, HURD) creates unnecessary difficulties, keeping us much more factionalized, which makes us much weaker than Windows. If free operating system developers could cooperate and leverage their efforts, we have a lot to be gained here. What does Microsoft have to gain here? Not much; the hardware vendors will always write drivers for Windows without Microsoft lifting a finger, as long as Windows is the dominant platform. If we could level the playing field with UDI, Microsoft would lose a key strategic advantage they currently enjoy over free operating systems.
"Given these consequences, it is no surprise that Intel, a supporter of UDI, has started to ``look to the Linux community for help with UDI.'' How does a richand self-seeking company approach a cooperating community? By asking for a handout, of course. They have nothing to lose by asking, and we might becaught off guard and say yes." I agree that Intel was less than tactful in asking (nay, expecting) Linux developers to assume the burden of UDI driver development. (Bear in mind, however, that UDI originated with SCO a number of years before Intel recently jumped on the bandwagon; it started as a standardization attempt for UNIX systems.) Indeed, Intel is hoping to freeload off our efforts. They should have offered some fair compensation for our efforts, such as writing their own UDI drivers for all old and new Intel hardware, and releasing those drivers as free software along with hardware specifications. A commitment like that would have been taken more seriously. Instead, they asked for a handout, and it backfired on them. Now we have many honorable members of the free software community hostile to the idea of UDI (irrespective of the technology) because of the (correct) perception that Intel (and others) would like to take advantage of our efforts in this area. At the same time, "don't cut off your nose to spite your face." Free software can benefit greatly from a common API (whether UDI or not), and refusing to use one because it might help "the enemy" still leaves us in the same mess we've been in for too long. Let's evaluate it on the benefits we can derive, not on the benefits we can deny to the opposition.
"One way to make a deal a good one could be by modifying the UDI project itself. Eric Raymond has proposed that UDI compliance could require that the driver be free software. That would be ideal, but other alternatives could also work. Just requiring source for the driver to be published, and not a trade secret, could do the job--because even if that driver is not free, it would at least tell us what we need to know to write a free driver." Actually, a good start would be to convince them to honor their commitment to place the specification in the public domain as described in the following paragraph from the "Project UDI Policies and Procedures" page:
The definition of any specification developed by the working group will be placed in the public domain, not subject to copyright, patent or any other intellectual property right, so that any party may implement or utilize the specification. However, any party may develop and assert intellectual property rights over a particular implementation of the interface.
This statement couldn't be any more clear, yet the UDI 1.0 specification as finally released has an entire page filled to the brim with copyright declarations. A good question for Project UDI is why they failed to follow through on this commitment. (The lawyers probably insisted...)
UDI drivers released by vendors would be valuable to us, even if some of those vendors fail to release their UDI drivers as free software. First, the source to a non-free driver might be published by the vendor, simply to increase market share -- UDI compatibility is only guaranteed at the source level. Even if the source is not released, the UDI driver is tightly constrained; it must funnel all interaction with outside code and actual devices through the UDI environment implementation -- this allows "black box" investigations that can easily see what effects the driver has, even if the source is not available. This should make UDI drivers easier to reverse-engineer than Windows drivers, especially if a special "test-rig" UDI environment implementation was created to facilitate such reverse-engineering.
"One difficulty with any deal with Intel about UDI is that we would do our part for Intel at the beginning, but Intel's payback would extend over a long time." Not necessarily; we could implement UDI environments for free operating systems and wait for them to start creating some UDI drivers before we put too much more effort into it. After all, they have a vested interested; they'll surely invest some effort into writing drivers if they can't get us to subsidize their bottom line with charity work. Free-software developers might still port some drivers in their own interest (e.g. a FreeBSD hacker porting a Linux driver to UDI, perhaps) but we wouldn't have to "loan" our efforts to Intel (et al) if we choose not to. Even if we don't, we might as well implement UDI environments to take advantage of the work of proprietary companies...
Basically, I believe that a common device-driver API represents the best opportunity for new free operating systems to flourish without having to compete with established free operating systems (much less Windows) on the basis of levels of device driver support. Whether UDI is the best API for this, I don't know. Perhaps UDI will be a dismal failure for performance reasons, as Alan Cox repeatedly insists will be the case. Perhaps a better API will come along. But we need something if we're to stop wasting time retracing our steps over and over again. Right now, UDI seems like the best prospect, and I believe we should embrace it for our own benefit rather than letting fear of possible misuse dissuade us from improving our software and methodology.
Personally, I'd like to play around with writing a new kernel from scratch, even if nobody but me ever uses it. I may never finish (or even start) such a project, or it may never be useful compared to a mature kernel like Linux. Suppose (for the sake of argument) that I do finish it, and it's somehow superior to the design of the Linux kernel (as it sounds like HURD may be) -- would I really want to port all Linux drivers to this kernel and maintain them? Of course not. I'd much rather invest the time once in implementing a UDI environment, and support free-software UDI drivers, unchanged. That's what people mean when they talk about "working smarter, not harder"...
Here's a hyptothetical. What if the GPL'd code were compiled as a library to match an existing proprietary API. The library could be distributed freely under the GPL, and proprietary programs which would just happen to work with the GPL'd code also be written and distributed with impunity.
I am not a lawyer, but my understanding is that using an API which is specifically to access the GPL'd library makes the calling application a "derived work". If the application is coded to an existing API for non-GPL'd code, it cannot be said to be derived from the GPL'd code. Making a glue layer to translate the non-GPL API to the GPL'd library's API would be new code covered by the GPL. Linking the application with that library, despite the changed API, almost certainly requires the application to be distributed under the GPL.
If it's a shared library (DLL), the application can probably be closed, maybe even if the shared library is distributed with the application. If _only_ the GPL'd library is included, an argument might be made that the application is still a derived work; it might be necessary to include a proprietary shared library and leave it up to the user to replace it.
Check with a real lawyer if you're actually thinking of trying this.
On the ethical question of whether this is an okay thing to do, I'd say it's not. You may be able to find a legal way to do it (or maybe not), but legal != ethical. If you want to have the library used by a closed application, the best way is to convince the authors to relicense the code under the LGPL, which is explicitly designed for this purpose. Since they didn't use the LGPL, assume they don't want you using it with closed source. (On the other hand, if it didn't start as a library, maybe they didn't consider the possibility; they might be open to relicensing it...)
How will we know until we see it? If it sucks that badly, they'll probably either revise the UDI spec to make it perform well (which would eliminate the main argument against it), or punt and implement a traditional interface (which would be a tacit admission of failure). I don't know what will happen, but I wish them luck.
In the Linux world, the binary KPI is not considered relevant. The ABI has remained compatible from 1.2 (when ELF appeared) to the present day and is unlikely to change in the foreseeable future. The source KPI remains consistent within a stable series. Since the source is open and the source KPI is consistent, who cares about the binary KPI?
This is a serious problem. Do you remember what a nightmare it was to manually upgrade a.out systems to ELF? Even with all the source readily available, recompiling all that code is very painful. The more code, the more painful it is. Now that it's been stable under ELF from one kernel version to the next, hasn't life been easier? Application developers don't have to worry about capricious changes in the ABI for their ELF binaries; why aren't device driver developers accorded the same courtesy? This deliberate nonchalance about stable interfaces isn't "studly hacking"; it's amateurish and it shows.
There's over a million lines of device driver code in the Linux kernel. That's a lot of code to review and modify when changes are made. Device driver development could be less painful if a solid API/ABI (or KPI/KBI if you prefer) could be trusted not to change often. UDI aims for that kind of interface stability. It also aims for high performance. I don't know if it will meet these goals, but I'd rather give it a chance instead of running it out of town on a rail.
Imagine the uproar it would cause if the kernel hackers suddenly decided that they didn't care if ELF changed with every kernel revision and couldn't be bothered to keep backward compatibiltiy with old ABI's, and refused to accept such efforts contributed by others. After all, who care, if you have source code and the API hasn't changed? Oh, you don't have source to Oracle? Too bad, proprietary code sucks -- that'll teach 'em not to release their source!
This attitude is childish, and impedes the progress of the entire Linux community. Clean, solid abstractions are the basis of complex code. Do you really think you'd have such fancy browsers and word processors if they had to twiddle the bits on the screen at the application level instead of using GUI toolkits? I doubt it.
We need more stable interfaces, to make way for the Next Big Thing, whatever that may be. Right now it's hard to see the forest for the trees.
Consistent interfaces are the lifeblood of continued interoperability, whether you're talking about GUI fluff or kernel grunge. If lots of people call a function or use a data structure, great care should be taken to preserve that item's behavior or change it only for very good reasons.
Thank you!
Finally, someone who understands the real issues here and why the ad hoc methodology used until now is so limiting...
If you have any platform other than i386 then 99% of the time closed-source is exactly the same as nothing.
That's usually true right now. A big part of the reason is the cost required to port to other platforms and support them. On the other hand, if no actual porting is involved (just a recompile), even proprietary companies might be more willing to release binaries for multiple platforms, since it would expand their market for a smaller cost...
Face it, your typical Joe Linguru doesn't give a rat's ass about a new potential convert, especially a Joe Sixpack one.
It's the dichotomy of the Linux community, isn't it? On the one hand, you have people wanting to replace Windows everywhere with Linux everywhere. On the other hand, people are lamenting about how the lower quality of the average Linux user as more newbies show up.
We can't have it both ways, folks. The average computer user never gets far past "clueless newbie" in their skills. Now that Linux is becoming more of a mainstream OS, we're stuck with more average users. It's a trade-off that's tough to evade. If you don't like it, switch to an OS like HURD that is more hostile to average user. (Of course, if you could move UDI drivers from Linux to HURD, that would be a lot easier...)
Many corporates just can't see things that way.
Quite true. However, some companies are starting to see the light. Matrox, for example, is paying for an accelerated Linux driver to be written for the G400, to be released as Open Source. The result? They get a competitive advantage. (I just bought a G400, actually, for this reason.) Even if most companies don't get it, you only need a few enlightened ones...
Nice, really. But legally speaking, you won't be allowed to distribute these drivers. If you don't believe me, here's a quizz:
The KDE project is based on Qt, which isn't GPL: Yes/No.
The KDE project is under GPL: Yes/No.
As Debian pointed out, you can use KDE but not distribute it, as the GPL forbids you to distribute your software if it requires a non-opensource component: Yes/No.
The correct answers are "Yes", "Yes" and "Yes". We'll have the same problem with UDI, which will be to the driver what Qt is to KDE.
(This response is based on my understanding of copyright law, but I am not a lawyer; standard disclaimers apply. Could a real lawyer please check this and comment?)
This is an oversimplification. Copyright law only allows the GPL to exert influence over "derived works", which is why "mere aggregation" on a distribution media does not bring other code under the scope of the GPL. (This is explicitly acknowledged in the GPL, in fact.) Since KDE is a derived work of its own GPL code and the proprietary Qt code, the GPL should apply to the whole. (Hard to enforce when the KDE developers don't seem to care...)
UDI, on the other hand, is a specification which is not under the GPL. If Microsoft were to implement a UDI environment (an idea they're probably more to than Alan Cox is), that UDI environment code would be a derived work of the UDI specification, and could remain proprietary. Meanwhile, if a GPL'd Linux kernel driver were ported to make a UDI driver (perhaps by Microsoft), that UDI driver would be covered by the GPL, since it would be a derived work of the original GPL code. It would also be a derived work of the UDI specification, which wouldn't interfere with using the GPL.
So, this hypothetical scenario has a proprietary UDI environment, and a GPL-licensed UDI driver. Each is kosher on its own. The key question is, what happens when you combine them? As I understand it, if the proprietary OS loads the UDI driver dynamically, the GPL couldn't apply, because there would be no derived work for it to apply to. (This is akin to loading a GPL'd user program with a proprietary OS.) A direct quote from the GPL:
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works.
Here is the "mere aggregation" quote from the GPL:
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
Even from the words of the GPL itself, it seems clear that a proprietary OS with UDI (which is clearly identifiable as a separate work; it could also use proprietary UDI drivers) and the GPL'd UDI driver could even be on the same distribution medium without violating the GPL. Static linking, on the other hand, probably does bring the whole under the GPL. All the proprietary vendor needs to do is keep it dynamic loading, and I think they're in the clear.
Is there anything non "100% pure GNU" that Stallman don't consider as an international conspiracy of proprietarist to eradicate free software?:> (evil grin)
It's a quick and easy way to add the increasingly important Linux checkbox to their marketing gloss without giving up any of their docs or paying someone to write a driver.
Since UDI exists, you can't prevent this kind of game. They can still write a UDI driver, say "we support Linux!" and add "by the way, you need this patch to use our UDI driver" in the fine print. The glossies can still have that little checkbox, regardless of how hostile Linux kernel hackers may be to UDI. The solution to this problem is user education, not rejecting UDI environment code for a perceived (but illusory) idealogical benefit.
But maybe we're just splitting hairs anyway. The simple facts are that, politics and licensing aside, UDI will not be a part of mainline Linux anytime soon, if ever, and that this decision has been made for technical reasons, rightly or wrongly. We can argue the nontechnical side of things, but the people who matter don't care in the slightest.
Let's get real here. The decision was not technical -- plenty of low-quality drivers are allowed into even stable-series releases, even with little technical merit. As long as it's marked "EXPERIMENTAL", Linus will allow almost any extra drivers to be included. UDI environment code could be marked "EXPERIMENTAL", and it wouldn't impact those who don't enable the option. This wouldn't hurt anyone, and should be done. However, the kernel developers don't like the idea of supporting UDI, so they find technical excuses for why it "cannot" work to avoid including it.
I thought the Open Source way was to give the code a chance and let it succeed or fail on its own merits?
I'll give you another example. Years ago, Oracle said they were reluctant to consider porting their database (in part) because Linux had no support for raw disk devices. Linus (for whatever reason) hated the idea of raw I/O and insisted that all disk I/O must be buffered. His response to this genuine need was to the effect of "screw that, I don't think we need it, and Linux will never support raw I/O to disk devices." (Not an actual quote.) He insisted that he would reject patches for raw disk I/O even if someone else did all the work. It was because he didn't like it.
So, what happened with raw disk I/O in the end? It's going to be in the Linux 2.4 kernel. This is a tacit admission that there is a real need for this feature. It was resisted for years only because Linus preferred his way. (Of course, now devfs is being used as a technical excuse for this delay, because it "would have required too many device numbers" -- that never stopped other UNIX vendors...)
UDI is a lot like raw disk I/O -- it's against the preferences of the Linux kernel developers, and they don't feel it's needed. Nevertheless, there is a real need for this stuff, and it will probably happen eventually in some fashion; refusing to allow it just causes unnecessary strife. It's clear that when it comes to UDI, Alan Cox doesn't like it. Must we go through the same struggle as with raw disk I/O?
As you admit, it's already a problem where proprietary vendors are releasing binary-only Linux drivers and refusing to release source or specs. New Linux users can be just as lulled by these (potentially) low-quality binary-only native Linux drivers. This is a user training issue and a community issue. The problem isn't going to go away on its own.
It all seems like a wash to me. How does UDI actually make this problem worse than it is anyway?
Anyone who expects to run Linux on their computer should really buy hardware with Linux in mind.
That's true for early adopters. When I ordered my computer at the end of 1992, I made sure to select hardware (e.g. Adaptec 1542CF) that was supported by Linux and NetBSD, since I wasn't sure yet which I would run. (I quickly decided I liked Linux better.) Selecting the best hardware for Linux is obviously ideal, but not everyone has that luxury, or necessarily even knowledge of which hardware is best.
For those who are using existing hardware, I don't think UDI would offer any benefit. It is unlikely that hardware manufactures are going to provide support for old hardware via UDI, because there's little economic benefit -- they've already sold their product, support or no support, so there's no reason put extra effort forth (unless you want to keep your good name, but that seems to mean little to most hardware manufactures).
I'll tend to agree with you here -- vendors probably won't rewrite drivers for old hardware. On the other hand, old hardware is more likely to have Open Source drivers available. New hardware tends to be more troublesome; if new hardware started becoming available with UDI drivers, that hardware could be used immediately. If open source drivers were later written (or maybe higher-performance Linux-native drivers?), you could switch later.
Of course, there's always the "don't use that hardware" argument, but that attitude doesn't mesh well with the quest for World Domination (tm). Face it, your typical Joe Sixpack doesn't give a rat's ass when he buys his computer whether the hardware has Linux drivers -- but if you can make it run Linux anyway, and better than it runs Windows, then you may have a potential convert on your hands...
Hardware support for Linux is pretty good right now. While not everything is supported, a little of everything is supported. If you want a nice graphics card, you can get one -- not any graphics card, but you don't need any graphics card, just a single one that works well.
Linux probably has the best device driver support of any free OS, and better than many proprietary OS's. It can't match Windows 98, but it might actually have better support than NT 3.51 or NT 4.0 did? Linux is reaching critical mass and starting to become a significant target market for vendors, although still less important than Windows.
Now that Linux is more mainstream and less of an "alternative" OS, what about the other alternative OS's? What about HURD, FreeBSD, NetBSD, and even BeOS? They may all be great OS's, but they lack the driver support of Linux (especially HURD and BeOS), which is a barrier to entry. Years ago, people used to complain about how they'd like to use Linux, but it had little driver support -- now you hear the same about HURD or BeOS. Won't we be better off if new OS's can compete on features and merit rather than sheer volume of available device drivers?
UDI would keep even many good companies from releasing their specs, because they wouldn't have to do so to provide support. It would hurt Linux and its bretheren.
We can't stop companies from being shortsighted. You can always boycott such companies; that's nothing new. Smart companies would release UDI driver source (both for the "with enough eyeballs, all bugs are shallow" effect, and to allow the driver to run on as many possible platforms without needing to directly support each binary configuration) and specifications (so that the community could do most of their support work for them, reducing their support costs). Dumb companies that keep their source and specs closed will suffer a competitive disadvantage, which should encourage them to change their ways.
UDI drivers would (finally) separate out policy decisions and leave them in the kernel, where they belong. More improvements could be made to the kernel's driver code, because the API remains unchanged and drivers need not be recoded for architectural changes.
That's not the way things work. The ideal of providing the perfect abstraction is a nice, but unattainable, ideal. Innovation very often is a matter of changing the boundaries of abstraction. And Linux is great because there is that freedom to innovate. That freedom is one that is used a lot in the development of the kernel, and is part of what keeps the Linux kernel from getting too unwieldy.
At over 1.6 million lines of code, the Linux kernel is already somewhat unwieldy. (Nothing compared to Windows 2000, of course.) Over 1.1 million lines of that is drivers; decoupling driver development from kernel development would give both kernel developers and driver developers more freedom to innovate, because they wouldn't spend so much time tripping over each other!
While I agree that attaining a perfect abstraction is probably impossible, UDI looks to be a very, very good one. I'm amazed at how flexible it is, especially for an API designed by committee. It remains a matter of speculation whether or not it will be fast enough to be a system's primary API, but SCO and IBM must have some faith in it -- I'm told that UDI will be the only device driver API supported by Monterey, the "High Volume Enterprise UNIX Platform" (as their whitepaper describes it) being developed for Merced. I'll be interested to see if that succeeds; it sounds like a demanding environment.
There will be a UDI 1.1 or 2.0 or something. Even if the people behind UDI are quite intelligent and thoughtful, they aren't oracles, they can't see into the future, they can't predict what the demands on future APIs will be.
Of this, I am certain -- sooner or later, UDI will surely have to be revised, unless it dies completely. (The obvious reason why a revision might be necessary would be for performance reasons.) Project UDI has prepared for this; the UDI specs and the drivers themselves are versioned; if a UDI environment and UDI driver don't support the same API version, they will be able to tell. An OS supporting UDI 1.0 won't accidently try to run a UDI 1.1 driver and crash the system; it will simply refuse to run the driver at all.
In any case, hopefully such revisions would be rare occurrences. An OS could, of course, support several UDI versions simultaneously if necessary. Really, what are the odds that the UDI specification will change more often than the Linux kernel driver API already has?
Open Source drivers don't need to predict the future, because they can change. If other Unices want to get the hardware support that Linux has, they can GPL their kernels and make their kernel APIs compatible with Linux's, and then they are set. This isn't wholely unreasonable. And if they don't, well, tough luck for them.
Actually, the cat's out of the bag on this one. The very existence of the UDI spec presents an opportunity for proprietary OS vendors (even Microsoft) to support UDI in their system, then port Linux drivers to the UDI model. The ported driver would be GPL, but the UDI environment could remain entirely proprietary, and it would not violate the GPL since their code changes wouldn't be a "derived work" of the GPL code. It would be a derived work of the UDI spec, which isn't bound by the GPL. They can do this whether or not the Linux kernel developers support UDI.
On the other hand, this bugaboo isn't worth getting too alarmed about. Microsoft has little incentive to "steal" drivers this way -- they already have the most comprehensive driver support, courtesy of hordes of bootlicking vendors. Proprietary UNIX vendors have an incentive, but they still have a problem with the value proposition of proprietary systems -- increasingly, Linux is becoming recognized as a best-of-breed UNIX platform in more and more areas, and the proprietary UNIX vendors are bound to fall by the wayside sooner or later, with or without device driver parity with Linux. In short, this one is a red herring.
If Linux wants to get better hardware support, UDI offers almost nothing. Is someone going to make a UDI driver but not a Linux driver, because UDI has a 10% larger share? No. Are they going to make one for UDI because it's binary-only? Sure, but that's not what Linux needs.
Vendors can make binary-only Linux drivers now, and some are starting to. This is more problematic, because it makes it difficult to upgrade the Linux kernel.
As for why vendors might release UDI drivers instead of Linux ones, it's a question of leveraging their investments. If a vendor is targetting Unix-like systems, getting all versions with UDI would be better than investing in learning each individual native interface. Also, the UDI driver could actually be easier to write with a stable API that hides issues such as MP sychronization from the driver...
UDI represents the best hope for "fringe" operating systems (e.g. HURD) to get comprehensive driver support.
I think it's highly unlikely the HURD people want anything to do with UDI. Don't support it for their benefit.
Given Stallman's hostility towards UDI (he seems to believe it is a plot for proprietary vendors to rip off free software developers), you may be correct in believing that the HURD people will have nothing to do with UDI. That doesn't mean they wouldn't be shortsighted for that. If they ever want "the GNU system" (with HURD) to replace "GNU/Linux", they'll need to address the driver issue, and UDI is a better solution than trying to race Linux in these driver parity wars...
Who says free software needs to compromise? UDI is a technology that has significant potential benefits for free software, independent of political considerations. Yes, UDI also offers significant benefits to commercial, proprietary developers, but that's incidental. Don't cut off your nose to spite your face; use the best technology instead of hobbling yourself for purely political reasons.
Again, where exactly is the compromise here? How would enabling UDI drivers enable disreputable proprietary behaviors that aren't already being practiced anyway?
As for whether developers want to work on drivers, I have no objection if that's how they want to spend their time. However, I'm concerned about people who insist that vendors shouldn't write a driver and should only release specs so we can write the driver. Even with specs, not all drivers get written, and little-used drivers might be just as poor quality as typical vendor fare. I believe that the vendor should be expected to release open source to a basic driver and specs.
If they only release specs and we write the code, we're subsidizing their efforts -- let them shoulder the burden of making their products work. Once they've gone that far, it's more reasonable for them to ask the community to fix bugs and enhance the driver. Again, why should they expect us to do their work for them?
"A driver version should not be tied to a kernel version in the first place."
Linus and everyone else on linux-kernel disagrees with you.
Are you suggesting that their opinions are beyond even debating then?
Currently, device driver modules must be tied to the Linux kernel because code written for one kernel version often won't work with another version. If the API and ABI are stable, then you only need to version those and not every kernel code change, large and small.
See my previous post for a long response to another poster. I'll only address new points below...
This, I believe, may be only a chimera; there are enough differences between the mechanisms that are used to protect driver and kernel data structures from interrupt service routines and peer-processor access in the various OSs that it may not even be possible to create a set of UDI drivers, much less port them across major kernel architecture change.
Most such policy decisions (uniprocessor vs. multiprocessor, singletasking vs. multitasking, privileged vs. userspace, synchronous vs. asychronous I/O, VM or not, protected memory or not, etc.) are entirely contained within the UDI environment implementation on the OS side, and unknown to the UDI driver itself. In fact, the UDI driver code can be simpler, because it doesn't deal with interrupt masks, task switching, synchronization, etc. (Since the environment has to deal with these issues, the environment implementation is probably harder, but it only has to be done once for all drivers on that OS.)
Since some devices MUST BE present in the kernel to access a boot device (and console), there is no way to prevent rebuilding drivers into a kernel. The current system of modular drivers already permits non-boot drivers to be excluded from the kernel image, and these modules can be distributed as separate packages. BTW, I just ran a line count on 2.2.5; there is a total of 1005095 lines of source code.
While it makes the most sense for UDI drivers to normally be loaded dynamically, there's no reason some bootstrap drivers couldn't be statically linked with the kernel. After booting, those drivers could continue to operate, or possibly be replaced with dynamically-loaded (possibly newer) versions.
In my Linux 2.2.12 tree (generic Red Hat 6.1, I think), "wc -l `find . -name '*.[ch]' -print`" gives me 1642672 lines. Most of this is device drivers: 1117142 lines, or 68% of the total. Surely the kernel would be more manageable if this mass of code wasn't so tightly coupled with kernel internals?
The performance will be that bad, so the existing sort-of APIs will be used and all that will have happened is a lot of unused work creating the code to implement and support the APIs.
I agree that the jury is still out, when it comes to UDI performance. They've made efforts to keep it high-performance, but it's unproven. Even if the performance is poor, there are good reasons to support UDI.
If the Linux, bsd, etc. communities had been the driving aganecy for UDI, there's a good chance that the result would be a benefit to both users and device manufacturers. Since the current initiative is by M$ and the vendors that want to dump their M$-Windows drivers on Linux, bsd, etc., then YES it would be a REALLY, REALLY bad thing to implement UDI in Linux.
Why aren't the Linux/BSD communities driving UDI? UDI can be good for everyone but Microsoft. Project UDI is not a Microsoft initiative; they're not even a participant! (They also have the most to lose, as the most entrenched OS vendor.) The history goes back years (1993, maybe?) to a multivendor effort to create common drivers for UNIX systems. Major participants include Sun, HP, SCO, Intel, Compaq, IBM and others. SCO and IBM are putting UDI support in AIX, Unixware and Monterey. (For Monterey, I'm told it will be the only API for device drivers.)
Project UDI has an (outdated) HTML presentation that has some overview information to help give you a broad sense of the architecture -- it's well worth reading.
Slashdot Mirror
I fail to see how Berkeley DB is any better than MySQL.
Berkeley DB already supports transactions and ACID properties. MySQL doesn't. That makes Berkeley DB more solid at the low level. It doesn't support the high level. That's why neither is a complete substitute for Oracle.
I believe MySQL is so popular because it's simple, really fast, and very easy to work with. And not everybody really understands about the database integrity dangers inherent in MySQL's approach, or why they should even care.
I've often wondered if the MySQL frontend could be merged with a Berkeley DB backend... (There is an older version of MySQL that has been re-released under the GPL...)
As a professional IT consultant working for one of the top names in the software industry I am working on a detailed report into the "open source" phenomenon (thanks to various people for pointing out that it is not freeware per se) as started by Linus Torvalds with his Linux operating system some six years ago. I browse this forum for insights into the Linux user and developer communities.
Allow me to correct you a bit further. "Open Source" is essentially a marketing program (on practical grounds rather then idealogical) for "free software". Richard Stallman started the free software movement when he started the GNU Project in 1984 with the aim of creating a freely-distributable reimplementation of Unix.
Linus Torvalds significantly popularized free software with Linux (which he started in 1991). Linus provided the last missing piece of the hitherto incomplete GNU system -- the kernel. It's a critical component, but bear in mind that without the prior work of the GNU project, Linux wouldn't be where it is today.
The "Open Source" movement was created in response to Netscape's announcement in January 1998 that they would release the source code to their browser. The relabeling has been very effective, as can be seen in events of the past two years. Netscape's source code release has been viewed by some as less successful, but Mozilla is alive and well, and has made very significant progress since the original source code release. Jury's still out on this one; my personal belief is that Netscape will be making a comeback in the browser marked based on the Mozilla efforts.
Anyway, my question is, is there a fully-featured open source RDBMS out there? Your help is appreciated.
You might want to check out PostgreSQL. It's an object-oriented RDBMS with SQL support as well as transactional integrity. It used to be considered only suitable for academic use, but much work has been done in the last 5 years, and from what I've heard it's one of the most solid free databases out there...
I would never trust the master copy of any critical data to MySQL. It's a nice little database, simple and very fast. However, without transactions or journalling, there's no way to trust completely that the data is safe. I would use MySQL as a high-speed cache, but not as a master repository; you may need to rebuild the database at any time if it becomes corrupted.
Berkeley DB is one of my favorite databases, because it is also small and fast. Unlike MySQL, it does support ACID properties, transactions, journalling and rollback, etc. However, it doesn't support a schema layer or a SQL processor. It's designed for embedded applications.
Neither MySQL nor Berkeley DB is a substitute for a real SQL database. Berkeley DB at least has a solid foundation that could be extended to become a full SQL database, should someone write the necessary code. MySQL, on the other hand, has fundamental deficiencies that are hard to correct. (On the bright side, that's why MySQL is really fast.)
Is the user "Deven" so stone cold stupid that he falls for the "IT Consultant" troll bait?
It doesn't matter one bit that it was troll bait. Adding irrelevant stuff to the kernel is a bad idea, and even a troll could get other people thinking that maybe it's a good idea. The last thing we need is thousands of people clamoring to put every application into the kernel. (Sure, they wouldn't be heeded, but it would be a distraction nonetheless.)
Or is the user "Deven" actually a sophisticated troll herself?
Bzzt. Wrong on both counts: (1) I'm not trolling, and (2) I'm male.
On \., who can tell?
"On the Internet, nobody knows you're a dog." (Or a program that can pass a Turing test?)
Sure, it starts out as simple "sponsorship" messages. Right now it's only a minor nuisance. Later (as another poster mentioned), the output could start getting more and more gaudy and intrusive as in the world of DOS TSR's.
Eventually, it could degenerate as much as PBS has. PBS claims to be "commercial-free" public television, yet more and more of their programs have a professionally-produced 10-20 second piece from the sponsoring company, indistinguishable from any other commercial on television, except in that it's more likely to be a soft sell. What happened to simply announcing a list of names of companies and individuals? When did it become necessary to show company logos and finally full-motion professional video clips?
I'm not as concerned with the current messages so much as what this could become...
Why have you gotten so offended? If you don't like what I have to say then at least be polite, after all, it only reflects badly on you and hence Slashdot as a whole. I have commonly found an amazing resistance to different opinions amongst the "open" source community, which seems to me to be the antithesis of what you stand for.
Comments such as "XML should be in the kernel" betray a lack of understanding as to the proper function of the kernel. Worse yet, (unlike, say, khttpd), putting an XML parser in the kernel wouldn't provide any benefit. All you're doing is encouraging the kind of useless feature bloat that Microsoft is rightly loathed for. That's why people get upset about remarks like this; they don't want this attitude to spread further than it already has.
Anyway, what you are clearly unaware of is that the perception of performace and stability is far more important in the corporate domain than the actuality of the situation. By integrating XML into the kernel, you have provided Linux with a major marketing point for the people who are actually in charge of what their company uses.
You won't be able to maintain the perception of performance and stability if the actuality is the opposite. Even Microsoft, with its legendary marketing might, has begun to pick up on this fact a little. (Note how stability has become a marketing point for them; why would it need to be, but for the constant crashing of their existing products?)
The exact breakdown of an operating system varies from one OS to another. In general, the purpose of any "operating system" is to arbitrate and manage hardware resources. Anything else is basically fluff. XML parsing is an application support issue, and detracts from the core function of managing hardware resources. Occasionally, an application function may be put in the kernel for good reasons, usually related to huge performance advantages gained by an in-kernel implementation. (khttpd is an example of this.) Even this is resisted strongly, because it "pollutes" the most critical code in the entire system, and poses an inherent risk to the stability, integrity and maintainablility of the system as a whole.
Basically, to add an application-specific function to the kernel, you had better have a really good reason to be suggesting it, one that can be justified (and defended) on a technological basis. If Linus were to allow marketing considerations (such as this) to drive kernel development, not only would he lose the respect of most of his supporters, but the end result would be just as crappy as Windows, sooner or later.
Given that Linus himself has talked about "world domination", doesn't it seem short-sighted to ignore a major selling point in favour of your petty-minded arguments?
Keep in mind that "world domination" remarks are somewhat tongue-in-cheek. Yes, he's half-serious, but only half. He wants people to use Linux over Windows because it's a better system. It wouldn't remain better if this approach to kernel development were adopted. Keeping the kernel pure isn't a "petty-minded argument"; it's a critical element of good design.
All that said, you would have received a much different response had you suggested that Linux systems (as a whole) start integrating XML support , use XML for system configuration and provide XML services for applications. There's a good argument to be made for that, and the marketing value should be similar. There's also technological arguments to be made in favor of it. The distinction here is that this support would all be in "user space" rather than the kernel, even though it might be an integral part of the operation of the system as a whole. The kernel is the core of the system, and the idea of integrating XML into Linux does not imply that it belongs in the kernel.
Bell Labs has a press release from April 20 about this...
Making the stack non-executable can intefere with valid code (e.g. signal handlers, nested function calls and trampoline functions) while leaving other stack-smashing exploits open to exploit. The libsafe library comes with an example exploit that will give you a shell despite a non-executable stack. Using libsafe will protect you from this attack without harming valid code. Making the stack non-executable remains vulnerable to this attack while breaking otherwise-valid code; the Linux kernel folks were right to reject the non-executable-stack "fix" to the problem.
I downloaded the code and looked through their whitepaper and the source code a bit. Here's the basic technique:
- Install the libsafe library in
/lib/libsafe.so.1.3. (Red Hat Linux 6.2 users might want to get the RPM .) - Set the environment variable LD_PRELOAD to point to the libsafe library. (The RPM installs shell init scripts into
/etc/profile.d for Red Hat 6.2 shells to do this.) - Calls to "unsafe" C library routines (e.g. strcpy(3)) will be trapped by libsafe, which will figure out the size of the stack frame and reimplement the "unsafe" function safely (e.g. with memcpy(3)).
- If the program attempts to overflow the stack frame (presumably from a stack-smashing attack), a message is logged with syslog (into
/var/log/secure) and the process group is killed with the SIGKILL signal. - This interception is done at runtime, and works without source code or recompiling
- This technique can guard against stack-smashing exploits that haven't even been discovered yet. (And might even help discover them earlier!)
There are a few caveats here:- There is a performance impact, but the overhead appears to be relatively low.
- Since this technique relies on the dynamic linker (ld.so) to intercept the unsafe calls, statically-linked programs cannot be protected with this technique.
- If LD_PRELOAD is used, setuid programs will not be protected because ld.so (properly) doesn't trust the environment variables when running setuid, and thus ignores LD_PRELOAD.
- For system-wide protection, it is safer to use
/etc/ld.so.preload instead of LD_PRELOAD; it will apply to all (dynamically-linked) programs, including setuid programs, and cannot be accidently lost from the environment.
To the packager of the RPM: how about usingIf it goes offline again, perhaps this old address could reach someone:I found that address in the comments at http://wiretap.area.com/Gopher/Libr ary/Classic/, dated June 24, 1994 -- the P.O. box may or may not still be valid...
I am not a lawyer. But I found an archived Slashdot article that discusses these issues. In the main article, Bruce Perens notes that the issue is a little more complicated because the GPL combines copyright law with contract law. Later in the comments (look for comment #45), an actual intellectual property attorney weighed in on the matter. Worth a read.
If linking is creating a derivative work, don't link. Let the user do the linking.
This has been discussed in the past, and I believe the concensus was that the application would still be a derived work by virtue of being intended for use with that particular piece of code. (Same goes for libraries that are only available in GPL form.) On the other hand, this theory may not withstand a legal test...
I don't think function names are copyrightable at all. Otherwise projects like WINE would be in a big trouble.
This is a good point. If Microsoft can't stop us from imitating their APIs (and I'm sure they would if they could), why should we expect to be able to protect our APIs? I don't know what the answer to this is...
Would you like to see more free software kernels out there, which could be used as part of a GNU system, as the Linux kernel is currently used? Would you like new kernels to be able to compete on a level playing field based on quality, technology and other merits? Would you like to eliminate a major barrier to entry for alternative kernels, including the HURD?
Enough of the rhetorical questions; here's the real question: Would you reconsider supporting Project UDI, so that developers don't have to waste time duplicating effort supporting the same devices in one kernel after another?
Yes, I know you've already addressed this question, but I believe it bears revisiting. Here is a quote from your opening:Isn't this exactly the sort of cooperation that free software is intended to encourage? Can't we work towards the ideal you've described? Must we shackle ourselves to poor legacy practices merely because proprietary interests could benefit? The free software community has a lot to gain here in the long term, and it may help us more than the proprietary interests in the end...
At risk of making this posting way too long, let me briefly respond to some of your objections:
- "People could run free GPL-covered Linux drivers with Windows systems." If the GPL-covered drivers are dynamically loaded, this is probably true. However, the cat's out of the bag on this one; the proprietary company could always port the GPL driver to UDI themselves.
- "It would not directly hurt us, either; but the developers of GPL-covered free drivers could be discouraged to see them used in this way, and that would be very bad." Look at the flip side; developers of GPL-covered free drivers might be very encouraged to see their driver used on a wide variety of free kernels, knowing that their efforts have been leveraged to increase the greater good. (This could outweigh the downside of possible use by proprietary systems, couldn't it?)
- "People could run non-free Windows drivers on GNU/Linux systems." The cat's out of the bag on this one already also; since Linus has declared the API between the Linux kernel and device drivers to be public, and not covered by the GPL, it is already possible to distribute proprietary drivers for Linux. (One might try to argue that this is still improper under the GPL, but Linus would have to enforce it, and it appears that he won't.)
- "To the extent that the community began to accept the temptation, we would be moving to using non-free drivers instead of writing free ones." This is a user/developer education issue more than anything. It is important to help people understand the value of freedom for its own sake. Many people have trouble with that concept (witness the struggles of the Libertarian Party), since too many people are willing to sacrifice liberty for convenience. This is an ongoing battle, with or without UDI.
- "But why encourage the community to be weaker than it needs to be? Why make unnecessary difficulties for the future of free software? Since UDI does no good for us, it is better to reject UDI." Having a lack of stable APIs for device drivers makes us weaker. (Look at how often Linux drivers have needed to be recoded to adapt to kernel architectural changes.) Having incompatible drivers between different free operating systems (e.g. Linux, FreeBSD, NetBSD, HURD) creates unnecessary difficulties, keeping us much more factionalized, which makes us much weaker than Windows. If free operating system developers could cooperate and leverage their efforts, we have a lot to be gained here. What does Microsoft have to gain here? Not much; the hardware vendors will always write drivers for Windows without Microsoft lifting a finger, as long as Windows is the dominant platform. If we could level the playing field with UDI, Microsoft would lose a key strategic advantage they currently enjoy over free operating systems.
- "Given these consequences, it is no surprise that Intel, a supporter of UDI, has started to ``look to the Linux community for help with UDI.'' How does a richand self-seeking company approach a cooperating community? By asking for a handout, of course. They have nothing to lose by asking, and we might becaught off guard and say yes." I agree that Intel was less than tactful in asking (nay, expecting) Linux developers to assume the burden of UDI driver development. (Bear in mind, however, that UDI originated with SCO a number of years before Intel recently jumped on the bandwagon; it started as a standardization attempt for UNIX systems.) Indeed, Intel is hoping to freeload off our efforts. They should have offered some fair compensation for our efforts, such as writing their own UDI drivers for all old and new Intel hardware, and releasing those drivers as free software along with hardware specifications. A commitment like that would have been taken more seriously. Instead, they asked for a handout, and it backfired on them. Now we have many honorable members of the free software community hostile to the idea of UDI (irrespective of the technology) because of the (correct) perception that Intel (and others) would like to take advantage of our efforts in this area. At the same time, "don't cut off your nose to spite your face." Free software can benefit greatly from a common API (whether UDI or not), and refusing to use one because it might help "the enemy" still leaves us in the same mess we've been in for too long. Let's evaluate it on the benefits we can derive, not on the benefits we can deny to the opposition.
- "One way to make a deal a good one could be by modifying the UDI project itself. Eric Raymond has proposed that UDI compliance could require that the driver be free software. That would be ideal, but other alternatives could also work. Just requiring source for the driver to be published, and not a trade secret, could do the job--because even if that driver is not free, it would at least tell us what we need to know to write a free driver." Actually, a good start would be to convince them to honor their commitment to place the specification in the public domain as described in the following paragraph from the "Project UDI Policies and Procedures" page:
- "One difficulty with any deal with Intel about UDI is that we would do our part for Intel at the beginning, but Intel's payback would extend over a long time." Not necessarily; we could implement UDI environments for free operating systems and wait for them to start creating some UDI drivers before we put too much more effort into it. After all, they have a vested interested; they'll surely invest some effort into writing drivers if they can't get us to subsidize their bottom line with charity work. Free-software developers might still port some drivers in their own interest (e.g. a FreeBSD hacker porting a Linux driver to UDI, perhaps) but we wouldn't have to "loan" our efforts to Intel (et al) if we choose not to. Even if we don't, we might as well implement UDI environments to take advantage of the work of proprietary companies...
Basically, I believe that a common device-driver API represents the best opportunity for new free operating systems to flourish without having to compete with established free operating systems (much less Windows) on the basis of levels of device driver support. Whether UDI is the best API for this, I don't know. Perhaps UDI will be a dismal failure for performance reasons, as Alan Cox repeatedly insists will be the case. Perhaps a better API will come along. But we need something if we're to stop wasting time retracing our steps over and over again. Right now, UDI seems like the best prospect, and I believe we should embrace it for our own benefit rather than letting fear of possible misuse dissuade us from improving our software and methodology.This statement couldn't be any more clear, yet the UDI 1.0 specification as finally released has an entire page filled to the brim with copyright declarations. A good question for Project UDI is why they failed to follow through on this commitment. (The lawyers probably insisted...)
UDI drivers released by vendors would be valuable to us, even if some of those vendors fail to release their UDI drivers as free software. First, the source to a non-free driver might be published by the vendor, simply to increase market share -- UDI compatibility is only guaranteed at the source level. Even if the source is not released, the UDI driver is tightly constrained; it must funnel all interaction with outside code and actual devices through the UDI environment implementation -- this allows "black box" investigations that can easily see what effects the driver has, even if the source is not available. This should make UDI drivers easier to reverse-engineer than Windows drivers, especially if a special "test-rig" UDI environment implementation was created to facilitate such reverse-engineering.
Personally, I'd like to play around with writing a new kernel from scratch, even if nobody but me ever uses it. I may never finish (or even start) such a project, or it may never be useful compared to a mature kernel like Linux. Suppose (for the sake of argument) that I do finish it, and it's somehow superior to the design of the Linux kernel (as it sounds like HURD may be) -- would I really want to port all Linux drivers to this kernel and maintain them? Of course not. I'd much rather invest the time once in implementing a UDI environment, and support free-software UDI drivers, unchanged. That's what people mean when they talk about "working smarter, not harder"...
Here's a hyptothetical. What if the GPL'd code were compiled as a library to match an existing proprietary API. The library could be distributed freely under the GPL, and proprietary programs which would just happen to work with the GPL'd code also be written and distributed with impunity.
I am not a lawyer, but my understanding is that using an API which is specifically to access the GPL'd library makes the calling application a "derived work". If the application is coded to an existing API for non-GPL'd code, it cannot be said to be derived from the GPL'd code. Making a glue layer to translate the non-GPL API to the GPL'd library's API would be new code covered by the GPL. Linking the application with that library, despite the changed API, almost certainly requires the application to be distributed under the GPL.
If it's a shared library (DLL), the application can probably be closed, maybe even if the shared library is distributed with the application. If _only_ the GPL'd library is included, an argument might be made that the application is still a derived work; it might be necessary to include a proprietary shared library and leave it up to the user to replace it.
Check with a real lawyer if you're actually thinking of trying this.
On the ethical question of whether this is an okay thing to do, I'd say it's not. You may be able to find a legal way to do it (or maybe not), but legal != ethical. If you want to have the library used by a closed application, the best way is to convince the authors to relicense the code under the LGPL, which is explicitly designed for this purpose. Since they didn't use the LGPL, assume they don't want you using it with closed source. (On the other hand, if it didn't start as a library, maybe they didn't consider the possibility; they might be open to relicensing it...)
How will we know until we see it? If it sucks that badly, they'll probably either revise the UDI spec to make it perform well (which would eliminate the main argument against it), or punt and implement a traditional interface (which would be a tacit admission of failure). I don't know what will happen, but I wish them luck.
In the Linux world, the binary KPI is not considered relevant. The ABI has remained compatible from 1.2 (when ELF appeared) to the present day and is unlikely to change in the foreseeable future. The source KPI remains consistent within a stable series. Since the source is open and the source KPI is consistent, who cares about the binary KPI?
This is a serious problem. Do you remember what a nightmare it was to manually upgrade a.out systems to ELF? Even with all the source readily available, recompiling all that code is very painful. The more code, the more painful it is. Now that it's been stable under ELF from one kernel version to the next, hasn't life been easier? Application developers don't have to worry about capricious changes in the ABI for their ELF binaries; why aren't device driver developers accorded the same courtesy? This deliberate nonchalance about stable interfaces isn't "studly hacking"; it's amateurish and it shows.
There's over a million lines of device driver code in the Linux kernel. That's a lot of code to review and modify when changes are made. Device driver development could be less painful if a solid API/ABI (or KPI/KBI if you prefer) could be trusted not to change often. UDI aims for that kind of interface stability. It also aims for high performance. I don't know if it will meet these goals, but I'd rather give it a chance instead of running it out of town on a rail.
Imagine the uproar it would cause if the kernel hackers suddenly decided that they didn't care if ELF changed with every kernel revision and couldn't be bothered to keep backward compatibiltiy with old ABI's, and refused to accept such efforts contributed by others. After all, who care, if you have source code and the API hasn't changed? Oh, you don't have source to Oracle? Too bad, proprietary code sucks -- that'll teach 'em not to release their source!
This attitude is childish, and impedes the progress of the entire Linux community. Clean, solid abstractions are the basis of complex code. Do you really think you'd have such fancy browsers and word processors if they had to twiddle the bits on the screen at the application level instead of using GUI toolkits? I doubt it.
We need more stable interfaces, to make way for the Next Big Thing, whatever that may be. Right now it's hard to see the forest for the trees.
Consistent interfaces are the lifeblood of continued interoperability, whether you're talking about GUI fluff or kernel grunge. If lots of people call a function or use a data structure, great care should be taken to preserve that item's behavior or change it only for very good reasons.
Thank you!
Finally, someone who understands the real issues here and why the ad hoc methodology used until now is so limiting...
If you have any platform other than i386 then 99% of the time closed-source is exactly the same as nothing.
That's usually true right now. A big part of the reason is the cost required to port to other platforms and support them. On the other hand, if no actual porting is involved (just a recompile), even proprietary companies might be more willing to release binaries for multiple platforms, since it would expand their market for a smaller cost...
It's the dichotomy of the Linux community, isn't it? On the one hand, you have people wanting to replace Windows everywhere with Linux everywhere. On the other hand, people are lamenting about how the lower quality of the average Linux user as more newbies show up.
We can't have it both ways, folks. The average computer user never gets far past "clueless newbie" in their skills. Now that Linux is becoming more of a mainstream OS, we're stuck with more average users. It's a trade-off that's tough to evade. If you don't like it, switch to an OS like HURD that is more hostile to average user. (Of course, if you could move UDI drivers from Linux to HURD, that would be a lot easier...)
Many corporates just can't see things that way.
Quite true. However, some companies are starting to see the light. Matrox, for example, is paying for an accelerated Linux driver to be written for the G400, to be released as Open Source. The result? They get a competitive advantage. (I just bought a G400, actually, for this reason.) Even if most companies don't get it, you only need a few enlightened ones...
Nice, really. But legally speaking, you won't be allowed to distribute these drivers. If you don't believe me, here's a quizz:The correct answers are "Yes", "Yes" and "Yes". We'll have the same problem with UDI, which will be to the driver what Qt is to KDE.
(This response is based on my understanding of copyright law, but I am not a lawyer; standard disclaimers apply. Could a real lawyer please check this and comment?)
This is an oversimplification. Copyright law only allows the GPL to exert influence over "derived works", which is why "mere aggregation" on a distribution media does not bring other code under the scope of the GPL. (This is explicitly acknowledged in the GPL, in fact.) Since KDE is a derived work of its own GPL code and the proprietary Qt code, the GPL should apply to the whole. (Hard to enforce when the KDE developers don't seem to care...)
UDI, on the other hand, is a specification which is not under the GPL. If Microsoft were to implement a UDI environment (an idea they're probably more to than Alan Cox is), that UDI environment code would be a derived work of the UDI specification, and could remain proprietary. Meanwhile, if a GPL'd Linux kernel driver were ported to make a UDI driver (perhaps by Microsoft), that UDI driver would be covered by the GPL, since it would be a derived work of the original GPL code. It would also be a derived work of the UDI specification, which wouldn't interfere with using the GPL.
So, this hypothetical scenario has a proprietary UDI environment, and a GPL-licensed UDI driver. Each is kosher on its own. The key question is, what happens when you combine them? As I understand it, if the proprietary OS loads the UDI driver dynamically, the GPL couldn't apply, because there would be no derived work for it to apply to. (This is akin to loading a GPL'd user program with a proprietary OS.) A direct quote from the GPL:Here is the "mere aggregation" quote from the GPL:Even from the words of the GPL itself, it seems clear that a proprietary OS with UDI (which is clearly identifiable as a separate work; it could also use proprietary UDI drivers) and the GPL'd UDI driver could even be on the same distribution medium without violating the GPL. Static linking, on the other hand, probably does bring the whole under the GPL. All the proprietary vendor needs to do is keep it dynamic loading, and I think they're in the clear.
Is there anything non "100% pure GNU" that Stallman don't consider as an international conspiracy of proprietarist to eradicate free software?
Probably not!
It's a quick and easy way to add the increasingly important Linux checkbox to their marketing gloss without giving up any of their docs or paying someone to write a driver.
Since UDI exists, you can't prevent this kind of game. They can still write a UDI driver, say "we support Linux!" and add "by the way, you need this patch to use our UDI driver" in the fine print. The glossies can still have that little checkbox, regardless of how hostile Linux kernel hackers may be to UDI. The solution to this problem is user education, not rejecting UDI environment code for a perceived (but illusory) idealogical benefit.
But maybe we're just splitting hairs anyway. The simple facts are that, politics and licensing aside, UDI will not be a part of mainline Linux anytime soon, if ever, and that this decision has been made for technical reasons, rightly or wrongly. We can argue the nontechnical side of things, but the people who matter don't care in the slightest.
Let's get real here. The decision was not technical -- plenty of low-quality drivers are allowed into even stable-series releases, even with little technical merit. As long as it's marked "EXPERIMENTAL", Linus will allow almost any extra drivers to be included. UDI environment code could be marked "EXPERIMENTAL", and it wouldn't impact those who don't enable the option. This wouldn't hurt anyone, and should be done. However, the kernel developers don't like the idea of supporting UDI, so they find technical excuses for why it "cannot" work to avoid including it.
I thought the Open Source way was to give the code a chance and let it succeed or fail on its own merits?
I'll give you another example. Years ago, Oracle said they were reluctant to consider porting their database (in part) because Linux had no support for raw disk devices. Linus (for whatever reason) hated the idea of raw I/O and insisted that all disk I/O must be buffered. His response to this genuine need was to the effect of "screw that, I don't think we need it, and Linux will never support raw I/O to disk devices." (Not an actual quote.) He insisted that he would reject patches for raw disk I/O even if someone else did all the work. It was because he didn't like it.
So, what happened with raw disk I/O in the end? It's going to be in the Linux 2.4 kernel. This is a tacit admission that there is a real need for this feature. It was resisted for years only because Linus preferred his way. (Of course, now devfs is being used as a technical excuse for this delay, because it "would have required too many device numbers" -- that never stopped other UNIX vendors...)
UDI is a lot like raw disk I/O -- it's against the preferences of the Linux kernel developers, and they don't feel it's needed. Nevertheless, there is a real need for this stuff, and it will probably happen eventually in some fashion; refusing to allow it just causes unnecessary strife. It's clear that when it comes to UDI, Alan Cox doesn't like it. Must we go through the same struggle as with raw disk I/O?
As you admit, it's already a problem where proprietary vendors are releasing binary-only Linux drivers and refusing to release source or specs. New Linux users can be just as lulled by these (potentially) low-quality binary-only native Linux drivers. This is a user training issue and a community issue. The problem isn't going to go away on its own.
It all seems like a wash to me. How does UDI actually make this problem worse than it is anyway?
That's true for early adopters. When I ordered my computer at the end of 1992, I made sure to select hardware (e.g. Adaptec 1542CF) that was supported by Linux and NetBSD, since I wasn't sure yet which I would run. (I quickly decided I liked Linux better.) Selecting the best hardware for Linux is obviously ideal, but not everyone has that luxury, or necessarily even knowledge of which hardware is best.
For those who are using existing hardware, I don't think UDI would offer any benefit. It is unlikely that hardware manufactures are going to provide support for old hardware via UDI, because there's little economic benefit -- they've already sold their product, support or no support, so there's no reason put extra effort forth (unless you want to keep your good name, but that seems to mean little to most hardware manufactures).
I'll tend to agree with you here -- vendors probably won't rewrite drivers for old hardware. On the other hand, old hardware is more likely to have Open Source drivers available. New hardware tends to be more troublesome; if new hardware started becoming available with UDI drivers, that hardware could be used immediately. If open source drivers were later written (or maybe higher-performance Linux-native drivers?), you could switch later.
Of course, there's always the "don't use that hardware" argument, but that attitude doesn't mesh well with the quest for World Domination (tm). Face it, your typical Joe Sixpack doesn't give a rat's ass when he buys his computer whether the hardware has Linux drivers -- but if you can make it run Linux anyway, and better than it runs Windows, then you may have a potential convert on your hands...
Hardware support for Linux is pretty good right now. While not everything is supported, a little of everything is supported. If you want a nice graphics card, you can get one -- not any graphics card, but you don't need any graphics card, just a single one that works well.
Linux probably has the best device driver support of any free OS, and better than many proprietary OS's. It can't match Windows 98, but it might actually have better support than NT 3.51 or NT 4.0 did? Linux is reaching critical mass and starting to become a significant target market for vendors, although still less important than Windows.
Now that Linux is more mainstream and less of an "alternative" OS, what about the other alternative OS's? What about HURD, FreeBSD, NetBSD, and even BeOS? They may all be great OS's, but they lack the driver support of Linux (especially HURD and BeOS), which is a barrier to entry. Years ago, people used to complain about how they'd like to use Linux, but it had little driver support -- now you hear the same about HURD or BeOS. Won't we be better off if new OS's can compete on features and merit rather than sheer volume of available device drivers?
UDI would keep even many good companies from releasing their specs, because they wouldn't have to do so to provide support. It would hurt Linux and its bretheren.
We can't stop companies from being shortsighted. You can always boycott such companies; that's nothing new. Smart companies would release UDI driver source (both for the "with enough eyeballs, all bugs are shallow" effect, and to allow the driver to run on as many possible platforms without needing to directly support each binary configuration) and specifications (so that the community could do most of their support work for them, reducing their support costs). Dumb companies that keep their source and specs closed will suffer a competitive disadvantage, which should encourage them to change their ways. That's not the way things work. The ideal of providing the perfect abstraction is a nice, but unattainable, ideal. Innovation very often is a matter of changing the boundaries of abstraction. And Linux is great because there is that freedom to innovate. That freedom is one that is used a lot in the development of the kernel, and is part of what keeps the Linux kernel from getting too unwieldy.
At over 1.6 million lines of code, the Linux kernel is already somewhat unwieldy. (Nothing compared to Windows 2000, of course.) Over 1.1 million lines of that is drivers; decoupling driver development from kernel development would give both kernel developers and driver developers more freedom to innovate, because they wouldn't spend so much time tripping over each other!
While I agree that attaining a perfect abstraction is probably impossible, UDI looks to be a very, very good one. I'm amazed at how flexible it is, especially for an API designed by committee. It remains a matter of speculation whether or not it will be fast enough to be a system's primary API, but SCO and IBM must have some faith in it -- I'm told that UDI will be the only device driver API supported by Monterey, the "High Volume Enterprise UNIX Platform" (as their whitepaper describes it) being developed for Merced. I'll be interested to see if that succeeds; it sounds like a demanding environment.
There will be a UDI 1.1 or 2.0 or something. Even if the people behind UDI are quite intelligent and thoughtful, they aren't oracles, they can't see into the future, they can't predict what the demands on future APIs will be.
Of this, I am certain -- sooner or later, UDI will surely have to be revised, unless it dies completely. (The obvious reason why a revision might be necessary would be for performance reasons.) Project UDI has prepared for this; the UDI specs and the drivers themselves are versioned; if a UDI environment and UDI driver don't support the same API version, they will be able to tell. An OS supporting UDI 1.0 won't accidently try to run a UDI 1.1 driver and crash the system; it will simply refuse to run the driver at all.
In any case, hopefully such revisions would be rare occurrences. An OS could, of course, support several UDI versions simultaneously if necessary. Really, what are the odds that the UDI specification will change more often than the Linux kernel driver API already has?
Open Source drivers don't need to predict the future, because they can change. If other Unices want to get the hardware support that Linux has, they can GPL their kernels and make their kernel APIs compatible with Linux's, and then they are set. This isn't wholely unreasonable. And if they don't, well, tough luck for them.
Actually, the cat's out of the bag on this one. The very existence of the UDI spec presents an opportunity for proprietary OS vendors (even Microsoft) to support UDI in their system, then port Linux drivers to the UDI model. The ported driver would be GPL, but the UDI environment could remain entirely proprietary, and it would not violate the GPL since their code changes wouldn't be a "derived work" of the GPL code. It would be a derived work of the UDI spec, which isn't bound by the GPL. They can do this whether or not the Linux kernel developers support UDI.
On the other hand, this bugaboo isn't worth getting too alarmed about. Microsoft has little incentive to "steal" drivers this way -- they already have the most comprehensive driver support, courtesy of hordes of bootlicking vendors. Proprietary UNIX vendors have an incentive, but they still have a problem with the value proposition of proprietary systems -- increasingly, Linux is becoming recognized as a best-of-breed UNIX platform in more and more areas, and the proprietary UNIX vendors are bound to fall by the wayside sooner or later, with or without device driver parity with Linux. In short, this one is a red herring.
If Linux wants to get better hardware support, UDI offers almost nothing. Is someone going to make a UDI driver but not a Linux driver, because UDI has a 10% larger share? No. Are they going to make one for UDI because it's binary-only? Sure, but that's not what Linux needs.
Vendors can make binary-only Linux drivers now, and some are starting to. This is more problematic, because it makes it difficult to upgrade the Linux kernel.
As for why vendors might release UDI drivers instead of Linux ones, it's a question of leveraging their investments. If a vendor is targetting Unix-like systems, getting all versions with UDI would be better than investing in learning each individual native interface. Also, the UDI driver could actually be easier to write with a stable API that hides issues such as MP sychronization from the driver... I think it's highly unlikely the HURD people want anything to do with UDI. Don't support it for their benefit.
Given Stallman's hostility towards UDI (he seems to believe it is a plot for proprietary vendors to rip off free software developers), you may be correct in believing that the HURD people will have nothing to do with UDI. That doesn't mean they wouldn't be shortsighted for that. If they ever want "the GNU system" (with HURD) to replace "GNU/Linux", they'll need to address the driver issue, and UDI is a better solution than trying to race Linux in these driver parity wars...
Who says free software needs to compromise? UDI is a technology that has significant potential benefits for free software, independent of political considerations. Yes, UDI also offers significant benefits to commercial, proprietary developers, but that's incidental. Don't cut off your nose to spite your face; use the best technology instead of hobbling yourself for purely political reasons.
Again, where exactly is the compromise here? How would enabling UDI drivers enable disreputable proprietary behaviors that aren't already being practiced anyway?
As for whether developers want to work on drivers, I have no objection if that's how they want to spend their time. However, I'm concerned about people who insist that vendors shouldn't write a driver and should only release specs so we can write the driver. Even with specs, not all drivers get written, and little-used drivers might be just as poor quality as typical vendor fare. I believe that the vendor should be expected to release open source to a basic driver and specs.
If they only release specs and we write the code, we're subsidizing their efforts -- let them shoulder the burden of making their products work. Once they've gone that far, it's more reasonable for them to ask the community to fix bugs and enhance the driver. Again, why should they expect us to do their work for them?
"A driver version should not be tied to a kernel version in the first place."
Linus and everyone else on linux-kernel disagrees with you.
Are you suggesting that their opinions are beyond even debating then?
Currently, device driver modules must be tied to the Linux kernel because code written for one kernel version often won't work with another version. If the API and ABI are stable, then you only need to version those and not every kernel code change, large and small.
See my previous post for a long response to another poster. I'll only address new points below...
This, I believe, may be only a chimera; there are enough differences between the mechanisms that are used to protect driver and kernel data structures from interrupt service routines and peer-processor access in the various OSs that it may not even be possible to create a set of UDI drivers, much less port them across major kernel architecture change.
Most such policy decisions (uniprocessor vs. multiprocessor, singletasking vs. multitasking, privileged vs. userspace, synchronous vs. asychronous I/O, VM or not, protected memory or not, etc.) are entirely contained within the UDI environment implementation on the OS side, and unknown to the UDI driver itself. In fact, the UDI driver code can be simpler, because it doesn't deal with interrupt masks, task switching, synchronization, etc. (Since the environment has to deal with these issues, the environment implementation is probably harder, but it only has to be done once for all drivers on that OS.)
Since some devices MUST BE present in the kernel to access a boot device (and console), there is no way to prevent rebuilding drivers into a kernel. The current system of modular drivers already permits non-boot drivers to be excluded from the kernel image, and these modules can be distributed as separate packages. BTW, I just ran a line count on 2.2.5; there is a total of 1005095 lines of source code.
While it makes the most sense for UDI drivers to normally be loaded dynamically, there's no reason some bootstrap drivers couldn't be statically linked with the kernel. After booting, those drivers could continue to operate, or possibly be replaced with dynamically-loaded (possibly newer) versions.
In my Linux 2.2.12 tree (generic Red Hat 6.1, I think), "wc -l `find . -name '*.[ch]' -print`" gives me 1642672 lines. Most of this is device drivers: 1117142 lines, or 68% of the total. Surely the kernel would be more manageable if this mass of code wasn't so tightly coupled with kernel internals?
The performance will be that bad, so the existing sort-of APIs will be used and all that will have happened is a lot of unused work creating the code to implement and support the APIs.
I agree that the jury is still out, when it comes to UDI performance. They've made efforts to keep it high-performance, but it's unproven. Even if the performance is poor, there are good reasons to support UDI.
If the Linux, bsd, etc. communities had been the driving aganecy for UDI, there's a good chance that the result would be a benefit to both users and device manufacturers. Since the current initiative is by M$ and the vendors that want to dump their M$-Windows drivers on Linux, bsd, etc., then YES it would be a REALLY, REALLY bad thing to implement UDI in Linux.
Why aren't the Linux/BSD communities driving UDI? UDI can be good for everyone but Microsoft. Project UDI is not a Microsoft initiative; they're not even a participant! (They also have the most to lose, as the most entrenched OS vendor.) The history goes back years (1993, maybe?) to a multivendor effort to create common drivers for UNIX systems. Major participants include Sun, HP, SCO, Intel, Compaq, IBM and others. SCO and IBM are putting UDI support in AIX, Unixware and Monterey. (For Monterey, I'm told it will be the only API for device drivers.)
Project UDI has an (outdated) HTML presentation that has some overview information to help give you a broad sense of the architecture -- it's well worth reading.