1
2
3
4
5
6
7
8
9
10
 
 

Hello,

so I have quite a few drives in my desktop, but the main one that really lags my system down is a 12TB (seagate ironwolf, yes i know..). It seems to spin up and down often, then whenever I open a file in nemo I get freezeups when the drive has to spin up.

I know my 2 issues, it's an ironwolf, and I have it formatted as NTFS (because when I got it I was moving from windows to linux and kind of needed NTFS to still be there for windows. But now, I don't have a way to offload it all to reformat as EXT4.

Is there a way to keep it spun up for longer? My power saving shouldn't be doing anything with drives but i'm unsure.

I'm on Mint (yay noobs)

11
 
 

cross-posted from: https://piefed.world/c/linux/p/1352148/a-question-for-gnome-kde-users

For people who already tried both, what's the reason you're sticking with GNOME or KDE as your desktop environment?

12
 
 

More specifically, issues for one distro (or maybe family of distros if applicable) and not other distros.

I'll start: NixOS. I love how I can have my whole operating system configuration defined deterministically with configuration files, but what I believe is a serious flaw, is when you choose the "unstable" channel, the channel for receiving the latest packages rather than ones up to 6 months old: stable. Unstable package often build dependencies on device, and I've often faced build failures, why are new package versions given if they fail to build?!

Why can't Nixpkgs backend ensure that new package versions build successfully before shipping them to end users?! It would take a lot of work to do so, but I can't think of any other distros that have this problem: where installing a new package version that came out a few days or even a week ago, has a chance of failing after its made available in the distro's official package manager.

There are a handful of workarounds for your NixOS configuration in this case, but it happens too often for me and I shouldn't have to edit my config for to work around it.

13
14
15
16
17
18
19
20
21
22
23
submitted 3 days ago by to c/linux@lemmy.world
24
25
view more: next ›