I got into this discussion once before with someone else here on Slashdot. I subscribe excusively to advertisement-free publications. Pennsylvania Magazine, Birds & Blooms, Backyard Living, to name a few. These publications are small ones, hence their production overhead is more significant to their bottom line, yet they can survive free of advertising. The National Geographic model (which typically includes only one car advertisment on the inside cover or something; I don't actually subscribe to this one) says to me that magazines are sustainable sans-advertising, or at least with much less advertising, and that it's pure greed that puts most advertisements in these periodicals.
National Geographic has much higher production costs than most fluff magazines (such as Reader's Digest), since they do things like foot multiple-year expeditions to the rain forest, and generally produce a much higher quality, and longer (thicker) digest, but yet still turn a profit with only one ad.
Actually, this is pedantic, but I'd buy into disk drivers that only supported reading or only supported writing. A logging filesystem could be write-only so that you can avoid a system compromise from rewriting log files. Especially consider that perhaps it's a network filesystem that's write-only (append-only), and your security significantly increases as you'll be able to see log entries at least up until the point of compromise.
The same driver might even support expunging data over a certain age. This could be quite useful!
It's well established that you have no reasonable expectation of privacy (in the legal sense) when you're at work, on company hardware, and/or on a company network. I think responsible disclosure should require the company to let you know that you have a chance to be monitored, but so long as you're doing it on their dime, on their stuff, what you do belongs to them.
Well, if you're running as root and get compromised, it might do more than just steal or delete your data. It might install spyware or a bot that infects / spams / whatevers other people, and continues to corrupt / steal your data going forward.
There's a lot more danger to a virus than losing your personal data. There's other users of the same machine, and even for single-user machines, there's forward going infection, and danger to other netizens.
Get a rootkit in place, and you might be unwittingly giving away access to your box from now until the next time you do a full system upgrade, and never know it.
I'm giving up a mod point I used elsewhere in this thread, but oh well.
I've always taken it to mean something along the lines of, "They could care less... but not likely." Or that old maternal saying, "If you don't have anything nice to say...," extended by principle to "The best I can say about them is that they could care less." Like when you call a potential hire's former employer, and the best they can give you by reference is "Well, they were usually on time." Communication by omission. In the case of this phrase, it's patent omission of anything with any actual positive merit.
They covered this on Mythbusters recently, but I'm now a little fuzzy on the details since I was fairly tired at the time.
They built a large faraday cage, placed a cockpit inside it, and generated various frequencies common to cell phones. They were able to deviate at least one of the instruments fairly significantly -- the instrument which gives a vector to the nearest airport.
Of course this only happens under a constant generation of the interfering frequency, so something like a lightning bolt would make the needle sway from side to side, but it would correct itself in a few seconds, and that time would not be sufficient for the pilot to make an uncorrectably bad decision as a result.
A properly used fire extinguisher should be ok. It is a common mistake for someone not trained in using a fire extinguisher to get as close to the fire as they can, when the extinguisher is actually more effective from several feet away. Most of the force of the extinguisher should be dispelled before the blast reaches the fire.
Few people have extinguisher training. Another common mistake is to direct the extinguisher at the flame itself, which of course puts most of the retardant past the source of the flame.
Trying to move a burning pot outside (especially in the case of a grease / oil fire) could be insanely dangerous! Most people don't realize how hot a grease fire can actually be (significantly hotter than boiling water or the fire in your fireplace). Of course the actual temperature depends on the type of grease.
They might grab the pot, start moving it toward a door, and be overcome by the heat, slopping some burning grease onto themselves or onto the floor, if they don't drop the pot completely.
I'm not. I've had some very serious difficulties RE a custom order being royally goofed up, with Dell claiming it was one way, and all my documentation demonstrating it was not.
Basically I climbed the phone tree, the regional manager admitted I was probably right, but he wasn't going to do anything about it because it would negatively affect his figures. If I wanted to pursue the matter further, here's the contact information of their legal department; they only accept certified letters on legal letterhead.
Since then I've done all my buying from Alienware (before they were the cool company to buy from, just because they put together a darn good rig). Now I need to find another high end manufacturer. Maybe they'll ship Linux on the box, saving me the Microsoft tax, wouldn't that be nice.
If not, I guess it's back to building my own systems from scratch and hoping I don't order the wrong parts (I'm not really a hardware guy).
sudo su will drop you to a super user shell from which you type exit to return to regular user land.
On Ubuntu, enable the root account, and remove sudo rights from your main user account, and now it works just like normal. However you'll have to log out to do any graphical superuser functions (or start those graphical superuser functions from a superuser shell).
In general it is considered bad practice to ever open a super user shell. One of the reasons people like to use sudo is that it lets you execute a series of superuser commands in a row with only having to type your password once (before it times out and requires the password again in a few minutes). It's the middle road between the danger of a full-time root shell and having to type your root password for every root command.
Running in a root shell when you can avoid it is dangerous because there are certain very easy to make typos that can have absolutely cataclysmic results. I once meant to type "rm -rf.*" to erase all my personal pref files, but instead typed "rm -rf/*" (. and / being next to each other). After a minute, I began to wonder why it was taking so long to erase what should have only been a few files.
It does represent a form of unreasonable search and siezure. It does violate reasonable expectation of privacy. Both of these things are constitutionally protected against.
I can have a conversation with my lawyer or my spouse in a park, and it is not legal for the police to sit 200 yards away with a parabolic microphone listening in. That reasonable expectation of privacy can only be breached with a search warrant, which first demonstrates to a judge that sufficient evidence is present that I committed a crime to supercede my constitutional rights. Even then there still exist privileges that cannot be breached by any means (such as attorney client privilege); so long as I have a resonable expectation of privacy with my attorney, my conversation with him is not fair game in any way.
The justice department is not even alleging a crime happened here, hence no search warrant can be issued, hence users' reasonable expectation of privacy re: their communications with Google cannot be violated.
The only saving grace is that they are not asking for personally identifiable information (they do not want to even be able to tell whether any two searches were made by the same individual, let alone any information to identify that individual). It is however one step down a slippery slope. There is no need for this information, and more importantly, the information itself could be collected by the justice department if they bothered to perform the searches in question themselves.
Perhaps more significantly fresh out of college you will have a much weaker sense of the ethical implications of certain actions, simply because you don't necessarily understand the ramifications of those actions. The business world complex enough that until you have at maybe 5 or 10 years of experience, you probably don't know enough about what the business landscape is (especially considering your competetors and their potential espionage both legal and illegal).
For example, I've talked to entry level new hires who think the security practices are purely the result of some IT guy getting his rocks off making other people's lives miserable, and so circumvent them.
Less destructive but just as effective is the use of spray snow (might be hard to find outside of the holidays). Or if they are happy to come clean it off every 30 minutes, then use something a bit more aggressive such as spray adhesive.
Plus you'll have a good idea of how aggressively you're being watched by how quickly they show up to fix it. If it goes for days before anyone notices, at least you'll know you're not being watched, just recorded. If they walk into the room 5 minutes later, then you know they're actively watching your every move.
I wonder if there's any small devices which can play back a static image on a CC loop if physically intercepting the cable.
Well, you can take this one guy's word for it in the case of Windows.
Or in the case of OSS you can take the word of the hundreds of developers who want to audit the code themselves (and for something this important, there'll be hundreds of them), where it only takes one person to throw a red flag on bugtraq, and suddenly there's thousands if not tens of thousands of them looking over this code.
Also you could, if you had an especially vested interest, hire some developers to look over it. Say, perhaps, several independant parties including overseas operations. This is a lot better option than the closed source model where you're pretty much limited to decompiling the code (illegal here in these U.S, and still very hard for even a seasoned developer to figure out) or simply trusting the word of this one guy who maybe didn't notice the back door already present, or simply wasn't motivated to look very hard, or maybe has a family member being threatened in some way by the NSA, who knows.
Unfortunately it's the quarter-to-quarter traders who of course influence price. If you can't attract the quarter-to-quarter traders, the price will suffer greatly (they are the ones who will buy whenever a long-term investor is looking to cash out, such as for paying for a new home, retirement, liquidating some cash to diversify their portfolio, etc). As a result, it makes the stock less attractive to long term investors. Even though your long term investors are really the people who really drive your finances, it's the short term investors that drive attractiveness for long termers.
I'd like to point out that there exist members of the "religious right" who oppose a ban on gay marriage. That doesn't mean they necessarily support the decision made by such individuals to practice their sexuality, but simply that they do not believe it is within the authority of the government to tell individuals how to practice their lives when that practice has does not intrude on the rights of others.
...In this sense, and to return to the topic that began this article, a liberal democracy, or better said, an American democracy, is not to be concerned with constitutionally defining marriage in such a way as to intentionally exclude homosexuals from entering into marriage relationships.
My beliefs align with the above article, and I am religious, and I am Christian.
I'd like to think that if I was homosexual, that I'd possess the willpower to avoid practicing it, because there is no place for it in my belief system. But even though my beliefs forbid me from such activity, they make no statement preventing me from loving (in the platonic sense) those who engage in such an activity. I can condemn another for their actions only when my own are faultless.
Whether or not another is homosexual, or bisexual, or transsexaul has no impact on my willingness to know them or befriend them. However, I'm no more interested in discussing their sexuality with them, than I am with discussing a hetero's sexuality (although I know some people enjoy such topics, I find them base, and undesirable for conversation, regardless of whether it's homo or hetero).
So I suppose it's a don't ask, don't tell philosophy. I don't go about announcing that I'm straight, and I don't appreciate others going about announcing that they're gay.
I play Warcraft to participate in a fantasy realm where for a short time a few days a week, I can put reality aside, and think instead only about that fantasy. I don't want to hear about the super bowl, what you do for a living, what your sexuality is, nor, frankly, how you think Blizzard should fix the login queues. There are media which are appropriate for each of these topics, and none of them is the general chat channel. Frankly there's even a game where these things can be on-topic to the game itself -- Second Life.
I have no problem with them creating a GLBT friendly guild, but I don't really want to hear about it being that way. Blizzard's actions weren't meant as discrimination against GLBT's, but as a means to preserve the immersiveness of their world. I don't agree with their statement about protecting members of that guild from harrassment from other players; membership is voluntary, and presumably players would know what they were getting into in advance. But I do think it's worthwhile to protect those who are not involved in that guild from the discussions that are unpreventably going to happen when a guild advertises itself that way. It's a game where people go to get away from reality, this is a service that the game provides, and that service is directly defeated by taking a controversial topic from real life and presenting it so prominently.
RE: playing different positions (engineering, tactical, helm), that could be covered by classes. You're a commander, you're an engineer, you're a pilot, etc. Per character, you'd be locked into a given role (just like traditional MMO's), and your pilot character couldn't take over the medical duties.
RE: Who's in charge, if you're the commander class, you can captain a ship.
The class of ship you can work on is dependant on your level, and perhaps on specific skills within your character (eg, you might need a certain heavy-momentum piloting skill level to pilot a slow but powerful battle cruiser).
So you can't captain a galaxy class cruiser unless you've got the appropriate skill for it. You have to work your way up as an officer before you get the good stuff, just like you don't get the best weapons in other MMO's unless you're the top level.
Unlike real command, the captain's role wouldn't *necessarily* be to give orders to others, but perhaps the captain has different information about the state of things, and so is better suited for giving those commands. For example, maybe a big part of being a commander class is that you have huds for each strategic area of your ship, while each strategic area has a hud only for its own area. Only you have the complete picture of what's going on.
There'll be some problem with too many people wanting to be captains, and not enough people wanting to be engineers, but all MMO's have problems with too many people hopping on the flavor of the month, and not enough people playing the support classes. That makes good support classes all that much more valuable. Because of this, you should have the option of letting the game control certian functions of your ship. The game won't be as responsive (or as thinking) as a real player, so you'll do better to put a player in that position, but it shouldn't be absolutely necessary to have a player there for any but the most difficult encounters.
The real challenge is providing interesting things for each class to do. The same problem hits other MMO's, such as priests (my EQ cleric was bored off his butt most of the time, can't believe I played him so long -- sit, stand, heal, sit, stand, heal, sit, stand, buff, sit) and other support classes.
So I'm thinking 5 distinct classes: Commander -- captains a ship, gets a complete HUD for all areas of the ship, including extensive tactical data. Abilities for the commander affect other players' abilities to do their jobs (they make you able to do your job more effectively or more quickly). The commander doesn't directly affect any ship operation, just has access to all the information, and helps others do their jobs better.
Engineer -- keeps the systems running, and directly affects things like the overall performance, damage done by the weapons, overall power available, where the power goes (gives more or less to the engines, shields, or weapons, etc). Also has systems repair skills, and virtual team members who can be deployed to various areas to affect fixes (send 10 engineers, send 50 engineers, etc)
Tactical -- controls shields, weapons, and is responsible for maintaining sensor locks on other ships. These sensor locks are fundamental for the captain to be able to do his or her job, as a ship whose sensor lock is lost no longer shows up on the captain's hud. Slipping locks reduce the effectiveness of weapons, and reduce the effectiveness of shields when attacked by that ship.
Pilot -- responsible almost solely for piloting the ship. Abilities include various evasive maneuvers and attack patterns (evasives and attack patterns are rock paper scissors setups). They can pull directly from lore: The Piccard Maneuver, Evasive Pattern Delta, stuff like that. The available options depend on what engineering has prepared (if warp drives are down, you can't do the Piccard Maneuver for example), and how much reserve power you can draw on.
Because it seems to be beginning to crawl under a good ol' fashioned/.ing, here's the article text:
Boost socket performance on Linux
Four ways to speed up your network applications
M. Tim Jones (mtj@mtjones.com), Senior Principal Software Engineer, Emulex
17 Jan 2006
The Sockets API lets you develop client and server applications that can communicate across a local network or across the world via the Internet. Like any API, you can use the Sockets API in ways that promote high performance -- or inhibit it. This article explores four ways to use the Sockets API to squeeze the greatest performance out your application and to tune the GNU/Linux® environment to achieve the best results.
When developing a sockets application, job number one is usually establishing reliability and meeting the necessary requirements. With the four tips in this article, you can design and develop your sockets application for best performance, right from the beginning. This article covers use of the Sockets API, a couple of socket options that provide enhanced performance, and GNU/Linux tuning.
To develop applications with lively performance capabilities, follow these tips:
* Minimize packet transmit latency.
* Minimize system call overhead.
* Adjust TCP windows for the Bandwidth Delay Product.
* Dynamically tune the GNU/Linux TCP/IP stack.
Tip 1. Minimize packet transmit latency
When you communicate through a TCP socket, the data are chopped into blocks so that they fit within the TCP payload for the given connection. The size of TCP payload depends on several factors (such as the maximum packet size along the path), but these factors are known at connection initiation time. To achieve the best performance, the goal is to fill each packet as much as possible with the available data. When insufficient data exist to fill a payload (otherwise known as the maximum segment size, or MSS), TCP employs the Nagle algorithm to automatically concatenate small buffers into a single segment. Doing so increases the efficiency of the application and reduces overall network congestion by minimizing the number of small packets that are sent.
John Nagle's algorithm works well to minimize small packets by concatenating them into larger ones, but sometimes you simply want the ability to send small packets. A simple example is the telnet application, which allows a user to interact with a remote system, typically through a shell. If the user were required to fill a segment with typed characters before the packet was sent, the experience would be less than desirable.
Another example is the HTTP protocol. Commonly, a client browser makes a small request (an HTTP request message), resulting in a much larger response by the Web server (the Web page).
The solution
The first thing you should consider is that the Nagle algorithm fulfills a need. Because the algorithm coalesces data to try to fill a complete TCP packet segment, it does introduce some latency. But it does this with the benefit of minimizing the number of packets sent on the wire, and so it minimizes congestion on the network.
But in cases where you need to minimize that transmit latency, the Sockets API provides a solution. To disable the Nagle algorithm, you can set the TCP_NODELAY socket option, as shown in Listing 1.
Listing 1. Disabling the Nagle algorithm for a TCP socket
int sock, flag, ret;/* Create new stream socket */ sock = socket( AF_INET, SOCK_STREAM, 0 );/* Disable the Nagle (TCP No Delay) algorithm */ flag = 1; ret = setsockopt( sock, IPPROTO_TCP, TCP_NODELAY, (char *)&flag, sizeof(flag) );
if (ret == -1) {
printf("Couldn't setsockopt(TCP_NODELAY)\n");
exit(-1); }
Well, we're not a good company to try that particular example on; our business isn't centered on our online portion, and in fact we don't even permit anonymous signups on our website; you have to already be a customer before you get an account (though you can call our 800 number and become a customer the same day you first visit the site if you want; so long as you have appropriate documentation to send us -- we sell legally restricted materials, and you have to be authorized to purchase them). A very high percentage of our visitors are also customers, and our conversion rate is through the roof, since people generally have a specific list of goods they're looking to procure when they come to the site.
Your point is well taken with regards to businesses whose presence is purely online though, and whose conversion rates would be significantly lower than ours. If you had a 10% conversion rate, $10 profit margin, and $1 cost per user from a given ISP, then you're right, it would no longer make sense to pay the extortion fees. In which case we probably would turn down customers from that ISP (more accurately we'd probably provide our 1-800 number, explain that their ISP refuses to permit them to use our website correctly, and offer them a 10% discount for calling the 1-800 number, if they mention BellSouth). Of course then BellSouth would have priced themselves out of our market, and in a month, we'd probably hear back from them with a reduced price so they could still extort something out of us instead of nothing.
It's sad, but I find that outcome unlikely. I know that here at work, if this extortion attempt was made in our direction, there is no way we would turn away business by telling our customers that they use an ISP we don't like. If Bell South said, "Pay us $1 per visitor to your site, and you'll get full and fast access to our customer base," we'd do an evaluation of the number of visits we get from BellSouth, and cut them a check the next day.
It wouldn't be my decision, it would be up to the business, but every customer turned away is a customer lost, as far as most businesses are concerned. If our competition was paying BellSouth and we weren't, we'd definately lose customers to them. Let's say we do $100,000 / month (it's actually more, but I'm not prepared to disclose real figures =)) in sales for 1,000 customers. Let's say that of that, 10% is profit, and BellSouth wants to charge us $1 per customer. We'd be looking at giving up $10 per customer in profit, vs giving up $1 per customer. As sleezy (and potentially illegal) as this deal is, that $9 in un-lost sales would make it worthwhile.
No, it won't be the content providers that cause this idea to fall apart. It'll be the customers. Personally, I'd be looking for a new ISP today if I had Bell South. When other customers get wind that "accelerated" websites / services are in fact just not crippled, they'll be doing the same.
Someone will get the idea to start a class action lawsuit, and this'll end it once and for all. As was mentioned elsewhere, the company can only bill once for a given service. They can either choose to bill the end user (the current model), or they can choose to bill the content providers, but not both. In fact, this is no different from them wanting to charge other phone companies every time you receive a call from one. I doubt congress & the legal system will see it any differently. Sadly, when the class action suit settles, and BS goes bankrupt, it'll be our tax dollars that bail them out, while the C*O's walk away with their golden parachutes.
Re:Web 2.0: Where solutions don't need problems?
on
Web 3.0
·
· Score: 5, Insightful
AJAX? Why?
Well said. This is really the fundamental question present, isn't it? We've been doing it for a couple of years, before the "AJAX" term appeared. As a sidenote, I believe the reason this term took off so well is because the web had been naturally moving in this direction, a lot of bleeding edge developers felt it, knew it in their bones, but until that point, didn't have any term to latch onto. Like a chemical reaction where all the reagents are present in the right quantities but the catalyst is missing.
The answer of course depends on your business circumstances. Ajax isn't right for everyone, but because it's the current buzz word, you'll see a lot of abuses of ajax in the coming months. Sadly it'll detract from the elegance that the technology can lend users.
So anyway, to answer your question in a general fashion, it's got several advantages from traditional web development. Most importantly, from a user perspective, a well thought out ajax application means a much more responsive interface, and really nothing else. If you expose anything else about ajax to your users, you're doing it wrong (IMHO). The snappiness comes from two aspects. First, asynchronous requests means that the user can keep working while something is processing in the background. Second, there's simply less data to transfer in a well thought out site, so the page itself downloads faster (though usually only on the 2nd and later hits since the first hit involves downloading a potentially sizy library).
Now this point should not be under-considered. From an evil marketing perspective, having a website where users can complete the ordering process in 7 seconds from search to receipt means more sales. Not because you can handle a higher volume (though that's another of ajax's benefits), but because users have less time to reconsider their purchase. Less opportunity to say, "Wonder if I'll find a better deal elsewhere," or, "Do I really want to spend $400 on a new camera when my old one actually does everything I need."
From a technical perspective, I see two main benefits in practice. First, it represents lower server loads. Traditional web development means you have to rebuild every page every time the user clicks anything. The framework, the navigation, and the logic that goes into determining whether the user sees specific page elements, all has to be redone from scratch every page hit. That takes time and resources: memory to hold that page data on a buffered system, network bandwidth to transfer it, and cpu time to generate it. On a low volume site, this is meaningless. If you're serving 500-1000 hits a second though, this adds up. Of course in that case you're going to have load balancing, and money to throw at additional hardware.
However our work has shown about half the load on a heavily ajax based app from a traditional app, so that's fewer things to go wrong, fewer 2am calls because a hard disk crashed, and fewer hours spent troubleshooting why your edge optomized routing isn't optomizing its edge routing.
Also, from a development perspective, this is exactly the Model View Controller framework that so many people really like to enforce in their development practices. The roles are also clearly defined, since each role happens in a different location. No matter how many MVC frameworks I've worked in, it's always felt forced to me. You end up doing things in an odd and counter-intuitive way in order to pound your complex business logic (which invariably seems to affect display).
The biggest problem is that often business logic *is* the display. In the end, either you end up passing many dozens of flags to your display to affect these things (the correct way, but with more flags, becomes increasingly difficult to not make mistakes), you end up generating some of the display in the model portion (much easier, so lazy programmers will often take this route), or worst of all, you end up putting business logic in the displa
Actually, despite the obvious joke in your comment, I honestly can't decide.
On one hand, we need more alternatives to oil, and anything that hurts that hurts us all in the long run.
On the other hand, if a high profile patent case is brought against hybrid cars, then it'll possibly bring the absurdity of current patent situations into the public light, and I can already hear screaming on the senate floor about the evils of patents.
On the third hand, patents *do* have their uses (recovering research costs and profiting from your truly unobvious inventions), and not knowing the background here, it's possible these guys deserve their patent (even if they should probably have upheld it earlier). Not all patents are evil.
I think this is an interesting idea, but I feel like it's got a few flaws:
If a product that uses your patent without an agreement in place is on the market for X months and you, the patent holder, do not challenge such use, a license is automatically granted for that product.
So I could get myself a license by producing a product, and making sure it's low enough on the radar that it never blips on the patent holder's screen (for example, sell it to a few "customers" for whom I do the same sort of favor in return, and never advertise it).
You can only exercise this challenge Y times over the life of the patent. Y will not include any challenge that is upheld, either initially or after the fact.
In this case, in the case of a really valuable patent, I could set up Y veil companies who are talking about the new "product" they are producing, which provides just enough details to make it appear as if perhaps they're violating your patent. You can challenge all the companies, and when it's discovered that they're not in fact violating the patent (since perhaps they're all vaporware), you've used up your right to challenge. If you fail to challenge any of them for the aforementioned window of opportunity to challenge the use of the patented tech, then whatever company was unchallenged suddenly de-vaporizes their product, and surprise surprise, it uses the patented technology, now granted an implicit license.
Decidedly well said, and I agree with the sentiment, as long as resources exist to implement them. Web development has been my gig for nearly the last 10 years, so I do feel I've got a decent grasp on typical web setups.
In general, maybe 99% of web servers have no protection against a DDoS, and probably 90% of them have at best a software firewall running on the box itself. The enterprise systems (ecommerce) I work on have load balancing switches, multiple servers on the back end, redundancy on all levels (including Internet access, power supply, and all other back end systems). But even we don't have good DDoS protection. Our hardware and Internet connections are pretty high end, so it would take a *massive* DDoS to take us down, but I'm pretty confident that there are people out there with botnets who could manage it (never underestimate the power of 250,000 broadband-connected compromised computers).
There is really *little* you can do to protect yourself from a DDoS, unless you have the infrastructure to absorb the DDoS. There was an article about how a central-american gambling site beat out a DDoS attack (the DDoSers were holding the site for ransome for like $50,000 or something). They ended up needing to proxy their website through a really huge ISP, set up advanced firewall rules to differentiate legitimate traffic from the DDoS traffic, and in the end it cost them $1 million to protect against a $50k extortion effort. (Just found the link: http://www.csoonline.com/read/050105/extortion.htm l )
I had the unfortunate experience of having been on the receiving end of a DDoS (fortunately without any extortion attempt, though I wouldn't have been able to pay it anyhow) on my project site (lotgd.net). About 25,000 unique IP's were requesting random pages on my site, each every 4 minutes. I was pretty helpless to protect against it for the first couple of days, because it was a personal site on a server I rent, my ISP offered no DDoS protection at the time, and I hadn't been able to find any pattern other than that the requests came 4 minutes apart per IP address (plus or minus about 10 seconds). That's about a total of 100 requests per second [on top of my existing user traffic, which is generally about 25 requests per second], and my project is very database heavy.
I couldn't really keep a database of how often each IP address accessed the site on average, because I was already under a heavy enough load, and 25,000 deny entries in my firewall at a time would also lend a heavy load (software based firewall on the web server [iptables]). Further, the IP's kept changing (either someone was only dedicating a small portion of their overall botnet to me at a time, or they mostly had computers that had dynamic IP's). Over the course of the ~2 weeks that the attack took place, there were a total of 1.7 million unique IP's (only ever almost exactly 25,000 at a time, plus or minus a few percent). Obviously I needed an adaptive solution, because a reactive one (where I identified IP's manually or with a script and added them to the firewall) would probably typically have missed the window where I was actually being attacked by any given IP.
The *only* way I was able to beat it is by identifying a few IP's that were obviously attackers, and using a network sniffer to watch their traffic and noticing one thing that was wrong in their IP headers (which I could only do because I happen to know what IP headers should look like). It wasn't even technically wrong, it was just different from all the legit traffic. Then I was able to add a simple firewall rule that fixed the issue, but if the attackers had corrected this, I would have been screwed unless I invested in additional infrastructure. I paid a really hefty bandwidth bill that month (about 4x average usage overall), and I never found out who was attacking me (no one ever sent me an email, but because my site is a gaming site that has specific
Well, programs like Firefox actually warn you before they send information for the first time, and provide you the option to not send that information (though of course you can't request the page that information was going to without providing that information). Of course there's certain information that is always sent with any Internet request, and you won't get away from that with any 'net enabled app.
Slashdot Mirror
Such as National Geographic?
I got into this discussion once before with someone else here on Slashdot. I subscribe excusively to advertisement-free publications. Pennsylvania Magazine, Birds & Blooms, Backyard Living, to name a few. These publications are small ones, hence their production overhead is more significant to their bottom line, yet they can survive free of advertising. The National Geographic model (which typically includes only one car advertisment on the inside cover or something; I don't actually subscribe to this one) says to me that magazines are sustainable sans-advertising, or at least with much less advertising, and that it's pure greed that puts most advertisements in these periodicals.
National Geographic has much higher production costs than most fluff magazines (such as Reader's Digest), since they do things like foot multiple-year expeditions to the rain forest, and generally produce a much higher quality, and longer (thicker) digest, but yet still turn a profit with only one ad.
Actually, this is pedantic, but I'd buy into disk drivers that only supported reading or only supported writing. A logging filesystem could be write-only so that you can avoid a system compromise from rewriting log files. Especially consider that perhaps it's a network filesystem that's write-only (append-only), and your security significantly increases as you'll be able to see log entries at least up until the point of compromise.
The same driver might even support expunging data over a certain age. This could be quite useful!
It's well established that you have no reasonable expectation of privacy (in the legal sense) when you're at work, on company hardware, and/or on a company network. I think responsible disclosure should require the company to let you know that you have a chance to be monitored, but so long as you're doing it on their dime, on their stuff, what you do belongs to them.
Well, if you're running as root and get compromised, it might do more than just steal or delete your data. It might install spyware or a bot that infects / spams / whatevers other people, and continues to corrupt / steal your data going forward.
There's a lot more danger to a virus than losing your personal data. There's other users of the same machine, and even for single-user machines, there's forward going infection, and danger to other netizens.
Get a rootkit in place, and you might be unwittingly giving away access to your box from now until the next time you do a full system upgrade, and never know it.
I'm giving up a mod point I used elsewhere in this thread, but oh well.
I've always taken it to mean something along the lines of, "They could care less... but not likely." Or that old maternal saying, "If you don't have anything nice to say...," extended by principle to "The best I can say about them is that they could care less." Like when you call a potential hire's former employer, and the best they can give you by reference is "Well, they were usually on time." Communication by omission. In the case of this phrase, it's patent omission of anything with any actual positive merit.
They covered this on Mythbusters recently, but I'm now a little fuzzy on the details since I was fairly tired at the time.
They built a large faraday cage, placed a cockpit inside it, and generated various frequencies common to cell phones. They were able to deviate at least one of the instruments fairly significantly -- the instrument which gives a vector to the nearest airport.
Of course this only happens under a constant generation of the interfering frequency, so something like a lightning bolt would make the needle sway from side to side, but it would correct itself in a few seconds, and that time would not be sufficient for the pilot to make an uncorrectably bad decision as a result.
A properly used fire extinguisher should be ok. It is a common mistake for someone not trained in using a fire extinguisher to get as close to the fire as they can, when the extinguisher is actually more effective from several feet away. Most of the force of the extinguisher should be dispelled before the blast reaches the fire.
Few people have extinguisher training. Another common mistake is to direct the extinguisher at the flame itself, which of course puts most of the retardant past the source of the flame.
Trying to move a burning pot outside (especially in the case of a grease / oil fire) could be insanely dangerous! Most people don't realize how hot a grease fire can actually be (significantly hotter than boiling water or the fire in your fireplace). Of course the actual temperature depends on the type of grease.
They might grab the pot, start moving it toward a door, and be overcome by the heat, slopping some burning grease onto themselves or onto the floor, if they don't drop the pot completely.
I'm not. I've had some very serious difficulties RE a custom order being royally goofed up, with Dell claiming it was one way, and all my documentation demonstrating it was not.
Basically I climbed the phone tree, the regional manager admitted I was probably right, but he wasn't going to do anything about it because it would negatively affect his figures. If I wanted to pursue the matter further, here's the contact information of their legal department; they only accept certified letters on legal letterhead.
Since then I've done all my buying from Alienware (before they were the cool company to buy from, just because they put together a darn good rig). Now I need to find another high end manufacturer. Maybe they'll ship Linux on the box, saving me the Microsoft tax, wouldn't that be nice.
If not, I guess it's back to building my own systems from scratch and hoping I don't order the wrong parts (I'm not really a hardware guy).
sudo su will drop you to a super user shell from which you type exit to return to regular user land.
.*" to erase all my personal pref files, but instead typed "rm -rf /*" (. and / being next to each other). After a minute, I began to wonder why it was taking so long to erase what should have only been a few files.
On Ubuntu, enable the root account, and remove sudo rights from your main user account, and now it works just like normal. However you'll have to log out to do any graphical superuser functions (or start those graphical superuser functions from a superuser shell).
In general it is considered bad practice to ever open a super user shell. One of the reasons people like to use sudo is that it lets you execute a series of superuser commands in a row with only having to type your password once (before it times out and requires the password again in a few minutes). It's the middle road between the danger of a full-time root shell and having to type your root password for every root command.
Running in a root shell when you can avoid it is dangerous because there are certain very easy to make typos that can have absolutely cataclysmic results. I once meant to type "rm -rf
It does represent a form of unreasonable search and siezure. It does violate reasonable expectation of privacy. Both of these things are constitutionally protected against.
I can have a conversation with my lawyer or my spouse in a park, and it is not legal for the police to sit 200 yards away with a parabolic microphone listening in. That reasonable expectation of privacy can only be breached with a search warrant, which first demonstrates to a judge that sufficient evidence is present that I committed a crime to supercede my constitutional rights. Even then there still exist privileges that cannot be breached by any means (such as attorney client privilege); so long as I have a resonable expectation of privacy with my attorney, my conversation with him is not fair game in any way.
The justice department is not even alleging a crime happened here, hence no search warrant can be issued, hence users' reasonable expectation of privacy re: their communications with Google cannot be violated.
The only saving grace is that they are not asking for personally identifiable information (they do not want to even be able to tell whether any two searches were made by the same individual, let alone any information to identify that individual). It is however one step down a slippery slope. There is no need for this information, and more importantly, the information itself could be collected by the justice department if they bothered to perform the searches in question themselves.
Perhaps more significantly fresh out of college you will have a much weaker sense of the ethical implications of certain actions, simply because you don't necessarily understand the ramifications of those actions. The business world complex enough that until you have at maybe 5 or 10 years of experience, you probably don't know enough about what the business landscape is (especially considering your competetors and their potential espionage both legal and illegal).
For example, I've talked to entry level new hires who think the security practices are purely the result of some IT guy getting his rocks off making other people's lives miserable, and so circumvent them.
Less destructive but just as effective is the use of spray snow (might be hard to find outside of the holidays). Or if they are happy to come clean it off every 30 minutes, then use something a bit more aggressive such as spray adhesive.
Plus you'll have a good idea of how aggressively you're being watched by how quickly they show up to fix it. If it goes for days before anyone notices, at least you'll know you're not being watched, just recorded. If they walk into the room 5 minutes later, then you know they're actively watching your every move.
I wonder if there's any small devices which can play back a static image on a CC loop if physically intercepting the cable.
Well, you can take this one guy's word for it in the case of Windows.
Or in the case of OSS you can take the word of the hundreds of developers who want to audit the code themselves (and for something this important, there'll be hundreds of them), where it only takes one person to throw a red flag on bugtraq, and suddenly there's thousands if not tens of thousands of them looking over this code.
Also you could, if you had an especially vested interest, hire some developers to look over it. Say, perhaps, several independant parties including overseas operations. This is a lot better option than the closed source model where you're pretty much limited to decompiling the code (illegal here in these U.S, and still very hard for even a seasoned developer to figure out) or simply trusting the word of this one guy who maybe didn't notice the back door already present, or simply wasn't motivated to look very hard, or maybe has a family member being threatened in some way by the NSA, who knows.
Unfortunately it's the quarter-to-quarter traders who of course influence price. If you can't attract the quarter-to-quarter traders, the price will suffer greatly (they are the ones who will buy whenever a long-term investor is looking to cash out, such as for paying for a new home, retirement, liquidating some cash to diversify their portfolio, etc). As a result, it makes the stock less attractive to long term investors. Even though your long term investors are really the people who really drive your finances, it's the short term investors that drive attractiveness for long termers.
from a member of the "religious right".
My beliefs align with the above article, and I am religious, and I am Christian.
I'd like to think that if I was homosexual, that I'd possess the willpower to avoid practicing it, because there is no place for it in my belief system. But even though my beliefs forbid me from such activity, they make no statement preventing me from loving (in the platonic sense) those who engage in such an activity. I can condemn another for their actions only when my own are faultless.
Whether or not another is homosexual, or bisexual, or transsexaul has no impact on my willingness to know them or befriend them. However, I'm no more interested in discussing their sexuality with them, than I am with discussing a hetero's sexuality (although I know some people enjoy such topics, I find them base, and undesirable for conversation, regardless of whether it's homo or hetero).
So I suppose it's a don't ask, don't tell philosophy. I don't go about announcing that I'm straight, and I don't appreciate others going about announcing that they're gay.
I play Warcraft to participate in a fantasy realm where for a short time a few days a week, I can put reality aside, and think instead only about that fantasy. I don't want to hear about the super bowl, what you do for a living, what your sexuality is, nor, frankly, how you think Blizzard should fix the login queues. There are media which are appropriate for each of these topics, and none of them is the general chat channel. Frankly there's even a game where these things can be on-topic to the game itself -- Second Life.
I have no problem with them creating a GLBT friendly guild, but I don't really want to hear about it being that way. Blizzard's actions weren't meant as discrimination against GLBT's, but as a means to preserve the immersiveness of their world. I don't agree with their statement about protecting members of that guild from harrassment from other players; membership is voluntary, and presumably players would know what they were getting into in advance. But I do think it's worthwhile to protect those who are not involved in that guild from the discussions that are unpreventably going to happen when a guild advertises itself that way. It's a game where people go to get away from reality, this is a service that the game provides, and that service is directly defeated by taking a controversial topic from real life and presenting it so prominently.
Well, here's a couple of thoughts:
RE: playing different positions (engineering, tactical, helm), that could be covered by classes. You're a commander, you're an engineer, you're a pilot, etc. Per character, you'd be locked into a given role (just like traditional MMO's), and your pilot character couldn't take over the medical duties.
RE: Who's in charge, if you're the commander class, you can captain a ship.
The class of ship you can work on is dependant on your level, and perhaps on specific skills within your character (eg, you might need a certain heavy-momentum piloting skill level to pilot a slow but powerful battle cruiser).
So you can't captain a galaxy class cruiser unless you've got the appropriate skill for it. You have to work your way up as an officer before you get the good stuff, just like you don't get the best weapons in other MMO's unless you're the top level.
Unlike real command, the captain's role wouldn't *necessarily* be to give orders to others, but perhaps the captain has different information about the state of things, and so is better suited for giving those commands. For example, maybe a big part of being a commander class is that you have huds for each strategic area of your ship, while each strategic area has a hud only for its own area. Only you have the complete picture of what's going on.
There'll be some problem with too many people wanting to be captains, and not enough people wanting to be engineers, but all MMO's have problems with too many people hopping on the flavor of the month, and not enough people playing the support classes. That makes good support classes all that much more valuable. Because of this, you should have the option of letting the game control certian functions of your ship. The game won't be as responsive (or as thinking) as a real player, so you'll do better to put a player in that position, but it shouldn't be absolutely necessary to have a player there for any but the most difficult encounters.
The real challenge is providing interesting things for each class to do. The same problem hits other MMO's, such as priests (my EQ cleric was bored off his butt most of the time, can't believe I played him so long -- sit, stand, heal, sit, stand, heal, sit, stand, buff, sit) and other support classes.
So I'm thinking 5 distinct classes:
Commander -- captains a ship, gets a complete HUD for all areas of the ship, including extensive tactical data. Abilities for the commander affect other players' abilities to do their jobs (they make you able to do your job more effectively or more quickly). The commander doesn't directly affect any ship operation, just has access to all the information, and helps others do their jobs better.
Engineer -- keeps the systems running, and directly affects things like the overall performance, damage done by the weapons, overall power available, where the power goes (gives more or less to the engines, shields, or weapons, etc). Also has systems repair skills, and virtual team members who can be deployed to various areas to affect fixes (send 10 engineers, send 50 engineers, etc)
Tactical -- controls shields, weapons, and is responsible for maintaining sensor locks on other ships. These sensor locks are fundamental for the captain to be able to do his or her job, as a ship whose sensor lock is lost no longer shows up on the captain's hud. Slipping locks reduce the effectiveness of weapons, and reduce the effectiveness of shields when attacked by that ship.
Pilot -- responsible almost solely for piloting the ship. Abilities include various evasive maneuvers and attack patterns (evasives and attack patterns are rock paper scissors setups). They can pull directly from lore: The Piccard Maneuver, Evasive Pattern Delta, stuff like that. The available options depend on what engineering has prepared (if warp drives are down, you can't do the Piccard Maneuver for example), and how much reserve power you can draw on.
Medical -- I'm a little shorter on t
Because it seems to be beginning to crawl under a good ol' fashioned /.ing, here's the article text:
/* Create new stream socket */ /* Disable the Nagle (TCP No Delay) algorithm */
Boost socket performance on Linux
Four ways to speed up your network applications
M. Tim Jones (mtj@mtjones.com), Senior Principal Software Engineer, Emulex
17 Jan 2006
The Sockets API lets you develop client and server applications that can communicate across a local network or across the world via the Internet. Like any API, you can use the Sockets API in ways that promote high performance -- or inhibit it. This article explores four ways to use the Sockets API to squeeze the greatest performance out your application and to tune the GNU/Linux® environment to achieve the best results.
When developing a sockets application, job number one is usually establishing reliability and meeting the necessary requirements. With the four tips in this article, you can design and develop your sockets application for best performance, right from the beginning. This article covers use of the Sockets API, a couple of socket options that provide enhanced performance, and GNU/Linux tuning.
To develop applications with lively performance capabilities, follow these tips:
* Minimize packet transmit latency.
* Minimize system call overhead.
* Adjust TCP windows for the Bandwidth Delay Product.
* Dynamically tune the GNU/Linux TCP/IP stack.
Tip 1. Minimize packet transmit latency
When you communicate through a TCP socket, the data are chopped into blocks so that they fit within the TCP payload for the given connection. The size of TCP payload depends on several factors (such as the maximum packet size along the path), but these factors are known at connection initiation time. To achieve the best performance, the goal is to fill each packet as much as possible with the available data. When insufficient data exist to fill a payload (otherwise known as the maximum segment size, or MSS), TCP employs the Nagle algorithm to automatically concatenate small buffers into a single segment. Doing so increases the efficiency of the application and reduces overall network congestion by minimizing the number of small packets that are sent.
John Nagle's algorithm works well to minimize small packets by concatenating them into larger ones, but sometimes you simply want the ability to send small packets. A simple example is the telnet application, which allows a user to interact with a remote system, typically through a shell. If the user were required to fill a segment with typed characters before the packet was sent, the experience would be less than desirable.
Another example is the HTTP protocol. Commonly, a client browser makes a small request (an HTTP request message), resulting in a much larger response by the Web server (the Web page).
The solution
The first thing you should consider is that the Nagle algorithm fulfills a need. Because the algorithm coalesces data to try to fill a complete TCP packet segment, it does introduce some latency. But it does this with the benefit of minimizing the number of packets sent on the wire, and so it minimizes congestion on the network.
But in cases where you need to minimize that transmit latency, the Sockets API provides a solution. To disable the Nagle algorithm, you can set the TCP_NODELAY socket option, as shown in Listing 1.
Listing 1. Disabling the Nagle algorithm for a TCP socket
int sock, flag, ret;
sock = socket( AF_INET, SOCK_STREAM, 0 );
flag = 1;
ret = setsockopt( sock, IPPROTO_TCP, TCP_NODELAY, (char *)&flag, sizeof(flag) );
if (ret == -1) {
printf("Couldn't setsockopt(TCP_NODELAY)\n");
exit(-1);
}
Bonus tip: Experimentation with Samb
Well, we're not a good company to try that particular example on; our business isn't centered on our online portion, and in fact we don't even permit anonymous signups on our website; you have to already be a customer before you get an account (though you can call our 800 number and become a customer the same day you first visit the site if you want; so long as you have appropriate documentation to send us -- we sell legally restricted materials, and you have to be authorized to purchase them). A very high percentage of our visitors are also customers, and our conversion rate is through the roof, since people generally have a specific list of goods they're looking to procure when they come to the site.
Your point is well taken with regards to businesses whose presence is purely online though, and whose conversion rates would be significantly lower than ours. If you had a 10% conversion rate, $10 profit margin, and $1 cost per user from a given ISP, then you're right, it would no longer make sense to pay the extortion fees. In which case we probably would turn down customers from that ISP (more accurately we'd probably provide our 1-800 number, explain that their ISP refuses to permit them to use our website correctly, and offer them a 10% discount for calling the 1-800 number, if they mention BellSouth). Of course then BellSouth would have priced themselves out of our market, and in a month, we'd probably hear back from them with a reduced price so they could still extort something out of us instead of nothing.
It's sad, but I find that outcome unlikely. I know that here at work, if this extortion attempt was made in our direction, there is no way we would turn away business by telling our customers that they use an ISP we don't like. If Bell South said, "Pay us $1 per visitor to your site, and you'll get full and fast access to our customer base," we'd do an evaluation of the number of visits we get from BellSouth, and cut them a check the next day.
It wouldn't be my decision, it would be up to the business, but every customer turned away is a customer lost, as far as most businesses are concerned. If our competition was paying BellSouth and we weren't, we'd definately lose customers to them. Let's say we do $100,000 / month (it's actually more, but I'm not prepared to disclose real figures =)) in sales for 1,000 customers. Let's say that of that, 10% is profit, and BellSouth wants to charge us $1 per customer. We'd be looking at giving up $10 per customer in profit, vs giving up $1 per customer. As sleezy (and potentially illegal) as this deal is, that $9 in un-lost sales would make it worthwhile.
No, it won't be the content providers that cause this idea to fall apart. It'll be the customers. Personally, I'd be looking for a new ISP today if I had Bell South. When other customers get wind that "accelerated" websites / services are in fact just not crippled, they'll be doing the same.
Someone will get the idea to start a class action lawsuit, and this'll end it once and for all. As was mentioned elsewhere, the company can only bill once for a given service. They can either choose to bill the end user (the current model), or they can choose to bill the content providers, but not both. In fact, this is no different from them wanting to charge other phone companies every time you receive a call from one. I doubt congress & the legal system will see it any differently. Sadly, when the class action suit settles, and BS goes bankrupt, it'll be our tax dollars that bail them out, while the C*O's walk away with their golden parachutes.
AJAX? Why?
Well said. This is really the fundamental question present, isn't it? We've been doing it for a couple of years, before the "AJAX" term appeared. As a sidenote, I believe the reason this term took off so well is because the web had been naturally moving in this direction, a lot of bleeding edge developers felt it, knew it in their bones, but until that point, didn't have any term to latch onto. Like a chemical reaction where all the reagents are present in the right quantities but the catalyst is missing.
The answer of course depends on your business circumstances. Ajax isn't right for everyone, but because it's the current buzz word, you'll see a lot of abuses of ajax in the coming months. Sadly it'll detract from the elegance that the technology can lend users.
So anyway, to answer your question in a general fashion, it's got several advantages from traditional web development.
Most importantly, from a user perspective, a well thought out ajax application means a much more responsive interface, and really nothing else. If you expose anything else about ajax to your users, you're doing it wrong (IMHO). The snappiness comes from two aspects. First, asynchronous requests means that the user can keep working while something is processing in the background. Second, there's simply less data to transfer in a well thought out site, so the page itself downloads faster (though usually only on the 2nd and later hits since the first hit involves downloading a potentially sizy library).
Now this point should not be under-considered. From an evil marketing perspective, having a website where users can complete the ordering process in 7 seconds from search to receipt means more sales. Not because you can handle a higher volume (though that's another of ajax's benefits), but because users have less time to reconsider their purchase. Less opportunity to say, "Wonder if I'll find a better deal elsewhere," or, "Do I really want to spend $400 on a new camera when my old one actually does everything I need."
From a technical perspective, I see two main benefits in practice.
First, it represents lower server loads. Traditional web development means you have to rebuild every page every time the user clicks anything. The framework, the navigation, and the logic that goes into determining whether the user sees specific page elements, all has to be redone from scratch every page hit. That takes time and resources: memory to hold that page data on a buffered system, network bandwidth to transfer it, and cpu time to generate it. On a low volume site, this is meaningless. If you're serving 500-1000 hits a second though, this adds up. Of course in that case you're going to have load balancing, and money to throw at additional hardware.
However our work has shown about half the load on a heavily ajax based app from a traditional app, so that's fewer things to go wrong, fewer 2am calls because a hard disk crashed, and fewer hours spent troubleshooting why your edge optomized routing isn't optomizing its edge routing.
Also, from a development perspective, this is exactly the Model View Controller framework that so many people really like to enforce in their development practices. The roles are also clearly defined, since each role happens in a different location. No matter how many MVC frameworks I've worked in, it's always felt forced to me. You end up doing things in an odd and counter-intuitive way in order to pound your complex business logic (which invariably seems to affect display).
The biggest problem is that often business logic *is* the display. In the end, either you end up passing many dozens of flags to your display to affect these things (the correct way, but with more flags, becomes increasingly difficult to not make mistakes), you end up generating some of the display in the model portion (much easier, so lazy programmers will often take this route), or worst of all, you end up putting business logic in the displa
Actually, despite the obvious joke in your comment, I honestly can't decide.
On one hand, we need more alternatives to oil, and anything that hurts that hurts us all in the long run.
On the other hand, if a high profile patent case is brought against hybrid cars, then it'll possibly bring the absurdity of current patent situations into the public light, and I can already hear screaming on the senate floor about the evils of patents.
On the third hand, patents *do* have their uses (recovering research costs and profiting from your truly unobvious inventions), and not knowing the background here, it's possible these guys deserve their patent (even if they should probably have upheld it earlier). Not all patents are evil.
I think this is an interesting idea, but I feel like it's got a few flaws:
If a product that uses your patent without an agreement in place is on the market for X months and you, the patent holder, do not challenge such use, a license is automatically granted for that product.
So I could get myself a license by producing a product, and making sure it's low enough on the radar that it never blips on the patent holder's screen (for example, sell it to a few "customers" for whom I do the same sort of favor in return, and never advertise it).
You can only exercise this challenge Y times over the life of the patent. Y will not include any challenge that is upheld, either initially or after the fact.
In this case, in the case of a really valuable patent, I could set up Y veil companies who are talking about the new "product" they are producing, which provides just enough details to make it appear as if perhaps they're violating your patent. You can challenge all the companies, and when it's discovered that they're not in fact violating the patent (since perhaps they're all vaporware), you've used up your right to challenge. If you fail to challenge any of them for the aforementioned window of opportunity to challenge the use of the patented tech, then whatever company was unchallenged suddenly de-vaporizes their product, and surprise surprise, it uses the patented technology, now granted an implicit license.
Decidedly well said, and I agree with the sentiment, as long as resources exist to implement them. Web development has been my gig for nearly the last 10 years, so I do feel I've got a decent grasp on typical web setups.
In general, maybe 99% of web servers have no protection against a DDoS, and probably 90% of them have at best a software firewall running on the box itself. The enterprise systems (ecommerce) I work on have load balancing switches, multiple servers on the back end, redundancy on all levels (including Internet access, power supply, and all other back end systems). But even we don't have good DDoS protection. Our hardware and Internet connections are pretty high end, so it would take a *massive* DDoS to take us down, but I'm pretty confident that there are people out there with botnets who could manage it (never underestimate the power of 250,000 broadband-connected compromised computers).
There is really *little* you can do to protect yourself from a DDoS, unless you have the infrastructure to absorb the DDoS. There was an article about how a central-american gambling site beat out a DDoS attack (the DDoSers were holding the site for ransome for like $50,000 or something). They ended up needing to proxy their website through a really huge ISP, set up advanced firewall rules to differentiate legitimate traffic from the DDoS traffic, and in the end it cost them $1 million to protect against a $50k extortion effort. (Just found the link: http://www.csoonline.com/read/050105/extortion.htm l )
I had the unfortunate experience of having been on the receiving end of a DDoS (fortunately without any extortion attempt, though I wouldn't have been able to pay it anyhow) on my project site (lotgd.net). About 25,000 unique IP's were requesting random pages on my site, each every 4 minutes. I was pretty helpless to protect against it for the first couple of days, because it was a personal site on a server I rent, my ISP offered no DDoS protection at the time, and I hadn't been able to find any pattern other than that the requests came 4 minutes apart per IP address (plus or minus about 10 seconds). That's about a total of 100 requests per second [on top of my existing user traffic, which is generally about 25 requests per second], and my project is very database heavy.
I couldn't really keep a database of how often each IP address accessed the site on average, because I was already under a heavy enough load, and 25,000 deny entries in my firewall at a time would also lend a heavy load (software based firewall on the web server [iptables]). Further, the IP's kept changing (either someone was only dedicating a small portion of their overall botnet to me at a time, or they mostly had computers that had dynamic IP's). Over the course of the ~2 weeks that the attack took place, there were a total of 1.7 million unique IP's (only ever almost exactly 25,000 at a time, plus or minus a few percent). Obviously I needed an adaptive solution, because a reactive one (where I identified IP's manually or with a script and added them to the firewall) would probably typically have missed the window where I was actually being attacked by any given IP.
The *only* way I was able to beat it is by identifying a few IP's that were obviously attackers, and using a network sniffer to watch their traffic and noticing one thing that was wrong in their IP headers (which I could only do because I happen to know what IP headers should look like). It wasn't even technically wrong, it was just different from all the legit traffic. Then I was able to add a simple firewall rule that fixed the issue, but if the attackers had corrected this, I would have been screwed unless I invested in additional infrastructure. I paid a really hefty bandwidth bill that month (about 4x average usage overall), and I never found out who was attacking me (no one ever sent me an email, but because my site is a gaming site that has specific
Well, programs like Firefox actually warn you before they send information for the first time, and provide you the option to not send that information (though of course you can't request the page that information was going to without providing that information). Of course there's certain information that is always sent with any Internet request, and you won't get away from that with any 'net enabled app.