When I was at Red Hat, the conventional wisdom even in late 2006 was that Novell was dying and the growing threat was Canonical. Novell was dying before it bought SuSE, and nothing about that acquisition did anything about the unprofitable business lines that were driving Novell to its grave. The main thing Novell brought to the table was its sales channels, but that made for an enterprise Linux company with much more overhead than Red Hat and fewer customers. If SuSE is spun off or sold to a profitable tech company, it could remain quite viable. If it's allowed to languish, Canonical's leaner operation will probably grow fast enough to begin to challenge Red Hat in the enterprise market by the time SuSE fades from the scene, so it's unlikely that there will be a functional monopoly any time soon. If for some reason Canonical fails to execute on that, its history is proof enough that a challenger can be created relatively quickly with an initial investment that's well within the reach of many major tech companies.
Hardware that old uses sufficiently large components such that the mundane cosmic rays that regularly strike earth and earth-orbiting satellites are generally not strong enough to flip a bit. While it's certainly possible that one got a lucky shot, it's also quite possible that the hardware is failing, or that Voyager 2 is encountering much more energetic cosmic rays at the edge of the protective range of the Sun's magnetic field. Assuming the reset works, it'll be interesting to see how it fares as it flies further from the Sun's protection.
Forget dual-core, and forget hyperthreading. I just want one core that's reasonably fast without burning through my battery life. Two slow cores that give me four very slow threads is not going to be much help. They only way I'm going to use 4 logical CPUs is if I'm doing some very heavy multitasking, or running heavy number-crunching apps that take advantage of multiple CPUs. That doesn't sound much like a netbook.
If we're talking about heart surgery that happens while your heart is stopped, then a transatlantic session wouldn't be a problem, but 100 ms latency links plus moving parts are a bad combination.
I don't really care who wins the lawsuit, but the PR fight is sure to be full of blatant hypocrisy. Meanwhile Google gets to brag about how Android is open source, the Android Market isn't held hostage to the whims of Steve Jobs, and they support both Flash and HTML 5.
...is to reassure people you have not yet attacked that you will not attack them, unless of course they attack you first. IBM has been trying to bury Hercules since long before they made their patent pledge. While this is certainly a violation of the letter of the patent pledge, it is not a violation of the spirit of the patent pledge, which is that open source developers will not get in trouble with IBM for using these specific techniques. IBM isn't mad at Hercules because of these two patents, they just happen to have been dug up in the patent review they did because they're mad at Hercules for daring to threaten their mainframe business, which is an infuriatingly inflexible division of the company that is defending its dying empire as viciously as Microsoft.
Most of IBM realizes that its business advantage in the mainframe space is with all the RAS features implemented in hardware and firmware, and that anything that makes it easier for developers to write code for the platform (like an emulator) improves the value of those products, but the mainframe business, which is quite appropriately extremely conservative, is terrified that all their customers who are using the s390 architecture to run 20-year-old legacy apps might suddenly move them all to x86 servers.
The reality is that anyone paying for the exorbitant service contracts for an IBM mainframe just to support legacy apps is either so poorly managed that they'll be losing budget or going out of business soon, or is smart enough that they're trying to modernize the apps, which gives them an opportunity to move to a platform where IBM doesn't have them by the balls. If IBM were to back off of Hercules, it would probably make people feel a lot more comfortable about continuing to use such an arcane and unique architecture, and drive more sales in the long term. Unfortunately, I don't think the culture of that group will really change much until their biggest competitor, the IBM POWER group, devours them and enforces a more flexible outlook on community relations.
The job market is shit right now. People with lots of very valuable experience are having great difficulty getting a foot in the door.
Do you know people who work for companies that are hiring? Recommendations from employees put you in a totally different (and much shorter) stack on the HR desk than unsolicited resumes. That's not because of rampant corruption, but rather the very real fact that no sane hiring process can come close to evaluating how effectively a software developer will work as well as actually working with the person, be it in industry or school. Work those contacts.
...are meant to sidestep the halting problem. I've never seen a programming contest problem that couldn't be solved within the time limit with a naive O(n^3) algorithm in the slowest interpreted language available.
Yes, reverse-engineering a driver *is* expensive, but when you compare it to the man-years of labor Red Hat has spent due to the binary blob writing random crap all over physical memory causing weird crashes, or merely investigating the possibility of the binary blob writing random crap all over physical memory for any given crash, it suddenly makes a lot of sense. Sure, the Nvidia driver is fast, but it's written with the philosophy that it's more important to be fast than correct, to the point where they actually patent their bugs. And that driver is running inside the kernel, with the ability to corrupt anything and everything on the system. Usually it doesn't, but it has the capability, and it has demonstrated the inclination on occasion. Tracking down memory corruption bugs is a fantastic pain in the ass even when you have the source code, let alone when you don't.
After a recent change in hardware platform for new acquisitions, Facebook was surprised to get a speedup from RDDR2-800 memory vs. FB-DDR2-667 memory, because many of their apps are actually memory-bound. They're a major user of memcached, so the real limiting factor on how many servers they can power down is how much RAM they can stuff in a server. The CPU utilization comes somewhere after memory/disk throughput/latency in power conservation considerations. Sure, there's a small marginal difference in how much energy they burn through on PHP code vs. C++ code, and a small marginal difference in how much RAM they need free for PHP vs. C++ code, but for the effort it would take them to switch to C++, they could save a lot more energy by optimizing how they use memcached. Which is exactly what they're doing.
...Microsoft is planning to support 5-letter acronym hardware, even though the industry has not yet completed the migration from 3-letter acronyms to 4-letter acronyms. The 5-letter version of the operating system will support 4-letter acronyms, but will not be backwards compatible with shorter acronyms, such as the popular "CPU" and "RAM" used widely in the computer industry.
Who's more likely to do something damaging with your data: one of the few Google employees who has direct access to it as part of a sea of data belonging to millions, or the disgruntled tech in your own company who has access to the server room?
I'm not saying that you should outsource without a second thought, but if you have a contract with clear terms for how your data should be handled, with an explicit lack of disclaimer of liability for damage to your business in case they mess up, and you outsource to a company with a track record of managing their systems at least as well as your own staff, you're probably at less of a risk of malicious disclosure with your data in the hands of a reputable disinterested party.
On the other hand, if the outsourcing provider wants you to sign away all your rights (and many do), they don't have much of an incentive to adhere to the terms of the contract, so you should stay away.
...didn't contain information directly relevant to his research! How can he be expected to waste his valuable time reading it? That's what he has Chinese and Iranian grad students for.
Forcing researchers to actually read documents they sign will severely hamper their research output. This is a slippery slope to enforcing acceptable use policies, delaying ethically sensitive experiments for IRB reviews, and punishing careless plagiarism. Does tenure mean nothing?
I'm terribly afraid a certain former adviser of mine could be swept up in this dragnet of red tape. I'd email him a link to this story, but I'm sure he wouldn't have time to read it.
Fixing a bug, or fixing a design flaw? If your customers aren't going to ditch you for the occasional glitch, and it sounds like yours won't, it's much more important to focus your resources on making sure that they have a good overall experience.
...that Airbus goes to the extreme effort of formally verifying code used in flight control systems. Theoretically, this should make the software as close to infallible as anything else on the aircraft. Unfortunately, as the airspeed indicator defect on the A330 demonstrates, a computer program, however perfect, is only as reliable as the data it receives. If the flight data recorders are ever recovered, it will be interesting to see if the computer system entered a "should never happen" codepath. Based on the error messages that were transmitted before the crash, it appears that the instruments were indeed reporting inaccurate information, though it's quite possible that that's simply a result of the same extreme conditions that caused a completely independent failure, rather than a cause of a failure cascade. At the very least, confusion in the cockpit is never good, regardless of how much ability the pilots have to override the computer.
...is about a 1000x difference in cost per line of code. There's a lot of pure software engineering going on out there, but the products are relatively few (and usually heavily re-used) because the cost of being reasonably certain no one will die is really quite astronomical. Most people who call themselves software engineers with a straight face are really doing something in between, which is why we have entire libraries full of books describing methods that trade off varying degrees of safety for economy.
In one sense, software engineering can be considered a more formal discipline than other forms of engineering, because software engineering has studied in much greater depth the tradeoffs between formality and economy, since the spread between them is so much wider.
...which isn't GPS at all when you're inside a building without a broad line of sight to the sky, so the best resolution they'll have is based on cell information, perhaps refined somewhat by triangulation, but there's limited resolution with that. I'm pretty sure that every last one of my lecture halls in college was within 30 meters of both a lab full of nice gaming boxes (err, CAD workstations) and a lounge with comfy couches.
As always, when considering a new technology, the best place to deploy it is in large, single-purpose setups that actually benefit from the differences relative to the thing you're replacing. You'd have to be completely nuts to migrate an existing data center full of disparate workloads to ext4, but if you're about to deploy a bunch of functionally identical streaming media servers where the improvements in handling large volumes and files will make a measurable difference, and the cost of validating the setup is amortized across several production systems, you'd really be nuts not to at least consider it. If there's an app that does something stupid, you have one bug report to file instead of 50, and you need to change one install configuration file to fix it.
I've used several different IDEs, with several different languages, for many different programming tasks, over the past decade. I have encountered exactly one instance where having a "project" be anything more than a collection of files I work on at the same time was actually a good thing. Every other time it has simply been an obstacle to bottom-up design, by forcing me to make a lot of decisions about the structure of my code before most of it had actually been written.
The one time the project-oriented IDE was a good thing, I was working on a large app with more than a dozen people who never got to all meet at once, with a central authority dictating the general structure of things to make sure we didn't duplicate effort or step on each others' toes. There was AI involved, so having an integrated debugger to figure out why the AI was making particular choices was very useful. Kdevelop served us very well.
Of course, large development teams are inefficient and prone to communication problems that cause delays and bugs, so they should be avoided whenever possible, just like top-down design. Most of the time, I'm either working on incremental modifications to mature code, where a glorified source browser is sufficient, or writing a small utility from scratch by myself, where I really just need a text editor and a command line. I generally use kscope for the former, and kate for the latter. They get out of the way and let me code.
Sure, I still use a debugger, but the overwhelming majority of the time it's to analyze dumps from crashes I can't reproduce easily, so integrating it with the IDE offers no benefit. A debugger is no substitute for understanding the code, and I can count on one hand the number of times there have been enough control flow-relevant variables being modified at once to make that something I couldn't work out in my head or on a whiteboard.
Slashdot Mirror
When I was at Red Hat, the conventional wisdom even in late 2006 was that Novell was dying and the growing threat was Canonical. Novell was dying before it bought SuSE, and nothing about that acquisition did anything about the unprofitable business lines that were driving Novell to its grave. The main thing Novell brought to the table was its sales channels, but that made for an enterprise Linux company with much more overhead than Red Hat and fewer customers. If SuSE is spun off or sold to a profitable tech company, it could remain quite viable. If it's allowed to languish, Canonical's leaner operation will probably grow fast enough to begin to challenge Red Hat in the enterprise market by the time SuSE fades from the scene, so it's unlikely that there will be a functional monopoly any time soon. If for some reason Canonical fails to execute on that, its history is proof enough that a challenger can be created relatively quickly with an initial investment that's well within the reach of many major tech companies.
Hardware that old uses sufficiently large components such that the mundane cosmic rays that regularly strike earth and earth-orbiting satellites are generally not strong enough to flip a bit. While it's certainly possible that one got a lucky shot, it's also quite possible that the hardware is failing, or that Voyager 2 is encountering much more energetic cosmic rays at the edge of the protective range of the Sun's magnetic field. Assuming the reset works, it'll be interesting to see how it fares as it flies further from the Sun's protection.
Forget dual-core, and forget hyperthreading. I just want one core that's reasonably fast without burning through my battery life. Two slow cores that give me four very slow threads is not going to be much help. They only way I'm going to use 4 logical CPUs is if I'm doing some very heavy multitasking, or running heavy number-crunching apps that take advantage of multiple CPUs. That doesn't sound much like a netbook.
If we're talking about heart surgery that happens while your heart is stopped, then a transatlantic session wouldn't be a problem, but 100 ms latency links plus moving parts are a bad combination.
...that just UPGRADED to IE 6.
*headdesk*
I really wish I had mod points right now. I'm with you on this.
I don't really care who wins the lawsuit, but the PR fight is sure to be full of blatant hypocrisy. Meanwhile Google gets to brag about how Android is open source, the Android Market isn't held hostage to the whims of Steve Jobs, and they support both Flash and HTML 5.
I'm making popcorn.
...is to reassure people you have not yet attacked that you will not attack them, unless of course they attack you first. IBM has been trying to bury Hercules since long before they made their patent pledge. While this is certainly a violation of the letter of the patent pledge, it is not a violation of the spirit of the patent pledge, which is that open source developers will not get in trouble with IBM for using these specific techniques. IBM isn't mad at Hercules because of these two patents, they just happen to have been dug up in the patent review they did because they're mad at Hercules for daring to threaten their mainframe business, which is an infuriatingly inflexible division of the company that is defending its dying empire as viciously as Microsoft.
Most of IBM realizes that its business advantage in the mainframe space is with all the RAS features implemented in hardware and firmware, and that anything that makes it easier for developers to write code for the platform (like an emulator) improves the value of those products, but the mainframe business, which is quite appropriately extremely conservative, is terrified that all their customers who are using the s390 architecture to run 20-year-old legacy apps might suddenly move them all to x86 servers.
The reality is that anyone paying for the exorbitant service contracts for an IBM mainframe just to support legacy apps is either so poorly managed that they'll be losing budget or going out of business soon, or is smart enough that they're trying to modernize the apps, which gives them an opportunity to move to a platform where IBM doesn't have them by the balls. If IBM were to back off of Hercules, it would probably make people feel a lot more comfortable about continuing to use such an arcane and unique architecture, and drive more sales in the long term. Unfortunately, I don't think the culture of that group will really change much until their biggest competitor, the IBM POWER group, devours them and enforces a more flexible outlook on community relations.
The job market is shit right now. People with lots of very valuable experience are having great difficulty getting a foot in the door.
Do you know people who work for companies that are hiring? Recommendations from employees put you in a totally different (and much shorter) stack on the HR desk than unsolicited resumes. That's not because of rampant corruption, but rather the very real fact that no sane hiring process can come close to evaluating how effectively a software developer will work as well as actually working with the person, be it in industry or school. Work those contacts.
...are meant to sidestep the halting problem. I've never seen a programming contest problem that couldn't be solved within the time limit with a naive O(n^3) algorithm in the slowest interpreted language available.
Python will be fine.
Yes, reverse-engineering a driver *is* expensive, but when you compare it to the man-years of labor Red Hat has spent due to the binary blob writing random crap all over physical memory causing weird crashes, or merely investigating the possibility of the binary blob writing random crap all over physical memory for any given crash, it suddenly makes a lot of sense. Sure, the Nvidia driver is fast, but it's written with the philosophy that it's more important to be fast than correct, to the point where they actually patent their bugs. And that driver is running inside the kernel, with the ability to corrupt anything and everything on the system. Usually it doesn't, but it has the capability, and it has demonstrated the inclination on occasion. Tracking down memory corruption bugs is a fantastic pain in the ass even when you have the source code, let alone when you don't.
After a recent change in hardware platform for new acquisitions, Facebook was surprised to get a speedup from RDDR2-800 memory vs. FB-DDR2-667 memory, because many of their apps are actually memory-bound. They're a major user of memcached, so the real limiting factor on how many servers they can power down is how much RAM they can stuff in a server. The CPU utilization comes somewhere after memory/disk throughput/latency in power conservation considerations. Sure, there's a small marginal difference in how much energy they burn through on PHP code vs. C++ code, and a small marginal difference in how much RAM they need free for PHP vs. C++ code, but for the effort it would take them to switch to C++, they could save a lot more energy by optimizing how they use memcached. Which is exactly what they're doing.
But if you run Linux on it, you have to deal with the Nvidia drivers.
...Microsoft is planning to support 5-letter acronym hardware, even though the industry has not yet completed the migration from 3-letter acronyms to 4-letter acronyms. The 5-letter version of the operating system will support 4-letter acronyms, but will not be backwards compatible with shorter acronyms, such as the popular "CPU" and "RAM" used widely in the computer industry.
...rest assured that the department's signing key is stored on a Windows 2008 server with many open ports.
Oh, wait...
Who's more likely to do something damaging with your data: one of the few Google employees who has direct access to it as part of a sea of data belonging to millions, or the disgruntled tech in your own company who has access to the server room?
I'm not saying that you should outsource without a second thought, but if you have a contract with clear terms for how your data should be handled, with an explicit lack of disclaimer of liability for damage to your business in case they mess up, and you outsource to a company with a track record of managing their systems at least as well as your own staff, you're probably at less of a risk of malicious disclosure with your data in the hands of a reputable disinterested party.
On the other hand, if the outsourcing provider wants you to sign away all your rights (and many do), they don't have much of an incentive to adhere to the terms of the contract, so you should stay away.
...didn't contain information directly relevant to his research! How can he be expected to waste his valuable time reading it? That's what he has Chinese and Iranian grad students for.
Forcing researchers to actually read documents they sign will severely hamper their research output. This is a slippery slope to enforcing acceptable use policies, delaying ethically sensitive experiments for IRB reviews, and punishing careless plagiarism. Does tenure mean nothing?
I'm terribly afraid a certain former adviser of mine could be swept up in this dragnet of red tape. I'd email him a link to this story, but I'm sure he wouldn't have time to read it.
Fixing a bug, or fixing a design flaw? If your customers aren't going to ditch you for the occasional glitch, and it sounds like yours won't, it's much more important to focus your resources on making sure that they have a good overall experience.
...that Airbus goes to the extreme effort of formally verifying code used in flight control systems. Theoretically, this should make the software as close to infallible as anything else on the aircraft. Unfortunately, as the airspeed indicator defect on the A330 demonstrates, a computer program, however perfect, is only as reliable as the data it receives. If the flight data recorders are ever recovered, it will be interesting to see if the computer system entered a "should never happen" codepath. Based on the error messages that were transmitted before the crash, it appears that the instruments were indeed reporting inaccurate information, though it's quite possible that that's simply a result of the same extreme conditions that caused a completely independent failure, rather than a cause of a failure cascade. At the very least, confusion in the cockpit is never good, regardless of how much ability the pilots have to override the computer.
...is about a 1000x difference in cost per line of code. There's a lot of pure software engineering going on out there, but the products are relatively few (and usually heavily re-used) because the cost of being reasonably certain no one will die is really quite astronomical. Most people who call themselves software engineers with a straight face are really doing something in between, which is why we have entire libraries full of books describing methods that trade off varying degrees of safety for economy.
In one sense, software engineering can be considered a more formal discipline than other forms of engineering, because software engineering has studied in much greater depth the tradeoffs between formality and economy, since the spread between them is so much wider.
...where it's illegal to build within 100km of historical landmarks.
Oh, wait.
...which isn't GPS at all when you're inside a building without a broad line of sight to the sky, so the best resolution they'll have is based on cell information, perhaps refined somewhat by triangulation, but there's limited resolution with that. I'm pretty sure that every last one of my lecture halls in college was within 30 meters of both a lab full of nice gaming boxes (err, CAD workstations) and a lounge with comfy couches.
As always, when considering a new technology, the best place to deploy it is in large, single-purpose setups that actually benefit from the differences relative to the thing you're replacing. You'd have to be completely nuts to migrate an existing data center full of disparate workloads to ext4, but if you're about to deploy a bunch of functionally identical streaming media servers where the improvements in handling large volumes and files will make a measurable difference, and the cost of validating the setup is amortized across several production systems, you'd really be nuts not to at least consider it. If there's an app that does something stupid, you have one bug report to file instead of 50, and you need to change one install configuration file to fix it.
Don't be first, but definitely don't be last.
I've used several different IDEs, with several different languages, for many different programming tasks, over the past decade. I have encountered exactly one instance where having a "project" be anything more than a collection of files I work on at the same time was actually a good thing. Every other time it has simply been an obstacle to bottom-up design, by forcing me to make a lot of decisions about the structure of my code before most of it had actually been written.
The one time the project-oriented IDE was a good thing, I was working on a large app with more than a dozen people who never got to all meet at once, with a central authority dictating the general structure of things to make sure we didn't duplicate effort or step on each others' toes. There was AI involved, so having an integrated debugger to figure out why the AI was making particular choices was very useful. Kdevelop served us very well.
Of course, large development teams are inefficient and prone to communication problems that cause delays and bugs, so they should be avoided whenever possible, just like top-down design. Most of the time, I'm either working on incremental modifications to mature code, where a glorified source browser is sufficient, or writing a small utility from scratch by myself, where I really just need a text editor and a command line. I generally use kscope for the former, and kate for the latter. They get out of the way and let me code.
Sure, I still use a debugger, but the overwhelming majority of the time it's to analyze dumps from crashes I can't reproduce easily, so integrating it with the IDE offers no benefit. A debugger is no substitute for understanding the code, and I can count on one hand the number of times there have been enough control flow-relevant variables being modified at once to make that something I couldn't work out in my head or on a whiteboard.