Yeah, I’ve been beta testing the Streamyfin tvOS app. it’s now about on par with the official tvOS client, but feels like it’s making more progress regularly
I switched to Debian a long time ago for both desktops and servers. For me personally I don’t see what value prop Ubuntu even has anymore, apart from maybe having ZFS in the kernel. Support maybe? I’ve never used it personally so I don’t know if it’s any good, but for any serious shop willing to spend money on support I’d probably go with RHEL anyway.
> NOTE: Use a VPN on these pages if you don't want your IP shown in the logs, but it won't be significant amongst the millions of others anyways
Is this supposed to be a joke? Is the author expecting users to travel back in time and use a VPN so their IP is scrubbed from logs that will get published at any time, because that's something the author just obviously has the right to do?
> The EDPB explicitly identifies IP addresses as being personal data due to their ability to identify individual data subjects.[1]
This is a nice idea, but how do you follow through in practice? Who decides what counts as an "upstream dependency", where do you draw the line? Is the Linux kernel included? Are desktop environments included? How do you decide how much of the pot goes to each project, does curl get an equal amount to Wine? Why/why not?
As I said, it's a nice idea but I have a feeling the complexity behind making this work well is what might have kept them from doing it.
So the steam devs can most likely produce a finite list of all their dependencies. They can then take a day or two to score each one with a weight. Then they use the weights to determine how to split the funds. Or they can have an open source champion person internally that takes care of relationships with opensource projects and can release funds to them as needed. Point is, lets say they accumulate $1M/year this way, it is that person's responsibility to distribute it fully back out to the community. Obviously try to keep it super simple & transparent. They can even ask game developers each quarter who they should think need money or which problems were solved well for them this round, as an extra layer of input.
This extends past linux. Open source projects get used broadly regardless of runtime environment. Steam is just one open nerve ending where this could be used for good and they have the power to do so (and from what we've seen, steam seems to be a low friction company, less corpo red tape - would you trust say Ubisoft with handling this or steam?). If a game gets deployed to windows, it doesn't matter, as each game/application probably use five or ten or more open source projects regardless of where they run. It can help open source devs keep pacing with steam and game developer needs. Remember a ton of these project have upstream effects outside of gaming - its just the most obvious open nerve we can use to help open source.
You can only show the checkbox on Linux. You can add OS detection to the checkbox and have it say "support our $OS dependencies" and put that into different pots of money. You can make the checkbox say "support our Linux dependencies" and then rely on Windows people not selecting it.
There are about 60k ports you can choose from for each IP, so I don’t understand why you can’t just give one user 1.2.3.4:1001 and the other 1.2.3.4:1002 and route that.
Setting it up like this where you just assume:
> The public key tells us the user, and the {user, IP} tuple uniquely identifies the VM they are connecting to.
Seems like begging for future architectural problems.
Most Linux distros are not Arch either. It would be nice to have more support for this use case in general - like something one can configure easily during the initial OS setup.
I use OpenSuse so I had to use the guide for Fedora, but there were some differences as far as I remember.
”Fedora, RHEL, CentOS, Rocky, Alma” are all the same distro group: Enterprise Linux (EL). That it's ”available” on other distros is irrelevant, almost anything is ”available” as a non standard choice for any distro.
It's not only more complicated, it also does not sound to me like it would scale. What do you do when you have N servers? Do you buy N raspis, or do you keep using one bastion host? How do you automate it when you sooner or later must (re-)deploy?
If you set this up once ("this" meaning adding networking, SSH and tailscale inside initramfs), you can just do the same thing for the next server you set up, and you don't have to worry about the failure of one node affecting the other(s).
The approach I've outlined scales fine to N servers, it just doesn't work if they're on different networks.
But scaling also isn't really a parameter I (or the author) are optimizing for: we have a single beefy server we do all our work on, and a thin laptop client we want to access the server from, remotely and booting an encrypted root partition.
I don't necessarily understand the deployment question. If it's about the Raspberry Pi, I just do my updates when I don't need to use it to boot the server.
I'm not from the US and I'm not bipartisan; in fact, I find the bipartisan US to be extremely backwards, illogical, and detrimental to the whole nation.
reply