That’s a good reply. Reading the other replies, I realized that great runtime is very different for everyone. I wouldn’t consider 5-7 hours great. More like absolute minimum 8. Better is 10-12. This sounds very unlikely though, apart from MacBooks with ARM CPU.
I use systemd mount files instead of fstab, that way I can specify a network dependency in the off chance there’s no network connection. Plus I can have other services like jellyfin depend on that mount file so it starts after the share is available.
Wait, isn’t a lower frame time better? Why does their screenshot show windows having the lowest and say that it scored last?
Looking at the source article, windows did have generally better 1% lows except for Starfield, so I think this article has it backwards. They also cherry picked 2 results where windows was worse lol.
I’m all for pro-linux stuff but articles like this just reek of making shit up so it looks better.
They probably didn’t label their axes properly. FPS is a clearly defined metric, and there, more is better. This indicates that the conclusion (Linux is faster) holds. Since frame times have an entry with value “100” and all other values are lower, I assume that’s in percent, i.e. Arch Linux is the fastest and picked as comparison point, and the others are shown with relative performance to Arch.
I think FPS was actually selected, not frametimes. 1% low frametimes of 89 does not make sense.
There is an issue with the image in the article, but not the one that you might think it was. The FPS should have been more clearly indicated that it was the selected tab and then it probably would have been fine.
edit: I went to the base website www.computerbase.de/2023-12/…/2/ it’s in German, but, it seems like the frametimes and frame rates are nearly the exact same values - which doesn’t even seem to make sense to me?
I’ve never been a fan of the UEFI logo inserting itself into the boot screen. It’s basically just an advertisement for the hardware vendor because they’re jealous of the OS having the spotlight. And it’s an ad that, like so many other ads before it, screws over the security and privacy of the advertisee because fuck you that’s why.
I don’t know. It looks more aesthetically consistent. Your computer has to display something. Average users would be scared if it dumped logs on the display. so the vendor logo makes sense. It COULD just say loading, but this is a bit pedantic I think.
With UEFI, it goes “Motherboard Logo -> Motherboard Logo”
Sure, it’s more consistent, but the alternative is not user unfriendly, the only people it’s unfriendly to is the marketing wankers at Dell, Lenovo, Acer, etc.
When it comes to security, particularly at boot time, fuck the user. Users don’t interact with devices at boot time so it doesn’t matter if it shows a blank screen, a mile of logs or a screaming clown penis. If it was up to users no device or service would have a password or security of any kind, and every byte of information about your life would be owned by 'The Cloud." Let the marketing wanks insert their logo into the Windows boot process,
I want to insert my own logo into the boot process, and I want these ducking vendors to properly validate and assess their mother ducking software. But nooo, penetration tests and any remediations are too expensive for these pieces of bit. Why do it when you can just stick your dick in everyone’s face, right?
The principled “old” way of adding fancy features to your filesystem was through block-level technologies, like LVM and LUKS. Both of those are filesystem-agnostic, meaning you can use them with any filesystem. They just act as block devices, and you can put any filesystem on top of them.
You want to be able to dynamically grow and shrink partitions without moving them around? LVM has you covered! You want to do RAID? mdadm has you covered! You want to do encryption? LUKS has you covered? You want snapshotting? Uh, well…technically LVM can do that…it’s kind of awkward to manage, though.
Anyway, the point is, all of them can be mixed and matched in any configuration you want. You want a RAID6 where one device is encrypted split up into an ext4 and two XFS partitions where one of the XFS partitions is in RAID10 with another drive for some stupid reason? Do it up, man. Nothing stopping you.
For some reason (I’m actually not sure of the reason), this stagnated. Red Hat’s Strata project has tried to continue pushing in this direction, kind of, but in general, I guess developers just didn’t find this kind of work that sexy. I mentioned LVM can do snapshotting "kind of awkward"ly. Nobody’s done it in as sexy and easy way to do as the cool new COWs.
So, ZFS was an absolute bombshell when it landed in the mid 2000s. It did everything LVM did, but way way way better. It did everything mdadm did, but way way way better. It did everything XFS did, but way way way better. Okay it didn’t do LUKS stuff (yet), but that was promised to be coming. It was Copy-On-Write and B-tree-everywhere. It did everything that (almost) every other block-level and filesystem previously made had ever done, but better. It was just…the best. And it shit all over that block-layer stuff.
But…well…it needed a lot of RAM, and it was licensed in a way such that Linux couldn’t get it right away, and when it did get ZFS support, it wasn’t like native in-the-kernel kind of stuff that people were used to.
But it was so good that it inspired other people to copy it. They looked at ZFS and said “hey why don’t we throw away all this block-level layered stuff? Why don’t we just do every possible thing in one filesystem?”.
And so BtrFS was born. (I don’t know why it’s pronounced “butter” either).
And now we have bcachefs, too.
What’s the difference between them all? Honestly mostly licensing, developer energy, and maturity. ZFS has been around for ages and is the most mature. bcachefs is brand spanking new. BtrFS is in the middle. Technically speaking, all of them either do each other’s features or have each other’s features on their TODO list. LUKS in particular is still very commonly used because encryption is still missing in most (all?) of them, but will be done eventually.
NVIDIA’s Debian repo for Cuda has more up to date GPU drivers, if you don’t wanna manually install from the .run file. Documentation here, its not reflected yet in the docs but there’s a Debian 12 repo.
You can use the terminal commands to automate tasks, build cicd etc. Navigating file tree and performing tasks is much quicker once you get the hang of it. Lastly it translates well on all distros and even on Mac, or windows with wsl or cygwin
The article didn’t mention this, but would disabling the UEFI logo in the boot screen mitigate the vulnerability until proper patches get rolled out? (Or honestly at this point, I’d keep it disabled even after it’s patched in case they didn’t patch it right. UEFI’s are all proprietary so it’s not like you can check.) Since the vulnerability is in the image parser, would bypassing that be enough?
Just use rsync -va (possibly with --chown if you want user/group to be different at the destination and with --delete if you want removed files to be deleted) to continue the copy operation, it automatically takes care of figuring out which files still need to be copied and which are already there.
The default quick check algorithm of rsync is not safe for this. It only checks filesize and modification time to determine if files are equal. After a b0rked copy, these are not to be trusted.
You should add the -c flag so that files are properly checksummed, unfortunately if you have slow storage on either end, this often negates the speed advantage of rsync.
My memory of the cp command is that attributes such as file times were transferred at the last step. I think this would make rsync safe in most situations where a system crash wasn’t involved.
True if the initial state is unknown but if you do your initial copy and all the later syncs with rsync it is not really necessary since rsync puts the partial files in a temporary location (there are same parameters to control the details of that too).
Next time I look for a small laptop to have handy one thing I’m going to be sure to prioritise is: how much battery does it use while suspended? I’d really like to not need to have it switch to hibernate after 30m of sleep or w/e and ideally just plug it in overnight like a phone.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.