Nortel doesn't own the IP addresses, yet their bankruptcy trustees decided to sell them anyway, which is probably not legal. Now whether ICANN actually sues them remains to be seen: http://en.wikipedia.org/wiki/Conversion_(law)
Lots of high-current outlets, preferably on several circuits. Some non-fluorescent, repositionable work lights to help kill the flicker and see the work. Locking wheels for everything. Pegboard and hangers. Fans, ventilation, etc.
The problem isn't being able to keep up with younger programmers in quality so much as quantity. As long as managers believe that hours and lines of code are reasonable proxies for quality and success, younger developers will continue to be seen as the saviors of projects long past failure, while the experienced programmers that can implement far better solutions far faster are going to be second class citizens. And the young code factories will be promoted to management, which they will be even more incompetent at, and will continue the same metrics.
At least now people who would not have known about a potential attack vector can take precautions and be safer without having to wait for Microsoft to introduce more vulnerabilities when they come up with a "fix" for this one.
I'm fairly certain that past a certain volume, keeping a significant fraction of requests resident in RAM is not actually possible. Consider sites serving up large media files that are constantly changing, and even with a fairly large budget having RAM to cache all of that content is not reasonable. It's not much larger when having sufficient spindles for naïve algorithms is also not an option.
At this point having intelligent algorithms that understand non-uniform memory access patterns is essential, whether it's L1 - L2 cache, cache to SDRAM, RAM to disk, and even local disks to network storage. This is where algorithms like B*-tree and the B*-heap start to perform much better, since they're designed around such non-uniform memory access. Database engines also have been designing indexes around these principles for decades, although in a very specific way that's much more difficult to use generally.
So while it may be comforting to throw out the RAM card and give up when the reality of budgets and billion-dollar-RAM-caching systems are unobtainable and give up, actually trying to solve the underlying problem is much more interesting.
I use them on ext3 with no problems. It's true that very early on there was a problem with them and journaled filesystems, but that has long since been solved.
They are not at all related. Seriously. And if you are getting requirements you think Hibernate can't fulfill, you have done something so fundamentally wrong somewhere that if you code the database layer yourself you will be completely screwed. So find out what the real problem is and what you need to change to work with Hibernate.
The OLPC project actually demonstrates what an organization not making maximizing their profit their main focus can accomplish. While the Eee PC is impressive for a laptop that inexpensive, it doesn't compare at all to the OLPC. Of course, the reverse is also true.
The ASUS Eee PC is a general purpose laptop designed to run standard consumer software and handle normal consumer tasks. It will run in a coffee shop, an office, a car, and will work well with a standard First World internet connection. And it's really cheap. It's nice. I'd like a few to play with.
The OLPC system has a custom operating system with support for ad-hoc networking, a display that works indoors in color (back-lit) and outdoors in black-and-white (not back-lit). It has a ruggedized case, and a hand crank so you don't need a centralized power grid to recharge periodically. The organization did many usability studies to design the hardware and the software together so it would be easier for children of any background to learn.
So, while building a $200 laptop isn't difficult, building one that can operate in conditions more adverse than the typical coffee shop with a custom operating system that takes advantage of things like the display and lighting conditions with a dynamic range far larger than even the highest contrast ratio LCD and a full ad-hoc wireless mesh networking stack for under $200 is actually impressive.
If you leave, find another job (that likely pays more anyway), and they have to replace you, they'll figure out pretty quickly what metrics they should have used to measure your productivity. And you'll be in a job that doesn't try and manage knowledge workers the same way as unskilled labor.
I managed to catch front-row seats to the whole battle myself. Buesch (the Linux bcm43xx developer) posted a formal but not in any way harsh question to the BSD developer on the public bcm43xx list and to the BSD list. In any language, when communicating in unfamiliar places with unfamiliar people, using more formal dialects is almost always the rule. Some people find the higher dialects offensive, but almost everyone appreciates the attempts to not sound like one of the local street punks hanging out around the corner at the strip mall trolling for some action.
Apparently the OpenBSD people were put off by this, which is unfortunate. And apparently they were so focused on making it yet another OpenBSD vs The World incident that they completely lost sight of the goal of both projects, which is to create Free and Open drivers for other people to use, despite the hardware specifications not being available. It's an unfortunate situation, of course.
Hopefully after everyone has a chance to reflect on the situation, the OpenBSD developers will realize that even though many other situations are actually OpenBSD vs The World, this is not one of them, and the Linux bcm-43xx team was not only willing to work with them on relicensing code, they also published the results of an incredible reverse engineering effort for anyone, including the OpenBSD team, to use in order to achieve this goal.
So basically the company doesn't have the budget for a $200 off-site USB drive (on the cheap, this can be housed at the sysadmin's home, even), but would be willing to pay out on a lawsuit brought by the family of the victim who was dedicated enough to risk his own life to make up for the complete and total short-sightedness of his managers? Excellent precedent. Now we know why management is so stupid sometimes. There's always a technical stud who is willing to risk his life to cover up the fuckups of his higherups.
I'm going through something similar now with my company. Recently we've been bringing on clients who have grown to the point they can no longer manage things in-house, and need outside assistance. We've been going in, and across the board, they want things done "right", meaning we get in, map out their networks, and then suggest changes. The companies this works best at are the ones who understand that it's better if we stick to this mapping plan, don't make any changes ourselves, and then come up with good, feasible, recommendations for improving their systems.
The bad ones are the ones where a week into a mapping, they decide that things must be "done now", and then it's a slash-and-burn saga with an exploding budget and lots of outages. Usually after this, these clients are reformed and become good ones. Otherwise, it's just unrewarding money for us.
They may not be watching the process directly, but seeing the resulting code will still reveal a lot about the candidate. Is the code clear and readable even when the candidate is coding under pressure? Does the candidiate point out rought spots? Does the candidate comment on why a particular solution was chosen over another? Did the candidate put any thought into the problem at all, or did he just fold and give up without any effort to discover what the nature of possible solutions would be? There are many ways to pass a test by failing an exercise gracefully, and many ways to fail a test by not taking it at all.
The Battle-Hardened Veteran would explain to the potential employer/customer why the problem was impossible, and while perhaps not providing a formal proof, would present enough evidence that he would be seen as a Veteran. And he would still make an attempt to do it anyway, just to be sure. Watching how a person discovers why something is not possible is far more revealing than listening yet again to someone state quickly that it cannot be done.
Seeing a possible candidate breaking down the problem of writing a web server in an hour and studying how they approach it is far more telling about them than typical interview questions. Most candidates would throw up their hands and say "It can't be done", which demonstrates completely that they aren't the kinds of people who should be working there.
It may not be a conspiracy so much as doctors not wanting to deal with trying to argue patients out of eating refined sugars. It's bad enough I'm sure with patients always demanding some sort of magic cure which requires no work on their part and some magic pills. To actually suggest to a patient "Well, you're going to have to not eat anything with sucrose, which means you'll have to read nutrition labels and stop eating any sweet substance" would pretty much turn into an uncomfortable situation. With diabetes, it's actually life-threatening and the disease has a certain image, so patients are probably more willing to change a lot. But for a non-life-threatening condition, I can imagine that patients would fall back on the typical whining and demanding.
If it were the students' information on their own computers getting stolen, it would be much like someone breaking into their homes and stealing their things.
However, the school is holding the students' personal information, and not securing it properly. This requires a different analogy, and if one is required, it would be more like going into a restaurant, handing over your credit card, and the staff then allowing anyone who drives by to take a copy of your credit card number and signature.
If the school requires that the students' personal information be stored indefinitely, they should also be required to excercise reasonable care in protecting it from theft. Otherwise, the school should be held fully liable for whatever damage is caused by the theft of the information, much like a restaurant would be peanalized severely for handing out customer credit cards freely.
Colocate a system or two at an ISP that charges by transfer for the large traffic content, and upload updates to that over a standard Internet link using rsync or ftp. Then, you only need to pay for actual data transferred.
If your company is adamant about having everything in-house, get a Point-Point link to the nearest Internet Nexus (probably not far if you're in any sort of city), and terminate its far end in an ISP that will charge by transfer instead of by allocation.
Ideally, lease dark fiber for this link so that you don't need to pay a telco to carry your traffic over their network, although since you're not buying transit from the telco, it will drop the price of the link significantly.
Slashdot Mirror
Q.E.D.
Nortel doesn't own the IP addresses, yet their bankruptcy trustees decided to sell them anyway, which is probably not legal. Now whether ICANN actually sues them remains to be seen: http://en.wikipedia.org/wiki/Conversion_(law)
PHP, my days of not taking you seriously are certainly coming to a middle.
Lots of high-current outlets, preferably on several circuits. Some non-fluorescent, repositionable work lights to help kill the flicker and see the work. Locking wheels for everything. Pegboard and hangers. Fans, ventilation, etc.
Not Zombies. A Hive Mind: http://en.wikipedia.org/wiki/LOIC
The problem isn't being able to keep up with younger programmers in quality so much as quantity. As long as managers believe that hours and lines of code are reasonable proxies for quality and success, younger developers will continue to be seen as the saviors of projects long past failure, while the experienced programmers that can implement far better solutions far faster are going to be second class citizens. And the young code factories will be promoted to management, which they will be even more incompetent at, and will continue the same metrics.
Even better would be a language that didn't need horrendous amounts of crappy boilerplate code for every API.
At least now people who would not have known about a potential attack vector can take precautions and be safer without having to wait for Microsoft to introduce more vulnerabilities when they come up with a "fix" for this one.
I'm fairly certain that past a certain volume, keeping a significant fraction of requests resident in RAM is not actually possible. Consider sites serving up large media files that are constantly changing, and even with a fairly large budget having RAM to cache all of that content is not reasonable. It's not much larger when having sufficient spindles for naïve algorithms is also not an option.
At this point having intelligent algorithms that understand non-uniform memory access patterns is essential, whether it's L1 - L2 cache, cache to SDRAM, RAM to disk, and even local disks to network storage. This is where algorithms like B*-tree and the B*-heap start to perform much better, since they're designed around such non-uniform memory access. Database engines also have been designing indexes around these principles for decades, although in a very specific way that's much more difficult to use generally.
So while it may be comforting to throw out the RAM card and give up when the reality of budgets and billion-dollar-RAM-caching systems are unobtainable and give up, actually trying to solve the underlying problem is much more interesting.
I use them on ext3 with no problems. It's true that very early on there was a problem with them and journaled filesystems, but that has long since been solved.
They are not at all related. Seriously. And if you are getting requirements you think Hibernate can't fulfill, you have done something so fundamentally wrong somewhere that if you code the database layer yourself you will be completely screwed. So find out what the real problem is and what you need to change to work with Hibernate.
You are wrong.
The OLPC project actually demonstrates what an organization not making maximizing their profit their main focus can accomplish. While the Eee PC is impressive for a laptop that inexpensive, it doesn't compare at all to the OLPC. Of course, the reverse is also true.
The ASUS Eee PC is a general purpose laptop designed to run standard consumer software and handle normal consumer tasks. It will run in a coffee shop, an office, a car, and will work well with a standard First World internet connection. And it's really cheap. It's nice. I'd like a few to play with.
The OLPC system has a custom operating system with support for ad-hoc networking, a display that works indoors in color (back-lit) and outdoors in black-and-white (not back-lit). It has a ruggedized case, and a hand crank so you don't need a centralized power grid to recharge periodically. The organization did many usability studies to design the hardware and the software together so it would be easier for children of any background to learn.
So, while building a $200 laptop isn't difficult, building one that can operate in conditions more adverse than the typical coffee shop with a custom operating system that takes advantage of things like the display and lighting conditions with a dynamic range far larger than even the highest contrast ratio LCD and a full ad-hoc wireless mesh networking stack for under $200 is actually impressive.
If you leave, find another job (that likely pays more anyway), and they have to replace you, they'll figure out pretty quickly what metrics they should have used to measure your productivity. And you'll be in a job that doesn't try and manage knowledge workers the same way as unskilled labor.
I managed to catch front-row seats to the whole battle myself. Buesch (the Linux bcm43xx developer) posted a formal but not in any way harsh question to the BSD developer on the public bcm43xx list and to the BSD list. In any language, when communicating in unfamiliar places with unfamiliar people, using more formal dialects is almost always the rule. Some people find the higher dialects offensive, but almost everyone appreciates the attempts to not sound like one of the local street punks hanging out around the corner at the strip mall trolling for some action.
Apparently the OpenBSD people were put off by this, which is unfortunate. And apparently they were so focused on making it yet another OpenBSD vs The World incident that they completely lost sight of the goal of both projects, which is to create Free and Open drivers for other people to use, despite the hardware specifications not being available. It's an unfortunate situation, of course.
Hopefully after everyone has a chance to reflect on the situation, the OpenBSD developers will realize that even though many other situations are actually OpenBSD vs The World, this is not one of them, and the Linux bcm-43xx team was not only willing to work with them on relicensing code, they also published the results of an incredible reverse engineering effort for anyone, including the OpenBSD team, to use in order to achieve this goal.
So basically the company doesn't have the budget for a $200 off-site USB drive (on the cheap, this can be housed at the sysadmin's home, even), but would be willing to pay out on a lawsuit brought by the family of the victim who was dedicated enough to risk his own life to make up for the complete and total short-sightedness of his managers? Excellent precedent. Now we know why management is so stupid sometimes. There's always a technical stud who is willing to risk his life to cover up the fuckups of his higherups.
When IBM started sponsoring it.
Or, when it became large enough for statisticians to start trending behavior patterns.
I'm going through something similar now with my company. Recently we've been bringing on clients who have grown to the point they can no longer manage things in-house, and need outside assistance. We've been going in, and across the board, they want things done "right", meaning we get in, map out their networks, and then suggest changes. The companies this works best at are the ones who understand that it's better if we stick to this mapping plan, don't make any changes ourselves, and then come up with good, feasible, recommendations for improving their systems.
The bad ones are the ones where a week into a mapping, they decide that things must be "done now", and then it's a slash-and-burn saga with an exploding budget and lots of outages. Usually after this, these clients are reformed and become good ones. Otherwise, it's just unrewarding money for us.
They may not be watching the process directly, but seeing the resulting code will still reveal a lot about the candidate. Is the code clear and readable even when the candidate is coding under pressure? Does the candidiate point out rought spots? Does the candidate comment on why a particular solution was chosen over another? Did the candidate put any thought into the problem at all, or did he just fold and give up without any effort to discover what the nature of possible solutions would be? There are many ways to pass a test by failing an exercise gracefully, and many ways to fail a test by not taking it at all.
The Battle-Hardened Veteran would explain to the potential employer/customer why the problem was impossible, and while perhaps not providing a formal proof, would present enough evidence that he would be seen as a Veteran. And he would still make an attempt to do it anyway, just to be sure. Watching how a person discovers why something is not possible is far more revealing than listening yet again to someone state quickly that it cannot be done.
Seeing a possible candidate breaking down the problem of writing a web server in an hour and studying how they approach it is far more telling about them than typical interview questions. Most candidates would throw up their hands and say "It can't be done", which demonstrates completely that they aren't the kinds of people who should be working there.
It may not be a conspiracy so much as doctors not wanting to deal with trying to argue patients out of eating refined sugars. It's bad enough I'm sure with patients always demanding some sort of magic cure which requires no work on their part and some magic pills. To actually suggest to a patient "Well, you're going to have to not eat anything with sucrose, which means you'll have to read nutrition labels and stop eating any sweet substance" would pretty much turn into an uncomfortable situation. With diabetes, it's actually life-threatening and the disease has a certain image, so patients are probably more willing to change a lot. But for a non-life-threatening condition, I can imagine that patients would fall back on the typical whining and demanding.
If it were the students' information on their own computers getting stolen, it would be much like someone breaking into their homes and stealing their things.
However, the school is holding the students' personal information, and not securing it properly. This requires a different analogy, and if one is required, it would be more like going into a restaurant, handing over your credit card, and the staff then allowing anyone who drives by to take a copy of your credit card number and signature.
If the school requires that the students' personal information be stored indefinitely, they should also be required to excercise reasonable care in protecting it from theft. Otherwise, the school should be held fully liable for whatever damage is caused by the theft of the information, much like a restaurant would be peanalized severely for handing out customer credit cards freely.
Decent pipe and RAID hardware
Colocate a system or two at an ISP that charges by transfer for the large traffic content, and upload updates to that over a standard Internet link using rsync or ftp. Then, you only need to pay for actual data transferred.
If your company is adamant about having everything in-house, get a Point-Point link to the nearest Internet Nexus (probably not far if you're in any sort of city), and terminate its far end in an ISP that will charge by transfer instead of by allocation.
Ideally, lease dark fiber for this link so that you don't need to pay a telco to carry your traffic over their network, although since you're not buying transit from the telco, it will drop the price of the link significantly.