leopold @ leopold @lemmy.kde.social

Posts

0

Comments

239

Joined

2 yr. ago

is this flamebait? we really don't need this stale-ass debate revived for the millionth time. everything that had to be said has been said and no one is going to budge from their positions. there is nothing to be gained from reposting some old controversial 2021 blog post about this outside of more flaming. it's time to move on. this is a waste of everyone's time.

if you're a developer, support themes if you want to support them, don't support them if you don't. if you're a user, use the apps you want to use. if you care about theming, use the apps that support it. if you don't, good for you. there doesn't need to be anything more to it.

steam is fully themable btw

if you're coming from i3, you may want to check out Sway instead.

Well, technically the OG would be Quake, but Yakuake did come before Guake.

Neither is a fork of the other, but Yakuake came first. I assume it has more features, since that's how it usually goes with KDE apps vs GNOME apps. Haven't tried Guake, tho.

VP9 is AV1's predecessor and VP8 is VP9's predecessor. Dunno what the “264K 360° Surround sound 3D VR” thing is about, but AV1 is a good general purpose video codec and I recommend using it, with Opus audio.

EDIT: I should add, h264 and h265 are non-free because of software patents, for which there are licensing fees. There are free implementations and there always have been, but the extent to which these implementations can actually freely be used legally is limited by this. Cisco's OpenH264 is an exception, because there is a cap to the licensing fee and Cisco is already paying the max amount. This allows them to freely distribute binaries for their h264 implementation without having to pay additional licensing fees for every user. It's a clever loophole, but there are still limitations, namely that you have to be using Cisco's pre-built binaries. If you want to use the source code, you still need to pay for the licensing fee.

Because patents last twenty years and the initial release of h264 was made in August 2004, the key h264 patents should all expire within the next few years, which will eliminate the problem. h265 however was introduced in 2013 and its patents still have a good decade left in them.

Is there any particular problem with MoltenVK? As I see it, it's by far the best solution for cross platform software on macOS in need of graphical hardware acceleration.

RHEL is used and is meant to be used both for servers and professional workstations. I imagine clones like Rocky are much the same.

Not just snapshots. Also compression and CoW.

color management is by no means "mainly used" in gaming

basically every big tech company does at least a little

Ah yes, the most misused xkcd. AppOutlet isn't a new standard. It's a frontend which attempts to support all of the existing standards. There is no special AppOutlet package format or repository. It's simply an application that can install Snaps, AppImages and Flatpaks, which you would be installing anyway through other means.

This is like looking at VLC's support for dozens of multimedia formats and calling it a new standard. VLC isn't a multimedia format, it's a multimedia player. It implements the existing multimedia standards, it isn't itself supposed to be one.

KDE Discover supports Snap, Flatpak and distro packages (through PackageKit). It doesn't support AppImage, though. It also doesn't work very well outside of Plasma.

nearly your entire system is written in C and you're worried about a simple fetch program

They attempted to add opt-in telemetry a few years ago and people lost their shit for some reason. They didn't merge it, but the FOSS community's "fork first ask questions later" attitude kicked in anyway and multiple forks popped up while now the original project has permanently been labelled as spyware, which is fun. Fun fact, KDE Plasma actually has opt-in telemetry. Dolphin, Kate and a few kdepim apps also do. Plasma also has opt-in automated crash reporting, which is particularly evil. Y'all better uninstall them right now. I mean, what if you accidentally opted in, or something? Anyway, not a fan of hostile forks unless someone can actually prove the original project has gone to shit.

that would be Inferno

This would be a ludicrous time investment for very little gain.

ElementaryOS has nothing to do with Red Hat or Arch. It's Ubuntu LTS with a custom macOS-like desktop environment called Pantheon. Being based on Ubuntu LTS means packages only get updated every two years, so they can be a bit old. Debian has the same problem, tho. If you like macOS, you might want to use it. Otherwise, you might not. Worth noting that Pantheon is available on distros other than ElementaryOS (but not Debian).

I would call iOS mostly proprietary, but not Android. It is entirely possible to have a fully usable Android system with AOSP, as shown by LineageOS and other free software Android distributions.

Meanwhile the available Darwin source code is nowhere near enough to build anything remotely resembling iOS, or even any usable operating system. OpenDarwin died in 2006. PureDarwin tried to become successor, but that hasn't gone so well. They got Darwin 9 working okay, but then got stuck porting to Darwin 10 (which is still from 2009).

True. If their goal is truly to use the "native" solution everywhere, they should use QtWebEngine on Qt desktops. For the most part, the advantage with Tauri isn't so much that it's using the "native" web engine, it's that not every Tauri application has to bundle a full (probably outdated) web engine. On Linux, this is achieved regardless of whether WebKitGTK or QtWebEngine is used. The first Tauri application you install pulls in WebKitGTK if you didn't already have it installed, then every subsequent application just uses the same one. I'm personally glad it's using WebKitGTK despite being a Plasma user. The less we rely on Blink and Blink-based web engines, the better. Having to spend 100MB of my 1TB hard drive on WebKitGTK to achieve this isn't making me lose a whole lot of sleep.