Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)L
Posts
12
Comments
1501
Joined
3 yr. ago

  • But you only have two kidneys, how will you buy a third Mac?

    Macs are outrageously priced for the hardware you get.

    Non-Apple laptops can be just as reliable and last just as long nowadays, and you get to upgrade them at a fraction of the cost. Actually I should say you get to upgrade them, period.

  • It's not that the ad issue isn't going to be solved, it's that ads are here now and we have to deal with them.

    They are going to be replaced by direct micro-payments eventually but the puzzle pieces have been slow to get into place (also Google and the whole ad industry haven't been cooperating for obvious reasons).

    One of the major hurdles was the [in]ability to make online payments of a fraction of a cent but the digital Euro aims to make that possible (among other things).

    With that and support for direct micropayments implemented in the browser we'll be able to give a web page owner that fraction of a cent they get from ads now but only IF we want to, and when we do that we cut out all the ad industry as middlemen.

  • Everybody should be using DNS over HTTPS (DoH) or over TLS (DoT) nowadays. Clear DNS is way too easy to subvert and even when it's not being tampered with most ISP snoop on it to compile statistics about what their customers visit.

    DoH and DoT aren't a full-proof solution though. HTTPS connections still leak domain names when the target server doesn't use Encrypted Hello (ECH) and you need to be using DoH for ECH to work.

    Even if all that is in place, a determined ISP, workplace or state actor can identify DoH/DoT servers and compile block lists, perform deep packet inspection to detect such connections regardless of server, or set up their own honey trap servers.

    There's also the negative side of DoH/DoT, when appliances and IoT devices on your network use it to bypass your control over your LAN.

  • As opposed to what, the domain certificate? Which can't be air-gapped because it needs to be used by services and reverse proxies.

  • If you mean properly signed certificates (as opposed to self-signed) you'll need a domain name, and you'll need your LAN DNS server to resolve a made-up subdomain like lan.domain.com. With that you can get a wildcard Let's Encrypt certificate for *.lan.domain.com and all your https://whatever.lan.domain.com URLs will work normally in any browser (for as long as you're on the LAN).

  • Ubuntu and Kubuntu are nice distros, the problem with Ubuntu is that Canonical makes snaps mandatory. But on Kubuntu you can make them optional.

  • Kubuntu comes with snap support but you can uninstall it and the default snaps, mark the snapd package as forbidden and that's pretty much it.

  • What project?

  • I did Linux From Scratch once. I got it to the point it was booting a kennel that supported everything I needed, had a working init (sysv), a helper script that "installed" packages (symlinked stuff to integrate them into the system) and kept "recipes" for whatever I compiled.

    If I had kept going and compiled everything I needed and kept maintaining that I'm guessing it would have been pretty close to the Slackware experience, right?

    It was very cool to know I can do all that and I learned a lot but if I had kept going I feel like it would have become limiting rather than empowering.

    Like, it's cool to go camping and catch your food, and cook it, and sleep outdoors and to know you can survive in the wild, but I wouldn't want to have to do that every day.

  • I refuse to trust a car I can't fix myself

    Isn't that basically all cars nowadays? It's not about the type of engine, cars have gone "no serviceable parts inside" for at least a decade.

  • The problem with making the core immutable is that you have to decide where you draw the line between immutable and regular packages.

    It sounds nice to be able to always have an immutable blob with some built-in functionality that you can fall back to, but the question is how far do you want to take that blob?

    Things that go into the immutable blob don't offer much (if any) choice to the user. I can see it being used for something like the kernel and basic drivers, coreutils, basic networking. It starts getting blurry when you get to things like systemd and over-reaching when it gets to desktop functionality.

    Also, you say it's more reliable but you can get bugs in anything. Version x.y.z of the kernel can have bugs whether it's distributed as part of an immutable core or as a package.

    I definitely think distributing software as immutable bulk layers can be useful for certain device classes such as embedded, mobile, gaming etc. The Steam Deck for example and other devices where the vendor can predefine the partition table and just image it with a single binary blob.

    On the desktop however I struggle to see what problems immutable solves that are not already solved some other way. Desktop machines require some degree of flexibility.

  • I wish they'd add reader mode to Firefox Focus too.

  • It's using work done for the Arkdep tookkit by Arkane Linux. The immutable image is based on btrfs.

  • Immutable was adopted for Android because Google and the Android vendors wanted to lock down the platform, and because they always distribute their OS images and updates as binary blobs.

    It offers no benefits to an open ecosystem like Linux, that you can't already accomplish with existing security measures.

    It offers some benefits to distro maintainers who are only willing/able to focus on the core system and delegate the rest of the software to distro-agnostic packages. That's definitely an interesting niche and I look forward to it. But please note that whether the core is immutable is completely irrelevant in this scenario.

    Generally speaking, if you want to use distro-agnostic packages you can do that regardless of whether the system is immutable or not.

    And since we're on the topic, if we're borrowing things from Android I would love to have the application sandboxing and permissions. I think they'd be a much bigger benefit – to all distros, immutable or not.

  • But an immutable distro is not necessarily declarative, and the other way around.

    Why lump them together?

  • Copyright licensing allows the owner to control how a work is distributed, not how it's consumed.

    First of all, that's incorrect.

    Secondly, by default you have zero rights to someone else's work. If something doesn't explicitly grant you rights, you have none. If there's a law or license, and if it's applicable to you, you get exactly what's specified in there.

    The "personal use" or "fair use" exceptions in some places grant some basic rights but they are very narrow in scope and generally applicable only to individuals.

  • Just because something is available for public viewing does not mean it's licensed for anything except personal use.

    The strawman here is that since physical people benefit from personal use exceptions in the law, machine learning software should too. But why should they? Since when is a piece of software ran by a corporation equivalent to an individual person?

  • No, see, because it's "learning like a human", and everybody knows that you're allowed to bypass any licensing for learning. /s

    But seriously I don't know how they make the jump to these conclusions either.

  • If it works intermittently like that it's probably just crap code, and it will be crap in any browser.