81–90 of 144 posts
Earlier quoted context omitted.
checkout the different implementations of echo across various operating systems: " https://gist.github.com/dchest/1091803" .
That link is not working for me, Github is throwing a 404.
Earlier quoted context omitted.
>Rob probably sees things like LANG and LC_ALL as bugs. His fix was UTF-8 everywhere, always The problems solved by LANG or LC_ALL are not solved by UTF8 alone. Even if you use UTF8 for all your input and output, there is still the question of how to format numbers and dates to the user and how to collate strings. These things are dependent on country and language, sometimes even varying between different places in a…
I still don't understand how encodings find their way into the localization. I understand that date/time/number formatting is localizable. Do not understand why "LC_TIME=en_GB.UTF-8" would be a different option from just "en_GB"? Can I really expect it to work if I set "LC_TIME=en_GB.encA" and "LC_MONETARY=en_GB.encB" How would the two encodings be used? How would they be used in a message consisting of both monetary…
Full month names would be encoded in encA. Currency symbols in encB. Is it a good idea? No.
>Should the setting not be one for encoding (selected from a range of encodings), then settings for formatting and messages (selected from ranges of locales), then finally a setting for collation which is both a locale and an encoding?
I would argue an encoding setting should not be there to begin with or at most be application specific because that really doesn't depend on system locale (as long as the signs used by the system locale can be represented in the encoding used by the application).
I was just explaining why LC_* should exist even on a strictly UTF-8 everywhere system. I never said storing the encoding in the locale was a good idea (nor is it part of the official locale specification - it's a posix-ism)
Earlier quoted context omitted.
> The maintainers of the free BSD's have been carrying that torch, but they don't believe in features. I used Linux for more than a decade before switching to OpenBSD precisely because Linux developers believe in features to the point where how well they're implemented is no longer relevant. The arrogant, know-it-all kids that we so lovingly nurtured in the Linux community grew up to be its forefront developers today…
The basic problem, as i see it, is that the Gnome/Freedesktop people got hold of the user space reins, and turned what used to be a kernel up development process into a desktop down development process.
I don't think it's a simple problem, and I don't think all the blame should be laid on Freedesktop.org, where a lot of good projects originated. I do think a lot could be solved by developers being a little more modest.
Earlier quoted context omitted.
>Rob probably sees things like LANG and LC_ALL as bugs. His fix was UTF-8 everywhere, always The problems solved by LANG or LC_ALL are not solved by UTF8 alone. Even if you use UTF8 for all your input and output, there is still the question of how to format numbers and dates to the user and how to collate strings. These things are dependent on country and language, sometimes even varying between different places in a…
Here in ex-USSR we have those problems too. Why not standardize decimal separators altogether worldwide? We're not dealing with feeking paper handwriting! If a number is printed on a computer display, it must look like 123456.78, not like "123 456,78"! Same goes for datetime representation. This localization BS has spawned an entire race of nonsense, where, for example, CSV files are not actually CSV in some regions,…
as we're talking encodings: The worst file I ever had to deal with combined, within one file, UTF-8, cp437 and cp850.
I guess they had DOS and Unix machines bot no Windows boxes touching that file.
This is a problem that won't go away. Many developers are not aware of how character encoding, let alone Unicode, actually works and, what's the worst about this mess, many times, they can get away without knowing.
Earlier quoted context omitted.
While it is only a few : Sydney Olympics lighting system was Plan9 based. Inferno was used by NASA JPL projects Lucent use a real time version of plan9 in phone masts Coraid use Plan9 on their NAS servers Researchers at LANL and IBM use plan9 on the Blue Gene, and other, supercomputers I have worked for two plan9 based companies - ok they didn't survive but we tried :) The international plan9 conferences drew about 3…
Lonely comment is lonely. Literally halfs of dozens of research projects and ones of promotional installations served! Nearly threes of dozens attended conferences, at which twos of booths were no doubt tabled, perhaps both by you, one of the only persons who apparently used Plan 9 commercially. I'm feeling nostalgic enough to go launch an inferno instance now just on principle.
Now I downvoted all your comments in this thread for they are unconstructive both in the negative and the positive directions. This is a fanboy-like attitude, where you ignore the fact I explained above, and attack other comments. You take quantity over quality.
BSDs and other systems have their user bases. Those may be small, but they exist. Both GNU/Linux and BSDs are inferior to the ideal system where most legacy cruft shall be gone, but in order to reach that ideal system we should develop the research projects, the ones with little-to-no use. E.g. Plan9. Or microkernels. The all-utf8 approach is perfect, but it can't easily propagate to the mainline if it is not tested for long in research projects, and the ecosystem adapts in this timeframe. So we'd rather not attack them, but let them happen. They'll always be better than mainline, but lesser-adopted, but when they die, the good parts of them will propagate to GNU/Linux, BSD, etc. Take ZFS for example, it was developed on a Sun system, it's not widely adopted, but its now on FreeBSD and Linux (i.e. btrfs, the same concept), for you to enjoy. Or the research in functional languages. Many of those are not adopted, but many features are now propagating to mainline languages.
Earlier quoted context omitted.
That was baseless posturing. A famous study and its follow-up found that the utilities on GNU/Linux are more robust, and that was twenty years ago: ftp://ftp.cs.wisc.edu/paradyn/technical_papers/fuzz-revisited.pdf [1995] " This study parallels our 1990 study (that tested only the basic UNIX utilities); all systems that we compared between 1990 and 1995 noticeably improved in reliability, but still had significant rat…
> The maintainers of the free BSD's have been carrying that torch, but they don't believe in features. I used Linux for more than a decade before switching to OpenBSD precisely because Linux developers believe in features to the point where how well they're implemented is no longer relevant. The arrogant, know-it-all kids that we so lovingly nurtured in the Linux community grew up to be its forefront developers today…
UTF-8 must be the default and only encoding. Why does anything else still exist?
Earlier quoted context omitted.
That and getting rid of the TTY altogether. We aren't using punched cards EDIT: people hate when I say this, which amuses me. The TTY must die !!!!
> The TTY must die!!!! Being sight-impaired, I have to disagree strongly! The TTY is the only thing that lets me adjust the font size of all programs running in it without going through lots of trouble. (BTW: didn't downvote your comment.)
I've been trying to teach myself some unicode code points because I'm getting sick and tired of continually Googling them and copying and pasting the result or bringing up a symbol character table. In fact, I'd say keyboards are woefully out to date. Specifically, I keep looking up † dagger (U+2020) and ‡ double-dagger (U+2021) for footnotes, black heart (U+2065) to be romantic, black star (U+2605) to talk about Davi…
Earlier quoted context omitted.
>Rob probably sees things like LANG and LC_ALL as bugs. His fix was UTF-8 everywhere, always The problems solved by LANG or LC_ALL are not solved by UTF8 alone. Even if you use UTF8 for all your input and output, there is still the question of how to format numbers and dates to the user and how to collate strings. These things are dependent on country and language, sometimes even varying between different places in a…
Here in ex-USSR we have those problems too. Why not standardize decimal separators altogether worldwide? We're not dealing with feeking paper handwriting! If a number is printed on a computer display, it must look like 123456.78, not like "123 456,78"! Same goes for datetime representation. This localization BS has spawned an entire race of nonsense, where, for example, CSV files are not actually CSV in some regions,…
See also paper sizes and electrical power outlets.