Kernel configuration and compilation only needs to be a one-time event at distributor HQ. Users should not have to worry about such things. Imagine the impact on Windows use if it did:)
Indeed. Trouble is that the Linux kernel apparently doesn't admit that kind of "one-time event" to happen easily, since neither Debian nor RedHat seem to be able to figure out how to make a modular binary kernel distribution that works on most machines with all of the supported devices. Because if they did, I would just be using this, my friends would not be asking me to help them recompile their kernels, and we wouldn't be having this discussion.
Congratulations, you've proven that *gasp!* some modules are still immature.
The question is: why do they remain immature for so long? Why do I (realistically) need to wait for a kernel upgrade to get a fixed audio card driver? Why isn't driver development completely separate from the kernel?
Again, what is wrong with the build system?
If I change, say, an APM setting and follow the instructions ("make dep; make; make modules"), it ends up recompiling everything as far as I can tell. Furthermore, "make install" ends up recompiling some stuff yet again. And the recursive make itself has a lot of overhead.
"Every time you recompile the kernel, you need to recompile some kernel modules." If you're recompiling the kernel, taking the time to compile modules isn't that much of an inconvenience
The inconvenience isn't the time spent, the inconvenience is that vendors can't make a fully modular binary kernel distribution.
or wasting space with all the different "versions" of the kernel binaries (also icky, but not as).
You forgot the third option: making the kernel modular and distributing different "versions" as separate binary packages. That's the way the rest of Linux works. Allowing for packaging and individual distribution of packages is what has made Linux distributions practical and accessible to many people.
Adobe is a hawk when it comes to what they consider their intellectual property, and they are just throwing their weight around. They need to complain a lot so that politicians believe that there is a problem.
If Adobe were to pull out, some Asian competitor (or, gasp, free software) would fill their market niche, at a lower cost and probably higher quality. And those Asian competitors would have a much easier time delivering English-language versions than the other way around.
Adobe won't pull out. They are just saber rattling. Pulling out would be foolish. They'd rather give their software away than let some other company take over their market niche.
All name-brand Intel-based notebook makers buy some of their product line from cheap Asian sources. But almost all of them have their own designs as well. On many HP laptops, the design and the keyboard are distinctly HP, and several of them are really nice.
The drivers at least could have been modularized and are a vendor bug.
Oh, please. Do you think vendors purposely make their kernels hard to configure? If Debian and RedHat packagers can't figure out how to create binary kernel distributions that support all the hardware on most machines out of the box, then that is a problem with the kernel, not with the vendors.
(But there are lots of important configuration choices that cannot be modularized. And that, again, is a kernel architecture problem.)
I question the "lots" and the "important" but if that's the problem then that is what needs to be fixed.
Indeed, that's all I'm saying: it needs to get fixed. Otherwise, the future of Linux may be running GNU/Linux userland stuff under MacOSX or Darwin. I mean, it's easier to write and distribute kernel extensions for those systems than for Linux.
But if you believe that fixing it is just a matter of hacking around a little in a few source files, I think you are wrong.
Mostly Linus is just a fall guy. Not many people feel that MOSIX needs to be included into the standard kernel.
Not many people may feel that ReiserFS or a SupermaticFooBar driver or vid4lin or any other specific functionality needs to be in the kernel. Just like not many people may feel that "ptx" is a particularly important command line utility. But if you need it, you need it. For the command line stuff, there is no monolithic source tree and there are no gatekeepers. For the kernel, there are, and that really limits how the kernel can evolve. It's not a complete bar, it just makes adding kernel functionality sufficiently cumbersome that a lot doesn't get done.
All the talk about how it needs to be simple to compile the kernel is really just a work around for a poor default kernel. File a bug report with your vendor.
No, sorry, that's not it. Vendors generally modularize everything they can. But there are lots of important configuration choices that cannot be modularized. And that, again, is a kernel architecture problem.
[excessive recompilation after configuration changes] Hmm.. better docs could fix that, but another approach would be superior.
I don't think it's a question of documentation. There are two choices "don't check everything, just recompile the modules" and "recompile everything". If the make system can't figure it out automatically, people have to guess, and they will make mistakes. I follow the instructions ("make dep; make; make modules") precisely because I have guessed wrong in the past.
Note, incidentally, that "make install" starts recompiling parts of the kernel, and that definitely is a bug.
How about, "in order to make your sound card work", please go get in your car, drive over to a retailer, and get a CD with the new minor release of our operating system. Or download a service pack in excess of 30MB." I see folly in either direction. I do not see where you think the latter in some kind of panacea.
Driving to a dealer and getting a new CD, or downloading even a big service pack, doesn't involve answering trick questions posed by "menuconfig" or installing a software development system. My mother can drive to a dealer and get an OS upgrade CD; she can't recompile the Linux kernel.
I genuinely want to know of a superior alternative [to make], as each I have tried has proven to be less useful than make.
An alternative doesn't have to be "superior", in the sense of doing even more than "make" does. In fact, I think part of the problem is that "make" is so powerful that people create lots of messy dependencies that eventually make the whole system unmanageable. I think the best approach would be a custom build script (Perl or Python), together with a restructuring of the kernel tree or more explicit dependency annotations in source files. In fact, several open source Python and Perl-based make-clones could be a good starting point.
Perhaps you are confusing a refusal to load with just a message of mismatch -- when it loads across version boundaries, insmod reports the message but loads anyway.
Either it is guaranteed to work, in which case there shouldn't be a "warning", or it is something that only works sometimes, in which case I can't predict what's going to happen. And if I can't rely on it to work, I have to recompile if I want a reliable system.
I repeat -- C++ doesn't offer enough in the way of language to make it worth stepping farther away from the machine.
The issue isn't whether you or I like C++. The issue is that kernel development and the kernel architecture are organized in such a way that the core developers effectively decide what languages anybody else in the world develops in if they want to create a kernel module.
Most systems everywhere hinge on a high level person making the call. I don't know why you've ignored this fact.
Most monolithic systems hing on a high level person making the call. But look about what made the UNIX environment great: everybody could write scripts, programs, and tools in whatever language they wanted to. A UNIX distribution is a collection of weakly coupled programs. But Linux kernel development goes through a bottleneck. It doesn't matter how benevolent, intelligent, and well-meaning the people making the decisions are (and they are), there is still a bottleneck.
But as for the architectural complaint, please tell us what is better.
Well, first of all, I'm mainly prognosticating, not prescribing cures. As a practical matter, many people are having trouble with installing Linux because of its kernel, and that's a problem. Windows or OSX may not be any better designed, but, by whatever mechanisms, Microsoft and Apple have managed to distribute driver development among many developers. That's what Linux is competing with. That may not be fair, but it's a fact. Whether there are technical solutions to that problem that Linux can adopt is an open question.
Now, what concretely can be done? Before tackling the big things, maybe a few small things, and I have already mentioned some:
Fix the make and dependency system. A "make" in the top level should recompile only the necessary parts of the kernel, not everything. A "make install" should not recompile anything. How can you do that? If you want to stick with "make", get rid of nested make files and create a single, large set of dependencies at the top.
Decide whether loading mismatching modules is safe or not. If it is safe, don't have the kernel complain about it and stick to versioning that ensures that it is safe. If it is not safe, don't allow it. Don't leave users guessing.
Break up the kernel source tree into lots of separate tar files and distribute them individually. Is that more convenient? No. But what it does is force kernel development in the direction where new functionality can be distributed separately by others--being part of the one kernel tree would become much less of an issue.
Accomodate other languages if it isn't too much hassle. You may not like C++ in the kernel, but there is no reason not to fix the header files so that people can write their own C++ modules and distribute them outside the kernel tree. Failure to accept the necessary patches (supplied by IBM and others) is pure politics.
In the long run, I think it would be worth to think about making Linux a bit more micro-kernelish. Unlike a true microkernel, Linux wouldn't be a microkernel from the ground up, it would be a monolithic kernel with optional Mach-like servers.
On machines with really exotic hardware, I have had to recompile a great many kernel configurations. Usually, however, I can just rmmod & insmod to test the new configurations without rebooting, so the experimenting phase is not overlong.
Every single machine I have (a few dekstops and a few laptops) has required recompilation, even with recent kernel installs. Why? APM configuration requires different settings (if they are wrong, the machine crashes or hangs), drivers are missing from the default kernel, etc.
You are in no way forced to compile anything as a module -- the kernel will live quite happily as a solitary elf executable. So don't tell me 'every time'.
You are missing the point, which is that if you have modules, many of them need to be recompiled.
I've been pulling kernel sources off a 33k modem link for the last 6 months, and I'm not hurting for the speed.
Well, wonderful for you. But imagine where Windows or OSX were if the premise was "in order to make your sound card work, please download these 30Mbytes of stuff, a complete development environment, and recompile everything". Don't you even begin to see the folly of that suggestion?
I agree with you that make sucks. Unfortunately, it still sucks less than almost everything on the field. Please suggest an alternative.
Well, for starters, you could get rid of hierarchical make files, which simply don't work right. There are several alternatives to "make", any of which could be distributed with the kernel.
OTOH, C++ sucks even harder, and for its extra demands of space and time and its ability to obfuscate,
And you accuse me of trolling? C++ imposes no unexpected overhead in space or time. If you don't use a feature, it doesn't cost you (at least in a good C++ implementation).
You can do that. Say yes to 'attach version information to modules' in the kernel config.
I do, and it doesn't work. The kernel keeps complaining about version mismatches when tryikng to load those modules.
I agree with you, but that's pretty far off. The MIT exokernel is I think the shining example of what you are looking for.
No, it's not "far off". Microkernels have been around for years. But what Linux could do is, rather than imposing a microkernel architecture throughout, allow the loading of some modules into a protected space.
There *is* no reason to recompile the whole kernel to add a module. What are you smoking?
I follow the instructions in the kernel: after changing configuration parameters in menuconfig, I type "make dep; make; make modules". That recompiles the whole kernel. How am I supposed to know in what cases it is safe to type just "make modules"?
You see, that's what we call not in the linus kernel. Your impressions of importance and maturity of the patch are really something you should take up with Linus himself.
If so many bits and pieces of functionality need to be approved by one person, that really is an architecture problem. Imagine where the whole Linux system were if any command line program needed to be approved by the shell maintainer and then merged into a single, huge source tree.
It's easy to throw around accusations of trolling, but I think you are just out of touch with reality. I think the majority of Linux users either recompile the kernel, or they put up with significant chunks of missing functionality (no audio, no APM, etc.) on their installations. Rebuilding the kernel is an arcane and time consuming process out of the reach of even many technically savvy users. And new functionality takes forever to make it into the kernel.
If you do something long enough, you don't see the problems with it anymore. Try to take a fresh look at how cumbersome the kernel actually is, even if it works like a charm once you get it installed. And keep those accusations of "trolling" down--listen for a change and try to understand what people are saying.
C++ is a big shotgun--it's very effective if you point it forward, but it's very easy to shoot yourself in the foot if you point it generally downward. I think in the short run, it's the only feasible choice because it really interfaces very easily with C.
If the kernel weren't so monolithic and was composed from lots of different bits and pieces compiled separately, I think this would happen naturally.
CPRT is an organization dedicated to promoting these kinds of transportation systems, and Taxi2000 is one commercial system being developed. The washington.edu evaluate many different systems.
Note that it is essential for these kinds of systems that cabs are small--if they hold many people, they either need to stop a lot (=longer travel times), or they waste a lot of space and resources.
Let me first say that, despite the problems I mention below, I really appreciate the work that has been going into the Linux kernel. Once you get it configured and compiled, it's a reliable and powerful system. But if the kernel is too hard to configure and compile, that severely limits how widely Linux can get adopted.
Now, what problems am I talking about? The latest 2.4 kernels still have compilation problems in some drivers (2.4.17 has problems in USB, 2.4.18pre4 has problems in one of the sound drivers). Important and mature packages like MOSIX require patching the kernel and aren't integrated into the kernel. Many hardware setups require recompiling the kernel and experimenting endlessly. Every time you recompile the kernel, you need to recompile some kernel modules. Dependencies and recompilation aren't working correctly--some things don't recompile when they should, and lots of things recompile over and over and over again.
The kernel itself is a 30Mbyte download. And the list of problems goes on and on.
People seem to have gotten used to it and think there is nothing wrong. The kernel hackers keep telling us that C and make are just great tools for building kernels. But as a user and sometime driver hacker, I think the kernel is falling apart under its own weight. This is not a system I can recommend to non-technical users--commercial distributions can't cover all the possible kernel configurations (even with fully modularized kernels), and recompilation is out of the question for many users. What is needed?
It must be possible to write drivers and other kernel modules that can be compiled separately from the kernel and work across many versions. Binary modules really should keep working across minor version number changes (2.2 to 2.4, for example).
As a consequence, it should be possible to package bits and pieces of the kernel separately. If I want the ACPI module, I should be able to install that with "apt-get install kernel-2.x-module-acpi". I should be able to download RPM packages from reiserfs.com and install them on (at least) any 2.4 kernel without recompiling anything.
It must be possible to write kernel modules with more safety in mind. There should also be some way to apply some memory protection to kernel modules when desired.
The build system needs to get fixed. There is no reason why adding or removing a module should result in a recompilation of the whole kernel. Maybe it's time to get rid of "make" altogether for the kernel.
The configuration system needs to get fixed. The kinds of questions it asks right now just cannot be answered by a normal user. In fact, there really shouldn't be much of any configuration: all the different options should be dynamically loadable. Yes, this even means MMX-optimized versions of some piece of code or other. And most of the drivers and file systems should be distributed in completely separate source packages, independent of the kernel. (The new configuration system treats the symptom but not the root case.)
I think, ultimately, if the kernel wants to survive and be able to keep up with the world, it needs some kind of more flexible dynamic binding of functions at runtime. It also must allow people to start writing kernel components in languages other than C, foremost C++. No, C++ isn't the epitome of good language design, and, yes, people can write even more horrible code in C++ than in C, but C++ can really help with safety, security, resource management, and modularity.
If those things don't happen, I think the Linux kernel will simply fall so far behind that it will get replaced by something else. And that would be a shame because the Linux kernel actually does have a lot of useful functionality, and once compiled and configured, works very well.
People don't have a problem with the fact that these contracts are "standard", they have a problem with the conditions they contain.
It is also an economic fallacy to suggest that reducing legal costs for the seller is necessarily advantageous to the buyer. If the reduced legal costs and resulting lower product costs are more than offset by higher risk to the buyers, it's a bad deal. Think of it as reverse insurance. Since sellers are rational and can bank on buyers not understanding this point, they are going to make sure not to lower their prices enough to compensate for the increased risk to buyers.
Finally, your "free market" argument is bogus as well. IDEs aren't like apples--you can't substitute one for the other easily. There is a high cost associated with switching to a different development environment even if the other environment were fully functionally equivalent. But, in many cases, there are actually no functional equivalents. You can't substitute anything for Visual C++, for example; obviously, there is no other IDE that is as up-to-date with recent Microsoft "enhancements" as the one they produce. And, to a lesser degree, the same applies to Kylix/JBuilder.
Whether copying or sharing is faster really depends a lot on the program and the hardware. "Everything is pointers" can be just as devastating to performance as "nothing is pointers". That's probably why C/C++ are so popular, since they give the programmer control over this important aspect of computation. Languages like Lisp don't, and their optimizers cannot infer the necessary optimizations automatically.
No, that's not right. Good malloc/free allocators use buckets, hash tables, and trees, and no linear search is involved. It's slower than most people think, but it's pretty fast--about comparable to GC in my experience (there are some cases where GC is faster and some where it is slower).
Your idea of speech recognition is about 10 years out of date. Language models these days are huge and take into account syntax and semantics (not just vocabulary). Systems adapt to individual speakers, whose pronunciation differs systematically, and their language models adjust dynamically to the conversation. You update these systems not by hacking around with the code, but by adding new models and rules.
The airline trip planning problem sounds very similar to constrained graph search problems in speech recognition (which are now routinely carried out in real time on graphs with millions of nodes). It would be interesting to see a more detailed statement of what the problem actually is.
I think it's pretty much a toss-up whether using Lisp in this kind of system helps. While using Lisp makes initial development and testing much nicer, once you start mixing Lisp and C, debugging gets much harder and you may get very subtle and time consuming bugs in the Lisp/C interface. Note also that Carl also says that, for performance reasons, they have really limited the Lisp features they use.
Most people who have tried developing these kinds of systems seem to move away from them over time and end up developing a single-language solution--it's simpler to maintain and debug in the long run.
The C/C++ memory allocator is about as slow as a good Lisp or Java garbage collector. If you write performance critical code, the first thing to do is to look at your memory allocation and usage patterns--in any language.
Come on, do a little bit of research before making such claims. The NetVista starts at $1549. That's not all that different from the iMac (which, right now, starts at $1800 with a slower processor and less business-oriented support but better peripherals).
While you may argue that there is a lot of good stuff and quality in an iMac or iBook, the fact is that Apple's machines still cost a premium compared to a PC that appears functionally equivalent to most users. That doesn't mean that Apple has it wrong and Compaq/Microsoft have it right, it means that they have different products for different market segments.
And even though Gates may be terribly embarrassed and keep trying to improve the upscale appeal of Windows, it's a losing proposition. Microsoft is the KMart of software. Compaq/Microsoft will not take over Apple's market segment, but neither will Apple take over Compaq/Microsoft's market segment.
The real problem with the PC market is simply that there isn't more choice on the OS side: Windows, MacOS, BeOS, and Linux do not even scratch the surface of the space of possible and useful user experiences and interface styles. There should be 20 companies making entirely different systems, each with 5% market share (and all interoperable, one would hope). But, on the PC side, at least we get a lot of hardware variety and form factors. In fact, while Apple's iMac is stylish, its form factor has been available for a while from several PC vendors, including IBM's NetVista X series (at roughly the same price).
If you send mail to someone perennially disorganized and they need some context for your response, you append the original message(s) (if you receive a lot of those, you can figure out yourself what it means). For a point-by-point reply, you edit in bits and pieces of their original message. And if neither of those cases applies, you don't need to quote. Now, was that so hard?
I believe the Japanese robotics professor built the original version 15 years ago, a model scaled down in size. A lot of research robots back then were tethered. Fitting equivalent hardware into a full size device 15 years later doesn't seem like a big technological advance.
Don't get me wrong: I'm sure Kamen made real technical contributions, and those are then protected by patents.
There may be other problems with SmoothWall but this doesn't look like one. Even if the files were completely readable, it shouldn't be a big deal. People aren't supposed to log into firewalls. If you buy a proprietary firewall, it likely stores all that stuff in plain text and "world readable" as well, if it even has a notion of file protection and users in its embedded OS.
The part I can't figure out is why anyone would bother with a Linux software firewall running on a PC if you can get good firewall appliances with web-based configuration for little more than $100.
If the basic design for a two-wheeled scooter with wheels side-by-side was patented by someone else prior to Kamen's patent, then Kamen doesn't "deserve" a patent on it. If Kamen came up with improvements on the basic design, he deserves a patent on those improvements. And if the improvements are essential to making the device useful, then his patent will be valuable. If his improvements are not useful or essential, his patent will be worthless.
And if you actually took an "Engineering Law Class" and you were taught that people deserve patent protection because they implement their controller software in "ASM" as opposed to C++, you should ask for your tuition back. But perhaps you just made that up.
Well, how nice for you. But the question is not whether MQSeries ultimately turns out to be the right tool for the job, but whether KingOfChat's managers made their decision based on sufficient information.
(Besides, not all websites are the same. I have built websites in PHP, but that doesn't mean that PHP is the right tool for all websites.)
What's wrong with the BookPC form factor? There are several manufacturers making them, and they usually have both a 3.5" and 5.25" bay and one or two PCI slots. If that's too big, get a laptop. With FireWire, Bluetooth, and USB they are about as expandable as you might want them to be. Or build a PC104 system. If you run Linux, a handheld can be an even tinier system.
Apple makes some nice hardware, but their range of designs and form factors is very limited in comparison to the PC world: a big box, an iMac, and two sizes of laptops (well, three if you count the two iBooks). You could always get something similar in the PC world (even when it comes to the iMac, the IBM Netvista X series is similar in form factor, though not style).
Slashdot Mirror
Indeed. Trouble is that the Linux kernel apparently doesn't admit that kind of "one-time event" to happen easily, since neither Debian nor RedHat seem to be able to figure out how to make a modular binary kernel distribution that works on most machines with all of the supported devices. Because if they did, I would just be using this, my friends would not be asking me to help them recompile their kernels, and we wouldn't be having this discussion.
Congratulations, you've proven that *gasp!* some modules are still immature.
The question is: why do they remain immature for so long? Why do I (realistically) need to wait for a kernel upgrade to get a fixed audio card driver? Why isn't driver development completely separate from the kernel?
Again, what is wrong with the build system?
If I change, say, an APM setting and follow the instructions ("make dep; make; make modules"), it ends up recompiling everything as far as I can tell. Furthermore, "make install" ends up recompiling some stuff yet again. And the recursive make itself has a lot of overhead.
"Every time you recompile the kernel, you need to recompile some kernel modules." If you're recompiling the kernel, taking the time to compile modules isn't that much of an inconvenience
The inconvenience isn't the time spent, the inconvenience is that vendors can't make a fully modular binary kernel distribution.
or wasting space with all the different "versions" of the kernel binaries (also icky, but not as).
You forgot the third option: making the kernel modular and distributing different "versions" as separate binary packages. That's the way the rest of Linux works. Allowing for packaging and individual distribution of packages is what has made Linux distributions practical and accessible to many people.
If Adobe were to pull out, some Asian competitor (or, gasp, free software) would fill their market niche, at a lower cost and probably higher quality. And those Asian competitors would have a much easier time delivering English-language versions than the other way around.
Adobe won't pull out. They are just saber rattling. Pulling out would be foolish. They'd rather give their software away than let some other company take over their market niche.
All name-brand Intel-based notebook makers buy some of their product line from cheap Asian sources. But almost all of them have their own designs as well. On many HP laptops, the design and the keyboard are distinctly HP, and several of them are really nice.
Oh, please. Do you think vendors purposely make their kernels hard to configure? If Debian and RedHat packagers can't figure out how to create binary kernel distributions that support all the hardware on most machines out of the box, then that is a problem with the kernel, not with the vendors.
(But there are lots of important configuration choices that cannot be modularized. And that, again, is a kernel architecture problem.)
I question the "lots" and the "important" but if that's the problem then that is what needs to be fixed.
Indeed, that's all I'm saying: it needs to get fixed. Otherwise, the future of Linux may be running GNU/Linux userland stuff under MacOSX or Darwin. I mean, it's easier to write and distribute kernel extensions for those systems than for Linux.
But if you believe that fixing it is just a matter of hacking around a little in a few source files, I think you are wrong.
Not many people may feel that ReiserFS or a SupermaticFooBar driver or vid4lin or any other specific functionality needs to be in the kernel. Just like not many people may feel that "ptx" is a particularly important command line utility. But if you need it, you need it. For the command line stuff, there is no monolithic source tree and there are no gatekeepers. For the kernel, there are, and that really limits how the kernel can evolve. It's not a complete bar, it just makes adding kernel functionality sufficiently cumbersome that a lot doesn't get done.
All the talk about how it needs to be simple to compile the kernel is really just a work around for a poor default kernel. File a bug report with your vendor.
No, sorry, that's not it. Vendors generally modularize everything they can. But there are lots of important configuration choices that cannot be modularized. And that, again, is a kernel architecture problem.
I don't think it's a question of documentation. There are two choices "don't check everything, just recompile the modules" and "recompile everything". If the make system can't figure it out automatically, people have to guess, and they will make mistakes. I follow the instructions ("make dep; make; make modules") precisely because I have guessed wrong in the past.
Note, incidentally, that "make install" starts recompiling parts of the kernel, and that definitely is a bug.
How about, "in order to make your sound card work", please go get in your car, drive over to a retailer, and get a CD with the new minor release of our operating system. Or download a service pack in excess of 30MB." I see folly in either direction. I do not see where you think the latter in some kind of panacea.
Driving to a dealer and getting a new CD, or downloading even a big service pack, doesn't involve answering trick questions posed by "menuconfig" or installing a software development system. My mother can drive to a dealer and get an OS upgrade CD; she can't recompile the Linux kernel.
I genuinely want to know of a superior alternative [to make], as each I have tried has proven to be less useful than make.
An alternative doesn't have to be "superior", in the sense of doing even more than "make" does. In fact, I think part of the problem is that "make" is so powerful that people create lots of messy dependencies that eventually make the whole system unmanageable. I think the best approach would be a custom build script (Perl or Python), together with a restructuring of the kernel tree or more explicit dependency annotations in source files. In fact, several open source Python and Perl-based make-clones could be a good starting point.
Perhaps you are confusing a refusal to load with just a message of mismatch -- when it loads across version boundaries, insmod reports the message but loads anyway.
Either it is guaranteed to work, in which case there shouldn't be a "warning", or it is something that only works sometimes, in which case I can't predict what's going to happen. And if I can't rely on it to work, I have to recompile if I want a reliable system.
I repeat -- C++ doesn't offer enough in the way of language to make it worth stepping farther away from the machine.
The issue isn't whether you or I like C++. The issue is that kernel development and the kernel architecture are organized in such a way that the core developers effectively decide what languages anybody else in the world develops in if they want to create a kernel module.
Most systems everywhere hinge on a high level person making the call. I don't know why you've ignored this fact.
Most monolithic systems hing on a high level person making the call. But look about what made the UNIX environment great: everybody could write scripts, programs, and tools in whatever language they wanted to. A UNIX distribution is a collection of weakly coupled programs. But Linux kernel development goes through a bottleneck. It doesn't matter how benevolent, intelligent, and well-meaning the people making the decisions are (and they are), there is still a bottleneck.
But as for the architectural complaint, please tell us what is better.
Well, first of all, I'm mainly prognosticating, not prescribing cures. As a practical matter, many people are having trouble with installing Linux because of its kernel, and that's a problem. Windows or OSX may not be any better designed, but, by whatever mechanisms, Microsoft and Apple have managed to distribute driver development among many developers. That's what Linux is competing with. That may not be fair, but it's a fact. Whether there are technical solutions to that problem that Linux can adopt is an open question.
Now, what concretely can be done? Before tackling the big things, maybe a few small things, and I have already mentioned some:
In the long run, I think it would be worth to think about making Linux a bit more micro-kernelish. Unlike a true microkernel, Linux wouldn't be a microkernel from the ground up, it would be a monolithic kernel with optional Mach-like servers.
Every single machine I have (a few dekstops and a few laptops) has required recompilation, even with recent kernel installs. Why? APM configuration requires different settings (if they are wrong, the machine crashes or hangs), drivers are missing from the default kernel, etc.
You are in no way forced to compile anything as a module -- the kernel will live quite happily as a solitary elf executable. So don't tell me 'every time'.
You are missing the point, which is that if you have modules, many of them need to be recompiled.
I've been pulling kernel sources off a 33k modem link for the last 6 months, and I'm not hurting for the speed.
Well, wonderful for you. But imagine where Windows or OSX were if the premise was "in order to make your sound card work, please download these 30Mbytes of stuff, a complete development environment, and recompile everything". Don't you even begin to see the folly of that suggestion?
I agree with you that make sucks. Unfortunately, it still sucks less than almost everything on the field. Please suggest an alternative.
Well, for starters, you could get rid of hierarchical make files, which simply don't work right. There are several alternatives to "make", any of which could be distributed with the kernel.
OTOH, C++ sucks even harder, and for its extra demands of space and time and its ability to obfuscate,
And you accuse me of trolling? C++ imposes no unexpected overhead in space or time. If you don't use a feature, it doesn't cost you (at least in a good C++ implementation).
You can do that. Say yes to 'attach version information to modules' in the kernel config.
I do, and it doesn't work. The kernel keeps complaining about version mismatches when tryikng to load those modules.
I agree with you, but that's pretty far off. The MIT exokernel is I think the shining example of what you are looking for.
No, it's not "far off". Microkernels have been around for years. But what Linux could do is, rather than imposing a microkernel architecture throughout, allow the loading of some modules into a protected space.
There *is* no reason to recompile the whole kernel to add a module. What are you smoking?
I follow the instructions in the kernel: after changing configuration parameters in menuconfig, I type "make dep; make; make modules". That recompiles the whole kernel. How am I supposed to know in what cases it is safe to type just "make modules"?
You see, that's what we call not in the linus kernel. Your impressions of importance and maturity of the patch are really something you should take up with Linus himself.
If so many bits and pieces of functionality need to be approved by one person, that really is an architecture problem. Imagine where the whole Linux system were if any command line program needed to be approved by the shell maintainer and then merged into a single, huge source tree.
It's easy to throw around accusations of trolling, but I think you are just out of touch with reality. I think the majority of Linux users either recompile the kernel, or they put up with significant chunks of missing functionality (no audio, no APM, etc.) on their installations. Rebuilding the kernel is an arcane and time consuming process out of the reach of even many technically savvy users. And new functionality takes forever to make it into the kernel.
If you do something long enough, you don't see the problems with it anymore. Try to take a fresh look at how cumbersome the kernel actually is, even if it works like a charm once you get it installed. And keep those accusations of "trolling" down--listen for a change and try to understand what people are saying.
If the kernel weren't so monolithic and was composed from lots of different bits and pieces compiled separately, I think this would happen naturally.
CPRT is an organization dedicated to promoting these kinds of transportation systems, and Taxi2000 is one commercial system being developed. The washington.edu evaluate many different systems.
Note that it is essential for these kinds of systems that cabs are small--if they hold many people, they either need to stop a lot (=longer travel times), or they waste a lot of space and resources.
Now, what problems am I talking about? The latest 2.4 kernels still have compilation problems in some drivers (2.4.17 has problems in USB, 2.4.18pre4 has problems in one of the sound drivers). Important and mature packages like MOSIX require patching the kernel and aren't integrated into the kernel. Many hardware setups require recompiling the kernel and experimenting endlessly. Every time you recompile the kernel, you need to recompile some kernel modules. Dependencies and recompilation aren't working correctly--some things don't recompile when they should, and lots of things recompile over and over and over again. The kernel itself is a 30Mbyte download. And the list of problems goes on and on.
People seem to have gotten used to it and think there is nothing wrong. The kernel hackers keep telling us that C and make are just great tools for building kernels. But as a user and sometime driver hacker, I think the kernel is falling apart under its own weight. This is not a system I can recommend to non-technical users--commercial distributions can't cover all the possible kernel configurations (even with fully modularized kernels), and recompilation is out of the question for many users. What is needed?
I think, ultimately, if the kernel wants to survive and be able to keep up with the world, it needs some kind of more flexible dynamic binding of functions at runtime. It also must allow people to start writing kernel components in languages other than C, foremost C++. No, C++ isn't the epitome of good language design, and, yes, people can write even more horrible code in C++ than in C, but C++ can really help with safety, security, resource management, and modularity.
If those things don't happen, I think the Linux kernel will simply fall so far behind that it will get replaced by something else. And that would be a shame because the Linux kernel actually does have a lot of useful functionality, and once compiled and configured, works very well.
It is also an economic fallacy to suggest that reducing legal costs for the seller is necessarily advantageous to the buyer. If the reduced legal costs and resulting lower product costs are more than offset by higher risk to the buyers, it's a bad deal. Think of it as reverse insurance. Since sellers are rational and can bank on buyers not understanding this point, they are going to make sure not to lower their prices enough to compensate for the increased risk to buyers.
Finally, your "free market" argument is bogus as well. IDEs aren't like apples--you can't substitute one for the other easily. There is a high cost associated with switching to a different development environment even if the other environment were fully functionally equivalent. But, in many cases, there are actually no functional equivalents. You can't substitute anything for Visual C++, for example; obviously, there is no other IDE that is as up-to-date with recent Microsoft "enhancements" as the one they produce. And, to a lesser degree, the same applies to Kylix/JBuilder.
Whether copying or sharing is faster really depends a lot on the program and the hardware. "Everything is pointers" can be just as devastating to performance as "nothing is pointers". That's probably why C/C++ are so popular, since they give the programmer control over this important aspect of computation. Languages like Lisp don't, and their optimizers cannot infer the necessary optimizations automatically.
No, that's not right. Good malloc/free allocators use buckets, hash tables, and trees, and no linear search is involved. It's slower than most people think, but it's pretty fast--about comparable to GC in my experience (there are some cases where GC is faster and some where it is slower).
Your idea of speech recognition is about 10 years out of date. Language models these days are huge and take into account syntax and semantics (not just vocabulary). Systems adapt to individual speakers, whose pronunciation differs systematically, and their language models adjust dynamically to the conversation. You update these systems not by hacking around with the code, but by adding new models and rules.
The airline trip planning problem sounds very similar to constrained graph search problems in speech recognition (which are now routinely carried out in real time on graphs with millions of nodes). It would be interesting to see a more detailed statement of what the problem actually is.
Most people who have tried developing these kinds of systems seem to move away from them over time and end up developing a single-language solution--it's simpler to maintain and debug in the long run.
The C/C++ memory allocator is about as slow as a good Lisp or Java garbage collector. If you write performance critical code, the first thing to do is to look at your memory allocation and usage patterns--in any language.
Come on, do a little bit of research before making such claims. The NetVista starts at $1549. That's not all that different from the iMac (which, right now, starts at $1800 with a slower processor and less business-oriented support but better peripherals).
And even though Gates may be terribly embarrassed and keep trying to improve the upscale appeal of Windows, it's a losing proposition. Microsoft is the KMart of software. Compaq/Microsoft will not take over Apple's market segment, but neither will Apple take over Compaq/Microsoft's market segment.
The real problem with the PC market is simply that there isn't more choice on the OS side: Windows, MacOS, BeOS, and Linux do not even scratch the surface of the space of possible and useful user experiences and interface styles. There should be 20 companies making entirely different systems, each with 5% market share (and all interoperable, one would hope). But, on the PC side, at least we get a lot of hardware variety and form factors. In fact, while Apple's iMac is stylish, its form factor has been available for a while from several PC vendors, including IBM's NetVista X series (at roughly the same price).
If you send mail to someone perennially disorganized and they need some context for your response, you append the original message(s) (if you receive a lot of those, you can figure out yourself what it means). For a point-by-point reply, you edit in bits and pieces of their original message. And if neither of those cases applies, you don't need to quote. Now, was that so hard?
Don't get me wrong: I'm sure Kamen made real technical contributions, and those are then protected by patents.
The part I can't figure out is why anyone would bother with a Linux software firewall running on a PC if you can get good firewall appliances with web-based configuration for little more than $100.
And if you actually took an "Engineering Law Class" and you were taught that people deserve patent protection because they implement their controller software in "ASM" as opposed to C++, you should ask for your tuition back. But perhaps you just made that up.
(Besides, not all websites are the same. I have built websites in PHP, but that doesn't mean that PHP is the right tool for all websites.)
Apple makes some nice hardware, but their range of designs and form factors is very limited in comparison to the PC world: a big box, an iMac, and two sizes of laptops (well, three if you count the two iBooks). You could always get something similar in the PC world (even when it comes to the iMac, the IBM Netvista X series is similar in form factor, though not style).