• 0 Posts
  • 18 Comments
Joined 3 years ago
cake
Cake day: June 17th, 2023

help-circle








  • KexPilot@lemmy.worldtolinuxmemes@lemmy.world•*Permanently Deleted*
    link
    fedilink
    arrow-up
    2
    arrow-down
    3
    ·
    2 months ago

    More than just “being an asshole”

    Yeah, might be true, their discord is a toxic cesspool. And yes, there was that case of the power tripping transphobic mod. But c’mon, “nazi”… If anything, it weakens the nazi tag of a literal nazi.

    Not sure if you are aware, but hyprland even has a code of conduct now (check on github) due to those events. It could be argued that it is a bit lax or not as enforced as we would want, but it is a step in the correct direction. Compare that to DHH who seems to be on a straight downward trend with no signs of stopping…



  • KexPilot@lemmy.worldtolinuxmemes@lemmy.world•*Permanently Deleted*
    link
    fedilink
    arrow-up
    15
    arrow-down
    7
    ·
    2 months ago

    I read through all the comments here, and at time of writing I kind of don’t like that Hyprland and Omarchy are both labelled as nazi software… It is mentioned in multiple comments that being an asshole developer is not the same as being a nazi, yet people still call Hyprland “nazi software”. Why? Vaxry is an asshole, but according to this nazi<->asshole categorisation, I don’t find it accurate that people here (with many likes on each such comment) rightfully call Omarchy nazi software and give examples why that is true, and then just casually attach Hyprland into the nazi category because… (???) the dev is an asshole?


  • I mean, you are right in this sense I guess. I see this topic from the POV of an arch user in the original sense: I installed the OS myself and made concious decisions about how I built up my OS, I by default read the wiki, I know why and how I do what in my system installation. From my POV it is obvious that there is no problem here. But maybe due to the rise of the user friendly arch-based OS-es (which is an oxymoron in my opinion) the current state of the OS should be reevaluated.

    In the end, my opinion still is that if you use tools like yay, you are probably not the target audience, and maybe got lured into using arch due to the memes or stigma. Maybe the entry barrier should be lifted in the sense that for example the AUR and archinstall are split off the project into their separate own thing. Weird situation IMO…


  • The arch wiki page for the AUR has a big, vibrant red box in the intro section stating:

    Warning AUR packages are user-produced content. These PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk.

    If you have ever installed something through the AUR in the intended way, you would know that it does not involve running the package manager tool until the very last step. You need to git checkout the package recipe, build it. This is clearly what the post you are answering to meant by “not part of the arch linux repositories”.




  • It might be not this simple in case of notification providers, the notifications are somehow sent in the name of the app I guess. And don’t forget: in general, this principle is true for most of your apps that send notifications. I.e. if you are getting Signal or Facebook notifications, it uses the same principle.

    Btw, google is not the only notification service for android. Check up on Unified Push, there are many alternatives to do this, and there are some apps that support these alternatives in their non-play-store builds.


  • In general, notifications on Android don’t go through apps, that would require apps to run all the time and consume too much battery. They instead are going through a notification provider (google in the default case). This is why your notifications arrive, but you have no other connections to your HA.

    Edit for clarification: HA uploads it to google servers (which of course doesn’t need port forwarding) and your phone then polls them from google.


  • No. The issue is that an assumption they make in the unsafe block does not actually always hold true. They changed the safe rust code to strenghten the (incorrect) assumption they made in the first place, because that is way easier than rearchitecting the unsafe part. I.e. if the unsafe part was somehow to be written safely, the mitigation they introduced now would not result in any difference in behaviour, it would be correct behaviour both before and after.

    Tldr: the problem lies in the unsafe part