Open Raster as an interchange format instead of PSDs. It would be nice if I could open the same file in GIMP or Krita that I can in Photoshop.

Forty years ago, Richard Stallman announced the plan to develop the GNU operating system

This is completely true. The GNU Project’s plan was to build an operating system in 1983, and they intended to call it GNU. The fact that they didn’t build every tool for the operating system doesn’t change their goal or the work they put into it. We have GNU Guix now, an operating system “entirely composed of free software”, so mission accomplished?

Honestly I laugh at the people whining about password sharing getting shut down. It was never really intended to be used that way

To quote Netflix, “Love is sharing a password”: https://twitter.com/netflix/status/840276073040371712?ref_src=twsrc^tfw

I haven’t been subscribed to a streaming service for about five years. Well, sometimes I pay for a month of Hidive. I usually just buy the show/film on disc and rip it. A decent amount of the shows I want to watch are old and not even on a streaming service.

Ah, okay. It sounds like you have a physical server, too…you would need to upgrade it yourself if you wanted to use AV1, right? Sounds expensive and annoying…

My understanding is the client needs to explicitly support hardware decoding with the relevant APIs, and Jellyfin probably accomplishes it with FFmpeg. There is no way Jellyfin would be implementing a software decoder for HEVC, but they should have no problem implementing hardware decoders for every platform.

iOS doesn’t even have a software decoder for AV1 yet, but the iPhone 15 Pro hardware decoder is a start. Likewise, only expensive Android phones have hardware AV1 decoders right now. More desktop GPUs are implementing AV1 decoders. But this transition looks like it’s going to take another 3 years (?) to hit every market segment (cheapest to most expensive)… sigh. I don’t have an AV1 hardware decoder on any of my devices either. It’s insane how long it takes for new hardware decoders to become mainstream. Many HEVC patents might be close to expiring by then, lol.

I don’t have a lot of experience with this, but if you want more logs, you can try upping the WINEDEBUG debug channel: https://wiki.winehq.org/Debug_Channels

Oh does it not add new entries for every new DXVK release anymore?

Looks like the last time a verb for a new DXVK version was added was dxvk2010 or DXVK 2.1, in February this year. We’re up to DXVK 2.3 now. Because the Winetricks codebase is around 20,000 lines of shellscript and I’m not the best at reading shellscript…I don’t think the dxvk verb updates the Wineprefix’s DXVK version based on what the newest version is. I think that’s just an alternate way of installing DXVK; you can pull the latest stable release, or you can install a particular version.

I think executing a particular verb for a DXVK version would override whatever DXVK dlls you currently have installed in that prefix, too. I have no idea how to check what DXVK version is installed a particular Wineprefix, though.

even though it says DXVK (Latest) and that it’s from year 2023

That’s based on the verb metadata; not what version of DXVK you currently have installed. A contributor bumped the year for the dxvk verb from 2017 to 2023 in a commit in February this year.

Oh I had no idea about this, and I normally just use winetrick’s GUI while using it so I would’ve had to look up how to update dxvk if not for you explaining it.

Happy if it helps. I’ve never used the GUI, but it’s awesome that they managed to create a functioning GUI frontend with shellscript. Insane, really. God I hate shellscript…

So far I haven’t had an issue with DXVK being too old, but I mostly play older games

You probably won’t get an issue with DXVK being “too old”, but newer versions of DXVK implement more features (particularly for D3D12) and include bug fixes to improve compatibility or performance. From the 2.3 release notes:

Fixed a minor issue with D3D9 feedback loop tracking.

Test Drive Unlimited 2: Fixed shadows on grass.

Tomb Raider Anniversary: Improved performance.

So you want to be running the latest version for better compatibility. That said, I mostly play visual novels. My biggest problems are still DRM and media playback, which DXVK has very little to do with.

Unrelated but I’ll check that guide out, I’ve had trouble playing VNs that are in Japanese, as without LANG=“ja_JP.UTF-8” wine /path/to/game.exe they won’t even run but even with it the fonts don’t work and are shown as empty boxes.

