• 6 Posts
  • 111 Comments
Joined 1 year ago
cake
Cake day: January 5th, 2024

help-circle

  • A general checklist for flags that software will enshittify:

    • owned by publicly-traded company
    • backed by VC or other expecting sources of funding
    • product is closed-source
    • company tries to circumvent open-source licensing of product (often for financial gain)
    • product has transferred ownership to a different company (through monetary transaction or similar)
    • product incorporates DRM
    • organization that owns the product has a track record for bad behavior

    On their own, not all of these flags are excellent indicators. Some are better than others in a vacuum. If you see a product start to check several of these flags, it might be time to jump ship early (to a fork or other competing project).



  • It’s funny how EA is attributing their statistic to something can be strongly disproven. When looking at the given statistic they provided, they don’t specify the raw count of cheaters banned, but simply the rate. Even giving the generous assumption that EA’s statistics aren’t significantly flawed, they show an alleged large drop in cheaters bottoming out in the week of Nov. 4, 2024, before starting to rise up again. Does something else coincide with the rate of cheaters dropping in the week of Nov. 4? There is in fact something that does. Season 23 was released the fifth with a large spike of players being brought into the game. Without a more comprehensive statistic graph over several months, it looks like EA is trying to just capitalize on the fact that a large influx of players joining the game will drop the rates of cheaters momentarily, and then passing it off as evidence that Linux cheating was rampant. Quite disingenuous.


  • I’m not really sure I can support using DNT headers currently. Some good points were made about alongside GPC, DNT being legally recognized for GDPR requests in some countries. I live in the US outside of California, and don’t closely follow along to the nuances of either CCPA or GDPR, so correct me if I get something wrong. Given the list of websites in a comment that respect DNT, the notion that DNT is voluntary to handle, and how many websites use to harm users instead (further fingerprinting data points), I don’t see why Mozilla should be keeping around DNT for the time being.

    Yes, the fingerprinting metric for DNT may not be that unique of a data point if a given user isn’t using content blocking extensions and other browser-hardening techniques. It still is however a data point often masked to follow the herd in order to minimize fingerprinting in territories where user privacy isn’t enforced by law. If law actually demanded respect to user privacy, I think DNT could work. As it stands though, it really doesn’t seem like DNT is well-ingrained in law.

    Given the list of sites you listed, I only recognize two websites on the list that claim to support DNT. Perhaps a majority of these sites are from smaller organizations and/or based in the EU? On top, this is only what the sites’ privacy policies claim, no? How many of these sites are actively proven to respect DNT beyond claiming that they do?

    It really seems like DNT is still considered way too optional for websites to handle and respect. The best way for this to change is for the GDPR to recognize proper DNT handling as mandatory for sites to be compliant in the EU. Furthermore (unlikely to happen anytime soon but would be helpful) is for the US to gain similar privacy laws at the country-level that also defines enforcement.

    There is just about zero reason I think nicely asking website admins to monitor and add support for DNT. Given that a majority of the problem with violations isn’t with the smallest of independent websites, but those run by larger businesses, I doubt simple activism will work. If just activism for respecting the privacy of users actually did something, I feel like in ~15 years Do Not Track headers would have shown meaningful progress. The only way going forward is deliberate user-enforced destruction of available tracking points granted to websites or law that dictates when and how websites may track users: be it GPC, DNT, or something else. Only when a consensus is being reached should Mozilla and browsers prepare to support the enforced feature.

    EDIT: re-reading the list of websites claiming support for DNT, I found a second website I recognize.







  • I did accidentally type the relevant command incorrectly, forgetting that sudo swaps the user before subcommands like whoami will resolve. So that command attempted to add the kvm group to ‘root’ rather to your user. I have fixed the command in the relevant comment for anyone else reading this thread. You can try sudo adduser "<username>" kvm, manually substituting <username> for your username. As normal, restart after adding the group to your user. Additionally, I have added a warning to the solution in the original comment of why you may not want to keep this solution enabled forever as well as a way to disable it later if desired.


  • Based on using a local installation without elevated permissions (outside of /usr/(local)), I can only guess of two things happening:

    The first is GNOME Boxes asks for elevated permissions when running or otherwise uses Polkit to gain those permissions. Your user by default likely isn’t granted access to /dev/kvm and running userland software without additional permissions will inherently not allow KVM access.

    To allow this sanely, you can add your user to the KVM group to allow userland KVM access. It can be done via sudo adduser "<username>" kvm and then restarting your computer. To note, this is something that can allow any application to access virtualization without special permissions. If you don’t want this change to remain forever, the command sudo usermod -r -G kvm "<username>" followed by a restart can revert this change.

    Alternatively, installing Android Studio via the Flathub Flatpak may handle permissions without needing to modify user groups in this case.

    The second (unlikely, but possible) problem is the AppArmor profile blocking KVM access for userland. I don’t have particularly any experience with creating modified profiles for AppArmor, if this is the cause. I could only offer terrible advice for AppArmor (disabling AppArmor or switching to warn-only, both things I do not recommend doing). Again, it might be worth trying to install Android Studio via flatpak to see if things work better if this is the cause.


  • I am testing this currently to ensure correctness, but if you’re using Android Studio via Flatpak, you may need to enable kvm permissions for the application to have hardware-accelerated VMs. This can be done using Flatseal. The relevant permission (device=kvm) is under the Device section labeled as Virtualization.

    Additionally, if problems are occurring outside of Flatpak, you might need to enable certain hardware virtualization technologies from your computer’s BIOS (AMD-V, VT-x, VT-d, Intel VT, Virtualization, or some other similar term depending on CPU and motherboard).

    EDIT: Doing testing, it seems the default permissions provided for Android Studio’s Flathub Flatpak includes device=all. No permissions edits are necessary by default. If there are problems with the /dev/kvm device not being reachable, it is almost certainly due to the necessary extensions not being enabled in the BIOS, or your CPU doesn’t support virtualization. Pop! OS 22.04 has the necessary components in software for KVM to function pre-installed, so nothing should be wrong on the OS side.



  • From my experience with a modern Thinkpad (A485); nothing if not outright inferior. The trackpoints on them are pretty terrible compared to classic IBM-era thinkpads (10-20hz polling rate, abysmal velocity curve). The physical durability of the machine might be above-average for business laptops, but the chance of the hardware failing in some major way within warranty seems to be quite high (among other replacement parts, I had 4-5 mainboard replacements done under warranty). The cooling solution on the Thinkpad I used to use was also a fair bit inadequate, and would lead to severe thermal throttling of the mid-range APU. Honestly between the reliability and torturous process to even buy a new Thinkpad from Lenovo, I just wouldn’t bother.


  • jrgd@lemm.eetoLinux@lemmy.mldo we need a linuxquestions?
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 month ago

    On my mobile Lemmy client (Eternity), I already keep a multicommunity group for finding tech support posts in case I have something to offer in response. As it stands with !linux@lemmy.ml, there aren’t too many posts that are pure conjecture or information and thus doesn’t really clog my feed. If this community grows to have more of these kinds of posts showing up, it may be worth having a split. As it stands currently though, I feel it would mostly serve to significantly lessen what gets posted to this community.


  • What board/connector is affected? At worst, a replacement connector and a soldering iron should be able to replace the damaged connector and get your printer in a functional state.

    UPDATE: if you are referring to certain mainboard connectors, it may be best to replace the mainboard if you don’t have the tools for replacement. I see surface-mount connectors for some things on the mainboard that can be difficult to replace correctly without more unique tools.


  • jrgd@lemm.eetoLinux@lemmy.ml"Fedora Project Leader" position open
    link
    fedilink
    English
    arrow-up
    5
    ·
    edit-2
    1 month ago

    Systemd is both in a lot more large distros than just Fedora, RHEL and has limited viable alternatives (OpenRC as a partial replacement, no others I can think of that come close). While it has its issues particularly with the extra bundled services of mixed quality, SystemD is generally a flexible and suitable option for service management on Linux.

    Not to mention how inflammatory the parent comment is.



  • GrapheneOS only publishes updates for devices with active security updates. Your device is EOL and therefore won’t receive any further mainline updates. It still will receive extended support from the Android 14 legacy branch with whatever security patches arrive in upstream AOSP, but unlikely to see device-specific patches nor firmware patches. Your device isn’t getting the same care and attention that active devices are receiving nor will it receive any future versions of Android through GrapheneOS.