We should do this: we should pay a tax to a worldwide media/entertainment global consortium. A monthly/annual fee. How about US$ 50.00 per month? Everyone pays, you have no choice.
Fuck you. That's like having to testify against yourself.
And what difference spoofing would have made I fail to understand. The destination would still have been the same..
If I read him correctly, Gibson asserts that the ability to spoof would have resulted in a different kind of attack, one that would have been much more difficult to identify and block at the destination.
But yeah, the guy's a blowhard. Still his article documents a nice piece of work.
Nothing that McDonalds sells is "low-fat" or "healthy", and calling it "McLean" doesn't make it so. Ultimately each and every one of their food products is a well-nigh flavourless mixture of gunk, so the people who appreciate food that tastes well don't go to McDonalds anyway. So the failure of that product doesn't really prove anything.
If people really wanted to eat vegetables and low-fat, healthy foods, McDonalds would crank it out.
Nope, that's not true. McDonalds will always churn out the same rubbish. You are correct, however, in that if people want low-fat healthy food, they will market their rubbish as being low-fat and healthy. IOW, You've been bamboozled. YHL. HAND.
Well, if by hacking you mean crashing, yes, just today actually. Luckily none of its zero user accounts had been compromised, and none of its zero network services had been disturbed, and there were just two applications running because available memory didn't allow for any more, or I might have actually lost work.
You definitely "need to get used" to LCD's in general, and while they're not great for graphics, I find them ideal for programming. Very very steady, not glary at all. Try it for a few days.
KDE is an ugly and confusing Windows ripoff. But hey, whatever floats your boat. Nice to hear Konq is working for you.
Who cares about web browsing anyway
on
Mozilla 0.9 Out
·
· Score: 1
Nowadays it's all about "productivity" and other bullshit biz talk anyway.
Remember when technology would deliver us from hard work and lead us unto leisure? Today, all it promises is to "increase your productivity". Damn. They might as well advertise "adds 10 inches to your slap stick".
Meanwhile, it's all people seem to want anyway ("WHOOPASS, PRODUCTIVITY IN A CAN!").
Indentation should help the programmer to understand the code. It should not be an additional source of worry.
As such, indentation should represent the program structure. It should not embody it.
First, because this approach makes it possible to compute the indentation from the program structure, and this helps to flag many errors without the need for compilation.
But perhaps more importantly, because the indentation is computable, it is discardable.
And this makes the language easy to transcribe: you can easily copy and paste snippets of C or Perl code to and from weblogs and email messages and get them to compile, usually without worrying about spaces or tabs or newlines or any such transformations that may have occurred in the process.
Yes, properly indented code looks gorgeous, and this counts. But in any non-trivial program, semantical ugliness quickly dwarfs syntactical ugliness.
Indentation should help the programmer to understand the code. It should not be an additional source of worry.
With C, you can derive the indentation from the program text, and if the indentation is wrong, you know there is a problem with the program text. With Python, you have to supply the indentation, and if your program doesn't run, you know there might be a problem with the indentation.
All you need is to have is a large number of computers doing these attacks at the same time.
The problem happens after the first few attacks wreck such massive damage that it becomes impossible to deliver the remaining attacks with the necessary force.
Remember, "I could use a lever to lift the world, if only I had a place to stand."
Your security is as weak as your enemies and as strong as your allies. Things like "unbreakable" keylengths, though protecting against casual misuse, are rather worthless in the Real World (you know, which is where people make connections... and stuff).
Indeed, who doesn't love Perl for it's ability to churn out simply badarsed little programs!
Still I can't help but feeling that the language has somehow aged (rather than matured) over the last couple of years. People just don't seem to be as enchanted with Perl as they used to be, and "Perl 6" in places seems motivated by a strong sentiment to regain this lost sense of wonder, instead of by concrete applications that Perl could be or should be targetting.
I don't think it is "better for web work, period". What you think of as an advantage (100 ways to do templating) some people think of as a liability.
In any case, I don't care much for the kind of data acquisition slash web proposition you're describing anymore. But if Perl is helping you to develop an exciting application, more power to you.
In fact it might be illuminating to hear, from your application's point of view, what you reckon might be the most exciting new feature in Perl 6.
At the time when I first encountered Perl, around 1996, I thought it was wonderful. But it was wonderful, because I could easily see, what with it's powerful text processing, easy networking and platform independance, how it could play a major part in doing wonderful things on the budding web.
But nowadays, I'm bored stiff with (programming for) the web, and likewise, my interest in Perl has waned. Also not unimportant, stuff like PHP has basically taken the crown from Perl where it comes to web development.
This is not to say that Perl doesn't have a place. Perl lends itself extremely well to perlish things. It's just that the excitement surrounding Perl seems to have diminished.
And so sometimes I cannot help but wonder whether this longish and rather dramatic prelude to the start of the preliminary design for Perl 6 is really not just a way to try and summon some lost Perl spirit; to try and recapture some of the excitement of yore.
Does the world really need another Perl? And if yes, what should it provide? The answers to that last question seem to oscillate wildly between grand visions of syntax independance and mundane matters such as thread support.
Frankly I think neither answer is very exciting. Grand visions are a dime a dozen, and thread support is just thread support.
The bottom line, I guess, is whether Perl 6 will succeed in targetting an application, or whether it will just succumb to change for the sake of change.
Slashdot Mirror
Hahaha, yeah, the nanoprobe stuff was entertaining. Thanks for digging up that link.
But yeah, the guy's a blowhard. Still his article documents a nice piece of work.
What's with the legitimacy of ICANN?
Nothing that McDonalds sells is "low-fat" or "healthy", and calling it "McLean" doesn't make it so. Ultimately each and every one of their food products is a well-nigh flavourless mixture of gunk, so the people who appreciate food that tastes well don't go to McDonalds anyway. So the failure of that product doesn't really prove anything.
Well, if by hacking you mean crashing, yes, just today actually. Luckily none of its zero user accounts had been compromised, and none of its zero network services had been disturbed, and there were just two applications running because available memory didn't allow for any more, or I might have actually lost work.
Mod this up for great justice.
Yes, it does matter, because it makes children think that the world has always looked the same.
It's quite professional not to accept documents that disrupt your workflow and have that been known to compromise sensitive information ...
You definitely "need to get used" to LCD's in general, and while they're not great for graphics, I find them ideal for programming. Very very steady, not glary at all. Try it for a few days.
You, sir, are an utterly worthless grammar nazi.
Oh please. Wasting bandwidth on Slashdot by telling people that it is wrong for the worm to waste bandwidth? Don't be so pious.
Something I created many moons ago ...
It gives the release an attitude ... And this attitude helps to remained focused on what's most important to the code at this point in its life.
KDE is an ugly and confusing Windows ripoff. But hey, whatever floats your boat. Nice to hear Konq is working for you.
Remember when technology would deliver us from hard work and lead us unto leisure? Today, all it promises is to "increase your productivity". Damn. They might as well advertise "adds 10 inches to your slap stick".
Meanwhile, it's all people seem to want anyway ("WHOOPASS, PRODUCTIVITY IN A CAN!").
Fuck it.
If you feel that way. I beg to differ.
Indentation should help the programmer to understand the code. It should not be an additional source of worry.
As such, indentation should represent the program structure. It should not embody it.
First, because this approach makes it possible to compute the indentation from the program structure, and this helps to flag many errors without the need for compilation.
But perhaps more importantly, because the indentation is computable, it is discardable.
And this makes the language easy to transcribe: you can easily copy and paste snippets of C or Perl code to and from weblogs and email messages and get them to compile, usually without worrying about spaces or tabs or newlines or any such transformations that may have occurred in the process.
Yes, properly indented code looks gorgeous, and this counts. But in any non-trivial program, semantical ugliness quickly dwarfs syntactical ugliness.
Mandatory comments would be a better idea.
With C, you can derive the indentation from the program text, and if the indentation is wrong, you know there is a problem with the program text. With Python, you have to supply the indentation, and if your program doesn't run, you know there might be a problem with the indentation.
Remember, "I could use a lever to lift the world, if only I had a place to stand."
Your security is as weak as your enemies and as strong as your allies. Things like "unbreakable" keylengths, though protecting against casual misuse, are rather worthless in the Real World (you know, which is where people make connections ... and stuff).
Still I can't help but feeling that the language has somehow aged (rather than matured) over the last couple of years. People just don't seem to be as enchanted with Perl as they used to be, and "Perl 6" in places seems motivated by a strong sentiment to regain this lost sense of wonder, instead of by concrete applications that Perl could be or should be targetting.
But, I know nothing.
In any case, I don't care much for the kind of data acquisition slash web proposition you're describing anymore. But if Perl is helping you to develop an exciting application, more power to you.
In fact it might be illuminating to hear, from your application's point of view, what you reckon might be the most exciting new feature in Perl 6.
But nowadays, I'm bored stiff with (programming for) the web, and likewise, my interest in Perl has waned. Also not unimportant, stuff like PHP has basically taken the crown from Perl where it comes to web development.
This is not to say that Perl doesn't have a place. Perl lends itself extremely well to perlish things. It's just that the excitement surrounding Perl seems to have diminished.
And so sometimes I cannot help but wonder whether this longish and rather dramatic prelude to the start of the preliminary design for Perl 6 is really not just a way to try and summon some lost Perl spirit; to try and recapture some of the excitement of yore.
Does the world really need another Perl? And if yes, what should it provide? The answers to that last question seem to oscillate wildly between grand visions of syntax independance and mundane matters such as thread support.
Frankly I think neither answer is very exciting. Grand visions are a dime a dozen, and thread support is just thread support.
The bottom line, I guess, is whether Perl 6 will succeed in targetting an application, or whether it will just succumb to change for the sake of change.
Let's just hope for the former.