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.
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.
It’s unclear what you are trying to say. The question was what would switching license do. There’s 2 scenarios: 1) either Google is really not doing changes in ffmpeg source internally right now …or 2) they are in fact making changes to it internally (perhaps for encoding with their own codecs, etc.) which they are not releasing back to the public (since the code is LGPL, and not AGPL)
With situation 1, they can simply continue using ffmpeg, even if it were to switch to AGPL. They would have no need/obligation to release anything, whether they decide to fund development or not. The way I see it, only if it’s situation 2, will Google be affected by a license change. However, if the use they make of ffmpeg is just to have their own encoder program for use with specific codecs, they might as well decide to stop using ffmpeg for this purpose instead and have their own program to work with their encoders. Most of the encoding work is already being done in the encoding libraries separately released (like libaom, which Google licensed under BSD-2).
But even in the rare case of Google having made changes that (after license change) they would suddenly decide to be willing to share with the community despite having not done so before… the whole problem with this bug-reporting mess is that most of the issues reported by the automated tools aren’t something really that impactful/important, they are things that even Google would not really be that interested to fix… (why would Google need to fix a codec that only affects a videogame cinematic from 1995?). These reports are just the result of automated & indiscriminated AI analysis, slop.
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.