Live data from Hacker News

OpenBSD removes support for non-UTF8 locales

marc.info

71–80 of 186 posts

Re: OpenBSD removes support for non-UTF8 locales

#71
post #30

Earlier quoted context omitted.

It was sort of darkly funny to be reading along as you're quoting the guy then all of a sudden hit so matter-of-factly, "He's dead, but you can still get the thing from...." A real splash of cold water.

What would be great would be if someone would take up UTF-8B again. I mentioned his death because otherwise you might think he lost interest in the project, but no, he lost interest in living.

> he lost interest in living

I get what you're trying to accomplish with the parallel construction, but that's a pretty callous way to describe it :/

Re: OpenBSD removes support for non-UTF8 locales

#72

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

My dream also includes the Hanke-Henry calender. https://en.wikipedia.org/wiki/Hanke-Henry_Permanent_Calendar My pick of the numerous proposals. Mostly because I can understand it. https://en.wikipedia.org/wiki/Calendar_reform

Interesting! This one keeps the 7-day week, which means it has a chance of succeeding. But wouldn't inserting an entire extra week every few years cause problems with things like monthly salaries and mortgage payments?

Re: OpenBSD removes support for non-UTF8 locales

#73
post #56

Earlier quoted context omitted.

If you changed the sizes of lumber, I'm pretty sure that someone would come out with "new inch" tapes that were labeled with inches and feet but accounted for the change in size (spreading the extra millimeters out across the distance). The dimensions in use are something that people are very used to working with and they know how to do the necessary mental arithmetic to work with them.

Luckily, the easy mental arithmetic is a main benefit of the metric system. I really doubt people would create "new inch" tapes. They would probably hang on to existing measuring tape for personal projects though.

The imperial choice of using highly composite numbers is at least as convenient for mental arithmetic as decimals.

Re: OpenBSD removes support for non-UTF8 locales

#74
post #32

Earlier quoted context omitted.

There's really no benefit in switching for "everyday" things like temperature, speed limits, weight... it would be a huge expense that doesn't really have any payoff. Where metric units are important, e.g. science and engineering, they are already used.

1. it does have the benefit that it's cross-cultural, you can actually talk to people outside your cultural bubble 2. it's got the advantage that you're using the same measurements as all your trade partners so people don't need two production lines anymore 3. it's got the advantage that people going into science and engineering don't need to build a whole new set of unit references because they've got the one which…

> 1. it does have the benefit that it's cross-cultural, you can actually talk to people outside your cultural bubble

We already do that.

> 2. it's got the advantage that you're using the same measurements as all your trade partners so people don't need two production lines anymore

Two production lines? For what?

> 3. it's got the advantage that people going into science and engineering don't need to build a whole new set of unit references because they've got the one which already works

Yup, failure to use the metric system in everyday life is why the US has the worst scientists and produces the least scientific output. Oh, wait.

> 4. the "huge expense" is pretty much made out of whole cloth for the purpose of saying you can't switch, the UK's metrication cost basically nothing except for road sign replacements which is why those are still imperial

I agree with this one. It probably wouldn't be terribly expensive to implement, though I would question the priorities of anyone who is really hung up about it (like the grandparent post who started this whole discussion).

Re: OpenBSD removes support for non-UTF8 locales

#75

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

I'd prefer to skip metric and redefine the foot as the distance light travels in a nanosecond ~ 11.8 inches. The length of the path travelled by light in vacuum during a time interval of 1/299792458 of a second seems a bit arbitrary to me. I would also vote for any candidate that would ban anything but powers of 2 in the definition of computer storage.

It's not arbitrary at all, it's for backwards compatibility. Previously the meter was defined in terms of the emission lines of krypton-86, which was a distance that we could measure most precisely with an interferometer. Before that it was based on the size of the earth, which could be measured with a astronomical calculations. And originally it was based on the length of a pendulum that produced a period of a 1 seconds, from which the length can be calculated using a scale, a reference mass and a clock (there was another definition, but this one was more precise I believe).

Each definition gives you something pretty close to what we now define as a meter, but the precision to which they could be measured at the time differed. The length of a "meter" was more or less the same distance in everybody's mind then as now, but if a 10000 scientists would sit down and perform experiments to actually calculate the exact length in 1700 versus, the mean of the values they reported would be about the same as it is today, but the statistical uncertainty would be much much much higher.

The redefining of the meter has typically occurred when some new process was invented that was more precise than the the previous method, for instance today measuring a laser in a vacuum is something like 1/3 the uncertainty than the old method using an interferometer. So the uncertainty is smaller, but crucially the mean value is still basically the same or very close. That's the reason for the weird 1/299792458 seconds, it's because we can define seconds very very precisely (from atomic clocks) and that's the amount of time it takes light in a vacuum to travel the same distance as the previous most precise known value for the length of a meter.

