• 1 Post
  • 233 Comments
Joined 1 year ago
cake
Cake day: July 1st, 2023

help-circle


  • “While we are making this change to ensure users’ expectations regarding a community’s access do not suddenly change, protest is allowed on Reddit,” writes Nestler. “We want to hear from you when you think Reddit is making decisions that are not in your communities’ best interests. But if a protest crosses the line into harming redditors and Reddit, we’ll step in.”

    Yall have very clearly demonstrated that you do not care about the communities best interest, and you have no interest in hearing what we think. Fuck Spez and good riddance to reddit




  • That’s alright, I’ll do my best to walk you through it.

    Your drive contains multiple partitions (/dev/sda1 through /dev/sda3).
    One of these drives is going to be your EFI partition. This is what your system can read before linux boots, your BIOS can’t understand ext4 / btrfs / etc, but it can understand fat32.
    If you run lsblk -no FSTYPE /dev/sda1 it should return vfat if that’s your EFI partition. That’s what we’re going to mount to /mnt/boot/efi

    I’m assuming that /dev/sda3 is your data partition, e.g. where your linux install is. You can find the filesystem format the same way as your EFI partition. Edit: After determining which partition is which, you’re going to want to mount the root partition, and then the EFI partition
    mount /dev/sda3 /mnt
    mount /dev/sda1 /mnt/boot/efi

    Unix systems have theology of “everything is a file”, all devices and system interfaces are mounted as files. As such, to be able to properly chroot into an offline install, we need to make binds from our running system to the offline system. That’s what’s achieved by running for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
    This is just a simple loop that mounts /dev, /dev/pts, /proc, /sys, and /run to your offline install. You’re going to want to either add /sys/firmware/efi/efivars to that list, or mount it (with -B, which is shorthand for --bind, not a normal mount).

    Once you’ve done this, you should be able to successfully chroot into /mnt (or /mnt/root if running btrfs)
    At this point, you should be able to run your grub repair commands.


  • I’m doing my morning scroll before I start my day, so I can’t delve too deep, but this is the article I always reference when I have to do repairs

    https://askubuntu.com/a/831241

    #1 thing I noticed in your image is that lsblk only shows you partitions, and doesn’t mount them. You probably want /dev/sda3 mounted at /mnt

    The only thing from the article you want to modify is using mount -B /sys/firmware/efi/efivars /mnt/sys/efi/efivars, I believe the functionality changed since that article was written and that’s what worked for me

    Additionally, if you drive is formatted as btrfs instead of ext4, once you mount your drive your root will most likely be at /mnt/admin or similar. Mount subdirectories to that folder instead of /mnt

    If you have questions lmk and I’ll get back to you at some point today










  • Linus never said he hates unions, he said he’d feel that he failed as the owner if his employees felt so underrepresented that they needed a union.

    He has historically expressed support of unions in other companies and hasn’t been against one in his own, he just doesn’t want his company to need one.

    In regards to the misconduct…
    Announcement on the WAN show of the 3rd party results
    Post that matches the one on Twitter

    And the actual contents of the post:

    There were a series of accusations about our company last August from a former employee. Immediately following these accusations, LMG hired Roper Greyell - a large Vancouver-based law firm specializing in labor and employment law, to conduct a third-party investigation. Their website describes them as “one of the largest employment and labour law firms in Western Canada.” They work with both private and public sector employers.

    To ensure a fair investigation, LMG did not comment or publicly release any data and asked our team members to do the same. Now that the investigation is complete, we’re able to provide a summary of the findings.

    The investigation found that:

    • Claims of bullying and harassment were not substantiated.

    • Allegations that sexual harassment were ignored or not addressed were false.

    • Any concerns that were raised were investigated. Furthermore, from reviewing our history, the investigator is confident that if any other concerns had been raised, we would have investigated them.

    • There was no evidence of “abuse of power” or retaliation. The individual involved may not have agreed with our decisions or performance feedback, but our actions were for legitimate work-related purposes, and our business reasons were valid.

    • Allegations of process errors and miscommunication while onboarding this individual were partially substantiated, but the investigator found ample documentary evidence of LMG working to rectify the errors and the individual being treated generously and respectfully. When they had questions, they were responded to and addressed.

    In summary, as confirmed by the investigation, the allegations made against the team were largely unfounded, misleading, and unfair.

    With all of that said, in the spirit of ongoing improvement, the investigator shared their general recommendation that fast-growing workplaces should invest in continuing professional development. The investigator encouraged us to provide further training to our team about how to raise concerns to reinforce our existing workplace policies.

    Prior to receiving this report, LMG solicited anonymous feedback from the team in an effort to ensure there was no unreported bullying and harassment and hosted a training session which reiterated our workplace policies and reinforced our reporting structure. LMG will continue to assess ongoing continuing education for our team.

    At this time, we feel our case for a defamation suit would be very strong; however, our deepest wish is to simply put all of this behind us. We hope that will be the case, given the investigator’s clear findings that the allegations made online were misrepresentations of what actually occurred. We will continue to assess if there is persistent reputational damage or further defamation.

    This doesn’t mean our company is perfect and our journey is over. We are continuously learning and trying to do better. Thank you all for being part of our community.





  • Nate@programming.devtoLinux@lemmy.mlLinux and being speedy
    link
    fedilink
    English
    arrow-up
    7
    ·
    3 months ago

    This is just a theory, I don’t have knowledge of the inner-workings of either Linux or Windows (beyond the basics). While Microsoft has been packing tons of telemetry in their OS since Windows 10, I think they fucked up the I/O stack somewhere along the way. Windows used to run well enough on HDDs, but can barely boot now.

    This is most easily highlighted by using a disk drive. I was trying to read a DVD a while ago and noticed my whole system was locked up on a very modern system. Just having the drive plugged in would prevent windows from opening anything if already on, or getting past the spinner on boot.

    The same wasn’t observed on Linux. It took a bit to mount the DVD, but at no point did it lock up my system until it was removed. I used to use CDs and DVDs all the time on XP and 7 without this happening, so I only can suspect that they messed up something with I/O and has gone unnoticed because of their willingness to ignore the issues with the belief they’re being caused by telemetry