Check out our Monthly Survey Page to see what our users are running.
Latest Comments by Kithop
Discord Overlay for Linux adds PulseAudio / PipeWire integration
8 April 2024 at 6:39 pm UTC Likes: 1

Quoting: nenoroI'm waiting for OBS to be compatible with pipewire then i can get rid of pulseaudio

It... Already is? Or at least, you may need the Pipewire Pulseaudio compatible module and maybe the appropriate xdg-portal package(s) but OBS works great with Pipewire now.

Discord Overlay for Linux adds PulseAudio / PipeWire integration
8 April 2024 at 3:10 pm UTC

Oh, nevermind - they're actually actively antagonistic towards self-hosting, even if 'technically' supported.

I *could* set up my own private instance for friends, but without a federation protocol this feels kind of half-baked, unfortunately. FLOSS alternatives are great, but I don't trust anyone that wants to lump all users onto some big centralized cloud infrastructure. We have enough problems with that in the Fediverse with big instances like mastodon.social.

Discord Overlay for Linux adds PulseAudio / PipeWire integration
8 April 2024 at 3:05 pm UTC

Quoting: iod
Quoting: KithopStill wish there was a viable, self-hostable, FLOSS alternative that covered enough of Discord's feature set to convince people to switch.
Have you tried Revolt chat? I believe they focus on Discord features

