• What made You think You could just kill graphics in singleuser

    From Peter 'PMc' Much@pmc@citylink.dinoex.sub.org to muc.lists.freebsd.stable on Wed Sep 17 12:56:11 2025
    From Newsgroup: muc.lists.freebsd.stable


    Dear Warner,

    after upgrading my desktop 13.5 to 14.3, it suddenly stared at me
    with ascii-art, and in single-user with a horrifying 80x25 resolution.

    I started to experiment. I need a proper resolution to at least get a
    chance to read what the kernel tells me when booting (the mixup in
    log/messages and log/console is usually not intellegible).

    The functionality of the graphics options in loader.conf has always
    stayed obscure to me. Between options like "kern.vt.fb.modes.HDMI-A-1"
    or "vbe_max_resolution", which are hardware dependent and frequently
    change, and multiple different monitors that cannot be switched off
    (because even when unplugged from mains, they still babble to the
    system), it is really a matter of luck to get to something useful.

    So, in short, when graphics didn't appear, I started to search for my
    own mistake. That it could have been turned off deliberately, was
    unimaginable to me.

    Only when I finally gave up that approach, and started the radical
    way, install six clean new systems for analysis (13.5 and 14.3
    each with MBR, GPT and EFI), I noticed that EFI would work in 14.3
    (the machine is old, I didn't know it could even do EFI).

    Then I started to read the published documentation, very thoroughly,
    to finally find a small kind of sidenote that *might*, with some
    understanding, be interpreted as a change in the singleuser hi-res.
    It still didn't tell people what to do about it, but instead send
    them on a paper chase into the source configuration, solveable
    only for those already used to build from source.

    I don't know how long it took me to read all the stuff, but I do know
    that I started to put 14.3 onto the desktop around 2300, and it was
    0600 when completing the hunt.
    This is not acceptable.

    I would have expected a prominent notice in the release notes (that
    is, in each of them, not only in a single minor release), like so:

    "Single-user graphics have been removed from loader. If you
    have a graphics screen and still want to read your kernel messages
    on-screen, do this-and-that..."

    And *AT LEAST* I would have expected an elaboratory notice in UPGRADING.

    Cheers,
    PMc


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Mark Linimon@linimon@portsmon.org to muc.lists.freebsd.stable on Wed Sep 17 07:44:52 2025
    From Newsgroup: muc.lists.freebsd.stable

    I am going to do something I almost never do, and that is
    to speak for someone else: in this instance, Warner.

    Warner and I and a number of other people have been attempting
    to remain calm and patient in the middle of various ongoing
    stressful issues within FreeBSD.

    This kind of snide attack is exactly the kind of "reward"
    we do not deserve. For me, an insinuation that some
    regression was deliberate is insulting and demotivating.

    This is exactly the kind of attitude that drives volunteers
    away from any organization.

    Please consider your words more carefully next time.

    mcl


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Danilo Pecher@danilo.pecher@data-experts.biz to muc.lists.freebsd.stable on Wed Sep 17 15:01:54 2025
    From Newsgroup: muc.lists.freebsd.stable

    I'm not trying to put too fine a point on it, but it might be worth
    thinking why there are so many 'stressful issues' within FreeBSD
    lately. Ever since FBSD12 the system has been the IT equivalent of
    gambling. You might get lucky, you might not. If a new version ends up
    working is a complete crap shoot, even on systems that are several
    years old and should therefore be supported. This lack of reliability
    is the reason why I walked away from it.

    As for your blaming other people for the exodus of volunteers. Sorry,
    but that's a strawman argument. Being a volunteer doesn't mean that
    others have to applaud you for doing a substandard job, and
    substandard jobs have been done within FreeBSD for quite some time.
    Maybe getting your act together is a better method to reduce the
    number of 'stressful issues'.

    I've been a professional programmer for thirty years. The only stress
    I ever had was self-inflicted, when I mucked things up. The usual
    reason was that I pushed stuff out with too little testing, because I prioritized meeting some deadline over spending the neccessary time to
    test and re-test things until I was satisfied with the results.

    hippo

    On Wed, 17 Sept 2025 at 14:45, Mark Linimon <linimon@portsmon.org> wrote:

    I am going to do something I almost never do, and that is
    to speak for someone else: in this instance, Warner.

    Warner and I and a number of other people have been attempting
    to remain calm and patient in the middle of various ongoing
    stressful issues within FreeBSD.

    This kind of snide attack is exactly the kind of "reward"
    we do not deserve. For me, an insinuation that some
    regression was deliberate is insulting and demotivating.

    This is exactly the kind of attitude that drives volunteers
    away from any organization.

    Please consider your words more carefully next time.

    mcl



    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Tomoaki AOKI@junchoon@dec.sakura.ne.jp to muc.lists.freebsd.stable on Wed Sep 17 22:25:26 2025
    From Newsgroup: muc.lists.freebsd.stable

    Sorry, not Warner. ;-)

    On Wed, 17 Sep 2025 12:56:11 +0200
    "Peter 'PMc' Much" <pmc@citylink.dinoex.sub.org> wrote:

    Dear Warner,

    after upgrading my desktop 13.5 to 14.3, it suddenly stared at me
    with ascii-art, and in single-user with a horrifying 80x25 resolution.

    I started to experiment. I need a proper resolution to at least get a
    chance to read what the kernel tells me when booting (the mixup in log/messages and log/console is usually not intellegible).

    The functionality of the graphics options in loader.conf has always
    stayed obscure to me. Between options like "kern.vt.fb.modes.HDMI-A-1"
    or "vbe_max_resolution", which are hardware dependent and frequently
    change, and multiple different monitors that cannot be switched off
    (because even when unplugged from mains, they still babble to the
    system), it is really a matter of luck to get to something useful.

    So, in short, when graphics didn't appear, I started to search for my
    own mistake. That it could have been turned off deliberately, was unimaginable to me.

    Only when I finally gave up that approach, and started the radical
    way, install six clean new systems for analysis (13.5 and 14.3
    each with MBR, GPT and EFI), I noticed that EFI would work in 14.3
    (the machine is old, I didn't know it could even do EFI).

    Then I started to read the published documentation, very thoroughly,
    to finally find a small kind of sidenote that *might*, with some understanding, be interpreted as a change in the singleuser hi-res.
    It still didn't tell people what to do about it, but instead send
    them on a paper chase into the source configuration, solveable
    only for those already used to build from source.

    I don't know how long it took me to read all the stuff, but I do know
    that I started to put 14.3 onto the desktop around 2300, and it was
    0600 when completing the hunt.
    This is not acceptable.

    I would have expected a prominent notice in the release notes (that
    is, in each of them, not only in a single minor release), like so:

    "Single-user graphics have been removed from loader. If you
    have a graphics screen and still want to read your kernel messages
    on-screen, do this-and-that..."

    And *AT LEAST* I would have expected an elaboratory notice in UPGRADING.

    Cheers,
    PMc

    Putting other than boot time graphics mode aside.

    In short, use UEFI if you want graphical beastie.

    In detail, legacy (BIOS) bootcodes are tooo restrictive in size.
    This is because bootcodes in legacy boots are running on "real mode",
    only 1MB of address space including mapped ROM, memory mapped I/O
    and any other reserved area, thus, around 540kB is available.

    This is too small to support everything UEFI bootcode (currently,
    loader.efi itself by default, and before, boot1.efi), which runs
    on 64 (or in rare cases, 32) bit address space.

    So to add (back) anything, something equivalent in size SHALL be
    removed instead.

    IMHO, if graphics mode in legacy boot is MANDATORY for most of users, disallowing Root-on-ZFS boot on legacy BIOS would be the candidate.
    Who wants it?

    So such an angers should go to Intel, as Intel didn't decided to make
    32bit address space at the first place on 8086/8088.
    (In 8bit era, IIUC/IIRC, many CPUs supported address bus width
    doubled with data bus, 16bit.)


    And yes, differences in configurations for vt between backend is
    a pain. But I think it comes from the differences of the mechanism
    that each backends (various different framebuffers) uses.

    If UEFI forcibly designates per-resolution/depth modes to be fixed
    number as mandatory spec, I think things would be much cleaner and
    simpler. Maybe for VGA, VESA (both for legacy BIOS) and whole UEFI.
    Maybe refactoring to integrate configs would be complexed.

    Regards.
    --
    Tomoaki AOKI <junchoon@dec.sakura.ne.jp>


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Peter 'PMc' Much@pmc@citylink.dinoex.sub.org to muc.lists.freebsd.stable on Wed Sep 17 15:38:03 2025
    From Newsgroup: muc.lists.freebsd.stable

    On Wed, Sep 17, 2025 at 07:44:52AM -0500, Mark Linimon wrote:
    ! I am going to do something I almost never do, and that is
    ! to speak for someone else: in this instance, Warner.
    !
    ! Warner and I and a number of other people have been attempting
    ! to remain calm and patient in the middle of various ongoing
    ! stressful issues within FreeBSD.
    !
    ! This kind of snide attack is exactly the kind of "reward"

    Sorry, what kind of "side attack" are You talking about?

    ! we do not deserve. For me, an insinuation that some
    ! regression was deliberate is insulting and demotivating.

    What regression are You taking about?
    I am not insinuating anything, since the commit logs clearly state
    that this was done fully deliberate, after an educated evaluation
    about how best to save some space.

    But Your reaction now is very typical for a certain kind of people
    all busy to protect those in power against those considered plebs,
    even if it requires "alternate facts".

    ! This is exactly the kind of attitude that drives volunteers
    ! away from any organization.

    What in God's name are You talking about ???

    ! Please consider your words more carefully next time.

    Sorry, but why, and in what regard?

    I am not speaking about any regression of any means, nor have I
    intended any insinuation.
    I only spent a night sleepless, to finally find out that it all
    was done deliberately. I don't understand the reasons - there
    certainly are some. But still I want to give as much feedback as
    that this does really hurt. And obviousely I am not amused.

    During the night I was in the process of filing a bug report, but
    I thought I should first do careful and extensive research, like
    testing all the possible combinations, and reading all the documents
    from since 14.0. So I did that, and only by that I could figure out
    that this is a deliberate action, and so I cancelled the bug report.

    But as You don't want such thoroughly researched feedback - so why
    don't you just make the commit logs a secret we ordinary users are
    not allowed to read? Then we can no longer understand what was done
    on purpose, and must file a bug report for everything.

    cheerio,
    PMc


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Joachim Durchholz@joachim@durchholz.org to muc.lists.freebsd.stable on Wed Sep 17 15:48:47 2025
    From Newsgroup: muc.lists.freebsd.stable

    On 17.09.25 15:01, Danilo Pecher wrote:
    As for your blaming other people for the exodus of volunteers. Sorry,
    but that's a strawman argument.

    Not entirely.
    I can't talk about the merit of the factual issues PMc is reporting,
    only about the tone of his message.
    But wow that's agressive. And it essentially blames everything on the
    team being dumb; there is no regard for even the possibility of other
    reasons ("what made you think" is merely a rhetorical device, not
    genuine interest).
    And even if it *was* being done dumbly: It seems that the real complaint
    was that the change wasn't communicated properly, and that's not a fault
    of a single person, but of the way the work is organized. That's
    something that you can discuss without getting personal, and very, very
    smart persons can do dumb stuff if the overall organisation isn't
    tailored towards smart action, or even if it is but the people don't
    have time.

    About walking away from the team: That's more because they are less
    satisfied about what they do. Individual flame messages like the one
    above can constribute to a decision to walk away, but they are rarely
    the main cause; it all depends on whether people get satisfaction and appreciation.

    Just my 5c, back to lurking.

    Regards,
    Jo


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Peter 'PMc' Much@pmc@citylink.dinoex.sub.org to muc.lists.freebsd.stable on Wed Sep 17 15:51:03 2025
    From Newsgroup: muc.lists.freebsd.stable

    On Wed, Sep 17, 2025 at 03:01:54PM +0200, Danilo Pecher wrote:
    ! I'm not trying to put too fine a point on it, but it might be worth
    ! thinking why there are so many 'stressful issues' within FreeBSD
    ! lately. Ever since FBSD12 the system has been the IT equivalent of
    ! gambling. You might get lucky, you might not. If a new version ends up
    ! working is a complete crap shoot, even on systems that are several
    ! years old and should therefore be supported. This lack of reliability
    ! is the reason why I walked away from it.

    Sorry, Danilo, but You didn't get the point. This here is not about
    "stressful items" or whatever.

    It is about a deliberate decision to change system defaults in a
    way as certain commercial powers want it, no matter whether that
    implies beating up some ordinary users like me.


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Tomoaki AOKI@junchoon@dec.sakura.ne.jp to muc.lists.freebsd.stable on Wed Sep 17 23:12:17 2025
    From Newsgroup: muc.lists.freebsd.stable

    On Wed, 17 Sep 2025 15:38:03 +0200
    "Peter 'PMc' Much" <pmc@citylink.dinoex.sub.org> wrote:

    On Wed, Sep 17, 2025 at 07:44:52AM -0500, Mark Linimon wrote:
    ! I am going to do something I almost never do, and that is
    ! to speak for someone else: in this instance, Warner.
    !
    ! Warner and I and a number of other people have been attempting
    ! to remain calm and patient in the middle of various ongoing
    ! stressful issues within FreeBSD.
    !
    ! This kind of snide attack is exactly the kind of "reward"

    Sorry, what kind of "side attack" are You talking about?

    ! we do not deserve. For me, an insinuation that some
    ! regression was deliberate is insulting and demotivating.

    What regression are You taking about?
    I am not insinuating anything, since the commit logs clearly state
    that this was done fully deliberate, after an educated evaluation
    about how best to save some space.

    But Your reaction now is very typical for a certain kind of people
    all busy to protect those in power against those considered plebs,
    even if it requires "alternate facts".

    ! This is exactly the kind of attitude that drives volunteers
    ! away from any organization.

    What in God's name are You talking about ???

    ! Please consider your words more carefully next time.

    Sorry, but why, and in what regard?

    I am not speaking about any regression of any means, nor have I
    intended any insinuation.
    I only spent a night sleepless, to finally find out that it all
    was done deliberately. I don't understand the reasons - there
    certainly are some. But still I want to give as much feedback as
    that this does really hurt. And obviousely I am not amused.

    During the night I was in the process of filing a bug report, but
    I thought I should first do careful and extensive research, like
    testing all the possible combinations, and reading all the documents
    from since 14.0. So I did that, and only by that I could figure out
    that this is a deliberate action, and so I cancelled the bug report.

    But as You don't want such thoroughly researched feedback - so why
    don't you just make the commit logs a secret we ordinary users are
    not allowed to read? Then we can no longer understand what was done
    on purpose, and must file a bug report for everything.

    cheerio,
    PMc

    Just about the last paragraph.
    Commit logs are not a secret. We, regular users who don't have commit
    bit can read the whole bunch of commit log the developers can read
    via cgit.

    https://cgit.freebsd.org/

    There are read only mirrors like GitHub, GitLab and Codeberg, but they restricts items per directories, so cannot track all files via web
    interdace unless you already know its path.

    https://github.com/freebsd/

    https://gitlab.com/FreeBSD/

    https://codeberg.org/freebsd/

    Note that GitHub mirror alone is official web mirror.

    And note that commit logs of stable/* and releng/* (for ports,
    quarterly like 2025Q3) are often truncated, so better to read
    on main branch (aka Current for src, latest for ports).
    In these cases, what committers can read should be the same
    as us.
    --
    Tomoaki AOKI <junchoon@dec.sakura.ne.jp>


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Colin Percival@cperciva@tarsnap.com to muc.lists.freebsd.stable on Wed Sep 17 14:36:55 2025
    From Newsgroup: muc.lists.freebsd.stable

    On 9/17/25 06:51, Peter 'PMc' Much wrote:
    It is about a deliberate decision to change system defaults in a
    way as certain commercial powers want it, no matter whether that
    implies beating up some ordinary users like me.

    Release engineer here. I'm not paid by any nefarious "commercial powers" (although I wouldn't object to getting paid something for the hundreds of
    hours I'm spending on managing this release), and I approved the change.

    When our CPU is pretending to be a CPU from the 1980s there isn't enough
    memory to support everything we'd like to do, and some tradeoffs were
    needed. Warner consulted within the project and I think we picked the
    right tradeoffs.

    The long-term solution here is to just stop using BIOS boot mode. There
    are very few places (mostly obscure virtualization environments) where we
    can't boot EFI at this point.
    --
    Colin Percival
    FreeBSD Release Engineering Lead & EC2 platform maintainer
    Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid



    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Warner Losh@imp@bsdimp.com to muc.lists.freebsd.stable on Wed Sep 17 07:40:43 2025
    From Newsgroup: muc.lists.freebsd.stable

    --0000000000005214b3063f00390d
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable

    On Wed, Sep 17, 2025 at 6:54=E2=80=AFAM Peter 'PMc' Much < pmc@citylink.dinoex.sub.org> wrote:

    On Wed, Sep 17, 2025 at 03:01:54PM +0200, Danilo Pecher wrote:
    ! I'm not trying to put too fine a point on it, but it might be worth
    ! thinking why there are so many 'stressful issues' within FreeBSD
    ! lately. Ever since FBSD12 the system has been the IT equivalent of
    ! gambling. You might get lucky, you might not. If a new version ends up
    ! working is a complete crap shoot, even on systems that are several
    ! years old and should therefore be supported. This lack of reliability
    ! is the reason why I walked away from it.

    Sorry, Danilo, but You didn't get the point. This here is not about "stressful items" or whatever.

    It is about a deliberate decision to change system defaults in a
    way as certain commercial powers want it, no matter whether that
    implies beating up some ordinary users like me.


    man src.conf
    ...
    WITHOUT_LOADER_BIOS_TEXTONLY
    Include graphics, font and video mode support in the i386 and
    amd64 BIOS boot loader.
    ...

    So you can rebuild the boot loader to get this back. As noted elsewhere,
    space is extremely limited on /boot/loader for BIOS systems. The size of
    ZFS has been expanding for years, and something had to give in order to accomodate ZFS growth. ZFS has been adding new crypto and compression algorithms as an astound rate. Due to the boot loader needing to run in a variety of systems (some of which have more limited space than the defaults
    due to their hardware installing BIOS extensions for things like disk
    support needed to boot), the graphics support needed to go by default. Many system will still fit, so enabling the above option will restore this.

    You are correct, though, that I neglected to put it in UPDATING or RELNOTES
    it seems. At least I can't find it right now. That's a fair knock on me.

    Warner

    --0000000000005214b3063f00390d
    Content-Type: text/html; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable

    <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g= mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Sep 17,=
    2025 at 6:54=E2=80=AFAM Peter &#39;PMc&#39; Much &lt;<a href=3D"mailto:pmc= @citylink.dinoex.sub.org">pmc@citylink.dinoex.sub.org</a>&gt; wrote:<br></d= iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord= er-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Sep 17, 2025 a=
    t 03:01:54PM +0200, Danilo Pecher wrote:<br>
    ! I&#39;m not trying to put too fine a point on it, but it might be worth<b=

    ! thinking why there are so many &#39;stressful issues&#39; within FreeBSD<=

    ! lately. Ever since FBSD12 the system has been the IT equivalent of<br>
    ! gambling. You might get lucky, you might not. If a new version ends up<br=

    ! working is a complete crap shoot, even on systems that are several<br>
    ! years old and should therefore be supported. This lack of reliability<br>
    ! is the reason why I walked away from it.<br>

    Sorry, Danilo, but You didn&#39;t get the point. This here is not about<br> &quot;stressful items&quot; or whatever.<br>

    It is about a deliberate decision to change system defaults in a<br>
    way as certain commercial powers want it, no matter whether that<br>
    implies beating up some ordinary users like me.<br></blockquote><div><br></= div><div>man src.conf</div><div>...</div>=C2=A0 =C2=A0 WITHOUT_LOADER_BIOS_= TEXTONLY<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Include graphic=
    s, font and video mode support in the i386 and<br>=C2=A0 =C2=A0 =C2=A0 =C2=
    =A0 =C2=A0 =C2=A0 =C2=A0amd64 BIOS boot loader.<br><div>...</div><div><br><= /div><div>So you can rebuild the boot loader to get this back. As noted els= ewhere, space is extremely limited on /boot/loader for BIOS systems. The si=
    ze of ZFS has been expanding for years, and something had to give in order =
    to accomodate ZFS growth. ZFS has been adding new crypto and compression al= gorithms as an astound rate. Due to the boot loader needing to run in a var= iety of systems (some of which have more limited space than the defaults du=
    e to their hardware installing BIOS extensions for things like disk support=
    needed to boot), the graphics support needed to go by default. Many system=
    will still fit, so enabling the above option will restore this.</div><div>= <br></div><div>You are correct, though, that I neglected to put it in UPDAT= ING or RELNOTES it seems. At least I can&#39;t find it right now. That&#39;=
    s a fair knock on me.</div><div><br></div><div>Warner=C2=A0</div></div></di=


    --0000000000005214b3063f00390d--


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Peter 'PMc' Much@pmc@citylink.dinoex.sub.org to muc.lists.freebsd.stable on Wed Sep 17 16:41:38 2025
    From Newsgroup: muc.lists.freebsd.stable

    On Wed, Sep 17, 2025 at 10:25:26PM +0900, Tomoaki AOKI wrote:

    ! Putting other than boot time graphics mode aside.
    !
    ! In short, use UEFI if you want graphical beastie.

    I don't need beastie (I like it, but dont need it).
    What I *do* need is some 60-90 lines of text in single-user.

    So, if this has worked before (and I formerly went to some lengths
    to make it work, because there are three monitors of different size
    attached, and it should then cleanly switch over to i915kms, and
    then again switch to X), and now it doesn't anymore, that is
    certainly worth noting.

    Then when I finally figure that this is not my own derived configuration falling apart in the new release due to some mistake of mine. No,
    it is something that was done deliberately, but seemingly was kept under
    the carpet.

    ! In detail, legacy (BIOS) bootcodes are tooo restrictive in size.
    ! This is because bootcodes in legacy boots are running on "real mode",
    ! only 1MB of address space including mapped ROM, memory mapped I/O
    ! and any other reserved area, thus, around 540kB is available.
    !
    ! This is too small to support everything UEFI bootcode (currently,
    ! loader.efi itself by default, and before, boot1.efi), which runs
    ! on 64 (or in rare cases, 32) bit address space.
    !
    ! So to add (back) anything, something equivalent in size SHALL be
    ! removed instead.
    !
    ! IMHO, if graphics mode in legacy boot is MANDATORY for most of users,
    ! disallowing Root-on-ZFS boot on legacy BIOS would be the candidate.
    ! Who wants it?

    I don't know. I don't use Root-on-ZFS (on dependables, for safety
    reasons).

    ! So such an angers should go to Intel, as Intel didn't decided to make
    ! 32bit address space at the first place on 8086/8088.
    ! (In 8bit era, IIUC/IIRC, many CPUs supported address bus width
    ! doubled with data bus, 16bit.)

    That is not the point, I build all from source, always, so I have
    no issue whatsoever with adjusting things to my need.
    (But that works only after I come to know that there is a need.)

    ! And yes, differences in configurations for vt between backend is
    ! a pain. But I think it comes from the differences of the mechanism
    ! that each backends (various different framebuffers) uses.

    I think the problem is that I just never managed to study it in-depth. Graphical desktops are not my favourite plaything; I like servers. But
    I have to make my desktop machine working, and I'm happy if it comes
    up on at least two monitors with a proper resolution.

    My point is, specifically in such matters where one isn't even sure if
    one is doing it correctly, it is the more imperative that others who
    change the behaviour, do vocally pronounce that they did so.

    I have no issue with a decision made one way or another, as long
    as somebody tells that something was decided and *that* I possibly
    have to remedy for it. Would be even better if they tell me *how* to
    remedy (but that is optional).

    ! If UEFI forcibly designates per-resolution/depth modes to be fixed
    ! number as mandatory spec, I think things would be much cleaner and
    ! simpler. Maybe for VGA, VESA (both for legacy BIOS) and whole UEFI.
    ! Maybe refactoring to integrate configs would be complexed.

    I understand UEFI even less. (Sadly, I do more and more fail to
    develop a full understanding of every component of the environment.)
    So with UEFI, I'm still just happy when I don't need to use it.

    Cheerio,
    PMc


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Warner Losh@imp@bsdimp.com to muc.lists.freebsd.stable on Wed Sep 17 07:52:55 2025
    From Newsgroup: muc.lists.freebsd.stable

    --000000000000fb8881063f0064da
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable

    On Wed, Sep 17, 2025 at 6:45=E2=80=AFAM Peter 'PMc' Much < pmc@citylink.dinoex.sub.org> wrote:

    Sorry, what kind of "side attack" are You talking about?


    Hot button political issue causing professional info warriors to launch harassment campaigns against members of the project. Needless to say, it's
    a bit stressful, even though I'm not in the main path of these attacks. You never know what the other fellow's day has been like.

    Also, I hadn't intended anything I did around the boot loader to be secret.
    I made a mistake in not documenting the change thoroughly enough, though
    it's easily remedied by building a custom loader. In hindsight somebody
    should have caught it.

    Warner

    --000000000000fb8881063f0064da
    Content-Type: text/html; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable

    <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g= mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Sep 17,=
    2025 at 6:45=E2=80=AFAM Peter &#39;PMc&#39; Much &lt;<a href=3D"mailto:pmc= @citylink.dinoex.sub.org">pmc@citylink.dinoex.sub.org</a>&gt; wrote:<br></d= iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord= er-left:1px solid rgb(204,204,204);padding-left:1ex">Sorry, what kind of &q= uot;side attack&quot; are You talking about?<br></blockquote><div><br></div= ><div>Hot button political issue causing professional info warriors to laun=
    ch harassment=C2=A0campaigns against members of the project. Needless to sa=
    y, it&#39;s a bit stressful, even though I&#39;m not in the main path of th= ese attacks. You never know what the other fellow&#39;s day has been like.<= /div><div><br></div><div>Also, I hadn&#39;t intended anything I did around = the boot loader to be secret. I made a mistake in not documenting the chang=
    e thoroughly enough, though it&#39;s easily remedied by building a custom l= oader. In hindsight somebody should have caught it.</div><div><br></div><di= v>Warner</div></div></div>

    --000000000000fb8881063f0064da--


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Peter 'PMc' Much@pmc@citylink.dinoex.sub.org to muc.lists.freebsd.stable on Wed Sep 17 16:51:30 2025
    From Newsgroup: muc.lists.freebsd.stable

    On Wed, Sep 17, 2025 at 11:12:17PM +0900, Tomoaki AOKI wrote:
    ! On Wed, 17 Sep 2025 15:38:03 +0200

    ! > During the night I was in the process of filing a bug report, but
    ! > I thought I should first do careful and extensive research, like
    ! > testing all the possible combinations, and reading all the documents
    ! > from since 14.0. So I did that, and only by that I could figure out
    ! > that this is a deliberate action, and so I cancelled the bug report.
    ! >
    ! > But as You don't want such thoroughly researched feedback - so why
    ! > don't you just make the commit logs a secret we ordinary users are
    ! > not allowed to read? Then we can no longer understand what was done
    ! > on purpose, and must file a bug report for everything.
    ! >
    ! > cheerio,
    ! > PMc
    !
    ! Just about the last paragraph.
    ! Commit logs are not a secret. We, regular users who don't have commit
    ! bit can read the whole bunch of commit log the developers can read
    ! via cgit.
    !
    ! https://cgit.freebsd.org/

    Indeed I know; I have my own public mirror on my webserver:
    https://gitr.daemon.contact/Mirrors/FreeBSD/

    I am just suggesting, when I am accused of "insinuationg" what is
    written in the commitlog, then one should as well make the commitlog read-protected.

    cheerio,
    PMc


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Peter 'PMc' Much@pmc@citylink.dinoex.sub.org to muc.lists.freebsd.stable on Wed Sep 17 17:33:11 2025
    From Newsgroup: muc.lists.freebsd.stable

    On Wed, Sep 17, 2025 at 02:36:55PM +0000, Colin Percival wrote:
    ! On 9/17/25 06:51, Peter 'PMc' Much wrote:
    ! > It is about a deliberate decision to change system defaults in a
    ! > way as certain commercial powers want it, no matter whether that
    ! > implies beating up some ordinary users like me.
    !
    ! Release engineer here. I'm not paid by any nefarious "commercial powers"
    ! (although I wouldn't object to getting paid something for the hundreds of
    ! hours I'm spending on managing this release), and I approved the change.

    Great! Thanks a lot for responding!

    ! When our CPU is pretending to be a CPU from the 1980s there isn't enough
    ! memory to support everything we'd like to do, and some tradeoffs were
    ! needed. Warner consulted within the project and I think we picked the
    ! right tradeoffs.

    Okay. I have no problem with the decision itself (even if I dont
    really understand the pros and cons), as long as I get to know the
    fact that I can roll my own.

    ! The long-term solution here is to just stop using BIOS boot mode. There
    ! are very few places (mostly obscure virtualization environments) where we
    ! can't boot EFI at this point.

    Just FYI: the dedicated servers which I rent from my hoster can only
    boot MBR. Not even GPT.
    (But then also, I never got the idea to try and run graphics over
    IDRAC. Might actually be possible...)

    But also then, if there were a good statement somewhere, along the
    line of "booting into hi-res will no longer be supported for non UEFI-Installations. If you need to use that, either boot via UEFI
    or compile your own loader.>
    That then would be something in the good old style that catches
    attention, telling us thet something is *NOT* working anymore.

    BTW, I don't know why the release-notes now read like advertisement
    sheets - not even IBM ever did that (with them everything sounded
    like either advertisement or lawyers task, except the release-notes:
    these carried the valuable information about what one can and cannot
    do).

    cheerio,
    PMc


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Mark Linimon@linimon@portsmon.org to muc.lists.freebsd.stable on Wed Sep 17 12:13:30 2025
    From Newsgroup: muc.lists.freebsd.stable

    When I made this post, I was not in possession of all
    the facts.

    Please forget I said anything. I will make a note to
    not post first thing in the morning anymore.

    mcl


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Sulev-Madis Silber@freebsd-stable-freebsd-org730@ketas.si.pri.ee to muc.lists.freebsd.stable on Wed Sep 17 22:09:50 2025
    From Newsgroup: muc.lists.freebsd.stable

    while still on topic slightly
    on 13.*, in bios mode in console. i have red cursor, the bold kernel messages can be sometimes yellow, and i had to switch from new vt back onto deprecated sc because video liked to reset every time i switch consoles. like video turned off, display went i to standby and the came back on after few seconds
    what are all those 3 bugs or features? just my hw? i have never seen anything like this in any of my machines before. or it's a feature? limitation of something? that also made me somehow pissed because this was cosmetic but annoying error
    but yea, just recently i argued over who has even powers in this project and was able to smoke some of the old guys out. i didn't know he still lived. didn't know who he even was. told he stepped down, couldn't handle decisionmakings
    that didn't get things much better either because indeed all decisions keep getting made
    actually the secret changes are worse ones. often this is why (local) government gets cursed on. everyone are like why didn't you tell, why did you make all decisions before telling us
    fbsd has made those decisions and users get pissed
    also look what David Greenman-Lawrence had to say here: https://lists.freebsd.org/archives/freebsd-current/2025-August/008259.html
    that thing also got hooot, the whole pkgbase thing
    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Chris@bsd-lists@bsdforge.com to muc.lists.freebsd.stable on Wed Sep 17 13:06:12 2025
    From Newsgroup: muc.lists.freebsd.stable

    --=_9d09a4c9183942e1993bb4effe598fc5
    Content-Transfer-Encoding: 7bit
    Content-Type: text/plain; charset=US-ASCII;
    format=flowed

    On 2025-09-17 12:09, Sulev-Madis Silber wrote:
    while still on topic slightly

    on 13.*, in bios mode in console. i have red cursor, the bold kernel messages can
    be sometimes yellow, and i had to switch from new vt back onto deprecated sc because video liked to reset every time i switch consoles. like video turned off,
    display went i to standby and the came back on after few seconds

    what are all those 3 bugs or features? just my hw? i have never seen anything like
    this in any of my machines before. or it's a feature? limitation of something?
    that also made me somehow pissed because this was cosmetic but annoying error
    Speaking to the reactions to monitor switching. This is largely due to the OS/drivers polling your hardware and should be expected. Back in the "old days" most
    drivers weren't as sophisticated and commonly simply kept the same
    resolution.
    This is not a bug. :)

    --Chris

    ---8<-------8<-----
    --
    There is no such place as the internet
    --=_9d09a4c9183942e1993bb4effe598fc5
    Content-Transfer-Encoding: 7bit
    Content-Type: application/pgp-keys;
    name=0xE512722F.asc
    Content-Disposition: attachment;
    filename=0xE512722F.asc;
    size=3074

    -----BEGIN PGP PUBLIC KEY BLOCK-----

    mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd
    TEM=
    =oj6y
    -----END PGP PUBLIC KEY BLOCK-----

    --=_9d09a4c9183942e1993bb4effe598fc5--


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Sulev-Madis Silber@freebsd-stable-freebsd-org730@ketas.si.pri.ee to muc.lists.freebsd.stable on Wed Sep 17 23:52:29 2025
    From Newsgroup: muc.lists.freebsd.stable


    On September 17, 2025 11:06:12 PM GMT+03:00, Chris <bsd-lists@bsdforge.com> wrote:
    On 2025-09-17 12:09, Sulev-Madis Silber wrote:
    while still on topic slightly

    on 13.*, in bios mode in console. i have red cursor, the bold kernel messages can
    be sometimes yellow, and i had to switch from new vt back onto deprecated sc >> because video liked to reset every time i switch consoles. like video turned off,
    display went i to standby and the came back on after few seconds

    what are all those 3 bugs or features? just my hw? i have never seen anything like
    this in any of my machines before. or it's a feature? limitation of something?
    that also made me somehow pissed because this was cosmetic but annoying error
    Speaking to the reactions to monitor switching. This is largely due to the >OS/drivers polling your hardware and should be expected. Back in the "old days" most
    drivers weren't as sophisticated and commonly simply kept the same resolution. >This is not a bug. :)

    --Chris

    ---8<-------8<-----

    but does it have to keep blinking all the time? i don't have any different settings in any of those 12 terminals
    maybe that text mode helps me. anyway sc helps me too, but that option will go away
    does it mean it keeps flickering then?
    unsure if it will goes away in uefi machines
    to be honest, there are cases when you need physical console to debug stuff. sometimes you need extra terminal. it quite largely disrupts view if you do ttyv0 <-> ttyv1, and there's always a blank screen and 1s delay each time you switch since now video apparently always has to reset
    either this doesn't happen on uefi, noone uses console, or noone cares?
    imagine if this would happen in x
    i don't know why it has to absolutely happen? even if resolution is effectively same?
    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Sulev-Madis Silber@freebsd-stable-freebsd-org730@ketas.si.pri.ee to muc.lists.freebsd.stable on Thu Sep 18 00:09:02 2025
    From Newsgroup: muc.lists.freebsd.stable

    hw is
    vgapci0@pci0:0:2:0: class=0x030000 rev=0x02 hdr=0x00 vendor=0x8086 device=0x29b2
    subvendor=0x103c subdevice=0x2818
    vendor = 'Intel Corporation'
    device = '82Q35 Express Integrated Graphics Controller'
    class = display
    subclass = VGA
    monitor is some lcd on vga
    and it resets on console switch and i can't find vt option to stop it and put whole console on same mode
    i have researched it and can't find any proper way
    what's the proper fix? or there is none?
    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Peter 'PMc' Much@pmc@citylink.dinoex.sub.org to muc.lists.freebsd.stable on Thu Sep 18 14:11:31 2025
    From Newsgroup: muc.lists.freebsd.stable

    On Wed, Sep 17, 2025 at 07:40:43AM -0700, Warner Losh wrote:
    ! On Wed, Sep 17, 2025 at 6:54rC>AM Peter 'PMc' Much <
    ! pmc@citylink.dinoex.sub.org> wrote:
    !
    ! > On Wed, Sep 17, 2025 at 03:01:54PM +0200, Danilo Pecher wrote:
    ! > ! I'm not trying to put too fine a point on it, but it might be worth
    ! > ! thinking why there are so many 'stressful issues' within FreeBSD
    ! > ! lately. Ever since FBSD12 the system has been the IT equivalent of
    ! > ! gambling. You might get lucky, you might not. If a new version ends up
    ! > ! working is a complete crap shoot, even on systems that are several
    ! > ! years old and should therefore be supported. This lack of reliability
    ! > ! is the reason why I walked away from it.
    ! >
    ! > Sorry, Danilo, but You didn't get the point. This here is not about
    ! > "stressful items" or whatever.
    ! >
    ! > It is about a deliberate decision to change system defaults in a
    ! > way as certain commercial powers want it, no matter whether that
    ! > implies beating up some ordinary users like me.
    ! >
    ! man src.conf
    ! ...
    ! WITHOUT_LOADER_BIOS_TEXTONLY
    ! Include graphics, font and video mode support in the i386 and
    ! amd64 BIOS boot loader.
    ! ...
    Yes, that is what I finally figured out the long way:
    going through all the relnotes, finding a relnote that might be
    somehow related, following the mentioned commit, finding a
    configuration file, understanding that file is the system default
    for src.conf, and then finding this can be configured.
    ! You are correct, though, that I neglected to put it in UPDATING or RELNOTES
    ! it seems. At least I can't find it right now. That's a fair knock on me.
    It is somehow mentioned in 14.2 relnotes, but in a way that gets all
    too easily skipped by quick scanning. In fact I did read them all
    before upgrading, and did not come to understand that this would call
    for any action in my case.
    So this is the point where we might achieve some improvement in the
    future, and since Mark Linimon's reaction was apparently a
    misunderstanding, I am sorry that I then consequentially also
    overreacted.
    cheerio,
    PMc
    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Peter 'PMc' Much@pmc@citylink.dinoex.sub.org to muc.lists.freebsd.stable on Thu Sep 18 14:34:15 2025
    From Newsgroup: muc.lists.freebsd.stable

    On Wed, Sep 17, 2025 at 07:52:55AM -0700, Warner Losh wrote:
    ! On Wed, Sep 17, 2025 at 6:45rC>AM Peter 'PMc' Much <
    ! pmc@citylink.dinoex.sub.org> wrote:
    !
    ! > Sorry, what kind of "side attack" are You talking about?
    ! >
    !
    ! Hot button political issue causing professional info warriors to launch
    ! harassment campaigns against members of the project. Needless to say, it's
    ! a bit stressful, even though I'm not in the main path of these attacks. You
    ! never know what the other fellow's day has been like.
    Okay, then I'm probably not involved, since my political issues mainly
    circle about building bicycle lanes in our village...
    ! Also, I hadn't intended anything I did around the boot loader to be secret.
    ! I made a mistake in not documenting the change thoroughly enough, though
    ! it's easily remedied by building a custom loader. In hindsight somebody
    ! should have caught it.
    Well, from the viewpoint of the observer it appears quite strange:
    One finally finds this brief release note, which typically was skipped
    for irrelevance on first read, and notices that it actually is very
    relevant.
    Then one starts to wonder: sponsored by Netflix? This is not a
    development or bugfixing effort needing sponsorship. It is just
    changing a compile time option.
    Is Netflix now uncapable of compiling the sources by themselves with
    whatever options they would like to have? And do we all have to
    follwo along the changes they impose, only because they can wave
    with a chequebook?
    I do *NOT* say that would be the truth! It is just the THOUGHTS that
    come up from the available input (or lack thereof).
    In fact, I for my part have no idea what the majority of users
    might prefer to have in the loader. I don't even know any longer what
    the majority is actually doing.
    In the last century we had user-groups, we were meeting once a week,
    we talked about and knew almost everything - but this has gone away
    with the advent of "social media" :(
    cheerio,
    PMc
    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Warner Losh@imp@bsdimp.com to muc.lists.freebsd.stable on Thu Sep 18 08:09:12 2025
    From Newsgroup: muc.lists.freebsd.stable

    --000000000000a75857063f13e692
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable

    On Thu, Sep 18, 2025 at 6:36=E2=80=AFAM Peter 'PMc' Much < pmc@citylink.dinoex.sub.org> wrote:

    On Wed, Sep 17, 2025 at 07:52:55AM -0700, Warner Losh wrote:
    ! On Wed, Sep 17, 2025 at 6:45=E2=80=AFAM Peter 'PMc' Much <
    ! pmc@citylink.dinoex.sub.org> wrote:
    !
    ! > Sorry, what kind of "side attack" are You talking about?
    ! >
    !
    ! Hot button political issue causing professional info warriors to launch
    ! harassment campaigns against members of the project. Needless to say,
    it's
    ! a bit stressful, even though I'm not in the main path of these attacks.
    You
    ! never know what the other fellow's day has been like.

    Okay, then I'm probably not involved, since my political issues mainly
    circle about building bicycle lanes in our village...

    ! Also, I hadn't intended anything I did around the boot loader to be
    secret.
    ! I made a mistake in not documenting the change thoroughly enough, thoug=
    h
    ! it's easily remedied by building a custom loader. In hindsight somebody
    ! should have caught it.

    Well, from the viewpoint of the observer it appears quite strange:
    One finally finds this brief release note, which typically was skipped
    for irrelevance on first read, and notices that it actually is very
    relevant.

    Then one starts to wonder: sponsored by Netflix? This is not a
    development or bugfixing effort needing sponsorship. It is just
    changing a compile time option.
    Is Netflix now uncapable of compiling the sources by themselves with
    whatever options they would like to have? And do we all have to
    follwo along the changes they impose, only because they can wave
    with a chequebook?


    This doesn't follow, and is gratuitously insulting. The setting / feature
    was changed in the best interest of the largest number of users in the community as BIOS booting starts to sunset. ZFS keeps growing, and we need
    the space so that we don't have silent failures on some OpenZFS imports
    that bring in a newer compression or crypto algorithm that gets too close
    to the line (there's not an exact hard limit due to runtime stack usage
    being a factor).

    Netflix pays me to maintain the boot loader. Part of that is to make sure
    it works for the largest number of people. BIOS has a hard limit, and after consultation with others in the community, we made the hard choice here.
    See the discussion at https://lists.freebsd.org/archives/freebsd-arch/2024-October/000792.html
    This wasn't a convenience for Netflix: We build FreeBSD with dozens of
    options for our systems. One more would take me less time to add/remove
    than it took me to write this paragraph.

    I do *NOT* say that would be the truth! It is just the THOUGHTS that
    come up from the available input (or lack thereof).


    Not all thoughts need to be shared. We're a community and in this together. Sharing thoughts that allege bad faith or bad dealing is corrosive to the community, especially when done so without any real evidence of motivation.

    Warner


    In fact, I for my part have no idea what the majority of users
    might prefer to have in the loader. I don't even know any longer what
    the majority is actually doing.
    In the last century we had user-groups, we were meeting once a week,
    we talked about and knew almost everything - but this has gone away
    with the advent of "social media" :(


    cheerio,
    PMc


    --000000000000a75857063f13e692
    Content-Type: text/html; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable

    <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g= mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Sep 18,=
    2025 at 6:36=E2=80=AFAM Peter &#39;PMc&#39; Much &lt;<a href=3D"mailto:pmc= @citylink.dinoex.sub.org">pmc@citylink.dinoex.sub.org</a>&gt; wrote:<br></d= iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord= er-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Sep 17, 2025 a=
    t 07:52:55AM -0700, Warner Losh wrote:<br>
    ! On Wed, Sep 17, 2025 at 6:45=E2=80=AFAM Peter &#39;PMc&#39; Much &lt;<br>
    ! <a href=3D"mailto:pmc@citylink.dinoex.sub.org" target=3D"_blank">pmc@city= link.dinoex.sub.org</a>&gt; wrote:<br>
    ! <br>
    ! &gt; Sorry, what kind of &quot;side attack&quot; are You talking about?<b=

    ! &gt;<br>
    ! <br>
    ! Hot button political issue causing professional info warriors to launch<b=

    ! harassment campaigns against members of the project. Needless to say, it&= #39;s<br>
    ! a bit stressful, even though I&#39;m not in the main path of these attack=
    s. You<br>
    ! never know what the other fellow&#39;s day has been like.<br>

    Okay, then I&#39;m probably not involved, since my political issues mainly<=

    circle about building bicycle lanes in our village...<br>

    ! Also, I hadn&#39;t intended anything I did around the boot loader to be s= ecret.<br>
    ! I made a mistake in not documenting the change thoroughly enough, though<=

    ! it&#39;s easily remedied by building a custom loader. In hindsight somebo= dy<br>
    ! should have caught it.<br>

    Well, from the viewpoint of the observer it appears quite strange:<br>
    One finally finds this brief release note, which typically was skipped<br>
    for irrelevance on first read, and notices that it actually is very<br> relevant. <br>

    Then one starts to wonder: sponsored by Netflix? This is not a<br>
    development or bugfixing effort needing sponsorship. It is just<br>
    changing a compile time option.<br>
    Is Netflix now uncapable of compiling the sources by themselves with<br> whatever options they would like to have? And do we all have to<br>
    follwo along the changes they impose, only because they can wave<br>
    with a chequebook?<br></blockquote><div><br></div><div>This doesn&#39;t fol= low, and is gratuitously=C2=A0insulting. The setting / feature was changed =
    in the best interest of the largest number of users in the community as BIO=
    S booting starts to sunset. ZFS keeps growing, and we need the space so tha=
    t we don&#39;t have silent failures on some OpenZFS imports that bring in a=
    newer compression or crypto algorithm that gets too close to the line (the= re&#39;s not an exact hard limit due to runtime stack usage being a factor)= .</div><div><br></div><div>Netflix pays me to maintain the boot loader. Par=
    t of that is to make sure it works for the largest number of people. BIOS h=
    as a hard limit, and after consultation with others in the community, we ma=
    de the hard choice here. See the discussion at <a href=3D"https://lists.fre= ebsd.org/archives/freebsd-arch/2024-October/000792.html">https://lists.free= bsd.org/archives/freebsd-arch/2024-October/000792.html</a> This wasn&#39;t =
    a convenience for Netflix: We build FreeBSD with dozens of options for our = systems. One more would take me less time to add/remove than it took me to = write this paragraph.</div><div><br></div><blockquote class=3D"gmail_quote"=
    style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p= adding-left:1ex">I do *NOT* say that would be the truth! It is just the THO= UGHTS that<br>
    come up from the available input (or lack thereof).<br></blockquote><div><b= r></div><div>Not all thoughts need to be shared. We&#39;re a community and =
    in this together. Sharing thoughts that allege bad faith or bad dealing is = corrosive to the community, especially when done so without any real eviden=
    ce of motivation.</div><div><br></div><div>Warner</div><div>=C2=A0</div><bl= ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef= t:1px solid rgb(204,204,204);padding-left:1ex">
    In fact, I for my part have no idea what the majority of users<br>
    might prefer to have in the loader. I don&#39;t even know any longer what<b=

    the majority is actually doing.<br>
    In the last century we had user-groups, we were meeting once a week,<br>
    we talked about and knew almost everything - but this has gone away<br>
    with the advent of &quot;social media&quot; :(<br>


    cheerio,<br>
    PMc<br>
    </blockquote></div></div>

    --000000000000a75857063f13e692--


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Sulev-Madis Silber@freebsd-stable-freebsd-org730@ketas.si.pri.ee to muc.lists.freebsd.stable on Fri Sep 19 00:22:06 2025
    From Newsgroup: muc.lists.freebsd.stable

    how do we avoid stepping on that rake?
    this always tends come up every so often
    decisions get made, noone tells, until it goes live
    local governmental processes are very good at this. but here it is quite similar
    local governmental process that made someone very pissed in my town was when trying to drive a car out of front gate, it wasn't possible as someone started digging there seemingly out of nowhere just a ~hour earlier
    while at national level, it was told that taxes won't go up, later they did and reason to lie on live video was supposedly that this was unpopular decision. what it looked like, was giving a middle finger
    i was reading at that bootloader story and apparently it has going on for a long time in many variations. until it slapped someone in the face so to say. oh and reactions would be similar with irl slaps. either no reaction or last thing you ever did. fortunately you can't kill anyone via tcp/ip yet
    i'm giving up on that video issue i have i think. somehow the vt needs to reset video despite resolution is same and that's it. user experience of that is a broken system. could be technical marvel
    i think many don't even talk about all the issues they encounter. that doesn't mean they accept it. they could insult the decisionmakers behind they backs, including the fact that it wasn't allowed to tell it. the fact that fbsd also has some kind of coc now doesn't do anything to those "dinner table" talks
    no way to fix, eh, isn't it?
    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2