• 1 Post
  • 129 Comments
Joined 1 year ago
cake
Cake day: September 10th, 2023

help-circle
  • tinkers with pulseaudio
    “Why does my audio not work?”
    tinkers more
    “Okay I think it kinda works now?”
    it breaks again
    “fml”

    I found the docs for pulseaudio and particularly for pipewire to be rather hard to use, personally. RTFM works if the manual is readable, but in these cases, the learning curve was very steep for me (and I still don’t know that I properly understood what’s going on, but it’s working, so I’ve stopped tinkering for now).






  • I mean, the minimum you need is some authentication mechanism, a secure certificate, an authenticated endpoint to send a live data feed to, an endpoint to query a given live data feed from, maybe a website to serve the whole thing for people that don’t have their own tool for reading and playing back a live data feed…

    …and the infrastructure to distribute that data feed from ingest to content delivery. Easy.

    (Note: easy does not mean cheap. Even if a live data feed ingest and delivery was easy to implement (which I doubt it is), you’d skip buffering (to reduce memory demands) and only used a single server (to spare such stupid things as distributed networks, load balancing, redundancy or costs for scaling cloud solutions), you’d still have computational overhead of network operations and of course a massive data throughput.)




  • A lot of data throughput and buffer just for ingesting and distributing the live streams themselves, technical and business administration to keep things running, moderation to ensure compliance with content laws and data protection regulation, and then there’s still all the other fancy features major platforms offer if you want to compete for users.

    Multiple resolution options with server-side rescaling for users with slower connections? Graphics computing power.
    Store past broadcasts? Massive amounts of data storage capacity.
    Social features? Even more moderation.

    And we haven’t even touched on the monetary issue of “How do you pay for all that?” and all its attached complexity. You could be running the nicest platform in the world, but without any funding, it won’t run very long.






  • I do think that we should continue to encourage developers to create native builds when they can

    Yes

    My problem is calling people who want Linux native games misguided or wrong. I really don’t think that’s helpful.

    I’d prefer games to be compatible natively too, so I definitely count myself among them. I think it’s an issue of visibility, the usual “loud and visible minority”. A thousand calm “I would prefer games were natively compatible” just don’t stick out as much as one aggressive “Fuck every company that doesn’t make their games natively compatible, and fuck you for supporting them by buying their game”.

    I just don’t think Proton is the worst thing to happen to Linux Gaming because it allows developers to target alternative platforms without having to actually support them. This is where my personal impression of “misguided” (again, probably a loud minority) native game advocates comes from: Platform Inertia works because people stick with the platforms holding things they like, and the things on those platforms stay there because their prime audience is there. If the extra effort (=cost) of supporting Linux doesn’t match a sufficient uptake (=revenue), profit-controlled companies won’t do it (as they can’t justify it to their shareholders).

    This isn’t just an issue with the evil corpos, but with the whole system itself. Screaming at consumers to change their habits won’t make much of a dent either there. Compelling people to change rarely has lasting results, if any. Better to invite them over and make the switch attractive enough to break that inertia. Only then can we meaningfully challenge the status quo.

    It comes down to strategy accounting for ideological passion, an understanding of social and economic dynamics and patience. By and large, I think many understand this. Proton may not be what we want, but it’s an ally in achieving our goal. When we get to the point where it’s no longer “Underdog Linux against the near monopoly of Windows”, we can push harder (and honestly, I don’t think Valve would be terribly upset if Proton became obsolete and saved them resources).

    We shouldn’t stop asking for native builds, so long as we do it mindfully and respectfully.


  • I maintain that Proton could be a gateway to open the Linux market and create a sufficient share of revenue that, if and when it is shutdown, it’s lucrative enough to make natively compatible games.

    It’s a bit of a deadlock issue: Most Devs will only develop for Linux if they see there’s money to be made there and they can estimate it will be worth the effort. But we need games on Linux for that to happen.

    Proton is a stop-gap solution to provide the latter and lower the barrier on both ends: I can play games on Linux and devs have an easier time shipping their games to a Linux audience. I hope long term, the major frameworks will feature defaults that allow devs to easily do so without relying on Steam, but until then, Proton is better than nothing.



  • I’ve had to grapple with pipewire. My old pulseaudio config didn’t seem to work and I wanted to migrate to the pw config file format anyway, but I found the pw docs to be highly opaque. You get a thousand solutions for commands online, or tools you can do it visually in, but to apply that config you need to start the tool…

    I’m a noob, granted, but there seemed to be a lot of assumed common knowledge that I just don’t have. And if I don’t even know what I’m missing, it’s hard to google for it.