The next iteration of the enlightenment window manager will use openGL rendering. So I guess it would be possible to make gnome and kde doing it too. Maybe some day..
And windows has its graphic drivers in the kernel, I don't know if it's gpu accelerated though. I suspect not.
I guess they wanna charge you a few bucks extra for installing linux. As is said in the article, this is mainly aimed at big corporations who install their own stuff anyway, so they don't want to pay extra for a linux installation they probably won't use anyway. As to why use freedos instead of some 1-floppy linux distro, who knows? Maybe they don't wanna tarnish Linux reputation (which perhaps would hurt their server biz) as "that toy crappy thing which is included with every pc to circumwent MS contracts and everybody throws away anyway".
UTF-8 is somewhat ascii compatible, and an efficient coding for mostly ascii data. Looks like the unix world, ietf protocols etc. are moving in this direction. For more info check out UTF-8 and Unicode FAQ for Unix/Linux.
Re:moving Sourceforge to DB2?!?!
on
Linuxworld Fun
·
· Score: 2
Which you don't seem to know much about either, as you can't even spell it right..:) *hint* PostgreSQL *hint*
Well, postgresql is what sourceforge.net is currently running. I doubt they'll change either, I think this announcement was about sourceforge enterprise edition, which is the thingy va software tries to sell to companies.
In web development, it's all about the tools. The language doesn't really matter. Think about it. For web development, you need a language which can: 1) Connect to a database 2) Be good at string handling Why are strings important? Well, most stuff in web development is about strings. You interact with the DB via strings, you send the client a bunch of strings etc. Hell, even a god-awful language like Tcl can be really good for web development when you couple it with a kick-ass toolkit, like aolserver/openacs. Incidentally, aolserver/openacs and expect are the only reasons any mentally stable person agrees to learn Tcl.
Performance, on the other hand, is not that important. Most of the time you'll be waiting for the database or to push data to that guy behind a 14.4 modem anyway. What matters performance-wise is that you have some mechanism of keeping the script interpreter loaded all the time (like aolserver/mod_perl/php/java) and having persistent db connections.
So why use Java? It's not really good at handling strings, strong typing is often not necessary in web development and having to compile your code before you test it slows you down (yes, I know JPS:s are automagically compiled). As I said at the beginning of my rant, it's all about the tools. Java has _excellent_ tool support. XML stuff, web services, layered architectures (J2EE), you name it. Java has it. And all the major players in the industry are behind it, except Microsoft of course.
Java is also scalable. For the really simple site, writing a JSP page is as simple as writing a PHP/ASP page. For the high-end stuff, you can have 27 bazillion layers all cleanly separated on separate clusters costing umpteen million dollars.
I'll second that. Although R is primarily for statistics (which is not my cup of tea), I use it for plotting because the plotting stuff in R blows gnuplot (and hence octave) out of the water, IMHO. Another useful free plotting tool that is widely used is grace, it has a nice GUI if you happen to like such things.
2) Ok, maybe bashing is a too harsh word, but I'd hardly say his comparison is unbiased.
3) Yes but there are other things like hard links etc (like almost the entire unix tool chain). A quick search on google finds the author saying himself that arch is only for POSIX environments.
4) Even if it works when you use passive mode ftp, you still need shell access for ssh. Anyway, maybe this isn't such a big problem since there are patches for webdav support. Maybe they'll get integrated into the main tree soon.
Bottom line: both of these will easily blow cvs out of the water. Use whatever you like.
Hrm.. arch is cool in it's own right, no need to bash subversion. They have different goals.
The goal of subversion is to be as similar to cvs as possible, while correcting the big flaws in cvs. If you want, think of Subversion as CVS 2.0. While the backend is quite different, the command-line client is quite similar to cvs, it accepts many of the same options as cvs. Developers familiar with cvs should be almost immidiately productive with subversion. The subversion guys are even developing cvs2svn repository migration tools. Also, subversion has a client API, making writing GUI clients and the like much easier.
Arch, however, is different. Migrating from cvs to arch is not as painless as from cvs to subversion. That being said, arch supports distributed repositories, which subversion doesn't, and has oodles of fancy merge operations. Also, arch consists of about 40klines of mostly shell and awk scripts, which makes some people shudder. This also means that getting arch to run on a non-Unix platform is probably next to impossible, while subversion can run on any platform apache supports (Yes, the client and libs also use APR). Finally, arch currently uses ftp as transport protocol, making it problematic security-wise.
As it says right on the front page, Subversion uses WebDAV as its transport protocol. As webdav is based on HTTP 1.1 you get all the benefits of HTTP, like for example SSL encryption.
But not for long. According to GCC 3.3 ChangesVMS is obsoleted, which I think means they are going to remove it for the next release after that.
Of course, in GCC 3.1, which is the GCC branch used in Jaguar, VMS support is still there.:)
PS this message use UTF-8.
It will indeed be a good day when UTF-8 has replaced ISO-8859-* and various other encodings. Actually, I read that the Red Hat 8.0 beta is supposed to use UTF-8 as its default charset, so maybe it'll happen sooner than we think!
2) There's always the risk of name conflicts when linking another combination of software than the original. Of course your point is valid in the sense that "normal" identifiers can be put into namespaces, while IIRC #define:s can't. There are very good reasons for avoiding use of #define, see the post by NDsalermo below your post for the real reasons. In C++ one generally uses const variables and inline functions instead of #define.
Currently sarge == woody. Eventually newer packages will start to trickle down from sid to sarge, the same way the trickled down from sid to woody during the woody development. So yes, if you change to sarge you will be downgrading.
I guess it's some braindead idea NY Times has got. For benchmarking supercomputers (which of course necessarily doesn't say much about the performance of any particular application), flops is still the way to go. To be more exact in the form of the linpack benchmark, of which results are published at the top500 site. Incidentally, the site has recently been updated (usually 2 times per year).
Yes, quadrics is pretty sweet. Also the new PNL Linux/IA64 8.4 Tflop supercomputer which is supposed to come online at the end of the year uses quadrics.
From reading the beowulf mailing list archives I remember the estimated cost is about $3500-$5000 per node. Compared to about $2000 for Myrinet or Wulfkit.
No. They use standard compilers and tools for their respective architectures (that is Tru64 for Q and I guess Linux for Green Destiny). The applications are programmed using MPI, a FORTRAN/C/C++ message passing API which is an absolute bitch to program.
And your point is? FYI, none of the computers in the article uses x86 chips (ok you may of course argue that the transmeta chips are x86). As for Motorola chips giving the best tco, I'm not sure I buy it. Most clusters built on a tight budget these days use athlons or P4:s, often in a 2-way configuration. I'm sure they'd use Motorola chips if they would provide better tco and software was available.:) Any good fortran 95 compilers for the G4? Thought not..
Say, fo rinstance, you need to simulate particle interaction...
Actually most molecular dynamics codes parallelize quite well. Of course you need better bandwidth and latency than seti@home, but nothing a cluster couldn't handle (especially if you have one of them nifty low-latency interconnects).
If you don't buy Gates' ad-hocking promises of redemption there are other solutions, like creating a programming language that forces good code; going back to the days of intense peer-review, instead of relying on compilers; and intense planning, past the bungling paradigm of the bar napkin."
"There's no silver bullet" -Fred Brooks, a long time ago.
Well why don't you go read the FHS instead of spreading false info. For example in section 4.11.3 mentions/usr/share/doc as the place for documentation. You can also find the rationale explaining where apps and windowmanagers should be (binaries in one of/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/u sr/local/sbin, libraries etc.).
The next iteration of the enlightenment window manager will use openGL rendering. So I guess it would be possible to make gnome and kde doing it too. Maybe some day..
And windows has its graphic drivers in the kernel, I don't know if it's gpu accelerated though. I suspect not.
Um, you know, most businesses bigger than Bobs Lawnmower Repair Shop will use that $1000000 quicker than you can say 'cash flow problems'.
I guess they wanna charge you a few bucks extra for installing linux. As is said in the article, this is mainly aimed at big corporations who install their own stuff anyway, so they don't want to pay extra for a linux installation they probably won't use anyway.
As to why use freedos instead of some 1-floppy linux distro, who knows?
Maybe they don't wanna tarnish Linux reputation (which perhaps would hurt their server biz) as "that toy crappy thing which is included with every pc to circumwent MS contracts and everybody throws away anyway".
UTF-8 is somewhat ascii compatible, and an efficient coding for mostly ascii data. Looks like the unix world, ietf protocols etc. are moving in this direction. For more info check out
UTF-8 and Unicode FAQ for Unix/Linux.
Which you don't seem to know much about either, as you can't even spell it right.. :)
*hint* PostgreSQL *hint*
Well, postgresql is what sourceforge.net is currently running. I doubt they'll change either, I think this announcement was about sourceforge enterprise edition, which is the thingy va software tries to sell to companies.
In web development, it's all about the tools. The language doesn't really matter. Think about it. For web development, you need a language which can:
1) Connect to a database
2) Be good at string handling
Why are strings important? Well, most stuff in web development is about strings. You interact with the DB via strings, you send the client a bunch of strings etc. Hell, even a god-awful language like Tcl can be really good for web development when you couple it with a kick-ass toolkit, like aolserver/openacs. Incidentally, aolserver/openacs and expect are the only reasons any mentally stable person agrees to learn Tcl.
Performance, on the other hand, is not that important. Most of the time you'll be waiting for the database or to push data to that guy behind a 14.4 modem anyway. What matters performance-wise is that you have some mechanism of keeping the script interpreter loaded all the time (like aolserver/mod_perl/php/java) and having persistent db connections.
So why use Java? It's not really good at handling strings, strong typing is often not necessary in web development and having to compile your code before you test it slows you down (yes, I know JPS:s are automagically compiled). As I said at the beginning of my rant, it's all about the tools. Java has _excellent_ tool support. XML stuff, web services, layered architectures (J2EE), you name it. Java has it. And all the major players in the industry are behind it, except Microsoft of course.
Java is also scalable. For the really simple site, writing a JSP page is as simple as writing a PHP/ASP page. For the high-end stuff, you can have 27 bazillion layers all cleanly separated on separate clusters costing umpteen million dollars.
I'll second that. Although R is primarily for statistics (which is not my cup of tea), I use it for plotting because the plotting stuff in R blows gnuplot (and hence octave) out of the water, IMHO. Another useful free plotting tool that is widely used is grace, it has a nice GUI if you happen to like such things.
1) I didn't say that you were bashing subversion.
2) Ok, maybe bashing is a too harsh word, but I'd hardly say his comparison is unbiased.
3) Yes but there are other things like hard links etc (like almost the entire unix tool chain). A quick search on google finds the author saying himself that arch is only for POSIX environments.
4) Even if it works when you use passive mode ftp, you still need shell access for ssh. Anyway, maybe this isn't such a big problem since there are patches for webdav support. Maybe they'll get integrated into the main tree soon.
Bottom line: both of these will easily blow cvs out of the water. Use whatever you like.
Hrm.. arch is cool in it's own right, no need to bash subversion. They have different goals.
The goal of subversion is to be as similar to cvs as possible, while correcting the big flaws in cvs. If you want, think of Subversion as CVS 2.0. While the backend is quite different, the command-line client is quite similar to cvs, it accepts many of the same options as cvs. Developers familiar with cvs should be almost immidiately productive with subversion. The subversion guys are even developing cvs2svn repository migration tools. Also, subversion has a client API, making writing GUI clients and the like much easier.
Arch, however, is different. Migrating from cvs to arch is not as painless as from cvs to subversion. That being said, arch supports distributed repositories, which subversion doesn't, and has oodles of fancy merge operations. Also, arch consists of about 40klines of mostly shell and awk scripts, which makes some people shudder. This also means that getting arch to run on a non-Unix platform is probably next to impossible, while subversion can run on any platform apache supports (Yes, the client and libs also use APR). Finally, arch currently uses ftp as transport protocol, making it problematic security-wise.
Quoting AC:
So the client is entirely web based? How do you checkin code? Paste it into a web browser?
No, the client is a command-line client, like cvs. It just uses HTTP (or to be more specific WebDAV, a HTTP extension) to communicate with the server.
As it says right on the front page, Subversion uses WebDAV as its transport protocol. As webdav is based on HTTP 1.1 you get all the benefits of HTTP, like for example SSL encryption.
But not for long. According to GCC 3.3 ChangesVMS is obsoleted, which I think means they are going to remove it for the next release after that.
Of course, in GCC 3.1, which is the GCC branch used in Jaguar, VMS support is still there.
PS this message use UTF-8.
It will indeed be a good day when UTF-8 has replaced ISO-8859-* and various other encodings. Actually, I read that the Red Hat 8.0 beta is supposed to use UTF-8 as its default charset, so maybe it'll happen sooner than we think!
1) No, I don't think so.
2) There's always the risk of name conflicts when linking another combination of software than the original. Of course your point is valid in the sense that "normal" identifiers can be put into namespaces, while IIRC #define:s can't. There are very good reasons for avoiding use of #define, see the post by NDsalermo below your post for the real reasons. In C++ one generally uses const variables and inline functions instead of #define.
When that attitude changes we'll start seeing software that rivals hardware in reliability..
Or will we start seeing bridges collapse as an everyday occurance?
Well, hopefully that feature puts a lid on those trigger-happy pilots, especially at low altitude.
Sorry, couldn't resist.
Currently sarge == woody. Eventually newer packages will start to trickle down from sid to sarge, the same way the trickled down from sid to woody during the woody development. So yes, if you change to sarge you will be downgrading.
I guess it's some braindead idea NY Times has got. For benchmarking supercomputers (which of course necessarily doesn't say much about the performance of any particular application), flops is still the way to go. To be more exact in the form of the linpack benchmark, of which results are published at the top500 site. Incidentally, the site has recently been updated (usually 2 times per year).
Yes, quadrics is pretty sweet. Also the new PNL Linux/IA64 8.4 Tflop supercomputer which is supposed to come online at the end of the year uses quadrics.
From reading the beowulf mailing list archives I remember the estimated cost is about $3500-$5000 per node. Compared to about $2000 for Myrinet or Wulfkit.
No. They use standard compilers and tools for their respective architectures (that is Tru64 for Q and I guess Linux for Green Destiny). The applications are programmed using MPI, a FORTRAN/C/C++ message passing API which is an absolute bitch to program.
And your point is? FYI, none of the computers in the article uses x86 chips (ok you may of course argue that the transmeta chips are x86). :) Any good fortran 95 compilers for the G4? Thought not..
As for Motorola chips giving the best tco, I'm not sure I buy it. Most clusters built on a tight budget these days use athlons or P4:s, often in a 2-way configuration. I'm sure they'd use Motorola chips if they would provide better tco and software was available.
Say, fo rinstance, you need to simulate particle interaction...
Actually most molecular dynamics codes parallelize quite well. Of course you need better bandwidth and latency than seti@home, but nothing a cluster couldn't handle (especially if you have one of them nifty low-latency interconnects).
Eh? Your computer was able to run duke nukem and tie fighter while compiling a simple C program took 7 minutes? right...
;-))
And yes, it took ages to download on a 2400bps modem (I did it too
If you don't buy Gates' ad-hocking promises of redemption there are other solutions, like creating a programming language that forces good code; going back to the days of intense peer-review, instead of relying on compilers; and intense planning, past the bungling paradigm of the bar napkin."
"There's no silver bullet" -Fred Brooks, a long time ago.
"It's not because they have suddenly converted to Stallmanism."
Anyone else misread that as "Stalinism"?
So there's actually a difference?
Well why don't you go read the FHS instead of spreading false info. For example in section 4.11.3 mentions /usr/share/doc as the place for documentation. You can also find the rationale explaining where apps and windowmanagers should be (binaries in one of /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/u sr/local/sbin, libraries etc.).