Dammit RIAA all you have to do to win the entire fucking market and make these same billions of dollars you sue everyone for is OFFER FUCKING DRM FREE MUSIC FROM YOUR OWN SITES AT THE PRICE APPLE HAS ALREADY DETERMINED WILL WORK!!!!!
Why sell a song for $1 when you can wait for someone else to sell it and then sue them for $150,000?
This movement appears to be indicative of the propensity of lackadaisical or indeed preposterous individuals to repudiate the necessities of encouraging a proper enlightenment of the intricacies of linguistic comunication. Unquestionably, this preposterous
which only runs on my W2k workstation, because the distributed folks never rewrote the older cores that run on my pre-OSX Macs.
Have you tried mailing d.net about porting the clients to older Macs? They should be able to find someone willing to do it, although I admit the latest clients on their download page are very old.
I know for a fact that RC5-72 cores for PPC were made, because I wrote some of them:-)
This is exactly the issue with the Chinese characters. For a given character, there might be a difference between the
Taiwanese way of writing it, the Japanese way, and the mainland Chinese way; but the character is still recognized as being
the same, despite these presentation-level differences.
I'd like to make a couple more points about this: suppose the characters have been encoded by arrogant know-nothing westerners, and it were the case that logically distinct characters have been unified, the real solution is to get onto the committee and have new characters assigned. If, as the article suggests, around 170,000 code points are genuinely needed, then fine - Unicode can handle that many.
If there are any characters not included in Unicode, it's because it doesn't need them, or it doesn't support them yet. As has been pointed out by many posters, characters are being added all the time. Just last month, version 3.1 of the standard was published which just about doubled the number of assigned characters over 3.0.
Yeah, actually they do:-) But I don't have the book with me right now so I can't tell you the exact range of codes.
In fact they're one of the few (maybe the only) ranges of characters where the shape of the glyph is defined by the standard. Most characters are just encoded by semantic value (in other words, the letter 'A' is encoded once, and not separately for different fonts and styles - an italic 'A' is still just an 'A').
UTF-8, which is a variable length encoding most commonly used on the web allows a mapping of Unicode from U-00000000 to U-7FFFFFFF
No, Unicode only allows character values up to 0x10FFFF (the 16-bit basic multilingual plane, plus 2^20 surrogate pairs). This conveniently means that all characters can be expressed in four bytes in UTF-8, as noted here.
That FAQ, as I pointed out in another thread, is not 100% accurate.
...but it can handle the entire Unicode character set.
All encodings can handle the entire character set. They'd be pointless if they couldn't!
UCS allows 31-bit character codes, Unicode however only allows up to 0x10FFFF, which is a little over 2^20. UCS characters may occupy up to six bytes, but according to
this page, "All three encoding forms [UTF-8, UTF-16, UTF-32] need at most 4 bytes (or 32-bits) of data for each character."
BTW, it's important to recognise the difference between scalar values, which are the numerical values assigned to characters, and encodings (UTF-8 and so on), which are just ways of encoding those scalar values with different levels of memory efficiency, ease of parsing etc. Every encoding covers the same range of scalar values (ie. all of them).
(Unfortunately the official Unicode standard is only available in dead tree form, so it's kinda hard to give relevant links...)
I'm pretty sure that the fact that the clock will stop time is also not given away until later in the book, and I'm not entirely
sure about the Fifth Horseman either.
Both these things are mentioned in the blurb on the inside front cover, more or less.
> Basically there has to be some system to stop the buggy clients downloading blocks and wasting their time.
A tidier way might be to encode the minimum client version needed in each block. So, when OGR is restarted, the blocks given out are tagged as requiring build 460 or whatever, and older clients don't touch those blocks. If this were part of the protocol when clients talk to keyservers, clients could avoid downloading "newer" blocks entirely. A client could also tell the user when an upgrade is required to cope with the latest blocks.
Of course, this doesn't get around the current problem but could work in future clients, and also as a way of making sure old beta-test clients don't do any "real" work.
So? You've just described OS3.5, for existing Amiga users who want an upgrade to their existing machines. This has nothing to do with the new machines, which will be a new architecture running a new OS, based on QNX.
Slashdot Mirror
Why sell a song for $1 when you can wait for someone else to sell it and then sue them for $150,000?
*bzzzz*
Repetition!
Not if you're using "butt" to mean "barrel", as in a water butt.
which only runs on my W2k workstation, because the distributed folks never rewrote the older cores that run on my pre-OSX Macs.
Have you tried mailing d.net about porting the clients to older Macs? They should be able to find someone willing to do it, although I admit the latest clients on their download page are very old.
I know for a fact that RC5-72 cores for PPC were made, because I wrote some of them :-)
I'd like to make a couple more points about this: suppose the characters have been encoded by arrogant know-nothing westerners, and it were the case that logically distinct characters have been unified, the real solution is to get onto the committee and have new characters assigned. If, as the article suggests, around 170,000 code points are genuinely needed, then fine - Unicode can handle that many.
If there are any characters not included in Unicode, it's because it doesn't need them, or it doesn't support them yet. As has been pointed out by many posters, characters are being added all the time. Just last month, version 3.1 of the standard was published which just about doubled the number of assigned characters over 3.0.
Yeah, actually they do :-) But I don't have the book with me right now so I can't tell you the exact range of codes.
In fact they're one of the few (maybe the only) ranges of characters where the shape of the glyph is defined by the standard. Most characters are just encoded by semantic value (in other words, the letter 'A' is encoded once, and not separately for different fonts and styles - an italic 'A' is still just an 'A').
No, Unicode only allows character values up to 0x10FFFF (the 16-bit basic multilingual plane, plus 2^20 surrogate pairs). This conveniently means that all characters can be expressed in four bytes in UTF-8, as noted here.
That FAQ, as I pointed out in another thread, is not 100% accurate.
All encodings can handle the entire character set. They'd be pointless if they couldn't!
ISO 10646 != Unicode, and UCS-1 != UTF-8.
UCS allows 31-bit character codes, Unicode however only allows up to 0x10FFFF, which is a little over 2^20. UCS characters may occupy up to six bytes, but according to this page, "All three encoding forms [UTF-8, UTF-16, UTF-32] need at most 4 bytes (or 32-bits) of data for each character."
BTW, it's important to recognise the difference between scalar values, which are the numerical values assigned to characters, and encodings (UTF-8 and so on), which are just ways of encoding those scalar values with different levels of memory efficiency, ease of parsing etc. Every encoding covers the same range of scalar values (ie. all of them).
(Unfortunately the official Unicode standard is only available in dead tree form, so it's kinda hard to give relevant links...)
Both these things are mentioned in the blurb on the inside front cover, more or less.
> Basically there has to be some system to stop the buggy clients
downloading blocks and wasting their time.
A tidier way might be to encode the minimum client version needed in
each block. So, when OGR is restarted, the blocks given out are tagged
as requiring build 460 or whatever, and older clients don't touch
those blocks. If this were part of the protocol when clients talk to
keyservers, clients could avoid downloading "newer" blocks entirely. A
client could also tell the user when an upgrade is required to cope
with the latest blocks.
Of course, this doesn't get around the current problem but could work
in future clients, and also as a way of making sure old beta-test
clients don't do any "real" work.
Sounds like the "Made for Windows 95" monitors we used to have here.
So? You've just described OS3.5, for existing Amiga users who want an upgrade to their existing machines. This has nothing to do with the new machines, which will be a new architecture running a new OS, based on QNX.