If it wasn't done this way, every time we invented a more precise method to measure distance and want to improve the precision of the meter it'd be like defining a whole new unit. Defining a foot as the distance light travels in a nanosecond is fine now, but if we discover an even more precise way to measure distance than a laser in a vacuum we'd end up in the same position, where a "foot" would be some strange fraction of a reference value that makes it work out to agree with the old most precise known value.

This sort of stupidly accurate measurement doesn't matter anymore on the day-to-day life scale as the length of a meter is known to within ~(10^-9)%, which is about a ten picometers. However, that means then that if you're fabricating silicon at the nanometer scale, the actual exact length of a nanometer is only known to within about 1% of a nanometer (if I did my math right, might be off by a factor of 10). That's much more significant.

Re: OpenBSD removes support for non-UTF8 locales

#76
post #32

Earlier quoted context omitted.

There's really no benefit in switching for "everyday" things like temperature, speed limits, weight... it would be a huge expense that doesn't really have any payoff. Where metric units are important, e.g. science and engineering, they are already used.

1. it does have the benefit that it's cross-cultural, you can actually talk to people outside your cultural bubble 2. it's got the advantage that you're using the same measurements as all your trade partners so people don't need two production lines anymore 3. it's got the advantage that people going into science and engineering don't need to build a whole new set of unit references because they've got the one which…

This should be part of TTIP and TPP, actually.

Use SI and ISO standards for everything.

ISO A4 paper, ISO time (2015-08-14 23:52 UTC+2), Metric, etc

Re: OpenBSD removes support for non-UTF8 locales

#77
post #3

I wonder what the pros and cons weighed in the discussion were. Clearly not supporting Unicode text in non-UTF-8 locales (except through, like, some kind of compatibility function, like recode or iconv) is the Right Thing. One problem that I have is that current UTF-8 implementations typically are not "8 bit clean", in the sense that GNU and modern Unix tools typically attempt to be; they crash, usually by throwing a…

I'm willing to bet a large amount that non UTF-8 encoding were broken and nobody cared enough to bother fixing them. OpenBSD does not hesitate to nuke legacy stuff that gets broken. Which i feel is ultimately for the best, because half-assed support that barely functions is worse than no support at all many times.

It was in fact intentionally broken to find out where removing single-byte locales hurts our users most.

We have a hackathon coming up with devs committed to making UTF-8 work in more base utilities. If that works out, and the most sore points of latin1/koi-8/etc users have been adequately addressed, 5.9 will ship with only the UTF-8 locale (and of course the default "C" locale -- ASCII).

If this approach turns out to be wrong because we cannot get regressions fixed, 5.9 will ship like 5.7 and 5.8 (with UTF-8 and single byte locales).

Re: OpenBSD removes support for non-UTF8 locales

#78

Earlier quoted context omitted.

1. it does have the benefit that it's cross-cultural, you can actually talk to people outside your cultural bubble 2. it's got the advantage that you're using the same measurements as all your trade partners so people don't need two production lines anymore 3. it's got the advantage that people going into science and engineering don't need to build a whole new set of unit references because they've got the one which…

> 1. it does have the benefit that it's cross-cultural, you can actually talk to people outside your cultural bubble We already do that. > 2. it's got the advantage that you're using the same measurements as all your trade partners so people don't need two production lines anymore Two production lines? For what? > 3. it's got the advantage that people going into science and engineering don't need to build a whole new…

[deleted]

Re: OpenBSD removes support for non-UTF8 locales

#79
post #72

Earlier quoted context omitted.

My dream also includes the Hanke-Henry calender. https://en.wikipedia.org/wiki/Hanke-Henry_Permanent_Calendar My pick of the numerous proposals. Mostly because I can understand it. https://en.wikipedia.org/wiki/Calendar_reform

Interesting! This one keeps the 7-day week, which means it has a chance of succeeding. But wouldn't inserting an entire extra week every few years cause problems with things like monthly salaries and mortgage payments?

The financial year assumes 30 days per month, 12 months per year, 360 days per year. That’s what’s the basis for your salary calculation.

Re: OpenBSD removes support for non-UTF8 locales

#80
post #75

Earlier quoted context omitted.

I'd prefer to skip metric and redefine the foot as the distance light travels in a nanosecond ~ 11.8 inches. The length of the path travelled by light in vacuum during a time interval of 1/299792458 of a second seems a bit arbitrary to me. I would also vote for any candidate that would ban anything but powers of 2 in the definition of computer storage.

It's not arbitrary at all, it's for backwards compatibility. Previously the meter was defined in terms of the emission lines of krypton-86, which was a distance that we could measure most precisely with an interferometer. Before that it was based on the size of the earth, which could be measured with a astronomical calculations. And originally it was based on the length of a pendulum that produced a period of a 1 sec…

"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.

Post reply on HN