Parental controls means the control is done by the parents… not by the companies. I don’t need to tell any company what age bracket my kid might be, all I need is for them to tell me how can I block / restrict access to their services in my parent-controlled network (or how to allow them, if using allowlist).

Standardization of parental controls would be if routers and/or the OS of the devices came with standardized proxy settings that allowed privoxy-style blocking of sites in a customizable way so we can decide which services to allow… with perhaps blocklists / allowlists circulating in a similar way as adblockers do.

I mean, ultimately it can always be worked around… even if you were to add stronger forms of identification, a kid can take the parents card / ID / DNA sample / whatever when they are distracted and verify themselves. If a kid is smart enough to set up a VM like that they are smart enough to deceive adults. Teenagers have been finding easy ways to get to forbidden stuff for centuries.

I’d much prefer if the source of trust is in the local device, in the OS, that is responsibility of the family to control, and not on some remote third party service offered by some organization in who knows where with connections with who knows who. If parents don’t properly limit the local user account of their kids, or restrict access to the places they don’t want, it’s their responsibility. Set up proxies, blockers and lock the OS locally, but don’t mess up the internet for the rest of us.

Would they actually go after the people?

I expect the law would place the responsibility on the companies managing / distributing the OS. That’s the reason companies are complying. People can always look for alternatives… I’m sure there will always be homemade distros without stuff like this made by ragtag groups / communities without much of a corporate structure behind.

I mean… there’s nothing stopping anyone from setting their age to 100 years old. It’s not like they are adding any sort of identification check, from what I gather. Just doing the minimum to comply.

It recently overtook Japan, so it’s 4th now…

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.

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.

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.

The only reason for CSD is touch interfaces on small screens.

Even in this case I’d argue that on small screens most apps simply have no real decorations (not even client-side)… there’s typically not even a close button. Hamburger buttons are menus, which isn’t what’s typically considered “decoration”. One could argue that the bar at the bottom in Android with home/back/etc controls is effectively a form of SSD. Android offers system UI or gestures to send the app to the background (ie. minimize) or closing it, it does not require Apps to render their own, which is effectively what Gnome is asking with CSD.

They justify the rejection of SSD because it isn’t part of the core Wayland protocol and at the same time push client apps for the “minimize” and “maximize” buttons (along with respecting some settings) despite it also not being part of the core protocol and it being only possible through extensions. There’s a ton of tiling compositors that don’t even have any concept of minimize/maximize, so why should this be required of every client app?

It feels backwards to ask the app developers to be the ones adding the UI for whatever features the window compositor might decide to have. They might as well be asking all app developers to add a “fullscreen” button to the decoration, or a “sticky” button, or a “roll up”/“shade” button like many old school X11 WM used to have. This would lead to apps lagging behind in terms of what they have implemented support for and resulting in inconsistent UX, and at the same time limiting the flexibility and user customization of the decorations, not just in terms of visuals but also function and behavior.

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.

Yes, I think you’re talking about something else, related to your particular needs. But the post OP opened (which you were replying to) was about discussing what “implications for Linux” would the new Steam hardware have.

I feel the only part in your comment that was somewhat relevant to the question raised by OP was:

Anyway IMHO the big questions for VR on Linux more broadly is what changes upstream on KDE in terms of immersive UX? Is KDE Plasma becoming a VR graphical shell? Does it have 3D widgets? Does it impact freedesktop in any way?

The only reason Linux became a thing is because Torvalds managed to get engagement and popularity amongst a niche community of hackers that happened to share the same needs/goals.

Because what gives it importance is the needs we share. “The need of 1” is measured in relation to “the need of many”. Community is a huge piece in the “open source” puzzle. A community of 1 is not a community… it’s a personal space. If you don’t share your software with a community then declaring it “open” is pointless.

Also… when I said “relevant” I specifically meant for the questions raised by OP. I’m not talking about “relevancy” in some weird transcendental way… I don’t believe such a thing exists… everything has a viewpoint from which something can be said to be “relevant”… however, as you yourself said: “your preferences are not relevant to my needs”.

Everyone can say the same thing… your needs are not relevant either then.

Popularity is ultimately what moves the needle, this post was asking in which direction will the needle move… so in this context your personal needs are only relevant in relation to how popular they are.

Relevant section:

At first, around 1996, it was common practice to make the Windows key act as Meta. However, because of the existing alternative keys for Meta in Emacs, the reintroduction of a hardware Meta key binding did not prove exceptionally useful. This made Super the next most frequently emulated key of choice, and thus it became the standard assignment for the Windows key under X11.

Most Linux software and documentation calls these keys “Super” keys. However, they are still referred to as KEY_LEFTMETA and KEY_RIGHTMETA in the kernel,[5] and some documentation such as that of KDE Plasma refers to it as just the Meta key.[6][7] “Windows” and ⌘[8] are also used in documentation.

You’re not being fair, that wasn’t the conversation thread at all… I didn’t reply to OP’s initial message directly.

It was more like this:

1. OP: Hi guys, I’m looking for yellow tomatoes, do you know where can I get them?

2. Commenter: I go to this store, they have tomatoes that are yellow enough for me… for more sophistication you need to go to a much further away local shop.

3. OP Response: My question isn’t sophisticated! …all I want is my tomatoes to be of the same color as all the other yellow vegetables I exclusively eat, all yellow, tomatoes and ketchup being red is a step in the opposite direction.

4. Me: there’s a reason why the red ones are sold, [valid cultural reason]. But you can still change them, here’s a manual / recipe to turn them yellow when cooking.

As you see, when I was talking about reasons it was mainly directed to the apparent indignation of comment “3”, when the person was painting their request as something that should be seen as the more reasonable / less sophisticated approach… so I gave the reason to show how the opposite is also more reasonable / less sophisticated from another point of view.

But even then, I did link to the manual for readline to configure the input handling. It’s not like I just dismissed the initial question like your simplification implied.

PowerShell still runs inside a terminal emulator (e.g. Fish), so it changes nothing in the input/output behaviour.

You can definitely change the input/output behavior by changing the program that runs on the terminal… in fact, when I posted that link earlier, what I said is that you can configure this in readline, which is a library that bash and many other programs that run in the terminal (not all, not fish, for example) use for interpreting the input, so all terminal programs using the readline library for handling interactive input have the same shortcuts. It’s not the terminal the one with those shortcuts coded into it.

“GUI-friendly terminals”? What does that mean, in the context of the conversation? Why are you talking about GUI?

Because a terminal emulator is a GUI app… OP wasn’t talking about about real terminals, nor about a virtual console session in Linux (which runs without any GUI), but about a terminal emulator you open in a window within a graphical compositor.

My point was that most of the popular (amongst terminal nerds) GUI app terminals stay away from the traditional GUI toolkits when possible because they want to keep the app slim and lightweight. And it’s those toolkits the ones that orchestrate the standardization of the typical Windows-like shortcuts (similar as the readline library, but for GUI apps). This is also why in many terminals you don’t even have a menu when you right click, since those menus are usually done with GUI toolkits. But there are also heavy-weight terminals like the ones bundled in some more user-friendly DEs that do include GUI toolkits as dependencies, so they might actually have an easier go at playing nice with other conventions in their respective DEs. However, you’d still need to pair it with a shell that also plays nice (or configure it to play nice, if possible).