While the medium may have evolved from floppy disks to DVDs and USB flash drives, the overall process of installing an operating system onto a desktop computer has been more or less the same since the 1980s. In a broad sense you could say most OS installers require more clicking than typing these days, but on the whole, not a lot has really changed. Of course, that doesn’t mean there isn’t room for improvement.
Among the long list of projects detailed in FreeBSD’s April to June 2021 Status Report is a brief update on an experimental installer developed by [Yang Zhong]. In an effort to make the installation of FreeBSD a bit more user friendly, the new installer does away with the classic terminal interface and fully embraces the modern web-centric design paradigm. Once the user has booted into the live OS, they simply need to point the browser to the loopback address at any time to access the installer’s GUI.
Now that alone wouldn’t be particularly groundbreaking. After all, Google has implemented an entire operating system with web frameworks in Chrome OS, so is making the installer a web app really that much of a stretch? But what makes [Yang]’s installer so interesting is that the web interface isn’t limited to just the local machine, it can be accessed by any browser on the network.
That means you can put the install disc for FreeBSD into a headless machine on your network, and use the browser on your laptop or even smartphone to access the installer. The Graybeards will point out that savvy users have always been able to access the text installer from another computer over SSH, but even the most staunch Luddite has to admit that simply opening a browser on whatever device you have handy and pointing it to the target machine’s IP address is a big usability improvement.
While the software appears complete enough to get through a basic installation, we should remind readers these are still early days. There’s currently no authentication in place, so once you’re booted into the live environment, anyone on the network can format your drives and start the install process.
Some sections of the GUI aren’t fully functional either, with the occasional note from [Yang] popping up to explain what does and doesn’t work. For example, the manual network configuration panel currently only works with WiFi interfaces, as that’s all he personally has to test with. Quite a modern installer, indeed.
Some would argue that part of what makes alternative operating systems like Linux and BSD appealing is the fact that they can happily run on older hardware, so we imagine the idea of an installer using a memory-hungry web browser to present its interface won’t go over well with many users. In our testing, the experimental installer ISO won’t even boot unless it detected at least 4 GB of RAM onboard. But it’s certainly an interesting experiment, and something to keep an eye on as it matures.
[Thanks to Michael for the tip.]
Perhaps it is limited bfor people looking for niche hardware requirements, but for modern computers and users who want to try out something new/different, it sounds like a good step forward. It’s not the new default, so choosing the best tool for the job still applies.
The cheeky bastard in me would point out that you also can tunnel the X display server over ssh and use some installer like Debians gui one like that.
In fact, I’m pretty sure that X tunneling in itself was shown in a article here less than a month ago.
Granted my bias is from “agile developers” insisting even lightweight and simple programs like a disk flasher or IM chat client needs to have their graphical user interface based on a limping behemoth of a lobotomized web browser with accompanying excessive resource usage.
But I also got a Colin Chapman outlook on how programs should use computer resources, which is ever more important in a age where we’re told to rein in our energy usage, so there’s that.
To be fair, the OS installer has a pretty sane expectation of having the machine to itself, so resource requirements become a fairly binary “enough or not”.
An HTTP server can be really tiny, and this offloads the complicated UI rendering (and even layout, which X didn’t do) to the client web browser, so this is actually a pretty ingenious idea for providing an install wizard with a very minimal footprint. I could easily see something like this being used on light-weight distributions — even non-gui headless server ones.
As long as this stays optional, I can perfectly live without it!
Why can’t they figure out how to update an OS (minor or major update) without rebooting? Is it that hard to swap over to the new portions of the operating system without shutting down? I feel like there could be a fail safe set of drivers and executables the OS could hand off to while the core OS is upgraded, and then hand control back, without having to close all applications and restart the whole OS.
Assuming you could restart all of the daemons without losing significant state, you still need to replace the running kernel. It would be a HUGE task, and the only real benefits would be cosmetic (biger uptime).
Think about the number of systems people don’t restart for months at a time, for various reasons, which can’t install critical security patches. Now, you could say that’s their choice and they must face the consequences, but much like those that choose to skip vaccinations, they spread viruses and malware, support ransomed networks, and generally contribute to all bad actors that operate to hurt us. If these patches could instantly be deployed without requiring a disruption to the end user, it would be huge.
I run those kind of systems and, trust me (as much as you can some random comment on the inter webs), the “various reasons” matter. A lot. As do the numbers and risk. Don’t make the mistake of thinking we don’t pay significant attention to what’s going on and the impact upon us.
Having some random vendor applying some random, (untested – of course I trust you) patch at some random time to my systems is not a recipie for stabiity. For example, I give you: patch Tuesday – even if it stays up (ie: are your printers working yet)
Take cues from Virtual machines?
A virtual machine can be based on multiple physical ones. This means one can be taken down for repairs / upgrades, while the virtual machine keeps running.
Could you have a second kernel, on a single PC? For example, in a virtual container?
Start up new instance, transfer services. Option to then patch old kernel, and transfer back.
There have been a couple projects to hotpatch the kernel, but those are specific in what parts of it they can touch. Almost everything else is easy enough to restart just the updated service.
The problem with trying to do this generally is that OSs are like spaghetti, where everything impacts everything else. Not to mention that it’s vitally important for the system to be in a predictable state. Kernel updates Change that state, and trying to fix that on a running kernel is essentially impossible.
You can update the entire OS without rebooting… with the exception of the kernel. Like others describe, it’s a sophisticated task. However, the type of kernel best suited to do this is a microkernel like the Windows kernel. Ironically, Microsoft chooses to reboot for even minor changes instead of restarting services.
Lots of Windows driver stuff is in the kernel (file system, device driver, directx kernel, etc.).
Windows 10 architecture is called “hybrid kernel”. Nicht Fisch, nicht Fleisch.
Running freebsd-update fetch and freebsd-update install will get you updated, and only pester for a reboot if a new kernel is part of it.
This exists: https://ubuntu.com/security/livepatch
Solaris had this over two decades ago with Web Start.
while I certainly warmly welcome new tinkery ways to tackle known tasks, I want to add my 2 points.
* since ever I absolutely loved being able to perform OS installs in an absolutely isolated way: local readonly boot media with all needed files (package archives) on it. This experiment pushes the trend further towards “if you want to install a computer, you are required to have a running computer (meeting not-so-minimal requirements)” reads “chicken-and-egg problem”;
* the feared aspect of “bloat” is highly dependant on the specific usage of HTML’n’spices: will a simple and humble webbrowser be sufficient or is a top-notch-hog webbrowser mandatory? (reads lynx/Netscape1.0 w. HTML1.0 or Chromium/Firefox w. HTML5+JavaScript+cookies+…) see also HAD vs. RetroHAD for a hands-on experience;
Bonus aspect: we are talking sort of “network installs” so isn’t automating webbrowser/GUI things a real pain?
Independently on how many interactive choices/dataentries are to be done for an OS install and how much wallclock time the whole thing takes, I like to do them all in one relatively short timeslice “at once” (not scattered all over the whole duration of the install so I’m forced to babysit it all the time)
Useful for a headless system, but a real security problem if it’s on by default.
Shouldn’t be too bad if it’s just the install medium that has this feature (so not the whole OS once installed), and if it’s only on the local network though, right?
It should only permit connections from localhost by default; then it would be fine to have enabled by default. Local network without any auth is still not great as then anyone (including malware on other devices) can format your disks while you’re using the live disk to fix an issue or maybe even in the middle of your install. It might even be innocent (someone else in the office was also installing and typed the wrong IP).
A local network can be a home with few devices that you trust, but it could also be an entire college campus with dorms and public computer labs. Local network isn’t always trusted.
Old Sun hardware from the 90’s, was super simple: Press STOP+A and type “boot net – install” or just “boot net” for a diskless client that runs everything from RAM and NFS.
It revolved around rarpd/bootd/dhcpd, tftpd, bootparamd, and nfsd
Machine requests an IP address locally, these days it is via DHCP but it started out with RARP.
Machine connects to the local TFTP server and downloads a boot loader or kernel.
Machine connects to the local bootparam server to learn where the shares can be found.
Machine mounts remote NFS shares and either installs a new OS interactive or Noninteractive over the WAN!
I could point out all the security issues with the above, but the one liner would be “Far too much trust”
I would point out that you just called it “super simple” before pointing out you need need to setup a dedicated server to make it work. You basically described PXE with more steps.
IIRC JumpStart server was point-and-drool easy to set up.
Later (sun4m and newer) Suns came with no installed OS and would netboot out of the box. The box had the MAC and hostid on a barcode sticker, so an admin could use a keyboard wedge barcode scanner to assign a new machine to an employee via JumpStart without opening the box.
When the machine was unboxed and powered up, it would immediately start the OS install and configure its identity for its user.
The final few Sun workstations had the hostid and MAC on a removable smart card. It was no longer necessary to scan the box on a hardware upgrade or replacement, just swap out the card and power on the machine.
“even the most staunch Luddite has to admit that simply opening a browser on whatever device you have handy and pointing it to the target machine’s IP address is a big usability improvement.”
I guess I’m a stauncher Luddite than expected, this is a minor usability improvement at best. Clicking a browser and typing an IP seems like one step more than clicking an installer, and if you’re installing an OS you should probably be an advanced enough user to click a non-browser icon. The remote launch is interesting, and may be useful for remote family support assuming you have a path to their network.
There’s a big assumption in that quote that using a browser to do something is unquestionably a technological *advance*. Not fawning over it it makes someone a Luddite. Every CLI I’ve seen “advanced” to a browser or a dedicated GUI made it less flexible/configurable, harder to access any moderate to advanced features, and more resource intensive. Google’s spent a lot of PR convincing people that moving everything to a browser (their playing field) is a good thing, I guess good for them that it’s working?
All that said, moving things to a browser can make things more accessible to new users, which *can be* good.
Yes, but the CLI is all complicated and computer-y. Configuring things with a browser interface is much easier.
People who understand how computers work and aren’t afraid of the CLI are luddites.
It’s easy to be snide when you’ve got a ton of experience, but it seems that you, like the developers of bsdinstall, fail to realize that not everyone who installs FreeBSD knows the system inside and out. A Web-based installer is a fine experiment for someone to undertake, but it’s not something that the FreeBSD team need to be making a priority at this time. They need to get their text-mode installer sorted out first.
To say that bsdinstall is god-awful is a slanderous affront to god-awful things everywhere. Merely “understand[ing] how computers work” and not being “afraid of the CLI” don’t help the experience of wading through that morass. Slackware 2.3’s installer in 1995 was far more usable than FreeBSD 13.0-RELEASE’s in 2021. (I say this not to damn the Slackware installer with faint praise, but to underscore the fact that FreeBSD is over a quarter-century behind the curve in terms of usability.)
So they can now do (some of) what OpenSUSE Linux users have been doing for over a decade? 🙄
One of the reasons I used it. The command line and GUI were both easy to use.
What’s needed is an installer that records what you do you can save it and edit or run it later. I just went through a Linux hell session yesterday. I needed a fresh custom instance of Raspberry Pi OS on a headless Raspberry Pi Zero W. I had to dig out by crib sheets describing step-by-step the install procedure. What a waste of time. Yeah, I could write a script (I have done that for OpenBSD installs on production iron), but why should I have to?
While I’d personally probably prefer to do a remote headless install over ssh rather than via a web browser, as a long time FreeBSD user (since 1997) who knows the system pretty intimately, I’ve also gone blind in those years inbetween, so being able to use a web browser from another computer with a proper screen-reader would be a huge out-of-the-box improvement for me.