Haiku monthly activity report - 06/2017

Blog
1

Hey there, it's time for the monthly report again!

This report covers hrev51196-hrev51253.

This is a companion discussion topic for the original entry at https://www.haiku-os.org/blog/pulkomandy/2017-07-03_haiku_monthly_activity_report_june_2017/
1 Like
2

Thanks for another excellent summary of progress made.

Questions regarding time_t and the 2038 bug:
How about 32-bit Haiku? Is the expectation that no-one will run 32-bit Haiku after 2038?

3

For gcc2 haiku, we cannot change it as it would break compatibility with BeOS apps. This is why we did it only for 64-bit versions of Haiku for now. We can change it to 64-bit after R1 for the 32-bit systems (in the R2 ABI). This is still open, and it all depends on the timings.

4

For those who might be wondering, I looked it up and we should now be OK until 4 December 292,277,026,596, or almost 22 times the current age of the universe. After that we’ll have to reset to 128-bit time.

5

I see a problem if we wait till then for the change over.

Y2K caused a mess in 1999 as people have to scramble to fix the problem in time.

Now we see 2038 time problem not being fixed till 2017 when it could have been fixed long ago. Talk about waiting to the last decade or two. Now people are talking as if we have fixed the t_time problem.

Have we not learnt from history!

Next we will send the last million or so years fixing the time to 128 bits when we could fix the problem now!

Will we never learn? :slight_smile:

1 Like
6

Well, we are making the switch 20 years before the deadline. I think not much people were worried about Y2K bug back in 1980. So, we are learning, and when designing new APIs we are now careful of not making the same mistake again.
time_t actually is coming from early UNIX days, long before Y2K bug was even thought about. Now we know that computer systems and API can last for 40 years and more.

7

I have noticed WebPositive likes to crash with HTML5 videos, kind of annoying :slight_smile: