Merge remote-tracking branch 'feldtkeller.SCHWINGE/master'
[hurd-web.git] / open_issues / versioning.mdwn
index 69a6cb2..1987b6c 100644 (file)
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013, 2014 Free Software Foundation,
+Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -18,6 +19,8 @@ interfaces means to either remove, or add, or modify an existing interface.
 Modify basically means to remove and then re-add a variant, re-using the former
 name/identifier.
 
+[[!toc]]
+
 
 # [[RPC]]s
 
@@ -45,6 +48,9 @@ desc="Not changed" "87ob7cxbu6.fsf@kepler.schwinge.homeip.net"]] when doing the
 Bump the glibc SONAME to some point, or can do everything with symbol
 versioning?
 
+There are some comments in the sources, for example `hurd/geteuids.c`: `XXX
+Remove this alias when we bump the libc soname.`
+
 
 ### IRC, freenode, #hurd, 2012-12-14
 
@@ -65,3 +71,42 @@ In context of [[packaging_libpthread]]/[[libpthread]].
 
 [[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id
 "4BFA500A.7030502@gmail.com"]].
+
+
+### `time_t` -- Unix Epoch vs. 2038
+
+#### IRC, freenode, #hurd, 2013-12-12
+
+    <azeem> because it gets discussed in #debian-devel for the Linux i386
+      architecture right now: what's the deal with hurd-i386 and the 32bit
+      epoch overflow in 2038?
+    <braunr> what do you mean ?
+    <azeem> braunr: http://lwn.net/Articles/563285/
+    <braunr> ok but what do you mean ?
+    <braunr> i don't think there is anything special with the hurd about that
+    <azeem> well, time_t is 64bit on amd64 AIUI
+    <braunr> it's a signed long
+    <azeem> so maybe the Hurd guys were clever from the start
+    <azeem> k, k
+    <braunr> our big advantage is that we can afford to break things a little
+      without too much trouble
+    <braunr> in a system at work, we use unsigned 32-bit words
+    <braunr> which overflows in 2106
+    <braunr> and we already include funny comments that predict our successors,
+      if any, will probably fail to deal with the problem until short before
+      the overflow :>
+    <azeem> luckily, no nuclear reactors are running the Hurd sofar
+    <braunr> i wonder how the problem will be dealt with though
+    <braunr> ah, openbsd decided to break their abi
+    <azeem> yeah
+    <braunr> that's probably the simplest solution
+    <azeem> "just recompile"
+    <braunr> and they can afford it too
+    <azeem> yeah
+    <braunr> good to see people actually worry about it
+    <azeem> I guess people are getting worried about where Linux embedded is
+      being put into
+    <braunr> they're right about that
+    <azeem> "Please, don't fix the 2038 year issue. I also want to have some
+      job security :)"
+    <braunr> haha