d3Xt3r

@d3Xt3r@lemmy.nz

This profile is from a federated server and may be incomplete. Browse more on the original instance.

ULPT: If you get paid annual leave and you're definitely going to quit your job soon, ask for a large pay rise first. When you quit, your accumulated annual leave will be paid out at the higher rate

I had 6 weeks of annual leave saved up. Im changing to a job that pays significantly more than my current salary. When my boss asked me what it would take to stay, I asked for a salary increase of 35% which he begrudingly gave me. Then I quit. This equated to an entitlement payout of about $10,700 instead of $8000 on my previous...

d3Xt3r,

This is pretty much what I did, although it was coincidental. Felt bad for my boss because he fought pretty hard to get a meaty pay rise for me, and then a month later I quit.

d3Xt3r, (edited )

Foreground targets are where writes initially go. Data is moved from foreground to background targets while idle or as needed. Data which is read from the background targets is moved to promote targets.

If you set your NVMe as a promote target, SSD as foreground and your HDDs as background targets, all writes would first go to your SSD, then get copied to your HDD during idle, and finally the copy of the data on your SSD will then be marked as a cached copy. In case your SSD becomes full, then it’ll store the data on other drives. As for the promote targets, any time you read data from either the SSD or HDD that wasn’t on the NVMe, it would get cached to it, so the next read will be faster.

The main point of the foreground vs promote is to prioritize write vs read speeds. If you value faster writes, then set your NVMe as foreground. If you value faster reads, then set your NVMe as promote. Of course, you can also set your NVMe as both foreground and promote to benefit from both faster reads and writes.

But since you plan to introduce an SSD in the mix, you can create a single group for your NVMe + SSD, and a second group for the HDDs, and set your SSD group to foreground + promote, which will simplify things.

The Arch wiki illustrates this well:

A recommended configuration is to use an ssd group for the foreground and promote, and an hdd group for the background (a writeback cache).

Modified example to your scenario:


<span style="color:#323232;"># bcachefs format 
</span><span style="color:#323232;">    --label=ssd.nvme1 /dev/nvme0n1 
</span><span style="color:#323232;">    --label=ssd.ssd1 /dev/sda 
</span><span style="color:#323232;">    --label=hdd.hdd1 /dev/sdb 
</span><span style="color:#323232;">    --label=hdd.hdd2 /dev/sdc 
</span><span style="color:#323232;">    --replicas=2 
</span><span style="color:#323232;">    --foreground_target=ssd 
</span><span style="color:#323232;">    --promote_target=ssd 
</span><span style="color:#323232;">    --background_target=hdd 
</span>

If you’re concerned about chucking both the SSD and NVMe in the same group, no need to worry cause bcachefs will automatically prioritize reads from drives with lower latency as mentioned in the wiki.

If they are different speeds, reads for replicated data will be sent to the ones with the lowest IO latency.

But regardless of which setup you go for, main thing to remember is to use the NVMe (or the group containing the NVMe) as the promote target, as that will be your primary cache drive.

d3Xt3r, (edited )

As others have mentioned, the sequential speeds in RAID 0/5 won’t really help you in gaming. What you might see at best is faster loading times, but that’s really about it.

One option which no one else has mentioned is using setting up tiered storage using bcachefs - where your SSD acts like a cache drive, which would contain frequently read aka “hot” data, and the rest of the data would be on your spinning disks. This way, you’d be making the most of your limited SSD space, whilst still taking advantage of the large storage provided by the spinning disks.

The advantage of bcachefs is that all your drives can be part of the same pool and it’ll all be transparent to your OS/programs, and all your data is striped like a RAID 10 array, so you can replace your drives in the future without any issues, or any major config changes. Like if you get a faster NVMe drive in the future, you can set that as your “hot” (promote) drive, your SSD as the foreground drive and your spinning disk pool as the background ones and your data will automagically migrate.

Have a quick read of the manual, you’ll see that it’s actually fairly easy to set up and operate: bcachefs.org/bcachefs-principles-of-operation.pdf

