Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xterm(1) now UTF-8 by default on OpenBSD

undeadly.org

Post reply on HN
Print view View original

71–80 of 144 posts

Re: Xterm(1) now UTF-8 by default on OpenBSD

#71

Post by digi_owl »

notalaser wrote: post #69
kazinator wrote: post #25

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…

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.

Re: Xterm(1) now UTF-8 by default on OpenBSD

#72

Post by plugnburn »

Tiksi wrote: post #70
plugnburn wrote: post #57

UTF-8 must be the default and only encoding. Why does anything else still exist?

ANSI must be the default and only encoding. Why does anything else still exist?

Because, you see, not everyone in the world uses Latin characters. UTF-8 must become a new standard instead of that whole obsolete encoding zoo.

Re: Xterm(1) now UTF-8 by default on OpenBSD

#73

Post by Tiksi »

plugnburn wrote: post #72
Tiksi wrote: post #70

Earlier quoted context omitted.

ANSI must be the default and only encoding. Why does anything else still exist?

Because, you see, not everyone in the world uses Latin characters. UTF-8 must become a new standard instead of that whole obsolete encoding zoo.

And in 20-30 years we'll likely be saying the same about UTF-8.

I figured that "ANSI" would give away that I wasn't being serious since it's not actually an encoding.

Re: Xterm(1) now UTF-8 by default on OpenBSD

#74

Post by tempodox »

thisrod wrote: post #21

This reminded me of a Rob Pike comment. I can't find the text, but it was along the lines of, "I recently tried Linux. It was as if every bug I fixed in the 1980s had reverted."

Last I checked, a call to fgetwc(3) on Linux crashes as soon as I actually enter a non-ASCII character, with a locale of en_US.UTF-8.

Re: Xterm(1) now UTF-8 by default on OpenBSD

#76

Post by kiiski »

SixSigma wrote: post #37
cokernel_hacker wrote: post #28

Earlier quoted context omitted.

I don't think Rob meant stability. Rob was probably referring to the reality that modern Linux hasn't innovated itself past SVR4 by any appreciable amount. We are still using X, still using terminals powered by control codes, etc. Rob probably sees things like LANG and LC_ALL as bugs. His fix was UTF-8 everywhere, always. Where is Linux? Still in bag-of-bytes-o-rama.

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 !!!!

Personally I like doing text-only work (such as programming) in a TTY with Emacs. I'd like to have a machine with no X at all, but unfortunately there aren't many good framebuffer-friendly graphical tools (fbi is good for viewing images, but doesn't support gifs; vlc is ok for playing videos, but the ncurses UI is too buggy; most modern websites are barely usable with links2, while netsurf is too mouse-oriented for my tastes).

Re: Xterm(1) now UTF-8 by default on OpenBSD

#77

Post by plugnburn »

Tiksi wrote: post #73
plugnburn wrote: post #72

Earlier quoted context omitted.

Because, you see, not everyone in the world uses Latin characters. UTF-8 must become a new standard instead of that whole obsolete encoding zoo.

And in 20-30 years we'll likely be saying the same about UTF-8. I figured that "ANSI" would give away that I wasn't being serious since it's not actually an encoding.

> And in 20-30 years we'll likely be saying the same about UTF-8.

Well... If we will, why not? But the thing is that in 20-30 years we won't be able to invent any new writing systems that UTF-8 won't cover. Single-byte encodings were doomed because of their single-byteness. The same awaits two-byte encodings like UCS-2 (aka UTF-16BE) - we already have extended code points for something that glamour hipsters call "emoji". Variable-byte encoding will never become obsolete.

Re: Xterm(1) now UTF-8 by default on OpenBSD

#78

Post by plugnburn »

tempodox wrote: post #75
jmnicolas wrote: post #62

Earlier quoted context omitted.

Yes but UTF-8 with or without byte order mark ? ;-)

How do you have a BOM in the shell?

Some masochist M$-fan could invent even this just in order to justify the difference from civilized world.

Re: Xterm(1) now UTF-8 by default on OpenBSD

#79

Post by lozf »

igravious wrote: post #9
msbarnett wrote: post #7

Earlier quoted context omitted.

Also on OS X, † is option-t, and ‡ is option-shift-7.

Ok, On Linux I have found ‡ and † † is AltGr-Shift-%, and ‡ AltGr-Shift-: I'll never remember them :(

U+2020 (†) and U+2021 (‡) aren't that hard to remember for the sake of a few extra key-presses and wider compatibility.

Re: Xterm(1) now UTF-8 by default on OpenBSD

#80

Post by alkonaut »

pilif wrote: post #39
cokernel_hacker wrote: post #28

Earlier quoted context omitted.

I don't think Rob meant stability. Rob was probably referring to the reality that modern Linux hasn't innovated itself past SVR4 by any appreciable amount. We are still using X, still using terminals powered by control codes, etc. Rob probably sees things like LANG and LC_ALL as bugs. His fix was UTF-8 everywhere, always. Where is Linux? Still in bag-of-bytes-o-rama.

>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 and datetime?

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? Or is the linux locale system simply using these as keys, so in reality there is no difference in LC_TIME whether you use encA or encB, it will only use the locale prefix en_GB?

Post reply on HN