And ethanol isn't the only biofuel. Biodiesel generally has better numbers, and methanol (which you rarely hear about anymore) has a lot going for it too.
Well, I'll bite; if the cell is the fastest processor for your workload, the PS3 is the cheapest way to get one, even at only six usable SPEs and no GPU. Doesn't the PS3 have GigE? That's plenty fast enough to shovel data in and out of the system.
What workload is actually faster on a Cell than on a modern quad-core CPU or video card? I mean - it's possible that such a workload exists, but the niche between a general purpose CPU and the hundreds of FPUs in a video card has got to be pretty damn small.
Nothing. The world just changes more slowly than people expect. The technology we use now has replaced some uses of paper - mostly in places where it's non obvious. When was the last time you signed for a package on paper? Sent a paper office memo?
It'll be a long time before we can replace things like paper packing slips. Consider replacing them with RFID - every recipient would need a reader for that to work.
I'd prefer that then having a car weigh twice as much as it needs to just because the US car manufacturers have lobbied for backup redundant secondary top-impact airbags in order create a barrier to entry in the US market for competitors.
"So, Developer Danny, I notice that 8 out of your last 10 commits have had someone else's name on them. Can you explain to us what value you bring to SUN, and why we shouldn't just hire or reward the 3rd party contributors directly?"
Which of the six developers who's work I committed do you propose to hire? If they're busy vetting other people's code, when will they have time to keep writing this great stuff?
The point is that signing away copyright and/or not owning it because it was a "work for hire" is the norm in most industries that involve the production of copyrightable works. Therefore, copyright extensions almost never help artists / writers / developers.
There's got to be some Australian government policy making things that way then, because normally this sort of thing gets solve automatically by the market. Think of all the money *you* could make going to Taiwan or Hong Kong, buying netbooks for 250 AUD, shipping them bulk to Australia (probably less than $1/piece) and selling them for $300 AUD...
Things outide the US are generally more expensive, not including shipping/customs costs and currency differences.
For millions of units of something made in Taiwan, it shouldn't be terribly difficult to get a reasonable price on it in Australia. At that volume, you can rent your own ship. If you're the Australian government, you shouldn't be paying customs. Etc.
That's fine for hardware companies like Cisco and Nokia who mainly derive value from their hardware but I'm sure it'd kill a proprietary software company.
Would it? How about compared to a similar scenario where they based their product on unlicensed proprietary software?
With the unlicensed GPL software they have one more option, so they're strictly less screwed than if it were unlicensed proprietary software.
You think mandating a class where students become familiar with a very common tool they'd use when applying their skills, doesn't make sense?
What percentage of CS graduates will use the current version of Visual Studio, and use it as significantly more than a glorified text editor? How about Eclipse? NetBeans? A GNU toolchain? Xcode? Won't become programmers at all (Sysadmin perhaps)? Write PHP/Javascript in Notepad++?
Sure, it's worth exposing CS students to at least one of those things. But saying it specifically must be Visual Studio (or any one of the others) is foolish.
At this point in time, I'd expect every graduate who wants to be marketable to have some familiarity with C++, POSIX, Win32 and.NET, Java, Cocoa and Objective C, and SQL. Specialization for the young is foolish, like an evolutionary dead end. It limits your options and constrains your thinking.
And wasting valuable University time teaching any of those things is unnecessary specialization. Here's a list of requirements for the school I just graduated from: UMass Lowell CS Reqs. What would you drop to add a mandatory class in Cocoa / Objective C?
The gen-eds? The science requirement? Then you get a computer specialist who basically didn't get a university education.
The math? Then you get a junior technician who can basically never do anything interesting. There are two year "programming" programs at trade schools that give you this. If this is what you want, hire it - no need to try to screw up University CS programs.
The electives? I would have been pretty pissed off if someone told me I couldn't take my class in programming language design or network security because I needed to take a mandatory course in.NET instead.
have never seen a Windows development environment.
University isn't vocational training, and it certainly isn't vocational training for the specific tool set that you happen to use. If you mean that it would be reasonable to offer a Windows programming elective, great. But mandating a class in operating Visual Studio makes about as much sense as mandating a course in Ruby on Rails or the iPhone SDK.
Sure, there will likely be advances. But the run up to 2003 or so where every new processor was drastically faster than the previous processor has stopped. And Moore's law hasn't. And the chip makers keep making chips, with more transistors, and with no known way to speed up single-core chips by adding transistors we get multi-core chips.
You're insane. Most real-world problems are sequential. Take a payroll calculation for example. First you have the gross pay, then you take out taxes, then you take out contributions, then you take out deferred comp, and whatever's left goes on the pay stub.
First, I'm not sure that I would use accounting procedures as my example of a "real world" problem, but whatever.
There are two more direct reasons why payroll computations aren't the sequential problem you're looking for. First, they're not CPU bound. No-one's saying that it would be so much easier to do a payroll calculations if their CPU were just twice as fast. Second, most companies doing payroll calculations have more than one employee. Sure, the procedure you described is serial - but there's no reason you can't do it for every employee simultaneously in parallel and still get correct answers.
A similar thing is true for many other problems: One instance is serial and computationally trivial, in order to be computationally expensive you must have many instances, in which case your whole problem is naturally very parallel.
Actually, hasn't work been done in the past few years on producing smaller, more efficient transistors? That would allow the same basic designs to scale further up in processing speed. Sure, it won't make Moore's Law's Corollary for software work forever, but it could provide speedups without having to go multithreaded and run into Amdahl's Law.
That's Moore's law in action. The problem is that, for a couple years now, smaller transistors has meant many more transistors but only slightly faster transistors. We've been on 3ghz for like 5 years. And the best thing to do with more transistors at the same speed - once you have all the cache you want (and we do) - is to add more processor cores.
Obama "can't" send emails due to the presidential records act. More specifically, he can send all the emails he wants, but any email the president sends is a matter of public record.
Most real-world problems are boring, single-threaded, input-process-output problems.
This simply isn't true. Many real-world *programs* are implemented that way, but that's a side effect of the hardware platform rather than something required by the problem statement.
But even if you were right, you'd still be asking the wrong question. Only problems best solved by CPU-bound programs really matter here. Among those, it's difficult to come up with examples that don't admit to parallel implementations (hence compiling C programs) and even harder to come up with examples that don't give you parallelism anyway in practice (as C compilers do).
Which really means that companies like FedEx and Walmart should be buying into gasoline alternatives just to insure stable fuel prices for themselves.
And ethanol isn't the only biofuel. Biodiesel generally has better numbers, and methanol (which you rarely hear about anymore) has a lot going for it too.
What workload is actually faster on a Cell than on a modern quad-core CPU or video card? I mean - it's possible that such a workload exists, but the niche between a general purpose CPU and the hundreds of FPUs in a video card has got to be pretty damn small.
Nothing. The world just changes more slowly than people expect. The technology we use now has replaced some uses of paper - mostly in places where it's non obvious. When was the last time you signed for a package on paper? Sent a paper office memo?
It'll be a long time before we can replace things like paper packing slips. Consider replacing them with RFID - every recipient would need a reader for that to work.
It's both.
It's a plug-in hybrid, so it runs on straight electricity until you exceed it's base range, then it can self-recharge with gasoline for longer trips.
That's a bit expensive for a local-roads-only vehicle. I can think of only a few applications where I'd prefer that to something like this: http://soundspeedscooters.com/store/vehicles/evt-4000e-electric-vespa-lead-acid.html
I'd prefer that then having a car weigh twice as much as it needs to just because the US car manufacturers have lobbied for backup redundant secondary top-impact airbags in order create a barrier to entry in the US market for competitors.
Which of the six developers who's work I committed do you propose to hire? If they're busy vetting other people's code, when will they have time to keep writing this great stuff?
Huh?
You certainly can't apply additional license terms when you redistribute GPLed code.
You're completely missing the point.
The point is that signing away copyright and/or not owning it because it was a "work for hire" is the norm in most industries that involve the production of copyrightable works. Therefore, copyright extensions almost never help artists / writers / developers.
There's got to be some Australian government policy making things that way then, because normally this sort of thing gets solve automatically by the market. Think of all the money *you* could make going to Taiwan or Hong Kong, buying netbooks for 250 AUD, shipping them bulk to Australia (probably less than $1/piece) and selling them for $300 AUD...
For millions of units of something made in Taiwan, it shouldn't be terribly difficult to get a reasonable price on it in Australia. At that volume, you can rent your own ship. If you're the Australian government, you shouldn't be paying customs. Etc.
Would it? How about compared to a similar scenario where they based their product on unlicensed proprietary software?
With the unlicensed GPL software they have one more option, so they're strictly less screwed than if it were unlicensed proprietary software.
I think you missed the right reply button. That response would make more sense elsewhere in the tree.
What percentage of CS graduates will use the current version of Visual Studio, and use it as significantly more than a glorified text editor? How about Eclipse? NetBeans? A GNU toolchain? Xcode? Won't become programmers at all (Sysadmin perhaps)? Write PHP/Javascript in Notepad++?
Sure, it's worth exposing CS students to at least one of those things. But saying it specifically must be Visual Studio (or any one of the others) is foolish.
And wasting valuable University time teaching any of those things is unnecessary specialization. Here's a list of requirements for the school I just graduated from: UMass Lowell CS Reqs. What would you drop to add a mandatory class in Cocoa / Objective C?
The gen-eds? The science requirement? Then you get a computer specialist who basically didn't get a university education.
The math? Then you get a junior technician who can basically never do anything interesting. There are two year "programming" programs at trade schools that give you this. If this is what you want, hire it - no need to try to screw up University CS programs.
The electives? I would have been pretty pissed off if someone told me I couldn't take my class in programming language design or network security because I needed to take a mandatory course in .NET instead.
Most countries are functionally less free than the USA because they're poor and corrupt.
But there certainly are countries that are more free. I'd start with something like this list.
Don't some of the major CAD programs still primarly target *nix (= SuSE or RHED) workstations?
University isn't vocational training, and it certainly isn't vocational training for the specific tool set that you happen to use. If you mean that it would be reasonable to offer a Windows programming elective, great. But mandating a class in operating Visual Studio makes about as much sense as mandating a course in Ruby on Rails or the iPhone SDK.
Sure, there will likely be advances. But the run up to 2003 or so where every new processor was drastically faster than the previous processor has stopped. And Moore's law hasn't. And the chip makers keep making chips, with more transistors, and with no known way to speed up single-core chips by adding transistors we get multi-core chips.
First, I'm not sure that I would use accounting procedures as my example of a "real world" problem, but whatever.
There are two more direct reasons why payroll computations aren't the sequential problem you're looking for. First, they're not CPU bound. No-one's saying that it would be so much easier to do a payroll calculations if their CPU were just twice as fast. Second, most companies doing payroll calculations have more than one employee. Sure, the procedure you described is serial - but there's no reason you can't do it for every employee simultaneously in parallel and still get correct answers.
A similar thing is true for many other problems: One instance is serial and computationally trivial, in order to be computationally expensive you must have many instances, in which case your whole problem is naturally very parallel.
That's Moore's law in action. The problem is that, for a couple years now, smaller transistors has meant many more transistors but only slightly faster transistors. We've been on 3ghz for like 5 years. And the best thing to do with more transistors at the same speed - once you have all the cache you want (and we do) - is to add more processor cores.
There are some languages that legitimately aren't going anywhere any time soon. This is especially true on *nix platforms.
C, C++, Common Lisp, Java, Perl5, Bash scripts. They were here 10 years ago, and they'll be here 10 years from now.
Obama "can't" send emails due to the presidential records act. More specifically, he can send all the emails he wants, but any email the president sends is a matter of public record.
This simply isn't true. Many real-world *programs* are implemented that way, but that's a side effect of the hardware platform rather than something required by the problem statement.
But even if you were right, you'd still be asking the wrong question. Only problems best solved by CPU-bound programs really matter here. Among those, it's difficult to come up with examples that don't admit to parallel implementations (hence compiling C programs) and even harder to come up with examples that don't give you parallelism anyway in practice (as C compilers do).