Live data from Hacker News

OpenBSD removes support for non-UTF8 locales

marc.info

151–160 of 186 posts

Re: OpenBSD removes support for non-UTF8 locales

#151

Earlier quoted context omitted.

Personally, I wish everyone used the 24:00 clock. Maybe the military has messed me up, but I really prefer seeing something like 18:22 over 6:22pm. It just seems simplier.

I cannot tell you the number of times in my life that a 12 hour clock has lead to a _major_ fuckup. I run all my personal clocks on 24hr to prevent said fuckups, but somehow I still feel weird telling people a meeting is at 15:00 in an email.

>but somehow I still feel weird telling people a meeting is at 15:00 in an email.

It feels weird because you think people will think it's weird. You're probably right.

Personally I use a 24-hour representation and convert it to 12 when communicating with others.

11:59AM -> 12:00PM, 11:59PM -> 12:00AM caused me mental discomfort for a long time. A 24-hour clock made a lot more sense, but it doesn't seem like most other people have a problem with 12.

They'd rather you used "normal" time. If you want to fight that battle go for it. I believe you're right.

Next: Date format!

Re: OpenBSD removes support for non-UTF8 locales

#152
post #31
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…

If I remember correctly, raw lumber here in Finland is in inches and planed lumber in millimeters :)

Re: OpenBSD removes support for non-UTF8 locales

#153

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

AIUI, one of the big problems with using UTF-8 universally is that it's rather unfriendly to Asian character sets. e.g. apparently UTF-8 is three times bigger than TIS-620 for Thai characters (from http://www.micro-isv.asia/2009/03/why-not-use-utf-8-for-ever...).

Re: OpenBSD removes support for non-UTF8 locales

#154

Earlier quoted context omitted.

You're not thinking about all the designs, tooling, manufacturing facilities, etc to build all that stuff though. That's where the real cost is. > Would it be a huge deal to round that to 40mm by 90mm? It actually would be a big deal to round things like that I think. Whole designs would need to be updated to take into account the new dimensions of things.

More manufacturing is done in China, and the factories are used to the different international markets because they're often parts suppliers for foreign companies that have their designing done in various countries. So they're well equipped to make things in either inches or mm.

You're overstating it, there are only 2 other countries in the world that use imperial units

Re: OpenBSD removes support for non-UTF8 locales

#155
post #24

Earlier quoted context omitted.

Yes couldn't agree more with that. Also dates in numeric order I.e. yyyy/mm/dd you know like all the other numbers we deal with not dd/mm/yyyy or the crazy mm/dd/yy.

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

I had - I think - independently come up with this format for naming log files, and I was so very, very happy when I found out it is an ISO standard.

A little disappointed, too, because every single time I have a great idea like this, I find out that somebody else had it before me. But still.

Re: OpenBSD removes support for non-UTF8 locales

#156
post #123
post #95

Earlier quoted context omitted.

Or the even stricter RFC3339 date format, which is ISO8601 without the dumb bits: http://www.ietf.org/rfc/rfc3339.txt

Neat. I wonder if anyone collects a list of famous standards that have been superseded by compatible, better standards. Another example would be that many people know of ISO 639 language codes, but BCP 47 is a clearer, more relevant standard.

> I wonder if anyone collects a list of famous standards

If you really want to know, ask Wikipedia. There are some lists there that make me think somebody has a major case of OCD. There is even a List of Lists on Wikipedia, so ... wait, there is even a List of lists of lists...

Re: OpenBSD removes support for non-UTF8 locales

#157

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.

I have tried to convince people to change the metric system to binary, i.e. have a kilogram be 1024 grams, and a kilometer be 1024 meters. Which would finally force hard drive manufacturers to be honest about their devices' capacities.

So far, I have not been very successful, though. :(

Re: OpenBSD removes support for non-UTF8 locales

#158
post #105

Earlier quoted context omitted.

Easy, we just kill off the idea of leap seconds. Someone please convince Russia and UK to agree so we can do it.

> Easy, we just kill off the idea of leap seconds. OK, now everyone who cares how much time has passed in terms of the Earth's rotation needs to keep a time separate from everyone else. Astronomers come to mind, for example.

In terms of Earth's rotation, you start out hopelessly off because of time zones, so worrying about a few seconds either way is not a problem.

Re: OpenBSD removes support for non-UTF8 locales

#159

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

AIUI, one of the big problems with using UTF-8 universally is that it's rather unfriendly to Asian character sets. e.g. apparently UTF-8 is three times bigger than TIS-620 for Thai characters (from http://www.micro-isv.asia/2009/03/why-not-use-utf-8-for-ever... ).

I spoke to several Japanese OpenBSD developers about this. They told me UTF-8 is not perfect but it's the least of available evils. They'd be more happy with a UTF-8 capable base system than with the current state of things where with few exceptions UTF-8 is supported only by 3rd party applications installed from ports.

And note that this is about system locales which mostly concerns libc APIs. Applications are still free to support additional character sets via other means (e.g. iconv).

For some problems a locale may not be the best answer. For instance, during these conversations I learned that Japanese android phones expose filenames as Shift-JIS which cannot be listed by ls(1) when the phone's filesystem is mounted in OpenBSD. In my opinion what's needed is not a system locale that switches everything to Shift-JIS but a translation layer which presents filenames as UTF-8 to the rest of the system. Perhaps a fuse filesystem module which links to libiconv in userspace to perform the necessary translation, and presents the result at an auxiliary mount point.

Re: OpenBSD removes support for non-UTF8 locales

#160

Earlier quoted context omitted.

Sold.

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

I believe in my entire life I've encountered exactly one situation in which the day that is defined as the first day of the week actually made a difference to anything: my kids' swim school schedule, where Week N of the term runs from Sunday through to the following Saturday inclusive.

Since the working week (and the school week) here starts on Monday regardless of whether Sunday or Monday is regarded as the first day of the week, it seems to have always been a distinction without a difference to me.

Post reply on HN