is it possible to scale linux down, put (insert the most user-friendly windowmanager here) in it, and keep all those server stuff (appache, bind etc.) out put it on one cd, make an easy installer with good hardware detection, make a framework that 3rd party software vendors can work on
The one requirement you forgot was "and get it noticed by the media so that people will even know it exists". There are scores of Linux distributions, and more than a few were created with exactly these goals (SEUL for one), but you'll never hear about them on CNET.
ah ya, and dont forget to write a script that makes the delete and backspace buttons work under every terminal-emulator.
Use Debian, they actually have a "delete/backspace policy" that covers this. Of course, all bets are off when you use said terminal to telnet to a non-Debian system - that's a problem you just can't solve without cooperation from vendors....
However, why are you writing "installer scripts" anyway? If you want to deliver on Linux, please use the Linux packaging system. If you deliver on Solaris, please use the Solaris packaging system. Etc.
The Linux packaging system? There are several, at least three of which (rpm, deb, tgz) are in common use.
It's a valid question, but there are a lot of packaging systems out there - the ones for AIX, HP-UX and IRIX don't resemble each other in the least. Besides, while I don't mind installing packages on AIX or IRIX, the HP-UX 'depot' format and supporting tools are so clumsy that I'd rather run a vendor install script, and worry about uninstalling "manually", any day of the week. (In practice, vendors like Dassault, PTC and MSC never use the native install format - they always supply a script. And that script always seems to assume POSIX shell features. It is also always poorly-written, but that's a different rant.)
Debian kernels are now compiled with initrd support.
Now compiled? They have had initrd support for as long as I can remember (1996? 1997?).
They use ash for their kernel boot scripts. I'm guessing this is because of it's [sic] size.
Boot scripts (what is a "kernel boot script"?) can be in either bash or sh, but if they declare #!/bin/sh they must not use any non-POSIX-isms. The installation floppies use ash, because of its size. Recently someone proposed using the built-in shell from Busybox, but that may not happen because of robustness / compatibility.
but some shells that say/bin/sh will only work on my system if they use bash. Ash fails due to some difference in how it handles parentheses or file names or something...
Are these scripts distributed with Debian? If so, file bugs - this sort of thing is Not Allowed. If they are third-party, same thing - file bugs, although a third-party script vendor may not care as much....
Do you think that the startup scripts for most distributions would break because, even though they say #!/bin/sh at the top, they REALLY mean #!/bin/bash?
Many would. However, note that POSIX requires/bin/sh to be a POSIX shell, whose specs are derived mostly from the Korn Shell - so ksh is a valid POSIX shell, as is Bash, modulo a few features. Plain-vanilla Bourne shell is not.
AIX has the same dilemma: to be POSIX-compliant they have/bin/sh -> ksh and/bin/bsh is the real Bourne. HP-UX 11 has/bin/sh distinct from ksh, but it too allows things like 'export FOO=BAR'. I don't know if a real Bourne shell exists on HP-UX.
For a POSIX shell without the bash overhead, use ash, which is distributed with many (most?) Linux distributions. ash is the NetBSD/bin/sh, and at least on Debian the installation gives you the/bin/sh symlink option as well. Let me tell you, ash is much faster than bash in the autoconf-generated-configure "benchmark".
Since many Debian people use ash for/bin/sh, packages regularly have bugs filed -- and fixed -- vis-a-vis #!/bin/sh vs. #!/bin/bash. I don't know how careful other distros are about this sort of thing. Note that even many Debian scripts would fail if you found a real Bourne shell for/bin/sh rather than a POSIX-compliant shell.
Come on... is there ANY reason that the mounting drives doesn't/shouldn't occur automatically under Linux? I can't think of one good reason that the end user wouldn't want it that way.
There do exist solutions that do exactly this - various volume management daemons spring to mind, as well as hacks involving autofs.
But there are a few basic problems, stemming from the cultural difference between the Windows Way and the Unix Way:
Unix locks the drive door when you mount removable media (if possible, of course - most floppy drives don't support it) because it doesn't want you to eject something that's still mounted, lest you cause filesystem corruption. (Not an issue for read-only media like CDROMs, but there nonetheless.) This issue is solveable - the hw driver should detect you pushing the eject button and notify userspace to attempt to unmount, then eject if successful. 3 hits within say 2 seconds should trigger 'force umount' mode, perhaps, which can cause processes to get their file descriptors unceremoniously closed - or, if they have mmapped pages from the fs (text or otherwise), page faults become segfaults.
where do you want to mount the drive? Windows just "picks a drive letter"; NT lets you customise this letter in WINDISK.EXE (but just "picks one" if you don't specify). Unix does not restrict you to drive letters but lets you mount something anywhere you please, and call the mount point anything you please. Workaround: a distribution could default to having names like/mnt/zip0/mnt/cd0/mnt/fd0/mnt/sfd0 (scsi floppy) or something like that.
Should the OS really mount something read/write without your permission? Perhaps you wanted it mounted read-only so as not to further damage an already-damaged filesystem. In such a situation you would have to override the default behavior, fighting the system to convince it you know better than it does. This struggle is something I take for granted in the Windows world, but I would hate to see it in Linux. Once again it's a cultural thing.
The 'stripped down PC' uses a shared memory architecture that you won't find on a modern PC.
Ever heard of the Intel i740 and i810 graphics chips? (i810 motherboards are only 2 or 3 years old - what I would call a "modern PC".)
The "shared memory architecture" sounds to me a lot like what Intel did. Nobody liked the i740 in particular because the CPU and GPU would vie for memory bandwidth and sometimes you'd see artifacts on your screen (aka frame buffer) when the CPU was hogging the bandwidth.
Perhaps MS/NV's version doesn't suffer from this problem. But in any case, the concept of sharing memory between CPU and graphics is not exactly new.
I'm curious to see the arguments of "Mr ESR the hacker, author of amazing software from kernel space to user land like fetchmail or the insane gif2png" on the real tech needs to use Python2 over something else on this issue.
Thankfully, I am not ESR, but the answer is roughly:
The design requires (well, "wants") a language good at string handling and dynamic data. That means Perl or Python, not counting more obscure candidates like Ruby or Visual Basic. [(:]
So why not Perl? ESR prefers Python. It's that simple. (And yes, he used to be a Perl hacker, so if he's a Python bigot, at least he's an informed Python bigot....)
CML2 may be as ready for Linux 2.5 as it can be, but that doesn't matter one bit if Linus doesn't want to take it.
Actually, word on the street is that Linus has already decided to take it. (He is reported to have said as much at the last Kernel Developers' Summit.)
I imagine there would be quite a few oposed to this, especially if Linux now needs to ship with Python as well.
Yes, there were (I was one of them), but again, Linus has said that the new tool requirement is Not An Issue.
One thing has to be said - if we're getting a new language / tool requirement, at least we're dropping TCL! Much as I dislike Python, I'd rather hack in that than in TCL any day of the week.
Would it perhaps be feasible to to compile the CML2 parser, and just ship that binary for those that don't want to install Python as well?
ESR proposed exactly this idea, when confronted with the objection to requiring Python. It seems Python has a mode where you can ship your code as byte-compiled data inside a Python bytecode interpreter as one big C program. The problem with that is, since Linux is distributed as patches, any time the config system were changed, someone (Linus) would have to regenerate the C program and include the binary-looking changes in his patch files, bloating them.
It's like those SCSI firmware file updates which sometimes take up 80% of a kernel patch, long lines of hex digits that don't mean a thing to anyone except the card vendor. Those are necessary, because usually the firmware is closed-source. CML2 doesn't have that excuse.
The CML project got started when kernel developers started complaining about how hard it was to maintain the current configuration tool.
No, actually the project was started when ESR figured the current configuration tool was too hard to maintain and enfeaturate. Basically, he was bored, had nothing better to do, and decided to produce a new language and tools to replace it. He claims that designing "domain-specific mini-languages" is a favorite hacking activity of his.
Early on, he sought input from the current maintainers, asked if he would be stepping on any toes, etc. Some of us were less than enthusiastic, but none of us were willing to claim that the current system was actually beautiful or easy to maintain. (It's not!) Some of us also griped about Python, but (a) Linus Has Spoken and the new tool requirement is officially Not An Issue, and (b) we are generally agreed that he who writes the code decides on the language. (And really, it's not theoretically limited to Python - someone tried to reimplement the tools in C. I'm not sure of the current state of that project.)
I think CML2 includes the ability to build and install the kernel and modules in one nice neat package
No, that would be Keith Owens's kbuild-2.5 work. Both are scheduled to be added to Linus's tree very early in the 2.5 cycle. (Linus already agreed to this, although who knows, he could change his mind..)
it must be a nightmare to configure a kernel from scratch.
Takes me about 2 or 3 minutes, and is a much pleasanter experience than most nightmares I've had.
Granted, if you haven't done it before, you probably have to read through a lot of help text and maybe make some semi-educated guesses about what all the options mean. CML2 does not help much in this regard -- the options do not magically get less confusing.
And really, if you are daunted by a few screenfuls of options to tick or untick, perhaps you should stick with a kernel compiled by someone else. (Plenty of distribution vendors are more than happy to do this for you, free or for a fee. Even Debian, the "hacker's Linux", provides binary kernel images every few version numbers.) I don't mean to be patronizing, but it's true -- building your own kernel is not something everyone can or should do himself. It is too easy to get a kernel that doesn't work properly because you didn't know a specific option was needed for your setup. No amount of automated handholding completely removes the need to know, at least somewhat, what you are doing.
Whe he could not use GUILE, which is designed for things like this, adding domain-specific functions.
Uh -- CML2 is not a programming language, per se, but a language for representing a dependency graph for configuration options.
I fail to see how either XML or Scheme would be at all useful there. You would still have to invent conventions for how to store the graph, so instead of a language invented out of the blue, you get a language in XML or S-exp syntax invented out of the blue.
If anything, you should be advocating Prolog, which (unlike Scheme or XML) is a rule-based language, somewhat similar in semantics to CML2 data files. What's that, you say? Not enough people know Prolog? You can't be expected to install a Prolog compiler just to build a kernel? My point exactly.
What we've essentially got here is yet another language that a user needs to learn in order to take advantage of something that's supposed to make the user's life easier.
Are you referring to "regular" users, or developers?
"Regular" users, who don't hack their own kernels, will never see the guts of CML2 - any more than they ever see the current Config.in files.
Developers, on the other hand, will certainly have to learn esr's new language, or at least be astute enough to be able to cut and paste existing code in to add support for their new drivers.
Windows may have it's sucky points, but it's pretty much always click-point-click-scroll-click to get something set up.
The analogy to CML2 in Windows would be creating the OEMSETUP.INF file for a new driver. I have never done this, but I assume it's a lot more than click-point-click-scroll-click.
what i never got, nor investigated, was why the config didn't use an autoconf, et al. TYPE of system.
You mean an autoconf system with about 800 '--with-*' options? Thanks but no thanks....
I suppose you could use Metaconfig (the config engine used by Perl), which is interactive so it doesn't require 800 command line options, but Metaconfig produces a user experience not unlike 'make config', so what's the point?
There are ways to reduce the number of answers the computer has to get from you at config time:
keep a profile of settings you have used before - this is trivial, with Menuconfig's facilities to load and save your config to an alternate file, or with 'make oldconfig'.
probe your current hardware - this is perhaps what you meant by "an autoconf type of system". Giacomo Catenazzi (sp?) has implemented such a system and it will probably go in as an option with CML2, but it is limited in at least two ways: First, do you want to build a module for (e.g.) your sound card, or build it in to your kernel? Second, it only works if you are configuring your build on the same machine your kernel is intended for. (Not a good assumption for me - I generally compile on my fastest machine.)
Compile with a "default" set of options, and possibly give the user one or more "profiles" to choose from. The ARM tree has something like this - various defaults based on your machine sub-type. It is also something you could implement on top of CML2, since one of ESR's design goals was to support progressive disclosure.
I read the article and I was immediately impressed at how much MORE readable CML1 was... Perhaps because I know enough shell scripting to follow it in my head.
This is both an advantage and a disadvantage to the current kernel config language (which I don't call CML1 for the same reason that I don't refer to SunOS4 as Solaris 1).
It uses shell syntax for historical reasons, and two of its three parsers are implemented in bash, but a Config.in file is not a shell script. That means: sure, you can read config files just fine, but try to edit them and you can easily start generating syntax errors by assuming you can use all shell constructs. (You can't, because xconfig does not borrow a shell for its parser.)
Hmmmm. What sort of bus architecture would it take to run down Linus and Alan both?
First, it has to be pretty long-range. A modified FC bus, I suppose, with the protocol altered to support transatlantic distances and repeaters. The mother of all differential SCSI, shall we say.
It would also have to have a fairly fat pipe - one can't imagine serious injury resulting from a collision at a mere 10mbit/sec, right? PCI 33/32 packs a decent punch, enough to knock you down, but I doubt it could kill you. The FC bus would have to hang off something faster like AGP4x or VME.
Then we have routing... you know there's no direct fibre line from Swansea to Santa Clara, so the bus protocol would have to support bridging of some sort at the least. I guess FC fits the bill here too.
Under RedHat 7.2 I plugged in a Fat32 formatted USB external hard drive and rebooted, but nothing happened.
You shouldn't have had to reboot - just load the usb-storage.o module and the drive partition(s) should show up in/proc/partitions. Then you just mount 'em or whatever....
If the bugs were hidden, Counterpane would have a lot harder time knowing what to look for.
My understanding is that Counterpane does not just audit your network and then look for attacks to "known holes". Instead, they put a bug on your network, watch the traffic go by, and take note when something unusual happens.
This has nothing to do with knowing specific vulnerabilities, and everything to do with recognising "normal" traffic patterns and learning to recognise signs of cracker activity. I doubt the level of vendor disclosure makes much difference for their monitoring service.
In fact, if anything, Schneier has a conflict of interest in that the less secure the Internet is, the easier it will be for him to sell his services. One might suspect him, therefore, of advocating counterproductive measures just to drum up long-term business. However, he doesn't. At least not that I've ever noticed, and I do read his newsletter every month.
The reason why pthreads 'look pretty good' speed-wise is because the pthread library provides user level threads as opposed to a kernel level threads.
Technically, "pthreads" ("POSIX threads") is just an API which can be provided by any thread library. And yes, technically, you can get a user-level threads package that implements pthreads.
But I think you were referring to Linuxthreads, the pthreads implementation used by GNU libc on Linux. Linuxthreads is kernel-level, not user-level.
Semaphores and mutexes may be implementation mostly in user space (I don't know for sure) but thread creation/destruction/scheduling is definitely based on real kernel threads.
well duh. Just look at the section of the man pages
Actually, as another poster said, many library functions use system calls, so you can't always say "section 3 is faster". In fact, a few functions in section 2 are not direct system calls but wrappers around system calls, for historical or other reasons.
(a context switch is involved)
Not to be pedantic (a lie, I am being pedantic) but a system call does not necessarily cause a context switch. On some OSes, perhaps, but on Linux, the kernel address space does not conflict with the user address space, so no page table reloading ("context switch") is required to enter/leave a syscall. The act of entering/leaving kernel mode is definitely a non-zero cost, but it's much cheaper than a context switch (and, incidentally, much cheaper than a syscall on many other Unix implementations).
Regarding pthreads performance...
Linuxthreads (the Linux glibc implementation of pthreads) is somewhat less efficient than it could be because the glibc developers are so anal about standards compliance. It's been awhile since I looked at the details, but there are a few subtle things about POSIX threads that are clumsy to implement precisely in Linux. I believe thread creation is one of them - it costs a few syscalls + thread switches more than it should because Linux lacks the necessary facilities to "do the right thing" naturally.
So at least for now, if you want the fastest possible threads, roll your own using clone() rather than Linuxthreads. (Or use user-mode or hybrid threads, which can be even faster.)
at least it should be more stable (i.e., much less chance of bankruptcy) than a lot of these poor companies going out of business.
The government itself may not go out of business, but what will stop them from deciding next year that its broadband services are losing too much money and should be either privatised, discontinued, price increased dramatically, etc?
It's not like those politicians will be saying "sure it loses money but this is way more important than elementary education, so let's subsidise it just a little longer until it starts breaking even". Most governments (well, local governments) have fairly tight purse strings.
Ummmm... ever heard of UltraDMA? As in UDMA33, UDMA66, etc, up to the present ATA-133? One of the selling points of UltraDMA was that it removes the old "only one command pending on the bus at any given time" limitation from previous IDE transfer modes.
So either I'm full of it, or your information / advocacy is out of date.
Why does IPSec with Linux seem like such a hack? FreeSwan is pretty annoying - why don't they just get IPSec into the kernel and go from there? Instead there appears to be a megapatch.
Because Linus lives in the US, and Linux is thus distributed from the US, and until relatively recently, it wasn't legal to put IPsec source on a public FTP server in the US.
Now it appears to be legal, assuming you follow particular procedures, and kernel.org does explicitly say that they are hosting crypto software now. I guess the kernel development process hasn't caught up to reality yet.
Slashdot Mirror
The one requirement you forgot was "and get it noticed by the media so that people will even know it exists". There are scores of Linux distributions, and more than a few were created with exactly these goals (SEUL for one), but you'll never hear about them on CNET.
Use Debian, they actually have a "delete/backspace policy" that covers this. Of course, all bets are off when you use said terminal to telnet to a non-Debian system - that's a problem you just can't solve without cooperation from vendors....
The Linux packaging system? There are several, at least three of which (rpm, deb, tgz) are in common use.
It's a valid question, but there are a lot of packaging systems out there - the ones for AIX, HP-UX and IRIX don't resemble each other in the least. Besides, while I don't mind installing packages on AIX or IRIX, the HP-UX 'depot' format and supporting tools are so clumsy that I'd rather run a vendor install script, and worry about uninstalling "manually", any day of the week. (In practice, vendors like Dassault, PTC and MSC never use the native install format - they always supply a script. And that script always seems to assume POSIX shell features. It is also always poorly-written, but that's a different rant.)
Now compiled? They have had initrd support for as long as I can remember (1996? 1997?).
Boot scripts (what is a "kernel boot script"?) can be in either bash or sh, but if they declare #!/bin/sh they must not use any non-POSIX-isms. The installation floppies use ash, because of its size. Recently someone proposed using the built-in shell from Busybox, but that may not happen because of robustness / compatibility.
Are these scripts distributed with Debian? If so, file bugs - this sort of thing is Not Allowed. If they are third-party, same thing - file bugs, although a third-party script vendor may not care as much....
Many would. However, note that POSIX requires /bin/sh to be a POSIX shell, whose specs are derived mostly from the Korn Shell - so ksh is a valid POSIX shell, as is Bash, modulo a few features. Plain-vanilla Bourne shell is not.
AIX has the same dilemma: to be POSIX-compliant they have /bin/sh -> ksh and /bin/bsh is the real Bourne. HP-UX 11 has /bin/sh distinct from ksh, but it too allows things like 'export FOO=BAR'. I don't know if a real Bourne shell exists on HP-UX.
For a POSIX shell without the bash overhead, use ash, which is distributed with many (most?) Linux distributions. ash is the NetBSD /bin/sh, and at least on Debian the installation gives you the /bin/sh symlink option as well. Let me tell you, ash is much faster than bash in the autoconf-generated-configure "benchmark".
Since many Debian people use ash for /bin/sh, packages regularly have bugs filed -- and fixed -- vis-a-vis #!/bin/sh vs. #!/bin/bash. I don't know how careful other distros are about this sort of thing. Note that even many Debian scripts would fail if you found a real Bourne shell for /bin/sh rather than a POSIX-compliant shell.
Another Rincewind fan! Mod parent up! (:
There do exist solutions that do exactly this - various volume management daemons spring to mind, as well as hacks involving autofs.
But there are a few basic problems, stemming from the cultural difference between the Windows Way and the Unix Way:
Ever heard of the Intel i740 and i810 graphics chips? (i810 motherboards are only 2 or 3 years old - what I would call a "modern PC".)
The "shared memory architecture" sounds to me a lot like what Intel did. Nobody liked the i740 in particular because the CPU and GPU would vie for memory bandwidth and sometimes you'd see artifacts on your screen (aka frame buffer) when the CPU was hogging the bandwidth.
Perhaps MS/NV's version doesn't suffer from this problem. But in any case, the concept of sharing memory between CPU and graphics is not exactly new.
Thankfully, I am not ESR, but the answer is roughly:
The design requires (well, "wants") a language good at string handling and dynamic data. That means Perl or Python, not counting more obscure candidates like Ruby or Visual Basic. [(:]
So why not Perl? ESR prefers Python. It's that simple. (And yes, he used to be a Perl hacker, so if he's a Python bigot, at least he's an informed Python bigot....)
Actually, word on the street is that Linus has already decided to take it. (He is reported to have said as much at the last Kernel Developers' Summit.)
Yes, there were (I was one of them), but again, Linus has said that the new tool requirement is Not An Issue.
One thing has to be said - if we're getting a new language / tool requirement, at least we're dropping TCL! Much as I dislike Python, I'd rather hack in that than in TCL any day of the week.
ESR proposed exactly this idea, when confronted with the objection to requiring Python. It seems Python has a mode where you can ship your code as byte-compiled data inside a Python bytecode interpreter as one big C program. The problem with that is, since Linux is distributed as patches, any time the config system were changed, someone (Linus) would have to regenerate the C program and include the binary-looking changes in his patch files, bloating them.
It's like those SCSI firmware file updates which sometimes take up 80% of a kernel patch, long lines of hex digits that don't mean a thing to anyone except the card vendor. Those are necessary, because usually the firmware is closed-source. CML2 doesn't have that excuse.
No, actually the project was started when ESR figured the current configuration tool was too hard to maintain and enfeaturate. Basically, he was bored, had nothing better to do, and decided to produce a new language and tools to replace it. He claims that designing "domain-specific mini-languages" is a favorite hacking activity of his.
Early on, he sought input from the current maintainers, asked if he would be stepping on any toes, etc. Some of us were less than enthusiastic, but none of us were willing to claim that the current system was actually beautiful or easy to maintain. (It's not!) Some of us also griped about Python, but (a) Linus Has Spoken and the new tool requirement is officially Not An Issue, and (b) we are generally agreed that he who writes the code decides on the language. (And really, it's not theoretically limited to Python - someone tried to reimplement the tools in C. I'm not sure of the current state of that project.)
No, that would be Keith Owens's kbuild-2.5 work. Both are scheduled to be added to Linus's tree very early in the 2.5 cycle. (Linus already agreed to this, although who knows, he could change his mind..)
Takes me about 2 or 3 minutes, and is a much pleasanter experience than most nightmares I've had.
Granted, if you haven't done it before, you probably have to read through a lot of help text and maybe make some semi-educated guesses about what all the options mean. CML2 does not help much in this regard -- the options do not magically get less confusing.
And really, if you are daunted by a few screenfuls of options to tick or untick, perhaps you should stick with a kernel compiled by someone else. (Plenty of distribution vendors are more than happy to do this for you, free or for a fee. Even Debian, the "hacker's Linux", provides binary kernel images every few version numbers.) I don't mean to be patronizing, but it's true -- building your own kernel is not something everyone can or should do himself. It is too easy to get a kernel that doesn't work properly because you didn't know a specific option was needed for your setup. No amount of automated handholding completely removes the need to know, at least somewhat, what you are doing.
Uh -- CML2 is not a programming language, per se, but a language for representing a dependency graph for configuration options.
I fail to see how either XML or Scheme would be at all useful there. You would still have to invent conventions for how to store the graph, so instead of a language invented out of the blue, you get a language in XML or S-exp syntax invented out of the blue.
If anything, you should be advocating Prolog, which (unlike Scheme or XML) is a rule-based language, somewhat similar in semantics to CML2 data files. What's that, you say? Not enough people know Prolog? You can't be expected to install a Prolog compiler just to build a kernel? My point exactly.
Are you referring to "regular" users, or developers?
"Regular" users, who don't hack their own kernels, will never see the guts of CML2 - any more than they ever see the current Config.in files.
Developers, on the other hand, will certainly have to learn esr's new language, or at least be astute enough to be able to cut and paste existing code in to add support for their new drivers.
The analogy to CML2 in Windows would be creating the OEMSETUP.INF file for a new driver. I have never done this, but I assume it's a lot more than click-point-click-scroll-click.
You mean an autoconf system with about 800 '--with-*' options? Thanks but no thanks....
I suppose you could use Metaconfig (the config engine used by Perl), which is interactive so it doesn't require 800 command line options, but Metaconfig produces a user experience not unlike 'make config', so what's the point?
There are ways to reduce the number of answers the computer has to get from you at config time:
This is both an advantage and a disadvantage to the current kernel config language (which I don't call CML1 for the same reason that I don't refer to SunOS4 as Solaris 1).
It uses shell syntax for historical reasons, and two of its three parsers are implemented in bash, but a Config.in file is not a shell script. That means: sure, you can read config files just fine, but try to edit them and you can easily start generating syntax errors by assuming you can use all shell constructs. (You can't, because xconfig does not borrow a shell for its parser.)
Hmmmm. What sort of bus architecture would it take to run down Linus and Alan both?
First, it has to be pretty long-range. A modified FC bus, I suppose, with the protocol altered to support transatlantic distances and repeaters. The mother of all differential SCSI, shall we say.
It would also have to have a fairly fat pipe - one can't imagine serious injury resulting from a collision at a mere 10mbit/sec, right? PCI 33/32 packs a decent punch, enough to knock you down, but I doubt it could kill you. The FC bus would have to hang off something faster like AGP4x or VME.
Then we have routing ... you know there's no direct fibre line from Swansea to Santa Clara, so the bus protocol would have to support bridging of some sort at the least. I guess FC fits the bill here too.
........oh, that kind of bus? Ummmm, never mind..
You shouldn't have had to reboot - just load the usb-storage.o module and the drive partition(s) should show up in /proc/partitions. Then you just mount 'em or whatever....
My understanding is that Counterpane does not just audit your network and then look for attacks to "known holes". Instead, they put a bug on your network, watch the traffic go by, and take note when something unusual happens.
This has nothing to do with knowing specific vulnerabilities, and everything to do with recognising "normal" traffic patterns and learning to recognise signs of cracker activity. I doubt the level of vendor disclosure makes much difference for their monitoring service.
In fact, if anything, Schneier has a conflict of interest in that the less secure the Internet is, the easier it will be for him to sell his services. One might suspect him, therefore, of advocating counterproductive measures just to drum up long-term business. However, he doesn't. At least not that I've ever noticed, and I do read his newsletter every month.
Technically, "pthreads" ("POSIX threads") is just an API which can be provided by any thread library. And yes, technically, you can get a user-level threads package that implements pthreads.
But I think you were referring to Linuxthreads, the pthreads implementation used by GNU libc on Linux. Linuxthreads is kernel-level, not user-level.
Semaphores and mutexes may be implementation mostly in user space (I don't know for sure) but thread creation/destruction/scheduling is definitely based on real kernel threads.
Actually, as another poster said, many library functions use system calls, so you can't always say "section 3 is faster". In fact, a few functions in section 2 are not direct system calls but wrappers around system calls, for historical or other reasons.
Not to be pedantic (a lie, I am being pedantic) but a system call does not necessarily cause a context switch. On some OSes, perhaps, but on Linux, the kernel address space does not conflict with the user address space, so no page table reloading ("context switch") is required to enter/leave a syscall. The act of entering/leaving kernel mode is definitely a non-zero cost, but it's much cheaper than a context switch (and, incidentally, much cheaper than a syscall on many other Unix implementations).
Regarding pthreads performance...
Linuxthreads (the Linux glibc implementation of pthreads) is somewhat less efficient than it could be because the glibc developers are so anal about standards compliance. It's been awhile since I looked at the details, but there are a few subtle things about POSIX threads that are clumsy to implement precisely in Linux. I believe thread creation is one of them - it costs a few syscalls + thread switches more than it should because Linux lacks the necessary facilities to "do the right thing" naturally.
So at least for now, if you want the fastest possible threads, roll your own using clone() rather than Linuxthreads. (Or use user-mode or hybrid threads, which can be even faster.)
The government itself may not go out of business, but what will stop them from deciding next year that its broadband services are losing too much money and should be either privatised, discontinued, price increased dramatically, etc?
It's not like those politicians will be saying "sure it loses money but this is way more important than elementary education, so let's subsidise it just a little longer until it starts breaking even". Most governments (well, local governments) have fairly tight purse strings.
Ummmm ... ever heard of UltraDMA? As in UDMA33, UDMA66, etc, up to the present ATA-133? One of the selling points of UltraDMA was that it removes the old "only one command pending on the bus at any given time" limitation from previous IDE transfer modes.
So either I'm full of it, or your information / advocacy is out of date.
Because Linus lives in the US, and Linux is thus distributed from the US, and until relatively recently, it wasn't legal to put IPsec source on a public FTP server in the US.
Now it appears to be legal, assuming you follow particular procedures, and kernel.org does explicitly say that they are hosting crypto software now. I guess the kernel development process hasn't caught up to reality yet.