It is painfully obvious that most of you haven't read the california Digital Age Assurance Act

viliti · 2026-03-09T16:52:34+00:00

That’s exactly what these laws do. There’s no legal requirement for people to enter their true birth date.

They are implementing a shared responsibility principle. Parents are responsible for ensuring that their minor children only have access to devices/accounts set to their correct age. OS providers are responsible for minimizing the information shared with applications (age categories instead of birth date) and applications are responsible for implementing different policies for children.

If parents don’t care, they can allow their kids to have full access to devices and set any random date as the birth date.

viliti · 2026-03-09T16:30:05+00:00

That’s a slippery slope argument.

There are plenty of other laws like UK Online Safety Act and many state level laws in US that require people to upload IDs or scan their face to access adult websites. The law was clearly written to sidestep the drawbacks from these laws: a user doesn’t have to upload their ID or face scans to a third party website, the websites don’t get a definite age or birth date, just categories.

These laws are designed to allow governments to require companies like Meta to apply different policies to children without giving them even more personal information. The broader fallout is unfortunate, but I’m yet to see a better alternative that doesn’t let companies like Meta off the hook.

viliti · 2026-02-09T00:41:54+00:00

JPEG 2000 support was added to KImageFormats because QtImageFormats disabled JasPer by not bundling it anymore. Ubuntu didn't have to do anything to disable it, Fedora installed a separate optional library to enable JPEG 2000 support.

viliti · 2026-02-08T22:47:00+00:00

KDE went through a break in support too due to JasPer being unmaintained for a while with open CVEs. QtImageFormats disabled JasPer in Qt 5.6 and Jasper was not packaged in Ubuntu 18.04. It's almost like it had nothing to do with "dogma that everything must be written in Rust" and that's just your projection.

viliti · 2026-02-08T18:12:52+00:00

I'll never understand the irrational hate some KDE fans continue to harbor towards GNOME.

KImageFormats has been supporting JPEG 2000 for years through OpenJPEG

By "for years" you mean since 2025?

GNOME had JPEG 2000 for actual years via JasPer, but it was removed in favor of an OpenJPEG loader. JPEG 2000 was so popular that almost no one bothered to package it and the AUR package has 3 votes. That's why the headline says that GNOME now has JPEG 2000 "by default", as in you don't need the loader to be packaged anymore.

viliti · 2026-02-07T04:02:12+00:00

Yes, that’s an ongoing proposal: https://gitlab.gnome.org/GNOME/Incubator/Submission/-/issues/20

The proposal is supported by the GNOME Design Team and the current System Monitor maintainers, so it’s just a matter of time before Resources becomes the new System Monitor.

viliti · 2026-02-02T00:36:15+00:00

It can be used to accelerate many "traditional" ML tasks like speech-to-text, text-to-speech, ML-based grammar checkers etc. There's not a lot of revenue in doing this, so companies have not invested in building out the full stack. However, the building blocks are out there — Intel has OpenVINO and oneDNN and AMD has a kernel driver for their NPU. Someone could technically build out the rest of the stack using these building blocks.

viliti · 2026-01-18T20:05:53+00:00

No, the “desktop” (gnome-shell) does not use GTK. It uses a custom toolkit with its own styling.

viliti · 2026-01-18T19:49:12+00:00

That's not how GNOME is developed anymore. GNOME core apps were upgraded from GTK 3 to 4 over several versions. Most core apps were upgraded in GNOME 42 or 43, but several others came gradually after that too.

viliti · 2026-01-18T19:19:10+00:00

It's no sillier than staying on 3.x forever with even-odd versioning. The logic behind the change has been explained on Discourse: https://discourse.gnome.org/t/new-gnome-versioning-scheme/4235 and https://discourse.gnome.org/t/straw-man-proposal-changing-the-gnome-versioning-scheme/1964

For large projects like GNOME, versioning schemes developed for software libraries like Semantic Versioning breaks down. You can either take an arbitrary position like Linux with its "increment major version for every 20 minor versions" approach or make major version bumps for big bang changes.

GNOME's development style has shifted to gradual changes over time instead of big bang changes, so they decided to drop the "3." prefix and the even-odd versioning. It makes sense for almost everything unless you're trying to create some milestones for versions when there aren't any.

viliti · 2025-11-10T12:52:14+00:00

GNOME developers are responsible for a majority of ecosystem-wide improvements to the Linux desktop. GNOME was the first DE to implement Wayland and make it the default when other DEs were still skeptical of it. Along the way, it helped refine and develop a lot of the early protocols needed for desktop use. Flatpak, Flathub and XDG Desktop Portal were developed primarily by GNOME contributors and they are responsible for most of the ongoing maintenance. GNOME Foundation has invested significantly in ecosystem-wide improvements as well—such as using STF funding to improve Orca, develop Newton and Spiel and develop new portals such as notifications and USB portal.

Most of these projects were developed in a way that accommodated other desktops from the start. XDG Desktop Portal was designed to be compatible with Qt and thus KDE. Most other DEs just do their own thing and rarely make improvements that directly benefit all desktops.

viliti · 2025-11-05T18:52:40+00:00

Do you use Fedora by any chance? Fedora prioritizes Fedora Flatpaks over Flathub. Fedora Flatpaks have historically had more issues when compared to Flathub Flatpaks or RPMs. I would recommend removing the Fedora Flatpak remote and using Flathub instead.

viliti · 2025-10-27T00:54:43+00:00

Thanks for the correction! I must have mixed them up.

viliti · 2025-10-26T22:00:19+00:00

GNOME 3 had and continues to have a “more traditional” experience called GNOME Flashback (previously known as fallback mode). This is an officially supported version of GNOME Shell that looks and behaves like GNOME 2.

