From nobody Wed Jun 22 17:12:14 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9F5D686678A for ; Wed, 22 Jun 2022 17:12:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSqgt002nz3D5P for ; Wed, 22 Jun 2022 17:12:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa29.google.com with SMTP id az35so715193vkb.0 for ; Wed, 22 Jun 2022 10:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OcZnmRCPIwPCXNkcBJLHsLOS+EH+jMYh8k3pd2DRMZM=; b=odEYqcP9mCatB9yYcu6Ms0OoyXCe0h5GamFUBulKq9ftcl172mHSDAjmVkRblqhSJB VkutQUgK8Ir6A5YiXWiO1wf0CNqXKPfH9X+QHyKVDFZB5eFHaMru1hMItIb1jtztNXiS t1L80lK5nVJfNH5LCJ21RD3/SyJr83iPVB8QAoHa79SKKqlfc1YGuuxzvnVThlDcJ2oy kYHfPwthxDg197JRxcO3GWz+rWz/Zp6pqAegTNBOwn7ve0Ql30dg03kQmQQwrp0q8mg8 56lpIZNLe+iyD5qiCm0+vmIt9hX6HLfkIX5qDjFZESGdQBSFZbNzuI/EBTonfrAgQjQ/ QXag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OcZnmRCPIwPCXNkcBJLHsLOS+EH+jMYh8k3pd2DRMZM=; b=oORtVhQUpH8XKQGWuUV01W2J6+5du6mXYchYItPJsU4sOqAj/w3F44aLGUUlSPOutW C7bb3GxgfAL6rSqFtmM/deEzBlI72QSqtdwpYKzJF2uvrC0Y1SabYs1j2H3CWhvmjIdp j6lMzJkn7oMz1NfjGyIrOGxR79Md/iSAAmFGnnuVBy0LLcs3Sx6DEmR1wQTNzBbub15E dMRta+XQWy5lXghmiIpWYyQbx2ndwNLC5dyQRD9ZKk3yrnGD6X+crgAP6YZ0CHWQRa4x W2zXIjM6Z6tJtkzGTTXFoBtW0zBfsVklQkiiIp5cHNCraxiL8xsqSpG1+u0qc3sNZng7 /n6Q== X-Gm-Message-State: AJIora8HMjHhkIFnQl2a7+fSUIebZYN3PHExLngz3zgNAIrihgeL8P7h NQNsRKEADJswesASgkZJEUuqHBRYOphSNf9UNO2UBqWqMsE= X-Google-Smtp-Source: AGRyM1tJOpDGlrr+zvraW6HeQk/SSv5abRPQnCrr3DXFLKMGOsfFPtd0s1+XGq3VSYtgRcFTBrSdrjT+sj+JZyi6uU8= X-Received: by 2002:ac5:cb56:0:b0:35d:f905:e98a with SMTP id s22-20020ac5cb56000000b0035df905e98amr15405549vkl.29.1655917945266; Wed, 22 Jun 2022 10:12:25 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <546C53F4-E30F-4DAF-BE33-B1772A23ABAE@freebsd.org> In-Reply-To: <546C53F4-E30F-4DAF-BE33-B1772A23ABAE@freebsd.org> From: Warner Losh Date: Wed, 22 Jun 2022 11:12:14 -0600 Message-ID: Subject: Re: Updating reboot's default To: Michael Gmelin Cc: "Greg 'groggy' Lehey" , Warner Losh , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000e7bd5e05e20c709e" X-Rspamd-Queue-Id: 4LSqgt002nz3D5P X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=odEYqcP9; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a29) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.94 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.95)[-0.952]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a29:from]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; MLMMJ_DEST(0.00)[freebsd-arch]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --000000000000e7bd5e05e20c709e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 22, 2022 at 1:03 AM Michael Gmelin wrote: > > > On 22. Jun 2022, at 04:03, Warner Losh wrote: > > =EF=BB=BF > > > On Tue, Jun 21, 2022, 6:35 PM Greg 'groggy' Lehey > wrote: > >> On Tuesday, 21 June 2022 at 8:01:58 -0600, Warner Losh wrote: >> > 15 or 20 years ago, we talked about changing the default for reboot fr= om >> > 'right now' to being safe shutdown. There were arguments made against = it >> > due to tiny appliances and such. >> > >> > Time has past, and this oddity has persisted. It's time to revisit tha= t >> > decision. >> > >> > I'd propose that we keep 'fastboot' and 'fasthalt' having the immediat= e >> > behavior. However, the 'reboot' command will switch from '-q' behavior >> to >> > '-r' behavior. >> >> Somehow I hear this echo "If it ain't broke, don't fix it". My >> understanding has always been that shutdown(8) is the program that >> shuts down and maybe reboots the system, while reboot(8) is a quick >> and dirty way to reboot the system, along with halt(8) if you don't >> want to reboot. >> >> So why change this? At the very least you'll confuse people who want >> to use the old method. My guess is that you have some reason that's >> not immediately apparent, but what? >> > > Other systems have the behavior I'm advocating. We are the odd duck. This > means we tend to violate POLA here. And there is no good reason to do thi= s > when fastboot is available. Nobody that advocated to keep this difference > as useful the last time it came up still wants to advocate. Most people > find the behavior annoying and only a vanishingly small minority of peopl= e > like it. In fact, so far nobody has even asked to please not, let alone > come up with a good reason to retain this behavior. So, I'm polling arch@ > to see if anyone like that shows up. > > > Well, to be honest, I=E2=80=99m used to the current behavior and would pr= efer to > keep it (POLA for existing users). I didn=E2=80=99t answer to advocate ag= ainst the > change as > > 1. I have no metric to counter your argument that this is a real problem > for people used to other OSes (neither how many people pick up FreeBSD in > general nor how many are unpleasantly surprised by how `reboot` works) > 2. I will certainly be able to adapt and get used to the new behavior > 3. Given the amount of change in the world right now, it=E2=80=99s a =E2= =80=9Cpick your > battles=E2=80=9D situation. There is and will be so much to suck up, argu= ing about > this with someone who clearly put some thought into it seems like a waste > of everybody=E2=80=99s time. > I posted so I could understand other views, so I'd like to ask some questions if I may. Is your reliance on the current default due to shell and similar scripts you have? Or is it due to your interactive operations? What do you like about the current behavior: How quickly the reboot happens? Or you have a lot of running processes you don't want killed or to have a chance to clean up? What build process do you use to create your FreeBSD images? Images from the RE, buildworld, nanobsd, poudriere, etc... The only thought I've put into this is from my perspective, and while it is often a good reflection of the larger community, there are times there's a mismatch, so I'd like to at least understand why you hold these views. There may be a simple way to accommodate both sides. Warner > Cheers > Michael > > Warner > > > And no, I don't really have an axe to grind in this matter. >> >> Greg >> -- >> Sent from my desktop computer. >> See complete headers for address and phone numbers. >> This message is digitally signed. If your Microsoft mail program >> reports problems, please read http://lemis.com/broken-MUA.php >> > --000000000000e7bd5e05e20c709e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jun 22, 2022 at 1:03 AM Micha= el Gmelin <grembo@freebsd.org&= gt; wrote:


