Yeah, but you'll notice there are bajillions of people living in Missouri or Alaska. Most people are fairly smart, at least smart enough not to live by choice directly on a major geologic fault line (or in a city below sea level on a coastline known for hurricanes, or in an arctic wasteland, etc).
I have very little sympathy for people who lose it all in New Orleans Hurricanes or California Earthquakes, and I don't feel any desire at all to open up my pocketbooks to help bail you guys out of trouble either.
Unexpected and extremely rare natural and manmade disasters can and will happen just about anywhere, and I'm all for aid in those situations. But don't build (or live in) a city like New Orleans (or the population centers along the major CA faults), and pretend like you didn't know this shit was coming and beg for help when it does. All the rest of us knew better and made the wise choice not to be there in the first place.
A *really* ironic thing was on the news Sunday during the pre-hurricane coverage. The reporter was shooting a scene off of a beach off of either Louisiana or Missisippi. Even though the hurricane was still at least 18-24+ hours out, the water was already surging and rolling violently, and the public had been warned to stay out of the water. Yet there were 5-6 dumbass 16-25-ish looking males on *Jetskis* out there playing in it. The reporter pointed out their irresponsible actions, and said something along the lines of, "Folks, listen to the authorities and don't do dumb things like this. You may think it will be fine, but if or when you get in trouble out there, the authorities are going to have to come out and risk their own lives to save you, as well as divert considerable resources from what they have available to deal with everything else they have to do today".
The first thing that came to my mind when I saw that segment was to metaphor-ize that into the population of New Orleans out there on the Jetskis, and my tax-paid resources having to divert their efforts and risk their necks over the stupidity of building a city like that and filling it with people.
I would assume most major telcos already operate mobile emergency telecomms operations. I know when I worked at MCI/Worldcom, they owned similar equipment, which I saw some presentation about, but never got to see in person.
Eighteen-wheelers full of temporary land-line and cellular switching equipment with satellite linkup capability and generators that they would roll out to disaster areas. I'm not sure whether they made any money off of it.
I can only speculate about the money side of it, however I would imagine they don't charge anything at the time when they roll it out, it's more about saving lives at that point. But they may get to charge back some of the operating costs to FEMA or something afterwards, or perhaps state/federal emergency management funds pay them up front to maintain the capability or something.
While it's not a perfect metric, it is very useful for some very important target markets. Some companies crunch numbers continuously for profit. They have datacenters filled with thousands upon thousands of Opterons or Xeons or what-have-you. The battles they are fighting (in terms of maximizing their profits) are all about power/heat density (how many GFlops can I cram into X square feet of datacenter space and still be able to supply the proper power and cooling), and performance per watt (for every $100,000 I spend on electric bills running this datacenter, how many calculations can I complete?).
Where I work, the monthly power bill for the datacenter (power to machines, disk arrays, battery systems, and cooling for the room) is around $30,000. And I know I've seen bigger datacenters - we're just yet another technology-reliant company among thousands upon thousands of others.
I think this AC and the parent are correct, as opposed to the other replies saying it doesn't work.
If I spin a spotlight 360 degrees in one second, and there are no obstructions in the way, and there was a circular wall around me at 13 billion light years out, then 13 billion years later, you would see a gigantic spot of light sweep around the wall at a rate far faster than the speed of light. However, this doesn't violate any physics laws that we know of today, and does not transmit information faster than light in and of itself.
However, there is the potential for doing crazy things with a similar setup and quantum entaglement, I think (IANAP). If the photons being sent out were entangled, and/or some particles on opposite sides of the walls were entangled, you might acheive faster than light communication, if you can plan ahead and afford the "setup" delay ahead of time. I'm not sure on that stuff, I don't know much about it.
It actually is either flamebait or a moron. Anyone with even a passing knowledge of the facts would realize how unneccesarily contentious a point he makes.
Accidents preventable by robotic driving are *not* the primary reason (or even close) for why vehicles can be searched, for starters. The more you unravel the statements he makes, the more asinine they are.
It's a very common trolling/baiting tactic to draw misleading/false conclusions after initially stating a fact that most would agree to (that human error causes accidents).
Regexes do get nasty. They can be broken out onto multiple lines with comments, but then that takes all the fun away. For your enjoyment, here's 3 lovely regexes from some perl code I wrote a few years back. There were for parsing some stuff out of sendmail.cf. Actually sendmail.cf got pre-parsed by some s/// constructs to clean out comments, excess whitespace, etc, before these even touched it, so it could have been even worse:
My singular reason for never using python unless I absolutely have to (which was only once - I needed to interface with a redhat up2date library written in python), is the whitespace thing.
I would imagine if python were the same language it is today, but it ignored whitespace like all other sane languages and instead relied on pairs of paratheses/brackets/whatever and semicolons, I would probably like it. But the whitespace thing just kills me. It seems like such a horrible decision to me. Whitespace should never matter outside of quoted literal strings in source code.
Actually they booted Windows under VMWare under Knoppix from a usb device. What they'd really like to do is just boot Windows from the usb device, but Windows sucks at automatically configuring itself for random machines. So they let linux do all the hardware autoconfig and device drivers, then let VMWare virtualize the network/display/keyboard/mouse up into Windows.
But even then, we still have losses from the transmission lines, losses from stepdown transformers, losses from battery storage, and losses from the (considerable) added battery weight in his car. If he actually calculated real numbers for all of this in his specific situation, he might find that he increased his emissions per mile by 10% and lost his trunk space in the process.
Did you read beyond that first line? I advocated starting with old-school basic, which is even more basic than Visual Basic. I specifically think one should stick to old Basic rather than new Visual Basic to avoid the fact that there are complicated addons like VGL, DirectX, Database access.. not to mention the integrated IDE of sorts. Basic programming should be taught with truly Basic tools, from back in the bronze age of computing.
First, an emulated CDROM can "take over" via autorun on a windows pc. The autorun could launch up some sort of VNC-type remote desktop right back into the device.
But I'm betting they don't even do that. It sound to me like their intent is for the device to appear as a bootable usb cdrom to the host's BIOS, and that you reboot the host with this thing plugged in. The bootable cdrom image boots a native x86 linux kernel with a large set of ethernet, video, audio, usb, etc drivers available to it and the standard 2.6 udev/coldplug/etc hardware autodetection and module autoloading. It uses the storage space on the device as its secure data store, and quite likely communicates directly with the PowerPC linux kernel running in the device as well.
I was thinking about this (from the perspective of what I would do to educate a promising youth with no programming experience who seemed to have a the right mind for it) same sort of topic a while back, and here's what came of it:
First, kill Visual Basic - that's just plain bad.
Also note that you'd need some good emulators or some old-school hardware for some of this (although you might be able to build/find new DOS-era hardware based on Intel's 386EX chip, I think they still make it for little embedded systems, anyways..)
I would start a programming-illiterate person off in plain old BASIC (like, the kind you did in old MS-DOS, or the Apple ][, etc). No Visual anything, no windows, nothing complicated.
Start with "Hello World" and move up from there to the kinds of simplistic text-based applications and games one used to see source code for in 3-2-1 Contact
In parallel, teach them very basic electronics - the kind you'd learn from those old Radio Shack 423in1 electronics kits. Battery, LED, resistor, switch. Move from there to very basic digital logic using TTL or CMOS chips to teach them about the binary system and binary logic, finish it off around the level of making neat little circuits with the logic chips and a 555 timer or something. (They could of course branch out on their own beyond that).
Around the time both of the above are going well, introduce them to PEEK and POKE in BASIC, tell them more about the hardware in the system, show them how to directly manipulate video memory via PEEK/POKE to the mapped video-ram addresses, etc. This transitory phase will go quickly.
Next you step them right on down to early x86 (no more than simple '286 instructions are neccesary, screw protected mode and all that jazz for now) assembly, with a text editor and MASM/TASM. BASIC is no longer useful. Let them learn all over again to write those same little console games/apps in assembler. Get some good books on the subject for reference guides.
Once their assembly code starts getting a little unwieldy and difficult to debug due to complexity, introduce them to better ways to manage their code than BASIC-style linear programming. Show them to organize their assembler code into little libraries of subroutines with standardized calling interfaces, etc. Once they're comfortable, and they're ready to start making even more complex software, but the complexity of doing it all in ASM is slowing them down (But they are using some good functional-style technique)...
Switch them over to C. Show them how C is like platform-neutral assembler that's easier to write and maintain. You might well wean them off of DOS and head straight to Linux for the C part. Stick again to text-console software, no crazy graphics libraries or anything. As they're getting used to C and getting used to the Unix shell in general, touch on unix shellscripting - and later as their C starts getting decent show them perl.
After that, they're pretty much good to go in any language with Google and/or the O'reilly section of their local bookstore at their side.
I think part of the natural advantage programmers of my era have (~30 years old now) is that we grew through a lot of these stages naturally as they evolved around us in popular geek culture (if that's not an oxymoron). More recent guys are in some ways crippled by not having the benefit of going through these stages sans modern amenities and languages.
Well, actually I didn't read the linked FA yet, but I read about this same thing elsewhere a few days ago. They said the chances of two peices of the same kind of paper have the same signature were 1:1000. Two reams of paper and you're in (or 1,000 peices of passport plastic, or whatever). Hardly an effort considering the documents they're considering using it on. Unless they can bump that number into the billions or more, it's pointless because it's too easy to manufacture a duplicate of any given document that has an identical fingerprint just by brute force.
I went and looked at one box here, a SuSE 9.2 one, and it looks like the timezone definitions do ultimately come from the glibc sources, but SuSE has split them off into a seperate rpm package called "timezone".
I can't wait to see what we're going to do with the unsupported HPUX 10.0 box in the corner that hasn't been patched in years:)
The gadgets will be the least of our worries. For a whole lot of computers out there, this will be like a mini-Y2K. The upshot is the error is 1 hour instead of 100 years, but the downside is that virtually all computers that bother to know what a timezone is are affected, as opposed to just systems with sloppy programmers who used 2-year digits.
Sure, your whole datacenter may be NTP-synced, and therefore your datacenter's UTC time will stay correct, but any application or user asking for the current local time will get a wrong answer during the extension periods, until a system update is applied which updates the daylight savings definitions.
In the case of a Linux machine, this probably means a glibc update, although I haven't actually gone and looked to be sure who owns the timezone files.
But there's a lot of unix (and other) machines out there in the world who haven't updated their timezone data in years, and have no plan to. Good luck getting everyone smoothly upgraded before this takes effect.
The world is not that black and white, at least not to me. Anyone who would even turn in a random stranger over your 50 cent candy bar is a plain asshole in my book.
To some degree I think this hinges on what definition of friend we're talking about. For "just a friend" - some guy I met at work and don't hang out with much and don't honestly care that much about, I would probably turn on them even in a simple case like this one (~$500 retail theft), just like the video card guy did, but if it was under $100, I probably wouldn't do crap.
For a decent friend that I have some history with, I would probably ignore any "victimless" crime (monetary crime against a corporation), although I might well never speak to them again if I strongly disagreed with their actions. I would only turn on them and turn them in if something personal happened to an individual (theft/vandalism of valuable personal property, assault, murder, any sex crime, etc).
For a "real" friend - someone I would trust my life with, those rare few you have in your life, my response would entirely depend on the situation and context. Again, I might never speak to the person afterwards, but there are limits on what I would turn them in for. I would always still turn on them over a crime against a child, or rape, or senseless murder of an innocent. Anything less, possibly including intentional homicide of someone for a specific reason, I might well keep my mouth shut, depending on the circumstances - whether I agreed with his actions or not.
They should implement this automatically as a part of the page versioning system. Leave editing the way it is now, and don't implement "locks" per se. Flag the latest version of everything right now as "stable". When someone makes an edit, the article bumps to a new version, but the stable flag stays where it is. When the article has gone un-edited for some period (say around 5-10 days?), then the "stable" flag is moved up to the new latest version again.
By default, people browsing wikipedia articles should see only the "stable" version. But for those who prefer to read the "raw" version, or who are editing, they can switch to "raw" mode (a preference) and instead see wikipedia like they do today.
And when viewing an individual article, if there are changes pending that are newer than stable, you could put a link on the page indicating "A newer revision of this article is available, but it is not yet considered stable and may contain unreviewed content" with a link to the latest.
This would allow editing to happen as it always has, and if anyone makes a controversial or vandalous change, there is a window of X days for editors to notice it and correct it before it becomes stable. So long as the changes keep bouncing due to repeat vandalism, the vandal's content never makes it to "stable". Since this doesn't accomplish much, they're unlikely to even engaged in repeat-vandalism editing on the same page (edit wars).
What it does leave open is the possibility that someone will try to stealthily put in some vandalism and hope nobody notices for X days until it becomes stable - but there are lots of good people out there who watch the global list of the latest changes like hawks looking for this stuff, so it should get caught before it becomes stable. ALl they have to do to head it off is to edit the article back, which essentially resets the stable timer.
No amount of mincing words covers up the fact that the exploit (which was demo'd on a live Cisco router) can be done in the wild, and customers were not worried about it and not patching even with the old patch, because nobody was keeping the customers informed of this serious issue.
What was at stake here was whether it's ok for Cisco to hide security flaws in products the world trusts.
I'm with you. I just started at a new place that does Lotus Notes about 8 months ago. Not just email - they do *everything* in Notes. Project management, AFEs, knowledge base, etc, etc. I hate it.
The UI is unspeakably horrid. And it randomly hangs or crashes if you don't click the buttons they expected you to click in the order they expected you to click them in.
Want to open up Notes and open your Inbox with 1,000 messages in it? On a P4 with half a gig of ram, you'll be swap-thrashing for about 3 solid minutes before you get there.
Want to delete the 8,243 emails that some monitoring application spammed you with over the weekend while you were out? Good luck figuring out how to select only those emails and not the rest efficiently. And when you finally do get them selected, hit Delete and go to lunch. Notes may or may not have crashed and/or deleted your emails by the time you get back, but you definitely won't be using it for a while.
Do they have any idea how much money that is? I'm all for it - we could probably eliminate all other taxes the government collects and still double the budget.
I hate to break it to you, but even though today is Saturday, it is in fact Sunday somewhere while it is Saturday for you, under the current system. Under the proposal by the grandparent, it would be 13:00 Saturday everywhere in the world at the same time - but you probably wouldn't use an obsolete term like Saturday, and half the world would be asleep. As far as locality of time reference, I would imagine that for mundane traditional purposes we would re-purpose traditional words like "morning, noon, afternoon, evening", etc to mean relative to the sun where-ever you are. And when you want to speak with more precision than simple sun-terms like that, you specify "13:42", which only has sun-relevance in your own local area, but means the same instant in time everywhere.
The very reason these bugs cropped up is because the software in question was not written to account for leap seconds like it should have been. Yet they want to screw with Daylight Savings Time, which will cause a similar (but worse - twice a year and with an entire hour of error) problems for every system which is not updated/rewritten to match the new standard....
Slashdot Mirror
Yeah, but you'll notice there are bajillions of people living in Missouri or Alaska. Most people are fairly smart, at least smart enough not to live by choice directly on a major geologic fault line (or in a city below sea level on a coastline known for hurricanes, or in an arctic wasteland, etc).
I have very little sympathy for people who lose it all in New Orleans Hurricanes or California Earthquakes, and I don't feel any desire at all to open up my pocketbooks to help bail you guys out of trouble either.
Unexpected and extremely rare natural and manmade disasters can and will happen just about anywhere, and I'm all for aid in those situations. But don't build (or live in) a city like New Orleans (or the population centers along the major CA faults), and pretend like you didn't know this shit was coming and beg for help when it does. All the rest of us knew better and made the wise choice not to be there in the first place.
A *really* ironic thing was on the news Sunday during the pre-hurricane coverage. The reporter was shooting a scene off of a beach off of either Louisiana or Missisippi. Even though the hurricane was still at least 18-24+ hours out, the water was already surging and rolling violently, and the public had been warned to stay out of the water. Yet there were 5-6 dumbass 16-25-ish looking males on *Jetskis* out there playing in it. The reporter pointed out their irresponsible actions, and said something along the lines of, "Folks, listen to the authorities and don't do dumb things like this. You may think it will be fine, but if or when you get in trouble out there, the authorities are going to have to come out and risk their own lives to save you, as well as divert considerable resources from what they have available to deal with everything else they have to do today".
The first thing that came to my mind when I saw that segment was to metaphor-ize that into the population of New Orleans out there on the Jetskis, and my tax-paid resources having to divert their efforts and risk their necks over the stupidity of building a city like that and filling it with people.
I would assume most major telcos already operate mobile emergency telecomms operations. I know when I worked at MCI/Worldcom, they owned similar equipment, which I saw some presentation about, but never got to see in person.
Eighteen-wheelers full of temporary land-line and cellular switching equipment with satellite linkup capability and generators that they would roll out to disaster areas. I'm not sure whether they made any money off of it.
I can only speculate about the money side of it, however I would imagine they don't charge anything at the time when they roll it out, it's more about saving lives at that point. But they may get to charge back some of the operating costs to FEMA or something afterwards, or perhaps state/federal emergency management funds pay them up front to maintain the capability or something.
While it's not a perfect metric, it is very useful for some very important target markets. Some companies crunch numbers continuously for profit. They have datacenters filled with thousands upon thousands of Opterons or Xeons or what-have-you. The battles they are fighting (in terms of maximizing their profits) are all about power/heat density (how many GFlops can I cram into X square feet of datacenter space and still be able to supply the proper power and cooling), and performance per watt (for every $100,000 I spend on electric bills running this datacenter, how many calculations can I complete?).
Where I work, the monthly power bill for the datacenter (power to machines, disk arrays, battery systems, and cooling for the room) is around $30,000. And I know I've seen bigger datacenters - we're just yet another technology-reliant company among thousands upon thousands of others.
I think this AC and the parent are correct, as opposed to the other replies saying it doesn't work.
If I spin a spotlight 360 degrees in one second, and there are no obstructions in the way, and there was a circular wall around me at 13 billion light years out, then 13 billion years later, you would see a gigantic spot of light sweep around the wall at a rate far faster than the speed of light. However, this doesn't violate any physics laws that we know of today, and does not transmit information faster than light in and of itself.
However, there is the potential for doing crazy things with a similar setup and quantum entaglement, I think (IANAP). If the photons being sent out were entangled, and/or some particles on opposite sides of the walls were entangled, you might acheive faster than light communication, if you can plan ahead and afford the "setup" delay ahead of time. I'm not sure on that stuff, I don't know much about it.
It actually is either flamebait or a moron. Anyone with even a passing knowledge of the facts would realize how unneccesarily contentious a point he makes.
Accidents preventable by robotic driving are *not* the primary reason (or even close) for why vehicles can be searched, for starters. The more you unravel the statements he makes, the more asinine they are.
It's a very common trolling/baiting tactic to draw misleading/false conclusions after initially stating a fact that most would agree to (that human error causes accidents).
Regexes do get nasty. They can be broken out onto multiple lines with comments, but then that takes all the fun away. For your enjoyment, here's 3 lovely regexes from some perl code I wrote a few years back. There were for parsing some stuff out of sendmail.cf. Actually sendmail.cf got pre-parsed by some s/// constructs to clean out comments, excess whitespace, etc, before these even touched it, so it could have been even worse:
My singular reason for never using python unless I absolutely have to (which was only once - I needed to interface with a redhat up2date library written in python), is the whitespace thing.
I would imagine if python were the same language it is today, but it ignored whitespace like all other sane languages and instead relied on pairs of paratheses/brackets/whatever and semicolons, I would probably like it. But the whitespace thing just kills me. It seems like such a horrible decision to me. Whitespace should never matter outside of quoted literal strings in source code.
Actually they booted Windows under VMWare under Knoppix from a usb device. What they'd really like to do is just boot Windows from the usb device, but Windows sucks at automatically configuring itself for random machines. So they let linux do all the hardware autoconfig and device drivers, then let VMWare virtualize the network/display/keyboard/mouse up into Windows.
But even then, we still have losses from the transmission lines, losses from stepdown transformers, losses from battery storage, and losses from the (considerable) added battery weight in his car. If he actually calculated real numbers for all of this in his specific situation, he might find that he increased his emissions per mile by 10% and lost his trunk space in the process.
The departments in question do not care about monopolies, non-Windows users, closed source expenses, etc.
Perhaps they should start caring about the expenses. It's our damn tax dollars they're blowing.
Did you read beyond that first line? I advocated starting with old-school basic, which is even more basic than Visual Basic. I specifically think one should stick to old Basic rather than new Visual Basic to avoid the fact that there are complicated addons like VGL, DirectX, Database access.. not to mention the integrated IDE of sorts. Basic programming should be taught with truly Basic tools, from back in the bronze age of computing.
First, an emulated CDROM can "take over" via autorun on a windows pc. The autorun could launch up some sort of VNC-type remote desktop right back into the device.
But I'm betting they don't even do that. It sound to me like their intent is for the device to appear as a bootable usb cdrom to the host's BIOS, and that you reboot the host with this thing plugged in. The bootable cdrom image boots a native x86 linux kernel with a large set of ethernet, video, audio, usb, etc drivers available to it and the standard 2.6 udev/coldplug/etc hardware autodetection and module autoloading. It uses the storage space on the device as its secure data store, and quite likely communicates directly with the PowerPC linux kernel running in the device as well.
I was thinking about this (from the perspective of what I would do to educate a promising youth with no programming experience who seemed to have a the right mind for it) same sort of topic a while back, and here's what came of it:
First, kill Visual Basic - that's just plain bad.
Also note that you'd need some good emulators or some old-school hardware for some of this (although you might be able to build/find new DOS-era hardware based on Intel's 386EX chip, I think they still make it for little embedded systems, anyways..)
I would start a programming-illiterate person off in plain old BASIC (like, the kind you did in old MS-DOS, or the Apple ][, etc). No Visual anything, no windows, nothing complicated.
Start with "Hello World" and move up from there to the kinds of simplistic text-based applications and games one used to see source code for in 3-2-1 Contact
In parallel, teach them very basic electronics - the kind you'd learn from those old Radio Shack 423in1 electronics kits. Battery, LED, resistor, switch. Move from there to very basic digital logic using TTL or CMOS chips to teach them about the binary system and binary logic, finish it off around the level of making neat little circuits with the logic chips and a 555 timer or something. (They could of course branch out on their own beyond that).
Around the time both of the above are going well, introduce them to PEEK and POKE in BASIC, tell them more about the hardware in the system, show them how to directly manipulate video memory via PEEK/POKE to the mapped video-ram addresses, etc. This transitory phase will go quickly.
Next you step them right on down to early x86 (no more than simple '286 instructions are neccesary, screw protected mode and all that jazz for now) assembly, with a text editor and MASM/TASM. BASIC is no longer useful. Let them learn all over again to write those same little console games/apps in assembler. Get some good books on the subject for reference guides.
Once their assembly code starts getting a little unwieldy and difficult to debug due to complexity, introduce them to better ways to manage their code than BASIC-style linear programming. Show them to organize their assembler code into little libraries of subroutines with standardized calling interfaces, etc. Once they're comfortable, and they're ready to start making even more complex software, but the complexity of doing it all in ASM is slowing them down (But they are using some good functional-style technique)...
Switch them over to C. Show them how C is like platform-neutral assembler that's easier to write and maintain. You might well wean them off of DOS and head straight to Linux for the C part. Stick again to text-console software, no crazy graphics libraries or anything. As they're getting used to C and getting used to the Unix shell in general, touch on unix shellscripting - and later as their C starts getting decent show them perl.
After that, they're pretty much good to go in any language with Google and/or the O'reilly section of their local bookstore at their side.
I think part of the natural advantage programmers of my era have (~30 years old now) is that we grew through a lot of these stages naturally as they evolved around us in popular geek culture (if that's not an oxymoron). More recent guys are in some ways crippled by not having the benefit of going through these stages sans modern amenities and languages.
Well, actually I didn't read the linked FA yet, but I read about this same thing elsewhere a few days ago. They said the chances of two peices of the same kind of paper have the same signature were 1:1000. Two reams of paper and you're in (or 1,000 peices of passport plastic, or whatever). Hardly an effort considering the documents they're considering using it on. Unless they can bump that number into the billions or more, it's pointless because it's too easy to manufacture a duplicate of any given document that has an identical fingerprint just by brute force.
I went and looked at one box here, a SuSE 9.2 one, and it looks like the timezone definitions do ultimately come from the glibc sources, but SuSE has split them off into a seperate rpm package called "timezone".
I can't wait to see what we're going to do with the unsupported HPUX 10.0 box in the corner that hasn't been patched in years
The gadgets will be the least of our worries. For a whole lot of computers out there, this will be like a mini-Y2K. The upshot is the error is 1 hour instead of 100 years, but the downside is that virtually all computers that bother to know what a timezone is are affected, as opposed to just systems with sloppy programmers who used 2-year digits.
Sure, your whole datacenter may be NTP-synced, and therefore your datacenter's UTC time will stay correct, but any application or user asking for the current local time will get a wrong answer during the extension periods, until a system update is applied which updates the daylight savings definitions.
In the case of a Linux machine, this probably means a glibc update, although I haven't actually gone and looked to be sure who owns the timezone files.
But there's a lot of unix (and other) machines out there in the world who haven't updated their timezone data in years, and have no plan to. Good luck getting everyone smoothly upgraded before this takes effect.
The world is not that black and white, at least not to me. Anyone who would even turn in a random stranger over your 50 cent candy bar is a plain asshole in my book.
To some degree I think this hinges on what definition of friend we're talking about. For "just a friend" - some guy I met at work and don't hang out with much and don't honestly care that much about, I would probably turn on them even in a simple case like this one (~$500 retail theft), just like the video card guy did, but if it was under $100, I probably wouldn't do crap.
For a decent friend that I have some history with, I would probably ignore any "victimless" crime (monetary crime against a corporation), although I might well never speak to them again if I strongly disagreed with their actions. I would only turn on them and turn them in if something personal happened to an individual (theft/vandalism of valuable personal property, assault, murder, any sex crime, etc).
For a "real" friend - someone I would trust my life with, those rare few you have in your life, my response would entirely depend on the situation and context. Again, I might never speak to the person afterwards, but there are limits on what I would turn them in for. I would always still turn on them over a crime against a child, or rape, or senseless murder of an innocent. Anything less, possibly including intentional homicide of someone for a specific reason, I might well keep my mouth shut, depending on the circumstances - whether I agreed with his actions or not.
They should implement this automatically as a part of the page versioning system. Leave editing the way it is now, and don't implement "locks" per se. Flag the latest version of everything right now as "stable". When someone makes an edit, the article bumps to a new version, but the stable flag stays where it is. When the article has gone un-edited for some period (say around 5-10 days?), then the "stable" flag is moved up to the new latest version again.
By default, people browsing wikipedia articles should see only the "stable" version. But for those who prefer to read the "raw" version, or who are editing, they can switch to "raw" mode (a preference) and instead see wikipedia like they do today.
And when viewing an individual article, if there are changes pending that are newer than stable, you could put a link on the page indicating "A newer revision of this article is available, but it is not yet considered stable and may contain unreviewed content" with a link to the latest.
This would allow editing to happen as it always has, and if anyone makes a controversial or vandalous change, there is a window of X days for editors to notice it and correct it before it becomes stable. So long as the changes keep bouncing due to repeat vandalism, the vandal's content never makes it to "stable". Since this doesn't accomplish much, they're unlikely to even engaged in repeat-vandalism editing on the same page (edit wars).
What it does leave open is the possibility that someone will try to stealthily put in some vandalism and hope nobody notices for X days until it becomes stable - but there are lots of good people out there who watch the global list of the latest changes like hawks looking for this stuff, so it should get caught before it becomes stable. ALl they have to do to head it off is to edit the article back, which essentially resets the stable timer.
No amount of mincing words covers up the fact that the exploit (which was demo'd on a live Cisco router) can be done in the wild, and customers were not worried about it and not patching even with the old patch, because nobody was keeping the customers informed of this serious issue.
What was at stake here was whether it's ok for Cisco to hide security flaws in products the world trusts.
I'm with you. I just started at a new place that does Lotus Notes about 8 months ago. Not just email - they do *everything* in Notes. Project management, AFEs, knowledge base, etc, etc. I hate it.
The UI is unspeakably horrid. And it randomly hangs or crashes if you don't click the buttons they expected you to click in the order they expected you to click them in.
Want to open up Notes and open your Inbox with 1,000 messages in it? On a P4 with half a gig of ram, you'll be swap-thrashing for about 3 solid minutes before you get there.
Want to delete the 8,243 emails that some monitoring application spammed you with over the weekend while you were out? Good luck figuring out how to select only those emails and not the rest efficiently. And when you finally do get them selected, hit Delete and go to lunch. Notes may or may not have crashed and/or deleted your emails by the time you get back, but you definitely won't be using it for a while.
ARGGHGHGHHHH!!!!
Do they have any idea how much money that is? I'm all for it - we could probably eliminate all other taxes the government collects and still double the budget.
I hate to break it to you, but even though today is Saturday, it is in fact Sunday somewhere while it is Saturday for you, under the current system. Under the proposal by the grandparent, it would be 13:00 Saturday everywhere in the world at the same time - but you probably wouldn't use an obsolete term like Saturday, and half the world would be asleep. As far as locality of time reference, I would imagine that for mundane traditional purposes we would re-purpose traditional words like "morning, noon, afternoon, evening", etc to mean relative to the sun where-ever you are. And when you want to speak with more precision than simple sun-terms like that, you specify "13:42", which only has sun-relevance in your own local area, but means the same instant in time everywhere.
The very reason these bugs cropped up is because the software in question was not written to account for leap seconds like it should have been. Yet they want to screw with Daylight Savings Time, which will cause a similar (but worse - twice a year and with an entire hour of error) problems for every system which is not updated/rewritten to match the new standard....
Yeah, but that's just Minnesota. There's what, like 3 people with slow satellite porn links there?