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

51–60 of 186 posts

Re: OpenBSD removes support for non-UTF8 locales

#51

Post by peterfirefly »

fletchowns wrote: post #22
adamrt wrote: post #19

Earlier quoted context omitted.

The amount of time and money to shift at this point would be astronomical wouldn't it? It would take a few generations as we would continue to have to teach imperial so people could convert when they ran across any existing media referring to the imperial system measurements. Hundred years of machines that use imperial, speedometers, odometers, books, tools, software, air conditioning, heating, manufacturing, constru…

The total cost to switch has gotta be in the hundreds of billions of dollars. Has anybody done such a calculation?

"Metrication Matters" (Google TechTalk from 2007)

https://www.youtube.com/watch?v=NgtsSM7vN0M

It starts a bit slow but stick with it. I'm currently rewatching it after several years so I'm not sure there is a calculation. I think there is. A lot of the production in the US already is metric so it shouldn't be that expensive.

Remember that everybody else also had to change their (many) measuring systems over to metric. It went remarkably well.

Re: OpenBSD removes support for non-UTF8 locales

#52

Post by peterfirefly »

blackbeard wrote: post #45
qznc wrote: post #24

Earlier quoted context omitted.

Use minus instead of slash and you have ISO 8601: yyyy-mm-dd

Sold.

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

Re: OpenBSD removes support for non-UTF8 locales

#53

Post by jaawn »

fletchowns wrote: post #46
jaawn wrote: post #41

Earlier quoted context omitted.

Any manufacturing component which cannot easily be adjusted to a slightly different measurement is poorly designed, in my opinion. I would expect that much of these tools could be tweaked to produce things in metric measurements. If not, the dimensions can simply be converted and re-labeled. If something manufactures a square piece of metal that is 3" by 3", is it a huge deal to just document it as being 76.2mm by 76…

> Any manufacturing component which cannot easily be adjusted to a slightly different measurement is poorly designed, in my opinion. Imagine all of the parts in a car engine. Everything fits together perfectly. Engine mounts line up in the right places. It all has to be very precise. Now imagine you take all those parts and round them off a bit. Nothing much, just a mm here and there. If you try to put the engine tog…

While I think the rounding would work with lumber, I definitely don't think it would work with things like car engines. For such precisely-measured components, converting to a metric measurement with the correct significant figures should be fine.

Repair shops can maintain tools for both systems (they already have to). For converting, I mean the dimensions of a component, not tools and fasteners that need to work with tools. Those would likely take a "metric only going forward" approach.

Re: OpenBSD removes support for non-UTF8 locales

#54

Post by zf00002 »

jaawn wrote: post #31
adamrt wrote: post #19

Earlier quoted context omitted.

The amount of time and money to shift at this point would be astronomical wouldn't it? It would take a few generations as we would continue to have to teach imperial so people could convert when they ran across any existing media referring to the imperial system measurements. Hundred years of machines that use imperial, speedometers, odometers, books, tools, software, air conditioning, heating, manufacturing, constru…

I think it might not be as bad as we imagine. All speedometers I've seen show both miles-per-hour and kilometers-per-hour, all thermostats I've seen have an option for switching to Celsius, all scales I've owned can display both pounds and kilograms (my current one even has an option for stones), all measuring cups I've seen in a long time have both systems displayed, etc. Even lumber wouldn't necessarily be a huge i…

I-19 in southern Arizona has its distance signs in meters and kilometers as part of a test during the '70s. There have been plans to change it for a number of years but local opposition has stalled it.

https://en.wikipedia.org/wiki/Interstate_19

Re: OpenBSD removes support for non-UTF8 locales

#55

Post by skybrian »

kragen wrote: 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…

Reminds me of Go strings: they usually store UTF-8 but they're actually 8-bit clean:

"It's important to state right up front that a string holds arbitrary bytes. It is not required to hold Unicode text, UTF-8 text, or any other predefined format. As far as the content of a string is concerned, it is exactly equivalent to a slice of bytes."

https://blog.golang.org/strings

Re: OpenBSD removes support for non-UTF8 locales

#56

Post by jaawn »

maxerickson wrote: post #40
jaawn wrote: post #31

Earlier quoted context omitted.

I think it might not be as bad as we imagine. All speedometers I've seen show both miles-per-hour and kilometers-per-hour, all thermostats I've seen have an option for switching to Celsius, all scales I've owned can display both pounds and kilograms (my current one even has an option for stones), all measuring cups I've seen in a long time have both systems displayed, etc. Even lumber wouldn't necessarily be a huge i…

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.

Re: OpenBSD removes support for non-UTF8 locales

#57

Post by kstrauser »

masklinn wrote: post #39
kragen wrote: 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…

> 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 an exception Crashing on invalid data sounds like a great idea. Leaving garbage through doesn't.

Crashing in the "/* oops! */ exit(1)" sense is great. Crashing in the buffer overflow sense is not. OpenBSD treats all of the latter as potential security vulnerabilities.

Re: OpenBSD removes support for non-UTF8 locales

#58

Post by 0x0 »

protomyth wrote: post #50
fletchowns wrote: post #4

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.

You still have plenty of arbitrary-ness in your definition of a (nano-)second. :)

Re: OpenBSD removes support for non-UTF8 locales

#59

Post by kstrauser »

protomyth wrote: post #50
fletchowns wrote: post #4

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.

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

Re: OpenBSD removes support for non-UTF8 locales

#60

Post by ptx »

kragen wrote: 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…

Kuhn's idea is also used in in Python 3, so that garbage bytes can (optionally!) be decoded to Unicode strings and later losslessly turned back into the same bytes, which ensures (e.g.) that filenames that can't be decoded can still be used: https://www.python.org/dev/peps/pep-0383/
Post reply on HN