On 22. Jun 2022, at 04:03, Warner Losh &= lt;imp@bsdimp.com&g= t; wrote:

=EF=BB=BF


On Tue, Jun 21, 2022, 6:35 PM Greg 'g= roggy' Lehey <= grog@freebsd.org> wrote:
On Tuesday, 21 June 2022 at=C2=A0 8:01:58 -0600, Warner Los= h wrote:
> 15 or 20 years ago, we talked about changing the default for reboot fr= om
> 'right now' to being safe shutdown. There were arguments made = against it
> due to tiny appliances and such.
>
> Time has past, and this oddity has persisted. It's time to revisit= that
> decision.
>
> I'd propose that we keep 'fastboot' and 'fasthalt'= having the immediate
> behavior. However, the 'reboot' command will switch from '= -q' behavior to
> '-r' behavior.

Somehow I hear this echo "If it ain't broke, don't fix it"= ;.=C2=A0 My
understanding has always been that shutdown(8) is the program that
shuts down and maybe reboots the system, while reboot(8) is a quick
and dirty way to reboot the system, along with halt(8) if you don't
want to reboot.

So why change this?=C2=A0 At the very least you'll confuse people who w= ant
to use the old method.=C2=A0 My guess is that you have some reason that'= ;s
not immediately apparent, but what?

Other systems have the behavior I'm = advocating. We are the odd duck. This means we tend to violate POLA here. A= nd there is no good reason to do this when fastboot is available. Nobody th= at advocated to keep this difference as useful the last time it came up sti= ll wants to advocate. Most people find the behavior annoying and only a van= ishingly small minority of people like it. In fact, so far nobody has even = asked to please not, let alone come up with a good reason to retain this be= havior. So, I'm polling arch@ to see if anyone like that shows up.


W= ell, to be honest, I=E2=80=99m used to the current behavior and would prefe= r to keep it (POLA for existing users). I didn=E2=80=99t answer to advocate= against the change as

1. I have no metric to coun= ter your argument that this is a real problem for people used to other OSes= (neither how many people pick up FreeBSD in general nor how many are unple= asantly surprised by how `reboot` works)
2. I will certainly be a= ble to adapt and get used to the new behavior
3. Given the amount= of change in the world right now, it=E2=80=99s a =E2=80=9Cpick your battle= s=E2=80=9D situation. There is and will be so much to suck up, arguing abou= t this with someone who clearly put some thought into it seems like a waste= of everybody=E2=80=99s time.

I= posted so I could understand other views, so I'd like to ask some ques= tions if I may.

Is your reliance on the current de= fault due to shell and similar scripts you have? Or is it due to your inter= active operations?
What do you like about the current behavior: H= ow quickly the reboot happens? Or you have a lot of running processes you d= on't want killed or to have a chance to clean up?
What build = process do you use to create your FreeBSD images? Images from the RE, build= world, nanobsd, poudriere, etc...

The only thought= I've put into this is from my perspective, and while it is often a goo= d reflection of the larger community, there are times there's a mismatc= h, so I'd like to at least understand why you hold these views. There m= ay be a simple way to accommodate=C2=A0both sides.

Warner
=C2=A0
Cheers
Michael

War= ner=C2=A0


And no, I don't really have an axe to grind in this matter.

Greg
--
Sent from my desktop computer.
See complete headers for address and phone numbers.
This message is digitally signed.=C2=A0 If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.= php
--000000000000e7bd5e05e20c709e--