• 8 Posts
  • 728 Comments
Joined 3 years ago
cake
Cake day: June 15th, 2023

help-circle
  • if someone went to a phone store with a stock graphene on display and anything else next to it, which one do you think they’ll choose?

    People consider the phone features too. For example Huawei has built a really solid following due to their phones’ quality and that following didn’t go away when Google started sabotaging their phones. Eventually banking apps started releasing versions for Huawei AppGallery (the Huawei Android app store).

    So the Google monopoly can be bent if there’s sufficient demand.







  • Some extra options you might want to consider:

    • Having the device act like a DLNA renderer. You still need it to run a graphical stack and a DLNA app, but you can control it with a DLNA controller app on your phone, and tell it to fetch content from your Jellyfin server if you activate the DLNA plugin so it will act like a DLNA server. DLNA needs network broadcast so it will work if the stick/phone/server all all on local LAN but typically can’t cross VLANs.
    • Having the device run a Tailscale client alongside Kodi or connecting to Jellyfin with a browser or client. If you also put Tailscale on the server you will be able to securely connect to it even on vacations (hotel TV for example).

  • This isn’t the first type of problem that the AUR has had. A few years ago it had problems staying up, because it had no scalability to speak of.

    “Best hopes and wishes” is not an accepted engineering design strategy. If something can be abused, it will be. Not planning for it is just that, poor planning.

    The AUR has been poorly put together and this wave of malware is just another symptom of a deeper problem.




  • But it was my fault, for generating an initramfs without free space in /tmp, which caused it to fail.

    I really don’t think that was your fault. A critical build process that’s not checking for resources and not failing gracefully and leaving the machine unbootable is not the user’s fault.

    A build+install can fail for many reasons. It’s actually annoying how many critical system updates on Linux don’t use a staging process and a sudden power-off at the wrong time can leave the machine completely crippled.

    Some distros have taken to doing a BTRFS snapshot before they start the upgrade but (a) they’re far and few in between and (b) that still doesn’t fix the upgrade process, it’s just sweeping the problem under the carpet.


  • It’s not slower.

    proprietary

    Only the extension pack, the app itself is GPL.

    not even as easy to install

    How do you mean? You simply install virtualbox (and virtual-guest-iso if you want). All the relevant packages are available from official repos, at least on Manjaro, including a linux-virtualbox-host-modules-meta package that maintains the required linux*-virtualbox-host-modules as needed automatically.

    Also, I prefer virtualbox because it makes a lot of stuff easy to do.

    File sharing with the host for example, it’s a matter of simply pointing at a dir in settings, as opposed to having to set up Samba on the host (which I don’t have and don’t want) and deal with wierd networking issues, or deal with virtiofs.

    Don’t even get me started on selecting locations for the vm files. Whatever you think it should work like, virt-manager’s way ain’t it.


  • Manjaro has also shown how an Arch distro can achieve this as well, by releasing tested sets of updates slower.

    But OP is correct in that’s not the point of vanilla Arch and people who use vanilla should assume the risks.

    What’s annoying is people who use vanilla and tell everybody “oh don’t worry nothing ever breaks”. Something always breaks. You have a couple thousand packages installed on the average desktop system, dozens are updated to bleeding edge every day, something will break.

    Manjaro maintains a crowd-sourced list of the most egregious defects (+ their fixes) that crop up in popular packages, suffice to say it’s never empty.

    Many of them are not system-breaking and may not impact everyone, which is where I’m guessing the “nothing ever breaks” dissonance is coming from.








  • lemmyvore@feddit.nltoSelfhosted@lemmy.worldAnybody here does mTLS?
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    11 days ago

    I recommend taking a look at the new Tailscale access controls > policies (aka “grants”). Much easier to understand than their old ACLs. You can quickly draw up rules that only let specific devices access specific nodes and even only specific ports.

    There’s one small potential point of confusion, in that you can’t use node names directly in the rules. You have to go to access controls > definitions > hosts and make up a name there assigned to the node IP address, and then you can use that name in a policy.

    In other words, even if you already have a tailnode called “nas” with a fixed IP, you can’t just say “nas” in a policy. You have to go to hosts, define one called “nas” that points to that tailnode’s IP, and then you can use “nas” in the policy… 🤪

    I understand the logic, which is that hosts and definitions in general are much more powerful and can define IP netmasks and IP groups and then you can use those groups in policies… but boy, the redundancy when you have to do this for single nodes that are already assigned a name and an IP is rubbing me wrong.