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

141–150 of 186 posts

Re: OpenBSD removes support for non-UTF8 locales

#141

Post by gpvos »

kuschku wrote: post #79
gpvos wrote: post #72

Earlier quoted context omitted.

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.

Indeed I'm paid the same amount every month. Yet I'm paid on the same day of every 28/29/30/31-day month, i.e., with slightly varying intervals. The differences between the months are currently small enough that it doesn't really matter much, and it always evens out the next month. But if suddenly a wild week appears, I will want to get paid for that week. Either that, or everyone will need to keep to a parallel traditional month system for periodic payments.

Re: OpenBSD removes support for non-UTF8 locales

#142

Post by masklinn »

geofft wrote: post #134
masklinn wrote: post #39

Earlier quoted context omitted.

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

Is it really garbage? If we want to be true to UNIX's (questionable) "Write programs to handle text streams, because that is a universal interface" ethos, our definition of "text" has to admit all possible byte strings to be "universal". And the so-called C locale historically did.

> Is it really garbage?

Invalid UTF-8 when valid UTF-8 was expected? Yes.

> "Write programs to handle text streams, because that is a universal interface" ethos, our definition of "text" has to admit all possible byte strings to be "universal"

Random bytes are not text. The Unix ethos is "communicate via arbitrary binary streams" but programs which only understand text understand text, not random-bytes-which-are-not-text. It seems sensible for programs to have more restrictions on their input than the general-purpose communication protocol does: would you expect jq to try and process input which is not JSON in any way, shape or form despite being it being billed a JSON processor? Because that's not what it's going to do, at least not by default.

Re: OpenBSD removes support for non-UTF8 locales

#143

Post by masklinn »

kstrauser wrote: post #57
masklinn wrote: post #39

Earlier quoted context omitted.

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

No objection there, "crashing" in my comment was meant as "stops processing and report an input data error to the user", the erlang sense of crashing if you will.

Re: OpenBSD removes support for non-UTF8 locales

#144

Post by cpeterso »

RexRollman wrote: post #17
fletchowns wrote: post #4

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

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.

Plus people format 12 hour times inconsistently:

  6:00pm
  6:00PM
  6:00 PM
  6:00 P.M.
  6PM
  or just 6:00

Re: OpenBSD removes support for non-UTF8 locales

#145

Post by Asbostos »

joshuapants wrote: post #74
masklinn wrote: post #38

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…

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

Do you really? Whenever I hear an American telling the temperature of the weather, I have no idea what they mean. I have to guess from the context if it's hot or cold, and even what units they're using because they rarely mention the "Fahrenheit" part.

Conversely, how many Americans would recognize that "35 degrees" is blisteringly hot while "15 degrees" means you'll need a jacket and "40 degrees" could kill you if you don't find shelter quickly?

Re: OpenBSD removes support for non-UTF8 locales

#146

Post by repsilat »

cbd1984 wrote: post #140
feld wrote: 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.

If anyone needs to know about the Earth's rotation that precisely they probably

- don't rely on their laptop's system clock, - don't use UTC either because of minor rotational noise/drift and the discontinuity around the leap-second, and - find the whole 24-hour clock thing a little useless, not being seasonally adjusted etc.

I bet they'd prefer TAI to UTC (or even "Google time"), because they've probably got their own timekeeping systems that will probably interact more smoothly (heh) with it.

More to the point, there are approximately zero astronomers on Earth, and approximately seven billion non-astronomers. Even if astronomers do prefer UTC, it's better to make them have their own systems to add or subtract twenty-something seconds from TAI than forcing all of my timekeeping devices to have a database of historical leap-seconds and an internet connection to hear about new ones.

Not to mention the fact that I can't write down what the time will be in UTC in 86400 * 1000 seconds... Absolutely ridiculous.

Re: OpenBSD removes support for non-UTF8 locales

#147

Post by repsilat »

LeoPanthera wrote: post #115
feld wrote: 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.

No thank you. Just store times on computers as $epoch+$offset and then convert to UTC when displayed to the user. That way, only the display routine has to care about leap seconds and it won't break anything.

If you mean "UNIX time", you'll be disappointed -- UNIX time is not the number of seconds since the epoch, it is also leap-second adjusted. It stops when a leap second happens to make sure there are exactly 86400 UNIX seconds between every midnight (so you can do divmod calculations on timestamps.)

Maybe you were suggesting an improvement to UNIX time, though, in which case I think the grandparent and I would get behind your proposal.

Re: OpenBSD removes support for non-UTF8 locales

#148

Post by krylon »

RexRollman wrote: post #17
fletchowns wrote: post #4

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

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 have not served in the military (we still had the draft in Germany when I finished school, but I was a conscientious objector), but I greatly prefer the 24-hour time format as well.

Maybe digital clocks/watches have influenced this preference, but I still think it is a good idea, because it is unambiguous.

Re: OpenBSD removes support for non-UTF8 locales

#149

Post by caf »

opk wrote: post #87
stsp wrote: post #77

Earlier quoted context omitted.

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.

There has been some talk both in glibc and musl of shipping such a "C-but-UTF-8" locale.

Re: OpenBSD removes support for non-UTF8 locales

#150

Post by roghummal »

kragen wrote: post #129
nightpool wrote: post #71

Earlier quoted context omitted.

> 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 :/

I'm sorry I upset you. I didn't mean to.

>I'm sorry (if) I upset you. I didn't mean to.

The poster didn't express that he was upset. He expressed an opinion that your description was callous.

Post reply on HN