I'll put it this way, the last time I saw an evaluation of Linux I/O schedulers on a mainframe, the numbers were met with "That's not possible." from people who were used to having 4 dual-port Fibre Channel HBAs in a high-end Xeon/Opteron box.
Actually, a modern mainframe CPU has about the MIPS of a PII. Their strength is in reliability and I/O capacity. They use (very expensive) accelerators for CPU-intensive tasks. If you want to run Vista on one of these things, you'd need to spend a quarter million dollars on a video card.
Of course, that video card would be able to render 64 desktops simultaneously, and if it started to overheat, it would email the vendor, who would send you a replacement overnight, and you could replace it without downtime.
I'm willing to accept that the BIOS was mere incompetence, but the customer service is actively malicious. This is totally unprofessional, and the people responsible should be fired.
If you want to avoid overloading the utilities, you need to charge at night. There are two challenges with this:
1) You need the capacity to run all day.
2) You need to encourage consumers to charge at night. Currently only wholesale customers pay different rates depending on the hour. Expanding this to residential customers would require a substantial overhaul of distribution networks. Fortunately, everyone agrees we need an overhaul anyway. Unfortunately, this would make that overhaul more expensive and delay it further.
There are still people doing pure research to make machines do something resembling human thought, but this just isn't a very interesting problem to industry for the simple reason that we already have humans that can do that, and we understand how to manage them and tap their intellect quite well. The real money is in doing things that humans can't do at all. Historically this has been done in heavy beige boxes, but with laptops, smart phones, and embedded devices becoming more ubiquitous, there's a lot of low-hanging fruit where a small amount of engineering effort can greatly improve economic efficiency and quality of life, and as long as this is true, pure AI research will be funded only by institutions that can tolerate an extremely long path to useful products, or that have absolutely immense budgets.
Stability is meaningless if you can't read back the data 20 years later. I wouldn't bet on 12cm spinning optical discs of any kind being around in 20 years, nor would I bet on SDHC, SATA, firewire, USB, or even ethernet, though the last two seem most likely to me.
If we assume that storage density keeps increasing exponentially, and that you'll continue to have data to back up, it might actually make more sense to use something that's cheap and convenient now, that you can count on still being around in 5 years, and 5 years later you move it to the next big thing, along with all your new data. This way you'll never find yourself staring at a cable trying to remember what it plugged into 20 years ago, and wondering where you're going to find something that can read your media.
If I had to throw something in a time capsule, and I had less than $1000 to spend, I would use USB keys, because they're dirt cheap (you can afford more redundancy), they use an interface that's designed for backwards and forwards compatibility, and flash is pretty safe against spontaneous data degradation. If I had lots of money, I'd get two identical, mirrored NAS boxes, and plan on finding a transceiver to connect gigabit ethernet to whatever we're using in the future. Unlike system interconnects, such as USB, Firewire, SATA, etc., ethernet doesn't require either side of the connection to make any assumptions about the physical properties of the remote host, so bridging is much easier.
Are you kidding? When's the last time you saw any Itanium box?
In a locked data center with redundant 3-phase power taps and massive air conditioners, behind a 2-layer firewall. Definitely not attached to a WinXP box with a port open to the internet.
Spamming is rather profitable when it can convince the customer that the risk/reward ratio is very low, and when you're selling products that are either discretionary or interchangeable. If you're selling mainstream porn, it can be a rather suitable marketing vehicle, but none of these conditions apply to Real Estate. Real Estate is always a high risk investment, so customers will scrutinize you very carefully, and spam isn't going to help there. Worse, since Real Estate is highly localized, many of the targets are already potential customers, so you could actually be hurting your reputation and driving away more customers than you bring in.
Real Estate is a high-contact industry, and the impression given by that first contact is absolutely critical. Spamming might bring you a couple customers this month, but it will lose you many more in years to come.
It looks like their app store model is still very centralized, not at all well suited to installing arbitrary software willy-nilly, as open source DIY-ers are prone to do.
Of course, if someone makes a good ssh client for it, I'll probably buy one anyway.
a) The motherboard in question runs 4 PCIe slots at 8x, giving a theoretical limit of 2GB/s for each slot (thus card). The very large transfers they're probably making can probably approach something like 90% of this, so we'll say each card would like 1.8GB/s.
Actually, that's PCIe 2.0. They should be getting double that bandwidth.
You're describing "GPGPU clustering", and although there has been some work on this concept, it's not very attractive because it's even more difficult to tailor your application to the hardware, and you almost always need Infiniband (at least), which is so expensive that you're rapidly approaching the realm of specialized hardware prices anyway.
A lot of graphics work is considered to be "embarrassingly parallel", such that gigabit ethernet is more than adequate as an interconnect. This is what movie studios use for their render farms. Given that they've managed to parallelize this to the array of stream processors on the GPUs, it sounds like they're at least approaching the "embarrassingly parallel" level. Whether or not they're so parallel they can use commodity ethernet as an interconnect... that's the question. From a programming perspective, running on a single system is certainly easier, but what if someone wanted to scale this up by a factor of 1000? Would this problem scale like that, or would they be limited to a smaller, less interesting set of problems?
I'm extremely curious to know where the performance bottleneck is in this system. Is it memory bandwidth? PCIe bandwidth? Raw GPU power? Depending on which it is, it may or may not be very easy to improve upon the price/performance ratio of this setup. Given that the work parallelizes very easily, if you could build two machines that are each 2/3 as powerful and each cost 1/2 as much, that's a huge win for other people trying to build similar systems.
This smells like a stunt. Lieberman was probably expecting them to refuse him entirely, and use that to incite outrage to further his agenda. It looks like Youtube saw through it, and took the responsible course of action by fairly applying their community standards. Now Lieberman will have to openly admit that he wants to limit free speech if he wants to push this further, because he can't claim that they're unfairly supporting one viewpoint by keeping the majority of the content which did not violate the standards.
As many other people have noted, the classical RISC vs. CISC debate is moot, since all modern processors have elements of both. The real fight in the mobile space now is between general-purpose low-power processors, which may consume more power when doing certain computationally expensive tasks, and processors with specialized acceleration units that optimize certain tasks, at the expense of performance and power efficiency for general-purpose work.
I suspect that in the near future, the more interesting fight will be between chips with media acceleration features, and separate offload chips that allow the device to handle media decode with a very low-power general-purpose chip that otherwise wouldn't be up to the task.
For languages where no free static analysis tools exist, you're probably right, but if you're using C, things like lint will find the simple stuff that doesn't require analyzing execution paths. Taking it to the next level requires entering halting problem territory, and using heuristics or configuration options to limit your search to things that are likely to be problems and avoid spewing garbage that doesn't matter.
Because they cannot solve the halting problem, there are many instances where they will see a questionable piece of code, and have to decide whether they should flag it and risk a false positive, or ignore it and risk a false negative. This is where the magic happens, at least in the high-end commercial code analysis tools. If it always errs on the side of false positives, the output will be ignored in all but the most thoroughly audited fields. If it always errs on the side of false negatives, it's worthless. A lot of work goes into analyzing which practices commonly cause problems in the real world, and fine tuning the problem detection code to look for those, while perhaps passing up certain classes of bugs that are very rare and very computationally difficult to identify.
According to accretion theory, there's no way Venus could have formed with its spin in the opposite direction of the solar system. The prevailing theory is that a protoplanet smashed into it and radically changed its spin, possibly multiple times. Same goes for Uranus, which spins sideways, rather than backwards.
It's entirely possible that this pulsar formed in the usual way, but some interaction with a very massive object pulled it out of its pristine circular orbit. Given how these orbits stabilize themselves, it may have happened fairly recently, so there could still be some evidence nearby in the sky.
I work for a Linux vendor (though I speak only for myself), so take this with a grain of salt...
Personally, I think the staggering of releases between RHEL, SLES, and Ubuntu LTS is *good* for the community, and ultimately the customers as well. If all the enterprise distros synchronized, we'd see a much more pronounced oscillation between adding new features and improving existing code. Currently, someone somewhere is always preparing for a stable release, while someone else has just pushed one out and is addressing the issues that only crop up when customers deploy widely in production, and someone else is in the middle of their life cycle and working on major features they plan to support in their next version. This ensures a constant hum of work on all fronts that keeps community specialists busy in their various areas of expertise, and ensures that hardware and application vendors always have an incentive to post their work as soon as it's ready.
Can you imagine what would happen to the quality of upstream code if developers knew that nobody was going to run it through a heavy QA matrix for the next two years? I shudder to think. Worse, this would draw a much larger distinction between community and enterprise distributions, which might be good for some of the existing enterprise players until new competition comes along and bucks the trend, but would certainly harm innovation, even in the short run. Volunteers may contribute a minority of the lines of code that ship, but their constant involvement in the development process ensures that the enterprise developers don't get too far off track. New software technology always spends time maturing in the enthusiast realm before it gets adopted by the enterprise.
If this proposal is accepted by all of the enterprise vendors, it will lead to forks. Unlike some forks which increase the diversity of research and development, these forks will actually reduce it, because they will draw the majority of the labor away from the innovation and into glorified support.
Linux used to have a stable/unstable release model. It worked for a while, but ultimately it interfered with getting new technology into the hands of the users. We now have the economies of scale that allow us to have frequent stable community releases, with both quality and feature work at every step. We would be fools to give this up.
Think of your education like a computer. You can buy computers, even somewhat customized ones, from OEMs, with everything integrated at the factory. The components have been tested to work with each other fairly well, and as long as you're comfortable with their options, things will generally work well, or be supported if they don't. The tradeoff is that you won't have all the options you might otherwise have, unless you add in extra components which aren't supported, in which case you might have been better off just putting one together yourself.
Think of the liberal arts program as a barebones system, that you need to complete on your own with more applied experience, like an internship. In the long term, the theory they teach there is much more important than tools like programming languages, since those skills are mostly picked up on the job, and often not carried from one job to the next. On the other hand, the big engineering program probably has much better connections to industry and will get your career up and running more easily, just as an OEM computer works as soon as you turn it on.
If you choose the liberal arts program, you will need to augment it somehow with practical experience, or go to grad school at a big engineering program and get it there. If you want to take a DIY approach to your career, go to the liberal arts school and seek out internships to get experience. If you just want to focus on the tech, go to the big school which probably has a better equipped career center for the skills you'll be developing.
Slashdot Mirror
I'll put it this way, the last time I saw an evaluation of Linux I/O schedulers on a mainframe, the numbers were met with "That's not possible." from people who were used to having 4 dual-port Fibre Channel HBAs in a high-end Xeon/Opteron box.
Actually, a modern mainframe CPU has about the MIPS of a PII. Their strength is in reliability and I/O capacity. They use (very expensive) accelerators for CPU-intensive tasks. If you want to run Vista on one of these things, you'd need to spend a quarter million dollars on a video card.
Of course, that video card would be able to render 64 desktops simultaneously, and if it started to overheat, it would email the vendor, who would send you a replacement overnight, and you could replace it without downtime.
...to a lawyer. This scenario has LIABILITY written all over it.
Once you get that taken care of, look into Kensington-compatible locks.
I'm willing to accept that the BIOS was mere incompetence, but the customer service is actively malicious. This is totally unprofessional, and the people responsible should be fired.
If you want to avoid overloading the utilities, you need to charge at night. There are two challenges with this:
1) You need the capacity to run all day.
2) You need to encourage consumers to charge at night. Currently only wholesale customers pay different rates depending on the hour. Expanding this to residential customers would require a substantial overhaul of distribution networks. Fortunately, everyone agrees we need an overhaul anyway. Unfortunately, this would make that overhaul more expensive and delay it further.
Yum distro:
yum install screen
man screen
Apt distro:
apt-get install screen
man screen
There are still people doing pure research to make machines do something resembling human thought, but this just isn't a very interesting problem to industry for the simple reason that we already have humans that can do that, and we understand how to manage them and tap their intellect quite well. The real money is in doing things that humans can't do at all. Historically this has been done in heavy beige boxes, but with laptops, smart phones, and embedded devices becoming more ubiquitous, there's a lot of low-hanging fruit where a small amount of engineering effort can greatly improve economic efficiency and quality of life, and as long as this is true, pure AI research will be funded only by institutions that can tolerate an extremely long path to useful products, or that have absolutely immense budgets.
Stability is meaningless if you can't read back the data 20 years later. I wouldn't bet on 12cm spinning optical discs of any kind being around in 20 years, nor would I bet on SDHC, SATA, firewire, USB, or even ethernet, though the last two seem most likely to me.
If we assume that storage density keeps increasing exponentially, and that you'll continue to have data to back up, it might actually make more sense to use something that's cheap and convenient now, that you can count on still being around in 5 years, and 5 years later you move it to the next big thing, along with all your new data. This way you'll never find yourself staring at a cable trying to remember what it plugged into 20 years ago, and wondering where you're going to find something that can read your media.
If I had to throw something in a time capsule, and I had less than $1000 to spend, I would use USB keys, because they're dirt cheap (you can afford more redundancy), they use an interface that's designed for backwards and forwards compatibility, and flash is pretty safe against spontaneous data degradation. If I had lots of money, I'd get two identical, mirrored NAS boxes, and plan on finding a transceiver to connect gigabit ethernet to whatever we're using in the future. Unlike system interconnects, such as USB, Firewire, SATA, etc., ethernet doesn't require either side of the connection to make any assumptions about the physical properties of the remote host, so bridging is much easier.
In a locked data center with redundant 3-phase power taps and massive air conditioners, behind a 2-layer firewall. Definitely not attached to a WinXP box with a port open to the internet.
If you let the whole world control your heating elements, bad things happen. When was the last time you saw an Itanium box with a public IP?
Spamming is rather profitable when it can convince the customer that the risk/reward ratio is very low, and when you're selling products that are either discretionary or interchangeable. If you're selling mainstream porn, it can be a rather suitable marketing vehicle, but none of these conditions apply to Real Estate. Real Estate is always a high risk investment, so customers will scrutinize you very carefully, and spam isn't going to help there. Worse, since Real Estate is highly localized, many of the targets are already potential customers, so you could actually be hurting your reputation and driving away more customers than you bring in.
Real Estate is a high-contact industry, and the impression given by that first contact is absolutely critical. Spamming might bring you a couple customers this month, but it will lose you many more in years to come.
It looks like their app store model is still very centralized, not at all well suited to installing arbitrary software willy-nilly, as open source DIY-ers are prone to do.
Of course, if someone makes a good ssh client for it, I'll probably buy one anyway.
Actually, that's PCIe 2.0. They should be getting double that bandwidth.
A lot of graphics work is considered to be "embarrassingly parallel", such that gigabit ethernet is more than adequate as an interconnect. This is what movie studios use for their render farms. Given that they've managed to parallelize this to the array of stream processors on the GPUs, it sounds like they're at least approaching the "embarrassingly parallel" level. Whether or not they're so parallel they can use commodity ethernet as an interconnect... that's the question. From a programming perspective, running on a single system is certainly easier, but what if someone wanted to scale this up by a factor of 1000? Would this problem scale like that, or would they be limited to a smaller, less interesting set of problems?
I'm extremely curious to know where the performance bottleneck is in this system. Is it memory bandwidth? PCIe bandwidth? Raw GPU power? Depending on which it is, it may or may not be very easy to improve upon the price/performance ratio of this setup. Given that the work parallelizes very easily, if you could build two machines that are each 2/3 as powerful and each cost 1/2 as much, that's a huge win for other people trying to build similar systems.
Someone script something that will make slashcode context switch really quickly. Gotta make sure that TLB bug is nailed.
This smells like a stunt. Lieberman was probably expecting them to refuse him entirely, and use that to incite outrage to further his agenda. It looks like Youtube saw through it, and took the responsible course of action by fairly applying their community standards. Now Lieberman will have to openly admit that he wants to limit free speech if he wants to push this further, because he can't claim that they're unfairly supporting one viewpoint by keeping the majority of the content which did not violate the standards.
As many other people have noted, the classical RISC vs. CISC debate is moot, since all modern processors have elements of both. The real fight in the mobile space now is between general-purpose low-power processors, which may consume more power when doing certain computationally expensive tasks, and processors with specialized acceleration units that optimize certain tasks, at the expense of performance and power efficiency for general-purpose work.
I suspect that in the near future, the more interesting fight will be between chips with media acceleration features, and separate offload chips that allow the device to handle media decode with a very low-power general-purpose chip that otherwise wouldn't be up to the task.
For languages where no free static analysis tools exist, you're probably right, but if you're using C, things like lint will find the simple stuff that doesn't require analyzing execution paths. Taking it to the next level requires entering halting problem territory, and using heuristics or configuration options to limit your search to things that are likely to be problems and avoid spewing garbage that doesn't matter.
Because they cannot solve the halting problem, there are many instances where they will see a questionable piece of code, and have to decide whether they should flag it and risk a false positive, or ignore it and risk a false negative. This is where the magic happens, at least in the high-end commercial code analysis tools. If it always errs on the side of false positives, the output will be ignored in all but the most thoroughly audited fields. If it always errs on the side of false negatives, it's worthless. A lot of work goes into analyzing which practices commonly cause problems in the real world, and fine tuning the problem detection code to look for those, while perhaps passing up certain classes of bugs that are very rare and very computationally difficult to identify.
Seriously, touch-screen CRTs were an extraordinary pain in the ass. Aside from the gee-whiz factor, they were useless as input devices.
According to accretion theory, there's no way Venus could have formed with its spin in the opposite direction of the solar system. The prevailing theory is that a protoplanet smashed into it and radically changed its spin, possibly multiple times. Same goes for Uranus, which spins sideways, rather than backwards.
It's entirely possible that this pulsar formed in the usual way, but some interaction with a very massive object pulled it out of its pristine circular orbit. Given how these orbits stabilize themselves, it may have happened fairly recently, so there could still be some evidence nearby in the sky.
Old laptops make great thin clients. This is rarely interesting in the home, but there are plenty of places they can be put to good use.
I work for a Linux vendor (though I speak only for myself), so take this with a grain of salt...
Personally, I think the staggering of releases between RHEL, SLES, and Ubuntu LTS is *good* for the community, and ultimately the customers as well. If all the enterprise distros synchronized, we'd see a much more pronounced oscillation between adding new features and improving existing code. Currently, someone somewhere is always preparing for a stable release, while someone else has just pushed one out and is addressing the issues that only crop up when customers deploy widely in production, and someone else is in the middle of their life cycle and working on major features they plan to support in their next version. This ensures a constant hum of work on all fronts that keeps community specialists busy in their various areas of expertise, and ensures that hardware and application vendors always have an incentive to post their work as soon as it's ready.
Can you imagine what would happen to the quality of upstream code if developers knew that nobody was going to run it through a heavy QA matrix for the next two years? I shudder to think. Worse, this would draw a much larger distinction between community and enterprise distributions, which might be good for some of the existing enterprise players until new competition comes along and bucks the trend, but would certainly harm innovation, even in the short run. Volunteers may contribute a minority of the lines of code that ship, but their constant involvement in the development process ensures that the enterprise developers don't get too far off track. New software technology always spends time maturing in the enthusiast realm before it gets adopted by the enterprise.
If this proposal is accepted by all of the enterprise vendors, it will lead to forks. Unlike some forks which increase the diversity of research and development, these forks will actually reduce it, because they will draw the majority of the labor away from the innovation and into glorified support.
Linux used to have a stable/unstable release model. It worked for a while, but ultimately it interfered with getting new technology into the hands of the users. We now have the economies of scale that allow us to have frequent stable community releases, with both quality and feature work at every step. We would be fools to give this up.
[ ] Launchpad
[ ] Dead End
[X] Rest Stop
In so many ways...
Think of your education like a computer. You can buy computers, even somewhat customized ones, from OEMs, with everything integrated at the factory. The components have been tested to work with each other fairly well, and as long as you're comfortable with their options, things will generally work well, or be supported if they don't. The tradeoff is that you won't have all the options you might otherwise have, unless you add in extra components which aren't supported, in which case you might have been better off just putting one together yourself.
Think of the liberal arts program as a barebones system, that you need to complete on your own with more applied experience, like an internship. In the long term, the theory they teach there is much more important than tools like programming languages, since those skills are mostly picked up on the job, and often not carried from one job to the next. On the other hand, the big engineering program probably has much better connections to industry and will get your career up and running more easily, just as an OEM computer works as soon as you turn it on.
If you choose the liberal arts program, you will need to augment it somehow with practical experience, or go to grad school at a big engineering program and get it there. If you want to take a DIY approach to your career, go to the liberal arts school and seek out internships to get experience. If you just want to focus on the tech, go to the big school which probably has a better equipped career center for the skills you'll be developing.