In general, I agree that you can always use the CLI raw, but a frontend is a lot more friendly for many. It’s the reason some people prefer TUI over CLI as well (some people really like lazygit and lazydocker which are just frontends wrapping git and docker CLI calls and presenting it in a TUI). A TUI/GUI can structure information in panels, it can be more context-sensitive and it can help provide visual representations of the operation.

Also, wrapping CLI commands (whether through a GUI or a TUI) means the wrapper can automatically combine the commands in whichever way it’s best for a particular goal, or more conveniently set up batch processing… it’s helpful for people who don’t like having to make their own scripts, or craft long oneliners.

Plus: lets say you have your computer hooked to your TV and don’t have space for a keyboard (but can use a small wireless mouse on the arm of your couch), a GUI wrapper that allows you to perform operations with just a mouse can be very convenient.

I don’t know what kind of GUIs are you imagining, but I’ve hardly ever seen 1-to-1 recreations to a single individual command (unless that command is extremely complex or a graphical representation would be actually useful).

Some examples:

Gparted creates a job list of terminal commands for the disk manipulation, but it presents a graphical representation of the disks before you actually commit to executing the commands internally, so you can see what would be the result of the changes in the GUI side before actually pressing the button that actually executes parted, fdisk, mkfs, resize2fs, etc. (they do wrap the commands when it comes to executing the changes), without you needing to go through the steps and specific syntax of each of them on your own.

There are wrappers to ffmpeg for video editing or transcoding that some people find convenient for discoverability of the options available and/or to have a limited list of presets / sanitized options for those who don’t want to bother creating their own scripts. Sometimes also showing video previews for the graphical representation (useful when the operation is about cropping the image, or picking the exact millisecond where to cut). An example is LosslessCut, they keep a log of the ffmpeg calls… or maybe Shutter Encoder (press Alt+C to see the console commands).

In Synaptic, the GUI package manager, pressing “Apply” calls the appropriate APT commands as a CLI app inside a VTE with the selection of the packages you have decided to add/remove/update, which you have previously selected in the listing that is generated from the GUI view of the app. Some people like having a graphical detailed listing which might be useful for conveniently browsing packages and seeing their detailed description, while still you get the raw information and accurate log from the installation that you would get when you are just using the CLI.

Personally, I feel that if it uses control characters to update the screen in previous positions, altering the scroll buffer, moving beyond where the cursor is and redrawing the screen, then it’s a TUI.

CLI programs only output plain text in a stream, using just control characters for coloring and formatting, and if they do any re-drawing it’s only for the current line (eg. progressbars and so).

So… even something like less is a TUI program… but things like more or sed would be CLI programs.

Isn’t the T for “text”? (ie. “Text User Interface”)

I mean, in the context of Unix systems it’s most likely gonna be within a terminal emulator, but in theory you can have a TUI inside an SDL window rendering the text there (specially when they are ports from other systems where they might be using different character sets than whats available in terminals… or if they want to force a specific font).

The only example that comes to my head right now is ZZT, but I believe there are many games on Steam that use a TUI rendered within their own program, not a terminal.

I generally agree but it depends on the application and the computer purpose / input you will most use.

Like… it doesn’t make much sense to have a CLI/TUI for an image editor… if you start using things like sixel you are essentially building a GUI that runs in a terminal, not a TUI. The same happens with videogames, video players and related entertainment applications.

But like I said, I do generally agree. I’d even argue that when possible, GUIs should just be frontends that ultimately just call the corresponding CLI programs with the appropriate parameters, avoiding duplication.

The second most restrictive of the Creative Commons licenses (only behind the BY-NC-ND one). CC BY-NC-SA is not considered an open source license.

It gives the most control to the original owners of the Copyright, since only they can produce commercial and proprietary versions of the product. Free as in free beer, but not as in freedom.

I agree, which is why I think running those open source apps in a separate computer, isolating infotainment from the more critical software, would be a stronger safety layer.

Them being separated should, imho, be a precondition, so that it can minimize accidents and exploits in cars that might be running software that is not immediately up to date as a result from publicly and well known vulnerabilities being discovered as the code evolves.

Open source software is not bug free. I’d argue there are more vulnerabilities caused by human error than there are caused by malicious actors. More often than not, malicious actors are just exploiting the errors/gaps left by completely legit designers.

Running those open source apps in a separate computer, isolating infotainment from the more critical software, would be an even stronger safety layer, imho.

While it’s true that Debian installation used to make use of a TUI and it did not have a nice GUI “live-CD” installation image for a long time (I think until 2019), Debian installation process included a default DE for way longer than that (2000). And before they did, the installation offered a choice between different window managers (back in the days before well established DE suites were even a thing).

