Feedback please: foundation of a laptop and desktop work group

[Deleted member 81054]

It's definitely the latter.

And the reasoning is plenty obvious: it would add a gigabyte or more to the installer's size for no good reason - the GUI can be installed later, over the Internet connection.

The installation media doesn't have to include the "package" any more than it has to include any other "optional" components.

However, arguing that it should be there -- even if it then instantiates a network connection to a remote repository (even one that the user is maintaining) -- simplifies setting up a system (isn't that the ultimate goal? To make it easier for folks to adopt FreeBSD as their system?). It's only a few characters of text on a screen to say "these packages require access to a repository" -- with a description (HELP) of what that means/entails.

The current installer makes a point of asking for a hostname, early on -- before the user has even indicated that his box WILL be routed!

As to building the installer ON a GUI, there have been movements in this direction since... forever. But, all seem to just try to give the appearance of a GUI instead of the functionality that it provides.

[And, I would advocate for getting the installer RIGHT before disking around with window dressing -- even if that window dressing makes the process easier (e.g., having a window that shows what the installer is actually DOING would be a godsend in troubleshooting what it has FAILED to do!)]

 

[astyle]

having a window that shows what the installer is actually DOING would be a godsend in troubleshooting what it has FAILED to do!)]

The text-based installer actually does show errors that show up on the TTY through the ncurses!

 

[Deleted member 81054]

The text-based installer actually does show errors that show up on the TTY through the ncurses!

Errors get routed to the console. But, you don't get to see what COMMANDS the installer is invoking (because the installer is just a shell over existing command line utilities).

E.g., I should be able to look at what the installer does for the "automatic/assisted" partitioning of the disk and figure out what I need to do when "manually" partitioning the disk. And, be able to verify which steps it will perform for me vs. those that I will be expected to perform.

 

[linimon@]

So fwiw I (as wiki-admin) made some minor changes to the wiki article (nothing substantial, just to make it more FreeBSD-wiki-flavored).

But what I found while I was messing around there is that there were N laptops missing from CategoryLaptop. I have now fixed that. https://wiki.freebsd.org/CategoryLaptop now includes 130 hardware entries.

Clearly these entries are not an authoritative list of laptops/tablets that are known to work on FreeBSD; more contributions are welcome. Contact wiki-admin@ if you would like an account.

 

[linimon@]

Also in terms of Bugzilla PRs, traditionally things affecting only laptop/desktop users have been assigned to "multimedia@FreeBSD.org". OTOH this is one of our mailing lists that is mostly inactive except for having PRs assigned to it. But it can still be useful for browsing PRs:

https://bugs.freebsd.org/bugzilla/b...d=759705&query_format=advanced&resolution=---

Current count is 51.

The Bugzilla team has never really separated "laptop" issues out further than this. So, for instance, we do not have a way to easily track "having trouble installing on laptop xyz". If that is something that we want to do, please include bugmeister@ in the loop. Thanks.

 

[cmoerz]

It suggests subscribing to the freebsd-desktop list to stay up to date, but looking at the archive it's pretty busy and not all traffic relates to this workgroup. If there are other ways to make sure I don't miss progress on this workshop, I'd love to hear about it. Otherwise, I'll try and subscribe and filter out the 'noise' with some procmail rules.

Hi Martens,

thanks for the feedback. I can relate and we may switch to a dedicated mailing list if we manage to show that there is enough interest. So far, I was the only one wondering whether we should set up our own mailing list, hence I agreed with bapt@ that we should first gauge the interest before moving this anywhere else.

And as linimon points out, there are alternatives, that may be worth considering. We'll figure out a better way together!

In the meantime, I'm prefixing everything I send to the list with [LDWG] to help with the filtering.

So, your feedback is well noted and I am happy to hear you're interested in the matter! If you can actively participate and engage - even better!

 

[astyle]

E.g., I should be able to look at what the installer does for the "automatic/assisted" partitioning of the disk and figure out what I need to do when "manually" partitioning the disk. And, be able to verify which steps it will perform for me vs. those that I will be expected to perform.

