Just as intellectual as the rest of the farce known as politics. The only difference is that the professionals wear fancy suits and genuinely think they are saying something insightful.
Well, on the positive side at least with the modern gee-whiz electronically controlled engines flooding isn't really a problem anymore. But yeah, I'll have to agree it takes a certain engineering genius to design such an engine mounting.
On a related note, changing headlights on my Toyota is an hour long affair with lots of swearing and sore fingers. Toyota, hear me, would it be possible to design the engine compartment so you don't have to be a frickin' contortionist to perform such a common and trivial operation?
Personally, I think making cars difficult to work with is a conscious choice by the automakers to generate business for their own workshops. If someone complains, they just answer that 'Today, people don't want to work on their cars anymore'. Yeah, fuck you too.
So essentially you're saying Americans are idiots?
With the exception of the USA and a couple of developing countries, the rest of the world somehow managed to convert from whatever pre-metric system they used to metric.
You can actually build a workable vehicle from carbon fiber and ceramics nowdays without using any metal at all. The biggest problem is how to you repair such a vehicle when it's damaged? Is it even possible?
Yeah, sure it's possible. Same way as repairing glass fiber structures.
What about recycling the materials?
Crush it and use as filler material, I suppose. Extra brownie points for printing a glossy brochure bragging about your recycled carbon reinforced cement.
I live in an area with close to the sea, with snow in the winter, salted roads etc. I don't know about American cars, but at least European and Japanese ones nowadays all have zincked underbodies and beams. Even in this environment, they last almost forever. E.g. my fathers car at the moment has done about 250000 km during almost 10 years, and close to no rust.
Before the zincked cars were common, the trick was to regularly spray a mix of tectyl (a sort of rubberized anti-rust compound) and diesel oil on the underbody. The car smelt like an old tractor, but it wouldn't rust.:)
BTW, a very ill-advised design choice of Python: http://www.python.org/dev/peps/pep-0211/ [python.org] Ask any numerical analyst to know why it is a terrible idea to solve a linear system with inv(A)*b. But make sure you have at least half an hour free.
AFAIK PEP 211 and the related PEP 209 were never actually accepted into the language. Python users that want multidimensional arrays use the numpy package, along with the scipy package that builds on top of numpy.
For solving a linear system Ax=b, you just use
x = numpy.linalg.solve(A, b)
which calls LAPACK behind the scenes. For a simple matrix multiplication (or M-V or V-V depending on the dimensionality of the arrays) A*B=C you do
If anyone says Emacs or Vi they are insane and have never done 10k lines of code in a modern environment.
I use emacs to work on a roughly 2m LOC project written mostly in C (although the parts where I mostly play around is only a few hundred kLOC).
A couple of years ago I tried to use eclipse with the CDT plugin. It chugged for about half an hour trying to index the source files, then crashed.
I went back to emacs. exuberant ctags and ECB allow me to jump around the code just like an IDE, so I'm not missing that much in the end.
I said highest margin products, meaning not software or services. The SPARC line of servers is higher margin than their x86 line.
It better have damn good margins. Intel, and to a lesser extent AMD, can amortize their R&D and fab costs over a zillion units. Meanwhile, last quarter Sun sold 60000 servers, 28000 of which were x64, leaving only 32000 SPARC systems. Again, of the SPARC systems $500m revenue was for the Sun-Fujitsu SPARC enterprise products using Fujitsu SPARC64 chips, and $300m revenue for their own Niagara systems. So yeah, with those revenues they better have damn good margins if they are going to spend more than a pittance on R&D.
It wouldn't surprise me if they sell the rest of the SPARC chip business to Fujitsu pretty soon, provided Fujitsu wants it. That doesn't of course mean they would be killing SPARC, just that they'd be expanding the current Sun-Fujitsu deal to cover all SPARC chips.
As for Ellison's comments, his job at the moment is obviously to convince Sun shareholders to approve the deal, some of which might well have some sentimental attachment to the SPARC business. I wouldn't trust what he says wrt Sun for one second, at least until the deal is through.
As for services, with hardware increasingly commoditized, that's the obvious way to go. It's no surprise that the remaining survivors of the unix wars, IBM & HP, are both heavily into services.
Algae might be a better biofuel compared to the alternatives in many ways on paper at least, but it's far from actually proven to work economically. E.g. the principal investigator of the $100 million NREL aquatic species research program has the following to say: http://www.theoildrum.com/node/2541
Sure, I agree. My point was that by taking x86 as the strategic platform rather than SPARC they could have taken advantage of the economies of scale of x86, and thanks to the DOS compatibility they even had a window of opportunity to take on Microsoft on the desktop before MS got their act together with NT.
Of course, ultimately the x86 commodification of the workstation, low-end, and mid-range server markets would have forced them to reduce HW prices in order to compete with the vacuum cleaner salespeople (Compaq, Dell & their ilk). In such a scenario I suppose they could have kept their edge in the higher end x86 server market, say, by designing SMP chipsets and so forth. And also by focusing on software & services; I believe had they chosen x86 back then in the late 80's they would not only easily have won the "Unix wars", but the unix slice of the pie would be much bigger than it is now.
As for the rest of your comment, I didn't realize the killing of the x86 line was so political, and by the sound of it, painful. Thanks for sharing that piece of insight.
Sun basically killed themselves by canceling the Sparc line. They never ramped the clocks on cores, and the multi-threaded model that they designed towards was a fringe case at best.
Another way of seeing it, their volume*margin for SPARC was so low that they couldn't afford to keep up in the single-thread performance race with Intel, AMD and IBM. Short of completely getting rid of SPARC, cookie-cutter copying many simple and slow cores on a die was a cheap choice their budget did allow. And it does well in some workloads.
I expect Oracle to sell the SPARC business to Fujitsu (who already designs and fabs the SPARC64 chips). I don't expect Oracle to completely abandon SPARC, at least not yet, but rather they will resell rebadged Fujitsu servers, just like Sun does today.
Ironically, a couple of decades ago they were sitting there with literally the keys to the realm in their hands, and they threw them away. Back in the late 80's they introduced the Sun386i workstation, featuring (drumroll..) Intel's 386 processor and a 386 port of SunOS. This was a proper preemptive multitasking OS with 32-bit virtual memory and a decent GUI, far ahead of Windows 2.x at the time. Not only that, it also had a functioning DOS emulator, allowing the machine to run MS-DOS programs. By focusing on x86, and selling SunOS/x86 for $50 or so they could have become the Microsoft of today.
But, they weren't interested in playing the massive volumes with razor thin margins game of the PC world, thinking that the unix workstation market was insulated from the PC market. After all, PC's were for chumps running 1-2-3 and Wordperfect. So they introduced their own hardware, SPARC, and discontinued SunOS/x86. Of course, as TFA says, they re-entered the x86 game in 2002, but by then it was too little, too late.
The failure to see the cost effectiveness afforded by the massive volumes of x86 chips Intel was turning out is all the more damning considering the main reason they had become the dominant unix workstation vendor wasn't that their hardware or software was leagues ahead of their competitors, but rather that they were cheaper.
Interesting. My Ubuntu 8.10 installation at home started its life as a debian installation sometime back in 1997. Since then it's just been dist-upgraded [*], and of course moved to new computers every now and then. I've never had any major problems with upgrading.
[*] Yes, for some of the early ubuntu releases it was possible to dist-upgrade from debian.
Yes, it is. Look, C and C++ weren't designed with parallelism in mind, but neither was Fortran. The only parallel dialect of Fortran that saw some use was HPF, and that was a failure (see below). Back in the days of yore when vector supercomputers and dinosaurs roamed the earth, Fortran had a big advantage over C. This was largely due to the semantics of C which didn't have restrict at the time, as well as the relative immaturity of C compilers at that point. But all that code that the legendary Cray vectorizing Fortran compiler compiled was just standard F77, which had no FORALL nor array expressions. Vectorization was done on normal DO loops. Just like a modern C or C++ compiler can vectorize for-loops, possibly with the aid of restrict (or __restrict, #pragma noalias or whatever the extension is called in your C++ compiler)
"If you're thinking of FORALL and the other stuff imported from HPF, well, there's a reason HPF died and parallel Fortran applications use MPI and/or OpenMP just like C/C++."
Yes, the reason is that FORALL and parallel matrix operations vectorized code, while OpenMP is for multicore code.
HPF is a failure in many respects. Fundamentally it died because on distributed memory machines it's performance was poor compared to MPI. The parts of HPF that were included into F95, most notably FORALL, are widely considered to be mistakes. As I mentioned in my previous point, the semantics of FORALL make analyzing it no simpler than analyzing the equivalent DO loop, and the performance penalty for failing is higher. Hence it's always better to just use a normal DO loop. In fact F2008 is adding a "DO CONCURRENT" loop so that the programmer can explicitly tell the compiler there are no loop-carried dependencies; this is a direct response to the difficulty of properly optimizing FORALL.
As for F90 array expressions, they have similar optimization issues as FORALL, so if one is really concerned with maximum performance it's safer to use DO loops. The real value of the array expressions is that they make the code simpler and shorter, not that they provide better performance than normal loops.
For the most part, it is. There are some other minor things, but restrict closes the majority of the performance gap between C and Fortran. Oh yes, and C99 has some truly retarded pedantery wrt. complex arithmetic, so you might need to use some compiler option to get around that.
Fortran has built in support for vectorization, parallelization, and efficient dynamic multi-dimensional arrays.
If you're thinking of FORALL and the other stuff imported from HPF, well, there's a reason HPF died and parallel Fortran applications use MPI and/or OpenMP just like C/C++. Unfortunately the semantics of FORALL and array expressions makes them not much simpler to analyze for dependencies than normal loops, and the penalty for failing is higher.
However, the arrays in F90+ are very nice to program with; compared to those, programming with arrays in C is like poking your eyes out with a fork. But that's mostly a convenience feature, as such it doesn't improve performance (as long as you don't do your multidimensional C arrays in the popular but suboptimal array-of-arrays style).
If you have an irrational hatred for Fortran, at least do yourself the favor of using C++ where you can encapsulate multidimensional arrays in a class with overloaded operators. There's a bunch of such high-performance implementations around, such as Eigen, blitz, boost::multiarray and so forth, so no need to reinvent the wheel.
Slashdot Mirror
ZFS has built in RAID support (which, I assume, works on the block level, instead of on the disk level), maybe Btrfs will get this too.
Yes, btrfs currently has built-in support for raid 0/1/10, 5 and 6 are under development.
The article predicts a couple of years until it's safe enough as default in new distros.
Me, I'm a predator by nature
Well I'm not just any predator - I'm a frickin' T-Rex! There. Beat that! [*]
[*] Note: Ownership of a wolf moon t-shirt is considered cheating
Just as intellectual as the rest of the farce known as politics. The only difference is that the professionals wear fancy suits and genuinely think they are saying something insightful.
Well, on the positive side at least with the modern gee-whiz electronically controlled engines flooding isn't really a problem anymore. But yeah, I'll have to agree it takes a certain engineering genius to design such an engine mounting.
On a related note, changing headlights on my Toyota is an hour long affair with lots of swearing and sore fingers. Toyota, hear me, would it be possible to design the engine compartment so you don't have to be a frickin' contortionist to perform such a common and trivial operation?
Personally, I think making cars difficult to work with is a conscious choice by the automakers to generate business for their own workshops. If someone complains, they just answer that 'Today, people don't want to work on their cars anymore'. Yeah, fuck you too.
So essentially you're saying Americans are idiots?
With the exception of the USA and a couple of developing countries, the rest of the world somehow managed to convert from whatever pre-metric system they used to metric.
Didn't gcc 4.0 strip out all the processor-specific optimizations?
No.
You can actually build a workable vehicle from carbon fiber and ceramics nowdays without using any metal at all. The biggest problem is how to you repair such a vehicle when it's damaged? Is it even possible?
Yeah, sure it's possible. Same way as repairing glass fiber structures.
What about recycling the materials?
Crush it and use as filler material, I suppose. Extra brownie points for printing a glossy brochure bragging about your recycled carbon reinforced cement.
I live in an area with close to the sea, with snow in the winter, salted roads etc. I don't know about American cars, but at least European and Japanese ones nowadays all have zincked underbodies and beams. Even in this environment, they last almost forever. E.g. my fathers car at the moment has done about 250000 km during almost 10 years, and close to no rust.
Before the zincked cars were common, the trick was to regularly spray a mix of tectyl (a sort of rubberized anti-rust compound) and diesel oil on the underbody. The car smelt like an old tractor, but it wouldn't rust. :)
BTW, a very ill-advised design choice of Python: http://www.python.org/dev/peps/pep-0211/ [python.org] Ask any numerical analyst to know why it is a terrible idea to solve a linear system with inv(A)*b. But make sure you have at least half an hour free.
AFAIK PEP 211 and the related PEP 209 were never actually accepted into the language. Python users that want multidimensional arrays use the numpy package, along with the scipy package that builds on top of numpy.
For solving a linear system Ax=b, you just use
x = numpy.linalg.solve(A, b)
which calls LAPACK behind the scenes. For a simple matrix multiplication (or M-V or V-V depending on the dimensionality of the arrays) A*B=C you do
C = numpy.dot(A, B)
which is implemented with a call to BLAS.
Looks like these vagina pictures you find in the gents rooms worldwide.
Yes, I realize it's supposed to be a brain, but just saying, just saying..
Allow plugins, and somebody is bound to do it, plunging the FOSS world into a deep and evil darkness.
If anyone says Emacs or Vi they are insane and have never done 10k lines of code in a modern environment.
I use emacs to work on a roughly 2m LOC project written mostly in C (although the parts where I mostly play around is only a few hundred kLOC).
A couple of years ago I tried to use eclipse with the CDT plugin. It chugged for about half an hour trying to index the source files, then crashed.
I went back to emacs. exuberant ctags and ECB allow me to jump around the code just like an IDE, so I'm not missing that much in the end.
Really?
Putting my sysadmin cap on, the first thing that comes to mind when seeing a Slackware, or for that matter Gentoo, box is "Oh God no, a tweaker".
I said highest margin products, meaning not software or services. The SPARC line of servers is higher margin than their x86 line.
It better have damn good margins. Intel, and to a lesser extent AMD, can amortize their R&D and fab costs over a zillion units. Meanwhile, last quarter Sun sold 60000 servers, 28000 of which were x64, leaving only 32000 SPARC systems. Again, of the SPARC systems $500m revenue was for the Sun-Fujitsu SPARC enterprise products using Fujitsu SPARC64 chips, and $300m revenue for their own Niagara systems. So yeah, with those revenues they better have damn good margins if they are going to spend more than a pittance on R&D.
It wouldn't surprise me if they sell the rest of the SPARC chip business to Fujitsu pretty soon, provided Fujitsu wants it. That doesn't of course mean they would be killing SPARC, just that they'd be expanding the current Sun-Fujitsu deal to cover all SPARC chips.
As for Ellison's comments, his job at the moment is obviously to convince Sun shareholders to approve the deal, some of which might well have some sentimental attachment to the SPARC business. I wouldn't trust what he says wrt Sun for one second, at least until the deal is through.
As for services, with hardware increasingly commoditized, that's the obvious way to go. It's no surprise that the remaining survivors of the unix wars, IBM & HP, are both heavily into services.
Algae might be a better biofuel compared to the alternatives in many ways on paper at least, but it's far from actually proven to work economically. E.g. the principal investigator of the $100 million NREL aquatic species research program has the following to say: http://www.theoildrum.com/node/2541
But the Sun386i was a workstation, not a PC.
Sure, I agree. My point was that by taking x86 as the strategic platform rather than SPARC they could have taken advantage of the economies of scale of x86, and thanks to the DOS compatibility they even had a window of opportunity to take on Microsoft on the desktop before MS got their act together with NT.
Of course, ultimately the x86 commodification of the workstation, low-end, and mid-range server markets would have forced them to reduce HW prices in order to compete with the vacuum cleaner salespeople (Compaq, Dell & their ilk). In such a scenario I suppose they could have kept their edge in the higher end x86 server market, say, by designing SMP chipsets and so forth. And also by focusing on software & services; I believe had they chosen x86 back then in the late 80's they would not only easily have won the "Unix wars", but the unix slice of the pie would be much bigger than it is now.
As for the rest of your comment, I didn't realize the killing of the x86 line was so political, and by the sound of it, painful. Thanks for sharing that piece of insight.
Sun basically killed themselves by canceling the Sparc line. They never ramped the clocks on cores, and the multi-threaded model that they designed towards was a fringe case at best.
Another way of seeing it, their volume*margin for SPARC was so low that they couldn't afford to keep up in the single-thread performance race with Intel, AMD and IBM. Short of completely getting rid of SPARC, cookie-cutter copying many simple and slow cores on a die was a cheap choice their budget did allow. And it does well in some workloads.
I expect Oracle to sell the SPARC business to Fujitsu (who already designs and fabs the SPARC64 chips). I don't expect Oracle to completely abandon SPARC, at least not yet, but rather they will resell rebadged Fujitsu servers, just like Sun does today.
Ironically, a couple of decades ago they were sitting there with literally the keys to the realm in their hands, and they threw them away. Back in the late 80's they introduced the Sun386i workstation, featuring (drumroll..) Intel's 386 processor and a 386 port of SunOS. This was a proper preemptive multitasking OS with 32-bit virtual memory and a decent GUI, far ahead of Windows 2.x at the time. Not only that, it also had a functioning DOS emulator, allowing the machine to run MS-DOS programs. By focusing on x86, and selling SunOS/x86 for $50 or so they could have become the Microsoft of today.
But, they weren't interested in playing the massive volumes with razor thin margins game of the PC world, thinking that the unix workstation market was insulated from the PC market. After all, PC's were for chumps running 1-2-3 and Wordperfect. So they introduced their own hardware, SPARC, and discontinued SunOS/x86. Of course, as TFA says, they re-entered the x86 game in 2002, but by then it was too little, too late.
The failure to see the cost effectiveness afforded by the massive volumes of x86 chips Intel was turning out is all the more damning considering the main reason they had become the dominant unix workstation vendor wasn't that their hardware or software was leagues ahead of their competitors, but rather that they were cheaper.
Well, sort of. libg2c is the runtime library for g77. It fulfills the equivalent function as libgfortran does for gfortran.
The bottom line is, if one compiles ones code with gfortran instead of g77, libg2c isn't necessary.
You're a moron or in love with token ring.
I don't think those two are exclusive of each other.
Something like the SGI Molecule, perhaps.
Oh yeah, RIP SGI.
Interesting. My Ubuntu 8.10 installation at home started its life as a debian installation sometime back in 1997. Since then it's just been dist-upgraded [*], and of course moved to new computers every now and then. I've never had any major problems with upgrading.
[*] Yes, for some of the early ubuntu releases it was possible to dist-upgrade from debian.
No, for the most part it isn't.
Yes, it is. Look, C and C++ weren't designed with parallelism in mind, but neither was Fortran. The only parallel dialect of Fortran that saw some use was HPF, and that was a failure (see below). Back in the days of yore when vector supercomputers and dinosaurs roamed the earth, Fortran had a big advantage over C. This was largely due to the semantics of C which didn't have restrict at the time, as well as the relative immaturity of C compilers at that point. But all that code that the legendary Cray vectorizing Fortran compiler compiled was just standard F77, which had no FORALL nor array expressions. Vectorization was done on normal DO loops. Just like a modern C or C++ compiler can vectorize for-loops, possibly with the aid of restrict (or __restrict, #pragma noalias or whatever the extension is called in your C++ compiler)
"If you're thinking of FORALL and the other stuff imported from HPF, well, there's a reason HPF died and parallel Fortran applications use MPI and/or OpenMP just like C/C++." Yes, the reason is that FORALL and parallel matrix operations vectorized code, while OpenMP is for multicore code.
HPF is a failure in many respects. Fundamentally it died because on distributed memory machines it's performance was poor compared to MPI. The parts of HPF that were included into F95, most notably FORALL, are widely considered to be mistakes. As I mentioned in my previous point, the semantics of FORALL make analyzing it no simpler than analyzing the equivalent DO loop, and the performance penalty for failing is higher. Hence it's always better to just use a normal DO loop. In fact F2008 is adding a "DO CONCURRENT" loop so that the programmer can explicitly tell the compiler there are no loop-carried dependencies; this is a direct response to the difficulty of properly optimizing FORALL.
As for F90 array expressions, they have similar optimization issues as FORALL, so if one is really concerned with maximum performance it's safer to use DO loops. The real value of the array expressions is that they make the code simpler and shorter, not that they provide better performance than normal loops.
Sorry, but "restrict" is not sufficient.
For the most part, it is. There are some other minor things, but restrict closes the majority of the performance gap between C and Fortran. Oh yes, and C99 has some truly retarded pedantery wrt. complex arithmetic, so you might need to use some compiler option to get around that.
Fortran has built in support for vectorization, parallelization, and efficient dynamic multi-dimensional arrays.
If you're thinking of FORALL and the other stuff imported from HPF, well, there's a reason HPF died and parallel Fortran applications use MPI and/or OpenMP just like C/C++. Unfortunately the semantics of FORALL and array expressions makes them not much simpler to analyze for dependencies than normal loops, and the penalty for failing is higher.
However, the arrays in F90+ are very nice to program with; compared to those, programming with arrays in C is like poking your eyes out with a fork. But that's mostly a convenience feature, as such it doesn't improve performance (as long as you don't do your multidimensional C arrays in the popular but suboptimal array-of-arrays style).
If you have an irrational hatred for Fortran, at least do yourself the favor of using C++ where you can encapsulate multidimensional arrays in a class with overloaded operators. There's a bunch of such high-performance implementations around, such as Eigen, blitz, boost::multiarray and so forth, so no need to reinvent the wheel.