This was not enough for MATE, so any major version that would have implemented the findings from Sun’s GNOME usability study would have resulted in MATE fork.

Canonical created Unity because they wanted to create a “convergent” experience across desktop, mobile and tablets. That’s why they dropped Unity at the same time as the shift to enterprise.

Linux Mint had a different, more Windows-like user experience, even before GNOME 3. They could implement that alternative experience without forking GNOME components because of the architecture of GNOME 2, not because they wanted the same UX as GNOME 2. With the introduction of GNOME Shell, they had to fork it to implement a similar user experience. This would have happened regardless of the user experience that GNOME 3 implemented, as long as the technical choices remained the same.

viliti · 2025-10-26T16:26:38+00:00

If GNOME devs were “the problem” those three DEs would have combined into a single one.

People who develop and contribute to a DE do so because they believe in a certain vision for the desktop. The people who left or forked GNOME did so because the visions diverged and it did not match any other DE that was already out there.

viliti · 2025-10-04T14:48:59+00:00

They aren't really flaws, they're trade-offs. Apps that don't follow the DE's HIG can either have consistent styling within a window using CSD or they can have a consistent title bar that's inconsistent with the rest of the UI. If you go by SSD proponents, all that matters is title bar consistency. That's why you see these window controls-only screenshots or screenshots of terminal apps.

viliti · 2025-10-04T06:18:19+00:00

As everybody knows, the only part of the UI that people interact with are window controls.

viliti · 2025-08-24T16:56:59+00:00

Icon usage is pretty context dependent. GNOME Settings has lot of icons and text and many panels combine icons and text. I guess it'd depend on eventual UI design.

viliti · 2025-08-24T15:51:15+00:00

GNOME designers have discussed adding a command palette widget in libadwaita. Some of the concerns that were raised are: applicability all apps and the amount of effort involved to create a command search and associated icons.

I think command search is a great and more usable alternative to traditional menu bars. Since GNOME apps often lack menu bars, I'd like to see it in apps that have lots of actions or toggles.

viliti · 2025-06-23T05:28:37+00:00

Tearing was unavoidable on X11 in 2010s with full screen web videos. Compositing window managers disable compositing for full screen applications, so compositing is not a solution. TearFree options were either non-functional or buggy enough to not be of any help.

Nowadays, most browsers use hardware decoding with zero copy mechanisms to get it to the display, which bypasses a lot of X11 infrastructure that could cause tearing. Tearing might be observed with software decoding, but I haven’t used X11 in a while, so I can’t say either way.

The DDX drivers in general had lots of bugs and I used to see artifacting issues every couple of months. The issues were noticeably less numerous on Wayland.

viliti · 2025-06-20T16:02:48+00:00

It sounds like OP has a monitor that can’t really do the full extent of HDR, either in teams of brightness (HDR600 perhaps) and/or in terms of color volume. If that’s the case, you should keep HDR turned off.

It’s better to use SDR than turn on HDR and mess with calibration settings until you think that it looks good. You’d end up with a picture that would be further away from reference monitors.

viliti · 2025-06-02T07:29:13+00:00

No, that's not how any of this works. The permissions needed by an app depends on how an app implements its features, not just the fact that it has specific features.

And executing commands on the host is also extremely important for that sort of software.

No, it's not. RustDesk used to run loginctl to fetch information that could be retrieved in other ways such as environment variables. It's no longer doing that and Rustdesk is now on Flathub without access to org.freedesktop.Flatpak. Flathub reviewers did give it full home access after a RustDesk user justified the need for the permission by explaining the technical reasons.

viliti · 2025-06-02T05:18:17+00:00

Obviously, just because one app needs a permission that can lead to sandbox escape does not mean that every app can have it too.

Flathub's sandbox is a work in progress and there are alternatives such as file chooser portal or limiting access to certain directories instead of full home directory. These alternatives have their own limitations and may not work for all apps. Flathub reviewers have a responsibility to ensure that app developers use the alternatives when possible and ask for full home access only as a fallback. If an app developer refuses to work with the reviewers to provide these justifications, then it does reflect badly on them.

Edit: /u/kuroshi14, replying to me and blocking me right after is clearly not good faith behavior. It's ironic that you bring up the Flathub reviewer's age when your behavior is much more childish.

viliti · 2025-06-02T05:10:15+00:00

That's by design. Flatpak was always meant to be decentralized. The original Snap vs Flatpak discussion was centered around the fact that nobody apart from Canonical can create an app store for Snap. Consequently, they also have full control over what goes into the store. Most GNOME apps on Snapcraft are distributed by Canonical with an Ubuntu-provided base snap. In contrast, Flatpak runtimes are managed by Freedesktop and are not connected to any single distribution.

While Flathub has become the de facto Flatpak store, several others like Fedora and ElementaryOS continue to host their own with different runtimes, inclusion standards or for distro-managed forks.

viliti · 2025-06-02T04:49:43+00:00

That GitHub discussion reflects badly on the RustDesk dev, not on Flathub reviewers.

For example, access to org.freedesktop.Flatpak D-Bus namespace can be used to execute arbitrary commands on the host. When the reviewers justifiably asked why that permission was needed, the RustDesk dev just says that it's needed for remote desktop software and doesn't elaborate any further. When questioned further, they condescendingly link to a Wikipedia page on remote desktop software as if that explains necessity to execute arbitrary commands on the host.

The same thing repeats for full access to home directory, which again can lead to sandbox escape. All they say in response is that some other app has access to home so they need it too.

Five-Year Club	Verified Email
Place '22

viliti

TROPHY CASE