There is one huge problem with all this -- it's extremely hard to write any decent software for Windows platform, free or not. And it's even harder to keep it portable, especially if one hopes to use Wine/winelib or other such thing instead of full-blown native port (ex: WP 2000 vs. Opera 5.0 on Linux). One of problem with Mozilla is that too much of Windows-derived ideas were placed into it, causing unnecessary bloat. So there are reasons why there isn't much free software for Windows, and among those reasons idiosyncrasy or bigotry aren't even on the top of the list.
You are a Microsoft troll. Either MCSE that is trying to convince himself that he is not inferior to real sysadmions, or an astroturfer. What is your experience as "solaris admin" -- logging into a box as root, saying "rm -rf/" and loudly complaining about results?
Revealing passwords of outside resources allows subversion of those outside resources by others, which can allow attacks back into your facilities. Finding an outside telnet, ftp, or web mail password allows tinkering with files which may be transferred into your corporate facilities.
Who said that they even use passwords? Maybe they use one-time passwords?
An employee might trust the attachments on saved email from a trusted source, not realizing that someone has altered them.
There is much more to the security of other users' accounts than encryption. In fact, it's extremely unlikely that potential intruder is sitting at mae-west examining the packets from your network, in the hope that he will intercept some of your users' unencrypted password to some external account, so he will plant some file there, so user will transfer it to his box at work, run it, and that will compromise your network. Intruders don't think that way. At best, if they will bother to plant some modified files on the user's account outside, they will find a security flaw that will allow them to access user's insecure account outside, and then it will make absolutely no difference, how user will access it -- over ssh or ftp. In any case, port filtering at work will not prevent user from using telnet from home, and it's more likely that his connection will be intercepted there because of poor configuration of bridges and switches at his ISP, thus making the whole effort a moot point.
At most, banning all outside connections but ssh will make a lot of users who have outside accounts without ssh support ssh to some box outside, then run telnet to non-ssh-supporting account. Security gained: 0, waste of time: 15 seconds per connection (to type a password), 100ms per packet (latency between outside accounts).
It doesn't matter if the weak link is outside or inside your corporate LAN.
You can't eliminate any insecure stuff outside, except the most unlikely way for intruder to make his, very indirect, attack. And there are thousands of ways to send a file to someone, pretending that it comes from his own account. You can't control that, and you shouldn't for a second imagine that you can -- even if you can decrease the probability of such attack by 0.1%. Instead you have to create a reasonable policy in the place where it matters -- never transfer anything executable from outside, period. If users can't avoid opening attachments in outlook -- ban outlook, make mail server strip all non-text attachments, do something else useful, but it's important that policy should be directed against real dangers instead of creating imaginary protection for accounts, you can't control.
How ssh (port 22) is any different from anything else? If connection outside can be established, no matter through what, even if through HTTP proxy, it can be used for forwarding.
Certainly. However, ssh *is* a secure form of shell communication. Telnet isnt. The fact that it can be used for other things is really besides the point.
What users are doing connecting _outside_ from inside, changes nothing. Telnet may be insecure, but who said that users are accessing something that requires security in the first place? It's outside! I access slashdot without any possibility of hiding my password when I log in, and I have no way to verify any signatures, yet it's perfectly acceptable because my authentication here is not important for security. OTOH, what users doing by connecting _from outside_ is always important -- at very least the passwords they use must be protected. However even that may not be necessarily as important as sysadmin logging in -- user may use one-time password and never transfer anything sensitive unencrypted (but FTPing of encrypted files is ok). This, of course, requires users that ACTIVELY support security, so most of people in the company simply aren't qualified to make the distinction, what they can or can't do over one-time authenticated but unencrypted link, so restricting them to inbound ssh is reasonable.
The rest of your post is essentially a big "Why bother with security at all, just trust your users" speech.
Not at all. I only mean "don't protect your network against malicious users". And this is absolutely reasonable because users ALWAYS have more opportunities to cause harm to the company without talking to anything outside the network, compared to anything that they can do with it.
While thats nice, when you are in charge of protecting corporate data that is mission critical, and users that dont know what right-clicking is, you will have a different grasp of things.
If the users are not malicious but merely incompetent, harm from them will not be decreased in any way by messing up their connections to the outside world -- after all, Melissa distributes itself using plain mail, and there is no reason to believe that anything else harmful won't do exactly the same. Better results can be done by banning users from installing any software on their boxes without a technician involves, and, if the OS allows, enforcing it in the configuration. And even without that, banning Outlook goes a long way to stop whatever malicious stuff may arrive -- it certainly will allow to avoid more trouble than any imaginable restriction to outgoing connections.
The job requirements dont say get touchy-feely and trust our users, they say keep the bad guys ( including employees) out, or you are out of a job.
I don't care, what your "job requirements" are -- if "bad guys" are already among employees, you MUST GIVE UP trying to thwart them because you have already lost -- at that point at most you must be able to restore clean copies of everything from backups fast enough to prevent further damage. There is no defense, and all possible messing around with firewalls won't help a single bit if any -- ANY -- means of communications are open.
The good news is, this is what others are supposed to take care of, so you, a sysadmin, must not waste your time by trying to do the impossible, fighting ghosts and spreading a paranoia within the company, but spend it defending against real threats that no one but you is supposed to defend against.
How ssh (port 22) is any different from anything else? If connection outside can be established, no matter through what, even if through HTTP proxy, it can be used for forwarding. Period. By people, software, whatever else, so to avoid starting cat and mouse game, it's better not to mess with someone's ability to establish connection outside.
If you don't trust your employees to not undermine security, why would you trust them their job at all? They can do more rarm by plain sabotage of whatever they are doing than by any stupid port forwarding. Of course, there are all kinds of viruses/worms/etc. that will be more than happy to exploit any enabled protocol (and will succeed given that at least something works), but this returns to the basics -- system won't be secure if people who use it can run things of dubious origin. If your users run outlook and click on every attachment, be prepared that connection from their box is as untrustworthy as a connection from outside, it's that simple.
It's known as ISO2022. It's been around forever, and no one's stopping you from using it. It's used for COMPOUND_TEXT in X and MULE in Emacs. Most people don't like it because it's a state-heavy system. No one killed it by backroom poltics - it just didn't go over very well.
ISO 2022 is completely unacceptable for any practical use in multilingual environment -- it is used only to manage small set of charsets for display-only purpose.
The real solution won't appear until it will become easy to just place attributes that include language and charset by their full names in the text, so some simple interface (one to a program, not to a user) can be used to handle pieces of text accordingly to their attributes, and charset will be just one of them. By "handle" I mean everything that programs do with text -- sort, concatenate, input from a user, edit, format/hyphenate/..., fuzzy/phonetic match, and last and very, very least -- render with given set of fonts on a given device.
what i meant was is several friends of mine when i was in uni had japanese-character keyboards. they had some weird drivers just to write asci at all.
It's just the opposite. Japanese keyboards all support ASCII, and need special software to be able to enter Japanese characters. Your friends probably had Japanese DOS on their computers, and had problems running English DOS software because of incompatibilities.
Well, if your device "can't even fit Unicode font into their memory", then you (as you say later) cut the fonts into manageable subsets.
But which subset should one support in any given situation? And what is the benefit of Unicode then compared to text that just has charsets and language names embedded as state? I mean, other than having to look up symbols in translation table, 1.5-4 times larger text files and incompatibility with perfectly usable systems that already work with local charsets and can be easily modified to use multiple charsets if someone was able to standardize the metadata formats (by not being gagged by "Unicoders" every time when a suggestion of that kind is made in standard bodies)?
Character set, character encoding, and fonts are three separate issues. The reason why folks like UTF-8 so much is because it is easy to use. The software I code on used to support multiple character sets (European and CJK) internally. Now, we convert to UTF-8 on the way in and convert back to the desired character set on the way out. Our code is cleaner, smaller, easier to understand, and easier to debug.
Precisely because all work on standards, formats and libraries that would do it for the programmers is stopped to benefit "Unicoders" who taken over the standardization process.
Supporting multiple character sets per document is a mess and completely unnecessary for most real world applications.
If "real world applications" == "pretty display of text", you would be right, however Unicode loses all distinctions between languages used in the text, thus making impossible to do any complex processing that must know the language. So sooner or later applications will have to include the name of language used, or face the conversion of large amount of useful data into unprocessable junk, that is just as useful as, say, gif with text in them. Unicoders, of course, already declared a standard for adding language information back into Unicode text, and "allowed" to use language attribute in XML. However it's obvious that all Unicode-using code can't deal with stateful text stream (text + language as state) because the whole point of Unicode was to avoid any state, and XML processing programs have no requirement to preserve attributes i their internal processing, thus making the whole activity impractical.
Unicode in itself is an attempt to make completely artificial, huge charset mandatory for everything to support, including devices that can't even fit Unicode font into their memory. There were some attempts to support multiple charsets in the same text, thus avoiding this requirements, however some backroom politics caused them to be stopped, and now IETF's "official policy" is to demand Unicode and UTF-8, encodings that no one but a bunch of self-proclaimed unificators support.
Most of Unicode-should-replace-everything support emanates from people who use ISO 8859-1 encoding, that happens to be exactly the same as first 255 characters of Unicode, so they don't have to modify anything in non-trivial manner, and can just cut their fonts to fit them everywhere.
And last but not least, I have yet to see a pro-Unicode document that was not being actively pushed by someone Martin Duerst, who seems to be made a career from coming to every internationalization-related group or mailing lists to spew Unicode propaganda until all his opponents will get exhausted rebutting it.
My keyboard at home is cyrillic, with russian input configured, all other keyboards that I use, including the notebook, I am posting this from, are ASCII-only, and my native language is Russian for crying out loud.
I know, how fast it runs. I wrote an HTTP server, and in its early versions file-sender was a constantly restarting CGI-like process, like in FTP. Performance significantly increased when I have switched to process pool model, so I have added module interface that allows modules to have their own process pools when necessary, isolating modules from each other.
As a module, of course -- either Apache (native or through or fastcgi) or my fhttpd (that I wrote with protocol that looks a bit similar to fastcgi, but allows more complex processing models).
There is no "economics" involved -- running a free service is CHEAP if you have anything else on a colocated server at some ISP. If it isn't cheap for you, look for someone for whom it is, and very likely he will do that.
the first thing I have heard people ask about non Palm brand handhelds is "Will is run the same programs?"
Having different CPU, Jornada, even if it will run PalmOS, won't run Palm 68K binaries without an emulator. However 68K+Palm hardware emulator that the user can run PalmOS under, already runs on a shitload of OSes.
I think, most of people didn't exactly "get it", why adding a "standard" for unknown "generic" function can be a significant step to organization of CPRM schemes behind the scenes, so I will try to explain it. The "real" standards usually are pretty restrictive about what can be added to the protocol while it's still considered to be compliant. Say, if something claims that it talks SMTP, it can't demand that before "HELO" a client must send a credit card number, or the system won't work -- even if someone will make such a thing, no other SMTP client will work with that, and that system will be declared to be just as nonstandard as if it talked, say, one of internal Microsoft Exchange protocols. In some situations protocols allow extensions to be made in some backward-compatible way -- depending on the purpose of the protocol they may be allowed or not allowed, and if they are allowed, usually there is a requirement that all systems that support extensions MUST ("MUST" in capitals because it's used in the meaning, the word has in the standards texts) support the original protocol to avoid any kind of incompatibility. That was usually the rule when/where ptotocol standards were created to facilitate communication (say, first thousand-something RFCs) and not to be the base for "compatibility wars" (say, what ITU does).
Then large number of extremely vague and easily extensible "umbrella" standards appeared -- they usually involved some "wrapper" that can be easily pulled over anything, no matter how undocumented, proprietary or simply convoluted. Bright example is XML. The standard itself is very simple -- it defines how one can format the data, and, if the need will arise, how to make something that will allow to verify if there is a formatting error. What data is there, how it should be processed, what standards handle that, and who control those standards, is left to the "user". In some places it was justified -- one may want to use some standardized parser to save the trouble of using lex and yacc, so yes, there is a reason for this "umbrella" (I should add, weak reason because standard is awfully inefficient, and "poisoned" by overbroad requirements where they don't belong). But look, how it is used. Someone needs a "standard" for his data. He makes XML schema or DTD (and maybe publishes it), and some internal description, what the data means (and usually doesn't disclose it completely, leaves himself a "freedom" to change the semantics of the data, or simply writes that part in some ambiguous, illiterate way). Now he claims that he is using "open", "standardized" XML -- and indeed, with all its shortcomings, XML standard is defined in a very strict manner. More, DTD or schema very strictly defines, how to "verify" the format (but not the semantics of the data). But since XML is a "wrapper", and true format that he uses is defined in his internal or incomplete document about his internal semantics, all kinds of dirty tricks are possible. Developer can at will add, remove and change various rules and functionality that applies to semantics of the data (and more likely it will just happens because of his implementation's bugs -- there is no way to formally verify it), and different implementations, made by people who read XML standard, DTD or schema, and incomplete/confusing published part of semantics description, won't interoperate with "the original". Or different versions of implementation can appear, and while old and new versions all satisfy the standard, new version will stop interoperate with others' implementations, or will secretly get some new, harmful functionality. All that will be hidden from others because they know how wrapper works, but don't know, what mechanism is actually handling the data, and what is the true, complete definition of the semantics of the data.
This is the example how usually good feature of the standard -- extensibility -- can be counterproductive or even serve some sinister purpose. ATA standard is very strict. One can't easily add some completely unrelated functionality and claim that he is still compliant. So if someone will try to add a command for keys handling, he will make something other than ATA device, and no one in his right mind will place that thing where ATA hard drive is supposed to be. If the standard body will just extend the standard openly and say "This is a new command for copy protection, and now this is the new standard that includes it", it will be obvious that standard body is performing a sabotage of the standard that it is supposed to improve, and a lot of people will just vote against it. So the next best (or worst -- depending from the point of view) thing is to add the ability to extend the standard behind the scenes. Someone uses a "generic" command to control the disk rotation speed for power-saving reasons? Fine! Someone uses the command to erase all the data using some special eraser coil, to make it impossible to recover a disk that contained very sensitive data? Fine! Someone uses it to implement copy protection? Fine, too -- the standard says that the purpose and functionality is completely under vendor's control, and standard body isn't handling this.
Of course, the next step will be the creation of another "standard body" -- with closed membership, with only "interested parties" involved. And that body won't be responsible to anyone, it won't have to publish anything, and there will be nothing to prevent that body from issuing another standard -- how "generic" interface should be used for, you guessed, copy protection. Because whatever they will do, will be still compliant with the standard, accepted by the "public" standard body. Then they can publish copy-protection standard openly or keep it closed, patent it or keep it dangling in the air "trade secret", tie themselves by contracts or expect each other to support it willingly -- the end result will be that the next generation of ATA devices made by large companies will have copy protection implemented. And "public" standard body will have a heck of a problem reversing the loophole, once companies tasted the blood of imprisoned data.
I fall into the latter category. We don't know for certain if there's a God... and maybe that's how it should be. But what will happen to these clones if we discover that science can't regenerate a soul?
This is a very far-fetched assumption, not based on anything at all but a blind faith in a certain religion, and possibly on a misunderstanding of the whole process of cloning (if someone still doesn't know, a clone is merely conceived in an artificially modified process to have an exact copy of some set of genes, and then develops as an embryo, born and develops after that like any other living being, clone does not appears in a flash as a fully developed adult).
It's the same old argument as "why don't you believe in my god, imagine what would happen to you if he does exist?" The answer is, obviously, "what if you are wrong, and some god exists that considers this your behavior just as immoral and deserving punishment as your god supposedly considers non-believing?". In this case the answer is of the same kind -- even if god exists, there is no way to know his "opinion" on this, and "sacred" books of some particular religion aren't in any way reliable source for anyone who doesn't believe in them. I can certainly accept if Christians will decide not to participate in anything related to cloning, but if they want to tell everyone else what they should or should not do, they MUST use arguments from commonly accepted system such as scientific knowledge.
I'm forced sometimes by clients to make sure that nothing goes past a certain limit (since they believe their own clients are on PDA, 640x480 monitors, etc.)
Then they have no freaking idea, what they are talking about. Unless you DEFINE a fixed-size table, or make non-breakable piece of text that won't fit otherwise, any browser will do its best to display it without horizontal scrolling, but once you define it, browser will stop trying to do that, and will honor your limit, no matter how impossible it is.
With PDAs they are even more wrong -- Browse-it (formerly Proxiweb -- the only decent browser for PDAs that exists now) it either displays tables like they are supposed to be displayed (usually horizontally-scrollable on Palm because Palm has a small screen) or allows user to "unroll" them and place everything sequentially, but fit without horizontal scrolling. Slashdot, even its normal version, fits fine in "unrolled" mode, and is readable in normal mode, however your 600 pixels limit will do absolutely nothing for any PDA with this browser -- browser knows that it can't fit that table with any readable fonts anyway, and will have to ignore the limit.
Nevertheless, they do NOT have a license from the DVD CCA, so therefore, it's illegal.
DVD CCA doesn't have a right to license it in the first place -- neither algorithm, nor keys are protected under any law, they are merely trade secrets, so as long as they were not published by people who had access to them, everyone is free to discover what they are and do with them whatever they want.
DVD CCA can license their software that implements the encryption/decryption algorithms, however no one needs it now anyway, as long as algorithm was reverse-engineered, so DVD CCA can stuff everything they can license into their collective ass.
It is necessary to name executable "ssh" to make it compatible with scripts and other programs that intend to use the functionality of SSH protocol, so, trademarked or not, the reason to name executable "ssh" is not to create confusion but to provide actual functionality in a compatible manner. The name OpenSSH both reflects the functionality (open implementation of SSH protocol) and provides enough distinction to avoid confusion as much as possible.
The fact that OpenSSH is a superior product is pretty much irrelevant to the issue, however it explains why OpenSSH is more popular then the original SSH now -- certainly users chosen it because they expected that it will work better and because of more liberal license, not because they thought that they are installing the original SSH.
See my previous comment about what they did to peer to peer communications and starmode. I actually have two Ricochet GS modems that still have it enabled, however I have no idea how to convince Metricom to enable it on anything sold later, including my new Novatel Merlin for Ricochet that I hoped that I could switch to from one of older GS.
Metricom started disabling modem to modem communication in their network for devices registered after December 23 2000, so while devices bought/registered earlier can use starmode over the network of retransmitters (I had no problems talking from NY to San Francisco without touching WWC's router that was down at the moment), others can do that only in close proximity when they "hear" each other (usually few hundreds of feet in a city). This makes just as limited range as anything 802.11 with the same type of antenna, but 10 times more latency and 20-80 times slower, so there isn't much point of using starmode if retransmitters refuse to work with it.
And yes, I am the same Alex Belits mentioned on that page -- I have just finished STRIP support for PCMCIA card (it has even longer numbers), however thanks to Metricom's infinite wisdom, all those devices only work with STRIP in proximity because they were sold after the registration configuration switch.
Slashdot Mirror
There is one huge problem with all this -- it's extremely hard to write any decent software for Windows platform, free or not. And it's even harder to keep it portable, especially if one hopes to use Wine/winelib or other such thing instead of full-blown native port (ex: WP 2000 vs. Opera 5.0 on Linux). One of problem with Mozilla is that too much of Windows-derived ideas were placed into it, causing unnecessary bloat. So there are reasons why there isn't much free software for Windows, and among those reasons idiosyncrasy or bigotry aren't even on the top of the list.
You are a Microsoft troll. Either MCSE that is trying to convince himself that he is not inferior to real sysadmions, or an astroturfer. What is your experience as "solaris admin" -- logging into a box as root, saying "rm -rf /" and loudly complaining about results?
...for sidewalk.com when it just appeared. No one was trying to make Bill Gates clean it though.
Revealing passwords of outside resources allows subversion of those outside resources by others, which can allow attacks back into your facilities. Finding an outside telnet, ftp, or web mail password allows tinkering with files which may be transferred into your corporate facilities.
Who said that they even use passwords? Maybe they use one-time passwords?
An employee might trust the attachments on saved email from a trusted source, not realizing that someone has altered them.
There is much more to the security of other users' accounts than encryption. In fact, it's extremely unlikely that potential intruder is sitting at mae-west examining the packets from your network, in the hope that he will intercept some of your users' unencrypted password to some external account, so he will plant some file there, so user will transfer it to his box at work, run it, and that will compromise your network. Intruders don't think that way. At best, if they will bother to plant some modified files on the user's account outside, they will find a security flaw that will allow them to access user's insecure account outside, and then it will make absolutely no difference, how user will access it -- over ssh or ftp. In any case, port filtering at work will not prevent user from using telnet from home, and it's more likely that his connection will be intercepted there because of poor configuration of bridges and switches at his ISP, thus making the whole effort a moot point.
At most, banning all outside connections but ssh will make a lot of users who have outside accounts without ssh support ssh to some box outside, then run telnet to non-ssh-supporting account. Security gained: 0, waste of time: 15 seconds per connection (to type a password), 100ms per packet (latency between outside accounts).
It doesn't matter if the weak link is outside or inside your corporate LAN.
You can't eliminate any insecure stuff outside, except the most unlikely way for intruder to make his, very indirect, attack. And there are thousands of ways to send a file to someone, pretending that it comes from his own account. You can't control that, and you shouldn't for a second imagine that you can -- even if you can decrease the probability of such attack by 0.1%. Instead you have to create a reasonable policy in the place where it matters -- never transfer anything executable from outside, period. If users can't avoid opening attachments in outlook -- ban outlook, make mail server strip all non-text attachments, do something else useful, but it's important that policy should be directed against real dangers instead of creating imaginary protection for accounts, you can't control.
How ssh (port 22) is any different from anything else? If connection outside can be established, no matter through what, even if through HTTP proxy, it can be used for forwarding.
Certainly. However, ssh *is* a secure form of shell communication. Telnet isnt. The fact that it can be used for other things is really besides the point.
What users are doing connecting _outside_ from inside, changes nothing. Telnet may be insecure, but who said that users are accessing something that requires security in the first place? It's outside! I access slashdot without any possibility of hiding my password when I log in, and I have no way to verify any signatures, yet it's perfectly acceptable because my authentication here is not important for security. OTOH, what users doing by connecting _from outside_ is always important -- at very least the passwords they use must be protected. However even that may not be necessarily as important as sysadmin logging in -- user may use one-time password and never transfer anything sensitive unencrypted (but FTPing of encrypted files is ok). This, of course, requires users that ACTIVELY support security, so most of people in the company simply aren't qualified to make the distinction, what they can or can't do over one-time authenticated but unencrypted link, so restricting them to inbound ssh is reasonable.
The rest of your post is essentially a big "Why bother with security at all, just trust your users" speech.
Not at all. I only mean "don't protect your network against malicious users". And this is absolutely reasonable because users ALWAYS have more opportunities to cause harm to the company without talking to anything outside the network, compared to anything that they can do with it.
While thats nice, when you are in charge of protecting corporate data that is mission critical, and users that dont know what right-clicking is, you will have a different grasp of things.
If the users are not malicious but merely incompetent, harm from them will not be decreased in any way by messing up their connections to the outside world -- after all, Melissa distributes itself using plain mail, and there is no reason to believe that anything else harmful won't do exactly the same. Better results can be done by banning users from installing any software on their boxes without a technician involves, and, if the OS allows, enforcing it in the configuration. And even without that, banning Outlook goes a long way to stop whatever malicious stuff may arrive -- it certainly will allow to avoid more trouble than any imaginable restriction to outgoing connections.
The job requirements dont say get touchy-feely and trust our users, they say keep the bad guys ( including employees) out, or you are out of a job.
I don't care, what your "job requirements" are -- if "bad guys" are already among employees, you MUST GIVE UP trying to thwart them because you have already lost -- at that point at most you must be able to restore clean copies of everything from backups fast enough to prevent further damage. There is no defense, and all possible messing around with firewalls won't help a single bit if any -- ANY -- means of communications are open.
The good news is, this is what others are supposed to take care of, so you, a sysadmin, must not waste your time by trying to do the impossible, fighting ghosts and spreading a paranoia within the company, but spend it defending against real threats that no one but you is supposed to defend against.
How ssh (port 22) is any different from anything else? If connection outside can be established, no matter through what, even if through HTTP proxy, it can be used for forwarding. Period. By people, software, whatever else, so to avoid starting cat and mouse game, it's better not to mess with someone's ability to establish connection outside.
If you don't trust your employees to not undermine security, why would you trust them their job at all? They can do more rarm by plain sabotage of whatever they are doing than by any stupid port forwarding. Of course, there are all kinds of viruses/worms/etc. that will be more than happy to exploit any enabled protocol (and will succeed given that at least something works), but this returns to the basics -- system won't be secure if people who use it can run things of dubious origin. If your users run outlook and click on every attachment, be prepared that connection from their box is as untrustworthy as a connection from outside, it's that simple.
It's known as ISO2022. It's been around forever, and no one's stopping you from using it. It's used for COMPOUND_TEXT in X and MULE in Emacs. Most people don't like it because it's a state-heavy system. No one killed it by backroom poltics - it just didn't go over very well.
ISO 2022 is completely unacceptable for any practical use in multilingual environment -- it is used only to manage small set of charsets for display-only purpose.
The real solution won't appear until it will become easy to just place attributes that include language and charset by their full names in the text, so some simple interface (one to a program, not to a user) can be used to handle pieces of text accordingly to their attributes, and charset will be just one of them. By "handle" I mean everything that programs do with text -- sort, concatenate, input from a user, edit, format/hyphenate/..., fuzzy/phonetic match, and last and very, very least -- render with given set of fonts on a given device.
what i meant was is several friends of mine when i was in uni had japanese-character keyboards. they had some weird drivers just to write asci at all.
It's just the opposite. Japanese keyboards all support ASCII, and need special software to be able to enter Japanese characters. Your friends probably had Japanese DOS on their computers, and had problems running English DOS software because of incompatibilities.Well, if your device "can't even fit Unicode font into their memory", then you (as you say later) cut the fonts into manageable subsets.
But which subset should one support in any given situation? And what is the benefit of Unicode then compared to text that just has charsets and language names embedded as state? I mean, other than having to look up symbols in translation table, 1.5-4 times larger text files and incompatibility with perfectly usable systems that already work with local charsets and can be easily modified to use multiple charsets if someone was able to standardize the metadata formats (by not being gagged by "Unicoders" every time when a suggestion of that kind is made in standard bodies)?
Character set, character encoding, and fonts are three separate issues. The reason why folks like UTF-8 so much is because it is easy to use. The software I code on used to support multiple character sets (European and CJK) internally. Now, we convert to UTF-8 on the way in and convert back to the desired character set on the way out. Our code is cleaner, smaller, easier to understand, and easier to debug.
Precisely because all work on standards, formats and libraries that would do it for the programmers is stopped to benefit "Unicoders" who taken over the standardization process.
Supporting multiple character sets per document is a mess and completely unnecessary for most real world applications.
If "real world applications" == "pretty display of text", you would be right, however Unicode loses all distinctions between languages used in the text, thus making impossible to do any complex processing that must know the language. So sooner or later applications will have to include the name of language used, or face the conversion of large amount of useful data into unprocessable junk, that is just as useful as, say, gif with text in them. Unicoders, of course, already declared a standard for adding language information back into Unicode text, and "allowed" to use language attribute in XML. However it's obvious that all Unicode-using code can't deal with stateful text stream (text + language as state) because the whole point of Unicode was to avoid any state, and XML processing programs have no requirement to preserve attributes i their internal processing, thus making the whole activity impractical.
Unicode in itself is an attempt to make completely artificial, huge charset mandatory for everything to support, including devices that can't even fit Unicode font into their memory. There were some attempts to support multiple charsets in the same text, thus avoiding this requirements, however some backroom politics caused them to be stopped, and now IETF's "official policy" is to demand Unicode and UTF-8, encodings that no one but a bunch of self-proclaimed unificators support. Most of Unicode-should-replace-everything support emanates from people who use ISO 8859-1 encoding, that happens to be exactly the same as first 255 characters of Unicode, so they don't have to modify anything in non-trivial manner, and can just cut their fonts to fit them everywhere. And last but not least, I have yet to see a pro-Unicode document that was not being actively pushed by someone Martin Duerst, who seems to be made a career from coming to every internationalization-related group or mailing lists to spew Unicode propaganda until all his opponents will get exhausted rebutting it.
My keyboard at home is cyrillic, with russian input configured, all other keyboards that I use, including the notebook, I am posting this from, are ASCII-only, and my native language is Russian for crying out loud.
Domain names that can't be entered from a keyboard by everyone in the world are a bad idea anyway -- no one but spammers would want such a thing.
I know, how fast it runs. I wrote an HTTP server, and in its early versions file-sender was a constantly restarting CGI-like process, like in FTP. Performance significantly increased when I have switched to process pool model, so I have added module interface that allows modules to have their own process pools when necessary, isolating modules from each other.
As a module, of course -- either Apache (native or through or fastcgi) or my fhttpd (that I wrote with protocol that looks a bit similar to fastcgi, but allows more complex processing models).
There is no "economics" involved -- running a free service is CHEAP if you have anything else on a colocated server at some ISP. If it isn't cheap for you, look for someone for whom it is, and very likely he will do that.
the first thing I have heard people ask about non Palm brand handhelds is "Will is run the same programs?"
Having different CPU, Jornada, even if it will run PalmOS, won't run Palm 68K binaries without an emulator. However 68K+Palm hardware emulator that the user can run PalmOS under, already runs on a shitload of OSes.
I think, most of people didn't exactly "get it", why adding a "standard" for unknown "generic" function can be a significant step to organization of CPRM schemes behind the scenes, so I will try to explain it. The "real" standards usually are pretty restrictive about what can be added to the protocol while it's still considered to be compliant. Say, if something claims that it talks SMTP, it can't demand that before "HELO" a client must send a credit card number, or the system won't work -- even if someone will make such a thing, no other SMTP client will work with that, and that system will be declared to be just as nonstandard as if it talked, say, one of internal Microsoft Exchange protocols. In some situations protocols allow extensions to be made in some backward-compatible way -- depending on the purpose of the protocol they may be allowed or not allowed, and if they are allowed, usually there is a requirement that all systems that support extensions MUST ("MUST" in capitals because it's used in the meaning, the word has in the standards texts) support the original protocol to avoid any kind of incompatibility. That was usually the rule when/where ptotocol standards were created to facilitate communication (say, first thousand-something RFCs) and not to be the base for "compatibility wars" (say, what ITU does).
Then large number of extremely vague and easily extensible "umbrella" standards appeared -- they usually involved some "wrapper" that can be easily pulled over anything, no matter how undocumented, proprietary or simply convoluted. Bright example is XML. The standard itself is very simple -- it defines how one can format the data, and, if the need will arise, how to make something that will allow to verify if there is a formatting error. What data is there, how it should be processed, what standards handle that, and who control those standards, is left to the "user". In some places it was justified -- one may want to use some standardized parser to save the trouble of using lex and yacc, so yes, there is a reason for this "umbrella" (I should add, weak reason because standard is awfully inefficient, and "poisoned" by overbroad requirements where they don't belong). But look, how it is used. Someone needs a "standard" for his data. He makes XML schema or DTD (and maybe publishes it), and some internal description, what the data means (and usually doesn't disclose it completely, leaves himself a "freedom" to change the semantics of the data, or simply writes that part in some ambiguous, illiterate way). Now he claims that he is using "open", "standardized" XML -- and indeed, with all its shortcomings, XML standard is defined in a very strict manner. More, DTD or schema very strictly defines, how to "verify" the format (but not the semantics of the data). But since XML is a "wrapper", and true format that he uses is defined in his internal or incomplete document about his internal semantics, all kinds of dirty tricks are possible. Developer can at will add, remove and change various rules and functionality that applies to semantics of the data (and more likely it will just happens because of his implementation's bugs -- there is no way to formally verify it), and different implementations, made by people who read XML standard, DTD or schema, and incomplete/confusing published part of semantics description, won't interoperate with "the original". Or different versions of implementation can appear, and while old and new versions all satisfy the standard, new version will stop interoperate with others' implementations, or will secretly get some new, harmful functionality. All that will be hidden from others because they know how wrapper works, but don't know, what mechanism is actually handling the data, and what is the true, complete definition of the semantics of the data.
This is the example how usually good feature of the standard -- extensibility -- can be counterproductive or even serve some sinister purpose. ATA standard is very strict. One can't easily add some completely unrelated functionality and claim that he is still compliant. So if someone will try to add a command for keys handling, he will make something other than ATA device, and no one in his right mind will place that thing where ATA hard drive is supposed to be. If the standard body will just extend the standard openly and say "This is a new command for copy protection, and now this is the new standard that includes it", it will be obvious that standard body is performing a sabotage of the standard that it is supposed to improve, and a lot of people will just vote against it. So the next best (or worst -- depending from the point of view) thing is to add the ability to extend the standard behind the scenes. Someone uses a "generic" command to control the disk rotation speed for power-saving reasons? Fine! Someone uses the command to erase all the data using some special eraser coil, to make it impossible to recover a disk that contained very sensitive data? Fine! Someone uses it to implement copy protection? Fine, too -- the standard says that the purpose and functionality is completely under vendor's control, and standard body isn't handling this.
Of course, the next step will be the creation of another "standard body" -- with closed membership, with only "interested parties" involved. And that body won't be responsible to anyone, it won't have to publish anything, and there will be nothing to prevent that body from issuing another standard -- how "generic" interface should be used for, you guessed, copy protection. Because whatever they will do, will be still compliant with the standard, accepted by the "public" standard body. Then they can publish copy-protection standard openly or keep it closed, patent it or keep it dangling in the air "trade secret", tie themselves by contracts or expect each other to support it willingly -- the end result will be that the next generation of ATA devices made by large companies will have copy protection implemented. And "public" standard body will have a heck of a problem reversing the loophole, once companies tasted the blood of imprisoned data.
"The" is a trademark of The Linguistic Troublemaking Company.
I fall into the latter category. We don't know for certain if there's a God... and maybe that's how it should be. But what will happen to these clones if we discover that science can't regenerate a soul?
This is a very far-fetched assumption, not based on anything at all but a blind faith in a certain religion, and possibly on a misunderstanding of the whole process of cloning (if someone still doesn't know, a clone is merely conceived in an artificially modified process to have an exact copy of some set of genes, and then develops as an embryo, born and develops after that like any other living being, clone does not appears in a flash as a fully developed adult).
It's the same old argument as "why don't you believe in my god, imagine what would happen to you if he does exist?" The answer is, obviously, "what if you are wrong, and some god exists that considers this your behavior just as immoral and deserving punishment as your god supposedly considers non-believing?". In this case the answer is of the same kind -- even if god exists, there is no way to know his "opinion" on this, and "sacred" books of some particular religion aren't in any way reliable source for anyone who doesn't believe in them. I can certainly accept if Christians will decide not to participate in anything related to cloning, but if they want to tell everyone else what they should or should not do, they MUST use arguments from commonly accepted system such as scientific knowledge.
I'm forced sometimes by clients to make sure that nothing goes past a certain limit (since they believe their own clients are on PDA, 640x480 monitors, etc.)
Then they have no freaking idea, what they are talking about. Unless you DEFINE a fixed-size table, or make non-breakable piece of text that won't fit otherwise, any browser will do its best to display it without horizontal scrolling, but once you define it, browser will stop trying to do that, and will honor your limit, no matter how impossible it is.
With PDAs they are even more wrong -- Browse-it (formerly Proxiweb -- the only decent browser for PDAs that exists now) it either displays tables like they are supposed to be displayed (usually horizontally-scrollable on Palm because Palm has a small screen) or allows user to "unroll" them and place everything sequentially, but fit without horizontal scrolling. Slashdot, even its normal version, fits fine in "unrolled" mode, and is readable in normal mode, however your 600 pixels limit will do absolutely nothing for any PDA with this browser -- browser knows that it can't fit that table with any readable fonts anyway, and will have to ignore the limit.
Nevertheless, they do NOT have a license from the DVD CCA, so therefore, it's illegal.
DVD CCA doesn't have a right to license it in the first place -- neither algorithm, nor keys are protected under any law, they are merely trade secrets, so as long as they were not published by people who had access to them, everyone is free to discover what they are and do with them whatever they want.
DVD CCA can license their software that implements the encryption/decryption algorithms, however no one needs it now anyway, as long as algorithm was reverse-engineered, so DVD CCA can stuff everything they can license into their collective ass.
It is necessary to name executable "ssh" to make it compatible with scripts and other programs that intend to use the functionality of SSH protocol, so, trademarked or not, the reason to name executable "ssh" is not to create confusion but to provide actual functionality in a compatible manner. The name OpenSSH both reflects the functionality (open implementation of SSH protocol) and provides enough distinction to avoid confusion as much as possible.
The fact that OpenSSH is a superior product is pretty much irrelevant to the issue, however it explains why OpenSSH is more popular then the original SSH now -- certainly users chosen it because they expected that it will work better and because of more liberal license, not because they thought that they are installing the original SSH.
See my previous comment about what they did to peer to peer communications and starmode. I actually have two Ricochet GS modems that still have it enabled, however I have no idea how to convince Metricom to enable it on anything sold later, including my new Novatel Merlin for Ricochet that I hoped that I could switch to from one of older GS.
Metricom started disabling modem to modem communication in their network for devices registered after December 23 2000, so while devices bought/registered earlier can use starmode over the network of retransmitters (I had no problems talking from NY to San Francisco without touching WWC's router that was down at the moment), others can do that only in close proximity when they "hear" each other (usually few hundreds of feet in a city). This makes just as limited range as anything 802.11 with the same type of antenna, but 10 times more latency and 20-80 times slower, so there isn't much point of using starmode if retransmitters refuse to work with it.
And yes, I am the same Alex Belits mentioned on that page -- I have just finished STRIP support for PCMCIA card (it has even longer numbers), however thanks to Metricom's infinite wisdom, all those devices only work with STRIP in proximity because they were sold after the registration configuration switch.