My point was that it has already been done, twice: SSH and TLS.
Whether the asymmetric keys are wrapped in OpenPGP certificates, X.509 certificates, or nothing at all doesn't change the fact that we're already using public-key crypto to authenticate network streams (client-to-server and server-to-client). We don't need new network-stream crypto protocols to use public-key crypto for authentication. We need to fix the broken certification systems that help us know who the keys belong to.
Much like the SSL cert ecosystem today provides a means of merchant identification, without there either being a single point of failure or sinister government control.
Actually, as it's currently implemented, the SSL cert ecosystem today provides many points of failure and sinister government control that compromise the whole system. Count the number of "trusted" root CAs in your web browser -- any one of them can be evil, compromised by crackers, or agree to government intrusion in order to compromise any your web-based communications. Here's a more in-depth analysis of the problem. Even worse, these "trusted" roots can create subordinate CAs, which can in turn compromise all of your X.509-secured communications. You might also be interested in the EFF's SSL Observatory, along with their analysis of the abysmal state of today's X.509 certificate infrastructure.
To solve this properly, we'll probably need to do at least the following:
enable multiple paths of certification for any certificate -- X.509 only allows one issuer per certificate (OpenPGP allows an arbitrary number).
provide tools to let users indicate scoped reliance on certifying authorities. For example, you might be fine with using the US Government's certifying authority to identify https://www.irs.gov/ (note: the IRS currently uses akamai's CDN, so TLS is entirely broken for it). But you might not want to accept their certifications for https://slashdot.org/ (note: slashdot doesn't currently use TLS properly site-wide either, even though it should) or any other site that is frequently critical of the US government.
I agree that we need work on distributed trust infrastructure. That's why i contribute to the monkeysphere project -- we're pushing OpenPGP-style multi-party, user-centric certification into SSH, the web, and everywhere else we can.
I'm just not convinced that the US Government is likely do this the right way. It seems probable that they'll be happy with centrally-controlled, single-trust-path certification. Or that they'll botch it in the same way that X.509 is currently botched.
The scheme you're proposing is open to a replay attack by a man-in-the-middle. The MITM simply requests the randomly-generated string from the server, forwards it verbatim to the client, and passes along the client's response as well.
To do this right, you'd need to have the thing being signed/decrypted/passed around (the nonce) embed some unimpeachable detail about the established channel that should be visible to both sides of the transaction without being controllable by either (e.g. start by negotiating an anonymous DH key exchange, then embed the negotiated DH key in the nonce). Then both parties need to:
generate and sign their own nonce,
verify the other party's signature over the received nonce
verify that the key the other party is using does in fact belong to the expected party
inspect the received nonce to ensure that it is bound to the established channel
This sort of asymmetric-key authentication scheme is already implemented bi-directionally in two different widely-deployed stream-based connections: SSH and TLS. Please don't try to propose a third protocol, it's hard enough to get right in these two already:)
The asymmetric keys in question can be wrapped in whatever sort of packaging you like -- raw pubkey material (commonly used for SSH), X.509 certificates (commonly used for TLS), OpenPGP certificates, or some mixture of the above. See the monkeysphere project if you want to use OpenPGP certification with SSH and TLS connections.
i can't believe this is being moderated as Insightful. What are you mods thinking!?
i'm a huge fan of djb's work, and i use his software (and i use Debian), but quoting his theories about cross-platform compatibility as support for your argument is pretty weak. djb's strong suit is his technical and mathematical rigor, not his infamous interpersonal skills.
For those of us who maintain more than a handful of machines, cross-package similarity is a real and significant advantage:
Just installed package foo, but don't really know quite how you might use it best? debian policy lets you confidently look in/usr/share/doc/foo and know that you'll find *something* that the package maintainer thought would be worth reading, even if it's only the changelog.
package doesn't have a man page? thanks to policy, that's an actual bug, not just an inconvenience.
need to understand exactly how service foo starts and stops? you can read/etc/init.d/foo
where are the config files? you can find them in/etc/foo/
and so on...
djb is right that cross-platform incompatibility is a significant hassle. But what's his solution to that? He invents a whole new filesystem standard (see "Filesystem layout" on this page)! I respect the man for his technical prowess. And i'll grant that his proposed scheme probably makes more technical sense than the FHS, when viewed in isolation.
But you don't achieve cross-platform compatibility through technical rigor. You achieve it through compromise, social and political consensus, transparency, legacy support, and published standards. The FHS currently represents all of those things, as does debian. In fact, that's why debian endorses, attempts to comply with, and contributes back to the FHS, because it is committed to cross-platform compatibility.
djb's technical nit-picking, while usually a good thing, does him a disservice in this particular area, and debian gets it right.
With all due respect, your proposed fixes either miss the point (i.e. they aren't the fault of UNIX) and/or the resolutions to these problems are already completed or well underway.
1) Make filenames and command flags case-insensitive. The few cycles you spend doing case comparisons will quickly pale in comparison to the time savings you experience in tech support situations where a touch typist accidentally hits space too soon and types "emacS."
If this were a problem, it would be a UI problem, not a UNIX problem. But who are you fixing this for anyway? GUI users never types in filenames at all -- they just click on them. The CLI user has tons of resources at his or her disposal to alleviate mistyped filenames -- tab completion and filename globbing are available in bash alone.
if you feel you'd like to use ambiguous, case-insensitive filenames, you should be using a UI which handles that re-mapping for you. i want my tools to know that file abcde is different from file ABCDE. Please don't "fix" that feature!
2) Several files that do not have extensions usually have some information about their default parser in line #1. Either parse it, or start using file extensions in *NIX.
This is also best done by userland utilities, so that people can decide what mapping scheme they want to use for themselves. In fact, it already is implemented in userland utilities, for everything from konqueror and nautilus (on the GUI side) to simpler, old-school CLI tools like file and the mailcap handlers. GNOME and KDE (the two major GUI subsystems which run on top of X11) are now both committed to using a shared MIME-type database in their next releases (actually, GNOME already uses it in 2.8, and KDE will use it soon).
But don't make this a part of UNIX, please! Sometimes you need to dig into a file's guts with a different tool than the one "associated" with that file type. Any sort of tight binding would be anathema to the flexibility and power that UNIX represents.
3) Start making UI's that only initially expose the 20% of the UI that 80% of people will use. There's no reason for a CD-burning package to have a checkbox on the main screen about verifying post-gap length for 99% of the people in the world.
This recommendation is the closest to being on-target, but again, it's not the fault of UNIX, it's a question that needs to be resolved by system layers much closer to the user. it's a UI problem, and it is actively being worked on. Both GNOME and KDE have made leaps and bounds in streamlining their interfaces -- under certain conditions. They don't want to remove all the options for everyone, but to enable a "non-power user mode".
Here's an example from GNOME's Human Interface Guidelines. If you find a gnome app that doesn't meet that spec, you should file a bug against it (or fix it, if you have the skills/tools to do so!). For KDE, you might want to read relevant sections from their User Interface Guidelines as well.
Let's clean up the UI so that people who want a Windows- or Mac-style interface can have it, yes! but please don't take that as a shortcoming of UNIX. If it's a problem, it's a problem of the GUI layers that have been built on top of it. But whatever you do, please please please don't sacrifice the flexibility and power that undergirds the whole system!
Actually, it looks like this was patched in debian sid/unstable on on 18 November 2004 with urgency=high.
And from my logs, it looks like it propagated into sarge/testing some time before 23 Nov 2004. if you can't bring yourself to track the debian packages themselves, i recommend installing something like cron-apt and have it mail you when new packages are ready to be installed.
If you maintain any sort of servers that are on the 'net, please keep them patched. It's common courtesy for the rest of us who use this incredible shared resource.
Thanks! i actually did read the article. If they were doing a test run, they were probably considering the possible risks very deliberately on that run, don't you think? And they still killed someone. This is with all of the nice constraints that they get to work within on the AirTrain.
If those blocks had been people instead, yes, the individual crushed might not have been crushed to death. But then what about the people doing the crushing themselves? How will they fare? There are no seatbelts in the AirTrain.
Now imagine thousands of these systems on the road (not rails) every day, interacting with many more unforseen variables than just concrete blocks in place of human bodies. There are no test engineers around to consider all the angles (and maybe miss a few), and no immediate rescue personnel. Automated cars are a disaster waiting to happen, unless they have extremely well-controlled environments. We're just not there yet.
that's a good point. i was also just reminded of the automatic train that runs underneath atlanta's Hartsfield International Airport (ATL). This train has been in service for more than a decade (the linked page refers to an upgrade project completed in 2000), and it has Just Worked for as long as i can remember it. so maybe it's not about the automation at all, but more about the general information-friendliness of the system.
but i will note that the train in ATL has an even more constrained environment than the AirTrain: it is underground, and its tracks are basically a single straight line, whereas the AirTrain has a much weirder layout.
I'd imagine that the first fully automated cars will be airport shuttles and similar vehicles which make a repeated circuit of stops.
let's be realistic here and look at real-life automated transport. Here in New York, they've recently made the AirTrain a completely automated train that goes to the airport (JFK) from the nearest subway station.
anyone who has used the AirTrain will tell you that the system is a huge step backwards from the human-driven buses which used the local roads. The AirTrain has no drivers to ask questions of, is poorly documented, and occasionally stops in between stations with no information to any of the passengers about what's going on.
also, when it reaches a station, it leaves the doors open for either much longer than it needs to (when no one is waiting on the platform to come in, or on the train to go out), or it closes them too quickly (yes, closing doors on people's luggage or their arms!). Human conductors of the subway are much more efficient with these sort of things.
Now stop and consider the constraints on the system that the AirTrain deals with: no other traffic at all, no pedestrians/animals on the tracks, no intersections to speak of, and an extremely simple, well-maintained route. And it still sucks. An autonomous car would need to deal with a much more unconstrained system (potholes, construction, children, broken traffic lights, aggressive drivers...). We should all be hoping that these sort of vehicles aren't unleashed on our public streets soon.
If you found in a survey that 90% of all serial killers chew gum, you may have found a correlation.
Actually, you haven't yet found a correlation there, because you haven't tested the non-serial-killer population. if you find that 90% of normal people who aren't serial killers also chew gum, then there is not even a correlation, let alone causation.
This was one of the mistakes made by Frederic Wertham in his book Seduction of the Innocent, which condemned comic books as a genre by pointing out that nearly every juvenile delinquent boy had read comic books. Of course, nearly every boy had read comic books in that era, and the majority of them had not turned out delinquent. Wertham had proved no correlation.
Evidence of a correlation is valuable, and shouldn't be dismissed simply because it doesn't imply causation. it is a clue that can be used to search for hidden variables that may actually be causal factors (though nothing is ever so clean as strictly causal or non-causal in the real world).
Don't hide your head in the sand arguing about "correlation vs. causation" simply because you like video games and want to keep them legal. Actual demonstration of causality is extremely difficult to do, and most inferences we make on a daily basis as humans are done on the basis of correlation, because it's actually a pretty good heuristic.
However, if you can show that there isn't even a correlation, that is a much more powerful argument to use in shaping public policy than just claiming that no one has proved that video games cause violence.
if you use a more popular architecture (x86, for example), you can use the mozilla packages from unstable which are currently at 1.7.2 (1.7.3, having been released by mozilla just yesterday, has not been introduced to sid/unstable yet to my knowledge).
But there's hope:
here's a good link
about apt-pinning, which lets you pull select packages from sid/unstable while maintaining the rest of your system as sarge.
i just made the changes described in the link above to/etc/apt/preferences and/etc/apt/sources.list yesterday, and it worked pretty smoothly. if you run into any problems, you can try uninstalling the mozilla-browser and mozilla-mailnews packages and then reinstalling them while targetting the unstable distro like this:
apt-get remove --purge mozilla-mailnews mozilla-browser
apt-get -t unstable install mozilla
debian's multi-arch focus is a Good Thing, but delays the propagation of security fixes into testing. OTOH, no one ever claimed to support testing for security fixes in the first place, so you kinda get what you were promised.
By putting their advertisers' interests above their readers', news sites risk alienating their core customers. Without us, there wouldn't be any advertisers to appease.
This strikes me as obviously wrong. with corporate media, and especially with freely-distributed corporate media, the media company's core customers are not their readers. Their core customers are in fact their advertisers.
This is one more reason why anyone who cares about the content of the news they read should ensure that they readsomenon-corporatenewssources.
As a reader, you should demand that your media keeps your interests in mind, not just the interests of people who want to sell you things.
Port knocking is an excellent way to greatly reduce the probability that someone will be able to use a newly discovered exploit from using it against your server before an update is available to fix the exploit.
This is only true for vulnerabilities in services which allow for or rely on attackers making new connections. many vunerabilities take other forms, and port-knocking is no protection against them. For example:
No, because having a server listen on a UDP port clearly signals the expectation of meaningful communication.
How, exactly does it do that? my understanding of UDP is that there is no indication to the sending computer that anything happened on the receiving end. The reason you can portscan TCP is because of the handshake required to open a stream connection. There is no "expectation of meaningful communication" with UDP.
Seriously, read RFC 768, which defines UDP. It's a quick read. There's no way for a sender to know what happens to the UDP packets you send.
Even if somebody can sniff traffic in principle, he can't sniff everybody's traffic all the time. He has to evaluate which targets are likely to yield anything of value. Since a system protected by portknocking does not give him any clues of what he can expect to find, why would he sniff your traffic?
well, if you actually use the service you are protecting with portknocking, then there will be a suspiciously non-zero amount of traffic to and from your machine via port 22 (if ssh is what yer protecting), even though that port is not open to the casual scanner.
So if the relevant traffic-sniffing malware can catch data going to your machine, it would be trivial for it to figure out that the service is running. All it then needs to do is to capture traffic immediately prior to your next stream initiation to figure out what is going on.
Seems to me that a single, timestamped (and therefore non-replayable), cryptographically-generated UDP packet to a cryptographically-chosen UDP port would offer as much added security as port knocking (even with the one-time pad mentioned in the post). But the UDP technique has fewer complications in the implementation, which means it's more likely to be built correctly, which is a big part of security.
Sadly, this idea was already presented in Eldred v. Ashcroft, but the Supreme Court seems to have decided that interminable copyright extensions are OK as long as they are done piecemeal.
Your analysis is on target, but you probably don't have the clout that Disney ("We Must Always Own the Mouse!") and the other major publishers have to push their vision of copyright.
i know it's nothing like the downstream speeds yer talking about, but speakeasy offers server-friendly residential DSL packages with 768K upstream, which is better than any other DSL provider i've seen. and it's a reliable connection, too, in the month or two i've had it under heavy load.
i'm not a fan of the big corps in general. AT&T royally screwed me with a crappy DSL connection, pitiful upstream speed, non-documented port-blocking, an abysmal AUP once i started running servers, and a lock-in contract that they wouldn't let me out of even if i paid it off in full early.
But speakeasy's actually been pretty good. When the line was having some burn-in problems, they were willing to actually talk through the issues in full with me let me decide which tradeoffs i preferred to make to get things resolved. Now, if only their downstream could really provide the 6Mbps they sold it to me as instead of the 4Mbps which is what they can reliably provide... sigh. At least they explicitly let you do whatever you want with the connection you paid for.
actually, if that same information (username/password) is the only thing required by the system to acquire root-level powers (e.g. you have complete sudo privileges), then any application which harvests your uname/pw could use it to run any sudo'ed application -- including a root shell. This is definitely "r00ted", not just "usered".
My understanding is that this is the way Mac OS X is set up by default for the first account. So thjs kind of harvesting via a trojan is a real concern. The technique has yet to be exploited publicly that i know of. Of course, it's not a "hole in the OS", strictly speaking, but you need to think about it if yer an OS X admin.
This is right on. software RAID also gives you full source to what's actually being done to your disks so you have a better chance of recovering data in the event that a horrible failure (>1 drive, for example) does eventually happen.
moreover, software RAID tends to be more tunable, and you can count on the logic for the RAID control subsystem in yer OS to be updated more promptly (if you use a reasonable OS) than you can count on the firmware for some H/W controller to be updated.
Also, you can indeed do hotswap with software RAID, as long as you are working with the right disk I/O subsystem. for example, if your drives are all external ieee1394 or USB2, there's nothing stopping you from just adding a new drive to the system and adding it to the raid set as a spare disk (or a replacement), and moving on with your life while the array rebuilds itself in the background.
Everyone who wants to communicate about their computer should name the thing, if only for the sake of the tech support people they call to help them out when it's busted. But most people choose horrible names like "david's computer", or "my new computer", or worse, they name it after their spouse or something.
if you support the GNU project, you'll see that we need copyrights. The whole foundation of GNU principles is based on enforceable copyright law. We need some method to strongly coerce people who take advantage of the commons (read: GPL'ed works) to contribute back to the commons themselves. Copyright is that mechanism at the moment, via the GPL. Feel free to propose another mechanism, but for right now, it seems to be working pretty well. There's been a huge explosion of GPL'ed work in the last 10 years.
Of course, some folks will always want to use more lenient licenses, like the BSD license, or just straight-up public domain, as is their right. And their work will be more likely to be adopted by commercial interests and "embraced and extended" into proprietary applications. That should be up to the individual author.
Under a no-copyright regime, if you don't want other people taking your work and bastardizing it and not at least returning the bastardizations for peer review, your only option to just keep yer code hidden from everyone else forever. We all know what code like that looks like.
Getting rid of copyright altogether? No thank you. If i put in the effort to create something, i want to retain some control over it for a little while at least.
Now, does that control need to last 90-odd years for me to have an incentive to create? of course not, but that's a different question...
Actually, it would be cheaper to have Universal Healthcare than our current arrangement. Have a look at the results of this study from earlier this year, published in International Journal of Health Services.
The insurance industry and its attendant administrative expenses are by far the leading cause of the spiralling costs of the US healthcare system. Quoting from the above-linked article:
Insurance overhead (one component of administrative costs) rose by a whopping 16.8% in 2002, after a 12.5% increase in 2001, making it the fastest growing component of health expenditure over the past three years.
Basically, if we could get rid of the incompetent middlemen and businessfolk who've inserted themselves in the way of actually providing healthcare, we'd have enough money to insure everyone in the country who's currently left out or underinsured.
The problem is not Universal Healthcare or lack of money.
Slashdot Mirror
My point was that it has already been done, twice: SSH and TLS.
Whether the asymmetric keys are wrapped in OpenPGP certificates, X.509 certificates, or nothing at all doesn't change the fact that we're already using public-key crypto to authenticate network streams (client-to-server and server-to-client). We don't need new network-stream crypto protocols to use public-key crypto for authentication. We need to fix the broken certification systems that help us know who the keys belong to.
Actually, as it's currently implemented, the SSL cert ecosystem today provides many points of failure and sinister government control that compromise the whole system. Count the number of "trusted" root CAs in your web browser -- any one of them can be evil, compromised by crackers, or agree to government intrusion in order to compromise any your web-based communications. Here's a more in-depth analysis of the problem. Even worse, these "trusted" roots can create subordinate CAs, which can in turn compromise all of your X.509-secured communications. You might also be interested in the EFF's SSL Observatory, along with their analysis of the abysmal state of today's X.509 certificate infrastructure.
To solve this properly, we'll probably need to do at least the following:
I agree that we need work on distributed trust infrastructure. That's why i contribute to the monkeysphere project -- we're pushing OpenPGP-style multi-party, user-centric certification into SSH, the web, and everywhere else we can.
I'm just not convinced that the US Government is likely do this the right way. It seems probable that they'll be happy with centrally-controlled, single-trust-path certification. Or that they'll botch it in the same way that X.509 is currently botched.
The scheme you're proposing is open to a replay attack by a man-in-the-middle. The MITM simply requests the randomly-generated string from the server, forwards it verbatim to the client, and passes along the client's response as well.
To do this right, you'd need to have the thing being signed/decrypted/passed around (the nonce) embed some unimpeachable detail about the established channel that should be visible to both sides of the transaction without being controllable by either (e.g. start by negotiating an anonymous DH key exchange, then embed the negotiated DH key in the nonce). Then both parties need to:
This sort of asymmetric-key authentication scheme is already implemented bi-directionally in two different widely-deployed stream-based connections: SSH and TLS. Please don't try to propose a third protocol, it's hard enough to get right in these two already :)
The asymmetric keys in question can be wrapped in whatever sort of packaging you like -- raw pubkey material (commonly used for SSH), X.509 certificates (commonly used for TLS), OpenPGP certificates, or some mixture of the above. See the monkeysphere project if you want to use OpenPGP certification with SSH and TLS connections.
i'm a huge fan of djb's work, and i use his software (and i use Debian), but quoting his theories about cross-platform compatibility as support for your argument is pretty weak. djb's strong suit is his technical and mathematical rigor, not his infamous interpersonal skills.
For those of us who maintain more than a handful of machines, cross-package similarity is a real and significant advantage:
djb is right that cross-platform incompatibility is a significant hassle. But what's his solution to that? He invents a whole new filesystem standard (see "Filesystem layout" on this page)! I respect the man for his technical prowess. And i'll grant that his proposed scheme probably makes more technical sense than the FHS, when viewed in isolation.
But you don't achieve cross-platform compatibility through technical rigor. You achieve it through compromise, social and political consensus, transparency, legacy support, and published standards. The FHS currently represents all of those things, as does debian. In fact, that's why debian endorses, attempts to comply with, and contributes back to the FHS, because it is committed to cross-platform compatibility. djb's technical nit-picking, while usually a good thing, does him a disservice in this particular area, and debian gets it right.
if you feel you'd like to use ambiguous, case-insensitive filenames, you should be using a UI which handles that re-mapping for you. i want my tools to know that file abcde is different from file ABCDE. Please don't "fix" that feature!
This is also best done by userland utilities, so that people can decide what mapping scheme they want to use for themselves. In fact, it already is implemented in userland utilities, for everything from konqueror and nautilus (on the GUI side) to simpler, old-school CLI tools like file and the mailcap handlers. GNOME and KDE (the two major GUI subsystems which run on top of X11) are now both committed to using a shared MIME-type database in their next releases (actually, GNOME already uses it in 2.8, and KDE will use it soon).But don't make this a part of UNIX, please! Sometimes you need to dig into a file's guts with a different tool than the one "associated" with that file type. Any sort of tight binding would be anathema to the flexibility and power that UNIX represents.
This recommendation is the closest to being on-target, but again, it's not the fault of UNIX, it's a question that needs to be resolved by system layers much closer to the user. it's a UI problem, and it is actively being worked on. Both GNOME and KDE have made leaps and bounds in streamlining their interfaces -- under certain conditions. They don't want to remove all the options for everyone, but to enable a "non-power user mode".Here's an example from GNOME's Human Interface Guidelines. If you find a gnome app that doesn't meet that spec, you should file a bug against it (or fix it, if you have the skills/tools to do so!). For KDE, you might want to read relevant sections from their User Interface Guidelines as well.
Let's clean up the UI so that people who want a Windows- or Mac-style interface can have it, yes! but please don't take that as a shortcoming of UNIX. If it's a problem, it's a problem of the GUI layers that have been built on top of it. But whatever you do, please please please don't sacrifice the flexibility and power that undergirds the whole system!
And from my logs, it looks like it propagated into sarge/testing some time before 23 Nov 2004. if you can't bring yourself to track the debian packages themselves, i recommend installing something like cron-apt and have it mail you when new packages are ready to be installed.
If you maintain any sort of servers that are on the 'net, please keep them patched. It's common courtesy for the rest of us who use this incredible shared resource.
If those blocks had been people instead, yes, the individual crushed might not have been crushed to death. But then what about the people doing the crushing themselves? How will they fare? There are no seatbelts in the AirTrain.
Now imagine thousands of these systems on the road (not rails) every day, interacting with many more unforseen variables than just concrete blocks in place of human bodies. There are no test engineers around to consider all the angles (and maybe miss a few), and no immediate rescue personnel. Automated cars are a disaster waiting to happen, unless they have extremely well-controlled environments. We're just not there yet.
but i will note that the train in ATL has an even more constrained environment than the AirTrain: it is underground, and its tracks are basically a single straight line, whereas the AirTrain has a much weirder layout.
anyone who has used the AirTrain will tell you that the system is a huge step backwards from the human-driven buses which used the local roads. The AirTrain has no drivers to ask questions of, is poorly documented, and occasionally stops in between stations with no information to any of the passengers about what's going on.
also, when it reaches a station, it leaves the doors open for either much longer than it needs to (when no one is waiting on the platform to come in, or on the train to go out), or it closes them too quickly (yes, closing doors on people's luggage or their arms!). Human conductors of the subway are much more efficient with these sort of things.
it was even delayed for several months when it killed a person during a test run!
Now stop and consider the constraints on the system that the AirTrain deals with: no other traffic at all, no pedestrians/animals on the tracks, no intersections to speak of, and an extremely simple, well-maintained route. And it still sucks. An autonomous car would need to deal with a much more unconstrained system (potholes, construction, children, broken traffic lights, aggressive drivers...). We should all be hoping that these sort of vehicles aren't unleashed on our public streets soon.
Evidence of a correlation is valuable, and shouldn't be dismissed simply because it doesn't imply causation. it is a clue that can be used to search for hidden variables that may actually be causal factors (though nothing is ever so clean as strictly causal or non-causal in the real world).
Don't hide your head in the sand arguing about "correlation vs. causation" simply because you like video games and want to keep them legal. Actual demonstration of causality is extremely difficult to do, and most inferences we make on a daily basis as humans are done on the basis of correlation, because it's actually a pretty good heuristic.
However, if you can show that there isn't even a correlation, that is a much more powerful argument to use in shaping public policy than just claiming that no one has proved that video games cause violence.
the debian mozilla packages currently in sid/unstable appear to be not propagating into sarge/testing due to not being built cleanly for the mips and mipsel architectures. i'm not enough of a mozilla or mips hacker to understand the exact problems with the build, but the failed build logs are available for review, if anyone wants to send hints to the debian maintainer.
if you use a more popular architecture (x86, for example), you can use the mozilla packages from unstable which are currently at 1.7.2 (1.7.3, having been released by mozilla just yesterday, has not been introduced to sid/unstable yet to my knowledge).
But there's hope: here's a good link about apt-pinning, which lets you pull select packages from sid/unstable while maintaining the rest of your system as sarge.
i just made the changes described in the link above to /etc/apt/preferences and /etc/apt/sources.list yesterday, and it worked pretty smoothly. if you run into any problems, you can try uninstalling the mozilla-browser and mozilla-mailnews packages and then reinstalling them while targetting the unstable distro like this:
debian's multi-arch focus is a Good Thing, but delays the propagation of security fixes into testing. OTOH, no one ever claimed to support testing for security fixes in the first place, so you kinda get what you were promised.This is one more reason why anyone who cares about the content of the news they read should ensure that they read some non-corporate news sources.
As a reader, you should demand that your media keeps your interests in mind, not just the interests of people who want to sell you things.
Seriously, read RFC 768, which defines UDP. It's a quick read. There's no way for a sender to know what happens to the UDP packets you send.
well, if you actually use the service you are protecting with portknocking, then there will be a suspiciously non-zero amount of traffic to and from your machine via port 22 (if ssh is what yer protecting), even though that port is not open to the casual scanner.So if the relevant traffic-sniffing malware can catch data going to your machine, it would be trivial for it to figure out that the service is running. All it then needs to do is to capture traffic immediately prior to your next stream initiation to figure out what is going on.
Seems to me that a single, timestamped (and therefore non-replayable), cryptographically-generated UDP packet to a cryptographically-chosen UDP port would offer as much added security as port knocking (even with the one-time pad mentioned in the post). But the UDP technique has fewer complications in the implementation, which means it's more likely to be built correctly, which is a big part of security.
The story walterbyrd is referring to about patent issues with SQL Server can be found here
Your analysis is on target, but you probably don't have the clout that Disney ("We Must Always Own the Mouse!") and the other major publishers have to push their vision of copyright.
i'm not a fan of the big corps in general. AT&T royally screwed me with a crappy DSL connection, pitiful upstream speed, non-documented port-blocking, an abysmal AUP once i started running servers, and a lock-in contract that they wouldn't let me out of even if i paid it off in full early.
But speakeasy's actually been pretty good. When the line was having some burn-in problems, they were willing to actually talk through the issues in full with me let me decide which tradeoffs i preferred to make to get things resolved. Now, if only their downstream could really provide the 6Mbps they sold it to me as instead of the 4Mbps which is what they can reliably provide... sigh. At least they explicitly let you do whatever you want with the connection you paid for.
actually, if that same information (username/password) is the only thing required by the system to acquire root-level powers (e.g. you have complete sudo privileges), then any application which harvests your uname/pw could use it to run any sudo'ed application -- including a root shell. This is definitely "r00ted", not just "usered".
My understanding is that this is the way Mac OS X is set up by default for the first account. So thjs kind of harvesting via a trojan is a real concern. The technique has yet to be exploited publicly that i know of. Of course, it's not a "hole in the OS", strictly speaking, but you need to think about it if yer an OS X admin.
moreover, software RAID tends to be more tunable, and you can count on the logic for the RAID control subsystem in yer OS to be updated more promptly (if you use a reasonable OS) than you can count on the firmware for some H/W controller to be updated.
Also, you can indeed do hotswap with software RAID, as long as you are working with the right disk I/O subsystem. for example, if your drives are all external ieee1394 or USB2, there's nothing stopping you from just adding a new drive to the system and adding it to the raid set as a spare disk (or a replacement), and moving on with your life while the array rebuilds itself in the background.
the raidtools2 package for linux is really sweet!
or our good friends The Universal Church Triumphant of the Apathetic Agnostic.
or turned around! i'm so confused! which is left and which is right again?
Everyone who wants to communicate about their computer should name the thing, if only for the sake of the tech support people they call to help them out when it's busted. But most people choose horrible names like "david's computer", or "my new computer", or worse, they name it after their spouse or something.
check out Optimus Prime!
if you support the GNU project, you'll see that we need copyrights. The whole foundation of GNU principles is based on enforceable copyright law. We need some method to strongly coerce people who take advantage of the commons (read: GPL'ed works) to contribute back to the commons themselves. Copyright is that mechanism at the moment, via the GPL. Feel free to propose another mechanism, but for right now, it seems to be working pretty well. There's been a huge explosion of GPL'ed work in the last 10 years.
Of course, some folks will always want to use more lenient licenses, like the BSD license, or just straight-up public domain, as is their right. And their work will be more likely to be adopted by commercial interests and "embraced and extended" into proprietary applications. That should be up to the individual author.
Under a no-copyright regime, if you don't want other people taking your work and bastardizing it and not at least returning the bastardizations for peer review, your only option to just keep yer code hidden from everyone else forever. We all know what code like that looks like.
Getting rid of copyright altogether? No thank you. If i put in the effort to create something, i want to retain some control over it for a little while at least.
Now, does that control need to last 90-odd years for me to have an incentive to create? of course not, but that's a different question...
The insurance industry and its attendant administrative expenses are by far the leading cause of the spiralling costs of the US healthcare system. Quoting from the above-linked article:
Basically, if we could get rid of the incompetent middlemen and businessfolk who've inserted themselves in the way of actually providing healthcare, we'd have enough money to insure everyone in the country who's currently left out or underinsured.The problem is not Universal Healthcare or lack of money.