You’re the exact person this guide was written for! This sounds like an issue that’s easily fixed by installing fakejapanese with winetricks. More info here: https://wiki.comfysnug.space/doku.php?id=visualnovel:problems#japanese_characters_aren_t_displaying_properly

And if you have .txt files in the game directory (like documentation or whatever) with garbled text, that’s probably because they’re encoded in Shift JIS. There’s an easy fix to make them readable: https://wiki.comfysnug.space/doku.php?id=visualnovel:problems#text_files_with_garbled_text

(That last one had me scratching my head for a very long time)

This was a use case I was introduced to directly before I discovered Firefox was introducing support for HEVC decoding.

I use HEVC because it has significantly better compression than older codecs, and many modern devices have hardware decoding support for HEVC.

If it weren’t for iOS, VP9 could take its place, or so the Mozilla developers thought. HEVC and newer codecs like VP9, AV1, VVC, EVC, etc. offer better compression but often at the cost of compute. I imagine hardware decoding evens the scales a lot; I haven’t done any benchmarking myself. I don’t know how much impact the complexity of H.265 vs H.264 has on battery life, if any. Of course, hardware encoding on VP9 is not really a thing (AV1 is ahead of it, even), so HEVC has the edge there.

In a few years, AV1 hardware implementations will hopefully be ubiquitous; that would solve the efficiency and software patent problems at the same time. It’ll probably coincide with the last of H.264’s patents expiring. So on the one hand, I can understand why Mozilla is in no rush to support HEVC.

So I imagine you use a Chromium-based browser for Jellyfin?

I’m on GNU/Linux myself, and personally, I don’t use HEVC at all. I don’t even decode video in my browser most of the time. I’m usually using mpv with yt-dlp. Streaming services like YouTube, Facebook and Netflix don’t use HEVC to my knowledge (being AOM members and all), but I don’t use services that require me to enable DRM in my browser. I don’t know of a service that requires HEVC decoding support.

It’s possible Mozilla will support HEVC decoding on other operating systems in the future. Windows is just the easiest one to start with. It’s worth noting that Chrome’s HEVC hardware decoding support does not support Widevine, the DRM Netflix and other streaming services use. So you won’t see them adopting HEVC in browsers, at least.

The fact that this bug for macOS is a part of the hevc meta-bug indicates that Mozilla also wants to support HEVC decoding on macOS: https://bugzilla.mozilla.org/show_bug.cgi?id=1839107

Chrome supports HEVC decoding on GNU/Linux, so I don’t see any reason why Firefox wouldn’t too, eventually.

In about 5 years, the last patents for the baseline H.264 (AVC) video codec will expire. This means Firefox will finally be able to support decoding for H.264 (the codec most commonly used with the MP4 container) without Cisco needing to cover the licensing fees for them. DaVinci Resolve will also be able to support decoding/encoding on GNU/Linux. Basically, anyone will be able to implement a H.264 decoder/encoder without needing to pay royalties, which means free software programs like Firefox which don’t charge their users will be able to implement it. The codec will no longer be patent-encumbered. See Wikipedia’s debate on whether to support H.264 in 2014 for lots of opinions on this: https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/MP4_Video

However, H.265 (also called HEVC) is the “next-generation” video codec after H.264. The patent pool situation is so confusing and expensive compared to H.264 that Mozilla, Google, Apple, Microsoft, Netflix, and dozens of other companies using video compression technology formed the Alliance for Open Media to develop a royalty-free codec they could use instead of HEVC. As a result, HEVC has seen very little adoption, particularly on the web. Most companies continue to use H.264. Windows 10 asks you to pay $0.99 for HEVC decoding support in the default video player. In fact, Google even announced they were dropping support for H.264 in 2011 because of their “focus on open web principles”: https://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html

They never went through with it, of course.

AV1 is finally at a point where there are production-ready encoders and decoders. The iPhone 15 Pro is shipping with AV1 hardware decoding support, so even Apple is on board (though only for the most expensive phone so far). So, we’ll see hardware decoding support in more phones in a few years, and hopefully AV1 will see a lot of adoption.