I wasn't aware they had a self-host option, even if it's a bit buried off their main page. (https://github.com/revoltchat/self-hosted )

Definitely interesting and I'll be happy to look closer, but am I just dumb and not able to find a basic 'features' page? Like, I can tell from their front page it has text chat, and mayyyybe voice is implied?

Discord Overlay for Linux adds PulseAudio / PipeWire integration
8 April 2024 at 1:29 pm UTC Likes: 2

Still wish there was a viable, self-hostable, FLOSS alternative that covered enough of Discord's feature set to convince people to switch.

Mumble has great audio, but a very dated UX and nowhere near the rich text chat support, nor game streaming.

Element / Matrix seems promising, but they're wholly uninterested in being that competitor, considering how long people have been asking for simple drop in/out persistent voice channels (literally 4+ years I think, last I checked, which was admittedly a year+ ago at this point) where you can see who's already in or not at a glance, and the company behind it focuses on chasing contracts with police forces instead .

IRC of course strips it all back to text chat.

Everyone else seems to be chasing Slack and business use cases primarily.

Yeah, I can spin up my Owncast instance, hook OBS up to it, give my friends a link and then try to juggle both the VoIP call and the persistent rich text chat with other apps. While I'm fine going that route, there's intense friction getting the average Windows gamer to participate and leave the Discord bubble.

Dangeresque: The Roomisode Triungulate now available for Linux
15 March 2024 at 4:43 pm UTC Likes: 2

Did the quadratic formula explode? I see a "Strong Ba..." in there, but it's getting eaten by some... Linux or something.

( https://youtu.be/Az49aNuYeJs )

Game over for Roblox on Linux / Steam Deck as it's now blocked
1 March 2024 at 2:26 pm UTC Likes: 14

Simple solution to any of these that I (mostly) try to stick to:

Don't buy/play or support multiplayer games that don't support you hosting your own dedicated server, on hardware you control (none of this forced 'rent a server from our partners' BS either), using configs and settings you control, including the ability to opt out of and disable whatever anti-cheat they support.

Something like Minecraft Java? Amazing - totally the kind of thing an interested person can set up a private server for, mod and customize to your heart's content, invite friends and family onto and be able to admin (cheat) to fix when little Timmy's house gets blown up for the 5th time.

Any kind of 'live service' game? Not so much.

Now even I admit this can't be a 100% hard and fast rule - this means no MMOs, nothing ranked or hyper competitive, and not even the likes of casual things like VRChat (which *has* anti-cheat that works on Proton and they explicitly court Steam Deck support on, but that could change at any moment!), so you can be flexible if you so choose, but this is a general concept I try to stick to.

Kind of how hearing a cool game everyone talks about is some console exclusive, for a console I don't have nor have any other use for? That's nice, but I'll pass...

OpenAI say it would be 'impossible' to train AI without pinching copyrighted works
9 January 2024 at 11:18 pm UTC Likes: 3

Quoting: scaineI'd love to know where the money is being made with this shit.

Venture capitalists pouring money into it in the hopes that there'll be a bump in all this 'interest' in LLMs, so they can dump it when it peaks. It's just another dot-com bubble, or 2008 bubble all over again.

I wouldn't be surprised to learn all these AI companies are just burning cash in the hopes that they're the ones 'on top' when it all comes crashing down. As to how to 'monetize' it and actually make money off of all that wasted electricity and questionable results? That's the next guy's problem.

Cross-distribution support improvements coming for Canonical's Snap packages
9 January 2024 at 10:32 pm UTC Likes: 3

Quoting: mattaraxiaYou have a need to snadbox *everything* already. I'm blown away this mindset exists.

Ah yes, I'm going to sandbox 'ls' from the filesystem, and then explicitly fiddle to punch holes in to make it useful again...

Facetious and hyperbolic, yes, but let's not get into absolutes here. Sandboxing is great when you want it, but it's most definitely not for *everything*. There is a time and place for it, and I believe there are distros that lean on it extensively. It's great tech, but also *incredibly frustrating* as a user if you're not expecting it. All the Wayland xdg-desktop-portal stuff comes to mind - I love Wayland, but it shouldn't take *three separate popups* to allow OBS or Discord to screenshare a particular app, with no option to 'remember my choice forever please'. We're going to end up with Windows UAC level annoyances again, and then people will just turn it off entirely.

Should apps like Steam be sandboxed from accessing anything outside of ~/.steam (or equivalent)? Sure. Should your browser be sandboxed to not access things outside of your Downloads folder? Sounds like a good starting point. But remember, you may want to preview that PDF from your Documents or a thumb drive, or a static HTML page you're working on off a network drive, so it's got to be easy to do so and yes, explain and understand the implications.

If you want to run a Flatpak or Snap, you should understand that yes, you get sandboxing and the double edge that goes with it in terms of 'why can't this app see my files'. Unless your distro is explicitly designed for it, though, I believe it should not replace your native package manager. If I want to switch, let me make the choice to switch, don't start forcing Snaps on me when I call apt and expect a .deb.

Cross-distribution support improvements coming for Canonical's Snap packages
9 January 2024 at 7:01 pm UTC Likes: 1

Quoting: damarrinSnaps/flatpaks are there to make packaging and distribution easy for software creators and make them independent of distro maintainers who may or may not include a given piece of software, or may be including an ancient version of it.

Totally agree - that is 100% a valid use case for this, and a better way of putting what I was trying to get at: if your distro *does* ship an up to date version, you should use that as your first choice, since it may need to have been customized for said distro, it'll be kept up to date with shared libraries, etc., but if it *doesn't* (and you don't want to go down the rabbit hole of compiling it yourself... I've written my own janky PKGBUILDs for that, in fact, and it's not user-friendly), these are a great fallback.

My issue primarily is that Canonical likes to push the snap version of a package as the first choice, regardless if there's a perfectly valid .deb available, and I think that's wrong, because that pulls Ubuntu even further away from upstream Debian and introduces yet another unique distro-ism when trying to troubleshoot. The cynical part of me worries that 'pulling away from upstream Debian' is their big goal.

That said, it's been a few years since I ran Ubuntu on a desktop - does an 'apt install firefox' still pull in the snap by default? If they've walked that back since, then my argument is invalid and out of date.

Cross-distribution support improvements coming for Canonical's Snap packages
9 January 2024 at 3:08 pm UTC

Yeah, I don't mind stuff like Flatpaks for devices like the Steam Deck, where you don't normally get write access to the entire filesystem, but on desktop?

Unless you have a need to sandbox something, just use your distro's packages - they will be compiled with the recommended versions of libraries for the whole ecosystem, instead of storing multiple, slightly different (and potentially way out of date!) versions depending on what you're installing.

Security vulnerability in a shared library? Update it through your distro and you're reasonably well covered across everything on your system. Flatpaks and Snaps? Time to download updates to every single sandboxed app... if they updated at the exact same cadence, if they bother to update it at all. (Yes, it shouldn't mean a *ton* of wasted space as they link and share the same library copy once you've downloaded it once, AFAIK) Almost as bad as all the 'native' apps just using downright ancient, vulnerable versions of Electron for way longer than they should. (*cough* Discord)

It's cool tech, but it should remain specialised, and *definitely* not the first thing you reach for for regular day to day usage, IMO. Heck, snapd was always pretty much the first thing I purged (the Firefox snap was way, *way* underperformant compared to the regular .deb at the time) when I used Ububtu, until I switched distros entirely. You don't *need* to keep five different versions of a library to cover two dozen Flatpaks or Snaps on disk in almost all normal use cases, unless the library update is an API/ABI breaking one.

All that said, one of the biggest criticisms I've seen of Canonical's behaviour is that it feels like vendor lock in, so if it's being opened up to other distros (and it's easy for communities to host their own Snap repos *not* on Canonical's servers), then it's still interesting tech to watch and potentially keep in your back pocket for those situations where it makes sense, so good on them for at least trying, now.