The main drawback right now (for you) is that it’s not yet part of the kernel. The good news is that it’s gonna be in the next kernel (6.7), so you can either wait for it, or use a third-party kernel with bcachefs already compiled in it (I believe linux-tkg is one of them).

d3Xt3r,

No.

No headphone jack, no buy. It’s not a question of whether a headphone jack is useful to you, it’s just the principle of it - there’s no good reason to remove it (especially for the asking price of FP5), and more importantly, it goes against what the Fairphone stands for, IMO. I can understand if it were some other profit-driven company making a shrewd business decision, but for Fairphone to do it, seems very unfair to me.

d3Xt3r,

Yeah, unfortunately it looks like the reader on the X1 is a special case. Thankfully, this isn’t an issue with my Z13 - the reader itself worked out-of-the-box, just had to enroll my fingerprint from the Settings menu and then added fprintd to my pam.d rules.

d3Xt3r,

No such issues here with my XM5, been using mine for over an year. Are your devices on at least Bluetooth v5.2? All of mine are either 5.2 or 5.3 and I’ve not experienced any issues. I use my headphones with Android, Linux, Windows 10 and macOS. Even multipoint works fine.

As for the head comfort, you could get a headband cover/cushion, such as the ones made by Geekria.

My few remaining gripes with linux

It’s mostly libinput. Why the hell can’t I easily change scroll speed on Gnome and not on KDE? Why does gnome have a simple tool (gnome tweaks) to change the trackpad cooldown to change the time trackpad doesn’t work as a substitute for good palm rejection and KDE doesn’t? Why is it a bit of a pain in both to change...

d3Xt3r,

At least KDE is planning to introduce customisable trackpad gestures next year, with Plasma 6.0. Not sure if that would include palm rejection though or the other stuff.

d3Xt3r,

I used it at work recently to update my work-provided HP Thunderbolt dock, and it resolved an issue where the external monitors would fail to activate after resuming from standby. I never got an update notification when I was using my Windows laptop so I was oblivious to it; it was only thanks to connecting it to my Linux laptop and fwupd, that I found out there was an update, which subsequently resolved the issue.

I love it when stuff like this happens and Linux saves the day. =) (and I get to show off to my Windows heathens colleagues.)

d3Xt3r,

I thought NixOS was already reproducible, like, isn’t that the whole point? What’s the big deal here, and why is it a “great achievement” - does the Linux world now completely change? Does this revolutionize how Linux ISOs are built?

d3Xt3r,

github.com/maximbaz/dotfiles

Comes with a custom install script too. If you plan on using the scripts, then I’d highly recommend forking the repo and customizing the scripts for your own needs, and when there’s a change uostread you could just merge the new changes.

d3Xt3r,

I hope it supports themes. I’d like to make my BSOD look like the classic Windows 9x BSOD.

https://lemmy.nz/pictrs/image/1f681990-b9bc-4c61-9b0e-4fbc0b655e19.png

d3Xt3r,

You’re not breaking the law, you’re breaking a software license agreement. That does not automatically make it a crime, at least, that would depend on your exact local laws, and the lawyer’s interpretation of it - in many cases the actual wording around this is ambiguous and could be argued both ways. A better term for it would be a “legal grey area”, which means if you’re a company then don’t f*** around with it, and if you’re just a random user then no one gives a f***.

In any case, if those scripts were truly illegal, then the Microsoft-owned Github wouldn’t host them in the first place. Clearly Microsoft themselves don’t have an issue with it, so why should anyone else care about it?

Is there a safe way to run multiple desktop environments on Ubuntu 22.04?

I have tried it on several distros before and it always causes problems because you get a million more packages intermingled with your already installed packages and sometimes you get conflicts or whatever. But it usually messes up my system. is there a safe way to have several desktops installed? or do you pretty much install a...

d3Xt3r,

Seconded, Distrobox is the way to go.

