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

111–120 of 186 posts

Re: OpenBSD removes support for non-UTF8 locales

#111

Post by glandium »

kazinator wrote: post #106
RexRollman wrote: post #17

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.

The real beauty of the 24:00 clock is that it never actually shows that; at most 23:59. Then it goes to 0:00. The 12:00 clock would be more respectable if it went from 0:00 (midnight/a.m.) to 11:59 a.m. then to 0:00 (noon/p.m.) and to 11:59 p.m. and never showed 12:00. (Let alone continuously flash such a thing as a demand that the time be set.)

That's what 12:00 clocks display in Japan, fwiw, and it's much less confusing (because, really, jumping from 11:59am to 12:00pm is nonsensical for people not familiar with that quirk)

Re: OpenBSD removes support for non-UTF8 locales

#112

Post by mjevans »

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.

I'd argue that the unit liter was chosen as a nice power of 10 relation to a cubic meter (the obvious initial choice) as being the best for 'every day' common person transactions.

Take a bottle of water, most commonly the sold sizes are 0.5 (about 16oz) and 1 liter bottles; a liter is also pretty close to a quart.

As another example, it is common to find soda pop sold in bottles of 1, 2, and 3 liters (depending on the brand).

Re: OpenBSD removes support for non-UTF8 locales

#113

Post by joshuapants »

dietrichepp wrote: post #100
joshuapants wrote: post #74

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

> Yup, failure to use the metric system in everyday life is why the US has the worst scientists and produces the least scientific output. Oh, wait. Failure to use the metric system everywhere cost NASA a $125 million Mars orbiter just 16 years ago, and yet here you are, insisting that this is not a problem, and throwing in a non sequitur to justify the position.

> Failure to use the metric system everywhere cost NASA a $125 million Mars orbiter

No, bureaucratic failure to address the concerns of people who spotted the error well in advance of the launch cost NASA $125M. The investigation report makes that clear, especially when it goes on to make recommendations for avoiding future mishap; nobody recommended that the engineers needed to brush up on their units.

And yet here you are, insisting that the issue was that we didn't switch over to the metric system, and throwing in some unsupported claims to justify the position.

Re: OpenBSD removes support for non-UTF8 locales

#114

Post by busterarm »

dietrichepp wrote: post #99
kaoD wrote: post #90

Earlier quoted context omitted.

Why is it?

Not sure, but I can tell you that Emacs is weird inside, in a lot of ways. It runs an interpreter for a language that nobody else uses, which has been heavily optimized because otherwise Emacs would be too slow. Then they use tricks to speed up executable loading, like loading Emacs and then writing the contents of memory to disk, so it can be loaded more quickly the next time.

Yes, from what I hear, basically it's Emacs' issue.

Re: OpenBSD removes support for non-UTF8 locales

#115

Post by LeoPanthera »

feld wrote: post #105
nawitus wrote: post #8

Earlier quoted context omitted.

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…

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.

Re: OpenBSD removes support for non-UTF8 locales

#116

Post by mjevans »

toyg wrote: post #15
NoMoreNicksLeft wrote: post #13

Earlier quoted context omitted.

Metric's nice, but each day being 10 hours in a 10 day week just doesn't work for me. But at least it's Fiveday, and I have a 20 hour weekened to look forward to.

You should use the International Fixed Calendar https://en.wikipedia.org/wiki/International_Fixed_Calendar The failure to adopt the IFC is the proof that human beings will forever be shackled to their ancestral beliefs.

Re parent: ~365.25 does not relate at all well to bases of 10, or much else.

We can actually thank existing social patterns including religions for locking us in to a '7 day week' which is what many calendar systems try to promote.

With (roughly) every 4 years also containing an extra day of correction (the solar orbital period is not quite 365.25 days) the concept of 'leap days' is necessary anyway.

    360: 2 2 2 3 3 5
The IFC picks the 364 route, and puts the leap day in the middle of the printed year. The decision of where to put that date is pretty arbitrary, but probably based around a 'summer holiday'.

360 is 5 away from the closest integer orbital period of earth. Therefore 5 'extra days' (likely holidays) would need to be added. 5 is also a factor. It would either make sense to have an extra 5 day period as one long holiday set, or an extra holiday spread out through the year 5 times, though arguments for otherwise could be made.

7 and 360 get along poorly though. We'd probably also want to keep '12 months' for sanity/existing contractual structures (esp since we can't be in units of 10), and having 'months' close to current months seems to be an advantage.

Taking 2 * 2 * 3 out of the factor set, we're left with 2 * 3 * 5 for each month.

Stepping aside for a moment, let's examine a 'perfect' 28 day month in the IFC/current calendars. 2/7ths (0.285714) of the time is 'weekend' time.

I'd propose a 10 day 'week' in the new time, I also think 2 days in a row off of work is advantageous, and I think that this time should be time 'normal workers' can expect to share off. I think that this number might actually grow over time as we increasingly approach a more Utopian society based around automation and abundance.

The 10 day 'week' would begin with the following structure.

    * 2 days of work
    * 4 day period of 3/4th work (on each of these days about 1/4th of workers would have an 'erands' day)
    * 2 days of work
    * 2 days off work - weekend
On this schedule half the workers would get a 2+5 or 5+2 and the other half would get 3+4 or 4+3; all workers on a 'standard' shift would also see 0.3 weekend time, a slight increase.

The extra 5 holiday days could either be divided somehow over the year, or used up all at once as a burst half-week holiday. The necessary leap year correction would be added to one of those periods as a holiday as well.

Since this is another example of a 'standards proposal', someone must have thought of this before...

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

This link seems to do a decent job of discussing some of the other aspects of converting to a 10 day calendar (many of which also exist for the IFC) http://www.scientificamerican.com/article/is-it-time-to-over...

Re: OpenBSD removes support for non-UTF8 locales

#117

Post by ymse »

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…

I'd be happy just to get rid of DST.

Re: OpenBSD removes support for non-UTF8 locales

#118

Post by fletchowns »

kstrauser wrote: post #63
fletchowns wrote: post #22

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

> My estimate is "approximately zero"

You do realize there is more to switching to metric than just updating the road signs, right?

Think of all the military and space technology that uses inches.

Re: OpenBSD removes support for non-UTF8 locales

#119

Post by adamrt »

scott_karana wrote: post #48
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…

If Imperial keeps getting used, it will get even harder to get rid of it . What kind of argument is this? "It would really hurt to amputate my leg, so let's just wait and let the gangrene go further for now."

> What kind of argument is this?

"it's definitely my knee jerk reaction"

Re: OpenBSD removes support for non-UTF8 locales

#120

Post by rcfox »

jaawn wrote: post #41
fletchowns wrote: post #37

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.

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…

Rounding from 38 to 40 is a difference greater than 5%. Some applications might support that, but I'm sure there are plenty that won't. For example, wood joints have very small tolerances.
Post reply on HN