Finger info for flibitijibibo@icculus.org...

flibit's Official Catalina Plan

Hi everyone!

I'm supposed to be out of the office until the 8th, but I'm up late tonight (even though I've had about 10 hours of sleep over the last three days) and I wanted to address an issue that clients and partners have been asking me about for many weeks now. I'm exhausted, but it's really important, so I'll try to power through this:

When macOS Catalina releases this month, two major changes are going to happen:

The first issue is pretty basic, to be honest - if you support other modern platforms (Linux, PS4, Xbone, Switch) you've had lots of motivations to get your game to be 64-bit clean, so ideally you can rebuild and go back to bed.

For FNA games in particular this has been a non-issue from day 1, as there was only ever a 32-bit only kick.bin.osx for private cases where sgen was mandatory (back when sgen macOS didn't work on x86_64). I have already finished updating for all of those scenarios, at least for the SKUs I maintain.

Part 1 largely affects the back catalog; games running on crusty old stuff like Adobe AIR or various proprietary engines will be cut loose by this. Even if you can update your games there are still lots of old games that are going to get axed for no real reason other than that Apple doesn't want to build i386 binaries anymore. CodeWeavers happens to be building a 32-on-64-bit build of Wine right now for this very reason, but they are most likely the only ones in the entire world who are doing this and they will be the first to tell you that what they are creating is absolutely absurd. It's cool, yeah, but yeesh.

That's pretty bad by itself, but part 2 is what has been making headlines over the past couple weeks: Notarization.

For those who are unaware: The traditional way to ship a Mac app, regardless of storefront, is the following:

Signing associates a program binary with an approved Apple developer account. An account is $100USD a year for individuals and $300USD a year for businesses. There is no cap, this fee must be paid every year in perpetuity, or else your license will be revoked and your program will be treated like an unsigned app. UPDATE: A few people have asked for clarity on this particular part, so here's a link to Apple's documentation on this. In short: Apps that have already been run once should be okay, as long as you're not an Enterprise app, but on the App Store in particular you will no longer be available for download, and since the App Store is the ultimate endgame for Apple...

Unsigned apps, when run, will get blocked and will be presented with a pop-up that says something along the lines of "this program did not open because it is not made by an authorized developer." There are many ways to get around it, but most of them are in GUIs that change frequently and are sometimes mysteriously locked. The only consistent method around it is via Terminal:

sudo spctl --master-disable

With macOS Catalina, the process is now as follows:

The process for notarization is absurdly long, but it can be boiled down to this: Your program uses a different OS runtime that is more restrictive in the hopes that it will make the program more secure, and before shipping you must upload your program to Apple's servers so that they can run what is effectively an antivirus scan. As far as I know, this process is 100% automated.

I personally have some questions that I suspect will forever go unanswered, such as "why can we not just use the hardened runtime regardless of signature if it improves the user experience," "why am I uploading a binary to run an antivirus," "why does Apple need an antivirus all of a sudden," "why is the antivirus scanner not on users' machines so it can be run on any program regardless of signature," "why do people pretend security is a thing anymore when web browsers still exist," and so on. But I'm not here to talk about that, I'm here to talk about what my plan is for this new step.

I'll tell you what I'm doing: Not a single damn thing. I have stood my ground and refused to sign Mac apps from day 1, and I will continue to do what I do without notarizing them either. I encourage developers to do the same, and I encourage users to let developers know that they do not need to buckle to Apple's pressure to monetize computer users' ability to create and share programs with each other as we have, freely, for the better part of a century.

I am not a macOS fan myself, but to those who are wary about supporting macOS in the future: As long as I and my colleagues continue to build for the Mac, we need you as much as your existing Mac customers do. Here's why: This line still works for apps that are not notarized:

sudo spctl --master-disable

Yes, I know we've all seen that Valve e-mail and they didn't do this for signed apps, so clearly it must be different. It is different, but not in the way that was implied. Long-time Mac users are fully aware of these arbitrary blocks and users have always been perfectly happy tearing them down each and every time a new one was introduced. Since Gatekeeper was first introduced in 10.8, 7+ years ago, I have had zero users complain to me when I told them to disable it. It's not just developers that aren't buying into Apple's "security" excuse, users aren't buying it either.

So what I am asking everyone to do is to share this command with everybody. I don't care who it is, just tell them that this exists and if they ever need it, that's the command to run. Someone should make a website if it's necessary. fixmacos.com maybe? It wouldn't be the first time...

The more people that do this, the more likely it will be that your program will magically just work as it did before, because users will have already done it for another program that they were running before. If enough people do this, users will learn to just do this by default before running anything, effectively killing Gatekeeper (until Apple decides to kill the flag, which at this point would be a blatant and indisputable act of pure hostility).

And yes, I'm talking to YOU, the person reading this right now. Don't just go on Twitter and prod the popular kids to do this for you, odds are they're the ones that are paying the fees and will talk down to you with the usual "well that's just your problem" or some other miscellaneous Apple bootlicking. The people who have power and influence totally could have done something about it but decided to be absolutely silent (or worse, supportive) on the matter, so now it is everybody's responsibility equally until people have the resources necessary to move to Linux, which never has ridiculous barriers like this (but admittedly has had 32-bit threats in the past even after the feedback from Catalina was well-known, shoutout to the galactically tone-deaf management at Canonical!).

Apple has definitely gotten into the business of burning bridges lately, from deprecation of open standards to crippling their own developers' basic freedoms. But until the last bridge has been thoroughly burnt down, it's our responsibility to save as many of our customers as we can, rather than ostracize them after they put their trust and faith in us. We can do better than Apple in this regard.

-Ethan

SPIR-V Emitter for MojoShader (BETA)

After many months of development, primarily headed by Martin Krošlák, we're now ready to start testing a new SPIR-V shader emitter for MojoShader!

WTF is this?

FNA uses MojoShader for D3D9 shader support. Over the last 5 years, we've made numerous contributions to MojoShader, including full support for the Effects framework as well as various other features for simplified D3D9->OpenGL compatibility.

SPIR-V support is our next big contribution to MojoShader. SPIR-V is the official shader binary format for Vulkan, as well as an added shader format for OpenGL 4.6 (via ARB_gl_spirv).

This SPIR-V emitter is primarily focused on compatibility with ARB_gl_spirv, though there isn't much going on that would prevent this from being usable with Vulkan. We don't have a VulkanDevice yet, so for now this is purely for the extremely narrow subset of configurations out there that support OpenGL 4.6.

Who is this for?

If everything works perfectly, this is completely invisible to customers. It does not provide any benefits in performance or stability whatsoever. In fact, I plan to keep this turned off for the default OpenGLDevice once it's officially integrated, leaving it on only for the ModernGLDevice.

As far as I know, this feature is only supported on the following drivers:

In reality, it's mostly for anyone who wants to try writing VulkanDevice. It's also for any of the Mesa developers who are working to get ARB_gl_spirv supported by radeonsi/i965/iris, or whatever other drivers are looking to finish OpenGL 4.6 compliance. As far as I know, basically nobody uses this feature, so I hope we can help provide some real-world data for the Mesa team to use!

I want to try this, where do I go?

I've prepared an issue tracker here:

https://github.com/FNA-XNA/MojoShader/issues/15

The repository is here if you want to see it:

https://bitbucket.org/krolli/mojoshader/src/spirv-rebased/

Who is responsible for this?

This has been worked on by a lot of people, all of which are not me! I basically just dumped some money into this (and not even that much, to be honest). This was made by many skilled developers, including Martin Krošlák, Caleb Cornett, Angus Holder, and Melker Narikka.

An extra shoutout to Baldur Karlsson who added ARB_gl_spirv support to RenderDoc extremely quickly after we asked for it! RenderDoc rules!

If you give this a try...

... thanks for your time! I'll be out of town this weekend (Aug 16-18) so don't feel too rushed to try it out.

Want a Linux game?

I'm now working my way back to just making native Linux games, slowly but surely. I have my own hit list as always, but I'm always looking for more projects! Now's a really good time to hit me up while it's on my mind. Don't forget, whether you're an indie developer or an independent developer, there's a good chance I can accommodate your needs!

Love, flibit
flibitijibibo.com

Bill's Hat

Turn a minimal Fedora installation into a SteamOS box!

1. Write Fedora Workstation NetInstall ISO to a USB drive
2. Boot USB image, install Minimal configuration with standard partition layout matching SteamOS'
3. Set root password, create a user called 'steam', set a password for it
4. Reboot, log in as root
5. A whole bunch of commands:

dnf group install hardware-support
dnf install Xorg xorg-x11-drv-evdev libglvnd-egl vulkan-loader.x86_64 vulkan-loader.i686 lightdm flatpak NetworkManager-wifi kernel-modules-extra bluez
dnf config-manager --add-repo=https://negativo17.org/repos/fedora-steam.repo
dnf install steam steamos-compositor steamos-modeswitch-inhibitor.x86_64 steamos-modeswitch-inhibitor.i686
setsebool -P allow_execheap 1
systemctl enable sshd.service
systemctl enable lightdm.service
systemctl set-default graphical.target

6. Edit /etc/lightdm/lightdm.conf:

pam-service=lightdm-autologin
pam-autologin-service=lightdm-autologin
user-session=steamos
autologin-user=steam
autologin-session=steamos

7. Create /var/lib/AccountsService/users/steam:

[User]
Session=steamos
XSession=steamos
Icon=/home/steam/.face
SystemAccount=false

8. Reboot, should work now!

9. Additional steps for NVIDIA users:

dnf config-manager --add-repo=https://negativo17.org/repos/fedora-nvidia.repo
dnf install kernel-devel dkms-nvidia nvidia-driver-libs.x86_64 nvidia-driver-libs.i686
reboot # Should be using the NVIDIA driver now!

Bill's Hat TODO

Wait, a "plan"?

Well, this is a .plan file, so here's my TODO. Expect nothing from it, ever.

In Progress
    Proton Performance Analysis
    Proteus 64-bit macOS
        - Only push on Catalina Day
    Waveform 64-bit
        - Repo access...!
    Blueberry 64-bit Checkbox
        - Steam access...

Waiting Room
    DK BONGO QUEST
        - Reinvestigate multi-joystick device support
    SDL_GetAudioDeviceSpec
        - Oh god I don't even know dude
    Codename FullCircle
        - Need some backend access first...
    Codename Swine
        - Waiting for content completion
    Codename CityVessel
        - Not even finished yet, whatever
    Codename SpinnyTokelau
        - Assessment coming up in September
    Codename FlyingFinger
        - A bunch of non-dev stuff happens first
    Codename BlackHole
        - Waiting on some hardware
    ScoreRush PC
        - Graphics, AppAdmin, strings for PC settings, blah blah blah
    Zeboyd Catalog
        - Possibly no source, really just need AppAdmin access tbh
    64-bit Panic
        - They Bleed Pixels middleware :/
        - Gotta rebuild all MojoSetup packages (F you Canonical)

When this .plan was written: 2019-10-01 05:49:26
.plan archives for this user are here (RSS here).
Powered by IcculusFinger v2.1.27
You could be playing Pringles for Genesis but instead you're here?