I've already had the book ruined for me unexpectedly
It won't be ruined. I think it's a bit of a myth that the feeling of suspense really has anything to do with not knowing a few small facts that are revealed at the end. I can't give a definition of suspense, but I know from experience that it's something you feel in pretty much the same way whether or not you've seen some spoilers, and even when you've read a book before.
Databases with private information like credit card or social security numbers should be on encrypted disks. Not to protect against users, but to protect against the drive being replaced or stolen before it can be wiped....
If, as the original poster suggests, a large number of people in your organization have to have access to the key for this to work, then it doesn't really add much security--stealing the key off someone may not be any harder than stealing the drive.
There's really no advantage to having a server encrypt and decrypt each user's data with a different key. The server will have to know all the keys to perform the decryption at least
No, you'd do all encryption and decryption on the clients. This also has the advantage of offloading all the CPU-intensive crypto to the clients. Some complexity is required to make this work for shared data, but it's possible.
Anal sex is common in pre-literate societies and has been frequently observed among primates (especially bonobos). According to this Wikipedia article, it has been observed among many hundreds of species,...
It states some similar things, but I can't see where it says exactly that--I think you're falling into the fallacy of equating "anal sex" with "homosexual behavior".
The current candidate is criticized because he called homosexual intercourse unhealthy and unnatural. Excuse me, but are there any reproductive structures in the anus?
Erm.
Two men can have sex without having anal sex.
Heterosexual couples can have anal sex.
Anal sex isn't necessarily unhealthy.
Sexual practices that don't involve "reproductive structures" aren't necessarily unhealthy.
Sexual practices that don't lead to reproduction aren't necessarily unhealthy.
(And I don't even know what's meant by "unnatural" here--that's not the sort of word that would make sense in a scientific hypothesis. If you mean "occurs in nature"--since when are people not part of nature? Or is it just homosexuals that aren't part of nature? (That'd be circular reasoning if I've ever heard any.) And if by "natural" you mean "occurs in animals other than humans"--lots of other animals have homosexual sex.)
So, yes, the statement that "homosexual intercourse" is "unhealthy and unnatural" suggests someone that puts their personal prejudices ahead of any sort of clear-headed thinking about health.
Neo1912324, running OpenMoko, released just for developers for now and later for I don't know who and later maybe for everyone. For sale now in some places, if you can find it. What does it do? It's got advanced features running on Linux and is unlocked.
Normal people will see absolutely nothing in that phone, never mind how we, geeks, are salivating at it, if the marketing and branding effort is so weak. Sorry.
They'd be nuts to be marketing this to "normal people" at this point. They want people who will have fun hacking it, not people looking for a phone to use day-to-day.
And, yeah, even after they start mass-marketing it in the fall they're still not going to take over the entire market. So what? That doesn't mean they won't find a healthy niche for themselves.
Go ask 10 non-technical people if they would consider using Linux as an OS, and 9 will look at you like you just spoke Greek to them.
That's funny. I don't recall talking to anyone in the last few years who hasn't at least *heard* of it. Which isn't to say they really understand what it is--most of them say something like "that's some sort of alternative to Microsoft?" or "isn't that all done by volunteers?" Certainly few have considered it as something they'd actually use. But I think some people are kind of interested in the story (so there's no company called Linux? Do people make money at it? Etc.).
... maybe you could do some sort of over-the-top hacking of the hard drive to get some information about what happened to it. But even then, if the technician claims that imaging the whole drive is standard procedure, then at best all you could know is that the whole disk was read, and you'd have no way to know what they did with the data afterwards.
(On second thoughts, by far the simpler approach would be to exploit their file system code--whether they image it first or not, they'll almost certainly mount it eventually, and I doubt the code that reads the typical on-disk local file system is as carefully audited as code that, say, handles network traffic. So, set up something that breaks into any host that mounts the drive, installs a keylogger, and calls home.... But obviously at that point the customer's crossing an ethical line too. Far simpler just to wipe or encrypt any private data.)
All the tech has to do is hook the drive up as a slave to another PC, and scan for pix that way. There is no way software (that's not running) on the customer PC can detect that.
Yah. Huh, I don't know, maybe you could do some sort of over-the-top hacking of the hard drive to get some information about what happened to it. But even then, if the technician claims that imaging the whole drive is standard procedure, then at best all you could know is that the whole disk was read, and you'd have no way to know what they did with the data afterwards.
Of course at a place like Best Buy a technician is unlikely to have a totally private workspace, so they're probably depending on their coworkers/superiors looking the other way. And then how do you feel about running into that customer again? Do you really want to know that much about them?
So:
if you're never going to meet this person again, and they're never going to find out, does it really matter?
Somebody who made that kind of argument isn't someone I'd be comfortable trusting. But it's not the sort of thing that'll keep me up at night.
Good grief, no. This is basic do-unto-others as you'd have them do-unto-you stuff: I suppose I don't personally care if you want to read the contents of the hard drive (ok, stay out of my password files--I don't trust you to keep them secure; and stay out of mailbox files--besides the stuff that's mildly embarrassing to me, I don't have permission from all the other folks whose mail is in there), but I know that a lot of people really do care, and that they entrust their stuff to technicians with the understanding that their privacy will be respected.
OK, you can ask the "if a tree falls in a forest..." questions if you want: if you're never going to meet this person again, and they're never going to find out, does it really matter? I don't know. But that sort of abstract situation isn't reality. There's nothing at all difficult about the kind of trick Consumerist pulled. If you're doing this stuff routinely, you're taking a risk someone will find out.
And from the purely selfish point of view, why take the risk of losing a job and getting some awkward employment history to explain just for stuff you could rip off someplace else without much more trouble?
The price of Windows, both in pure dollars and in requirements is rising sharply.
Microsoft charges whatever they think they can get for it. If the price becomes an issue, they can (and will) give it away; the desktop monopoly is extremely valuable for many other reasons than just the revenue from individual desktop OS licenses.
"The gender ratio is pretty extreme, but it's not 100%--there *are* expert female kernel hackers." Like who?;)
I don't know how fair it is to single people out--they probably just want to get on with their work without being made examples of. But Val Henson (chunkfs), Mingming Cao (ext3/ext4), and Suparna Bhattacharya (aio, various fs hacking) are three that come to mind immediately.
And the fact that you may not know their names if you aren't a kernel developer doesn't mean much. I don't think most people realize
how large the Linux kernel project is at this point....
My suggestion would be to find someone who's pretty savvy in the area you're aimed at, and hire him or her (OK, let's face it, "him"...)
The gender ratio is pretty extreme, but it's not 100%--there *are* expert female kernel hackers.
I'm just guessing that finding a kernel guru willing to give up a month of Saturday afternoons at $300 a session will be easier than finding "Linux Kernel for Experts" at the downtown Learning Annex.
Personal tutoring is a pretty expensive way to get an education, especially if it's in a fast-moving field whose experts are in demand for other work.
Off the top of my head:
Volunteer, and find a problem to work on.
Find someone to hire you to do kernel work, or some other way to work with people doing what you want to do.
Have you considered grad school? There's places where you could get a degree taking operating systems classes and hacking the kernel for your dissertation. And when you're done you'll probably have an easier time with the previous item.
Local user groups and universities might be good places to meet up with people who share your interests. Maybe start a study group to learn some kernel subsystem together?
Conferences: OLS and linux.conf.au are fun. The OLS papers at least are on line if you can't go.
Mailing lists, irc channels--look at kernelnewbies, etc.
Books: Linux Device Drivers, Understanding the Linux Kernel, Robert Love's book.
Read the code!
And if people have told you that "the best method would be to dig into the kernel myself",... actually, in the end, it's probably the *only* way. There's a certain point in your study of any field where you just run out of "courses". That's good. It means you're ready to do real work, because you're at the point where people are still busy doing the work and figuring stuff out, and haven't yet figured out how to break it down into manageable chunks and explain it in a logical order, which is a great deal of work in and of itself.
The problem is that with almost every minor kernel version revision the driver interface is changed, so any book that goes into print will already be almost worthless by the time it got into the shops.
Nah. A lot of the basic stuff stays the same. And time invested in something that's changed isn't wasted time--an understanding of the old interface will probably help learn the new one. And I'll second the recommendation for the "Linux Device Drivers" book, it's good. See also lwn.net's kernel section for updates to the various api's.
Simple, separate the core kernel from the drivers and produce a specification for the interface which only changes with the major kernel version.
Fine. Try it. What I think you'll find is that just identifying which interfaces drivers need is a huge job in itself. Then you'll have to figure out how to maintain them when bugs are discovered or new features are needed. (If you suddenly discover that widgets can be hotplugged, and that your current widget api assumes the set of widgets available never change, are you going to add an entirely new widget api, and then maintain both the new and the old one? That doesn't sound simpler! Or are you going to make users wait a development cycle before they can plug their widgets in?)
rather than management seeing the driver maintenance and support costs being too high to bother because of the constant code churn.
The cost for in-tree drivers isn't that high--whoever fixes the api also fixes its callers in the drivers. Out-of-tree drivers have it harder, yup. So don't do that.
I know that there are many people who will veremently disagree with this because of the dogma saying, "the kernel hackers know best about the kernel so they should be the same people as those who write the drivers."
Who said that? Drivers are written by people with expertise in and access to the particular hardware--usually not core kernel maintainers. Once written, the work of future maintenance is then shared.
Find a bug (if you've done the above, you've probably run across one or two). The ideal bug would be something easy to reproduce.
Oh, and by the way, if you're not yet equipped to completely understand and fix the bug, you can still be extremely helpful (and learn a lot) just by reporting what you find out about the bug to the mailing list. Steps to reproduce it, partial results of any debugging, etc.--a lot of that grunt work can help you understand the project, and can provide just what the other developers need to finally nail the problem.
In that case its best to email the project owner or the dev list announcing your intentions.
Yep, definitely.
If the people who run it are cool they'll take a little time to sketch out what needs to be done. If not, they're probably jerks and you might do well to find a better project to donate your time to.
It's not necessarily that simple. I've got plenty of projects that need doing where it's exactly producing that sketch that would be the hardest part. It might be a solid week of work for me to to get the project broken down to the point where it'd be reasonable for somebody unfamiliar with the project to get a good start on it. And even then it might come down to "try doing x, y, and z, and then get back to me with what you've done so far, and *then* we'll be able to decide whether this is actually the right approach or whether we need to scrap it all and start over differently."
And it's painful for somebody new to have to do a ton of work like that maybe just to prove that we're barking up the wrong tree. At least when they're starting out, I'd rather have people work on something that'll be more immediately rewarding for them.... But, anyway, the developer should be able to help you find the right project. Just keep in mind that sometimes finding the right project isn't always easy, and they don't yet know whether you're someone they can count on to follow through, so there's probably only so much that you're going to get from them at first.
Yeah, absolutely, consider a graduate degree, and make sure you do a lot of research on the schools you consider to make sure they have people whose interests are closer to your own. Google is your friend here.
Might also be worth taking a harder look at your own school--are you sure there isn't an odd corner of some department someplace you hadn't previously noticed that's a hotbed of linux hackers? And if you're sure there's not, consider finding a meeting place, printing up some flyers, and starting something--maybe you'll be surprised by who comes out of the woodwork.
Other advice:
Run linux, if you don't already! It's easier to understand and care about the software that you use daily.
Work on documentation for some project. Even a lot of the most succesful projects are desperately in need of better documentation, so they'll be really happy to have you. And it's an easy way to get to know the project--both the technical details and the various personalities and projects. You'll probably at least learn how to build it, contribute patches, etc.
Find a bug (if you've done the above, you've probably run across one or two). The ideal bug would be something easy to reproduce.
Or find some interesting new feature you really want, and work on that.
There's a lot of technical stuff to learn (C, bash, various other languages, autotools (yipes), gcc, the basic posix api's, etc., etc.)--don't try to figure it out all at once. Figure out what you need to for a given project.
Document what you learn as you go along, and spend some time helping out newbies--if nothing else, it's a good way to make sure you really understand things yourself.
That can be trickier than it'd seem at first.
Sometimes stuff on the TODO list is straightforward. But sometimes the reason something's stuck on the TODO list is that people aren't really sure yet what exactly needs to be done. Without experience it may be difficult to sort out the doable stuff from the stuff that needs someone with a real breadth of knowledge about the project architecture, user requirements, etc. But, sure, ask around for advice about given projects, see what people tell you.
If you think transportation is using too much energy and producing too much pollution, then the only really reasonable way to weigh the different solutions is to tax the heck out of fuel--raise the price until it actually takes into account the externalities you're worried about--and then see what happens. Ideally it will suddenly become painfully obvious which solutions make sense and which don't.
But I suppose raising the price of gas is political suicide. So we'll go on wasting the stuff while throwing a few pennies the way of the odd "green" initiative so we can pat ourselves on the back for all the wacky energy-saving ideas our researchers come up with. And people that wonder whether any given idea actually works will be stuck trying add up all the costs by hand.
The in-kernel vs userland distinction has always struck me as quite arbitrary. So in one case you're linked at compile time and in another case you compile them separately and go through system calls.
Well, it's a bit more than that.... For one thing, the kernel is like a magic shared library that's used by every application on the system, and requesting services from the kernel doesn't require the context-shifting required to request services from another process on the same kernel. And there's a lot of vfs, memory management, etc. logic that your in-kernel filesystem code has access to that it wouldn't get purely over the system-call interface.
Why should that make one of them a derivative work and the other not? In either case the file system can be taken out and you still have a perfectly functional kernel that can run other file systems. Same goes for graphics drivers.
Userland code talks to the kernel over an extremely stable, well-defined system call interface. Filesystems in the kernel use a much lower-level and faster-changing interface, and are much more dependent on details of linux's implementation. That doesn't necessarily make them a derived work. But it's getting closer to the line.
There's also a practical consideration: the kernel developers reserve the right to change in-kernel interfaces without warning, whenever it would fix a bug, clean up some code, make something more efficient, or whatever, as long as they fix up all of the in-tree users of those interfaces. It can be challenging for an out-of-tree developer to keep up with such changes. So in practice if you want first-class Linux support for your hardware, you probably want to get your driver in the tree. And, even if they could sort out the legal issues, the Linux developers definitely aren't going to be interested in maintaining and distributing your non-GPL-compatibly-licensed driver for you....
And it's Sun's fault because they chose their license second, without (as far as I could tell) giving a clear explanation why a GPLv2-compatible license would have been impractical for them.
Linux wanting to pillage from the project isn't a good enough reason to make it impossible for people to write non-GPL drivers for Solaris
Whatever else their relative merits, Linux has by far the wider hardware support. I don't know, maybe there's a few crucial drivers Solaris would have to give up for lack of available GPL drivers, but they're giving up access to a ton of Linux driver code.
features are not patented.
The way to build them are. You just have to do it differently.
Do you consider "able to play or record mp3's" a "feature"? There certainly are patent-holders that claim you can't encode or decode an mp3 without their permission....
I would guess it's more likely related to your video card than your monitor.
Yeah, it's the drivers that always lag. The best supported stuff at this point is the integrated Intel chips, but for that you may need either a very new distribution with the latest driver, or 915resolution, to trick it into picking the right mode. And for the proprietary ati/nvidia stuff, I have no idea what the situation is....
[intelligent] means nothing if she uses her intelligence to do things I don't want.
Ya know, after the current administration, I think I'd settle for intelligent but wrong.
I mean, I was totally, bitterly opposed to invading Iraq. But, if it had been done by an administration that was actually interested in being *smart*, in exposing ideas to challenge and learning from it, etc., etc.... I don't know, maybe it could have had some merit. Or at least not been such an utter failure.
So while I may have a pretty strong political ideology of my own, I've got to recognize that a lot of good government comes down to understand the details really well, and to respecting good processes. As opposed to setting a broad course based on gut feeling and then fighting any sort of oversight.
population/area isn't really the right measure of "density" in this case--the right measure might be something like the density of the area where the average person lives. If 99% of the US population moved to New York or LA, we'd suddenly be much denser even though the population and total land area hadn't changed.
As it is we tend to have a lot of big spread-out urban/suburban areas, which leaves more space between us and our neighbors, but also makes it a lot more expensive to provide services like network, transportation, etc.
Slashdot Mirror
It won't be ruined. I think it's a bit of a myth that the feeling of suspense really has anything to do with not knowing a few small facts that are revealed at the end. I can't give a definition of suspense, but I know from experience that it's something you feel in pretty much the same way whether or not you've seen some spoilers, and even when you've read a book before.
If, as the original poster suggests, a large number of people in your organization have to have access to the key for this to work, then it doesn't really add much security--stealing the key off someone may not be any harder than stealing the drive.
No, you'd do all encryption and decryption on the clients. This also has the advantage of offloading all the CPU-intensive crypto to the clients. Some complexity is required to make this work for shared data, but it's possible.
It states some similar things, but I can't see where it says exactly that--I think you're falling into the fallacy of equating "anal sex" with "homosexual behavior".
By which logic vaginal intercourse is also unhealthy, and we should all stick to oral sex, or, better yet, masturbation....
Erm.
(And I don't even know what's meant by "unnatural" here--that's not the sort of word that would make sense in a scientific hypothesis. If you mean "occurs in nature"--since when are people not part of nature? Or is it just homosexuals that aren't part of nature? (That'd be circular reasoning if I've ever heard any.) And if by "natural" you mean "occurs in animals other than humans"--lots of other animals have homosexual sex.)
So, yes, the statement that "homosexual intercourse" is "unhealthy and unnatural" suggests someone that puts their personal prejudices ahead of any sort of clear-headed thinking about health.
They'd be nuts to be marketing this to "normal people" at this point. They want people who will have fun hacking it, not people looking for a phone to use day-to-day.
And, yeah, even after they start mass-marketing it in the fall they're still not going to take over the entire market. So what? That doesn't mean they won't find a healthy niche for themselves.
That's funny. I don't recall talking to anyone in the last few years who hasn't at least *heard* of it. Which isn't to say they really understand what it is--most of them say something like "that's some sort of alternative to Microsoft?" or "isn't that all done by volunteers?" Certainly few have considered it as something they'd actually use. But I think some people are kind of interested in the story (so there's no company called Linux? Do people make money at it? Etc.).
(On second thoughts, by far the simpler approach would be to exploit their file system code--whether they image it first or not, they'll almost certainly mount it eventually, and I doubt the code that reads the typical on-disk local file system is as carefully audited as code that, say, handles network traffic. So, set up something that breaks into any host that mounts the drive, installs a keylogger, and calls home.... But obviously at that point the customer's crossing an ethical line too. Far simpler just to wipe or encrypt any private data.)
Yah. Huh, I don't know, maybe you could do some sort of over-the-top hacking of the hard drive to get some information about what happened to it. But even then, if the technician claims that imaging the whole drive is standard procedure, then at best all you could know is that the whole disk was read, and you'd have no way to know what they did with the data afterwards.
Of course at a place like Best Buy a technician is unlikely to have a totally private workspace, so they're probably depending on their coworkers/superiors looking the other way. And then how do you feel about running into that customer again? Do you really want to know that much about them?
So:
Somebody who made that kind of argument isn't someone I'd be comfortable trusting. But it's not the sort of thing that'll keep me up at night.
Good grief, no. This is basic do-unto-others as you'd have them do-unto-you stuff: I suppose I don't personally care if you want to read the contents of the hard drive (ok, stay out of my password files--I don't trust you to keep them secure; and stay out of mailbox files--besides the stuff that's mildly embarrassing to me, I don't have permission from all the other folks whose mail is in there), but I know that a lot of people really do care, and that they entrust their stuff to technicians with the understanding that their privacy will be respected.
OK, you can ask the "if a tree falls in a forest..." questions if you want: if you're never going to meet this person again, and they're never going to find out, does it really matter? I don't know. But that sort of abstract situation isn't reality. There's nothing at all difficult about the kind of trick Consumerist pulled. If you're doing this stuff routinely, you're taking a risk someone will find out.
And from the purely selfish point of view, why take the risk of losing a job and getting some awkward employment history to explain just for stuff you could rip off someplace else without much more trouble?
Microsoft charges whatever they think they can get for it. If the price becomes an issue, they can (and will) give it away; the desktop monopoly is extremely valuable for many other reasons than just the revenue from individual desktop OS licenses.
I don't know how fair it is to single people out--they probably just want to get on with their work without being made examples of. But Val Henson (chunkfs), Mingming Cao (ext3/ext4), and Suparna Bhattacharya (aio, various fs hacking) are three that come to mind immediately.
And the fact that you may not know their names if you aren't a kernel developer doesn't mean much. I don't think most people realize how large the Linux kernel project is at this point....
The gender ratio is pretty extreme, but it's not 100%--there *are* expert female kernel hackers.
Personal tutoring is a pretty expensive way to get an education, especially if it's in a fast-moving field whose experts are in demand for other work.
Off the top of my head:
And if people have told you that "the best method would be to dig into the kernel myself",... actually, in the end, it's probably the *only* way. There's a certain point in your study of any field where you just run out of "courses". That's good. It means you're ready to do real work, because you're at the point where people are still busy doing the work and figuring stuff out, and haven't yet figured out how to break it down into manageable chunks and explain it in a logical order, which is a great deal of work in and of itself.
Nah. A lot of the basic stuff stays the same. And time invested in something that's changed isn't wasted time--an understanding of the old interface will probably help learn the new one. And I'll second the recommendation for the "Linux Device Drivers" book, it's good. See also lwn.net's kernel section for updates to the various api's.
Fine. Try it. What I think you'll find is that just identifying which interfaces drivers need is a huge job in itself. Then you'll have to figure out how to maintain them when bugs are discovered or new features are needed. (If you suddenly discover that widgets can be hotplugged, and that your current widget api assumes the set of widgets available never change, are you going to add an entirely new widget api, and then maintain both the new and the old one? That doesn't sound simpler! Or are you going to make users wait a development cycle before they can plug their widgets in?)
The cost for in-tree drivers isn't that high--whoever fixes the api also fixes its callers in the drivers. Out-of-tree drivers have it harder, yup. So don't do that.
Who said that? Drivers are written by people with expertise in and access to the particular hardware--usually not core kernel maintainers. Once written, the work of future maintenance is then shared.
Oh, and by the way, if you're not yet equipped to completely understand and fix the bug, you can still be extremely helpful (and learn a lot) just by reporting what you find out about the bug to the mailing list. Steps to reproduce it, partial results of any debugging, etc.--a lot of that grunt work can help you understand the project, and can provide just what the other developers need to finally nail the problem.
Yep, definitely.
It's not necessarily that simple. I've got plenty of projects that need doing where it's exactly producing that sketch that would be the hardest part. It might be a solid week of work for me to to get the project broken down to the point where it'd be reasonable for somebody unfamiliar with the project to get a good start on it. And even then it might come down to "try doing x, y, and z, and then get back to me with what you've done so far, and *then* we'll be able to decide whether this is actually the right approach or whether we need to scrap it all and start over differently."
And it's painful for somebody new to have to do a ton of work like that maybe just to prove that we're barking up the wrong tree. At least when they're starting out, I'd rather have people work on something that'll be more immediately rewarding for them.... But, anyway, the developer should be able to help you find the right project. Just keep in mind that sometimes finding the right project isn't always easy, and they don't yet know whether you're someone they can count on to follow through, so there's probably only so much that you're going to get from them at first.
Yeah, absolutely, consider a graduate degree, and make sure you do a lot of research on the schools you consider to make sure they have people whose interests are closer to your own. Google is your friend here.
Might also be worth taking a harder look at your own school--are you sure there isn't an odd corner of some department someplace you hadn't previously noticed that's a hotbed of linux hackers? And if you're sure there's not, consider finding a meeting place, printing up some flyers, and starting something--maybe you'll be surprised by who comes out of the woodwork.
Other advice:
That can be trickier than it'd seem at first. Sometimes stuff on the TODO list is straightforward. But sometimes the reason something's stuck on the TODO list is that people aren't really sure yet what exactly needs to be done. Without experience it may be difficult to sort out the doable stuff from the stuff that needs someone with a real breadth of knowledge about the project architecture, user requirements, etc. But, sure, ask around for advice about given projects, see what people tell you.
If you think transportation is using too much energy and producing too much pollution, then the only really reasonable way to weigh the different solutions is to tax the heck out of fuel--raise the price until it actually takes into account the externalities you're worried about--and then see what happens. Ideally it will suddenly become painfully obvious which solutions make sense and which don't. But I suppose raising the price of gas is political suicide. So we'll go on wasting the stuff while throwing a few pennies the way of the odd "green" initiative so we can pat ourselves on the back for all the wacky energy-saving ideas our researchers come up with. And people that wonder whether any given idea actually works will be stuck trying add up all the costs by hand.
Well, it's a bit more than that.... For one thing, the kernel is like a magic shared library that's used by every application on the system, and requesting services from the kernel doesn't require the context-shifting required to request services from another process on the same kernel. And there's a lot of vfs, memory management, etc. logic that your in-kernel filesystem code has access to that it wouldn't get purely over the system-call interface.
Userland code talks to the kernel over an extremely stable, well-defined system call interface. Filesystems in the kernel use a much lower-level and faster-changing interface, and are much more dependent on details of linux's implementation. That doesn't necessarily make them a derived work. But it's getting closer to the line.
There's also a practical consideration: the kernel developers reserve the right to change in-kernel interfaces without warning, whenever it would fix a bug, clean up some code, make something more efficient, or whatever, as long as they fix up all of the in-tree users of those interfaces. It can be challenging for an out-of-tree developer to keep up with such changes. So in practice if you want first-class Linux support for your hardware, you probably want to get your driver in the tree. And, even if they could sort out the legal issues, the Linux developers definitely aren't going to be interested in maintaining and distributing your non-GPL-compatibly-licensed driver for you....
The FSF lists 30 GPL-compatible licenses other than the GPL itself.
And it's Sun's fault because they chose their license second, without (as far as I could tell) giving a clear explanation why a GPLv2-compatible license would have been impractical for them.
Whatever else their relative merits, Linux has by far the wider hardware support. I don't know, maybe there's a few crucial drivers Solaris would have to give up for lack of available GPL drivers, but they're giving up access to a ton of Linux driver code.
Do you consider "able to play or record mp3's" a "feature"? There certainly are patent-holders that claim you can't encode or decode an mp3 without their permission....
Yeah, it's the drivers that always lag. The best supported stuff at this point is the integrated Intel chips, but for that you may need either a very new distribution with the latest driver, or 915resolution, to trick it into picking the right mode. And for the proprietary ati/nvidia stuff, I have no idea what the situation is....
Ya know, after the current administration, I think I'd settle for intelligent but wrong.
I mean, I was totally, bitterly opposed to invading Iraq. But, if it had been done by an administration that was actually interested in being *smart*, in exposing ideas to challenge and learning from it, etc., etc.... I don't know, maybe it could have had some merit. Or at least not been such an utter failure.
So while I may have a pretty strong political ideology of my own, I've got to recognize that a lot of good government comes down to understand the details really well, and to respecting good processes. As opposed to setting a broad course based on gut feeling and then fighting any sort of oversight.
population/area isn't really the right measure of "density" in this case--the right measure might be something like the density of the area where the average person lives. If 99% of the US population moved to New York or LA, we'd suddenly be much denser even though the population and total land area hadn't changed. As it is we tend to have a lot of big spread-out urban/suburban areas, which leaves more space between us and our neighbors, but also makes it a lot more expensive to provide services like network, transportation, etc.