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/)AC
apt_install_coffee @ apt_install_coffee @lemmy.ml
Posts
0
Comments
131
Joined
3 yr. ago

  • hat's a bad faith interpretation of "the people control the means of production".

    I want you to consider the difference between the work needed to complete a task, and the work needed to manage a workplace: for one of those tasks, only the experts in that task can meaningfully contribute to the outcome, whereas for the other, everybody who is part of the workplace has meaningful input.

    I don't know about your experience, but everywhere I've worked there have been people "on the ground" who get to see the inefficiencies in the logistics of their day to day jobs; in a good job a manager will listen and implement changes, but why should the workers be beholden to this middleman who doesn't know how the job works?

    I've also had plenty of roles where management have been "telling me where to cut".

  • Sure, but that's not necessarily a bad thing; if the Linux version is missing useful output that would be bad, but if the DX to Vulkan translation ironed out a performance regression, or the scheduler works better in this scenario, or filesystem access had issues with NTFS it could also cause performance differences in Linux favour.

  • It opens the door to more manufacturers since there is no ISA licence fees. While the AMD/Intel duopoly is being fairly competitive at the moment, it really doesn't have to be. Only think back to how bad it was late 2000s to 2015.

    I imagine a plethora of core designers, soc vendors and platform creators filling their own niches; lowest cost, lowest power, HW accelerators, highest core count etc.

    I don't see the raw performance of AMD/Intel being surpassed soon, just because of the sheer total R&D years each has, but that doesn't mean there aren't other areas better suited to a different architectural approach.

  • I don't see the problem, I also don't see how this is a novel situation.

    The technical merits of system level protocols only really affect the user insofar as they make it easier for userspace application writers to make their software. This is why we have the distinction, so that users never have to change the underlying software, and when they choose to it's because everything just works.

  • Likely a combination of 4 things:

    1. They have third party firmware in their blobs that they are under NDA regarding the source code.
    2. They believe in the source code is a large part of their success and don't want to reveal it.
    3. They believe giving out the source code will allow many inferior variants of the software, impacting their brand.
    4. Control; the more source code they have in mesa the more of their code can be rejected by mesa. Keeping their stuff as blobs allows them to put in whatever hacks they want.
  • NT is not the majority of windows code though; for windows to be multi architecture, all of windows needs to work with the new architecture; NT, drivers & userspace.

    For Linux, if an existing userspace application doesn't work in aarch64, somebody somewhere will build a port. For windows, so much of their stuff is proprietary that Microsoft are the only ones able to build that port.

    Not because "windows bad", just a consequence of such a locked down system which doesn't have anything open source to inherit.

  • Memory safety is likely to prevent a lot of bugs. Not necessarily in the kernel proper, I honestly don't see it being used widely there for a while.

    In third party drivers is where I see the largest benefit; there are plenty of manufacturers who will build a shitty driver for their device, say that it targets Linux 4.19, and then never support/update it. I have seen quite a few third party drivers for my work and I am not impressed; security flaws, memory leaks, disabling of sensible warnings. Having future drivers written in rust would force these companies to build a working driver that didn't require months of trawling through to fix issues.

    Now that I think about it, in 10 years I'll probably be complaining about massive unsafe blocks everywhere...

  • Any government which makes caffeine illegal must be prepared to enforce that law with mass violence, or let it be ignored.

    Given how unlikely your average cop is going to enforce a law they regularly brea... Oh, nevermind. Yeah it'd be a shit show. Demonstrations, arrests, black markets, the whole nine yards.

  • Setting up the PiHole device as a DNS server & DHCP server still won't make all traffic flow through it, you need it to be a gateway for all traffic that isn't destined for an internal subnet.

    To do that, you'll need to set up your device as a router, with the necessary entries in iproute2 and iptables in order to keep lock out external connections without conntracks. You might be able to route to a turnkey container of some kind.

  • Are you trying to route your DNS queries through your VPN device or all of your traffic?

    Just your DNS queries is easy, set up the VPN as the default route for the device (using netplan or iproute2), then all queries from PiHole will go via that.

    All traffic is a bit harder, unless your PiHole device is the only thing between your regular devices and the internet.

  • They made a smart call that has probably increased the long term privacy of their users.

    People were using port forwarding to host illegal shit, and governments were getting pissed off about it. Mullvad has been able to prove in court that they don't keep logs, but that's not a perfect deterrent; a properly motivated government, perhaps if somebody is using Mullvad to host CSAM, might attempt to legally force Mullvad to put logging in and add anti-canary clauses.

    Preventing port forwarding keeps customers as consumers rather than hosters, and avoids this issue.

  • Not necessarily, plenty of good programs written in C89 for example.

    With something that is heavily library dependent, having a more recent development stack may mean better maintained libraries but definitely not a sure thing.

  • Do you just care about privacy, or is it your primary focus?

    There are Linux distros like Tails which will be very hard to use day to day, but if you are laser focused on privacy, it's between that and CubesOS (not Linux).

    Most Linux distros will give you reasonable privacy from an OS standpoint, from there it's up to you to have good practices with your data.