They don’t customize the DE much, but neither does Archlinux which is a very popular distro nowadays (and the installer on that one is arguably even less friendly than Debian used to be).

Personally, I feel it has more to do with how other distros (like Mint, Ubuntu, Knoppix, etc.) have built on the work of Debian to make their own variants that are essentially Debian + extra stuff, making them better recommendations for the average people (if one thinks of those as Debian variants then I wouldn’t say Debian is “left out”). And for the not-so-average people, rolling release style distros (or even things like Nix/Guix) might be more interesting to experiment in.

Running it through the same computer is a bad practice, imho. Remember the Jeep Hack where researchers were able to dig into the integrated infotainment system and control the brakes?

I wouldn’t want to have critical car functions (or emissions control, regulatory software, ADAS, telematics, etc) depend on the same device that someone might be using to connect to the internet and/or run Android Auto apps. Regardless of whether it’s integrated or not.

I guess it might be ok to share energy and some non-critical capabilities with the infotainment system… but you can do that through a USB-C connection without requiring it be integrated directly in the vehicle. Imho they should be isolated, and what best way of isolating it than being completely different computers?

At least for the German one, it’s essentially a rebranding of existing open source products packaged/adapted to work as a suite.

For example, for editing documents they are using Collabora online (Libreoffice-based), for chat it’s Matrix, for storage Nextcloud, email & calendar from Ox Cloud, etc.

This just applies to the French government, unless you land a public job it’s likely you’d still have to deal with that shit.

Yes, but that’s the point. Why focus on something that does not make them criminals when there are other things that might?

Isn’t CachyOS more of a general purpose distro anyway?

I expected the OGC was mainly targeted to gaming-first distros, which in my mind are meant for an entirely different kind of devices with different interests and goals. I don’t think there should be much value in CachyOS joining it, regardless.

Most people already carry infotainment devices in their pockets that can be attached to holders and charging ports in the car. Even better if you connect a hub with some SSD storage to keep movies/music.

I feel infotainment systems bundled in cars are mostly redundant and explicitly made to be non-modular so that they can get you into their walled garden.

you shouldn’t be adjusting it while driving but, my response is why have it in the first place.

Exactly. If you shouldn’t be adjusting it, then why is the touchscreen even accepting adjustments in the first place? … it should be rejecting all touches whenever the engine is running to prevent people from even trying, which completely defeats the point of having a touchscreen in the first place anyway…

It makes no sense to have an input that explicitly requires you to take your eyes away from the road in order to operate it.

Code being visible is not very useful if you can’t distribute it, extend it, expand it and improve it.

It’s meant in the sense of “underwhelming” (as shown by the follow-up comment the article references). It’s not incompatible to be surprised at how capable AI is (ie. being “impressed”) and at the same time be also unwilling to pay the costs / repercussions and want to ban / regulate it.

In this context, being deeply unimpressed with something is equivalent to calling that something “irrelevant” / “incapable”. If AI was no more impressive than it was before the LLM boom then there wouldn’t have been such a reaction against it to begin with. If anything, people being now opposed to modern AI is proof of how impactful AI has become.

Yea, but he’s (intentionally?) misrepresenting things… people are not “unimpressed” by AI, what they are is not interested in MS “agentic OS”, these are not the same things.

It’s irresponsible to hand in control of your machine to an AI integrated that deeply into the OS, particularly when it’s designed to be tethered to the network and it’s privately owned and managed by human entrepreneurs that do have the company’s interests as first and main priority.

Many Keepass clients have support for not actually deleting entries, and instead moving them to a “Trash” subgroup inside the kdb that is ignored when searching entries. Also they usually keep track of the history of changes to each entry, to make it non-destructive.

Coupled with Syncthing typically automatically creating backups whenever it encounters conflicting changes, I feel this should be enough, at least for me personally.

Those are open questions that I don’t think we can answer yet.

If you are asking if Valve did make changes there, I’m expecting the answer is likely no. They haven’t shown anything regarding KDE/desktop mode on the Steam Frame. And we have yet to see how exactly this is integrated with gamescope. But if the device does become popular and interest grows for Linux VR development, then I expect we’ll see people trying to make new VR environments for Linux (or adapt existing ones for VR).

However, given that Valve plans to offer ways to play non-VR games with the Frame, I expect one could add a nested wayland session as if it were a non-Steam non-VR game, so in the VR environment from SteamOS one could have a floating screen showing a traditional KDE session relatively easy, I would expect. And in that sense one could have a desktop VR environment standalone, in the Frame.