I hate to say this but you can safely ignore anything Chosun Ilbo brags in their so-called 'tech' section. it's nothing but corporate PR stunt.
IMHO ETNews is far more reliable source of tech news in Korea.
(And yes, I'm a Korean)
The only legal attack that US gov could take about this supercomputer would be urging China gov to recontribute the kernel code. As I know of, they already adopted linux (don't know if its kernel tho) to use them in China gov, but I didn't hear their change (mostly I18N I think) was patched back.
Without action, China will never patch back the code for this supercomputer spontaneously. The C|Net article toutes `National Pride' thing, but they would consider the kernel code as `National Property': that's Chinese line of thought.
according to this Korean page, defendants include major Korean ISPs (KT, Hanaro et al.), Korean Govenment Dept. of IT, and finally, Microsoft. So they're suing the dumb admins and M$ altogether.
Maybe the confusion arose from the source eWeek is refering, Chosun Ilbo. It's not a very reliable source for arguable matter. Believe me... In case you can read Korean, that is to say.
Especially from Samsung, who to the best of my knowledge has never been a player in the workstation market.
Yes they were. Samsung produced Magic Workstation back in 90s. One machine was
still operating in my laboratory in 1996.
(Please don't confuse this with current MagicStation line. They are PCs)
IIRC, it used Intel i860 CPU with 1024x768 4-level grey display. I remember it had some SIMM
banks, so I suppose it had most chipsets common
with WinTel machines, just like this Alpha workstation.
The development of an OS must be managed, otherwise a lot of duplicated works or mistakes can be easily made.
But to not be in violation with the GPL, parts of the OS will be under GPL.
IANAFSFLawyer, but this smells like a violation of GNU GPL 3b. and they are not releasing the source to the public (as of now), and does not expose who they are.
interesting. here in Korea we are charged for every page we SEND. so basically we are almost page spam free.
we once had spam page too, when every portals and their mama had free ``paging on internet'' service. eventually wireless service providers prohibited paging through web (subscriber service), and the spam notably diminished.
I don't know very much about win32 innards but for POSIX environment UTF-8 seems to be the only choice.
First, M$ doesn't seem to bother about the endianness problem, since virtually the only hardware they are supporting is x86. while us the nixes front must support either endian flawlessly.
Second, I don't think we can use UTF-16 on any terminal driver just as easily as UTF-8.
about the processing penalty, as far as I know, glibc uses UCS-4 as the internal representation (wchar_t), and I highly doubt any libc might use UTF-8 as internal representation. converting UTF-8 to and from UCS-4 is fairly straight forward, and won't be much burden esp. since it will only occur at I/O stage.
Re:The road to closed PC hardware?
on
nVidia nForce
·
· Score: 1
maybe so. maybe not.
did you ever see any AT clone board made in 80s? it didn't have a single board chip solution like i815 nowadays. it had many ICs comprising ``chip-set'', including separate ISA Bus Arbiter, Interrupt, DMA, Serial, etc. it even had several 74xx's go among them. (*sigh* I'm getting older. I forgot the chip numbers...)
when they started to be integrated into handful of `chipset's, several of us worried about the future of `enhanced-mode programming', fearing that the way IRQ, DMA or serial port access might change to proprietary. but what happened? they still remain the same, more or less. even the IO port #s for serial/parallel port still remain the same (although you can change them in CMOS).
maybe your fear is justifiable. but rather than rejectting nVidia hardware, shouldn't we take their architecture into OSS? once enough software base is established it is very hard for a hardware maker to change the architecture. RE or not we must archieve it, because someone else will follow the nVidia way for performance.
embrace and enhance, rather than reject first.
multimedia is needed on desktop
on
MP3Pro Released
·
· Score: 1
we should pay more attention to this kind of news. without sufficient multimedia formats available on linux, it will be very hard for linux to root on most users desktop. and we definitely won't want to have every linux distro to pay $7.50 per codec as license fees.
one solution would be to encourage everyone to use free (read: ogg) or more-or-less free formats (like mpeg 1 video, mpeg 1 audio layer 3 etc). once this area is saturated by proprietary formats it will be harder to revamp than usual software market.
I'm really sad that real Westerner's attitude prevails right here in slashdot. I'm not surprised, even emacs rmail writers think MIME as a useless thing. that's the Westerner's attitude, so ignorant about I18N. probably most of you MERKINs don't know what I18N is in the first place.
Mr. Caroll is just wrong in everything he claims. even the most classical and even a little bit absurd, not proven to exist and pure theoretical Hangul (Korean script) glyphs are included in the block starting in U+1100. I won't repeat at each FUD's he is spreading since the reply from Unicode above sums them up very well.
I'm a Korean. for us the ISO-10646 and the Unicode is the Right Thing(tm), not only a Good Thing(tm).
well some of the Japanese seem to hate Unicode. so be it. but let me tell you this. the very notion that a coding system must be defined in a lexicographical order is just OBSOLETE. that's why you have LC_COLLATE in POSIX locale.
and about ability to code fictional script in Unicode, you can use the 31-bit space in UCS-4, just set the MSB 1. you can do whatever crazy thing in that space. that's why ISO-10646 is a 31-bit representation, not 32-bit.
the REAL PROBLEM in Unicode is that the standard itself is unavailable in web, so most/.ers (and most merkins) don't bother to find out what it is, so much for actually reading it. the standard is a hefty volume of dead trees (paper) and costs a hefty fit from your purse. before the standard itself is available on web FUD's like Mr. Caroll is spreading won't be stopped in english nations, most of all US of A.
but wouldn't you must RTFM before you throw flame on everything that makes you feel shit, mostly because you have to pay (storage space) for things you don't want (languages other than english the language so-much-perfect-for-everything-even-jesus-speaks-i n-it)? I expected that much from/.ers. maybe I expected too much.
this problem is more apparent here in far east than the U.S. of A.
friends of mine in 'net service corporations always mention this problem. interesting thing is, although they(geeks in development) 100% want to make it browser neutral, often budget and time prevents them to do it. even server-side scripting other than JSP is nightmare, because not so surprisingly, most BOFH's in your ISP doesn't know how to setup things properly to run mod_perl. or php4. or even apache. every now and then my friends run to the ISP, just to fix the configuration errors, and help BOFHs compile gcc-2.97.
so, with limited resource and wasted effort, you must choose the biggest pie you can get. and what is it? IE, of course.
worse is, most PHB clients want their webpage look fancy on their own desktop. they want every fscking kinds of bells and whistles, even if that actullay lowers usability of their own site. and what browser would they use, do you suppose?
only when other browsers gain comparable usage popularity, this trend could be hindered. and that means better-than-IE at least. especially dealing with I18N, especially around these parts of the world.
not to mention horrible rendering speed of mozilla 6.
I read on
http://www.spectrum.ieee.org/publicfeature/tran. html
that the guys in transmeta had really
hard times optimizing for Win95 and
its IA16 codes. and I don't suppose
C'T ran those benchmarks on NT or W2k.
That might too have hit the performance on
Cruseo.
I mostly agree about your point... but
would it hold for Q3 also? hopefully the
morph cache should have rendering code
and optimized it very hard, especially
no other CPU activity takes place in that case.
I hate to say this but you can safely ignore anything Chosun Ilbo brags in their so-called 'tech' section. it's nothing but corporate PR stunt. IMHO ETNews is far more reliable source of tech news in Korea. (And yes, I'm a Korean)
The only legal attack that US gov could take about this supercomputer would be urging China gov to recontribute the kernel code. As I know of, they already adopted linux (don't know if its kernel tho) to use them in China gov, but I didn't hear their change (mostly I18N I think) was patched back.
Without action, China will never patch back the code for this supercomputer spontaneously. The C|Net article toutes `National Pride' thing, but they would consider the kernel code as `National Property': that's Chinese line of thought.
according to this Korean page, defendants include major Korean ISPs (KT, Hanaro et al.), Korean Govenment Dept. of IT, and finally, Microsoft. So they're suing the dumb admins and M$ altogether.
Maybe the confusion arose from the source eWeek is refering, Chosun Ilbo. It's not a very reliable source for arguable matter. Believe me... In case you can read Korean, that is to say.
Yes they were. Samsung produced Magic Workstation back in 90s. One machine was
still operating in my laboratory in 1996.
(Please don't confuse this with current MagicStation line. They are PCs)
IIRC, it used Intel i860 CPU with 1024x768 4-level grey display. I remember it had some SIMM
banks, so I suppose it had most chipsets common
with WinTel machines, just like this Alpha workstation.
IANAFSFLawyer, but this smells like a violation of GNU GPL 3b. and they are not releasing the source to the public (as of now), and does not expose who they are.
interesting. here in Korea we are charged for every page we SEND. so basically we are almost page spam free.
we once had spam page too, when every portals and their mama had free ``paging on internet'' service. eventually wireless service providers prohibited paging through web (subscriber service), and the spam notably diminished.
I don't know very much about win32 innards but for POSIX environment UTF-8 seems to be the only choice.
First, M$ doesn't seem to bother about the endianness problem, since virtually the only hardware they are supporting is x86. while us the nixes front must support either endian flawlessly.
Second, I don't think we can use UTF-16 on any terminal driver just as easily as UTF-8.
about the processing penalty, as far as I know, glibc uses UCS-4 as the internal representation (wchar_t), and I highly doubt any libc might use UTF-8 as internal representation. converting UTF-8 to and from UCS-4 is fairly straight forward, and won't be much burden esp. since it will only occur at I/O stage.
maybe so. maybe not.
did you ever see any AT clone board made in 80s? it didn't have a single board chip solution like i815 nowadays. it had many ICs comprising ``chip-set'', including separate ISA Bus Arbiter, Interrupt, DMA, Serial, etc. it even had several 74xx's go among them. (*sigh* I'm getting older. I forgot the chip numbers...)
when they started to be integrated into handful of `chipset's, several of us worried about the future of `enhanced-mode programming', fearing that the way IRQ, DMA or serial port access might change to proprietary. but what happened? they still remain the same, more or less. even the IO port #s for serial/parallel port still remain the same (although you can change them in CMOS).
maybe your fear is justifiable. but rather than rejectting nVidia hardware, shouldn't we take their architecture into OSS? once enough software base is established it is very hard for a hardware maker to change the architecture. RE or not we must archieve it, because someone else will follow the nVidia way for performance.
embrace and enhance, rather than reject first.
we should pay more attention to this kind of news. without sufficient multimedia formats available on linux, it will be very hard for linux to root on most users desktop. and we definitely won't want to have every linux distro to pay $7.50 per codec as license fees.
one solution would be to encourage everyone to use free (read: ogg) or more-or-less free formats (like mpeg 1 video, mpeg 1 audio layer 3 etc). once this area is saturated by proprietary formats it will be harder to revamp than usual software market.
isn't the earth enough as contaminated by humans?
www.vhemt.org
yes. but put the sandboxes AFTER spending 140k? I always thought it's the 1st thing you should do after purchasing your first audio system, and house.
I wonder what audio mag he is reading...
I'm really sad that real Westerner's attitude prevails right here in slashdot. I'm not surprised, even emacs rmail writers think MIME as a useless thing. that's the Westerner's attitude, so ignorant about I18N. probably most of you MERKINs don't know what I18N is in the first place.
/.ers (and most merkins) don't bother to find out what it is, so much for actually reading it. the standard is a hefty volume of dead trees (paper) and costs a hefty fit from your purse. before the standard itself is available on web FUD's like Mr. Caroll is spreading won't be stopped in english nations, most of all US of A.
i n-it)? I expected that much from /.ers. maybe I expected too much.
Mr. Caroll is just wrong in everything he claims. even the most classical and even a little bit absurd, not proven to exist and pure theoretical Hangul (Korean script) glyphs are included in the block starting in U+1100. I won't repeat at each FUD's he is spreading since the reply from Unicode above sums them up very well.
I'm a Korean. for us the ISO-10646 and the Unicode is the Right Thing(tm), not only a Good Thing(tm).
well some of the Japanese seem to hate Unicode. so be it. but let me tell you this. the very notion that a coding system must be defined in a lexicographical order is just OBSOLETE. that's why you have LC_COLLATE in POSIX locale.
and about ability to code fictional script in Unicode, you can use the 31-bit space in UCS-4, just set the MSB 1. you can do whatever crazy thing in that space. that's why ISO-10646 is a 31-bit representation, not 32-bit.
the REAL PROBLEM in Unicode is that the standard itself is unavailable in web, so most
but wouldn't you must RTFM before you throw flame on everything that makes you feel shit, mostly because you have to pay (storage space) for things you don't want (languages other than english the language so-much-perfect-for-everything-even-jesus-speaks-
ignorance IS the human anyway.
this problem is more apparent here in far east than the U.S. of A.
friends of mine in 'net service corporations always mention this problem. interesting thing is, although they(geeks in development) 100% want to make it browser neutral, often budget and time prevents them to do it. even server-side scripting other than JSP is nightmare, because not so surprisingly, most BOFH's in your ISP doesn't know how to setup things properly to run mod_perl. or php4. or even apache. every now and then my friends run to the ISP, just to fix the configuration errors, and help BOFHs compile gcc-2.97.
so, with limited resource and wasted effort, you must choose the biggest pie you can get. and what is it? IE, of course.
worse is, most PHB clients want their webpage look fancy on their own desktop. they want every fscking kinds of bells and whistles, even if that actullay lowers usability of their own site. and what browser would they use, do you suppose?
only when other browsers gain comparable usage popularity, this trend could be hindered. and that means better-than-IE at least. especially dealing with I18N, especially around these parts of the world.
not to mention horrible rendering speed of mozilla 6.
Why bother make yet another time standard? we already have proven, well-working, Y2K-whatever-compliant method to time; UTC.
I'm writing this at 977388265. just remember
that a day is about 0x15k, you're set.
I read on
http://www.spectrum.ieee.org/publicfeature/tran
that the guys in transmeta had really
hard times optimizing for Win95 and
its IA16 codes. and I don't suppose
C'T ran those benchmarks on NT or W2k.
That might too have hit the performance on
Cruseo.
I mostly agree about your point... but
would it hold for Q3 also? hopefully the
morph cache should have rendering code
and optimized it very hard, especially
no other CPU activity takes place in that case.
--
gaemon