If you want to do manual installation of FreeBSD, the installer does give you the option to drop into a shell. All the utilities are avaiable (the installer merely automates them), but it's on you to read the manpages and troubleshoot the errors. The basic installation pattern is not that different from Linux.

Once you install the OS enough times, you'd have a grasp on what comes first, second, etc. You'd also have a grasp on what can be done later, what can be skipped altogether. Some people are motivated enough to learn about the process and write their own installer with all the features - that's how Open Source works. At this point, however, there's not that many people working on this. Dev resources need to be prioritized and directed.

So you got a chicken-and-egg problem: Learn to live with what you can get, or do your own homework/learning and write your own awesome installer that you can submit for consideration.

 

[Deleted member 81054]

All the utilities are avaiable (the installer merely automates them), but it's on you to read the manpages and troubleshoot the errors.

Yes, but if you could see what the installer was doing, then you would KNOW what YOU have to do! Because it would have to perform every step that would be required of you!

Amusing that the first thing a new user would be exposed to wouldn't be a "development priority"!

[Yes, installers are notoriously buggy. Try coercing the installer to fail to unpack the tarballs and then RESTART the process for an obvious bug! :> ]

 

[T-Aoki]

Because it would have to perform every step that would be required of you!

Exactly. But it's NOT to install "OS default" GUI.

