Ars Technica article on FreeBSD new user experience

[Daniel Ebdrup Jensen]

On 4/12/20, Joe Berner <stackyjoe at gmail.com> wrote:
> My 2 cents:
>
> 1) Make video driver detection a bit more straightforward. Or at least make
> it dead simple to figure out which you need to install to get things
> working. I still need 2 or 3 tries with pkg install -f after major driver
> upgrades to get X server working correctly again with all the peripherals.
>
> 2) A wifi tool that's easier to use. wpa_supplicant is fine for those
> already very comfortable with command line stuff, but for unix newbies it's
> very intimidating. wpa_cli is better but still too complicated. An
> interactive CLI tool that lists the SSIDs, lets you pick one, and then
> progressively fill out the required info would help a lot. I remember
> finding comments on the forums saying "just plug it in to ethernet to get
> set up" and that's very inconvenient if not infeasible for a lot of home
> set ups.
>
> 3) The horrible beeping. A newbie who starts out is likely to open up vi on
> rc.conf (or whatever) and be greeted by a sequence of earsplitting system
> beeps as they learn that vi is not vim and some of the things they are used
> to do not work. Them not working is fine, but the beeping feels like a way
> for the system to mock your failure, and quickly goes from annoying to
> enraging. Years later I still remember this!
>
> I don't think a Xorg + GUI are necessary on a default install, but make it
> dead simple for a beginner (say, someone who doesn't know to do pkg search
> $X | less ) to get it set up.
>
> Joe
[snip]

I mentioned this elsewhere in the thread, but video driver detection
can be solved with devmatch(8) for which there is an open issue [1]
that needs help, to add support for radeonkms and amdgpu, and
eventually vboxgfx and vmwgfx for virtualbox and vmware respectively,
plus nouveau if/when that lands and likely others (for example,
rockchip/videocore/et cetera drivers for ARM SBCs/systems) in the
future, as the DRM stack keeps getting bigger and bigger upstream.

As for wireless configuration tools, there's 'bsdconfig wireless',
which uses dialog(1) and therefore works on any terminal, as well as
net-mgmt/wifimgr for GTK, and net/wpa_supplicant_gui/ for Qt.
(Yes, 'bsdconfig wireless' is missing from the man-page, but hopefully
not for long [2])

Your third point seems to be that you might not at that point have
been aware that they're called bell events (specifically, audible bell
events), and are turned off with either the hw.syscons.bell or
kern.vt.enable_bell OIDs in sysctl(8) - so now you know, and knowing
is half the battle. ;)
There is a bigger problem underneath this that speaks to habits that
are in some cases distribution-specific - ie. distributions might use,
for example, Bill Joys version of vi, nvi v1/v2 (started by Keith
Bostic, but contributed to by many others over the years), vim,
Almquist sh, Bourne sh, Debian Almquist sh, some combination thereof
depending on PATH, or even some that I'm forgetting.


[1]: https://github.com/FreeBSDDesktop/kms-drm/issues/68
[2]: https://reviews.freebsd.org/D24378