Here's one way of thinking about it. It seems the article is talking about users complaining that in a forum that started out as English, Portugese comments get posted and the language shifts to Portugese. I tried to imagine this happening on slashdot (for example, on this thread). At first I thought it wouldn't be any big deal. But then I thought, what if I was following a thread on slashdot, and suddenly it switched to Portugese. It'd be kinda like threadjacking. It's annoying to read an English thread, then someone posts a response in Portugese, because then I can no longer follow the thread. I'd like to read what that person said, but I can't. And any Portugese speaking people who were commenting would probably switch to Portugese if they posted any more comments too. Maybe I'll post something in English, and the response will be in Portugese. It really comes down to netiquette. Sure they have a right to comment however they want, it's just not polite to switch languages mid-stream. If you reverse roles (e.g. suppose I can read Portugese) and I post English comments in a thread that's all Portugese, then people start switching to posting in English, that would leave out all the Portugese-only people. Although creating a separate area may help somewhat, a better solution to the problem is just informing users how to behave better. If it was common knowledge, the community would police itself and frown upon that kind of behavior. I know polite internet conversation seems like an oxymoron to many, but for all the trolls and BS that gets posted on slashdot, it's pretty readable, and well-thought out arguments still happen.
He's talking about how you have to switch off all the AutoCrap(TM) in Word to actually make it usable.
From your post, I'd gather that you enjoy having a program tell you what you want to do. That's your choice, but it's not everybody's.
It may not be everybody's choice, but it's probably the choice of 80-90% of Word users.
The reason I want control over things like my webserver, right down to the most basic level, is so I can keep an eye on it, make sure the security configs are okay, and kill it if it gets compromised.
Now you're talking about something very different. Someone managing a webserver is very different from someone who buys a $10 game from Wal-Mart. The article was talking about the $10 game market, average customers, not you.
Mod parent up. This is a much more insightful comment than the first poster. The problem isn't simply overloading due to high power output, it's clipping. A DSP could potentially emulate the clipping characteristics of a tube, but apparently it's not a simple thing. And I think you'd need to use this DSP technology at serveral stages of the recording/playback process to be complete.
Dollar for dollar, transistor amplifiers output far more power before they're overloaded, making this discussion moot.
RTFA. The author is talking about overloading as in clipping. Most audio is clipped somewhere -- tube playback of clipped audio sounds better than a transistor circuit due to the harmonics it creates. Clipping can be done smoothly rather than abruptly leveling off.
I was talking about the write-up -- the quote was attributed to Akamai's servers, when it was actually talking about ISC's servers (ISC, not ITC as the write-up says).
Also, Paul Vixie is the founder of ISC, not ITC. What a shoddy article write-up -- two blatantly obvious mistakes I caught by skimming the articles got front-paged.
Mod parent up. I don't understand why this guy simply didn't use the XP firewall and be done with it. It would've worked better, and he wouldn't have had to install Norton BS. Plus, in step 11 HE TURNS ALL FIREWALLS OFF. Of course he's getting infected. I don't think many people have pointed that out, but he got infected because he turned off the damn firewall like an idiot. Reading MS's line on the subject: here, they say to turn off ANTIVIRUS, not firewall. So he probably turned off all of NISP, not just the AV portion.
I just wrote two programs to count to 1 billion. The one written in C took 2.4 seconds, the one written in assembly took 0.85 seconds. Wow, assembly is so much faster. My in-depth analysis of these two languages has shown once and for all that all us high-level language suckers need to get back to coding in assembly and quit this HLL foolishness.
It's a good guide since a lot more people are taking a lot of pictures where they wouldn't have done so before. One aspect that you may be missing is that with digital cameras, you're free to take a LOT of pictures and experiment and throw away the crap ones, while not spending a fortune on developing film. It kinda reminds me of how long-distance phone calls used to be a big deal, but now I don't even think about it on my cell phone because the cost barrier has been eliminated. When digital cameras were first becoming available as cheap consumer products, I bought one because I'd be able to store my photos on my computer, and I woulnd't have to get them developed. It had crummy resolution (480x360), but it got me hooked. My current camera is 4MP. The ability for your average home user to be able to take a lot of photos and not having to worry about making every picture count due to development costs is really a big advantage. I'm not saying film is going out -- film still has its own advantages which can be debated elsewhere, but for someone interested in photography, or just plain taking pictures for fun (I fit in this category), digital cameras are great. And tips like these are a good guide to all the people new to photography who wouldn't have been taking pictures if it weren't for digital cameras.
I'm not saying that they can't capture GET or POST, I'm just saying that having the username and password in the URL is uncommon and irrelevant. Besides, the contents of a POST request are not stored. And the original post basically said there would be too much data to sift through. You suggested that capturing browser history would help, but I don't think browser history would be particularly useful because of the aforementioned reasons.
Most passwords are submitted via POST not GET (so that URLs like that don't show up in your browser history). I'm not sure how that URL relates to keylogging, since most people wouldn't type in a URL like that anyway.
There's a difference between this and other distributed computing projects. Other DC projects have a "good of mankind" kind of goal to them, and are unlikely to be targeted maliciously. A commercial project like rendering a cartoon would have to be extra careful in regards to security. While crackers may feel it is wrong to disrupt or otherwise harm people trying to find a cure for cancer, they may find it funny to distort a rendered picture in a cartoon.
I'm thinking something along the lines of Tyler Durden here...
and just how do you think 'technology' improves? By directing resources at it!
The technology needed would require tremendous if not impossible resources at this time, and the benefits are not very likely. It'd be better to wait until the technology is more feasible.
Not everything has to have a purpose, or has to produce results to be considered worthwhile.
You're missing the point... people running SETI are trying to produce results that are worthwhile, and I'm saying that I think their efforts are futile and better directed toward something more immediate. I never claimed everything has to have a purpose of produce results. I know I'm probably feeding a troll, but I hope this clarifies things if you aren't trolling.
If aliens are found, they'd be so distant contacting them would be useless. And by the time technology to communicate with them quickly was created, probably the technology to find them would also be significantly advanced. SETI just seems like a project that should be put off until another day when technology has improved significantly (this kinda reminds me of the Slashdot discussion on manned Mars missions and arguments as to why it'd be a waste of resources at the present time).
True, and I'm just trying to convince you to donate to a different "charity":-] I've been running UD for 2 or 3 years now, and I'm getting interested in Folding@Home currently (it runs on Linux, unlike UD).
All you SETI people out there... if you want your CPU cycles to actually produce something useful, how about running Folding@Home or United Devices or some other medical research program. Looking for scant signs of aliens just seems fruitless compared to the more immediate problems that you could direct your CPU cycles at.
Slashdot Mirror
If it starts in Portugese, it should remain in Portugese, and English comments shouldn't be posted in that thread. It's the polite thing to do.
Here's one way of thinking about it. It seems the article is talking about users complaining that in a forum that started out as English, Portugese comments get posted and the language shifts to Portugese. I tried to imagine this happening on slashdot (for example, on this thread). At first I thought it wouldn't be any big deal. But then I thought, what if I was following a thread on slashdot, and suddenly it switched to Portugese. It'd be kinda like threadjacking. It's annoying to read an English thread, then someone posts a response in Portugese, because then I can no longer follow the thread. I'd like to read what that person said, but I can't. And any Portugese speaking people who were commenting would probably switch to Portugese if they posted any more comments too. Maybe I'll post something in English, and the response will be in Portugese. It really comes down to netiquette. Sure they have a right to comment however they want, it's just not polite to switch languages mid-stream. If you reverse roles (e.g. suppose I can read Portugese) and I post English comments in a thread that's all Portugese, then people start switching to posting in English, that would leave out all the Portugese-only people. Although creating a separate area may help somewhat, a better solution to the problem is just informing users how to behave better. If it was common knowledge, the community would police itself and frown upon that kind of behavior. I know polite internet conversation seems like an oxymoron to many, but for all the trolls and BS that gets posted on slashdot, it's pretty readable, and well-thought out arguments still happen.
Mod parent up. This is a much more insightful comment than the first poster. The problem isn't simply overloading due to high power output, it's clipping. A DSP could potentially emulate the clipping characteristics of a tube, but apparently it's not a simple thing. And I think you'd need to use this DSP technology at serveral stages of the recording/playback process to be complete.
I was talking about the write-up -- the quote was attributed to Akamai's servers, when it was actually talking about ISC's servers (ISC, not ITC as the write-up says).
Also, Paul Vixie is the founder of ISC, not ITC. What a shoddy article write-up -- two blatantly obvious mistakes I caught by skimming the articles got front-paged.
If I read it right, one of their problems was their lack of diversity -- they all use Akamai's proprietary DNS.
More information on Kevin Warwick, a.k.a. Captain Cyborg here: here, here, and here ;-)
The folks over at El Reg are bigs fans of him
The thing is, that's not true: Microsoft says to turn off antivirus, NOT FIREWALL.
Mod parent up. I don't understand why this guy simply didn't use the XP firewall and be done with it. It would've worked better, and he wouldn't have had to install Norton BS. Plus, in step 11 HE TURNS ALL FIREWALLS OFF. Of course he's getting infected. I don't think many people have pointed that out, but he got infected because he turned off the damn firewall like an idiot. Reading MS's line on the subject: here, they say to turn off ANTIVIRUS, not firewall. So he probably turned off all of NISP, not just the AV portion.
I just wrote two programs to count to 1 billion. The one written in C took 2.4 seconds, the one written in assembly took 0.85 seconds. Wow, assembly is so much faster. My in-depth analysis of these two languages has shown once and for all that all us high-level language suckers need to get back to coding in assembly and quit this HLL foolishness.
You just drew two lines in the sand. Now people won't know whether to mod you up or flame you.
It's a good guide since a lot more people are taking a lot of pictures where they wouldn't have done so before. One aspect that you may be missing is that with digital cameras, you're free to take a LOT of pictures and experiment and throw away the crap ones, while not spending a fortune on developing film. It kinda reminds me of how long-distance phone calls used to be a big deal, but now I don't even think about it on my cell phone because the cost barrier has been eliminated. When digital cameras were first becoming available as cheap consumer products, I bought one because I'd be able to store my photos on my computer, and I woulnd't have to get them developed. It had crummy resolution (480x360), but it got me hooked. My current camera is 4MP. The ability for your average home user to be able to take a lot of photos and not having to worry about making every picture count due to development costs is really a big advantage. I'm not saying film is going out -- film still has its own advantages which can be debated elsewhere, but for someone interested in photography, or just plain taking pictures for fun (I fit in this category), digital cameras are great. And tips like these are a good guide to all the people new to photography who wouldn't have been taking pictures if it weren't for digital cameras.
I'm not saying that they can't capture GET or POST, I'm just saying that having the username and password in the URL is uncommon and irrelevant. Besides, the contents of a POST request are not stored. And the original post basically said there would be too much data to sift through. You suggested that capturing browser history would help, but I don't think browser history would be particularly useful because of the aforementioned reasons.
Most passwords are submitted via POST not GET (so that URLs like that don't show up in your browser history). I'm not sure how that URL relates to keylogging, since most people wouldn't type in a URL like that anyway.
You know what they say... you can lead a cat to coffee, but you can't make it drink.
OT, but FYI his name is spelled Gandhi (Ghandi is a common misspelling -- I used to do the same thing until it was pointed out to me).
There's a difference between this and other distributed computing projects. Other DC projects have a "good of mankind" kind of goal to them, and are unlikely to be targeted maliciously. A commercial project like rendering a cartoon would have to be extra careful in regards to security. While crackers may feel it is wrong to disrupt or otherwise harm people trying to find a cure for cancer, they may find it funny to distort a rendered picture in a cartoon.
I'm thinking something along the lines of Tyler Durden here...
If aliens are found, they'd be so distant contacting them would be useless. And by the time technology to communicate with them quickly was created, probably the technology to find them would also be significantly advanced. SETI just seems like a project that should be put off until another day when technology has improved significantly (this kinda reminds me of the Slashdot discussion on manned Mars missions and arguments as to why it'd be a waste of resources at the present time).
True, and I'm just trying to convince you to donate to a different "charity" :-] I've been running UD for 2 or 3 years now, and I'm getting interested in Folding@Home currently (it runs on Linux, unlike UD).
All you SETI people out there... if you want your CPU cycles to actually produce something useful, how about running Folding@Home or United Devices or some other medical research program. Looking for scant signs of aliens just seems fruitless compared to the more immediate problems that you could direct your CPU cycles at.