Dude, we've had a front page article where the linked story actually linked to Hooters in Amsterdam. As far as I can tell, the editors don't bother checking any of the links on the stories and just post them if they sound plausible.
Which, by the way, is one of the reasons I refuse to subscribe to Slashdot. The ads don't bother me, I don't bother blocking them, and I see no added value in subscribing.
If I saw an improvement in the stories (as opposed to editorial attacks of other articles and stories posted where the editors obviously did not even check the links provided), then I might change my mind. But for now, I find that the most value is in reading the comments.
Oh, yeah, the performance testing I can do on my PII that I use to develop on is definately going to be valid. Oh, wait, maybe not. The only other machines I can test on would wind up having the database server locally, screwing up the tests. And how, exactly, do you propose I try Orion and Resin? I believe I would somehow magically have to obtain a license for them.
Here's a hint: if you want to be considered "objective," try avoiding phrases like "stop being a pussy" - it kinda paints you as being some immature kid.
And, without knowing exactly what the tests he's using are, it's quite possible that he's not actually testing Tomcat, but something else like the DB server or JVM. I mean, really, what do you want me to say? The article is useless as a benchmark because we have no idea what he's actually doing. And the fact that he explicitly says that he has no intention of explaining what it was he was doing kinda makes me think he has an agenda to see Tomcat fail for some reason.
But we'll see - I'll have to try coming up with some tests myself, and see what I come up with. I can't take the word of someone who comes off as having some kind of need to watch Tomcat crash and burn.
There are issues with that article that he doesn't mention. For example, what is his test page? Is he serving static content? Does he have Tomcat in "reload" mode (where it checks for updated code every time a servlet is executed)?
I can't help but think that this article is just poorly written. It doesn't really paint a clear picture of what he's using Tomcat for. He mentions nothing about the various configurations tested. It's way too easy to just write him off due to an overly evident bias against Tomcat from the beginning. (Hint: when attempting to persuade people, calling a benchmark test "Is Tomcat Crap?" reveals your bias...)
I use Tomcat at work as the development platform we use. We're probably going to be using Oracle Portal for the production system (not that I know what that is or what it uses for it's JSP engine, but...). It works fine for a development platform.
I haven't done any performance testing on it (yet), but when I get the chance, I might look into it. It'd be interesting to find out what my results are. I have a suspicision that Tomcat performed poorly in his "tests" because the other servlet engines came in an optimized for speed setting while Tomcat comes "optimized" for development.
Re:I've got your challange right here...
on
Haiku vs Spam
·
· Score: 3, Funny
Junkyard to fight spam
So the spammers must fight back
Then it's Junkyard Wars.
You can try my journal entry listing browser and OS usage statistics found off a mirror of a Slashdotted site.
I have a more detailed report - somewhere - that I can dust off, but for now, this'll have to do. Maybe it's time to try and get Slashdotted again to get some more up-to-date info... uh, on second thought, maybe not.
Because it was changed when the American publishers got the hang of it and the American publishers thought that it would sell better as "the Sorcerer's Stone" than "the Philsopher's Stone." Hence, when it was made into a movie, the producers didn't want to confuse American audiences by changing the name of the movie back to the original - so they shot two versions of every scene that mentions the stone.
I must, unfortunately, agree with the publishers that calling it "Sorcerer's Stone" would probably be better for an American audience. I had never managed to run into the term "philosopher's stone" before hearing the original title. If the book was not the first in the series, it probably would have been left untouched. But since it was the first in the series, people wouldn't immediately associate "Harry Potter" and "wizard." So by changing it to Sorcerer's Stone they ensured that people would know that it was about magic.
Since, obviously, us Yanks and our image-driven culture are definately going to notice the title first and ignore the cover art consisting of a boy and his various magic artifacts. Whatever.
- Mr. Potter, son of James Potter. No, I'm not kidding.
I am so sick and tired of Slashdot editors whining that "it's in the FAQ" - yeah, I know, but those seem like lazy excuses that boils down to "this'd be kinda difficult and we're way too lazy to attempt it."
Besides, I think all they really need to do is just e-mail the webmaster of the site they're linking too. If it's a big web site, then yes, go ahead, link directly to it. If it's got ads, then link to it. If it's obviously some hobbyist's webpage, then contact them first!
Although, this is the Internet, so apparently being polite is passe. *sigh*
Oh, and it's nice to see that Slashcode now removes all HTML entities, so I can't put a nice accent in over the e. Thanks.
I believe that Anti-Adblocker works by simply loading the page and then waiting for the browser to request the ad page. If no request is made, it assumes you have ad-blocking software and will not let you into the site. (Presumably by using something along the lines of <meta http-equiv="refresh" content="15, URL=followthrough.php"> and using JavaScript in the ad page to pop the page through immediately.)
In reality, this is a very easy script to create. If I cared, I could do it on my own. Personally, what I'll bet will happen sometime in the future is that a new web standard will be created whereby the keys to decrypt the content of a site are stored in the ads and only software that promises to display the ads can decrypt the content. Evil, but with the DMCA, probably effective.
Anyway, to allow Mozilla through Anti-Ad-Blocker, I'll bet all you have to do is set it up so that window.open calls don't just silently fail, but instead create an "invisible window" that allows the script and HTML to be loaded but not displayed. Since the direct ad pages are usually small HTML pages, this would probably work - the bandwidth usage would be small because the images wouldn't need to be loaded. But I can't be 100% sure...
Re:Slashdot to change? Not likely
on
Linuxworld Fun
·
· Score: 2
You are aware that almost all of Slashcode involves select from comments where sid=37919? Slashcode is almost all select statements - something which MySQL does quite well. In fact, MySQL is supposedly faster with simple SELECT statements than other, more feature-rich databases. Based on my very poor sampling, MySQL is indeed noticibly faster than Oracle when it comes to running a lot of SELECT statements in rapid succession. (Not that I don't take issues with the fact that the application loads the entire [expletive] database on startup which is where this "benchmark" comes from, but that's another story...)
Appart from SELECTing data to generate the pages, the next most common action Slashdot does is INSERT. Since MySQL contains an "AUTOINCREMENT" metatype, the ID fields need not be calculated as a transation - MySQL will ensure that an appropriate key is generated when the INSERT is run.
There are several sections of Slashcode that do updates - but for the most part, they don't need transactions or anything too fancy. Multiple requests to change a single user's parameters are rather unlikely, and for the most part, editors are unlikely to update the same story at the same time.
Bottom line is that MySQL is more that sufficient for Slashcode. (Just like MySQL is fine for the above mentioned application, even though it uses Oracle in the "production" environment. Poorly.) There's no need to use a more robust database - Slashcode simply isn't really that intensive a DB application. In fact, it could probably be rewritten to use text storage files instead of a database. I'll bet it would be possible to store Slashcode information in a miriade of XML files. I wouldn't suggest it, but it might be possible...
With Slashcode 2, much of the database code was moved out into a module (which should speak to the speghettiness of the original design), helping to solve move most of the MySQL dependencies (most notably, AUTOINCREMENT everywhere and TEXT blocks as opposed to LONG VARCHAR which is the ANSI SQL standard) into a modular section that can be replaced.
With the Postgres Slashcode module, it should be possible to move Slashdot onto other databases. But for the most part, there's little need to move Slashdot to another database - MySQL is sufficient for it's needs.
A complete code rewrite, on the other hand...:)
(I think they should reimplement it in a Java servlet environment. Because Java is my hammer. Ow, my thumb!)
I've seen two Slashdottings locally - one was to a mirror of some KDE screenshots (which is kinda funny, since I'm a GNOME user:)), and the other was the Linux Powered Christmas Tree.
Both were very small pages with relatively small downloads, and both survived the Slashdot effect relatively well. However, this is probably because both were behind an OC-48 connection to the Internet...
I don't know about the Christmas tree's load, but it was a P100 with 64MB RAM, and it surivived the load fairly well. (I think - it appears that everybody was able to access the tree and view it and several people were able to bitch about it "not really being a Linux powered Christmas tree" by either contesting it being a Christmas tree or by contesting it being "Linux powered" - but now is not the time or place to argue that. However, if posters could come to conclusions about that, then they probably could view the site.)
The bottom line is that most servers, assuming they aren't doing some serious server side scripting, can safely handle the Slashdot effect without melting down. The Slashdot Effect is almost always a bandwidth issue and can easily be compared with a DDOS attack - massive incoming requests and outgoing answers filling the available bandwidth. Except that in the case of a Slashdotting, the requests are all valid and are attempting to access the resource, and not just run it off the net.
And while the caching suggestion to help the Slashdot Effect has been given many, many times - enough to appear in the FAQ - the reality is that the editors should actually consider implementing it instead of just dismissing it. I still believe that the right thing to do is to contact the site authors and determine whether or not the site can handle the load. The stories are staggered anyway; seriously, this story could have safely waited a month or longer to come to a mutual agreement with the site operator about how to handle the load.
Six hours is nothing if it means the site won't get taken off the net due to excessive bandwidth usage.
In relation to the KDE links, I still have my server logs of the connections and would at some point like to try and give a better view of the Slashdot effect from the side of a server. For simple text articles, it's not that bad. For movies and large images, on the other hand, I'd imagine it could be a lot harsher. If anyone's interested, I could release the logs minus the IP information. Due to the state of flux my e-mail is currently in, either reply via Slashdot or simply send via Sourceforge - I'll find it:)
Ah well - for a time being, they were on different servers - I guess I missed when whoever it was who was hosting them in the US (they did used to have a US host - didn't they?) stopped. (Or where they always on the same servers, and I just thought they were hosted in the US? I could have sworn there was a time when the Reg USA was hosted in the US, and a lookup gave different IPs - doesn't really matter...)
And Reg US was also provided to try and move some traffic over to the US to allow American viewers an easier time with accessing the content. I suppose I could look through the archives to try and find out, but I've wasted enough of my work day as is:)
American readers (that's right, as in everyone in North America) might wanna try The USA Register site for (slightly) faster access since then you don't have to access a webserver that's across the pond.
I doubt Slashdot can Slashdot the Register, but it might help American readers, especially those who missed the creation of the USA Register. The USA Register is basically the same content as the Register, but it drops some of the UK specific news (as in, UK elections and other events that are unlikely to matter to people who don't live there). As far as I know, there is no US-specific content, but several of their writers turn out to live in the US - so who knows...
Wang is a company that is (used to be?) based in Massachusetts. They've since gone under - I think - but we still have the Wang Theater and used to have the Wang Towers. You can read about them here, but that mostly talks about what's replaced Wang in the towers.
This should be the same Wang - Wang was a word processor (as in the physical word processors with a little monochrome monitor attached to a typewritter) manufactorer and made some microcomputers, I think. But they missed out on the PC "revolution" and became a bit player. They eventually went bankrupt in the early 1990s, but apparently survived to as later as 1998.
Wang seems to have been bought out/changed it's name to Getronics, but their webpage still exists.
As far as I know, Wang is the name of the founder of the company - I don't remember which Asian nation he was from, but it's an Asian name. But yeah, Wang does seem like a weird name to use for a US company...:)
I wonder how likely it is that the type of people who attend cypherpunk meetings are also likely to have similar purchasing habits...
The only thing this is likely to do is make brief false trends immediately after the transfer, when a Pepsi drinker suddenly becomes a Cherry Coke drinker and remains that way for another stretch of time (I guessing monthly meetings? dunno...)
The real useful information is what people are likely to buy at one time and what sales and insentives where in place at the time. Just changing the cards doesn't really screw up this kind of information. I'd assume the database analysis takes into account changing trends over time, meaning that unless the card changes between people with wildly different purchasing habits fairly rapidly, it's still probably generating useful information. Especially because the vast majority of the cards are being used by people not trying to screw around with the system, and the small amount of invalid trend data is probably lost in the larger picture.
Although I'd guess the entire reason to change cards is to make it harder to track your purchases - meaning that you'd better hope that you and the person the card was swapped with usually shop at the same location and at similar times - otherwise it'd still be possible to guess the hands a card went through.
Unless you're anal enough to change shopping times and go to random locations to keep the amount of data down - which really seems pointless to me.
They can collect my purchasing data all they want for all I care - just don't try and mail me ads or call up to sell me crap. Gathering data that isn't shared with others - that I'm OK with. Trying to sell me junk repeatedly? That's a little more annoying...
You know how CVS (the drug store) has those "ExtraCare" cards? Well, I got one by simply trying to purchase the product that was on sale to card holders, and then basically saying "can you give me the card now?". Usually you have to hand in the form before they'll give you the card, but I got the card and form at the same time.
Still have the card, threw out the form.
It's actually very easy to get away with not filling in information. Just hand in the form with the bare minimum information filled in (name, incomplete address (no street given, missing the street number, etc), skip over the phone entries). As long as there is some writing on the form, the clerk will usually just accept it because they really don't care and really don't feel like confronting someone who's being difficult.
The other fun technique to use is to just scrawl completely illegibly. The person will usually glance at the form, decide you filled it out, and put it in the stack to be sent to the data-entry clerks. Dunno if they'll cancel your card if the data backing it is missing or invalid, but I've had no problems with getting advertising crap or with the card yet... (although one of the stupid key tag things broke).
If my TV and video use the same codes for the remote control, causing me to tape over my wedding video, who is responsible?
Your responsibility. The VCR behaved as it is supposed to - it started taping when receiving the RECORD command that happened to be the same as the TV's ON command. It behaved as expected, even if the operation was not what you desired. If the VCR accidently erased the tape because the TV overloaded the VCR's input or something, you might have a case against the makers TV - it is supposed to provide a certain level of input, but failed to do so.
If I buy a replacement wheel that comes off my car because the car and wheel manufacturers interpreted the specifications differently, who is responsible?
Either the person who installed the wheel and didn't notice that it wasn't fitting correctly, or the manufactorer of the wheel who failed to test the wheel intended for the car with the car modelis responsible. This is different from software in that the wheel is intended to function with the car, and failure to do so indicates a failure on behalf of the manufactorer. Unless you just underinflated your Firestone tires on your Ford Explorer:).
While the second example is closer to a situation you might have on a computer with a combination of software and hardware, it assumes a specific piece of "software" (get it - software - rubber tire - no?... ok) that is designed specifically to work with a well defined piece of hardware, the car.
A computer is not a well-defined piece of hardware and software - minor differences in the interaction between two well tested pieces of software can cause issues that were unexpected. In my example, Product A was designed to work with Version 1 of Product C - but not tested against Version 2, which fixes some bugs and introduces a new one that Product A accidently exploits.
If the software is poorly tested, then yes, it might be fair to make the vendor responsible. But outside of providing fixes in a reasonable period of time, how much more responsibility do you want them to take? Software warranties should either require vendors to either provide patches or indicate that the product will not work in certain scenarios - they shouldn't make the vendor financially responsible for damages when the damages were caused by a scenario that could not be predicted. Especially when the cause is a specific interaction between multiple components that causes the error and is not directly the fault of any individual component. (Like Blizzard games and my network card, which do not get along together. Blizzard game + My network card = BSOD. Really fun when you die in Diablo II due to a BSOD. At least StarCraft only crashes on exit, and Warcraft III just kills incoming/outgoing connections over the specific port used. But then again, it might not be either companies fault - I think Microsoft's Windows Update uploaded an incorrect driver for my network card. So who do I blame?...)
Actually, software warranties are a bad idea in almost all cases anyway.
The real problem with software is that it interacts with other software in a complex and often difficult to understand way. For example, if I discover that Product A managed to corrupt my hard drive and erase all my work, should the manufactorer of Product A be liable?
However, what if the reason Product A corrupted my hard drive was because Product B overwrote some of the libraries that Product A uses, causing an incompatibility. Now who is liable? The maker of Product A or Product B?
But for added fun, let's say that the libraries were part of Product C that both Product A and Product B use. And Product B overwrote Product A's libraries because it had a newer version of the software that supposedly had bug fixes in it. Now who is liable? Manufactorer A, B, or C?
For added fun, let's assume that the incompatibility was actually caused due to a bug in the BIOS, that caused data corruption when sending data to the harddrive. Now who's liable? A, B, C, or D - the manufactorer of the BIOS?
But we're not done yet. It turns out that the command the BIOS sends to the harddrive is invalid, and should cause the hard drive to signal an error back to the BIOS. But because of buggy firmware, it instead writes random data to a random location. So a combination of A, B, C, D, and a hard drive with buggy firmware by E is what caused the data corruption. So when A, B, C, D, and then E - the buggy harddrive - combine, your data can be corrupted.
So - who's responsible? Is A responsible - they bug tested their software with Version 1 of Product C. But Product B installed Version 2 of Product C. So is Product A or Product B the actual culprit? Or is Version 2 of Product C responsible? But then again, Product C only caused a bug in the BIOS - which gave a command to the harddrive that should have caused an error but instead caused data to be written in the wrong fashion.
The real problem with software is that frequently bugs can come up when there are weird combinations of hardware and software that cause software to enter into states that the manufactorer never expected. Plus when you throw viruses and programs that alter the way fundamental components of the OS interact (think drivers, debuggers, or special programs like display "enhancers" or firewalls), the total number of combinations that might cause damage rise incredibly, and it become infeasable to anticipate and test every combination.
Especially when it works in the test lab with 100% accuracy, because the test lab does not have the fatal combination of software and hardware that eventually causes damage. So even though every manufactorer tested their component to work assuming everything else was working properly, when one thing turns out to generate a slightly wrong command, a whole chain of incompatibilies can result. Making software warranties a huge blame game.
Software warranties are really only feasable for a given configuration, with the user understanding that installing new software or hardware and making certain configuration changes will void the warranty. Which makes them next to useless anyway. And if the software manufactorer releases a patch to fix a known issue, are they liable for the issue anymore if people do not install the patch within a reasonable amount of time?
Responsibility is fine, but sometimes responsibility just means providing a fix and telling people of known issues. It is impossible to warrant against every possible condition. This is why most warranties specifically disclaim liability if the owner uses the device in a fashion that is unintended - the manufactorer cannot warrant the device "work" in a scenario that it is not supposed to be used in.
I didn't find that comment - but I did find this one, about 35 comments down:
[Thumbs Up] Commander Taco ---- 05-Aug-2002 11:17:21 AM
Features........ O O O O O (5) Ease of Use..... O O O O O (5) Output Quality.. O O O O O (5) Speed........... O O O O O (5)
"Wow! The best of its kind I have seen!"
This is an incredibly well made piece of software. It completely outperforms CDEX and the SpyWare is only enabled if you request it, and in return, you get 100+ free songs. This completely rocks. Don't use anything but this!
I didn't know Taco was using Windows now. Good to know he endorces this great piece of adware.
Hehe - that just brought to mind the time when my Dad managed to lock his keys (and medication) in his car at a Boy Scout camp. (The medication has to be kept out of the hands of the ever-so-irresponsible Boy Scouts, you see.) So he calls a local locksmith. The locksmith plays around with the door for a while, then finally gives up, takes out a blank and a key-cutter, and produces a duplicate key based on the keys sitting on the front seat. Took him about 30 seconds to cut a new key from the time he decides to do so to openning the door.
I also remember watching a program on repo men where they had some expert locksmith come along while they were reposessing a RV - you know, those big campers? He sticks a blank into the keyhole, moves it around a while, takes it out, analyzes the scratches made on the key, and starts cutting it. Then sticks in the now-cut blank, trys again, and fine-tunes it. Within a minute, he's cut a brand new key based off only the blank and the existing lock.
Pretty damned cool - assuming that only the good guys have that tech. Are repo men good guys? I dunno...
Well, to try and jump back to the topic of the story, I really don't see a problem with a national ID number - as long as there is a way to verify that the person using the number is actually the person issued the number. Similar to a PIN code on your ATM card - give everyone smart cards and have them verify themselves when completing a transaction that requires a verified identity. It would make forging quite a lot harder. Having an identity and a method of verifying the idenity is a good thing, in my opinion. The problem comes when all that's needed to forge an identity is a number that can be obtained off many records.
I find it rather amusing that Google would correct the spelling on a bunch of basically random letters... Especially when:
Your search -
aa ae ao eaee eo oa oo oo dork - did not match any documents.
I always wondered if they checked if the corrections brought in more results - now I guess I know that they don't. Presumably they look for keywords that are similar to ones presented that have a higher hit rate on the web than the ones given.
And, for the terminally lazy:
$./configure Please read through the following license agreement:
Pages of boring and dry text
Do you agree (y/N):
You already have to do this with the Sun Java runtime for Linux, which is distributed in a "self extracting TAR ball" - read "sh script which pipes most of its contents to gzip and then tar after displaying the license with less or, failing that, more, and then asking the user to enter a 'y' character is signify agreement." You can also get a "self extracting RPM" which is in essence the same thing, but instead of producing a TAR ball it produces an RPM.
So yeah, it's doable - it may not be very NICE, but it's doable...
Besides, with large software packages that share the same license (be it GPL or random proprietary) you just need to accept one copy of it before installing. That's how you can get away with "accepting" the license agreements packed in with most MS updates - a license is displayed that covers all the individual "components."
I'm not going to say that I enjoy click through licensing, just that it is possible in console mode and with software applications. I'm not going to try and draw any conclusions on its use or the need for it - just demonstrate how others have solved the problem.
I didn't say it would make it impossible - just harder. Yeah, you could sniff out the MAC address and act as a transparent proxy. But that involves a bit more coding than just knowing the standard C sockets library, since that's getting down into the network layer. (Transport layer? I can't remember the name - the Ethernet layer as opposed to the IP layer.)
Nothing is really impossible - the key is making it more difficult than worth it. Especially when it'd probably be far easier to just root one of the "authorized" machines, since my school is on the Internet with no firewall, and my work contains the brilliant engineers who leave their passwords on little sticky notes up on their monitors to ensure that other people who want to use their computer can. Really.
(Or add Guest to the Administrators group, or set the root password to "password" or "${COMPANY_NAME}", or...)
Where I work and where I go to college (two different places), the network is triggered based on MAC address. Only verified MAC addresses can access the gateway.
Where I work, the DHCP server will only give IPs out to systems that have valid MAC addresses - beyond that, I can't tell you anything. I believe you can't get the routers to route traffic with an invalid MAC address, but I'm not sure about that - haven't had the opertunity or the need to test it. (However, I have had my office machine be "forgotten" about, and it took them a full day to update the DHCP server to allow me back on the network.)
My school is a step more anal - MAC addresses are tied to specific ports - not just drops, individual ports in the dorm rooms. If an invalid MAC address is detected on a port, then the port is deactivated until NetOps is notified and it can take a while to have it reactivated. The ports are also theoretically designed to deactivate if the computer connected to them is operating in promiscous mode, but I'm unsure as to how this is accomplished.
While it is of course possible to - um, "spoof" - a MAC address, tieing the drops by MAC address makes it quite a lot harder for invalid systems to just be dropped onto the network. It means that a tunnel cannot just be established by plugging the box into the network - some actual work would be required. At work, all the drops are always active, and I'd bet you can set a static IP. But at my school, where the drops are tied to MAC address, you'd have to find a port where your box can exist without knocking the original computer offline - a considerably more difficult task than just plugging the box into the network.
Personally, if there are people out there who know something I use is vulnerable, I want to know as soon as possible, rather than wait until I'm sure I can get the patch.
Yeah, but the Slashdotting also prevented people from reading that actual advisory (which, being just text, probably could have been cached fairly easily...).
Reading the advisory indicates that the problems are only in SSL2 client side, and SSL3 both sides. Plus there is a potential problem on 64 bit systems. The other important bit of information was also rendered difficult to read:
Servers can disable SSL2, alternatively disable all applications using SSL or TLS until the patches are applied. Users of 0.9.7 pre-release versions with Kerberos enabled will also have to disable Kerberos.
Client should be disabled altogether until the patches are applied.
(And an ASN2 library exploit, I think.)
Now luckily, some Slashdot posters got the advisory and posted the text to Slashdot. But still, not just in this case but in others, it seems like it would be a small price to pay to just ask the site owner if they can post the story and if they need help with bandwidth issues. Besides, the six hour figure is made up anyway - the site could respond far quicker than that, or far later. It depends. And since many times, the "breaking news story" is something relatively foolish like Lego desks, there is little to be lost in waiting a day for a response from the owner.
Except potentially knocking the content offline and causing untold expenses on the owner's end.
Re:The Slashdot effect - enough is enough
on
OpenSSL Security Update
·
· Score: 3, Insightful
I've posted this rant before, but it seems appropriate to reiterate again in response to Slashdot killing the OpenSSL servers. As most people know, CmdrTaco gives a reason for not caching pages in the FAQ. Quotes from the FAQ answer:
Sure, it's a great idea, but it has a lot of implications. For example, commercial sites rely on their banner ads to generate revenue. If I cache one of their pages, this will mess with their statistics, and mess with their banner ads. In other words, this will piss them off.
Fair enough, and I agree - commerical sites probably would rather see the direct flow of visitors. However...
Of course, most of the time, the commercial sites that actually have income from banner ads easily withstand the Slashdot Effect. So perhaps we could draw the line at sites that don't have ads. They are, after all, much more likely to buckle under the pressure of all those unexpected hits.
Like OpenSSL - they are not commerical and cannot be expected to withstand the load of a Slashdotting and whatever other security lists have posted this.
But what happens if I cache the site, and they update themselves? Once again, I'm transmitting data that I shouldn't be, only this time my cache is out of date!
Well, yeah, that could be a problem. But then you get to:
I could try asking permission, but do you want to wait 6 hours for a cool breaking story while we wait for permission to link someone?
Well, yeah! I'd love to wait six hours to read a cool breaking story if it means I get to read the linked content or the mirrors have time to update. It sure beats waiting a day for the Slashdot effect to have worn off and for the servers to be responsive again, or pissing off all the mirror operators who now can't get at the content they intend to mirror.
Bottom line, I think contacting the owners of sites that probably cannot withstand the Slashdot Effect would be common courtesy - and possibly avoid some of the embarassments we've seen with Slashdot posting news of a release that hasn't actually happened.
So while caching content may not be the best answer, at least contact the site operators. They might tell you to wait, or to use a mirror, or at least know that they can expect higher load for a while and can possibly reduce load on their end. It just seems like the smart and courteous thing to do.
(And if anyone wants to question "a day" as for how long the Slashdot Effect lasts, yeah, I'm being overly drammatic. The Slashdot Effect generally lasts for around four hours on a site and then starts tappering off (with peak transfer from about 10 minutes after the link goes up to around 2 hours). Obviously, if there's a lot of data to transfer, the effect lasts longer. This is based on both the data transfer graphs generated with the Linux-powered Christmas tree and when I posted a mirror of KDE screenshots. Depending on the vitality of the content, like security updates, though, it's better to wait for the mirrors to get the content then to just send everyone looking all at once.)
Slashdot Mirror
Which, by the way, is one of the reasons I refuse to subscribe to Slashdot. The ads don't bother me, I don't bother blocking them, and I see no added value in subscribing.
If I saw an improvement in the stories (as opposed to editorial attacks of other articles and stories posted where the editors obviously did not even check the links provided), then I might change my mind. But for now, I find that the most value is in reading the comments.
Here's a hint: if you want to be considered "objective," try avoiding phrases like "stop being a pussy" - it kinda paints you as being some immature kid.
And, without knowing exactly what the tests he's using are, it's quite possible that he's not actually testing Tomcat, but something else like the DB server or JVM. I mean, really, what do you want me to say? The article is useless as a benchmark because we have no idea what he's actually doing. And the fact that he explicitly says that he has no intention of explaining what it was he was doing kinda makes me think he has an agenda to see Tomcat fail for some reason.
But we'll see - I'll have to try coming up with some tests myself, and see what I come up with. I can't take the word of someone who comes off as having some kind of need to watch Tomcat crash and burn.
I can't help but think that this article is just poorly written. It doesn't really paint a clear picture of what he's using Tomcat for. He mentions nothing about the various configurations tested. It's way too easy to just write him off due to an overly evident bias against Tomcat from the beginning. (Hint: when attempting to persuade people, calling a benchmark test "Is Tomcat Crap?" reveals your bias...)
I use Tomcat at work as the development platform we use. We're probably going to be using Oracle Portal for the production system (not that I know what that is or what it uses for it's JSP engine, but...). It works fine for a development platform.
I haven't done any performance testing on it (yet), but when I get the chance, I might look into it. It'd be interesting to find out what my results are. I have a suspicision that Tomcat performed poorly in his "tests" because the other servlet engines came in an optimized for speed setting while Tomcat comes "optimized" for development.
Junkyard to fight spam
So the spammers must fight back
Then it's Junkyard Wars.
I have a more detailed report - somewhere - that I can dust off, but for now, this'll have to do. Maybe it's time to try and get Slashdotted again to get some more up-to-date info... uh, on second thought, maybe not.
I must, unfortunately, agree with the publishers that calling it "Sorcerer's Stone" would probably be better for an American audience. I had never managed to run into the term "philosopher's stone" before hearing the original title. If the book was not the first in the series, it probably would have been left untouched. But since it was the first in the series, people wouldn't immediately associate "Harry Potter" and "wizard." So by changing it to Sorcerer's Stone they ensured that people would know that it was about magic.
Since, obviously, us Yanks and our image-driven culture are definately going to notice the title first and ignore the cover art consisting of a boy and his various magic artifacts. Whatever.
I am so sick and tired of Slashdot editors whining that "it's in the FAQ" - yeah, I know, but those seem like lazy excuses that boils down to "this'd be kinda difficult and we're way too lazy to attempt it."
Besides, I think all they really need to do is just e-mail the webmaster of the site they're linking too. If it's a big web site, then yes, go ahead, link directly to it. If it's got ads, then link to it. If it's obviously some hobbyist's webpage, then contact them first!
Although, this is the Internet, so apparently being polite is passe. *sigh*
Oh, and it's nice to see that Slashcode now removes all HTML entities, so I can't put a nice accent in over the e. Thanks.
In reality, this is a very easy script to create. If I cared, I could do it on my own. Personally, what I'll bet will happen sometime in the future is that a new web standard will be created whereby the keys to decrypt the content of a site are stored in the ads and only software that promises to display the ads can decrypt the content. Evil, but with the DMCA, probably effective.
Anyway, to allow Mozilla through Anti-Ad-Blocker, I'll bet all you have to do is set it up so that window.open calls don't just silently fail, but instead create an "invisible window" that allows the script and HTML to be loaded but not displayed. Since the direct ad pages are usually small HTML pages, this would probably work - the bandwidth usage would be small because the images wouldn't need to be loaded. But I can't be 100% sure...
Appart from SELECTing data to generate the pages, the next most common action Slashdot does is INSERT. Since MySQL contains an "AUTOINCREMENT" metatype, the ID fields need not be calculated as a transation - MySQL will ensure that an appropriate key is generated when the INSERT is run.
There are several sections of Slashcode that do updates - but for the most part, they don't need transactions or anything too fancy. Multiple requests to change a single user's parameters are rather unlikely, and for the most part, editors are unlikely to update the same story at the same time.
Bottom line is that MySQL is more that sufficient for Slashcode. (Just like MySQL is fine for the above mentioned application, even though it uses Oracle in the "production" environment. Poorly.) There's no need to use a more robust database - Slashcode simply isn't really that intensive a DB application. In fact, it could probably be rewritten to use text storage files instead of a database. I'll bet it would be possible to store Slashcode information in a miriade of XML files. I wouldn't suggest it, but it might be possible...
With Slashcode 2, much of the database code was moved out into a module (which should speak to the speghettiness of the original design), helping to solve move most of the MySQL dependencies (most notably, AUTOINCREMENT everywhere and TEXT blocks as opposed to LONG VARCHAR which is the ANSI SQL standard) into a modular section that can be replaced.
With the Postgres Slashcode module, it should be possible to move Slashdot onto other databases. But for the most part, there's little need to move Slashdot to another database - MySQL is sufficient for it's needs.
A complete code rewrite, on the other hand... :)
(I think they should reimplement it in a Java servlet environment. Because Java is my hammer. Ow, my thumb!)
Both were very small pages with relatively small downloads, and both survived the Slashdot effect relatively well. However, this is probably because both were behind an OC-48 connection to the Internet...
I don't know about the Christmas tree's load, but it was a P100 with 64MB RAM, and it surivived the load fairly well. (I think - it appears that everybody was able to access the tree and view it and several people were able to bitch about it "not really being a Linux powered Christmas tree" by either contesting it being a Christmas tree or by contesting it being "Linux powered" - but now is not the time or place to argue that. However, if posters could come to conclusions about that, then they probably could view the site.)
The bottom line is that most servers, assuming they aren't doing some serious server side scripting, can safely handle the Slashdot effect without melting down. The Slashdot Effect is almost always a bandwidth issue and can easily be compared with a DDOS attack - massive incoming requests and outgoing answers filling the available bandwidth. Except that in the case of a Slashdotting, the requests are all valid and are attempting to access the resource, and not just run it off the net.
And while the caching suggestion to help the Slashdot Effect has been given many, many times - enough to appear in the FAQ - the reality is that the editors should actually consider implementing it instead of just dismissing it. I still believe that the right thing to do is to contact the site authors and determine whether or not the site can handle the load. The stories are staggered anyway; seriously, this story could have safely waited a month or longer to come to a mutual agreement with the site operator about how to handle the load.
Six hours is nothing if it means the site won't get taken off the net due to excessive bandwidth usage.
In relation to the KDE links, I still have my server logs of the connections and would at some point like to try and give a better view of the Slashdot effect from the side of a server. For simple text articles, it's not that bad. For movies and large images, on the other hand, I'd imagine it could be a lot harsher. If anyone's interested, I could release the logs minus the IP information. Due to the state of flux my e-mail is currently in, either reply via Slashdot or simply send via Sourceforge - I'll find it :)
And Reg US was also provided to try and move some traffic over to the US to allow American viewers an easier time with accessing the content. I suppose I could look through the archives to try and find out, but I've wasted enough of my work day as is :)
The story is available on the US site.
I doubt Slashdot can Slashdot the Register, but it might help American readers, especially those who missed the creation of the USA Register. The USA Register is basically the same content as the Register, but it drops some of the UK specific news (as in, UK elections and other events that are unlikely to matter to people who don't live there). As far as I know, there is no US-specific content, but several of their writers turn out to live in the US - so who knows...
This should be the same Wang - Wang was a word processor (as in the physical word processors with a little monochrome monitor attached to a typewritter) manufactorer and made some microcomputers, I think. But they missed out on the PC "revolution" and became a bit player. They eventually went bankrupt in the early 1990s, but apparently survived to as later as 1998.
Wang seems to have been bought out/changed it's name to Getronics, but their webpage still exists.
As far as I know, Wang is the name of the founder of the company - I don't remember which Asian nation he was from, but it's an Asian name. But yeah, Wang does seem like a weird name to use for a US company... :)
The only thing this is likely to do is make brief false trends immediately after the transfer, when a Pepsi drinker suddenly becomes a Cherry Coke drinker and remains that way for another stretch of time (I guessing monthly meetings? dunno...)
The real useful information is what people are likely to buy at one time and what sales and insentives where in place at the time. Just changing the cards doesn't really screw up this kind of information. I'd assume the database analysis takes into account changing trends over time, meaning that unless the card changes between people with wildly different purchasing habits fairly rapidly, it's still probably generating useful information. Especially because the vast majority of the cards are being used by people not trying to screw around with the system, and the small amount of invalid trend data is probably lost in the larger picture.
Although I'd guess the entire reason to change cards is to make it harder to track your purchases - meaning that you'd better hope that you and the person the card was swapped with usually shop at the same location and at similar times - otherwise it'd still be possible to guess the hands a card went through.
Unless you're anal enough to change shopping times and go to random locations to keep the amount of data down - which really seems pointless to me.
They can collect my purchasing data all they want for all I care - just don't try and mail me ads or call up to sell me crap. Gathering data that isn't shared with others - that I'm OK with. Trying to sell me junk repeatedly? That's a little more annoying...
Still have the card, threw out the form.
It's actually very easy to get away with not filling in information. Just hand in the form with the bare minimum information filled in (name, incomplete address (no street given, missing the street number, etc), skip over the phone entries). As long as there is some writing on the form, the clerk will usually just accept it because they really don't care and really don't feel like confronting someone who's being difficult.
The other fun technique to use is to just scrawl completely illegibly. The person will usually glance at the form, decide you filled it out, and put it in the stack to be sent to the data-entry clerks. Dunno if they'll cancel your card if the data backing it is missing or invalid, but I've had no problems with getting advertising crap or with the card yet... (although one of the stupid key tag things broke).
Your responsibility. The VCR behaved as it is supposed to - it started taping when receiving the RECORD command that happened to be the same as the TV's ON command. It behaved as expected, even if the operation was not what you desired. If the VCR accidently erased the tape because the TV overloaded the VCR's input or something, you might have a case against the makers TV - it is supposed to provide a certain level of input, but failed to do so.
If I buy a replacement wheel that comes off my car because the car and wheel manufacturers interpreted the specifications differently, who is responsible?
Either the person who installed the wheel and didn't notice that it wasn't fitting correctly, or the manufactorer of the wheel who failed to test the wheel intended for the car with the car modelis responsible. This is different from software in that the wheel is intended to function with the car, and failure to do so indicates a failure on behalf of the manufactorer. Unless you just underinflated your Firestone tires on your Ford Explorer :).
While the second example is closer to a situation you might have on a computer with a combination of software and hardware, it assumes a specific piece of "software" (get it - software - rubber tire - no? ... ok) that is designed specifically to work with a well defined piece of hardware, the car.
A computer is not a well-defined piece of hardware and software - minor differences in the interaction between two well tested pieces of software can cause issues that were unexpected. In my example, Product A was designed to work with Version 1 of Product C - but not tested against Version 2, which fixes some bugs and introduces a new one that Product A accidently exploits.
If the software is poorly tested, then yes, it might be fair to make the vendor responsible. But outside of providing fixes in a reasonable period of time, how much more responsibility do you want them to take? Software warranties should either require vendors to either provide patches or indicate that the product will not work in certain scenarios - they shouldn't make the vendor financially responsible for damages when the damages were caused by a scenario that could not be predicted. Especially when the cause is a specific interaction between multiple components that causes the error and is not directly the fault of any individual component. (Like Blizzard games and my network card, which do not get along together. Blizzard game + My network card = BSOD. Really fun when you die in Diablo II due to a BSOD. At least StarCraft only crashes on exit, and Warcraft III just kills incoming/outgoing connections over the specific port used. But then again, it might not be either companies fault - I think Microsoft's Windows Update uploaded an incorrect driver for my network card. So who do I blame?...)
The real problem with software is that it interacts with other software in a complex and often difficult to understand way. For example, if I discover that Product A managed to corrupt my hard drive and erase all my work, should the manufactorer of Product A be liable?
However, what if the reason Product A corrupted my hard drive was because Product B overwrote some of the libraries that Product A uses, causing an incompatibility. Now who is liable? The maker of Product A or Product B?
But for added fun, let's say that the libraries were part of Product C that both Product A and Product B use. And Product B overwrote Product A's libraries because it had a newer version of the software that supposedly had bug fixes in it. Now who is liable? Manufactorer A, B, or C?
For added fun, let's assume that the incompatibility was actually caused due to a bug in the BIOS, that caused data corruption when sending data to the harddrive. Now who's liable? A, B, C, or D - the manufactorer of the BIOS?
But we're not done yet. It turns out that the command the BIOS sends to the harddrive is invalid, and should cause the hard drive to signal an error back to the BIOS. But because of buggy firmware, it instead writes random data to a random location. So a combination of A, B, C, D, and a hard drive with buggy firmware by E is what caused the data corruption. So when A, B, C, D, and then E - the buggy harddrive - combine, your data can be corrupted.
So - who's responsible? Is A responsible - they bug tested their software with Version 1 of Product C. But Product B installed Version 2 of Product C. So is Product A or Product B the actual culprit? Or is Version 2 of Product C responsible? But then again, Product C only caused a bug in the BIOS - which gave a command to the harddrive that should have caused an error but instead caused data to be written in the wrong fashion.
The real problem with software is that frequently bugs can come up when there are weird combinations of hardware and software that cause software to enter into states that the manufactorer never expected. Plus when you throw viruses and programs that alter the way fundamental components of the OS interact (think drivers, debuggers, or special programs like display "enhancers" or firewalls), the total number of combinations that might cause damage rise incredibly, and it become infeasable to anticipate and test every combination.
Especially when it works in the test lab with 100% accuracy, because the test lab does not have the fatal combination of software and hardware that eventually causes damage. So even though every manufactorer tested their component to work assuming everything else was working properly, when one thing turns out to generate a slightly wrong command, a whole chain of incompatibilies can result. Making software warranties a huge blame game.
Software warranties are really only feasable for a given configuration, with the user understanding that installing new software or hardware and making certain configuration changes will void the warranty. Which makes them next to useless anyway. And if the software manufactorer releases a patch to fix a known issue, are they liable for the issue anymore if people do not install the patch within a reasonable amount of time?
Responsibility is fine, but sometimes responsibility just means providing a fix and telling people of known issues. It is impossible to warrant against every possible condition. This is why most warranties specifically disclaim liability if the owner uses the device in a fashion that is unintended - the manufactorer cannot warrant the device "work" in a scenario that it is not supposed to be used in.
I didn't know Taco was using Windows now. Good to know he endorces this great piece of adware.
I also remember watching a program on repo men where they had some expert locksmith come along while they were reposessing a RV - you know, those big campers? He sticks a blank into the keyhole, moves it around a while, takes it out, analyzes the scratches made on the key, and starts cutting it. Then sticks in the now-cut blank, trys again, and fine-tunes it. Within a minute, he's cut a brand new key based off only the blank and the existing lock.
Pretty damned cool - assuming that only the good guys have that tech. Are repo men good guys? I dunno...
Well, to try and jump back to the topic of the story, I really don't see a problem with a national ID number - as long as there is a way to verify that the person using the number is actually the person issued the number. Similar to a PIN code on your ATM card - give everyone smart cards and have them verify themselves when completing a transaction that requires a verified identity. It would make forging quite a lot harder. Having an identity and a method of verifying the idenity is a good thing, in my opinion. The problem comes when all that's needed to forge an identity is a number that can be obtained off many records.
I find it rather amusing that Google would correct the spelling on a bunch of basically random letters... Especially when:
I always wondered if they checked if the corrections brought in more results - now I guess I know that they don't. Presumably they look for keywords that are similar to ones presented that have a higher hit rate on the web than the ones given. And, for the terminally lazy:
Please read through the following license agreement:
Pages of boring and dry text
Do you agree (y/N):
You already have to do this with the Sun Java runtime for Linux, which is distributed in a "self extracting TAR ball" - read "sh script which pipes most of its contents to gzip and then tar after displaying the license with less or, failing that, more, and then asking the user to enter a 'y' character is signify agreement." You can also get a "self extracting RPM" which is in essence the same thing, but instead of producing a TAR ball it produces an RPM.
So yeah, it's doable - it may not be very NICE, but it's doable...
Besides, with large software packages that share the same license (be it GPL or random proprietary) you just need to accept one copy of it before installing. That's how you can get away with "accepting" the license agreements packed in with most MS updates - a license is displayed that covers all the individual "components."
I'm not going to say that I enjoy click through licensing, just that it is possible in console mode and with software applications. I'm not going to try and draw any conclusions on its use or the need for it - just demonstrate how others have solved the problem.
Nothing is really impossible - the key is making it more difficult than worth it. Especially when it'd probably be far easier to just root one of the "authorized" machines, since my school is on the Internet with no firewall, and my work contains the brilliant engineers who leave their passwords on little sticky notes up on their monitors to ensure that other people who want to use their computer can. Really.
(Or add Guest to the Administrators group, or set the root password to "password" or "${COMPANY_NAME}", or...)
Where I work, the DHCP server will only give IPs out to systems that have valid MAC addresses - beyond that, I can't tell you anything. I believe you can't get the routers to route traffic with an invalid MAC address, but I'm not sure about that - haven't had the opertunity or the need to test it. (However, I have had my office machine be "forgotten" about, and it took them a full day to update the DHCP server to allow me back on the network.)
My school is a step more anal - MAC addresses are tied to specific ports - not just drops, individual ports in the dorm rooms. If an invalid MAC address is detected on a port, then the port is deactivated until NetOps is notified and it can take a while to have it reactivated. The ports are also theoretically designed to deactivate if the computer connected to them is operating in promiscous mode, but I'm unsure as to how this is accomplished.
While it is of course possible to - um, "spoof" - a MAC address, tieing the drops by MAC address makes it quite a lot harder for invalid systems to just be dropped onto the network. It means that a tunnel cannot just be established by plugging the box into the network - some actual work would be required. At work, all the drops are always active, and I'd bet you can set a static IP. But at my school, where the drops are tied to MAC address, you'd have to find a port where your box can exist without knocking the original computer offline - a considerably more difficult task than just plugging the box into the network.
Yeah, but the Slashdotting also prevented people from reading that actual advisory (which, being just text, probably could have been cached fairly easily...).
Reading the advisory indicates that the problems are only in SSL2 client side, and SSL3 both sides. Plus there is a potential problem on 64 bit systems. The other important bit of information was also rendered difficult to read:
(And an ASN2 library exploit, I think.)
Now luckily, some Slashdot posters got the advisory and posted the text to Slashdot. But still, not just in this case but in others, it seems like it would be a small price to pay to just ask the site owner if they can post the story and if they need help with bandwidth issues. Besides, the six hour figure is made up anyway - the site could respond far quicker than that, or far later. It depends. And since many times, the "breaking news story" is something relatively foolish like Lego desks, there is little to be lost in waiting a day for a response from the owner.
Except potentially knocking the content offline and causing untold expenses on the owner's end.
Sure, it's a great idea, but it has a lot of implications. For example, commercial sites rely on their banner ads to generate revenue. If I cache one of their pages, this will mess with their statistics, and mess with their banner ads. In other words, this will piss them off.
Fair enough, and I agree - commerical sites probably would rather see the direct flow of visitors. However...
Of course, most of the time, the commercial sites that actually have income from banner ads easily withstand the Slashdot Effect. So perhaps we could draw the line at sites that don't have ads. They are, after all, much more likely to buckle under the pressure of all those unexpected hits.
Like OpenSSL - they are not commerical and cannot be expected to withstand the load of a Slashdotting and whatever other security lists have posted this.
But what happens if I cache the site, and they update themselves? Once again, I'm transmitting data that I shouldn't be, only this time my cache is out of date!
Well, yeah, that could be a problem. But then you get to:
I could try asking permission, but do you want to wait 6 hours for a cool breaking story while we wait for permission to link someone?
Well, yeah! I'd love to wait six hours to read a cool breaking story if it means I get to read the linked content or the mirrors have time to update. It sure beats waiting a day for the Slashdot effect to have worn off and for the servers to be responsive again, or pissing off all the mirror operators who now can't get at the content they intend to mirror.
Bottom line, I think contacting the owners of sites that probably cannot withstand the Slashdot Effect would be common courtesy - and possibly avoid some of the embarassments we've seen with Slashdot posting news of a release that hasn't actually happened.
So while caching content may not be the best answer, at least contact the site operators. They might tell you to wait, or to use a mirror, or at least know that they can expect higher load for a while and can possibly reduce load on their end. It just seems like the smart and courteous thing to do.
(And if anyone wants to question "a day" as for how long the Slashdot Effect lasts, yeah, I'm being overly drammatic. The Slashdot Effect generally lasts for around four hours on a site and then starts tappering off (with peak transfer from about 10 minutes after the link goes up to around 2 hours). Obviously, if there's a lot of data to transfer, the effect lasts longer. This is based on both the data transfer graphs generated with the Linux-powered Christmas tree and when I posted a mirror of KDE screenshots. Depending on the vitality of the content, like security updates, though, it's better to wait for the mirrors to get the content then to just send everyone looking all at once.)