Installer SHALL do everything the admin (not limited with the computer's, but also more prioritized with the organization's or even enterprize's admin) wanto to install/configure. Yes, would be still incomplete.
The less the OS defaults to install, the better for the admins'es choices.

Admins can choose whatever in the ports tree. If they want DEs, they can choose from anything in ports tree, such as Mate, Compiz, Xfce, CDE, KDE5, Gnome and others. Admins can choose not to install DEs but simple WMs such as twm, afterstep, fvwm and so on. Admins can even choose no GUIs.

It SHALL be completely on admins, NOT FreeBSD project.

What FreeBSD project should do for better desktop experiences would be to make properly configured metaports which allows to be usable "just installed". Of course, install contains using official pkgs but also building via ports with local non-default options.

 

[astyle]

Yes, but if you could see what the installer was doing, then you would KNOW what YOU have to do! Because it would have to perform every step that would be required of you!

or, you can look at what the installer is doing, figure out how to read the source code for the installer, and play with those commands in the shell.

You can either buy a pre-assembled PC from Dell, or learn how to assemble your own machine from aftermarket parts that you decide on. And if the PSU's wattage rating is too low for the parts that you did assemble yourself, you have no warranty protections, just yourself to blame for not checking the wattage of your rig.

 

[Deleted member 81054]

or, you can look at what the installer is doing, figure out how to read the source code for the installer, and play with those commands in the shell.

Of course I can. But, if they were scrolling by in a separate "console window", I could just look over and NOTICE what I needed to know, without having to unpack tarballs (onto some OTHER system) and troubleshoot someone else's code.

The point is to make the experience easier for novices and experts, alike.

 

[astyle]

Of course I can. But, if they were scrolling by in a separate "console window", I could just look over and NOTICE what I needed to know, without having to unpack tarballs (onto some OTHER system) and troubleshoot someone else's code.

The point is to make the experience easier for novices and experts, alike.

If you can write an installer like that, and demo it, that would be nice.

There was someone who did write an installer script for a KDE desktop, and got that script accepted into ports.

My point is, there is a playbook for getting features you want. And yes, it involves rolling up your own sleeves and doing some dirty work yourself.

 

[Deleted member 81054]

And yes, it involves rolling up your own sleeves and doing some dirty work yourself.

As time is always limited, I have to ask where MINE is best used. E.g., porting an application (that someone else is unlikely to be able to do) or writing an installer (that others have apparently already decided they COULD do!)

 

[Espionage724]

I have notes here on how I set-up FreeBSD for a desktop: https://wiki.realmofespionage.xyz/bsd:freebsd_14.1_xfce

I like performance! After years of using GNOME, I'm liking Xfce and think it's the best balance between lightweight and eye-candy while not being a pure WM. General Greybird looks great, but being able to pull-off Windows 95 style with Chicago95 is amazing, and I haven't liked the idea of theming the OS since XP and Windows Blinds days (it feels like I can theme Xfce and not have it randomly break later)

 

[khorben]

Hi everyone,
About a year ago, I created a graphical version of bsdinstall (the current installer for FreeBSD) which re-uses the code of the current installer, basically replacing the dialog tool (bsddialog) with a different version I wrote in Gtk+. I have created a video illustrating it, and presented it at AsiaBSDCon 2024 (Work-in-Progress session) and at BSDCan 2024 (Lightning Talks).
In the meantime, Alfonso Siciliano has been working on additional options to the installer (link in Italian) allowing the selection of a desktop environment during the installation phase.
I believe it should be possible to combine both initiatives, and improve the general experience for less technical users willing to try FreeBSD.

 

[cmoerz]

In case you did not notice, we have a date and time set for our first call for the Laptop and Desktop Workgroup: we will start December 16, 10AM PT / 1PM ET / 6PM UTC.

Here are some heads up on this matter:

• We will use Jitsi to host and run the call: Call link.
• Please be advised that we plan to record our calls and publish the recordings on YouTube afterward.
• Anyone interested is welcome to join through the link

Here is a preliminary agenda for our first call:

1. Housekeeping
2. Why, How, What
   • Who am I (I, as an we as each participant) and why am I doing this? Quick Introduction
   • operational aspects: monthly calls, every nth Monday
   • discussions on the mailing list offline, otherwise during the call
3. Charter - DISCUSSION
4. Initial list of Laptop and Desktop Gaps - DISCUSSION
   • what are we missing?
   • what is the most important?
   • who/what do we need to achieve it?
5. Agenda for future calls
   • for example, add: news section
6. Next steps

I recommend checking the wiki page now and then for any relevant updates. I'll do my best to keep it updated with relevant areas of interests and any necessary changes to ensure we have a productive call.

LaptopDesktopWorkingGroup - FreeBSD Wiki

 

[Espionage724]

Just an idea, but scheduler guys would be strongly wanted here.

Current default sced_ule seems to focus on server workloads and known not to be good enough at desktop/laptop workloads. For example, kern.sched.preempt_thresh is too low by default and the default of (I've lost track with, but heard from someone) PC-BSD, 224, works much better on responding to user interactions for desktop/laptop use cases.

I did vblank_mode=0 glxgears and had all sorts of hitching when moving the window on Xfce desktop and 5k FPS with default 48. Upped to 224 and it seems fine without hitching and 6K FPS.

I tried it on fresh reboots for that, but seemingly starting the session on 48 and sysctl changing it to 224 still had the hitching on the same session (I needed the reboot to 224 for the improvement).

Edit: This may have been caused with drm-61-kmod; doing it on 14.2 with drm-515-kmod seems fine.

 

[kpedersen]

basically replacing the dialog tool (bsddialog) with a different version I wrote in Gtk+. I have created a video illustrating it, and presented it at AsiaBSDCon 2024 (Work-in-Progress session) and at BSDCan 2024 (Lightning Talks).

Ah, I didn't see this before. Whilst I am pretty loath of dragging in something as massive as Gtk and Xorg or as unstable as Wayland for a program which really is as simple as formatting the disks, extracting a couple of tarballs and copying across a bootloader, this does look pretty nicely done.

We don't even have libdrm in base (and sadly nothing to replace vgl(3)), otherwise perhaps a kms/framebuffer version of dialog could be implemented (in a similar way to yours) to avoid the complexity of the much larger display stacks.

cmoerz, I notice in the LaptopDesktop working group agenda, there is a lot of mention of graphics related ideas. Perhaps one agenda item to underpin them is getting a fundamental graphics API back into FreeBSD? Perhaps an api similar to the old vgl but sitting ontop of the more modern libdrm? It wouldn't be too much of a technical challenge and would open up a lot of doors in a more sustainable way than pulling a load of shite dependencies into the FreeBSD base install.

I believe it should be possible to combine both initiatives, and improve the general experience for less technical users willing to try FreeBSD.

Setting high expectations for non-technical users with a slick graphical installer, only to be left with either a command prompt base install, or a half finished Gnome / KDE desktop lacking even a working network manager... doesn't feel correct as an approach. I feel it will just shift their complaints sideways and they still won't be happy to engage with FreeBSD.

 

[Deleted member 81054]

Setting high expectations for non-technical users with a slick graphical installer, only to be left with either a command prompt base install, or a half finished Gnome / KDE desktop lacking even a working network manager... doesn't feel correct as an approach.

You don't need graphics to "impress". Rather, windowed so you can (easily) show the stream of commands being issued by the installer -- and their results -- in a way that allows the user to shift the focus TO that "console window" to look back over what was done and what happened (instead of just letting stderr scribble over the screen).

There is (was?) a package called screen() that was one of my favorite tools for interacting with the text console. Instead of coarsely splitting a text console (as it did), imagine creating a (text) console window that is partially visible along the bottom (?) edge of the screen annotated to make it easy for the user to access -- "Press ^G to select console window".

 

[kpedersen]

You don't need graphics to "impress". [...] There is (was?) a package called screen() that was one of my favorite tools for interacting with the text console.

I don't think screen or tmux are going to "impress" new users. They are generally of the mindset that anything that isn't a visual raster is "old" and "scary".

And for experienced users, they are kind of redundant anyway. OpenBSD's installer is a fantastic example of ease of use (pretty much just hold down "Enter" during the entire process) and flexibility (any prompt takes '!' which will spawn a shell instance for manual work).

Weirdly, Red Hat's cli mode of the installer (anaconda?) uses tmux to break it up into windows. It just feels kind of messy and scrappy. That said, had they shown a tiny bit more restraint with the terminal features they over-consume, it would have worked pretty well over serial.

 

[T-Aoki]

As "real" GUIs quite strongly depends on graphics hardwares (considering FreeBSD is often wanted to run on too few CPU powered computers that software rendering like scfb or vesa, maximum hardware acceleration available on the exact computer is almost mandatory), I don't think "read GUIs" good enough things.

Yes, I'm old enough guy that need to purchase Accelerated X for usable (acceptable speed) X11 environment on 486DX4-100 class or Pentium 66 class with ISA or VLB based Graphics accelerator, if I recall correctly.

Instead, improvements of ncurses-based "demi-(fake-)GUI" would be better.
Work like DEs, stop, revert and redo anything with blazingly quick response, menus (including pull downs) which does not require manuals and documents (self-contained enough, gray-out and disallow nonsense selections), easily switch vtys with good navigations (actual progresses on steps, detailed logs of what's running, ...).

Again, recently, attempting to install FreeBSD on poor-performanced "boards" with ARM or RISC-V seems to be increasing. For them, GUI installer "on the hardware" would be clearly overkill.

And back to GUI installers, I want to recommend people developing it to focus on "installer for creating 100%-configured-for-target-cards" on mighty amd64 DEs, preferrably with emulators to test before setting the created media into actual boards. It would be quite helpful for them.

 

[cracauer@]

As "real" GUIs quite strongly depends on graphics hardwares (considering FreeBSD is often wanted to run on too few CPU powered computers that software rendering like scfb or vesa, maximum hardware acceleration available on the exact computer is almost mandatory), I don't think "read GUIs" good enough things.

Yes, I'm old enough guy that need to purchase Accelerated X for usable (acceptable speed) X11 environment on 486DX4-100 class or Pentium 66 class with ISA or VLB based Graphics accelerator, if I recall correctly.

Instead, improvements of ncurses-based "demi-(fake-)GUI" would be better.
Work like DEs, stop, revert and redo anything with blazingly quick response, menus (including pull downs) which does not require manuals and documents (self-contained enough, gray-out and disallow nonsense selections), easily switch vtys with good navigations (actual progresses on steps, detailed logs of what's running, ...).

Again, recently, attempting to install FreeBSD on poor-performanced "boards" with ARM or RISC-V seems to be increasing. For them, GUI installer "on the hardware" would be clearly overkill.

And back to GUI installers, I want to recommend people developing it to focus on "installer for creating 100%-configured-for-target-cards" on mighty amd64 DEs, preferrably with emulators to test before setting the created media into actual boards. It would be quite helpful for them.

That is my impression, too.

FreeBSD increasingly gets installed on extremely low spec or outright crippled computers.

 

[kpedersen]

As "real" GUIs quite strongly depends on graphics hardwares (considering FreeBSD is often wanted to run on too few CPU powered computers that software rendering like scfb or vesa, maximum hardware acceleration available on the exact computer is almost mandatory), I don't think "read GUIs" good enough things.

FreeBSD increasingly gets installed on extremely low spec or outright crippled computers.

This may be beyond the scope of the "Laptop and desktop" working group. Mainly because these machines (SoC, ancient, exotic) will not really be suitable for general workstations and certainly not what a FreeBSD "newbie" would (hopefully) be using.

That said, I agree entirely with you both. In some ways I wonder if a thorough manual installation guide added to the handbook could solve this issue. Generally these machines need very custom steps (especially SoC) anyway that no installer would be suitable for. And whilst I have installed manually from scratch a number of times, I am *still* finding small tweaks that the installer performs that I missed out on.

 

[cracauer@]

This may be beyond the scope of the "Laptop and desktop" working group. Mainly because these machines (SoC, ancient, exotic) will not really be suitable for general workstations.

Older is no problem, as long as it was a real computer originally. Crippled is a problem, especially if it is 12 years old and was a crippled computer when new.

 

[Deleted member 81054]

I don't think screen or tmux are going to "impress" new users. They are generally of the mindset that anything that isn't a visual raster is "old" and "scary".

And for experienced users, they are kind of redundant anyway. OpenBSD's installer is a fantastic example of ease of use (pretty much just hold down "Enter" during the entire process) and flexibility (any prompt takes '!' which will spawn a shell instance for manual work).

Weirdly, Red Hat's cli mode of the installer (anaconda?) uses tmux to break it up into windows. It just feels kind of messy and scrappy. That said, had they shown a tiny bit more restraint with the terminal features they over-consume, it would have worked pretty well over serial.

The goal isn't to "impress" but, rather, to make the installer easier to understand in its actions, mistakes, etc.

If anything "goes wrong" (or "unexpectedly") during the install, the NEW user is clueless as to how to proceed -- because he has no way of understanding which SPECIFIC commands the installer was invoking (and stderr to the console is mucked up by the installers presence). The installer acts as if there was a high cost to every character displayed on the screen!

[E.g., would it kill you to indicate whether the hostname is expected to contain the domain name, as well? Or, to alert the user of how he will have to address that issue if he chooses NOT to specify a domain name (e.g., pop up a separate dialog informing him of what he must do in whichever of those cases is the "exception"). And, is it SO important to ask for a hostname that early in the install process -- when you don't even know if the system WILL install on the hardware? So, any repeated attempts -- because of problems -- force the user to again specify said hostname... cuz who knows what the consequences will be if it is NOT specified and the install WORKS, this time!]

There are issues to face regarding what (video) hardware you want to support as well as the control channel (console vs. serial port). Addressing every combination with the lowest set of dependant features limits your solutions. And, the more varied the solutions, the more development effort to create.

I started running FreeBSD with 0.9 (and NetBSD with 0.8). I gave up on the 14.1 install simply because there were too many "things" I would have to investigate in order to work around the problems the installer was having as well as understanding which "steps" it might not be completing in the different use cases.

I can peruse the sources. OR, I could have inspected a list of commands (invoked by the installer as it was issuing them) to see what it was trying to do in one case and what it was failing to do in another.

OR, I can go back to my NetBSD hosts, knowing exactly (albeit from experience) what the steps would be. (I can build a working system in just a dozen minutes, including installing all the sources and dragging /etc -- and /usr/pkg/etc -- over from another working system)

Remember, you are likely catering to users from other FOSS offerings. So, they probably have some idea of what is supposed to happen -- but, not FreeBSD's variations on that "script". This is especially true as folks can't seem to agree on a consistent set of names for things that would simplify porting personal experiences from one OS to another (as well as tools that don't behave the same from one OS to another -- despite sources being available for each!).