Adding support for HEVC in browsers feels like a step back because it legitimizes the codec and works against AV1 adoption. Many of these companies have resisted implementing HEVC support (aside from Apple) because it positions AV1 as the only realistic option to shift to from H.264. With HEVC in the picture now, it might be a realistic option in the future. Well, there’s VP9 too, but there are some patent disputes over that codec that might make companies sheepish about adopting it. Not that AV1 is free from those disputes either, but they are far more confident about it and Unified Patents is doing great work invalidating Sisvel’s AV1 patent claims (and even some HEVC patents here and there).

My opinion is that the ship has already sailed. Chrome caving in and adding HEVC support last year, albeit only with hardware decoders, was all it took with their 90%+ market share. Firefox’s 3% market share isn’t going to make a dent, and not doing it risks keeping users who need HEVC support on Chrome. I also don’t think hardware decoding support is a big deal right now due to all the older devices without HEVC hardware decoders, but it opens the door to ask for more support down the line. I very much doubt Google is going to do that, though.

Windows users have been asking for HEVC support for years: https://bugzilla.mozilla.org/show_bug.cgi?id=1332136

7 years ago, this was the answer:

Mozilla currently has no plans to support H.265. Our focus will be on AV1.

The reason we won’t support H265 has nothing to do with the difficulty in finding a decoder, or that a decoder source code is released under GPL. Those are trivial matters.

We will not support h265 video while its patent encumbered.

BTW, even today vp9 provides better results than H265.

The conversation changed to, “Firefox could at least do hardware decode support without worrying about patents, right?”

My guess is they’re doing this because Chrome added HEVC hardware decoding support last year.

I had some problems with alt tabbing in really old versions of Warcraft 3 (1.27 and older)

Have you tried Gamescope? I experienced similar issues with a lot of older visual novels. Gamescope was the cure-all for windowing issues like this. That said, if WineD3D works better than DXVK for the game, there’s not much reason to look into it.

Oh, mobile. That’s not a platform I use often. I’ll defer to you on that!

All my media is in HEVC and I dont want to have to buy a video card for the server just so I can transcode it to Firefox when everything else can play HEVC out of the box.

As far as I know, Google Chrome did not support HEVC until last year. Safari is still the only browser with a software decoder for HEVC, but I’m pretty sure it was the only one with any form of decoding support for HEVC until 2022. Let me check caniuse!

https://caniuse.com/hevc

So, it seems Samsung Internet (a browser I’ve never heard of, but presumably is the default on Samsung devices) also supported HEVC decoding for a long time, but aside from that, even hardware decoding support in Chrome is super recent: https://bitmovin.com/google-adds-hevc-support-chrome/

I was going to make a snarky comment about VP9 being good enough for Sisvel since they’re trying to chase down Google for patent infringement royalties on HEVC, but yeah, transcoding all that media does not sound fun.

But on the other hand, a bug triager for Mozilla opened a new ticket for HEVC support 3 months ago: https://bugzilla.mozilla.org/show_bug.cgi?id=1842838

It’s a strange ticket. No description at all, and why would they care about bugs for a video codec they don’t support? It suggests Mozilla is going to do…something with HEVC sometime in the future. Shrug.

Edit: Did some more digging. See this ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1853448

HEVC playback will be supported via the Media Foundation Transform (MFT) and WMF decoder module will check if there is any avaliable MFT which can be used for HEVC then reports the support information.

HEVC playback can only be support on (1) users have purchased paid HEVC extension on their computer (SW decoding) (2) HEVC hardware decoding is available on users’ computer

HEVC playback needs hardware decoding, and it currently only support on Windows. HEVC playback check would be run when the task is in the mda-gpu, which has the ability for hardware decoding. On other platforms, HEVC should not be supported.

Hooray for Windows users, I guess.

Reasonably sure, but willing to be corrected. See this section of the Winetricks code (it’s just shellscript):

        # Don't install if already installed
        if test "${WINETRICKS_FORCE}" != 1 && winetricks_is_installed "$1"; then
            echo "$1 already installed, skipping"
            return "${TRUE}"
        fi

Followed by:

