[SARCASM ON} Well, thank you so much for the news flash! [SARCASM OFF]
Hate to tell you, but I read Chinese and Japanese, and if you'd bothered looking, I said three encodings. There are two main character sets - the Traditional Chinese set, which uses the older, more complex form of characters, and Simplified Chinese, which was an effort by the mainland Chinese to cut down on the number of strokes required for most characters, as well as unifying similar characters into one.
As for your comment about the same set of characters for multiple spoken languages (actually dialects), that's true in a broad sense, but many Chinese dialects have words and phrases that cannot be expressed correctly in written Chinese.
And last of all, just because you don't bother actually learning about a subject before you spout off, don't assume that everyone else is on the same level of ignorance as yourself.
That's pretty obvious. If you're on Linux, then you're probably using Communicator, right? Pull down the View menu and have a look under Character Set (yeah, you know, it's that item that you've never bothered to check before). It lists three Chinese encodings - Big5, EUC-TW and GB2312.
And then there's Japanese, which has three widely-used encodings - JIS (not listed in Communicator but still viewable), SJIS (as used by MS and Apple) and EUC-JP (UNIX-related OSs).
Learn something about the subject before opening your mouth next time.
I was actually referring to the adjective "woozy", as in dizzy, rather than the noun "wussie"/"woosie"/"woosy", which means that you get sand kicked in your face regularly;)
Certainly, you're free to use the solution that suits your users, but saying things like:
If we have to sacrifice some bandwidth to make this happen, so what?
isn't going to make you many friends among most IT departments; not everyone runs Gigabit Ethernet (hell, the company I used to work at was using plain old 10Mb Ethernet for more than 350 clients (SMB, IPX, Ethertalk, TCP/IP) - without subnets or any other way of limiting broadcast traffic).
I know about H.323, but AFAIK the H.323 standard talks mainly about transmission over LANs and specifies nothing about encapsulating it with HTTP, so your last statement doesn't really mean much, does it? It's like saying, "A firehose is designed to carry water, so there's nothing wrong with encasing it in a garden hose." I mean, that's gotta kill your bandwidth.
My point (which applies to HTTP-DAV as well) is that most people would be better off using a server and protocol that are designed for the way they're going to use it, rather than trying to stick a square peg in a round hole. Just because your users are too braindead to use ftp/ncftp/WsFTP/CuteFTP/Fetch for file transfers, don't try and convince others that your solution is the best and web servers should be made to handle it.
Shit, yes, I do huge file transfers and video conferencing over HTTP all the time!
F'chrissakes, use a protocol that actually suits what you're trying to do. FTP, NFS or SMB for file transfers; one of the streaming protocols for video conferencing. (Actually, come to think of it, video conferencing over HTTP isn't really feasible; what are you doing, breaking the video stream up into frames, converting them to JPEGs and pushing them to the clients?!)
OK, I'll take a shot at guessing what these are (without peeking, of course):
linuxtraffic - ML archive linuxtomorrow - Linux-related press releases linuxtv - TV applicatins (like XawTV). Or a Linux-based settop box. linuxpenguin - Stuffed penguins linuxbob - Fnor! linuxpaper - Paper as in "newspaper", perhaps? linuxpop - A free mail server linuxvision - Ditto with linuxtv above. linuxfood - Penguin mints and free pizza
And, finally:
linuxninja - Bill Gates's crack team of asssassination experts.
I'm glad to see the free software/open source concept being recognized like this, but I think it would have been nice if these experts had taken the time to look at other alternatives. I mean, sure Linux is probably more secure than NT, but OpenBSD is way more secure than most Linux distributions (I'm talking about DEFAULT setups here), so declaring Linux to be the most secure open system available is a bit of a crock.
Yes, it will work on a Multia, but you'll lose most of the benefits of its code optimizations; a Multia is an EV4 Alpha (a 21066?), whereas the compiler's optimizations (especially math optimizations) are written to perform best on EV56 / EV6.
Heh. I just bought a Digital 600MHz Alpha 21164 PWS secondhand (but in spotless condition) for around $US1600. It'll kick a PII/400's ass for FP any day.
The C compiler has been available for quite a while now. I think they just tacked it on to the end of the press release as an afterthought, rather than as a new announcement.
If you think that real-world physics in game engines is "heavy number-crunching", then please, write your software in C++.
BTW, there's a big difference between in saying that libraries in C++ can be just as good as those in Fortran, and actually providing libraries that are faster than those in Fortran. I've yet to see any compiler/library combination on Alpha that improves on the performance of Digital's Fortran.
OTOH, I find it hard to imagine that too many ppl on Linux/Alpha have a big use for fortran anyhow..
You have got to be kidding. An awful lot of scientific applications are written in Fortran for two reasons: 1: Many scientists started using Fortran a long time ago, and they can't be bothered switching now (not to mention all that legacy software they've stocked up). 2: The floating-point math libraries for Fortran on the Alpha are way faster than just about any other language on any desktop platform, period.
If Fortran wasn't available for Alpha, the architecture would have most likely sunk into obscurity a long time ago.
IIRC, this has actually been available for quite a while in beta form. This is, however, good news - the Digital (I can't bear to call it Compaq) Alpha compiler for Fortran produces code that is anywhere up to 2-3 times as fast as g77 (currently, that is. I'm sure g77 will get better). Anybody doing scientific work on an Alpha under Linux (and, let's face it, most people that have Alphas use them specifically because they're good at scientific work) can benefit from this.
(FWIW, I've used the Digital C compiler for Linux, and it produces excellent code - better, in most cases, than gcc.)
That's the NM256AV, right? It's not actually a "sound chip" per se - they just stuck SBPro compatibility onto the graphics chip. That's part of the reason why the driver took so long to produce, and even now it's still a hack (you have to reserve a chunk of video memory (!) to use the audio).
Here in Japan, you can walk into virtually any post office in the country and pick up a book of zip codes for the entire country for a nominal fee. I believe they even supply them free to comapnies.
And believe me, since the switch to seven-figure zip codes a couple of years ago, they're pretty precise. My zip code covers an area of about one square kilometer.
AGP? Methinks you mean USB...
Boy, your face must be red right about now
You just managed to confirm your stupidity by not catching the error in your .sig, even when it was brought to your attention.
Well done. Try not to get yourself nominated for a Darwin Award...
[SARCASM ON} Well, thank you so much for the news flash! [SARCASM OFF]
Hate to tell you, but I read Chinese and Japanese, and if you'd bothered looking, I said three encodings. There are two main character sets - the Traditional Chinese set, which uses the older, more complex form of characters, and Simplified Chinese, which was an effort by the mainland Chinese to cut down on the number of strokes required for most characters, as well as unifying similar characters into one.
As for your comment about the same set of characters for multiple spoken languages (actually dialects), that's true in a broad sense, but many Chinese dialects have words and phrases that cannot be expressed correctly in written Chinese.
And last of all, just because you don't bother actually learning about a subject before you spout off, don't assume that everyone else is on the same level of ignorance as yourself.
i'm no expert on Linux with Chinese
That's pretty obvious. If you're on Linux, then you're probably using Communicator, right? Pull down the View menu and have a look under Character Set (yeah, you know, it's that item that you've never bothered to check before). It lists three Chinese encodings - Big5, EUC-TW and GB2312.
And then there's Japanese, which has three widely-used encodings - JIS (not listed in Communicator but still viewable), SJIS (as used by MS and Apple) and EUC-JP (UNIX-related OSs).
Learn something about the subject before opening your mouth next time.
I was actually referring to the adjective "woozy", as in dizzy, rather than the noun "wussie"/"woosie"/"woosy", which means that you get sand kicked in your face regularly
Certainly, you're free to use the solution that suits your users, but saying things like:
If we have to sacrifice some bandwidth to make this happen, so what?
isn't going to make you many friends among most IT departments; not everyone runs Gigabit Ethernet (hell, the company I used to work at was using plain old 10Mb Ethernet for more than 350 clients (SMB, IPX, Ethertalk, TCP/IP) - without subnets or any other way of limiting broadcast traffic).
I know about H.323, but AFAIK the H.323 standard talks mainly about transmission over LANs and specifies nothing about encapsulating it with HTTP, so your last statement doesn't really mean much, does it? It's like saying, "A firehose is designed to carry water, so there's nothing wrong with encasing it in a garden hose." I mean, that's gotta kill your bandwidth.
My point (which applies to HTTP-DAV as well) is that most people would be better off using a server and protocol that are designed for the way they're going to use it, rather than trying to stick a square peg in a round hole. Just because your users are too braindead to use ftp/ncftp/WsFTP/CuteFTP/Fetch for file transfers, don't try and convince others that your solution is the best and web servers should be made to handle it.
I believe that's spelled "woozy"
Shit, yes, I do huge file transfers and video conferencing over HTTP all the time!
F'chrissakes, use a protocol that actually suits what you're trying to do. FTP, NFS or SMB for file transfers; one of the streaming protocols for video conferencing. (Actually, come to think of it, video conferencing over HTTP isn't really feasible; what are you doing, breaking the video stream up into frames, converting them to JPEGs and pushing them to the clients?!)
Thanks
Just kidding
Um... I was just listing the ones that Hemos gave in his post. Nobody here is giving a full list of Linux-related domains. What's your problem?
Come to think of it, linuxpaper could be a site promoting toilet paper with little penguins printed all over it...
OK, I'll take a shot at guessing what these are (without peeking, of course):
linuxtraffic - ML archive
linuxtomorrow - Linux-related press releases
linuxtv - TV applicatins (like XawTV). Or a Linux-based settop box.
linuxpenguin - Stuffed penguins
linuxbob - Fnor!
linuxpaper - Paper as in "newspaper", perhaps?
linuxpop - A free mail server
linuxvision - Ditto with linuxtv above.
linuxfood - Penguin mints and free pizza
And, finally:
linuxninja - Bill Gates's crack team of asssassination experts.
This is OT, but does the "k" in kvajk stand for Kevin?
I'm glad to see the free software/open source concept being recognized like this, but I think it would have been nice if these experts had taken the time to look at other alternatives. I mean, sure Linux is probably more secure than NT, but OpenBSD is way more secure than most Linux distributions (I'm talking about DEFAULT setups here), so declaring Linux to be the most secure open system available is a bit of a crock.
Yes, it will work on a Multia, but you'll lose most of the benefits of its code optimizations; a Multia is an EV4 Alpha (a 21066?), whereas the compiler's optimizations (especially math optimizations) are written to perform best on EV56 / EV6.
Heh. I just bought a Digital 600MHz Alpha 21164 PWS secondhand (but in spotless condition) for around $US1600. It'll kick a PII/400's ass for FP any day.
I believe Alan Cox put together the remnants of a DOS COBOL compiler into a package that would run on Linux (try looking in ftp://ftp.linux.org.uk/pub/linux/alan/ Cobol/.
The C compiler has been available for quite a while now. I think they just tacked it on to the end of the press release as an afterthought, rather than as a new announcement.
If you think that real-world physics in game engines is "heavy number-crunching", then please, write your software in C++.
BTW, there's a big difference between in saying that libraries in C++ can be just as good as those in Fortran, and actually providing libraries that are faster than those in Fortran. I've yet to see any compiler/library combination on Alpha that improves on the performance of Digital's Fortran.
OTOH, I find it hard to imagine that too many ppl on Linux/Alpha have a big use for fortran anyhow..
You have got to be kidding. An awful lot of scientific applications are written in Fortran for two reasons:
1: Many scientists started using Fortran a long time ago, and they can't be bothered switching now (not to mention all that legacy software they've stocked up).
2: The floating-point math libraries for Fortran on the Alpha are way faster than just about any other language on any desktop platform, period.
If Fortran wasn't available for Alpha, the architecture would have most likely sunk into obscurity a long time ago.
IIRC, this has actually been available for quite a while in beta form. This is, however, good news - the Digital (I can't bear to call it Compaq) Alpha compiler for Fortran produces code that is anywhere up to 2-3 times as fast as g77 (currently, that is. I'm sure g77 will get better). Anybody doing scientific work on an Alpha under Linux (and, let's face it, most people that have Alphas use them specifically because they're good at scientific work) can benefit from this.
(FWIW, I've used the Digital C compiler for Linux, and it produces excellent code - better, in most cases, than gcc.)
That's the NM256AV, right? It's not actually a "sound chip" per se - they just stuck SBPro compatibility onto the graphics chip. That's part of the reason why the driver took so long to produce, and even now it's still a hack (you have to reserve a chunk of video memory (!) to use the audio).
Here in Japan, you can walk into virtually any post office in the country and pick up a book of zip codes for the entire country for a nominal fee. I believe they even supply them free to comapnies.
And believe me, since the switch to seven-figure zip codes a couple of years ago, they're pretty precise. My zip code covers an area of about one square kilometer.