From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 20 May 2014 10:04:05 -0400 To: 9fans@9fans.net Message-ID: <1c303148ec8dc74c876330176c2fa54c@mikro.quanstro.net> In-Reply-To: <3A01CE35-B176-4A24-B3D4-24AB0874BB48@9srv.net> References: <92606a17ce255a2e74049e4090d948b3@proxima.alt.za> <36c5eca0f06e9acbe2fac19067f457d8@ladd.quanstro.net> <20140519195016.B21E6B827@mail.bitblocks.com> <3a6dcbf0845989d60e627ad4e5df4313@ladd.quanstro.net> <3A01CE35-B176-4A24-B3D4-24AB0874BB48@9srv.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] syscall 53 Topicbox-Message-UUID: ea06fd62-ead8-11e9-9d60-3106f5b1d025 > > That said, the problems were due (IMHO) to a limitation in the > > update mechanism, not to the inclusion of a new system call. > > This is true depending on how you define "update mechanism". > A simple note from whoever made the decision to push the > change out to the effect of "hey, we're going to add a new > syscall, update your kernels before pulling new binaries" a > while before the push would have been sufficient. technology doesn't solve human communiction problems. here's the Official Meme. simply s/spam/update issues/g and you're good: https://craphound.com/spamsolutions.txt - erik