[HN Gopher] A critical look at NetBSD's installer
___________________________________________________________________
A critical look at NetBSD's installer
Author : jaypatelani
Score : 97 points
Date : 2025-06-04 03:19 UTC (19 hours ago)
(HTM) web link (eerielinux.wordpress.com)
(TXT) w3m dump (eerielinux.wordpress.com)
| rickcarlino wrote:
| I appreciate the Gemini:// cross posting.
| boyter wrote:
| I had never seen this before. Although I am now trying out
| lagrange and seeing what it can do.
|
| Sorry for hijacking the thread on what is a great post, but is
| gemini common these days? This is literally the first time I
| have ever seen it, and it seems fairly interesting, albeit
| deliberately limited.
|
| Annoyingly the learn more about it link
| https://gemini.circumlunar.space/ is now dead, as possibly
| might be protocol.
| trinix912 wrote:
| The cert has expired, but the site is still there if you
| click through the warnings.
|
| Edit: no it just redirects to https://geminiprotocol.net
| which seems to be the new official site
| rickcarlino wrote:
| Many HN users can't seem to get past some minor issues about
| the spec. Despite this, it's a working protocol that has a
| critical mass of real world users, mostly bloggers (which is
| what the spec author mostly had in mind). One of my blogs on
| Gemini has a "like" button and it gets several clicks a week,
| indicating that people are indeed reading my content in
| Gemspace.
| JdeBP wrote:
| Really? Is that actually really true that they cannot get
| past the spec?
|
| Because I followed the Wikipedia article to the article on
| _The Register_. Whoever wrote Wikipedia summarized _El Reg_
| 's entire article as how gemini has been critized for
| excluding people. 1 sentence. But that's only what the
| headline says, for clickbait. The actual article body
| paints a very different picture, including the rather
| subtle (by _Register_ standards) rebuttal of that criticism
| by pointing out that WWW browsers and the Internet are not
| in an everything-is-a-nail-and-I-have-this-hammer
| situation.
|
| So I wonder how true it really _is_ that there 's this wave
| of criticism, and how much that is rather inferred from
| people reading headlines and nothing else beyond them. Like
| the Wikipedia author did.
|
| That said, having discovered the existence of Gemini today,
| I am now wondering how much of a doddle it would be to add
| a gemini UCSPI-TCP server (which would obviously have to
| sit behind something like Hoffmann's sslserver) to
| Bernstein publicfile. The publicfile way would of course
| have a separate off-line tool to turn index.gopher into
| index.gemini, once at content generation time instead of
| over and over at runtime.
|
| Hmmm.
|
| Stop giving me distractions, people! I'm supposed to be
| getting the next djbwares running on NetBSD. (-:
|
| P.S. I have had the GOPHER server that I added to
| publicfile running for some time. I use it to publish a
| not-very-secret list of packages and source archives. It
| gets some quite odd requests in its logs.
| jmclnx wrote:
| Nice, I have to figure out how to add that to my site.
| unethical_ban wrote:
| IIRC it can't even show images, which I see as a big issue.
| I'm usually a fan of alt protocols.
| rickcarlino wrote:
| There are clients that can preload embedded images in
| 2025. Lagrange can handle this via config.
| jmclnx wrote:
| I also like the gemini link, this will be helpful for people on
| old systems :)
|
| Some links:
|
| https://geminiprotocol.net/docs/specification.gmi
|
| https://en.wikipedia.org/wiki/Gemini_(protocol)
| JSR_FDED wrote:
| Great that you took the time to do a thorough and constructive
| write up!
|
| The perspective of an otherwise knowledgeable user who is new to
| something is incredibly valuable.
| sam_lowry_ wrote:
| I wonder how the screenshots were taken. The installer run in a
| VM?
| JdeBP wrote:
| That would be one way to do it, certainly. It's boring, though.
| (-:
|
| There is another. In NetBSD one can, at least according to the
| manual, open the wsdisplay of the relevant terminal and read
| out the display contents, with the WSDISPLAYIO_GETWSCHAR I/O
| control. sysinst is just a full-screen TUI program.
|
| * https://man.netbsd.org/wsdisplay.4
|
| (The manual says that character values are "ASCII", but the
| data structure uses a 16-bit unsigned integer for them. So I
| wonder whether this is UCS-2 or NetBSD has been saddled with
| some 512-entry character set mess from back in the 1990s.)
|
| Presumably there is a third one if the virtual terminal's
| wsdisplay is in graphics mode and one can access its frame
| buffer.
|
| There was also a fourth for the serial console screenshots,
| although they were clearly done the boring way by
| screenshotting a GUI window, as its scrollbars are visible in
| the images. Presumably the terminal emulator at the other end
| of the connection had some sort of direct screen shotting
| functionality. That was definitely something that serial device
| DTE emulator programs in the days of yore _used to_ have.
|
| That's an interesting thought, actually. I wonder whether one
| could do that at all with many Unix/Linux tools, like GNU
| screen in its serial terminal mode. One could with (some of)
| the terminal emulators that used to be available for MS/PC/DR-
| DOS. There would be some "dump screen to file" menu option, or
| in extremis a TSR program that could do that. (-:
| actionfromafar wrote:
| Did not have "being jelaous of NetBSD wscons framework" on my
| bingo card.
|
| How does one make a "screenshot" of a TUI program? The
| classic terminal APIs don't have a "framebuffer" (or
| "textbufffer" I guess) from what I can tell.
|
| I could use such a mechanism to create automated screenshots
| of a TUI program (using Terminal.GUI in this case) for
| documentation generation.
| fredoralive wrote:
| I assume NetBSD supports some sort of multiplexing for the
| local console? In which case it will need to have some sort
| of text buffer for each virtual terminal to maintain state
| when it's off screen, and I guess they've decided to expose
| it to the outside world?
| JdeBP wrote:
| Don't be too envious. Linux kernel virtual terminals have
| "vcsa" devices that one can read for this sort of thing.
| And it's right there in the manual page how one does this.
|
| * https://man7.org/linux/man-pages/man4/vcsa.4.html
|
| They suffer from being straight copies of CGA, which has
| historically had a lot of conflation of boldness and
| brightness, as well as a very limited colour gamut that
| will make you weep at what your 256-colour TUI programs are
| reduced to. The NetBSD ioctl _supposedly_ has a bold
| attribute in a separate field of the structure to a bright
| colour. Which in the backwards-thinking world of terminals
| where some people still have the CGA Think that
| bold=bright, is almost heresy. Still. In 2025. (-:
|
| If you are looking for this sort of thing in a GUI/TUI
| terminal emulator that is a user application program,
| rather than the terminal emulators that are built into the
| NetBSD kernel or into Linux, then that's a different kettle
| of fish entirely. I know of one that provides a direct vcsa
| workalike. I wrote it.
|
| * http://jdebp.info./Softwares/nosh/guide/commands/user-
| vt.xml
|
| GNU screen works by having a server maintaining a buffer,
| and a client that attaches to the server and then renders
| that buffer's contents onto the client's own terminal. So
| _in theory_ one might be able to access the display of GNU
| screen in a similar manner by making something that
| pretends to be a client. But how much of this mechanism
| even operates when GNU screen is in serial terminal mode, I
| don 't know off the top of my head.
|
| The same goes for tmux, of course. And indeed mosh.
| Although the documentation of the actual protocol was a
| not-done to-do item, promised in the early publicity for
| mosh but never delivered, for _years_. I kept checking back
| for quite a while to see whether they 'd documented it as
| promised.
|
| There's at least one GUI terminal emulator that stores its
| scrollback area to file, but only the scrollback area. GUI
| terminal emulators generally do not expose this sort of
| thing, though. It's some complex private data structure in
| the emulator process's memory, usually.
|
| All that said, wscons is a fairly good-looking API.
| Certainly better than the undocumented mess that is fbio.
| actionfromafar wrote:
| Thank you very much. I'll go back to this and do some
| testing.
|
| Maybe also something like tmux capture-
| pane -pS -1000 > tui_snapshot.txt
|
| will work
| topsecret wrote:
| The installer was run in a VM, so presumably that's how
| screenshots were taken.
|
| > Both installations will be in VMs just for the sake of
| convenience.
| gawa wrote:
| That's what I understood as well. Also, the author mentions:
|
| > The installation succeeded, but the system would panic
| during boot. *Bhyve is more of a niche thing and not among
| the hypervisors supported by NetBSD*, [...]
|
| I am guessing what he meant was rather "the support of NetBSD
| (as a guest OS) by the hypervisor Bhyve", because Bhyve is an
| hypervisor running on FreeBSD. Given the other posts on the
| blog, it would not be surprising if the author was daily
| driving FreeBSD while doing this experiment, and Bhyve is
| well maintained and probably the best fit in the BSD world
| for this. I don't even know if OpenBSD's vmm can virtualize
| something else than OpenBSD.
|
| From https://wiki.freebsd.org/bhyve :
|
| > Q: What VM operating systems does bhyve support?
|
| > A: bhyve supports any version of FreeBSD i386/amd64.
| OpenBSD, NetBSD, illumos and GNU/Linux are supported using
| the UEFI and the sysutils/grub2-bhyve port.
| ho_schi wrote:
| On Linux there is the handy _fbgrab_. I guess they have
| something similar.
|
| https://github.com/GunnarMonell/fbgrab
|
| You also can set timeouts and switch between virtual terminals.
|
| PS: I'm love good TUIs. Clean and concise and it is surprising
| how well user can use them. If - they're well made. I think the
| installer of Debian or Linux menuconfig are good examples.
| numpad0 wrote:
| Cheapest HDMI splitters are ~$10 and compressing capture cards
| are ~$5, it's not hard or expensive anymore to capture display
| contents at emergency or illustrative use quality if these
| weren't VM screenshots or taken through OS feature.
| rahen wrote:
| Interesting perspective. sysinst could certainly use better
| ergonomics, but I wonder whether he's really approaching NetBSD
| like a typical user would - someone after a classic Unix
| experience on modern hardware.
|
| With an old-school Unix mindset myself, I've always found the CLI
| installers of OpenBSD and Alpine Linux cleaner, more
| straightforward and in line with that philosophy. Honestly, I'd
| rather see sysinst replaced by something along those lines.
| JdeBP wrote:
| I've had the classic Unix experience. It's not something that a
| typical user of the 21st century would either want or enjoy.
| There was everything from modem line noise to whether it was BS
| or DEL this week that actually erased a character. And yes,
| things like what is pointed out in the article: output from
| other places randomly overwriting the UI of a full-screen
| (curses) program.
|
| We who lived through the classic Unix experience also remember
| how at the time MS/PC/DR-DOS had things that we 300 BPS
| terminal users could but dream of, like an Alt key that just
| worked and highlighted menu option accelerators when one
| pressed it. And function keys that didn't just cause a mess, or
| beeps, or surprise commands to happen.
|
| Typical users of the 21st century would be appalled when faced
| with it. And there's probably no retrocomputing enthusiast that
| is _quite_ that masochistic. (-:
|
| Much of what sysinst does is just farmed out to tar, pkg_add,
| ifconfig, and other programs. It even handily prints their
| command lines at the top of the screen when they are running.
| So someone who wants a CLI rather than a TUI, and _not really_
| the _actual_ "classic Unix experience", could just run those
| programs. And there's probably room for an installer that does
| the same thing as sysinst but in the old text-adventure-game
| style of print-menu-prompt-for-line-with-selection for people
| with printer terminals. (-:
|
| Like AIX 7's installer:
|
| * https://ibm.com/docs/en/aix/7.3.0?topic=system-using-bos-
| men...
|
| But don't knock full screen TUI programs like sysinst. There's
| definitely a place for them, and on the commercial Unices,
| where the vendors had gone to some effort to make the
| installation and configuration programs user-friendly, they
| _were_ the "classic Unix experience". SCO had one, for
| example. They even managed to have it recognize F1 for help.
|
| * https://sco.com/products/openserver6/reviewers_guide2.html
|
| Function keys. F1 for help. This stuff for contemporary Unix
| people was like the "Classic MS-DOS experience", but at the
| time when PC users were using GUI installation programs in
| DOS+Windows 3. (-:
| rahen wrote:
| I'm not sure anyone invoking "classic Unix" is pining for
| modem noise or line printers, though that seems to be how
| you're interpreting it. That's more a caricature of early
| computing than what defines the Unix philosophy or what
| NetBSD preserves.
|
| When I say classic Unix, I really mean "simple software":
|
| - Text-first, scriptable interfaces where tools do one thing
| well and can be composed
|
| - Human-readable configuration in plain files, no XML or
| opaque binary blobs
|
| - Predictable, minimal system design where you can understand
| what's happening under the hood without chasing abstraction
| layers
|
| - Manual pages that matter, and a userspace that favors
| understanding over wizard-driven opacity
|
| - A system that's BSD-like in spirit: clean, coherent,
| documented, and built by people who care more about
| correctness and clarity than flash or trends
|
| This is in contrast to modern Linux distributions where
| systems are often a tangled mess of systemd units, layers of
| more or less obscure daemons and processes, unpredictable
| behaviors, and YAML/JSON/XML-based abstractions that sit
| between you and the actual system.
|
| So no, I'm not glorifying the past or pretending users in
| 2025 would enjoy a serial terminal setup from 1984. I'm
| saying that a clean, simple, consistent, modular Unix, in the
| traditional sense, is still valuable and NetBSD is one of the
| few OSes that still embodies that ethos.
| bitwize wrote:
| That romanticizes a vision of Unix that hasn't existed for
| like four decades, aside from maybe Xenix bitty boxes from
| Radio Shack servicing two terminals in auto shops, video
| stores, and the like. People bought Unix workstation and
| server systems specifically to run large, complex
| applications. Applications that did many things and kept
| their configuration in binary blobs or XML files.
| Stability, security, comprehensiveness, and ease of
| administration are stronger selling points for these
| systems than simplicity.
|
| As an example of how comprehensive beats simple in the real
| world, consider Microsoft Outlook. Not just email, but
| calendaring and contact management. Microsoft's engineers
| discovered that in the business world, these things go
| together and bundled them into one, well-integrated
| program. Outlook ate everybody's lunch, including Windows-
| based mail clients like Eudora. Integration with Exchange
| let these services be provided together on an
| organizational level, fully integrated with Active
| Directory, and Exchange came to dominate email server
| deployments over Unix-based solutions which were more
| piecemeal. Easier to administrate as well.
|
| NetBSD is a fantastic tinkerer's operating system, one of
| the most hackable ones out there. But let's not kid
| ourselves here. The philosophy it supposedly embodies
| hasn't really served real needs in a long time, if ever.
| Customers want solutions, not hacks held together with
| shell and Perl scripts.
| yjftsjthsd-h wrote:
| > As an example of how comprehensive beats simple in the
| real world, consider Microsoft Outlook.
|
| Yes, do consider it: Outlook is great at ticking
| checkboxes, resulting in a product that is widely adopted
| and sucks to use.
| jrockway wrote:
| I agree with that. Modern Unix is a 6-of-one-half-dozen-of-
| another type situation. Yes, terminal emulators and the
| termcap database are improved. But now, the traditional
| Unix user might be surprised at how things are done. I have
| accepted that ... systemd ... manages my networking now
| (ok, it's networkd or something I guess?). But if you can't
| accept that, it's good to have some option that just uses
| ifconfig.
| miladyincontrol wrote:
| > a tangled mess of systemd units
|
| Ironic you use that term when a number of systemd units is
| often the simplest way of cleanly, reliably orchestrating
| services and daemons, doubly so when theres any level of
| complexity or limitations you want to confine one too.
|
| Its cute to romanticize a bunch of scripts to run and
| orchestrate things but its a nightmare I'd not wish upon my
| enemies. Less moving parts, yet conceptually more complex
| to properly manage beyond the basics with far more that can
| and likely will go wrong.
| bitwize wrote:
| A "typical user of the 21st century" does not want to install
| an OS, ever. They use what comes preinstalled on the device.
|
| If an OS has to be installed by the end user, it is niche.
| spookie wrote:
| It's an impossible task to meet what typical 21st century
| users expect. For that, the OS would have to come pre-
| installed.
|
| Furthermore, most typical users today are so entrenched in
| commercial software, and their walled gardens they wouldn't
| even attempt to use an OS without that software.
|
| People don't own their devices anymore.
| hiAndrewQuinn wrote:
| The OpenBSD and Alpine Linux CLI installers are honestly a
| high-water mark for me when it comes to high risk applications
| where getting it wrong might mean a bricked installation. More
| people should book out 20 minutes to just spin up a VM and try
| them out for themselves, to see how nice a good old fashioned
| command line approach can be!
| jmclnx wrote:
| A rather fair review and the partitioning step can be confusing
| to new users. A first time user should read the Guide a few times
| and maybe refer to it during install. It renders fine on a
| smartphone.
|
| https://www.netbsd.org/docs/guide/en/
|
| _One thing to note_ , if you create a separate /usr and/or /var
| partition, y0u really should (must) add this line or similar line
| to /etc/rc.conf
|
| critical_filesystems_local="/var /usr"
|
| otherwise you will get odd boot errors/warnings, Dir order does
| not matter.
| JdeBP wrote:
| For completeness, as I pointed out on the FediVerse: The article
| has things backwards when it comes to partition table schemes.
| It's the _older_ firmwares that place the requirement on what
| partitioning scheme is used; not the newer ones. So the suggested
| change to one of the forms, as it stands, would be telling users
| the wrong thing.
|
| And Ed Maste has confirmed that FreeBSD is quite happy to accept
| non-U.S. keyboard layouts, contrary to the implication that
| NetBSD accepts them where FreeBSD has not. Even more ones, that
| is. (-:
|
| * https://mastodon.social/@emaste/114625612735189948
| hulitu wrote:
| > Yes, since /usr and /var are initially of size 0, one can
| deduce that allocating no space to it will probably make the
| installer discard them
|
| Why would the installer discard them if you created them ? Do
| what i mean, not what i say ?
___________________________________________________________________
(page generated 2025-06-04 23:01 UTC)