From owner-freebsd-questions@freebsd.org Mon Feb 5 16:32:34 2018 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4ACA3EDA3E9 for ; Mon, 5 Feb 2018 16:32:34 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ABFB07ADDA for ; Mon, 5 Feb 2018 16:32:33 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([92.195.213.55]) by mrelayeu.kundenserver.de (mreue002 [212.227.15.167]) with ESMTPA (Nemesis) id 0Lup4D-1ermAN0i93-0100bE; Mon, 05 Feb 2018 17:32:26 +0100 Date: Mon, 5 Feb 2018 17:32:25 +0100 From: Polytropon To: Frank Leonhardt Cc: freebsd-questions@freebsd.org Subject: Re: Response to Meltdown and Spectre Message-Id: <20180205173225.9d144902.freebsd@edvax.de> In-Reply-To: <9db8908e8c86efddcab5b768fcde1f24@roundcube.fjl.org.uk> References: <044e62f7-69ca-71fe-34a8-5c5cafc06f08@yahoo.com> <0520dd84-c00c-fbf2-da1c-f6ff4c63739d@yahoo.com> <20180203224612.GA10517@milliways.localdomain> <51178.108.68.160.114.1517699531.squirrel@cosmo.uchicago.edu> <53029.108.68.160.114.1517707316.squirrel@cosmo.uchicago.edu> <20180205143720.d4d98011.freebsd@edvax.de> <20180205155721.GA2938@c720-r314251> <9db8908e8c86efddcab5b768fcde1f24@roundcube.fjl.org.uk> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:jIJYK+YJ0EWwYSH5YDnJqj1VDn0+FBkli/Byjlw8Rvz1qVWABXd 4RBB1Fu8DRspRR5riiW2wCvcISb56sHHkwLqLPiv3HrykAK11SrInIQZzQSG1F+9Sx5o77s qFMko6xqkX12Y8Qk0OvOK0gaVrSfJBStqOjIGBryVDv+7bfs81xSCD1ekPohEx9Vc+Dgit4 VwGN/oq42xfk0RK59NEZg== X-UI-Out-Filterresults: notjunk:1;V01:K0:3/iHtpju/ns=:NwusWKBht0LIFCpk2OpIhq 0tMWsh2MoKEaA4RXipgt+Tatf8qOaApkjCZBhKzLKaqIu1keVjVe6/Z5W3b+unQLwpa17oo5z NVVM1dKmbaI09kACMhNd6xZUX+H6LwNoRu7ISEm5+xVAvjGvuqtwcp1OP+gRctYnjfFPC8oTS WAmzjIkVADUsy7Rwr/cVWodrrnwQWlOLrzrv+n6OtJFEFsQEDLyActgASnQkT698Z9wtht2ch H5Ue933hqqOlGb6A0kRGWGK1+KOxzumVTduHQ8CkSjwH1avXUQ1EXHBmKPuvzEkJN3DSDknC/ 2MvZW6wO+QKy+aEEiZsT3rW67kPGmtrY7M5KmfoeYXX0kJ2rKdaT8JZRLdqoiDKeOy+IMjHpN UAoi8koZraNlVdnirmwykD6hCTmhmxJaXkxK04XW/ci+MW4aTDsUkQun2E/HNilUj59DmGnn/ EsfR7ldJrCqGiDQOZoIyfIS6k9YUJDO+GAMQAgFqTkBQQDHhGBGwehYIK6mRF5RQ/ebG0VNhz MGRxEgP9Uh8R+zxWwN/J8y8tX5bwZHWbaJsrPnu7XAUMI4wW5nn+CpLfN5I1oDapNVJWklK4u C0iaNpCOGe2RnL0fbaJcARucVb2yxWFAzbO2VikymHFL6RePj0r47N9kAZcoe9U1x7nA53mZY dqw0swTGSOb5se7kKvxN9EXIXW3C1A7XYccn8/Kle2PruXMG7WfLpsLPv3Icg1+h8tvSZlTPZ sE55S49Uo3VkPgqsj6o7Jc6f3QZNc2jIhorIoQV8dkVphJTPvYoYgfSkRL8= X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 16:32:34 -0000 On Mon, 05 Feb 2018 16:19:43 +0000, Frank Leonhardt wrote: > On 2018-02-05 15:57, Matthias Apitz wrote: > > El d=EDa lunes, febrero 05, 2018 a las 02:37:20p. m. +0100, Polytropon= =20 > > escribi=F3: > >=20 > >> > For all production server I run any reboot that is not scheduled by = admins > >> > is ultimate disaster, so it is equivalent to "bricked" machine. That > >> > hardware can not be further used as production server, but "mere" fa= ct or > >> > reboot is ultimate disaster itself. > >>=20 > >> While this is not the established meaning of "bricked", it it > >> definitely an understandable (!) interpretation of the term. > >=20 > > For me "bricked" in addition to "unusable" means: there is no software > > way any more to change the fault because the hardware does not boot up > > into a state where it could read(...) any attempts to change somethinb.= =20 > > The > > device is now "dark" and does not communicate anymore by no means. > >=20 > > Only a hardware change (for example replace some chip) would help. >=20 > I'd go further - something is only bricked to me when I can't fix it=20 > using a rework station. It's been done... >=20 > HOWEVER, Polytropon et al make a very good point - if the software=20 > update means the device is no longer usable for its intended purpose=20 > then it might as well have bricked it. The effect is the same. That's exactly what I wanted to express: A device like a server is a machine that is specified and expected (!) to work within certain margins. Those can include processing power, I/O throughput, in conclusion downtime, reliability, performance (power utilized per $) and so on. If a software update changes this situation - and not needlessly turns it into an unbootable piece of electronic garbage -, the machine leaves those margins and can no longer be trusted in a production environment. It's not bricked per se (does still boot, does still run), but can be treated as if it was - it needs to be removed from the installation and replaced by something else. Basically, it's up to your defintion of "works as intended". Especially in production server environments, downtime is a very important thing. NB: Downtime always means "unplanned downtime", because planned downtime is "maintenance period". :-) --=20 Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...