Here’s how you can actually make it work seamlessly @Macaroni9538 :
github.com/…/run_latest_gnome_kde_on_distrobox.md

d3Xt3r,

Just use a terminal multiplexer to split your screen (so you don’t need a separate tab), and then ceate an alias/session file with your monitoring programs so you can call it with a single command.

Like @muhyb, I too use btop and nvtop, and this is how it looks like in zellij: https://lemmy.nz/pictrs/image/2e8ad660-f844-4df2-b5ce-aebb0d61d918.png

d3Xt3r,

Nobara KDE user here. One of the reasons why I chose it is because it comes with many of the customisations that I’d normally do (such as using an optimized kernel). But in addition, I use:

  • Opal instead of LUKS
  • KDE configured with a more GNOME/macOS like layout (top panel+side dock)
  • GDM instead of SDDM, for fingerprint login
  • Fingerprint authentication for sudo
  • TLP instead of power-profiles-daemon for better power saving (AMD P-State EPP control, charging thresholds etc)
  • Yakuake terminal (and Kitty for ad-hoc stuff)
  • fish shell instead of bash
  • mosh instead of ssh
  • btop instead of top/htop
  • gdu instead of du/ncdu
  • bat instead of cat
  • eza instead of ls
  • fd instead of find
  • ripgrep instead of grep
  • broot instead of tree
  • skim instead of fzf
d3Xt3r, (edited )

Opal drives are self-encrypting, so they’re done by the disk’s own controller transparently. The main advantage is that there’s almost no performance overhead because the encryption is fully hardware backed. The second advantage is that the encryption is transparent to the OS - so you could have a multi-boot OS setup (Windows and FreeBSD etc) all on the same encrypted drive, so there’s no need to bother with Bitlocker, Veracrypt etc to secure your other OSes. This also means you no longer have a the bootloader limitation of not being able to boot from an encrypted boot partition, like in the case of certain filesystems. And because your entire disk is encrypted (including the ESP), it’s more secure.

d3Xt3r, (edited )

Yes, I do provide a password on boot, as you said, keys can be extracted from the hardware so that’s not secure, which is why I don’t use the TPM to store the keys.

There are no hooks necessary in the bootloader, as it’s the BIOS which prompts you for the password and unlocks the drive.

And yes, there have been implementation problems in the past, but that’s why the Opal 2.0 standard exists - don’t just buy any random self-encrypting drive, do your research on past vulnerabilities for that manufacturer, and check if there are any firmware updates for the drive (don’t just rely on LVFS).

Also, the common hardware attacks rely on either a SATA interface (to unplug the drive while it still has power) or older external ports vulnerable to DMA attacks such as PCMCIA or Thunderbolt 3.x or below; so those attacks only affects older laptops. Of course, someone could theoretically install a hardware keylogger or something, but this is also why you have chassis intrusion detection, and why you should secure and check any external ports and peripherals connected to your machine. Overall physical security is just as important these days.

But ultimately, as always, it comes down to your personal threat model and inconvenience tolerance levels. In my case, I think the measures I’ve taken are reasonably secure, but mostly, I’ve chosen Opal for performance and convenience reasons.

d3Xt3r, (edited )

This is a great release

As KDE F38 user, this is a super boring release. Nothing noteworthy for us to look forward to except LibreOffice 7.6 - which you can get via Flatpak anyways. I was hoping the new DNF 5 would make the cut, but guess it’s still not ready yet. :(

Guess will have to hold out my excitement until F40 for Plasma 6 and DNF 5 (hopefully).

d3Xt3r, (edited )

Meh. As a KDE F38 user, this is a super boring release. Nothing really new for us to look forward to, except LibreOffice 7.6 (which you can get via Flatpak). I was hoping the new DNF 5 would make the cut, but guess it’s still not ready yet. :(

Guess will have to hold out my excitement until F40 for Plasma 6 and DNF 5 (hopefully).

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • localhost
  • All magazines
    •
    Loading…
    Loading the web debug toolbar…
    Attempt #