1 files changed, 0 insertions, 77 deletions
diff --git a/open_issues/glibc/0.4.mdwn b/open_issues/glibc/0.4.mdwn
deleted file mode 100644
index 33ef8f3a..00000000
--- a/open_issues/glibc/0.4.mdwn
+++ /dev/null
@@ -1,77 +0,0 @@
-[[!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
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_glibc open_issue_libpthread]]
-
-Things to consider doing when bumping the glibc SONAME.
-
-There are some comments in the sources, for example `hurd/geteuids.c`: `XXX
-Remove this alias when we bump the libc soname.`
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2012-12-14
-
-In context of [[packaging_libpthread]]/[[libpthread]].
-
-    <pinotree> once libc is switched internally from cthreads to pthreads (thus
-      breaking its BC), may be worth cleanup the hurd-specific exported symbols
-    <tschwinge> pinotree: Yes.  If you already have ideas about what to clean
-      up, feel free to add a new page or a section on open_issues/glibc.
-    <pochu> we're gonna break backwards compatibility in glibc on hurd? that
-      could be the perfect moment to fix the /dev/fd/N problem without adding
-      new RPCs, though we'd probably have to break backwards-compatibility in
-      the exec server IIRC...
-    <tschwinge> pochu: Oh, I have to re-read that discussion, but thanks for
-      reminding!
-
-[[!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