Anaconda’s new "Web UI" (Fedora Magazine)
Garrett LeSage has written an in-depth article for Fedora Magazine about a new web-based user interface (UI) for Fedora's Anaconda installer, planned to ship with Fedora 42. The article looks at the rationale for moving from GTK 3 to a web-based UI, provides a number of screenshots and demo screencasts, as well as instructions on trying out the new installer with Fedora Rawhide.
Posted Nov 12, 2024 19:27 UTC (Tue)
by davisr (guest, #154260)
[Link] (22 responses)
Posted Nov 12, 2024 20:23 UTC (Tue)
by kreijack (guest, #43513)
[Link] (18 responses)
Even tough would I agree with you, I think also that some more deeper analysis is required on the following topics:
- a browser needs a lot of dependencies; if we are already in a world where even a simple PC is powerful enough to use a WEB interface for everything, is it time to re-evaluate the chrome os idea ?
- is writing a Javascript UI simpler than a GTK UI, or is GTK more complex than needed ? In the past I developed with GTK, and I felt the gtk functions name a bit too verbose.
- personally for something that doesn't need speed, python + qt (pyside) is my favorite toolkit, and it is quite portable. I don't know the equivalent for GTK, but I think it should exists . The point is: is python + qt {/gtk}better or worse than a browser based GUI ?
- recently I re-wrote a non-banal program from python+qt to c++ + qt; I was impressed by the fact that the code size (in term of number of line) was still comparable thanks due to the new c++ recently achievements. However the need to compile before run is still a big disadvantage.
My feeling is that the switch from GTK to a web interface was due more than the complexity of writing (a non trivial) program in C, than the benefit of a WEB ui interface. There are a lot of better alternatives that require less resource than a browser like:
Thoughts ?
(a new GTK vs QT and/or C vs python vs C++ flame war is coming :-) )
Posted Nov 12, 2024 20:29 UTC (Tue)
by intelfx (subscriber, #130118)
[Link] (13 responses)
Anaconda _is_ written in Python, though. Gtk in fact does have bindings for a huge set of languages, thanks to the entire GLib ecosystem thing.
Posted Nov 12, 2024 22:00 UTC (Tue)
by kreijack (guest, #43513)
[Link] (8 responses)
> Anaconda _is_ written in Python, though. Gtk in fact does have bindings for a huge set of languages, thanks to the entire GLib ecosystem thing.
True... I didn't do my homework :-(
So, the only other explanation is that I am too old to understand why an HTML based gui is more attractive than a python/GTK based one....
Posted Nov 13, 2024 2:05 UTC (Wed)
by intelfx (subscriber, #130118)
[Link] (3 responses)
As someone in a sibling comment said, it's likely that web-devs are extremely easier to come by than someone proficient in Gtk.
According to the article, it's also "easier to update and maintain" than a Gtk desktop application, and while it makes no technical sense — sadly, web technologies are simply where all the mindshare is. It's literally "more attractive", much to the disappointment of those of us who prefer actual native applications.
Posted Nov 13, 2024 6:43 UTC (Wed)
by Lennie (subscriber, #49641)
[Link] (2 responses)
In Debian the steps, everything on the screen is the same in the text UI-based installer.
Debian basically has a questions/decision tree system for the user to answer to know what actions to do, you can use a GUI or text UI or even CLI-like UI to ask/answer the same questions (or use a bootstrap 'preseed' config file to skip the question/answer).
I think when it comes to web interfaces, I think it would maybe be useful to have a web interface to help make a preseed file to help with automating installing lots of systems.
[1] https://www.debian.org/releases/bookworm/example-preseed.txt
Posted Nov 13, 2024 12:42 UTC (Wed)
by m4rtink (guest, #95458)
[Link]
Anaconda also has a TUI - it can be seen on this older screenshot from Fedora Magazine for example:
It is also possible to fully automate the installation using kickstart:
Other things can be configured via boot options:
Or configuration files:
GUI is only one of the possible ways of interacting with the installer. :)
Posted Nov 13, 2024 14:38 UTC (Wed)
by smcv (subscriber, #53363)
[Link]
The reason Debian eventually gained one is: internationalization. For languages that are written with a small alphabet (Latin, Cyrillic, Greek) it's fairly easy to set up a TUI in the console character grid, but for languages with lots of characters (notably Chinese/Japanese/Korean) or languages that rely on letter-shaping (Arabic), you really need a fully-featured graphics library to be able to draw legible text.
Making new users feel more at home ("this looks difficult, like a thing for hackers" vs. "this looks a bit like Windows/macOS, how hard can it be?") is a side benefit of offering a GUI installer, but quite an important one IMO: first impressions do matter.
Posted Nov 13, 2024 2:05 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
Yeah, I think this is a generational thing, when you think of a GUI app you think of UI toolkits like GTK/Qt/Win32/Cocoa/etc. but over the last decade or so the development standards have flipped and now the vast vast majority of new GUI app development uses web tech (HTML/CSS/JS) and the majority uses some Single-Page-App (SPA) framework like React/Angular/Vue/etc or in this case the in-house framework PatternFly. I think the reasoning has flipped, if you want a GUI the simplest and most well trodden way is using web tech and only if special needs justify it do you use a traditional UI toolkit like GTK or Qt, the path for running Firefox in kiosk mode is well trodden and it makes your app network agnostic, run locally, run remotely, same difference. Firefox replaces the Xserver in modern computing ;-)
As far as how many developers are competent in web vs GTK, there are hundreds of thousands, probably millions of people who are competent developers with web tech, with a vibrant ecosystem supporting it, the number of people worldwide who can program with GTK (in python or C or anything) could probably fit on a single (large) passenger train.
Posted Nov 13, 2024 14:29 UTC (Wed)
by jzb (editor, #7867)
[Link] (2 responses)
I'm curious if you read the article or Garrett's response in the comments? The article explained in some detail why they wanted to pursue this as a web UI rather than GTK. Here's a snippet: GTK 3 is still currently maintained, but it’s old and showing its age. It won’t be maintained forever. Porting to GTK 4 (and possibly GNOME’s special widget set, libadwaita) will require a lot of effort to adapt to the changes and would require a massive effort to rewrite much of the frontend, especially as Anaconda has many custom GTK widgets. Since we’d likely have to rewrite a lot of the frontend anyway, we took another approach and have taken advantage of the modularization efforts to retool the frontend to have a web-based interface instead. The Cockpit team has been providing a web-based interface for Linux systems for managing systems for many years in the Cockpit web console, so it made sense to reuse Cockpit as a base and its web-based widget set, PatternFly, as a starting point for the next generation of Anaconda too.
Posted Nov 15, 2024 18:38 UTC (Fri)
by kreijack (guest, #43513)
[Link] (1 responses)
Not really, the article explained that in any case they had to rewrote a lot of code, so switching to a web base front end was no so expensive; but the same is true for switching to (e.g.) rust based code (o whichever toolkit you prefer).
I have to point out that I am not arguing the fedora decision; I am only wondering if we reached the point were writing a (non trivial) gui in a web browser is (absolutely) better than writing a gui in C/C++ in a case where *the "remote access" is not a "first" requirement*.
I want to be very clear to a point, I programmed a javascript UI (very simple for what matters), and I found it a friendly language to program. However my feeling was also that due to the lack a lot of "safety" (e.g. type checking) that other language provides, it is not good for big program; at least if we don't consider other aspects. E.g. if I have to program a front-end of a program that run on a server, which must be execute in any PC, yes a browser+javascript is a very good compromise, and may be the best choice.
However I am surprise that the same choice was taken for an installer. Again I am not arguing the other choice or blaming javascript as language; I am only guessing if the correct prospective is that the other are worse. And in this case I am curious about the other opinion.
Posted Nov 15, 2024 19:14 UTC (Fri)
by jzb (editor, #7867)
[Link]
the article explained that in any case they had to rewrote a lot of code, so switching to a web base front end was no so expensive; but the same is true for switching to (e.g.) rust based code They also explained the choice of a web-based interface: The Cockpit team has been providing a web-based interface for Linux systems for managing systems for many years in the Cockpit web console, so it made sense to reuse Cockpit as a base and its web-based widget set, PatternFly, as a starting point for the next generation of Anaconda too. I suppose they didn't go into a blow-by-blow comparision of that approach vs. Rust or whatever, but it's pretty clear they chose tooling they were already familiar with that is in use for other system management tools. We covered Cockpit in March. They also mention the use case of remote installs in the future—which makes sense since there are many instances when an admin may want to install Linux on a system they'll never be in the same room with and a TUI is not seen as friendly. Also, Red Hat has been investing in Patternfly for UIs for a long time now, I'm not at all surprised to see it employed in an installer because the alternative would be "use Patternfly here, here, and here, but not the installer". If you assume the folks working on Anaconda also work on other UIs, it would be weird to expect them to use Patternfly everywhere but the installer. However I am surprise that the same choice was taken for an installer. Fedora isn't alone here. We covered openSUSE's new installer, Agama, in August, which also has a web-based interface. Ubuntu, I think, uses Flutter, but I can see why that wouldn't have appealed to Fedora or SUSE.
Posted Nov 13, 2024 5:24 UTC (Wed)
by azumanga (subscriber, #90158)
[Link] (3 responses)
From their FAQ, can we use PyGObject (which is the base library) with the official Python release, rather than via msys2 (which I don't imagine anaconda wants to build on)?
https://gnome.pages.gitlab.gnome.org/pygobject/guide/faq....
Yes, except you have to use some unofficial sourceforge project, and also that sourceforge project last released in 2017 and has been officially abandoned for 4 years at this point.
Posted Nov 13, 2024 6:41 UTC (Wed)
by intelfx (subscriber, #130118)
[Link] (2 responses)
How is running anything on Windows relevant to Anaconda, the RHEL/Fedora installer?
Posted Nov 14, 2024 1:41 UTC (Thu)
by azumanga (subscriber, #90158)
[Link] (1 responses)
Posted Nov 14, 2024 11:44 UTC (Thu)
by m4rtink (guest, #95458)
[Link]
Posted Nov 12, 2024 20:49 UTC (Tue)
by joib (subscriber, #8541)
[Link]
Maybe also a workforce issue; much easier to find web ui developers than someone familiar with Gtk programming in C. I'm pretty sure web developers outnumber both C/Gtk and C++/QT developers combined. Probably by at least an order of magnitude, or even several.
Posted Nov 12, 2024 20:58 UTC (Tue)
by marcin (subscriber, #159076)
[Link] (2 responses)
Posted Nov 12, 2024 22:24 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Nov 13, 2024 12:36 UTC (Wed)
by m4rtink (guest, #95458)
[Link]
Posted Nov 12, 2024 23:45 UTC (Tue)
by equeim (guest, #153600)
[Link]
Posted Nov 13, 2024 0:57 UTC (Wed)
by azumanga (subscriber, #90158)
[Link] (1 responses)
Having a quick look at the issue tracker ( https://gitlab.gnome.org/GNOME/gtk/-/issues/?label_name%5... ), there are lots of windows-specific bugs, often with more obscure hardware, that long tail is hard to fix.
Now, I don't want this to sound like I'm picking on the GTK people, finding open source windows devs is always hard, and they mostly work for free. However, electron is used by so many companies it's cross-compatability at this point is excellent (still not perfect, but very good).
Posted Nov 13, 2024 13:41 UTC (Wed)
by WolfWings (subscriber, #56790)
[Link]
Posted Nov 12, 2024 19:30 UTC (Tue)
by miah (guest, #639)
[Link] (1 responses)
Posted Nov 13, 2024 4:57 UTC (Wed)
by Russell (guest, #1453)
[Link]
Posted Nov 13, 2024 7:00 UTC (Wed)
by oldtomas (guest, #72579)
[Link] (5 responses)
Sometimes you have to hit a "save" (or "apply changes", or "wopp"...) button, sometimes things take effect immediately. Sometimes the "right" field has focus when the window is focused, sometimes you've to click on it. Sometimes TAB cycles the focus through meaningful fields, sometimes things get selected you never knew they were going to accept input (to be fair, often they didn't know either). Arrow keys sometimes do things, sometimes do other things. The slash key sometimes finds-in-page, sometimes it sets of a hellish machinery whose back-end is typically some misconfigured Elasticsearch (I know, I know: it is being replaced by some misconfigured OpenAI).
The cynic in me thinks this introducing anomie [1], to keep users confused and thus, powerless.
Posted Nov 13, 2024 15:01 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (4 responses)
tldr; I don't know if I have a coherent thought here or just some random tangents until the coffee kicks in...
Man, I hear you, this is also a peeve of mine, although with the web platform there is less expectation of common HCI so that its less annoying (for me) when every app does it's own thing, and there is a monumental amount of effort put into attempts to standardize (with tools like Bootstrap, conventions such as hamburger menus, and all the work on accessibility supported by browsers) because the platform just provides a mechanism and doesn't really impose or even incentivize any particular guidelines (again, reminds me of X11 and the differences between xfig, xman, xv, LibreOffice, Krita, and Nautilus for example). I appreciate some of the modern desktop environments attempts to standardize their own apps behavior, although the days of an all-powerful HIG, with thoughtful testing and research behind it, seem to have passed. Back in the day when GUI apps were mostly tied to their platform toolkits (Win32, Carbon/Cocoa) there was more incentive for apps to use the same widgets and guidelines and get standardized behavior "for free", which made it more noticeable when something like Win98 shipped and came with at least 4 slightly different versions of the platform toolkit because the Win9x, WinNT, MSIE, and MSOffice teams all decided to fork the widget set to customize it in their own ways plus support for Win3x, so you could open 5 different apps and have 5 different File::Open dialogs between them, some of which didn't get normalized until the Win8/10 team tried to pave it over. In the Unix world GNOME and KDE are as different as Windows and MacOS and can be thought of as wholly different platforms that happen to run on the same system, and I'm enjoying (sarcastically) how we are speed-running all the issues with X11 that caused ICCCM to be necessary to negotiate with Wayland protocol extensions, probably more of a reflection on how development across an industry of different competing/cooperating entities without a top-down hierarchy to coordinate must function, rather than a failing that can be fixed.
Posted Nov 15, 2024 7:59 UTC (Fri)
by oldtomas (guest, #72579)
[Link] (3 responses)
Currently working on that myself :)
I wasn't so much about the "classical" GUIs. They had their "wars" back then. but the dust seems to have settled so far that someone coming from a Gnome environment can navigate a KDE app and vice-versa.
It's the repeat of this anti-pattern in a far more perverse and toxic way in the Web "GUI" space which has me up in arms. For one, the diversity of frameworks is stunning; then, quite a few of them are pushed by big actors making their money from user control; and third, the half life of the framework du jour is counted in half-decennia.
To me, it looks as if, for some actors, the resulting user confusion is seen as an asset.
What miffes me most is that free software activists uncritically take over those antipatterns.
Posted Nov 15, 2024 14:05 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Don't worry, when they get older, they'll see the errors of their ways ... we were like that when we were younger.
The problem is that youngsters "absorb", they don't learn. Once you start having to consciously learn all this stuff, you suddenly realise that it's taking you longer and longer, and at some point the time taken to learn exceeds that said half-life ... whoops ...
I'm very much hitting that barrier now, exacerbated by the fact that so much of this tech doesn't interest me, so I'm forced to learn it on behalf of other people (who are ill/old and incapable of learning), so I have to re-learn it EVERY time I try and use it. What a waste of time ... and the youngsters can't even understand the problem !!! That's the really infuriating thing !!!
"For those without a smart-phone, there's an app for that" - yes I REALLY DID see that in one of my company's internal FAQs ...
Cheers,
Posted Nov 15, 2024 14:51 UTC (Fri)
by raven667 (subscriber, #5198)
[Link] (1 responses)
This is all a tangent, but I've read a lot of what Alex Russel has to say about React and the whole client-side rendered JavaScript HTML/CSS ecosystem and how the uncritical adoption of this technology, lead by the advocacy of developers at Facebook, has done a disservice to the web by focusing so much of the development ecosystem around tools which are only really useful for a small number of cases encountered by large companies with large scale and large development teams, but because its "what the big boys use" it's become pervasive for general use cases that would be better served by a traditional Django/Rails app running on a server with normal HTML templates but instead are written as another React SPA doing everything over a REST API using micro-services on a Kubernetes cluster, which is an order of magnitude more complex to maintain.
> To me, it looks as if, for some actors, the resulting user confusion is seen as an asset.
I don't understand what their incentive has been for the endless rewrites, job security maybe. As far as the diversity of UI that seems to just be creativity without constraint of a HIG or an accepted community of practice for what is good that's consistent.
That all said, the use of a self-contained SPA WebUI that talks to a backend service for the Anaconda installer with a kiosk-mode Firefox for graphical display seems a perfectly reasonable use-case for SPA tech, especially since so much of the work is already done to support Cockpit, it's the traditional interactive forms-based client/server database apps which are a poor fit.
Posted Nov 15, 2024 19:28 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
I recommend not reading about React, but using it yourself. It really is a revolutionary approach to the UI, far increasing productivity.
People are now using React-based approach for text UIs: https://github.com/dino-dna/react-tui
Posted Nov 13, 2024 8:37 UTC (Wed)
by taladar (subscriber, #68407)
[Link] (1 responses)
Posted Nov 13, 2024 12:54 UTC (Wed)
by m4rtink (guest, #95458)
[Link]
The current text interface & GTK3 graphical interface both communicate with the Anaconda backend via DBus.
The Web UI does the same - via the WebUI/DBus bridge provided by the Cockpit project.
In this regard the Anaconda Web UI is very similar to many Cockpit screens & plugins, where you have a Web app wrapping a system provided DBus API (udisks, NetworkManager, firewalld, etc.).
Just in this case the Anaconda Web UI generally talks to the Anaconda backend instead to the system DBus APIs directly.
Posted Nov 13, 2024 12:17 UTC (Wed)
by bushdave (subscriber, #58418)
[Link]
Posted Nov 13, 2024 13:16 UTC (Wed)
by garrett (subscriber, #87976)
[Link]
The new installer UI improves the installation experience for everyone, especially those new to Linux (and Fedora). It streamlines the process, making installing Fedora Linux easier even for all of us seasoned Linux pros. It also won't affect your regular Fedora usage once it's installed; these changes are only seen during installation.
As someone who's been using Linux since 1996 (and used to have to compile XFree86, calculate modelines to use my monitor without it exploding, write chatscripts for my modem, and compile pre-releases of the kernel to get hardware to work), just about anything that simplifies basic things and lets us focus on more interesting tasks is a good thing. Most of you would probably agree. That's what we're trying to do here, make installation simple and painless for everyone, so everyone can quickly start using Fedora Linux instead of worrying about how to install it.
Anyway, this new approach uses a web-based UI but doesn't change the underlying Python code that performs the installation. The change away from GTK makes it easier for others to contribute to its development and for the core team to maintain. It also enables Anaconda to have a better experience when doing remote installations, which will be a great thing for server installations.
It also uses web standards and the UI is rendered by Firefox. (It isn't using Electron.)
We do welcome constructive feedback after you've had a chance to read the article, look at the screenshots, watch the videos, and try the new installer.
We're all part of a Free Software and Open Source community where we're supposed to build each other up and cheer each other on. Let's all keep that in mind when writing comments about FOSS on the Internet. Thanks!
Posted Nov 13, 2024 16:50 UTC (Wed)
by NightMonkey (subscriber, #23051)
[Link]
A web UI makes even more sense in front of a HTTP URI-based set of API paths offered by the backend. Then you can easily make *any* frontend that can make use of HTTP API calls, including a TUI or GUI web browser or even unix-style commands. The ecosystem for HTTP and HTTP APIs is quite large and varied. I skimmed the article but didn't see a mention of that approach specifically. Is that part of the goal?
Posted Nov 15, 2024 18:58 UTC (Fri)
by ypalanque (guest, #121581)
[Link] (1 responses)
Posted Nov 18, 2024 15:37 UTC (Mon)
by m4rtink (guest, #95458)
[Link]
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
- python + qt / gtk
- c++ + qt
....
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
https://fedoramagazine.org/wp-content/uploads/2017/07/tui...
https://docs.fedoraproject.org/en-US/fedora/f36/install-g...
https://anaconda-installer.readthedocs.io/en/latest/boot-options.html
https://anaconda-installer.readthedocs.io/en/latest/configuration-files.html
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
web devs, go home
web devs, go home
Oh, great, yet another browser "GUI"
Oh, great, yet another browser "GUI"
Oh, great, yet another browser "GUI"
Oh, great, yet another browser "GUI"
Wol
Oh, great, yet another browser "GUI"
Oh, great, yet another browser "GUI"
Installer as a REST API?
Installer as a REST API?
This architectural change makes a lot of sense.
Web APIs are incredibly stable and the web stack is certainly the number one way of doing remote UIs today and for the foreseeable future.
Makes a lot of sense
Don't panic!
Backend installer API?
As long as a good TUI remains possible
Having had (alas all too often) to install OS in datacenters, in difficult conditions, with a keyboard in poor condition, no mouse, or a mouse but not enough USB ports, or the mouse prevents the USB key from fitting properly, or other problems, I have to say that I like still being able to use a TUI (even if I don't have to do these weirds installs anymore).
As long as a good TUI remains possible
