Actually, I thought they mean a way how to have it truly asynchronous -- ie, without building a whole TCP connection first, getting acks and what not. But no, this is just the very basic XMLHttpRequest.
So, would anyone be able to tell me how to send something to a server using a single half-trip? It may be a part of a persistent connection, any eventual ack can be sent through a separate channel, I don't really care about bandwidth -- all that matters is the latency between the user's action and the time server receives the command. Think "interactive app", where interaction means something faster than a matter of seconds.
The only way I can think of so far is trying to send dummy requests to command.1.is.foo.dns.my.server and have the DNS relay me these; however, this would be an insanely ugly hack. Any better ideas?
Most of the warts were already pointed out by people with far more fame than me, there is no need for me to add an AOL comment. But, here's just one suggestion that I haven't seen yet: What about merging GPLv3 and GFDL, fixing known issues with the GFDL on the way? Having these two licenses incompatible is a major blocker. The issues, like the advertising (well, "Invariant") clause or the chmod o-r problem are not key part of that license.
Why? Of course, you are allowed to write such a player (although certain laws like the DMCA can be a blocker). What you won't be able to is taking someone's player, encrust it with your DRM and distribute it without providing the key. GPLv3 just closes the loophole where someone can try to claim that the decryption key doesn't belong to the source.
If you read GPLv2 as intended, this was already the case in that version -- source that can't produce functional binaries is not the real source; GPLv3 just amends the wording so shifty lawyers can't play word games.
GPLv3 is not perfect and it has many warts, so bad that I would go Linus' way (pure v2) at this moment, but the DRM clause is one of its stronger upsides.
I demand that Red Hat immediately hand over all their private keys!
Wrong. GPLv3 says that you need to provide all keys needed to make the software functional for its intended purpose, not the keys needed to make a bit-for-bit identical package.
Thus, if your piece of software is supposed to be able to read scrambled data, you cannot hide the decryption key -- but, you are free to sign the packages to prove they are untampered binaries produced by you. In the former case, the program wouldn't work, in the latter, it just will trigger a warning from the OS which says the user is about to install unsigned binaries. No one forces the user to heed the warning, and she can disable it if she wants. No functionality is lost.
Well, well. Since the quality exceeds those provided by "consumer-level" equipment, how are these guys going to deal with the Digital Transition Content Security Act?
Totally wrong. One of major flaws in Windows is that you can't replace any file that is currently open, and since the major system libs are not modular, nearly any patch issued by Microsoft requires a reboot.
On any Unix system, you can update anything except for the running kernel (actually, you can replace it on the disk but can't reload it). In the case of Hurd, you can update even it.
Since security updates to the kernel itself are pretty rare, you don't need to make almost any reboots. This enables you to have impressive uptimes and stay secure.
>what's stopping the U.S. government from instituting the same restrictions for China?
That Would kill our economy.
I would say that, to the contrary -- this is pretty much the only way to save the US (and Polish, the UK's, etc, etc...) economy. Sure, it would cause some short-run shortages, but in the long run, there is no real way you can compete with near-slave labour.
Right, there is still North Korea, and arguably Cuba.
know of one that warmongers in 100 countries as we speak
Which one? As we have around 192 countries in the world, give or take, the country you are talking about would have to be in a state of war with more than half of the world. As it stands, the only one who loudly declares an intent to do so doesn't even have nukes yet.
Oh, wait... you meant the US, just because they are waging war in Afghanistan and Iraq. This is clearly less than "100". And I personally wouldn't blame the US for these wars -- they deserve blame for waging them in an ineffective way. They at least had the balls to step up while many others just blabbed around. And yeah, there is the question of hypocrisy of being on friendly terms with China, North Korea and Russia while not having official diplomatic relations with places like Taiwan or Tibet.
How many countries that are more free than the US can you name? Certainly no more than a handful. In fact, it's basically only a few Scandinavian ones that can even try.
UK? Mass surveilance. Poland? Rampant corruption. Russia? At the level of Germany in the 30s. 90% of Africa? Muslim countries? Venesuela and the like?
Well, then tell me why all the virii listed there are either OS9 or Microsoft Office ones?
Indeed, old Macs suffered from security problems -- this is why Apple made the decision to go for a burned ground rewrite. Because they realize that sometimes you can't fix bad design in a milder way.
I'm not a Mac fanboi, hell, I haven't even seen a Mac in my entire life (if porting several pieces of software over ssh doesn't count) -- but I can't remember hearing any unofficial product of the AV industry or their "unconnected" contractors being able to survive in the wild on OS X fruits. Sure, you can pwn users of any OS, but I wouldn't call "please-run-me" trojan as a viable virus.
In other words: Macs are not perfect, but are pretty good. Same applies to *BSD, most Linux distros, Solaris, HP SUX, etc, etc... -- in other words, any major OS made by any company other than Microsoft.
Show me a secure Win98 box (or XP for that matter), and then we'll talk. Sure, a dumb user can turn any OS into a script kiddie paradise, but this doesn't work the other way. Both the OS and the user need to have a clue.
Actually, it is possible that the GSA waited with the response on purpose. At least this is what I used to do on a MUD -- carefully logging every action, in an attempt to get a list of the crooks. The bastards would then get slapped with appropiate action, including revoking gains for a period in the past. This would make them appropiately punished as opposed to simply fixing the flaw and let them slide.
This assumes some competency on the GSA's part -- but oh well, whom am I kidding?
It is notable that many Chinese died of starvation during the revolution when they were in charge of allocating food to the masses. One can have nothing but total admiration for this, admittedly, suicidal act in the face of adversity.
I have nothing but total scorn. Why in the hell would they die _for_ a system which allowed such a mass starvation? Yeah, a rebellion would be most likely a suicide, but it would give them both at least a chance, and an opportunity to actually amend the problems.
Actually, it's a bad decision for Microsoft. Since they won't be able to claim that their evil DRM works for everyone (they silently ignore Unices), judges/govt monkeys will be more likely to see that DRM as something wrong. Also, the unwashed masses are more likely to trip into it as well, thus increasing the public awareness.
Ahh, good. Anything bad for WM* and friends is great news for us.
Don't underestimate Symantec's relations with Open Source.
They are big. They are strong. They are all negative.
Symantec is known for its FUD campaigns in order to hawk their anti-virus software. They do everything they can to fool people into believing that viruses are as prevalent in the rest of the world as they are in Windows.
Thus, I believe that a dollar given to Symantec is worse than a dollar ripped apart.
And since when conventional power plants are safe? Even if you count just accidents alone, more people die per year in coal plants than the total death toll from Chernobyl.
Not to count the amount of pollution. This very article shows that radioactivity alone is a lot bigger when burning fossil fuels -- and then add all chemical-based emissions, which are none for nuclear power.
Nuclear power is like having a vial of concentrated poison in a closed bottle, fossil fuels are like taking a bucket of the same poison and spraying it thinly over a city. In the first case, the poison is more visible, that's all.
You're assuming that they are run by competent people -- and this is a thoroughly false assumption.
If I combine everyone from my company and all companies we cooperate with, I can name only two people who consider backups to be anything but an annoying waste of time some pessimists are blabbing about in order to suck in some of their money. Redundant hardware runs against the principle of cutting costs; no bean counter would even consider investing in data integrity.
When I tell people that I installed a script that will back up the most valuable part of the data and dump them to a remote location, the reaction is like: uh, cool, but what if it breaks things?
If you want to use parts from 1997 to build a computer, Reiser is not for you.
If you want to use your CPU for things other than handling the filesystem, Reiser is not for you. If you know that having enough RAM to hold currently used files, Reiser is not for you. If you want a filesystem that is good at quickly creating/deleting a lot of small files (compiling, etc: JFS), ReiserFS is not for you. If you want a good linear throughput (video processing: XFS), ReiserFS is not for you. If you want something light-weight for a virtual machine (ext{2,3}) or for something that must be really stable (ext3), ReiserFS is not for you. If you want something that is GPL-compatible (_not_ mkreiserfs which has an advertising clause attached), ReiserFS is not for you.
Add abysmal data integrity on top of that, and the image gets pretty clear.
Please, don't use the words "ReiserFS" and "data integrity" in the same sentence.
Reiser eats filesystems like popcorn. I have used it for around a couple of months on two boxes, and in both cases every file bigger than around 4KB went to hell; in one case on the whole filesystem and in a big subtree in the other. I'll be damned if I ever give it another try, especially considering that other FSes trump it speedwise as well.
Why? ReiserFS has an order of magnitude more code than ext3, and more than twice as much as the biggest contender; also, that code has seen little scrutiny. Quoting the words of Hans Reiser: "I personally think filesystems should be rewritten from scratch every 5 years". How exactly does he expect to have it bug free?
Generally, your choices are: JFS -- small files, lost of creations/deletions XFS -- throughput for large files (video, etc) ext3 -- simple, reliable
It's not about knowing the public IP of the machine that issued the http request. It's about sending lies and propaganda to the uneducated users.
We do know that visiting a site tells them about the IP address -- your, your proxy's or a random TOR server's; and also your browser's ID string which usually mentions your operating system. But we, users who are knowledgeful about how this works, are not those who are the intended target of this scare campaign. Just as those who know how a washing powder works are not a target of most TV adverts.
People who are knowledgeful about washing powders balk at nonsence spewed in adverts, but this doesn't stop the nonsense from affecting 99% of the society.
Well, screwing up a movie so much that only the main characters have similar names _does_ require a good deal of imagination. If I tell you that the Galadhrimm should never appear at Helm's Deep as they had a shoot-on-sight-if-you-come-to-our-lands relation with Rohan, you can call me a Tolkien geek. But if I point at fluorescent Minas Morgul, there is no other explanation than P.J. having had some seriously bad shrooms.
Wasn't this supposed to be the whole point of the contest?
I admit, my tutorial sucks monkey balls, but it at least does exist. The winning entry looks good, but I bet that many of other top-notch submissions met the requirements while being about as good.
in the US, truckers aren't allowed to drive more than 11 hours a day.
"allowed". Exactly. And...?
Those extra 7 hours you talk about would be profitable, but illegal.
So, they have profitable on one hand, and legal on the other. Since the former is needed to stay above the thin margins, spedition companies can't really afford to care about "legal" things, and enforcement is pretty weak. The truckers themselves don't rat their employeer in for obvious reasons -- they can stomach it or find a different job.
The laws were made specifically to prevent this abuse, but without decent enforcement, they are ineffective.
And in this case, it's not retarded socialist rambling -- it's a matter of safety on the roads.
Set up two accounts on your mail server (example.org): aaron@example.org and zeke@example.org -- any two names that sound legitimate and sort very early/very late. Then, make sure these two names are well-published; you may put them on your webpage, include them in.sig, whatever.
When anything hits one of these mailboxes, just block the relevant traffic -- autolearn the piece of spam, _temp_ block the IP and/or bump its score.
Finally, most truckers sit in that front seat 8 hours a day. The last thing they'll want to do is sit in that same seat and pretend to drive. I am thinking most would rather crawl back into the sleeper and lay down for some gaming or get on their laptop.
8 hours a day? Where???
When they're on route, they typically drive 18 or so hours per day, and if you include having to eat/etc, you'll see that they really are dead tired afterwards and think about sleep, not about playing silly games.
Of course, law is against them, but if the trucker can choose between getting surely fired on one hand, and _possibly_ having to pay a small bribe to a police officer on the other, the choice is obvious.
Slashdot Mirror
Actually, I thought they mean a way how to have it truly asynchronous -- ie, without building a whole TCP connection first, getting acks and what not. But no, this is just the very basic XMLHttpRequest.
So, would anyone be able to tell me how to send something to a server using a single half-trip? It may be a part of a persistent connection, any eventual ack can be sent through a separate channel, I don't really care about bandwidth -- all that matters is the latency between the user's action and the time server receives the command. Think "interactive app", where interaction means something faster than a matter of seconds.
The only way I can think of so far is trying to send dummy requests to command.1.is.foo.dns.my.server and have the DNS relay me these; however, this would be an insanely ugly hack. Any better ideas?
Exactly! That's why I said "at this moment".
Most of the warts were already pointed out by people with far more fame than me, there is no need for me to add an AOL comment. But, here's just one suggestion that I haven't seen yet:
What about merging GPLv3 and GFDL, fixing known issues with the GFDL on the way? Having these two licenses incompatible is a major blocker. The issues, like the advertising (well, "Invariant") clause or the chmod o-r problem are not key part of that license.
Why? Of course, you are allowed to write such a player (although certain laws like the DMCA can be a blocker). What you won't be able to is taking someone's player, encrust it with your DRM and distribute it without providing the key. GPLv3 just closes the loophole where someone can try to claim that the decryption key doesn't belong to the source.
If you read GPLv2 as intended, this was already the case in that version -- source that can't produce functional binaries is not the real source; GPLv3 just amends the wording so shifty lawyers can't play word games.
GPLv3 is not perfect and it has many warts, so bad that I would go Linus' way (pure v2) at this moment, but the DRM clause is one of its stronger upsides.
I demand that Red Hat immediately hand over all their private keys!
Wrong. GPLv3 says that you need to provide all keys needed to make the software functional for its intended purpose, not the keys needed to make a bit-for-bit identical package.
Thus, if your piece of software is supposed to be able to read scrambled data, you cannot hide the decryption key -- but, you are free to sign the packages to prove they are untampered binaries produced by you. In the former case, the program wouldn't work, in the latter, it just will trigger a warning from the OS which says the user is about to install unsigned binaries. No one forces the user to heed the warning, and she can disable it if she wants. No functionality is lost.
Well, well. Since the quality exceeds those provided by "consumer-level" equipment, how are these guys going to deal with the Digital Transition Content Security Act?
Totally wrong. One of major flaws in Windows is that you can't replace any file that is currently open, and since the major system libs are not modular, nearly any patch issued by Microsoft requires a reboot.
On any Unix system, you can update anything except for the running kernel (actually, you can replace it on the disk but can't reload it). In the case of Hurd, you can update even it.
Since security updates to the kernel itself are pretty rare, you don't need to make almost any reboots. This enables you to have impressive uptimes and stay secure.
>what's stopping the U.S. government from instituting the same restrictions for China?
That Would kill our economy.
I would say that, to the contrary -- this is pretty much the only way to save the US (and Polish, the UK's, etc, etc...) economy. Sure, it would cause some short-run shortages, but in the long run, there is no real way you can compete with near-slave labour.
FWIW, China isn't the worst government.
Right, there is still North Korea, and arguably Cuba.
know of one that warmongers in 100 countries as we speak
Which one? As we have around 192 countries in the world, give or take, the country you are talking about would have to be in a state of war with more than half of the world. As it stands, the only one who loudly declares an intent to do so doesn't even have nukes yet.
Oh, wait... you meant the US, just because they are waging war in Afghanistan and Iraq. This is clearly less than "100". And I personally wouldn't blame the US for these wars -- they deserve blame for waging them in an ineffective way. They at least had the balls to step up while many others just blabbed around. And yeah, there is the question of hypocrisy of being on friendly terms with China, North Korea and Russia while not having official diplomatic relations with places like Taiwan or Tibet.
How many countries that are more free than the US can you name? Certainly no more than a handful. In fact, it's basically only a few Scandinavian ones that can even try.
UK? Mass surveilance. Poland? Rampant corruption. Russia? At the level of Germany in the 30s. 90% of Africa? Muslim countries? Venesuela and the like?
Well, then tell me why all the virii listed there are either OS9 or Microsoft Office ones?
Indeed, old Macs suffered from security problems -- this is why Apple made the decision to go for a burned ground rewrite. Because they realize that sometimes you can't fix bad design in a milder way.
I'm not a Mac fanboi, hell, I haven't even seen a Mac in my entire life (if porting several pieces of software over ssh doesn't count) -- but I can't remember hearing any unofficial product of the AV industry or their "unconnected" contractors being able to survive in the wild on OS X fruits. Sure, you can pwn users of any OS, but I wouldn't call "please-run-me" trojan as a viable virus.
In other words: Macs are not perfect, but are pretty good. Same applies to *BSD, most Linux distros, Solaris, HP SUX, etc, etc... -- in other words, any major OS made by any company other than Microsoft.
${ANY_OPERATING_SYSTEM} + good sense == security
Any?
Show me a secure Win98 box (or XP for that matter), and then we'll talk.
Sure, a dumb user can turn any OS into a script kiddie paradise, but this doesn't work the other way. Both the OS and the user need to have a clue.
Actually, it is possible that the GSA waited with the response on purpose. At least this is what I used to do on a MUD -- carefully logging every action, in an attempt to get a list of the crooks. The bastards would then get slapped with appropiate action, including revoking gains for a period in the past. This would make them appropiately punished as opposed to simply fixing the flaw and let them slide.
This assumes some competency on the GSA's part -- but oh well, whom am I kidding?
It is notable that many Chinese died of starvation during the revolution when they were in charge of allocating food to the masses. One can have nothing but total admiration for this, admittedly, suicidal act in the face of adversity.
I have nothing but total scorn. Why in the hell would they die _for_ a system which allowed such a mass starvation? Yeah, a rebellion would be most likely a suicide, but it would give them both at least a chance, and an opportunity to actually amend the problems.
Actually, it's a bad decision for Microsoft. Since they won't be able to claim that their evil DRM works for everyone (they silently ignore Unices), judges/govt monkeys will be more likely to see that DRM as something wrong. Also, the unwashed masses are more likely to trip into it as well, thus increasing the public awareness.
Ahh, good. Anything bad for WM* and friends is great news for us.
Don't underestimate Symantec's relations with Open Source.
They are big. They are strong. They are all negative.
Symantec is known for its FUD campaigns in order to hawk their anti-virus software. They do everything they can to fool people into believing that viruses are as prevalent in the rest of the world as they are in Windows.
Thus, I believe that a dollar given to Symantec is worse than a dollar ripped apart.
And since when conventional power plants are safe? Even if you count just accidents alone, more people die per year in coal plants than the total death toll from Chernobyl.
Not to count the amount of pollution. This very article shows that radioactivity alone is a lot bigger when burning fossil fuels -- and then add all chemical-based emissions, which are none for nuclear power.
Nuclear power is like having a vial of concentrated poison in a closed bottle, fossil fuels are like taking a bucket of the same poison and spraying it thinly over a city. In the first case, the poison is more visible, that's all.
You're assuming that they are run by competent people -- and this is a thoroughly false assumption.
If I combine everyone from my company and all companies we cooperate with, I can name only two people who consider backups to be anything but an annoying waste of time some pessimists are blabbing about in order to suck in some of their money.
Redundant hardware runs against the principle of cutting costs; no bean counter would even consider investing in data integrity.
When I tell people that I installed a script that will back up the most valuable part of the data and dump them to a remote location, the reaction is like: uh, cool, but what if it breaks things?
they only get a slap on the wrist?
The last time I checked, they don't even get a slap, except in some very extraordinary circumstances.
If you want to use parts from 1997 to build a computer, Reiser is not for you.
If you want to use your CPU for things other than handling the filesystem, Reiser is not for you. If you know that having enough RAM to hold currently used files, Reiser is not for you. If you want a filesystem that is good at quickly creating/deleting a lot of small files (compiling, etc: JFS), ReiserFS is not for you. If you want a good linear throughput (video processing: XFS), ReiserFS is not for you. If you want something light-weight for a virtual machine (ext{2,3}) or for something that must be really stable (ext3), ReiserFS is not for you. If you want something that is GPL-compatible (_not_ mkreiserfs which has an advertising clause attached), ReiserFS is not for you.
Add abysmal data integrity on top of that, and the image gets pretty clear.
Please, don't use the words "ReiserFS" and "data integrity" in the same sentence.
Reiser eats filesystems like popcorn. I have used it for around a couple of months on two boxes, and in both cases every file bigger than around 4KB went to hell; in one case on the whole filesystem and in a big subtree in the other. I'll be damned if I ever give it another try, especially considering that other FSes trump it speedwise as well.
Why? ReiserFS has an order of magnitude more code than ext3, and more than twice as much as the biggest contender; also, that code has seen little scrutiny. Quoting the words of Hans Reiser: "I personally think filesystems should be rewritten from scratch every 5 years". How exactly does he expect to have it bug free?
Generally, your choices are:
JFS -- small files, lost of creations/deletions
XFS -- throughput for large files (video, etc)
ext3 -- simple, reliable
It's not about knowing the public IP of the machine that issued the http request.
It's about sending lies and propaganda to the uneducated users.
We do know that visiting a site tells them about the IP address -- your, your proxy's or a random TOR server's; and also your browser's ID string which usually mentions your operating system.
But we, users who are knowledgeful about how this works, are not those who are the intended target of this scare campaign. Just as those who know how a washing powder works are not a target of most TV adverts.
People who are knowledgeful about washing powders balk at nonsence spewed in adverts, but this doesn't stop the nonsense from affecting 99% of the society.
Well, screwing up a movie so much that only the main characters have similar names _does_ require a good deal of imagination. If I tell you that the Galadhrimm should never appear at Helm's Deep as they had a shoot-on-sight-if-you-come-to-our-lands relation with Rohan, you can call me a Tolkien geek. But if I point at fluorescent Minas Morgul, there is no other explanation than P.J. having had some seriously bad shrooms.
Wasn't this supposed to be the whole point of the contest?
I admit, my tutorial sucks monkey balls, but it at least does exist. The winning entry looks good, but I bet that many of other top-notch submissions met the requirements while being about as good.
in the US, truckers aren't allowed to drive more than 11 hours a day.
"allowed". Exactly. And...?
Those extra 7 hours you talk about would be profitable, but illegal.
So, they have profitable on one hand, and legal on the other. Since the former is needed to stay above the thin margins, spedition companies can't really afford to care about "legal" things, and enforcement is pretty weak. The truckers themselves don't rat their employeer in for obvious reasons -- they can stomach it or find a different job.
The laws were made specifically to prevent this abuse, but without decent enforcement, they are ineffective.
And in this case, it's not retarded socialist rambling -- it's a matter of safety on the roads.
There is a better idea: do this locally.
.sig, whatever.
Set up two accounts on your mail server (example.org): aaron@example.org and zeke@example.org -- any two names that sound legitimate and sort very early/very late. Then, make sure these two names are well-published; you may put them on your webpage, include them in
When anything hits one of these mailboxes, just block the relevant traffic -- autolearn the piece of spam, _temp_ block the IP and/or bump its score.
Finally, most truckers sit in that front seat 8 hours a day. The last thing they'll want to do is sit in that same seat and pretend to drive. I am thinking most would rather crawl back into the sleeper and lay down for some gaming or get on their laptop.
8 hours a day? Where???
When they're on route, they typically drive 18 or so hours per day, and if you include having to eat/etc, you'll see that they really are dead tired afterwards and think about sleep, not about playing silly games.
Of course, law is against them, but if the trucker can choose between getting surely fired on one hand, and _possibly_ having to pay a small bribe to a police officer on the other, the choice is obvious.