In this case, the new system call was to avoid ugly hacks like FreeBSD's Copy On Write system (which is transparent, but even harder to use because of that and frequently unhelpful in adding performance).
Linus's take on the whole thing is that if you want portability, you should just use the read(), write(), etc system calls, since they perform pretty well anyway. If you absoloutely must do something platform-specific for every ounce of performance, you should have a clean API to do it with.
Why are the network drivers part of the kernel? It seems like this would make it more difficult to adopt newer hardware types. Also, since most computers have 1-2 NICs at the most, wouldn't that clog up the kernel with tons of drivers for hardware you'll never use?
This is the essence of the Microkernel debate.
It has nothing whatsoever to do with the microkernel debate. The two issues are completely orthogonal to each other. The microkernel proponents claim the driver should be a process running outside the kernel, which has nothing to do with the number of drivers you have sitting around, or how difficult it is to adopt newer hardware types.
Either way, you've got a ton of drivers sitting around that you'll never use. They don't clog up the kernel, since the kernel image rarely contains many drivers. Instead, most Linux distros use modules that get loaded as needed. On a microkernel, they would be driver binaries that would get run as needed. They clog things up to exactly the same extent; they sit around on the hard drive doing nothing.
Either way, it's hard to add new drivers to old kernels. This is not a result of the fact that drivers are in the kernel, but of the fact that Linus refuses to use a stable driver API. This would preclude driver compatibility between versions just as effectively on a microkernel as it does now.
If data can be recovered after fewer wipes, the people capable of recovering it certainly wouldn't advertise the fact. Extra passes are cheap, the costs of someone recovering data might not be.
Of course, the bad sectors that get transparently reallocated leave dead sectors that can probably be recovered and would not be wiped with stock firmware, so it's academic anyway. If you can't take that risk, you have to turn the media inside the drive into molten slag. There's no other way.
"why not store the entire filesystem on RAM with a battery, in a tmpfs. when you want to wipe it, put a thousand volts through it for a couple of seconds, then cut power?"
RAM has the same problem. If a bit has been set a particular way for a long time, it will have detectable effects afterwards. It's not enough for your computer to be able to suspend to RAM without power to maintain the memory, but a forensics lab would have better luck recovering the data.
Yup. Where they're good, they're great, and where they haven't bothered to give something attention they're crap. It doesn't keep it from being a good OS, or a pleasure to work with when you work with it, it just means it can't do everything and you have to be prepared to use something else when it's not well suited.
I went to a presentation by the OpenBSD developers during their Hack-a-thon, and they indicated that WPA was not a very high priority for them. They prefer to do authentication with auth-pf, and if encryption is needed they prefer to use VPNs. It does make it a PITA if you want to use a network you have no control over, but the OpenBSD crowd are like that sometimes.
It's not a weakness in Itanium, it's the strength of Athlons/Opterons and now Conroe/Merom/Woodcrest. Intel wanted Pentium 4s to be good media processors (and they are), but they didn't want to compete against their own Itaniums, and that's what allowed AMD to steal their lunch. They have no choice but to respond with their own strong x86 processor.
It's not the weakness of Itanium that's the problem, it's apparently their ability to make any architechture fast and not just the one they want.
Skepticism is a healthy thing. The early indications are of a fast chip, but don't make any purchasing decisions unless you see reviews of a shipping product.
They get fixed in microcode, or they're published in the errata of the chip so OS developers can work around them. Bugs that end up visible to userspace are very rare indeed.
It would be appropriate for transmissions to an agent in the field. He can work out a way to smuggle information out, but you might need to tell him a time and place to meet a contact or something. Secure transmissions in either direction help you.
You can still track down the source pretty easily, but there is no doubt a station in Nevada that transmits exactly 200 characters at the same time every day whether or not they need to send anything out, or something similar to this. Knowing where it is does you no good.
I was going to post something here, but it seems half the board has already beaten me to it...
I'm looking forward to it, they had some pretty sweet demos last time. For example, to demonstrate the firewall failover capabilities, they played music on a network mount that was behind a firewall. When they shut down the primary firewall node, the music didn't even skip as the backup took over.
"The code release will come after the development process was extended by six weeks in order to improve the reliability of the software."
I've been using Dapper Drake since March, and I've had fewer problems with the betas than I have with stable releases from other distros (Gentoo I'm looking at you).
"The key is not transmitted or sent to the socket file."
No, but it would be possible to get the person's key agent to authenticate you on one of their boxes. Of course, this shouldn't be news to anyone. From man ssh(1):
Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's Unix-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.
I'm not sure what this 'box D' business is though. How does root on a box that they're not connected to help you get access to the socket for the key agent? A socket might be visible in the filesystem if they have root access to an NFS mount or something, but you're not going to have access to it as if it were the local machine, even if you're root. Sockets don't work that way. You need root on a box to which they're connected.
"Honestly. OSV is SLOW compared to native. No one wants slow."
While I don't think virtualization will kill off native OSes, it's not slow.
We use virtualization at work, the hit from VMWare is significant but usually managable, and the hit from Xen is small enough that it's getting hard to measure.
In the Ars review, the mentioned that the thing was throttling the CPU down to avoid damage, and in another review they had some instability caused by the heat.
I would have expected more from Apple, particularly after they had an identical issue with MacBook Pros. They have released a firmware update, but that just turns the fans on at lower temperatures, it can't increase the thermal conductivity of incorrectly applied thermal compound.
Real-time OSes, where guaranteeing a particular latency is more important than maximizing throughput, are often microkernels.
But server OSes like Solaris, Linux, FreeBSD, etc are overwhelmingly monolithic. They spend a lot of their time in the kernel doing network I/O, disk I/O, etc, and I would contend that performance is an issue here. L4Linux is a monolithic Linux server, so I don't think it represents the true impact of messaging overhead.
Like many services meant for users that can be expected to have a password, this is best tunneled through SSH. Access is controlled by a comparatively secure protocol and server. It's still best to patch (eg someone might get unpriviledged access to a machine and use this flaw to escalate the breach), but having a gateway that's more secure than any of the components behind it is nice. Even if the gateway itself has flaws from time to time.
Having to deal with him regularly might not be fun, but sometimes it takes assholes to get things done because they're prepared to piss people off to do what needs doing. If the goal were to make OpenBSD into another Ubuntu or Gentoo, his attitude probably wouldn't be that helpful, but for the goals they have it seems to work.
For example, major feature adds to XP over the years, all of them free. XP and OS X have been out for similar lengths of time, and there have been zero paid upgrades compared to Apple's 4.
"The bus connection between my CPU and the RAM is, indeed, the Hypertransport. Northbridge, CPU, and RAM are all connected by it."
This is wrong. Athlon64s have an on-die memory controller. They communicate with memory directly through the dual-DDR memory bus, no intermediaries. This is what gives Athlons their famously low memory latency.
In Athlon64s, the northbridge as we know it does not exist because the memory is connected directly to the CPU itself. The CPU is connected to the chipset by way of a hypertransport bus, and memory I/O for other devices goes over this bus to the CPU's memory controller.
Slashdot Mirror
In this case, the new system call was to avoid ugly hacks like FreeBSD's Copy On Write system (which is transparent, but even harder to use because of that and frequently unhelpful in adding performance).
Linus's take on the whole thing is that if you want portability, you should just use the read(), write(), etc system calls, since they perform pretty well anyway. If you absoloutely must do something platform-specific for every ounce of performance, you should have a clean API to do it with.
Either way, you've got a ton of drivers sitting around that you'll never use. They don't clog up the kernel, since the kernel image rarely contains many drivers. Instead, most Linux distros use modules that get loaded as needed. On a microkernel, they would be driver binaries that would get run as needed. They clog things up to exactly the same extent; they sit around on the hard drive doing nothing.
Either way, it's hard to add new drivers to old kernels. This is not a result of the fact that drivers are in the kernel, but of the fact that Linus refuses to use a stable driver API. This would preclude driver compatibility between versions just as effectively on a microkernel as it does now.
As I said, the two issues are unrelated.
You say that like 2.6 isn't a development branch as well.
If data can be recovered after fewer wipes, the people capable of recovering it certainly wouldn't advertise the fact. Extra passes are cheap, the costs of someone recovering data might not be.
Of course, the bad sectors that get transparently reallocated leave dead sectors that can probably be recovered and would not be wiped with stock firmware, so it's academic anyway. If you can't take that risk, you have to turn the media inside the drive into molten slag. There's no other way.
"why not store the entire filesystem on RAM with a battery, in a tmpfs. when you want to wipe it, put a thousand volts through it for a couple of seconds, then cut power?"
RAM has the same problem. If a bit has been set a particular way for a long time, it will have detectable effects afterwards. It's not enough for your computer to be able to suspend to RAM without power to maintain the memory, but a forensics lab would have better luck recovering the data.
Yup. Where they're good, they're great, and where they haven't bothered to give something attention they're crap. It doesn't keep it from being a good OS, or a pleasure to work with when you work with it, it just means it can't do everything and you have to be prepared to use something else when it's not well suited.
I went to a presentation by the OpenBSD developers during their Hack-a-thon, and they indicated that WPA was not a very high priority for them. They prefer to do authentication with auth-pf, and if encryption is needed they prefer to use VPNs. It does make it a PITA if you want to use a network you have no control over, but the OpenBSD crowd are like that sometimes.
It's not a weakness in Itanium, it's the strength of Athlons/Opterons and now Conroe/Merom/Woodcrest. Intel wanted Pentium 4s to be good media processors (and they are), but they didn't want to compete against their own Itaniums, and that's what allowed AMD to steal their lunch. They have no choice but to respond with their own strong x86 processor.
It's not the weakness of Itanium that's the problem, it's apparently their ability to make any architechture fast and not just the one they want.
Indeed.
Skepticism is a healthy thing. The early indications are of a fast chip, but don't make any purchasing decisions unless you see reviews of a shipping product.
Every non-trivial chip has errata.
They get fixed in microcode, or they're published in the errata of the chip so OS developers can work around them. Bugs that end up visible to userspace are very rare indeed.
It would be appropriate for transmissions to an agent in the field. He can work out a way to smuggle information out, but you might need to tell him a time and place to meet a contact or something. Secure transmissions in either direction help you.
You can still track down the source pretty easily, but there is no doubt a station in Nevada that transmits exactly 200 characters at the same time every day whether or not they need to send anything out, or something similar to this. Knowing where it is does you no good.
I was going to post something here, but it seems half the board has already beaten me to it...
I'm looking forward to it, they had some pretty sweet demos last time. For example, to demonstrate the firewall failover capabilities, they played music on a network mount that was behind a firewall. When they shut down the primary firewall node, the music didn't even skip as the backup took over.
"The code release will come after the development process was extended by six weeks in order to improve the reliability of the software."
I've been using Dapper Drake since March, and I've had fewer problems with the betas than I have with stable releases from other distros (Gentoo I'm looking at you).
No, but it would be possible to get the person's key agent to authenticate you on one of their boxes. Of course, this shouldn't be news to anyone. From man ssh(1):I'm not sure what this 'box D' business is though. How does root on a box that they're not connected to help you get access to the socket for the key agent? A socket might be visible in the filesystem if they have root access to an NFS mount or something, but you're not going to have access to it as if it were the local machine, even if you're root. Sockets don't work that way. You need root on a box to which they're connected.
"Honestly. OSV is SLOW compared to native. No one wants slow."
While I don't think virtualization will kill off native OSes, it's not slow.
We use virtualization at work, the hit from VMWare is significant but usually managable, and the hit from Xen is small enough that it's getting hard to measure.
"High operating temperatures (Almost 85 degrees!)"
In the Ars review, the mentioned that the thing was throttling the CPU down to avoid damage, and in another review they had some instability caused by the heat.
I would have expected more from Apple, particularly after they had an identical issue with MacBook Pros. They have released a firmware update, but that just turns the fans on at lower temperatures, it can't increase the thermal conductivity of incorrectly applied thermal compound.
I agree.
Real-time OSes, where guaranteeing a particular latency is more important than maximizing throughput, are often microkernels.
But server OSes like Solaris, Linux, FreeBSD, etc are overwhelmingly monolithic. They spend a lot of their time in the kernel doing network I/O, disk I/O, etc, and I would contend that performance is an issue here. L4Linux is a monolithic Linux server, so I don't think it represents the true impact of messaging overhead.
Like many services meant for users that can be expected to have a password, this is best tunneled through SSH. Access is controlled by a comparatively secure protocol and server. It's still best to patch (eg someone might get unpriviledged access to a machine and use this flaw to escalate the breach), but having a gateway that's more secure than any of the components behind it is nice. Even if the gateway itself has flaws from time to time.
"I would guess a new single-core pentium-M CPU"
I would have agreed until they put a dual-core chip in minis.
Linus's style is much more effective at getting Linux development done. OpenBSD is much more tightly integrated.
I've witnessed him being an asshole.
Having to deal with him regularly might not be fun, but sometimes it takes assholes to get things done because they're prepared to piss people off to do what needs doing. If the goal were to make OpenBSD into another Ubuntu or Gentoo, his attitude probably wouldn't be that helpful, but for the goals they have it seems to work.
Of course, MS has done other nice things.
For example, major feature adds to XP over the years, all of them free. XP and OS X have been out for similar lengths of time, and there have been zero paid upgrades compared to Apple's 4.
Windows is capable of running other applications at reasonable speeds, so I don't think it makes sense to blame Windows.
I think it's far more likely that Apple put a lot more time into optimizing iTunes for MacOS. They did the same for Quicktime.
"The bus connection between my CPU and the RAM is, indeed, the Hypertransport. Northbridge, CPU, and RAM are all connected by it."
This is wrong. Athlon64s have an on-die memory controller. They communicate with memory directly through the dual-DDR memory bus, no intermediaries. This is what gives Athlons their famously low memory latency.
In Athlon64s, the northbridge as we know it does not exist because the memory is connected directly to the CPU itself. The CPU is connected to the chipset by way of a hypertransport bus, and memory I/O for other devices goes over this bus to the CPU's memory controller.