I consider this hacking group no more than simple vandals and criminals at this stage. There is no "honour" in it, and exposing porn clients are extremely likely to be hypocritical. I don't believe for a second that all members of this hacker group has a "clean conscience" about porn.
I don't have any opinion on the motivations of Lulzsec. I'm more concerned about what happens now.
Try not to think of "Lulzsec, the annoying and dangerous cracking group, just busted open a porn site. How evil of them."
Think of "A goddamn porn site was compromised. What does that tell of the security in adult industry? What does that tell to the victims?"
In short, it's irrelevant who cracked them. The milk's on the floor, too late to cry.
Someone pointed out that Lulzsec is definitely doing a good job at pointing out security flaws that should be addressed. Why did a porn site have such lax security? Why is a porn site storing passwords in cleartext? Aren't they aware that quite a few of their members might not appreciate being advertised as members? Should people be more concerned about the security in porn sites? Not everybody minds being advertised as a member of a porn site, but since a lot of people obviously have a problem with that, should the porn sites provide additional security measures for people who are embarrassed to admit this stuff publicly? (e.g. not store details that might identify them, such as email)
I'm now selling my poo as a currency. Like bit coin it can only be mined at a steady rate so it can't be manipulated. My Poo is marked with my DNA so it can't be forged for less than it costs to make. It's Natural, and a work of Man. Now rather than transport it to you in all it's glory, I have established a Poo Reserve.
But your system assumes that you will be personally present at the Poo Reserve at all times. It hinges on our trust that the Poo will always be either collected by the Reserve or destroyed according to a secure standard operating procedure. As the brilliant Chinese strategist Sun Tzu said, "a man's gotta go when a man's gotta go". The Poo deposits may occur at weird, unpredictable times. What assurances do we get that there are absolutely no out-of-record deposits and all deposits occur at exactly specified manner? What if 100% genuine, DNA-verified Poo, which is not used for backing poocoin and shouldn't officially even exist, ends up in a place where it can be collected by the black market? Or the terrorists? Or the terrorists who run the black market?
Now, you may be thinking, "surely everyone can collect Poo! You don't need to be a specialist! We all handle Poo every day!", but secure collection of Poo is a surprisingly complicated matter, which is best left to the experts. What passes for everyday handling may not be enough when there's money in the line. Just goes to show that you shouldn't design a new currency if even a non-expert like me can see big fatal flaws in the system!
Further, our yielding to such [outrageous] demands could mark the beginning of a torrent of similar requests from governments around the globe, disrupting our current efficient setup, which we modify/tweak without asking for any government approval.
Yeah, except it always pays to ask one crucial question: What demands?
They're already subject to the laws of the countries they currently operate in. If the governments find out that Google is doing something illegal, you bet they should take action - and there might be a good reason why they're not doing anything right now. Like, no illegalities happening that they know of.
Laws of one jurisdiction don't necessarily apply to another. If Google gets busted in one country for doing something illegal, they won't get busted in another country unless a similar law exists there. And, frankly, if your democratic country is planning on quashing a frigging search engine for not building an alternate reality, perhaps it's just an indication of a really big problem somewhere else.
If you have to back down from some market because you cannot adequately serve your customers, that's fine. If you have to back down because you're worried that it might expose your global nefarious crime syndicate that's illegal everywhere, maybe you shouldn't run a crime syndicate in the first place and focus on legal endeavours instead.
And your point is what? That violation of privacy is okay so long as a LED is involved? That it's okay to violate the privacy of people who aren't paying enough attention?
"Most people, I think, don't even know what a rootkit is, so why should they care about it?" - Thomas Hesse, Sony BMG, 2005
...nnnope, I'm pretty sure that that wasn't an excuse then, and it sure doesn't sound like an an excuse now.
Look, I'm not an electronics geek. Here's the thing I know about flashlights: there's a battery, there's a lamp, and there's a switch. I'm sure you can figure out how to hook them up together with a bit of wire. If not, there's plenty of "fun scientific experiments for schoolkids" books that tell you how. Frankly, I was surprised and flabbergasted that this wasn't the first illustration in Wikipedia article on electrical circuits. (Generator and resistor? Bah! Give the kids an example of a circuit that does something...)
I guess it just highlights one unfortunate side of the terminology: "open source" is just how things are - even before someone specifically decides to call it that way. We might as well call it "commonly accepted knowledge" and "stuff that's too obvious to even go into in great detail". If you want to build a flashlight, just about everyone already knows how to do it, or can find someone who does.
That said, this could be the world's first non-trivial and very cool open source flashlight. All I'm saying is that the boundary is kind of blurry and it's hard to say if it really was the first. =)
Eh. You're basically correct - except for the technological point. There are generic terms. Twitter is a microblog. Facebook is a social network. The actual problem is that Twitter and Facebook are closed systems - you need to be a Twitter user to follow someone on Twitter, you need to be a Facebook user to talk to Facebook users. The difference is that the other examples you list are federated: you don't need to use wordpress.com to set up a blog, you can go to Blogger instead, or just install any of the dozens of blogwares on your own webhost - and it all works out.
Both microblogging and social networking are becoming federated systems, though; the standards that define the interchange between hosts (ostatus, activitystreams) are being developed at the moment.
Linux in general has a major problem with its model: the only user-friendly way of installing applications is via the distribution repositories, forcing such people to upgrade their entire OS when they just want to upgrade one application (unless they're lucky and someone backports it).
Except that's not the repository model's fault. Sure, you can try to install and run, say, a Windows 3.1 app in modern Windows - and the first things you'll say is "it works really wonkily, if at all, and it was not very easy to uninstall because it left crap all over the filesystem". Yes, you could unpack the.deb and stick it in a non-Debian/Ubuntu system, or older version, and it might work. (If not, the package maintainer is fully within their rights to say "See? Told ya it wouldn't run on libc5.") The value of the package management is that it knows what files belong to a package and which versions of the librariers are known to work.
make it a crime to use a friend's login — even with permission — to listen to songs or watch movies from services such as Netflix or Rhapsody.
But if an employer wants your Facebook username and password, that's completely acceptable - after all, they just need to make sure you're not talking behind their backs!
*sigh* Remember the time when things were much simpler? The service provider said "don't give your password to anyone", and you said "of course not, duh." And that worked. It still works.
I'm a computational neuroscientist. I view the mind as software.
Then why the hell do programmers spend 90% of their time doing 1) user interface code, 2) error validation and 3) doing stuff to accommodate various usage patterns? In other words, if humans truly grok software, and human/computer interaction is basically just a matter of finding a common language, why do programmers have to make the software to serve human needs and human limitations? Why do humans keep not getting or disregarding the software? Why do people make mistakes while using the software? And most importantly, why do humans sometimes outwit the user interface to reach new brands of failure - damn those cunning bastards?
Added complexity, more surface for bugs to appear, 'nuff said.
Well, that's almost true. The problem isn't increased complexity, it's that it's a more complex interface that isn't probably as well defined as the current std{in,out,err} interface is. It's possible to have a more complex interface and make it sufficiently bug-free, but in order to get there, it should be well-defined and not "hackish".
Basically, the bottom line is this: everyone knows Unix shells are limited in what they can display, but this is how they were designed and this is how you're stuck with. It may be simple, but at least we know it has been implemented in a way that we know is hard to mess up. If you want to reimagine how Unix shells operate, you need some pretty big changes in application side and come up with a well-defined, likewise hard-to-mess-up interface.
This isn't to say that such an interface couldn't be implemented with backwards compatibility (just look how well some X11 apps cooperate with command line tools). And, of course, losing backwards compatibility would be foolish because, like it or not, Unix shells do work just fine right now and graphical bells and whistles might not be appropriate for all uses.
In all seriousness, how long until this finds it's way onto Wikileaks?
What if Bin Laden already had a copy of the entirety of Wikileaks? If his hard drive would be leaked to Wikileaks, you'd get a Wikileaks leak that... included a copy of Wikileaks. You know, a leak like that might not do wonders to the allegations of excessive self-importance of the project.
I would expect a "professional publisher's platform" to be able to handle upgrades between versions seamlessly, or very close to that (possibly tool-assisted migration path).
What that meant was that you need to actually make some preparations before you migrate the site to the next major version. And these preparations can be pretty extensive. Especially if you're depending on the functionality that doesn't come out of the box (since a lot of Drupal functionality comes from non-core modules). Software that isn't massively customised or extended (e.g. Bugzilla) tends to fare better over upgrades.
I've not used Drupal much, but - hint hint - this is the same situation as every other damn package that depends on external modules has. I've actually yet to see a "professional" anything that you can just stick in and go, because "professional" software sort of assumes that the user knows what they're doing and are making actual plans so that the end users won't end up suffering in the unlikely scenario where the said professional somehow fucks up.
The bottom line is this: it's your site, you've decided to make some tweaks that lead out of the Boring Defaults zone, and the software can no longer guarantee that the upgrade is entirely smooth. It can, and should, facilitate it as far as it's possible. But ultimately, it's you who needs to say "Sorry, boss, we really need the Tweakulator module and it's not compatible with Mega-CMS 2.0 - but it's coming. We'll need to delay the migration until it works. Because if we did it now, we'd not have the same functionality and people would complain."
You do realize that everything about "radiation dangers" outside of actually affected area (small chunk of Ukraine, Belarus and Russia) was an anti-Soviet propaganda campaign, right?
Yeah, anti-Soviet propaganda is still profitable these days. The Finnish radiation authorities still tell people to boil mushrooms well in certain parts of the country (to get the pinko commie hippie influences out, obviously - all mushrooms are suspicious by default), and in some areas of Sweden and Norway reindeer have to be given fodder because the lichen are still contaminated by communism.
Aside from deeming CTRL+C CTRL+V as sacred symbols
...this will only lead into a bloody feud with the Church of Emacs and their Esc-w and Control-y....I mean, M-w and C-y. Don't look at me funnily, brethren! A honest mistake! Just trying to educate the public unwash'd who know not the Naming of the Keys!
A few hours ago, Garry Newman – the creator of Garry's Mod – asked, quite innocently, whether anyone was unable to shade polygon normals.
A few moments ago, Googlebot visited the sites.
A hour from now, a puzzled evil pirate gamer types "Unable to shade polygon normals" in Google, and guess what pops up? They're going to think "oops, I'd better not report that issue. In fact, it's better not to report any issues in any of my pirated games! Glad this issue has already been documented!"
This is the information age. People document things openly. Don't build DRM that is built on top of ignorance and secrets. It only works for a while and you wasted time.
It is still completely possible for Google to use hashed passwords to authenticate users and only "save" the plain password in a "write only" file (text or separate database) with the unhashed passwords...
The purpose of hashing passwords is that if the datastore that contains the user credentials is compromised, the attacker cannot learn the actual passwords. The problem in your scenario is that there's no such thing as a "write only" file and an additional database only increases the overall complexity of the system; if the attacker can get to the hashed passwords, the system is bound to be severely compromised and it's reasonable to assume that they're able to get to the components that save the passwords to that external database.
Look at it this way: The login component that stores the hashed passwords has to communicate with the plain-text database. The plain-text database has to assume that the login component's security is air-tight, because otherwise it won't be able to tell apart legit and illegal requests to update passwords. Now, if the attacker can get the hashed passwords, that means they have their claws on the login component. Which means they have the plain-text database credentials. Oops. And if you assume that everyone doing this sort of database always manages to make the database "write-only" (e.g. SQL database with only UPDATE commands allowed), you're assuming too much. Besides, if the attacker is able to get that database's credentials, what's stopping them from throwing a giant spanner in the works and making you legally liable for not saving plain-text passwords? (UPDATE users SET password = '';) You can do a lot of damage either ways.
User credentials are a very crucial bit of information whose privacy has to be guaranteed at all costs, and you don't replicate them randomly on bazillion places. Especially if some places are by design less secure than others, and there's an automated gatekeeper whose job is to purposefully degrade that security.
This is pretty damn hilarious. Though also, probably an April Fool's joke.
Weirder stuff has happened. There already was some Mafia guy who got caught because he was using Caesar cipher. <predictablejoke>And then there was that one Caesar-based encryption scheme in Adobe DRM. I have problems telling these Mafia guys apart.</predictablejoke>
Still, pretty hilarious. Even ignoring Kerckhoffs's Principle, there's still a big difference between using a cryptosystem the infidels developed, and a cryptosystem the infidels developed and then then abandoned centuries ago because they broke it and Muslim mathematicians no doubt helped cracking it. People who ignore history will only repeat it. This is also a good example of what happens when you play a high-stakes game of "I have a problem - let's throw a little bit of Excel at it to solve it once and for all".
Google changed its logo to an unreadable collection of chemisty glassware glyphs to honor a guy who invented a liquid candle, but they never once changed it in February to honor Black History Month?
I know who Robert Bunsen was, but what's a Black History Month? (- signed, a confused European.)
My point being, Google operates internationally and they have the whole world to draw inspiration from. They do these doodles pretty sparingly - under normal circumstances, they don't do these doodles.
February occurs every year, and Google hasn't announced that they're going *poof* before the next February; It's not like they'd be running out of opportunities to celebrate some locally occurring celebration thingy. And it's not like they're celebrating Robert Bunsen every year - they do this stuff once properly, which is better than doing something half-assedly every year.
Kuro5hin, once touted as a Slashdot alternative, was a pretty big name in social news and communal blogging back around 2000. (I was interested of the site because I'm fairly interested of the intersection of tech and politics. Then 9/11 happened, and as time went by, K5 became more about politics and less about tech. Yawn.) Basically, people could submit stories to sections, and they could be voted by registered users. If they get enough +1's to go past the threshold, they get posted. With enough "+1 FP" votes, the posts also go to the front page.
I haven't tried any Wine stuff in a while, but circa Wine 1.0, Dungeon Siege (and Lazarus) definitely ran pretty well on it, at least on Linux_x86. Some glitches and performance issues (videos looked really crappy and mouse cursor was glitchy), but definitely playable enough. I'm hoping the direction is only upward.
Lazarus definitely looked awesome, but I really wish EA would hand the IP to Bioware and tell them to remake stuff from U4 onward on Dragon Age: Origins (or DA2) engine.
Debian-based distributions have used code signing since the dawn of time to combat malicious modifications. This is done primarily to allow for effortless mirroring: It doesn't matter who hosts a copy of the repository, as long as the packages are signed by Debian and apt can verify the signatures correctly. As long as the mirrors don't mess with the packages in any way, the software just works. But if you want to host a repository of your own for your own packages, you have to either a) have apt-get scream about missing keys, or b) sign your packages, then tell the users where they can find the repository signing keys and how to install them. (And it uses gpg, so in theory you could use some sort of a chain-of-trust model for the keys, though I have no idea if people actually look that far in the keys. Most 3rd-party repositories just say "here's a damn key, go add it".)
Notice that this only covers distribution of the software, as any sane model for trusted software distribution requires. The.deb packages are just dumb containers for files, metadata and installation scripts. If you want signed binaries, there's no reason why you couldn't use the exact same model for key distribution.
But my table is good for holding food at dinners. Can your laptop do that?
The aluminium chassis of my PowerBook G4 can conduct heat pretty well, so it would keep food pretty warm. However, there's just not enough space on the wrist rest area! Can't even fit a good proper coffee mug on it.
Oh, how I long back to the days of Commodore 64, when the 1541 floppy drive wasn't called a "toaster" for no reason. The fact that it took huge 5.25" floppies in, and had an internal power supply that required half of Chernobyl's output, meant that there was plenty of space for keeping the food warm!
It's all in the refinement of already agreed-upon units. Basically, what happened was this: 1) Some people came up with a convenient 1 day = 24 hours = 60 minutes = 60 seconds division. 2) People who wanted precision defined second in an exact manner that is closest approximation of the commonly used definition of second. 3) Newer, more accurate methods were devised, again maintaining as-exact-as-possible match to the already established definition of second.
Notice that people stopped talking about days and instead talk of seconds.
This is mostly because people noticed there are multiple definitions of "day". Millennia ago, it was easy to just decide that there's 24 hours to the day and divide that further, because that was accurate enough for most tasks. Then they got the crazy idea of actually measuring how long the days are, and noticed the damn things don't seem to have a constant length. Sure, we're talking of minutes of differences here, which people wouldn't notice much anyway, but everyone agreed that this 24-hour system is pretty good because it's convenient. Days are of same length. Years are about the same length too. And the astronomers said "sure, OK, we'll, um, make a good calendar system that won't confuse the hell out of you."
If you want to be really accurate, you can define day based on Earth's orbiting around the Sun (sidereal day) or based on the position of the Sun in the sky (solar day). Sidereal day is shorter than solar day, so using that for calendar-keeping would be highly confusing. Solar days aren't entirely problematic either, because the Sun's apparent motion on the sky differs at different times of the year (i.e., if you stare at a sundial, days are shorter in spring and autumn). So calendar days are based on mean solar days, which are basically averages. To keep the wallclock time as close as possible to the "real" timekeeping, when the Earth orbit fluctuates, leap seconds are inserted as needed.
At this point, you start noticing that things are all a little bit relative: you can define a second - a single, short unit of time with a definite length - precisely using another predictable natural phenomenon... but it's far more convenient to keep "days" as best estimates as long as they don't fly too far from real values.
Slashdot Mirror
I consider this hacking group no more than simple vandals and criminals at this stage. There is no "honour" in it, and exposing porn clients are extremely likely to be hypocritical. I don't believe for a second that all members of this hacker group has a "clean conscience" about porn.
I don't have any opinion on the motivations of Lulzsec. I'm more concerned about what happens now.
Try not to think of "Lulzsec, the annoying and dangerous cracking group, just busted open a porn site. How evil of them."
Think of "A goddamn porn site was compromised. What does that tell of the security in adult industry? What does that tell to the victims?"
In short, it's irrelevant who cracked them. The milk's on the floor, too late to cry.
Someone pointed out that Lulzsec is definitely doing a good job at pointing out security flaws that should be addressed. Why did a porn site have such lax security? Why is a porn site storing passwords in cleartext? Aren't they aware that quite a few of their members might not appreciate being advertised as members? Should people be more concerned about the security in porn sites? Not everybody minds being advertised as a member of a porn site, but since a lot of people obviously have a problem with that, should the porn sites provide additional security measures for people who are embarrassed to admit this stuff publicly? (e.g. not store details that might identify them, such as email)
I'm now selling my poo as a currency. Like bit coin it can only be mined at a steady rate so it can't be manipulated. My Poo is marked with my DNA so it can't be forged for less than it costs to make. It's Natural, and a work of Man. Now rather than transport it to you in all it's glory, I have established a Poo Reserve.
But your system assumes that you will be personally present at the Poo Reserve at all times. It hinges on our trust that the Poo will always be either collected by the Reserve or destroyed according to a secure standard operating procedure. As the brilliant Chinese strategist Sun Tzu said, "a man's gotta go when a man's gotta go". The Poo deposits may occur at weird, unpredictable times. What assurances do we get that there are absolutely no out-of-record deposits and all deposits occur at exactly specified manner? What if 100% genuine, DNA-verified Poo, which is not used for backing poocoin and shouldn't officially even exist, ends up in a place where it can be collected by the black market? Or the terrorists? Or the terrorists who run the black market?
Now, you may be thinking, "surely everyone can collect Poo! You don't need to be a specialist! We all handle Poo every day!", but secure collection of Poo is a surprisingly complicated matter, which is best left to the experts. What passes for everyday handling may not be enough when there's money in the line. Just goes to show that you shouldn't design a new currency if even a non-expert like me can see big fatal flaws in the system!
Further, our yielding to such [outrageous] demands could mark the beginning of a torrent of similar requests from governments around the globe, disrupting our current efficient setup, which we modify/tweak without asking for any government approval.
Yeah, except it always pays to ask one crucial question: What demands?
They're already subject to the laws of the countries they currently operate in. If the governments find out that Google is doing something illegal, you bet they should take action - and there might be a good reason why they're not doing anything right now. Like, no illegalities happening that they know of.
Laws of one jurisdiction don't necessarily apply to another. If Google gets busted in one country for doing something illegal, they won't get busted in another country unless a similar law exists there. And, frankly, if your democratic country is planning on quashing a frigging search engine for not building an alternate reality, perhaps it's just an indication of a really big problem somewhere else.
If you have to back down from some market because you cannot adequately serve your customers, that's fine. If you have to back down because you're worried that it might expose your global nefarious crime syndicate that's illegal everywhere, maybe you shouldn't run a crime syndicate in the first place and focus on legal endeavours instead.
And your point is what? That violation of privacy is okay so long as a LED is involved? That it's okay to violate the privacy of people who aren't paying enough attention?
"Most people, I think, don't even know what a rootkit is, so why should they care about it?" - Thomas Hesse, Sony BMG, 2005
...nnnope, I'm pretty sure that that wasn't an excuse then, and it sure doesn't sound like an an excuse now.
Look, I'm not an electronics geek. Here's the thing I know about flashlights: there's a battery, there's a lamp, and there's a switch. I'm sure you can figure out how to hook them up together with a bit of wire. If not, there's plenty of "fun scientific experiments for schoolkids" books that tell you how. Frankly, I was surprised and flabbergasted that this wasn't the first illustration in Wikipedia article on electrical circuits. (Generator and resistor? Bah! Give the kids an example of a circuit that does something...)
I guess it just highlights one unfortunate side of the terminology: "open source" is just how things are - even before someone specifically decides to call it that way. We might as well call it "commonly accepted knowledge" and "stuff that's too obvious to even go into in great detail". If you want to build a flashlight, just about everyone already knows how to do it, or can find someone who does.
That said, this could be the world's first non-trivial and very cool open source flashlight. All I'm saying is that the boundary is kind of blurry and it's hard to say if it really was the first. =)
The proper generic verb hasn't been invented yet.
Eh. You're basically correct - except for the technological point. There are generic terms. Twitter is a microblog. Facebook is a social network. The actual problem is that Twitter and Facebook are closed systems - you need to be a Twitter user to follow someone on Twitter, you need to be a Facebook user to talk to Facebook users. The difference is that the other examples you list are federated: you don't need to use wordpress.com to set up a blog, you can go to Blogger instead, or just install any of the dozens of blogwares on your own webhost - and it all works out.
Both microblogging and social networking are becoming federated systems, though; the standards that define the interchange between hosts (ostatus, activitystreams) are being developed at the moment.
Linux in general has a major problem with its model: the only user-friendly way of installing applications is via the distribution repositories, forcing such people to upgrade their entire OS when they just want to upgrade one application (unless they're lucky and someone backports it).
Except that's not the repository model's fault. Sure, you can try to install and run, say, a Windows 3.1 app in modern Windows - and the first things you'll say is "it works really wonkily, if at all, and it was not very easy to uninstall because it left crap all over the filesystem". Yes, you could unpack the .deb and stick it in a non-Debian/Ubuntu system, or older version, and it might work. (If not, the package maintainer is fully within their rights to say "See? Told ya it wouldn't run on libc5.") The value of the package management is that it knows what files belong to a package and which versions of the librariers are known to work.
make it a crime to use a friend's login — even with permission — to listen to songs or watch movies from services such as Netflix or Rhapsody.
But if an employer wants your Facebook username and password, that's completely acceptable - after all, they just need to make sure you're not talking behind their backs!
*sigh* Remember the time when things were much simpler? The service provider said "don't give your password to anyone", and you said "of course not, duh." And that worked. It still works.
I'm a computational neuroscientist. I view the mind as software.
Then why the hell do programmers spend 90% of their time doing 1) user interface code, 2) error validation and 3) doing stuff to accommodate various usage patterns? In other words, if humans truly grok software, and human/computer interaction is basically just a matter of finding a common language, why do programmers have to make the software to serve human needs and human limitations? Why do humans keep not getting or disregarding the software? Why do people make mistakes while using the software? And most importantly, why do humans sometimes outwit the user interface to reach new brands of failure - damn those cunning bastards?
Inquiring computer guys want to know.
Added complexity, more surface for bugs to appear, 'nuff said.
Well, that's almost true. The problem isn't increased complexity, it's that it's a more complex interface that isn't probably as well defined as the current std{in,out,err} interface is. It's possible to have a more complex interface and make it sufficiently bug-free, but in order to get there, it should be well-defined and not "hackish".
Basically, the bottom line is this: everyone knows Unix shells are limited in what they can display, but this is how they were designed and this is how you're stuck with. It may be simple, but at least we know it has been implemented in a way that we know is hard to mess up. If you want to reimagine how Unix shells operate, you need some pretty big changes in application side and come up with a well-defined, likewise hard-to-mess-up interface.
This isn't to say that such an interface couldn't be implemented with backwards compatibility (just look how well some X11 apps cooperate with command line tools). And, of course, losing backwards compatibility would be foolish because, like it or not, Unix shells do work just fine right now and graphical bells and whistles might not be appropriate for all uses.
I'm Synonymous. Exactly the same as Anonymous, just a different name.
After seeing the original Chanology clip with the speech-synthesis voice, I was ready to call them Monotonous...
In all seriousness, how long until this finds it's way onto Wikileaks?
What if Bin Laden already had a copy of the entirety of Wikileaks? If his hard drive would be leaked to Wikileaks, you'd get a Wikileaks leak that... included a copy of Wikileaks. You know, a leak like that might not do wonders to the allegations of excessive self-importance of the project.
I would expect a "professional publisher's platform" to be able to handle upgrades between versions seamlessly, or very close to that (possibly tool-assisted migration path).
What that meant was that you need to actually make some preparations before you migrate the site to the next major version. And these preparations can be pretty extensive. Especially if you're depending on the functionality that doesn't come out of the box (since a lot of Drupal functionality comes from non-core modules). Software that isn't massively customised or extended (e.g. Bugzilla) tends to fare better over upgrades.
I've not used Drupal much, but - hint hint - this is the same situation as every other damn package that depends on external modules has. I've actually yet to see a "professional" anything that you can just stick in and go, because "professional" software sort of assumes that the user knows what they're doing and are making actual plans so that the end users won't end up suffering in the unlikely scenario where the said professional somehow fucks up.
The bottom line is this: it's your site, you've decided to make some tweaks that lead out of the Boring Defaults zone, and the software can no longer guarantee that the upgrade is entirely smooth. It can, and should, facilitate it as far as it's possible. But ultimately, it's you who needs to say "Sorry, boss, we really need the Tweakulator module and it's not compatible with Mega-CMS 2.0 - but it's coming. We'll need to delay the migration until it works. Because if we did it now, we'd not have the same functionality and people would complain."
You do realize that everything about "radiation dangers" outside of actually affected area (small chunk of Ukraine, Belarus and Russia) was an anti-Soviet propaganda campaign, right?
Yeah, anti-Soviet propaganda is still profitable these days. The Finnish radiation authorities still tell people to boil mushrooms well in certain parts of the country (to get the pinko commie hippie influences out, obviously - all mushrooms are suspicious by default), and in some areas of Sweden and Norway reindeer have to be given fodder because the lichen are still contaminated by communism.
Aside from deeming CTRL+C CTRL+V as sacred symbols
...this will only lead into a bloody feud with the Church of Emacs and their Esc-w and Control-y. ...I mean, M-w and C-y. Don't look at me funnily, brethren! A honest mistake! Just trying to educate the public unwash'd who know not the Naming of the Keys!
A few hours ago, Garry Newman – the creator of Garry's Mod – asked, quite innocently, whether anyone was unable to shade polygon normals.
A few moments ago, Googlebot visited the sites.
A hour from now, a puzzled evil pirate gamer types "Unable to shade polygon normals" in Google, and guess what pops up? They're going to think "oops, I'd better not report that issue. In fact, it's better not to report any issues in any of my pirated games! Glad this issue has already been documented!"
This is the information age. People document things openly. Don't build DRM that is built on top of ignorance and secrets. It only works for a while and you wasted time.
It is still completely possible for Google to use hashed passwords to authenticate users and only "save" the plain password in a "write only" file (text or separate database) with the unhashed passwords...
The purpose of hashing passwords is that if the datastore that contains the user credentials is compromised, the attacker cannot learn the actual passwords. The problem in your scenario is that there's no such thing as a "write only" file and an additional database only increases the overall complexity of the system; if the attacker can get to the hashed passwords, the system is bound to be severely compromised and it's reasonable to assume that they're able to get to the components that save the passwords to that external database.
Look at it this way: The login component that stores the hashed passwords has to communicate with the plain-text database. The plain-text database has to assume that the login component's security is air-tight, because otherwise it won't be able to tell apart legit and illegal requests to update passwords. Now, if the attacker can get the hashed passwords, that means they have their claws on the login component. Which means they have the plain-text database credentials. Oops. And if you assume that everyone doing this sort of database always manages to make the database "write-only" (e.g. SQL database with only UPDATE commands allowed), you're assuming too much. Besides, if the attacker is able to get that database's credentials, what's stopping them from throwing a giant spanner in the works and making you legally liable for not saving plain-text passwords? (UPDATE users SET password = '';) You can do a lot of damage either ways.
User credentials are a very crucial bit of information whose privacy has to be guaranteed at all costs, and you don't replicate them randomly on bazillion places. Especially if some places are by design less secure than others, and there's an automated gatekeeper whose job is to purposefully degrade that security.
This is pretty damn hilarious. Though also, probably an April Fool's joke.
Weirder stuff has happened. There already was some Mafia guy who got caught because he was using Caesar cipher. <predictablejoke>And then there was that one Caesar-based encryption scheme in Adobe DRM. I have problems telling these Mafia guys apart.</predictablejoke>
Still, pretty hilarious. Even ignoring Kerckhoffs's Principle, there's still a big difference between using a cryptosystem the infidels developed, and a cryptosystem the infidels developed and then then abandoned centuries ago because they broke it and Muslim mathematicians no doubt helped cracking it. People who ignore history will only repeat it. This is also a good example of what happens when you play a high-stakes game of "I have a problem - let's throw a little bit of Excel at it to solve it once and for all".
Google changed its logo to an unreadable collection of chemisty glassware glyphs to honor a guy who invented a liquid candle, but they never once changed it in February to honor Black History Month?
I know who Robert Bunsen was, but what's a Black History Month? (- signed, a confused European.)
My point being, Google operates internationally and they have the whole world to draw inspiration from. They do these doodles pretty sparingly - under normal circumstances, they don't do these doodles.
February occurs every year, and Google hasn't announced that they're going *poof* before the next February; It's not like they'd be running out of opportunities to celebrate some locally occurring celebration thingy. And it's not like they're celebrating Robert Bunsen every year - they do this stuff once properly, which is better than doing something half-assedly every year.
Kuro5hin, once touted as a Slashdot alternative, was a pretty big name in social news and communal blogging back around 2000. (I was interested of the site because I'm fairly interested of the intersection of tech and politics. Then 9/11 happened, and as time went by, K5 became more about politics and less about tech. Yawn.) Basically, people could submit stories to sections, and they could be voted by registered users. If they get enough +1's to go past the threshold, they get posted. With enough "+1 FP" votes, the posts also go to the front page.
I haven't tried any Wine stuff in a while, but circa Wine 1.0, Dungeon Siege (and Lazarus) definitely ran pretty well on it, at least on Linux_x86. Some glitches and performance issues (videos looked really crappy and mouse cursor was glitchy), but definitely playable enough. I'm hoping the direction is only upward.
Lazarus definitely looked awesome, but I really wish EA would hand the IP to Bioware and tell them to remake stuff from U4 onward on Dragon Age: Origins (or DA2) engine.
Yup.
Debian-based distributions have used code signing since the dawn of time to combat malicious modifications. This is done primarily to allow for effortless mirroring: It doesn't matter who hosts a copy of the repository, as long as the packages are signed by Debian and apt can verify the signatures correctly. As long as the mirrors don't mess with the packages in any way, the software just works. But if you want to host a repository of your own for your own packages, you have to either a) have apt-get scream about missing keys, or b) sign your packages, then tell the users where they can find the repository signing keys and how to install them. (And it uses gpg, so in theory you could use some sort of a chain-of-trust model for the keys, though I have no idea if people actually look that far in the keys. Most 3rd-party repositories just say "here's a damn key, go add it".)
Notice that this only covers distribution of the software, as any sane model for trusted software distribution requires. The .deb packages are just dumb containers for files, metadata and installation scripts. If you want signed binaries, there's no reason why you couldn't use the exact same model for key distribution.
> My $200 Laptop Can Beat Your $500 Table
But my table is good for holding food at dinners. Can your laptop do that?
The aluminium chassis of my PowerBook G4 can conduct heat pretty well, so it would keep food pretty warm. However, there's just not enough space on the wrist rest area! Can't even fit a good proper coffee mug on it.
Oh, how I long back to the days of Commodore 64, when the 1541 floppy drive wasn't called a "toaster" for no reason. The fact that it took huge 5.25" floppies in, and had an internal power supply that required half of Chernobyl's output, meant that there was plenty of space for keeping the food warm!
It's all in the refinement of already agreed-upon units. Basically, what happened was this: 1) Some people came up with a convenient 1 day = 24 hours = 60 minutes = 60 seconds division. 2) People who wanted precision defined second in an exact manner that is closest approximation of the commonly used definition of second. 3) Newer, more accurate methods were devised, again maintaining as-exact-as-possible match to the already established definition of second.
Notice that people stopped talking about days and instead talk of seconds.
This is mostly because people noticed there are multiple definitions of "day". Millennia ago, it was easy to just decide that there's 24 hours to the day and divide that further, because that was accurate enough for most tasks. Then they got the crazy idea of actually measuring how long the days are, and noticed the damn things don't seem to have a constant length. Sure, we're talking of minutes of differences here, which people wouldn't notice much anyway, but everyone agreed that this 24-hour system is pretty good because it's convenient. Days are of same length. Years are about the same length too. And the astronomers said "sure, OK, we'll, um, make a good calendar system that won't confuse the hell out of you."
If you want to be really accurate, you can define day based on Earth's orbiting around the Sun (sidereal day) or based on the position of the Sun in the sky (solar day). Sidereal day is shorter than solar day, so using that for calendar-keeping would be highly confusing. Solar days aren't entirely problematic either, because the Sun's apparent motion on the sky differs at different times of the year (i.e., if you stare at a sundial, days are shorter in spring and autumn). So calendar days are based on mean solar days, which are basically averages. To keep the wallclock time as close as possible to the "real" timekeeping, when the Earth orbit fluctuates, leap seconds are inserted as needed.
At this point, you start noticing that things are all a little bit relative: you can define a second - a single, short unit of time with a definite length - precisely using another predictable natural phenomenon... but it's far more convenient to keep "days" as best estimates as long as they don't fly too far from real values.
And while you're at it, support more than 140 chars, or allow compression, or something.
Already done.