I dream of a world where everything is UTC, UTF-8, and metric.
And \n line delimiters and \s+ tabs!
OpenBSD removes support for non-UTF8 locales
61–70 of 186 posts
Re: OpenBSD removes support for non-UTF8 locales
#62I 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.
Re: OpenBSD removes support for non-UTF8 locales
#63Earlier 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?
My estimate is "approximately zero". For example, people talk about the cost of converting road signs as though we have pick a Tuesday in March and switch the entire country that afternoon. How about we adopt a policy like "when we install new signs or replace old ones as routine maintenance, we make them metric - and here's a conversion chart so we're all using the same mile-to-km rounding."
Re: OpenBSD removes support for non-UTF8 locales
#64I 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…
For the benefit of others (the link is nonobvious), here's Markus Kuhn's presentation of UTF-8B:
http://hyperreal.org/~est/utf-8b/releases/utf-8b-20060413043...
The tl;dr is to map an invalid UTF-8 byte n to code point U+DC00 + n, which puts it in the code point range reserved for the second part of a surrogate pair. (In UTF-16, a 16-bit value between D800 and DBFF followed by a 16-bit value between DC00 and DFFF is used to encode a code point that cannot fit in 16 bits. Since these "surrogate pairs" happen only in that order, there is room to extend UTF-16 by assigning a meaning to a DC00-DFFF value seen without a D800-DBFF before it.) Since the surrogate code points are defined as not "Unicode scalar values" and cannot exist in well-formed "Unicode text", and therefore cannot be decoded from well-formed UTF-8, there's no risk of confusion.
There are some similarities with the extension of UTF-8 encoding that is sometimes called "WTF-8" https://simonsapin.github.io/wtf-8/. WTF-8 lets unchecked purportedly-UTF-16 data be parsed as a sequence of code points, encoded into an extension of UTF-8, and round-tripped back into the original array of uint16s. UTF-8B lets unchecked purportedly-UTF-8 data be parsed as a sequence of code points, encoded into an extension of UTF-16, and round-tripped back into the original array of uint8s. They're not quite compatible, because WTF-8 would encode U+DC80 as a three-byte sequence (ED B2 80), and UTF-8B would decode that into three code points (U+DCED U+DCB2 U+DC80) since U+DC80 isn't a Unicode scalar value. But if a system wanted to support both of these robust encodings simultaneously, I think you could handle this fairly clear special case.
Re: OpenBSD removes support for non-UTF8 locales
#65Earlier quoted context omitted.
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.
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.
That's what they thought before solar time was replaced by time zones. I think the US going metric would be a greater boost for the US and world economy than the supposed benefits of TPP, TTIP, and other "trade" agreements combined.
Re: OpenBSD removes support for non-UTF8 locales
#66Earlier quoted context omitted.
The total cost to switch has gotta be in the hundreds of billions of dollars. Has anybody done such a calculation?
My estimate is "approximately zero". For example, people talk about the cost of converting road signs as though we have pick a Tuesday in March and switch the entire country that afternoon. How about we adopt a policy like "when we install new signs or replace old ones as routine maintenance, we make them metric - and here's a conversion chart so we're all using the same mile-to-km rounding."
The Australian experience (as told in the "Metrication Matters" video) was that a "direct metrication" where everybody switches at the same time and doesn't try to maintain two systems at the same time is fast (about a year) and cheap (often saving money).
Road signs can be prepared in advance and covered. The covers can be removed quickly. Another option is to put stickers on the road signs on Metric Sunday.
Re: OpenBSD removes support for non-UTF8 locales
#67Earlier quoted context omitted.
It's really not that bad. Canada did it in the 1970s and it's still around, and we didn't revert to the stone age or anything. SI units are already in wide use in the US, for instance for electricity (Amperes, Watts, Volts). For the most part, international trade has pushed US industries to adopt metric anyway: metric fasteners are used all over, in cars for instance. Also, countries that have switched still use inch…
My favourite is car tyre sizes. 215/60R16 means the maximum width is 215 millimetres , the aspect ratio of the cross section is 60 percent , R is both a separator and a code for radials, and it's made for 16 inch rims.
Even in the Netherlands, a staunchly metric country, bicycle tyre diameters are measured in inches. (Wouldn't know about car tyres.)
Re: OpenBSD removes support for non-UTF8 locales
#68Re: OpenBSD removes support for non-UTF8 locales
#69Earlier 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.
You still have plenty of arbitrary-ness in your definition of a (nano-)second. :)
I'll take one level over two levels. Besides, memorizing that metric fraction is just wrong. Plus, do we really want to go into space with a unit of measure whose origins are tied to the size of the Earth? Let's at least free part of the definition from an Earth-centric bias. I fear a Mars-centric meter might develop.
Re: OpenBSD removes support for non-UTF8 locales
#70I 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…
In a roundabout way, this is because I wasn't able to push through an isprint() workaround diff to ls. http://marc.info/?l=openbsd-misc&m=142540203528315&w=2