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.

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.

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.

Still, it’s good news and lets hope it sets a trend.

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.

LLMs abstract information collected from the content through an algorithm (what they store is the result of a series of tests/analysis, not the content itself, but a set of characteristics/ideas). If that makes it derivative, then all abstractions are derivative. It’s not possible to make abstractions without collecting data derived from a source you are observing.

If derivative abstractions were already something that copyright can protect then litigants wouldn’t resort to patents, etc.

You are not gonna protect abstract ideas using copyright. Essentially, what he’s proposing implies turning this “TGPL” in some sort of viral NDA, which is a different category of contract.

It’s harder to convince someone that a content-focused license like the GPLv3 protects also abstract ideas, than creating a new form of contract/license that is designed specifically to protect abstract ideas (not just the content itself) from being spread in ways you don’t want it to spread.

Yes, but they do it in order to fill up a hole in their lives, to have a “greater purpose”, give their lives meaning. Ultimately all we do is to satisfy our desires…and the push towards caring for kids is one of the biologically hardwired desires we evolved having, the reason we do it is not really a lack of ego. Having a family is something people want for themselves, for their own happiness.

I believe it’s literally impossible for a person to not be egoistic without going crazy and/or offing oneself. Even christians who preach about self sacrifice and generosity only do it pushed by the promise of a better afterlife and their own self-interest of wanting to avoid hell and/or being closer to their god.

Ah, I see. Sorry, the text was too long and I’m not dutch so it was hard to spot that for me too.

But I interpret that part differently. I think them saying that there’s an ambiguous section about risks does not necessarily mean that the ambiguity is in the responsibility of those who choose to not implement the detection… it could be the opposite: risks related to the detection mechanism, when a service has chosen to add it.

I think we would need to actually see the text of the proposal to see where is that vague expression used that she’s referring to.

Thanks for the link, and the clarification (I didn’t know about april 2026)… although it’s still confusing, to be honest. In your link they seem to allude to this just being a way to maintain a voluntary detection that is “already part of the current practice”…

If that were the case, then at which point “the new law forces [chat providers] to have systems in place to catch or have data for law inforcements”? will services like signal, simplex, etc. really be forced to monitor the contents of the chats?

I don’t find in the link discussion about situations in which providers will be forced to do chat detection. My understanding from reading that transcript is that there’s no forced requirement on the providers to do this, or am I misunderstanding?

Just for reference, below is the relevant section translated (emphasis mine).

In what form does voluntary detection by providers take place, she asks. The exception to the e-Privacy Directive makes it possible for services to detect online sexual images and grooming on their services. The choice to do this lies with the providers of services themselves. They need to inform users in a clear, explicit and understandable way about the fact that they are doing this. This can be done, for example, through the general terms and conditions that must be accepted by the user. This is the current practice. Many platforms are already doing this and investing in improving detection techniques. For voluntary detection, think of Apple Child Safety — which is built into every iPhone by default — Instagram Teen Accounts and the protection settings for minors built into Snapchat and other large platforms. We want services to take responsibility for ourselves. That is an important starting point. According to the current proposal, this possibility would be made permanent.

My impression from reading the dutch, is that they are opposing this because of the lack of “periodic review” power that the EU would have if they make this voluntary detection a permanent thing. So they aren’t worried about services like signal/simplex which wouldn’t do detection anyway, but about the services that might opt to actually do detection but might do so without proper care for privacy/security… or that will use detection for purposes that don’t warrant it. At least that’s what I understand from the below statement:

Nevertheless, the government sees an important risk in permanently making this voluntary detection. By permanently making the voluntary detection, the periodic review of the balance between the purpose of the detection and privacy and security considerations disappears. That is a concern for the cabinet. As a result, we as the Netherlands cannot fully support the proposal.

Where is this explained? the article might be wrong then, because it does state the opposite:

scanning is now “voluntary” for individual EU states to decide upon

It makes it sound like it’s each state/country the one deciding, and that the reason “companies can still be pressured to scan chats to avoid heavy fines or being blocked in the EU” was because of those countries forcing them.

Who’s the one deciding what is needed to reduce “the risks of the of the chat app”? if it’s each country the ones deciding this, then it’s each country who can opt to enforce chat scanning… so to me that means the former, not the latter.

In fact, isn’t the latter already a thing? …I believe companies can already scan chats voluntarily, as long as they include this in their terms, and many do. A clear example is AI chats.

The thing is… that even if there are countries publicly rejecting this, once the infrastructure is in place and a backdoor exists due to it being enforced by some other country, how can you be sure it’s not being used / exploited?

Even in the (hypothetical) case that the government is not using it (regardless of what they might say to the public), I wouldn’t trust that this backdoor would be so secure that nobody else than a government could make use of it.

I believe Germany is now in favor of this new proposal, according to https://fightchatcontrol.eu/

Only Italy, Netherlands, Czech Republic and Poland are against. This seems to be based on “leaked documents from the September 12 meeting of the EU Council’s Law Enforcement Working Party”.

3. The Pixel is easily unlockable, so one can install custom firmware without being a “pro”, its hardware is (or was reverse-engineered to be) compatible enough to make the experience seamless, with a whole firmware project / community that it’s exclusively dedicated on that specific range of hardware devices, making it a target for anyone looking for a phone where to install custom Android firmware on.

But I’d bet it’s a mix of 2 and 3.

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