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

OpenBSD removes support for non-UTF8 locales

marc.info

Post reply on HN
Print view View original

81–90 of 186 posts

Re: OpenBSD removes support for non-UTF8 locales

#81

Post by protomyth »

kstrauser wrote: post #59
protomyth wrote: post #50

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.

A kibibyte is a fictional unit invented to make computer scientists sound like their lips were still asleep after a dentist visit.

All in the service of 10 worshipers. There is a tribe in the US (Yuki) who got it right and counts in octal because they count the spaces in between the fingers (you can hold 8 bottles).

Re: OpenBSD removes support for non-UTF8 locales

#82

Post by gh02t »

protomyth wrote: post #80
gh02t wrote: post #75

Earlier quoted context omitted.

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.

Yes, the original definition is arbitrary of course. I was talking about the random constant fraction of a second. Units are always arbitrary, by definition they're just a convention. They're a way of relating an abstract concept (a number) to some intuitively meaningful thing.

Re: OpenBSD removes support for non-UTF8 locales

#83

Post by baudehlo »

peterfirefly wrote: post #52
blackbeard wrote: post #45

Earlier quoted context omitted.

Sold.

8601 also gives you proper week numbering (which Europeans tend to like) + weeks start on Monday, after the weekend.

In some countries the weekend isn't Saturday and Sunday though. So the start of the week is kind of arbitrary.

Re: OpenBSD removes support for non-UTF8 locales

#84

Post by busterarm »

gnuvince wrote: post #20

As a French-speaking person, I cannot tell you how much the announcement[0] that after 5.8, basic utilities, including mg(1), will be UTF-8 ready pleases me. I'm a huge Emacs fan, but I like to use mg(1) for quick edits and this is very exciting news for me! [0] http://undeadly.org/cgi?action=article&sid=20150722182236

Funny thing about Emacs and OpenBSD...

...Emacs is the only package in the entire ports tree that can't use ASLR.

Re: OpenBSD removes support for non-UTF8 locales

#85

Post by kstrauser »

gh02t wrote: post #75
protomyth wrote: post #50

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…

Wait, wouldn't you still know the length of a nanometer to with (10^-9)% of a nanometer?

Re: OpenBSD removes support for non-UTF8 locales

#86

Post by kstrauser »

maxerickson wrote: post #73
jaawn wrote: post #56

Earlier quoted context omitted.

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.

What's 1/10th of 3 3/8"?

Re: OpenBSD removes support for non-UTF8 locales

#87

Post by opk »

stsp wrote: post #77
throwaway2048 wrote: post #18

Earlier quoted context omitted.

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 t…

My first thought was, what about the "C" locale so good to see that question already answered.

I really wish there was some sort of standard "U" locale that would be the same as "C" but UTF-8, and ISO rather than US format dates.

Re: OpenBSD removes support for non-UTF8 locales

#88

Post by readstoomuch »

nawitus wrote: post #8
fletchowns wrote: post #4

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

UTC is (as everyone knows) a bit problematic due to leap seconds. Different software systems handle the leap seconds somewhat differently. Handling leap seconds is is actually quite difficult if you want to get it absolutely correct. In 99% of cases the problems are just ignored (e.g. "it doesn't matter if the chart is slightly odd looking when you look at the moment of the leap second"). There's also the problem tha…

Was ist GoogleTime?

Re: OpenBSD removes support for non-UTF8 locales

#89

Post by gh02t »

kstrauser wrote: post #85
gh02t wrote: post #75

Earlier quoted context omitted.

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…

Wait, wouldn't you still know the length of a nanometer to with (10^-9)% of a nanometer?

No, because defined this way, the absolute precision to which distance can be defined is ~10^-11 meters. So 1 meter is known within +/- (10^-11) meters. If you convert (10^-11) meters to nanometers that's 10^-2 nanometers, which is 1% of a nanometer.

You don't divide the uncertainty when you scale it because the error is in the actual definition of distance itself. The uncertainty in for example 1 meter is the same as the uncertainty in 1 nanometer (=10^-11 meters), which is a correspondingly much larger fraction. It's kind of weird and perhaps counter-intuitive, but that's how it works.

Phrased differently, the idea of a meter is exact and it's our ability to measure distance that is uncertain. The error isn't in saying "a meter is some specific fraction of the distance light travels in a second", it's in determining what physical distance in the world is represented by our definition of the meter.

Re: OpenBSD removes support for non-UTF8 locales

#90

Post by kaoD »

busterarm wrote: post #84
gnuvince wrote: post #20

As a French-speaking person, I cannot tell you how much the announcement[0] that after 5.8, basic utilities, including mg(1), will be UTF-8 ready pleases me. I'm a huge Emacs fan, but I like to use mg(1) for quick edits and this is very exciting news for me! [0] http://undeadly.org/cgi?action=article&sid=20150722182236

Funny thing about Emacs and OpenBSD... ...Emacs is the only package in the entire ports tree that can't use ASLR.

Why is it?
Post reply on HN