OpenBSD removes support for non-UTF8 locales • Hacker News Board

Re: OpenBSD removes support for non-UTF8 locales

#181

Post by kragen » Sun, Aug 16, 2015, 8:25 AM UTC

masklinn wrote: post #142

geofft wrote: post #134

Earlier quoted context omitted.

Is it really garbage? If we want to be true to UNIX's (questionable) "Write programs to handle text streams, because that is a universal interface" ethos, our definition of "text" has to admit all possible byte strings to be "universal". And the so-called C locale historically did.

> Is it really garbage? Invalid UTF-8 when valid UTF-8 was expected? Yes. > "Write programs to handle text streams, because that is a universal interface" ethos, our definition of "text" has to admit all possible byte strings to be "universal" Random bytes are not text. The Unix ethos is "communicate via arbitrary binary streams" but programs which only understand text understand text , not random-bytes-which-are-not…

Although it was pretty common up to the mid-1990s to run into 8-bit-cleanness problems and arbitrary buffer sizes, IMHO, the Unix ethos is not for `wc`, `tr`, `dd`, `sort`, `uniq`, `read`, `diff`, `patch`, or `split` to crash with certain input data, to silently corrupt that data, or to spew warning messages about its contents. They are building blocks for your programs; it is not their business to impose unnecessary expectations on your data. They can and should correctly handle arbitrary data. When they don't do that, they limit the programs you can write with them, and with no compensating increase in anything other virtue.

Re: OpenBSD removes support for non-UTF8 locales

#182

Post by gh02t » Sun, Aug 16, 2015, 3:32 PM UTC

jerf wrote: post #125

protomyth wrote: post #80

Earlier quoted context omitted.

"It's not arbitrary at all, it's for backwards compatibility." The original definition of the meter was one ten-millionth of the distance from the equator to the North Pole. Sure, we got more precise, but its still arbitrary. The only interesting thing about metric is the relation of length, volume, mass. But, a liter is not a cubic meter, nope - its a cubic decimetre, another arbitrary decision.

The units that have the best claim to being non-arbitrary tend to be of rather inconvenient orders of magnitude: https://en.wikipedia.org/wiki/Natural_units#Systems_of_natur... A certain amount of arbitrariness is inevitable at human scale.

Indeed, what units are convenient depends on context. Metric/SI is set up so that most of the un-prefixed units are a convenient size on human scale. But doing this means that some derived units will have values that are not human scale (like the Pascal, atmospheric pressure is ~100000 pascal). The nice thing about SI is that they subdivide easily in powers of ten, so even if the Pascal is inconvenient in our day-to-day lives it's easy to talk in kPa as 1000 Pa.

This is contrasted with something like Imperial units, where every division of e.g. distance is supposed to be roughly based on some physical object. That's why you end up with 12 in/ft, 5280 ft/mi etc. Or alternatively you end up with metric-imperial hybrid units like the kilopound.

Not to mention, what units are convenient vary depending on what you do. For instance one of the SI alternative units for energy is the electron volt (eV), the work done to move an electron through a 1 volt potential. This is a tiny amount of energy on human scale- a common analogy is that 1 MeV (10^6 eV) is enough energy to make a single grain of sand twitch a little bit. But, if you're a nuclear physicist (or maybe a chemist) then eV are typically much more convenient than say Joules.

Re: OpenBSD removes support for non-UTF8 locales

#183

Post by fanf2 » Sun, Aug 16, 2015, 4:53 PM UTC

ohitsdom wrote: post #14

fletchowns wrote: post #4

I dream of a world where everything is UTC, UTF-8, and metric.

I'd strongly consider voting for a US presidential candidate solely on if moving to metric was a big part of their platform. So much time is wasted in school on the confusing mess that is the imperial system.

The US does not use the Imperial system. "Imperial" refers to the reformed volume measures introduced in Britain in about 1820, which have a slight metric flavour. The US uses the Queen Anne volume measures, avoirdupois weights, and the international inch (except when it uses the survey inch).

Re: OpenBSD removes support for non-UTF8 locales

#184

Post by kuschku » Sun, Aug 16, 2015, 7:59 PM UTC

gpvos wrote: post #179

kuschku wrote: post #169

Earlier quoted context omitted.

Why would you want to get paid for that week? You don’t get paid for January 31st, March 31st, May 31st, July 31st, August 31st, October 31st or December 31st either. (Actually, you get paid for 2 of them. Still leaves 5 days a year without pay, 6 days in leap years). So, why should you get more? Just because you feel like you deserve it?

As far as I know, I am paid for those 31st days, but the pay is evened out over the year. You may live in a different country than me. It is actually pretty presumptuous of you to claim that you know on what basis my salary is calculated, unless you have comprehensive information about the entire Western world. I have expenses during that week. I happen to earn enough to be able to save a bit during the rest of the y…

If you are paid monthly, does your wage differ from January to February?

If no, then you do not get paid for these days directly, and you won’t get paid for the leap week.

If yes, well, then you’d also get paid for that leap week.

Re: OpenBSD removes support for non-UTF8 locales

#185

Post by khaled » Sun, Aug 16, 2015, 8:28 PM UTC

Animats wrote: post #6

How does locale work on the keyboard side, then? What determines whether text entry is right to left or left to right?

Keyboard layout is independent of the locale used, and so are the directionality of the text which is a property of the characters themselves.

Re: OpenBSD removes support for non-UTF8 locales

#186

Post by gpvos » Tue, Aug 18, 2015, 2:46 PM UTC

kuschku wrote: post #184

gpvos wrote: post #179

Earlier quoted context omitted.

As far as I know, I am paid for those 31st days, but the pay is evened out over the year. You may live in a different country than me. It is actually pretty presumptuous of you to claim that you know on what basis my salary is calculated, unless you have comprehensive information about the entire Western world. I have expenses during that week. I happen to earn enough to be able to save a bit during the rest of the y…

If you are paid monthly, does your wage differ from January to February? If no, then you do not get paid for these days directly, and you won’t get paid for the leap week. If yes, well, then you’d also get paid for that leap week.

You don't give up, don't you? As far as I know, my salary is based on slightly less than 30.5 days per month. Anyway, that was not my point and I don't care about that.

You are not addressing my real argument, which maybe originally I did not articulate in a way that you understood. Which is that in the proposed calendar, unless special arrangements are made, at some point people will have to wait 37 days for their salary and will only get ~30 days' salary at that moment. That is the thing that's currently not much of a problem. Whether that gets resolved by reducing the salary over the normal months by a small percentage and introducing an extra payment for that week, or by spreading out the payments over a 30/31-day schedule that ignores the new official months (which I think would be confusing and complicated), or by some other method, I'm fine with that. I did not say I wanted extra money, but it needs to be spread out evenly over the year.