Actual laws vary from state to state, but some states (like California) actually suggest riding closer to the center of the lane when there isn't a separate bicycle lane and the traffic lane isn't wide enough for a car to safely pass. From the California DMV website:
Many roads do not have designated bicycle traffic lanes, so bicyclists share the traffic lane to the left of the white line. If there is no shoulder or bicycle lane and the traffic lane is narrow, ride closer to the center of the lane. This will prevent motorists from passing you when there is not enough room.
There's more extensive details in the formal traffic code as well. Of course this probably varies from state to state (California law also indicates that a car can only pass a bicycle if it can give three feet of room, so "enough room" is at least well-defined); don't assume the same expectations applies elsewhere without checking first.
I do agree that there are a lot of idiots on bikes out there doing really stupid/dangerous things (biking the wrong direction in bike lanes, biking at night without lights, etc.) and a surprising amount of the time it's because they never bothered to learn the part of the traffic code that deals with bicycles. We only let people drive cars and motorcycles on roads if they pass a test and earn a license . . . it seems like we really need similar requirements for anyone operating a bicycle on on public roads as well. It certainly wouldn't eliminate all of the idiots who shouldn't be on a bike (just as DMV tests today don't eliminate all of the idiot drivers), but it would hopefully help.
This is true to an extent, but keep in mind that most modern apps you run on Linux aren't "X apps" or "Wayland apps" but rather "{insert toolkit here} apps" that are written completely in something like QT or GTK and never make any direct calls into the X11 or Wayland API's. The same app can often run on both X and Wayland without modification as long as it's built with a toolkit that has both Wayland and X backends.
It's certainly possible to write pure GL + wayland (or shm + wayland) apps without using a toolkit, so your concern is valid there, but apps of this form probably won't be very common (the most likely cases will be things like 3d games and such that don't need a toolkit, but those aren't the kind of apps you'd be running with indirect rendering on X anyway).
As always, those of you who whine about Debian being out of date have probably never looked at the packages available in unstable and testing.
I think most of us that actually run Debian use testing or unstable, so we're not the ones complaining. I think most of the complaints come from people who try to switch to Debian, but then find that the kernels on the official CD images are too old to support their hardware (e.g., doesn't recognize their network card). Granted, there are other ways of installing Debian (knoppix, anaconda, sarge install images, etc.), but unfortunately people trying to install Debian for the first time often aren't aware of these. I think that's the real source of the "out of date" complaints we hear so often.
I, personally, set up a 'backup MX' record to point at one of my IPs that didn't actually run a mail server, and cut my daily spam attempts by 30%.
And you probably dropped the reachability of legitimate mail too. I'm sure that works well in your little playground, but this is a real environment and we have SLA's to honor.
Actually, using an unreachable backup MX is an excellent idea and shouldn't affect legitimate email at all. Real mail servers (i.e., servers running software like sendmail, postfix, exim, etc.) will try to deliver a message to each MX server, from high priority to low priority, until they find one that is accessible. So if he sets up a bogus MX server at the lowest priority, all of his other MX servers will still be attempted (and if they're all down for some reason, he's screwed anyway). However, spammers often use custom mass-mailing software that isn't smart enough to try all MX servers. In fact, their software seems to specifically target the lowest priority MX servers, probably because they think these servers will be less likely to inspect and reject the message at SMTP time. So if your lowest priority MX server is bogus and doesn't really exist, spammer software might not be smart enough to actually try the other MX servers; it will give up and move on to the next victim.
So using this technique shouldn't affect legitimate email, but it stands a good chance of cutting down on some spam. I'm glad he posted it.
"...that software will not be written but visually designed"
This brings to mind the scene in the movie Swordfish where the main character creates a computer virus by just moving spinning blocks around the computer screen. The sad thing is that after watching that scene, several of my non-geek friends thought that was how software is actually created...
Hmm. Just out of curiosity, does this ever cause a problem if you have to login remotely from a system with a different style keyboard than you're used to? (e.g. split vs non-split, laptop vs desktop, etc.)
Actually, the FirebirdSQL could back down pretty easily now. They gained an enormous boost to name recognition simply by raising this issue in the first place -- before this all started they weren't nearly as well known as the "big" open source databases (MySQL and postgres). Now so much information has been posted on Slashdot and other news sites about this that pretty much any geek who knows how to use a database has probably heard of them. If they back down now, they keep the name recognition. They've won no matter how it turns out.
I can't seem to access the article, so I'm not sure whether it addresses this, but it seems to me that the type of vulnerabilities discovered would be an important factor in determining how secure each OS is. Obviously remote exploits are more serious than local exploits. Likewise, the amount of privileges gained through each exploit should also play a role (i.e. does the exploit give administrator/root privileges or just guest/nobody power?) I'm not saying that the conclusion of the article is right or wrong, I'm just saying there's more to an OS's security than number of vulnerabilities.
Of course it's worth noting that the security of an operating system doesn't necessarily reflect the security of the systems using it. System security is an ongoing process that requires human intervention; if a sys admin is lazy and doesn't install patches then his system will be insecure regardless of which OS he uses.
If that means that he has to buy a *nix and get someone to write a compatibility layer and it takes 5 years, do you think that will stop him?
...
Be afraid. The result will be closed source (unless he really cant find a closed source way to do it - in which case he will go open), and it will be secure, and it won't happen in 2002. But it will happen. (It may even be a better thing for the average user - but if you were that you wouldn't be reading this now?)
I don't see why this would be a bad thing... As you point out, this would probably be a good thing good thing for the average user, but I think it would also be a good thing for the rest of us too. Security problems in MS products don't "help" the open source movement; even people using Linux/BSD/whatever still get affected when things like CodeRed come along and pound our web servers or when insecure Windows PC's are used for DDoS attacks. Enhanced security is always a good thing, even if it is in a product that you don't directly use.
Furthermore, if Microsoft did buy a *nix and write a compatibility layer on top of it, I suspect that it would be easier to port programs between the new MS OS and existing open source operating systems. Open Source operating systems might actually become serious alternatives to MS in the eyes of your average home user.
The discovery (if validated) is said to be good news for string theorists.
I bet all the poor college students with a modern physics course requirement aren't going to see it as good news when their midterm calculations start getting even more complex than they were before...
But remember, the last time it struck, it grew exponentially for 7 days until it really hit its stride.
Of course last month, Code Red started with just a few infected machines and built up to some incredible number. At the beginning of this month, Code Red is supposed to start out with about 200,000 existing infected, unpatched machines and grow from there.
The problem is, no matter how much this worm gets hyped up, there are going to be a lot of people out there that still don't patch their machines, either because they don't realize they are running a web server (e.g. home users running Windows NT/2000 on a DSL or cable connection) or because the web server is no longer actively used and has been forgotten.
"If customers do not renew or install an upgrade product, they can still open, view and print their existing documents."
I think Microsoft will have to do a lot more to cripple expired versions of Office than just taking away the "New Document" feature if they actually want to make money off of this subscription idea. I can see a lot of people buying the subscription version at the cheaper price and then continuing to use it after it expires. All people need to do to beat the system is keep a copy of a blank document on their hard drive. Then whenever they want to start a new document, they just make a copy of the blank one instead of using MS's builtin "New" command. If I recall correctly, the Windows operating system even has a feature builtin that would make this very easy (right-click -> new -> whatever).
Slashdot Mirror
Actual laws vary from state to state, but some states (like California) actually suggest riding closer to the center of the lane when there isn't a separate bicycle lane and the traffic lane isn't wide enough for a car to safely pass. From the California DMV website:
Many roads do not have designated bicycle traffic lanes, so bicyclists share the traffic lane to the left of the white line. If there is no shoulder or bicycle lane and the traffic lane is narrow, ride closer to the center of the lane. This will prevent motorists from passing you when there is not enough room.
There's more extensive details in the formal traffic code as well. Of course this probably varies from state to state (California law also indicates that a car can only pass a bicycle if it can give three feet of room, so "enough room" is at least well-defined); don't assume the same expectations applies elsewhere without checking first.
I do agree that there are a lot of idiots on bikes out there doing really stupid/dangerous things (biking the wrong direction in bike lanes, biking at night without lights, etc.) and a surprising amount of the time it's because they never bothered to learn the part of the traffic code that deals with bicycles. We only let people drive cars and motorcycles on roads if they pass a test and earn a license . . . it seems like we really need similar requirements for anyone operating a bicycle on on public roads as well. It certainly wouldn't eliminate all of the idiots who shouldn't be on a bike (just as DMV tests today don't eliminate all of the idiot drivers), but it would hopefully help.
This is true to an extent, but keep in mind that most modern apps you run on Linux aren't "X apps" or "Wayland apps" but rather "{insert toolkit here} apps" that are written completely in something like QT or GTK and never make any direct calls into the X11 or Wayland API's. The same app can often run on both X and Wayland without modification as long as it's built with a toolkit that has both Wayland and X backends.
It's certainly possible to write pure GL + wayland (or shm + wayland) apps without using a toolkit, so your concern is valid there, but apps of this form probably won't be very common (the most likely cases will be things like 3d games and such that don't need a toolkit, but those aren't the kind of apps you'd be running with indirect rendering on X anyway).
As always, those of you who whine about Debian being out of date have probably never looked at the packages available in unstable and testing.
I think most of us that actually run Debian use testing or unstable, so we're not the ones complaining. I think most of the complaints come from people who try to switch to Debian, but then find that the kernels on the official CD images are too old to support their hardware (e.g., doesn't recognize their network card). Granted, there are other ways of installing Debian (knoppix, anaconda, sarge install images, etc.), but unfortunately people trying to install Debian for the first time often aren't aware of these. I think that's the real source of the "out of date" complaints we hear so often.
Actually, using an unreachable backup MX is an excellent idea and shouldn't affect legitimate email at all. Real mail servers (i.e., servers running software like sendmail, postfix, exim, etc.) will try to deliver a message to each MX server, from high priority to low priority, until they find one that is accessible. So if he sets up a bogus MX server at the lowest priority, all of his other MX servers will still be attempted (and if they're all down for some reason, he's screwed anyway). However, spammers often use custom mass-mailing software that isn't smart enough to try all MX servers. In fact, their software seems to specifically target the lowest priority MX servers, probably because they think these servers will be less likely to inspect and reject the message at SMTP time. So if your lowest priority MX server is bogus and doesn't really exist, spammer software might not be smart enough to actually try the other MX servers; it will give up and move on to the next victim.
So using this technique shouldn't affect legitimate email, but it stands a good chance of cutting down on some spam. I'm glad he posted it.
"...that software will not be written but visually designed"
This brings to mind the scene in the movie Swordfish where the main character creates a computer virus by just moving spinning blocks around the computer screen. The sad thing is that after watching that scene, several of my non-geek friends thought that was how software is actually created...
Hmm. Just out of curiosity, does this ever cause a problem if you have to login remotely from a system with a different style keyboard than you're used to? (e.g. split vs non-split, laptop vs desktop, etc.)
Actually, the FirebirdSQL could back down pretty easily now. They gained an enormous boost to name recognition simply by raising this issue in the first place -- before this all started they weren't nearly as well known as the "big" open source databases (MySQL and postgres). Now so much information has been posted on Slashdot and other news sites about this that pretty much any geek who knows how to use a database has probably heard of them. If they back down now, they keep the name recognition. They've won no matter how it turns out.
I can't seem to access the article, so I'm not sure whether it addresses this, but it seems to me that the type of vulnerabilities discovered would be an important factor in determining how secure each OS is. Obviously remote exploits are more serious than local exploits. Likewise, the amount of privileges gained through each exploit should also play a role (i.e. does the exploit give administrator/root privileges or just guest/nobody power?) I'm not saying that the conclusion of the article is right or wrong, I'm just saying there's more to an OS's security than number of vulnerabilities.
Of course it's worth noting that the security of an operating system doesn't necessarily reflect the security of the systems using it. System security is an ongoing process that requires human intervention; if a sys admin is lazy and doesn't install patches then his system will be insecure regardless of which OS he uses.
If that means that he has to buy a *nix and get someone to write a compatibility layer and it takes 5 years, do you think that will stop him?
...
Be afraid. The result will be closed source (unless he really cant find a closed source way to do it - in which case he will go open), and it will be secure, and it won't happen in 2002. But it will happen. (It may even be a better thing for the average user - but if you were that you wouldn't be reading this now?)
I don't see why this would be a bad thing... As you point out, this would probably be a good thing good thing for the average user, but I think it would also be a good thing for the rest of us too. Security problems in MS products don't "help" the open source movement; even people using Linux/BSD/whatever still get affected when things like CodeRed come along and pound our web servers or when insecure Windows PC's are used for DDoS attacks. Enhanced security is always a good thing, even if it is in a product that you don't directly use.
Furthermore, if Microsoft did buy a *nix and write a compatibility layer on top of it, I suspect that it would be easier to port programs between the new MS OS and existing open source operating systems. Open Source operating systems might actually become serious alternatives to MS in the eyes of your average home user.
Darn. Posted this as soon as I read the line and didn't see that it was mentioned right at the end of the article. Oh well.
"Steve Wasko, Microsoft's Linux Competitive Manager, said that Microsoft is not very concerned about any competitive threat from WINE ... or Linux."
If they're not concerned about any competitive threat from Linux, then why do they have a position called "Linux Competitive Manager?"
The discovery (if validated) is said to be good news for string theorists.
I bet all the poor college students with a modern physics course requirement aren't going to see it as good news when their midterm calculations start getting even more complex than they were before...
But remember, the last time it struck, it grew exponentially for 7 days until it really hit its stride.
Of course last month, Code Red started with just a few infected machines and built up to some incredible number. At the beginning of this month, Code Red is supposed to start out with about 200,000 existing infected, unpatched machines and grow from there.
The problem is, no matter how much this worm gets hyped up, there are going to be a lot of people out there that still don't patch their machines, either because they don't realize they are running a web server (e.g. home users running Windows NT/2000 on a DSL or cable connection) or because the web server is no longer actively used and has been forgotten.