winetricks_is_installed()
{
    unset _W_file _W_file_unix
    if test "${installed_exe1}"; then
        _W_file="${installed_exe1}"
    elif test "${installed_file1}"; then
        _W_file="${installed_file1}"
    else
        return "${FALSE}"  # not installed
    fi

    # Test if the verb has been executed before
    if ! grep -qw "$1" "${WINEPREFIX}/winetricks.log" 2>/dev/null; then
        unset _W_file
        return "${FALSE}"  # not installed
    fi

Winetricks determines whether a verb has been installed by writing and reading to a winetricks.log file found in the root directory of the Wineprefix you’re working with. It also tests if the file actually exists too, but let’s just focus on winetricks.log for simplicity.

The first time Winetricks installs the dxvk verb, which takes the latest DXVK release at the time you run it, it writes dxvk to the winetricks.log file. When a new version of DXVK is released, and you run WINEPREFIX=~/.local/share/wineprefixes/whatever winetricks dxvk, it will hit winetricks_is_installed and read ~/.local/share/wineprefixes/whatever/winetricks.log to see if DXVK is already is installed. It will see that dxvk is in the log file and give up.

When I was writing the Visual Novels on GNU/Linux guide, I did a lot of experimentation with Winetricks. I installed dxvk in a Wineprefix a few months ago and haven’t touched it since then. A new version of DXVK was released three weeks ago. When executing the dxvk verb in that Wineprefix again, I get:

Executing w_do_call dxvk
dxvk already installed, skipping

Years ago, Winetricks would write a new verb definition for every new DXVK release. Presumably when it was much less stable. You can see remnants of that with the 100+ verbs for installing particular DXVK versions. Now it just takes the latest stable release. Yay for the maintainers, because that’s a lot less work. As a side effect, Winetricks doesn’t have a way of updating it normally.

Why doesn’t Winetricks have the ability to update verbs? Well, you’re often installing very specific versions of a native DLL to override the builtin Wine component. You don’t want that changing on you randomly. The w_get_github_latest_release function, which extracts the latest release, was created purely for and only used for DXVK. DXVK is the only component that really works like this in Winetricks.

There is an easy way of updating DXVK anyway. Just run Winetricks with --force:

WINEPREFIX=~/.local/share/wineprefixes/whatever winetricks --force dxvk

Now, admittedly, I misspoke about Winetricks “not supporting updating DXVK”. I learned this option exists just now. So you can force-update it with --force, which bypasses winetricks_is_installed and installs the latest version of DXVK. Guide has been updated accordingly; thank you for making me look into this again!

Profile switching is a big one for me.

You can change profiles by going to about:profiles. I find the way it’s implemented in Firefox preferable to other browsers but I can see why others wouldn’t.

You can also start up the profile switcher when you launch Firefox when launching it from the command-line with firefox -p.

Is this what you were talking about, or were you referring to something different?

but I would like to at least have the option for H.265 support.

Google Chrome only recently implemented this via hardware decoding. I imagine it’s possible for Firefox to do the same thing without infringing on patents, as the browser doesn’t implement a decoder this way; rather, they use the decoder implemented by NVIDIA et al.

I can only laugh when I consider Google announced they were dropping H.264 support 12 years ago: https://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html

H.264 support only exists in Firefox by the grace of Cisco. Out of curiosity, why are you interested in H.265 support?

If you want to play visual novels, you should watch out for games encumbered by DRM.

It’s possible to play non-Steam games without Lutris, Bottles, or Heroic Games Launcher, though it’s a little more annoying. The easiest way to install DXVK in a Wineprefix is using Winetricks. Just run WINEPREFIX=~/.local/share/wineprefixes/name winetricks dxvk.

The problem is Winetricks doesn’t support updating DXVK. Lutris makes managing DXVK a lot easier; you can turn it on or off and it will update DXVK and other compatibility components automatically.

Vulkan support is of course required for DXVK to work, but DXVK isn’t your only option for Direct3D translation. You can also use Wine’s OpenGL translation layer, WineD3D, which requires no setup. The downside is that WineD3D’s compatibility and performance is generally not as good as DXVK for the same versions of the Direct3D APIs. However, if your GPU doesn’t support Vulkan, then you need to use WineD3D.

On the other hand, if your GPU does support Vulkan, Lutris’ documentation provides a good place to start on installing Vulkan support for your distribution: https://github.com/lutris/docs/blob/master/InstallingDrivers.md

I wrote a guide explaining how the various components of Wine work to make games compatible. That might help you understand what exactly you need to do if you’re not using a Wine manager. And, if you want to make things easier when working in the terminal, you can try these Quick-Access Shell Functions the Winetricks wiki provides.

A popular spreadsheeting program that was displaced by Microsoft Excel in the '90s.

There’s also this infamous quote:

DOS ain’t done until Lotus can’t run

More information investigating the source of this quote: https://www.proudlyserving.com/archives/2005/08/dos_aint_done_t.html

I’m familiar with the history of GNOME, and somewhat with Xamarin and Mono. While I have made that argument in the past, it was pointed out to me that the GNOME name was used to ride off the coattails of the popularity the GNU project had in the '90s, and they ended the association when it stopped being convenient for them.

(A GNOME developer pointed this out to me using this language; I could link you to the interaction, but it was on reddit)

I mean, both RHEL and Debian use Glibc which means the vast majority of the Linux applications running outside the cloud are calling into GNU code.

This also includes the proprietary NVIDIA driver, which only works with glibc.

Unlike GNU, his vision of the Linux desktop was populated by music players, spreadsheets, email / calendar programs, PDF viewers, and video editors.

I think this is a strange characterization of the GNU Project’s goals. This is the Initial Announcement for the GNU Project:

To begin with, GNU will be a kernel plus all the utilities needed to write and run C programs: editor, shell, C compiler, linker, assembler, and a few other things. After this we will add a text formatter, a YACC, an Empire game, a spreadsheet, and hundreds of other things. We hope to supply, eventually, everything useful that normally comes with a Unix system, and anything else useful, including on-line and hardcopy documentation.

and eventually a Lisp-based window system through which several Lisp programs and ordinary Unix programs can share a screen.

Do you know something I don’t? I don’t think the GNU Project was against multimedia software; they were just focusing on the more fundamental stuff first.

The GNU Project’s biggest contributions were when the kernel was in its infancy. The most major contribution is undoubtedly the GPL. Without it, Linux would not be where it is today. I think enough has been said on that subject, but it’s what made RHEL billions. It’s the philosophy of free software that has made so much of the programs today possible. It’s incredibly important.

Obviously, we also have the GNU Project financially backing Debian GNU/Linux in its infancy. And while you say GNU wasn’t involved in the GUI layer, that’s not true. They worked on the free Harmony toolkit as a matter of high priority, and would have kept working on it if GNOME had not been so successful. Thanks to the success of another GNU project, GIMP, the GTK toolkit was able to be repurposed for general usage.

I don’t think it’s fair to discard contributions that never panned out like HURD and Harmony, because it shows GNU was actively involved in making the desktop better for everyone, which has really been its mission from the start. Maybe they’re not “the backbone” of the desktop, but I think it’s fair to say their biggest/most notable contributions have been to the desktop, not the server.

I don’t contribute to the GNU Project because frankly, they don’t do anything I consider worthwhile at the moment. I don’t contribute to the Linux Foundation, either. I contribute to user-facing software I’m interested in, like Lutris, GIMP, and Kdenlive.

It’s a good movie, but I find myself completely confused by the driving part at the end. The people who were in the van manage to catch up to him almost immediately, suggesting that the other guy could have just run across the distance to get to the van in the first place, saving everyone all the drama and hilarity.

I thought Wargames was a pretty good one too (mostly). It’s by the same writers.

The NET is…fun…

That’s a nice piece of hardware you’ve got there.

I’m just quoting the Free Software Foundation themselves. I didn’t say I agree with them. It’s a deceptive use of language that is rather unbecoming of an organization normally so careful with its words.

Edit: For the record, I think the GNU Project’s biggest contributions have been to the desktop, not the server world.