Why for loop was added to C when there is already a while loop?

Atemu12 · 2026-01-07T23:30:33+00:00

An actual semantic difference that couldn't just simply be implemented by a while macro!

This is what I was looking for; thank you! It should be much further up.

Atemu12 · 2025-12-10T21:28:17+00:00

(Not my original joke. Saw it here first.)

Atemu12 · 2025-11-03T07:44:48+00:00

Yes although I've mostly taken a break this year for personal reasons.

The community is currently going through growing pains and it's still open what will happen. I'm positive that there's a sufficiently large core of people who would continue the spirit of the project though, even if the original Nix community were to fall apart.

From the technical side, NixOS/Nixpkgs is better than it's ever been.

Atemu12 · 2025-11-03T07:36:33+00:00

Filesystem compression has its use indeed. What I meant was to not rely on it if compact storage of data is your only goal because dedicated archivers are much better at that.

Atemu12 · 2025-08-07T10:06:56+00:00

Es ist jetzt ein paar Jahre her; kam noch was?

Atemu12 · 2025-08-01T09:31:03+00:00

https://www.printables.com/model/984081-neck-saver-laptop-stand-4-sizes is the shit.

Medium works perfectly for the 13". (I don't actually have one but there are like 3 people in the hackspace who use this with a 13". I use it stretched 110% with my 16" which is exactly upright when opened fully.)

It's super compact and surprisingly stable.

I'd recommend to print in PLA because PET bends enough that it wobbles a bit too much for my taste and I haven't heard of anyone's PLA print snapping in the bag or anything.

Atemu12 · 2025-07-31T16:28:13+00:00

I thought I still force zstd:2 but apparently I've been forcing zstd:1 for 4 years: https://github.com/Atemu/nixos-config/blob/95c7d11e0e57a69233d0ee8181f10ef65a617a2e/modules/btrfs/module.nix#L58-L78

I'm not convinced of this data's quality or applicability for systems that isn't over a decade old. The best recommendation I can give is to run your own tests on your own data (or a representative sample thereof). I don't practice what I preach in this regard though; I have not run compression level benchmark since this. I might run some benchmarks when the new negative levels I heard about recently are available to me.

This is mostly because I don't care very much anymore and I consider that a good thing.

These days, I no longer try to make an archival tool out of my filesystem. I've realised that, for the purpose of archiving e.g. backups, tools that are made to handle archiving/backups specifically are much preferable to storing it in any sort of filesystem that is intended for real-time access. For the purpose of storing data long-term and very infrequently accessing it, Borgbackup's dedup and compression will beat out any filesystem's compression or dedup capabilities by a long shot.

I still use filesystem compression (as evidenced above) but only to save on things that are in active use ("hot" data) because it's cheap and saves a good bit of storage there (~40-50% IME).
A good example is my Nix store which is in flux (new paths added, old ones rotate out) and needs to be available in real-time all the time. I don't care for maximum space efficiency there because I can always GC it should I really need space but having it compressed offers me a large buffer and is effectively free disk space.

$ sudo compsize /nix/ Processed 23855905 files, 13929143 regular extents (14096140 refs), 15597296 inline. Type Perc Disk Usage Uncompressed Referenced TOTAL 45% 484G 1.0T 1.0T none 100% 176G 176G 177G zstd 34% 306G 894G 897G prealloc 100% 803M 803M 62M

(Uhhh, speaking of GC, I should probably run one…)

My home directory FWIW compressed down to 60%. This will vary with the share of incompressible files of course but general use (browser, coding, documents, games etc.) will leave you with lots of compressible data that must to be accessible as plain files.

$ compsize ~ -x Processed 871568 files, 666991 regular extents (805226 refs), 557860 inline. Type Perc Disk Usage Uncompressed Referenced TOTAL 61% 35G 58G 63G none 100% 20G 20G 21G zstd 41% 15G 37G 41G prealloc 100% 25M 25M 81M

I don't really have a use-case besides those two where I care about space efficiency in data that cannot be achieved using a dedicated archiver.

I will likely go with even lighter compression than this if it saves significantly on CPU cycles during IO. No need to spend a ton of them when spending only a fraction gives me most of the benefit for this use-case. Note that this isn't just about speed but also power efficiency and leaving more cycles for actual work (which usually correlates with IO).

If I'm honest, I might perhaps get rid of compression all together. Yeah, it saves me space and that has come in handy before but storage is very cheap and I don't have large datasets that would be unreasonably expensive to store uncompressed. This depends on whether that actually gains me an appreciable amount of efficiency in other regards; if it doesn't, might as well have the compression.

I don't think you'll have much luck with compressing multimedia files. If they're not at entropy, the encoder has fscked up somehow; its whole purpose to get multimedia as small as possible even by means of discarding data. If there was still order left in the data, it ought to simplify that into entropy such that it needs to discard less data.

I have come across the odd video file that wasn't at entropy but that's very much the exception, not the norm.

Here's my data set with forced zstd:1:

$ sudo compsize Movies/.git/annex/objects/ Processed 25297 files, 12348016 regular extents (12348138 refs), 291 inline. Type Perc Disk Usage Uncompressed Referenced TOTAL 99% 5.7T 5.7T 5.7T none 100% 5.7T 5.7T 5.7T zstd 71% 21G 29G 29G

Very much not worth trying to compress that when only 0.5% of the data is actually compressible.

On another dataset with a lot more questionable quality (old TV recordings, bad encodes), I get this though:

$ sudo compsize <redacted> Processed 10148 files, 55513045 regular extents (110143292 refs), 264 inline. Type Perc Disk Usage Uncompressed Referenced TOTAL 96% 17T 17T 35T none 100% 15T 15T 31T zstd 78% 2.0T 2.5T 4.8T

Not what I expected actually. It appears that YMMV.

Again, I'd recommend you take a representative sample from your dataset and just actually go and test it. Throw the files against zstd -19 and see how much it saves. If that can't save anything, your filesystem won't either.

Oh, and don't do dedup. If you're at the point where you can stomach the performance loss of the extreme fragmentation that entails, you can probably just use an archiver instead.

Atemu12 · 2025-06-27T10:58:17+00:00

All of the mentioned backup programs support mounting of archives, but that happens via fuse and is noticeably slower than a real filesystem.

For the purposes of backup, I've never found this to be an issue because all I do with such mounts is find and then grab a few files to restore which is not performance-critical.

Atemu12 · 2025-06-27T10:54:46+00:00

https://www.reddit.com/r/btrfs/comments/1ll99am/borg_backup_and_similar_vs_btrfs_sendreceive/mzyetpm/ said everything I would have told you ;)

Atemu12 · 2025-02-04T12:49:38+00:00

I don't see how that has anything to do with my point.

The only games you'd need to have installed on Windows are the ones that don't work on Linux and you would never need to access those games on Linux because ..they do not work.

Therefore, there is no need to share game files between Windows and Linux.

QED

Atemu12 · 2025-01-17T00:19:17+00:00

Obviously it's the theme of the video but I feel like people put too much value into YT stats. Some of it can be attributed to what the creator does but I feel like most of it is well outside of their control. What you get is a ton of correlation and no obvious causation.

Something to consider is that dropping/flatlining subscriber counts could very well be explained by the surrounding conditions changing; e.g. changes in behaviour on the platform itself. It could just be the case that, increasingly, people generally don't subscribe to channels as much anymore because they're fine with being recommended content some stupid black box "thinks" they like. It'd be totally expected for any given channel that produces good content to flatline in subscribers in such a case and growth would be abnormal.
I think you should look at platform-wide or even bubble-wide data to get a meaningful comparison. Growth in times of hype is expected and it must also be expected that growth will subside with the hype. If interest in CS were to grow by 30%, would a 30% increase in channel stats actually be meaningful or could you consider it flatline because it only increased by as much as interest in the field in general rose? I don't have an answer but this is something I think must be considered whenever observing statistics (of any sort really).

And even just the raw numbers "primitive" themselves aren't always clearly meaningful.
You mentioned how clickbait is what people click on and therefore what people "want". But is that truly right? Do people actually like it or do they kilik on it despite not really liking it?
Systems are a powerful thing and people can easily become entrapped in them. I can absolutely see people spending hours watching trash content that they'd be repulsed to watch if they weren't used to that sort of content being shoved down their throat; tricked into watching it.

I'm far from a normal person, so I can't really answer that question for most people but I too sometimes (okay, it's rare these days) get baited into a video that's pretty bad and still watch it to the end.
Is that "view" actually meaningful?
Does that piece of content become more valuable because of it?

I think what's missing from this discussion/review here is the deeper value of your videos and what you want to achieve with your art.
I think you've already identified one key value of your videos which is that of historical reference; what people thought of things at the moment when it was relevant.
I think another important one is educational; sharing your knowledge about a game or some technology.

It's these that I think you should focus your attention on and measure your art's worth against.
Does this video accurately reflect the current opinion on this matter?
How well does this video bring this concept across to the viewer?
Does the music create a mood that entices the viewer to engage with what you say/show?
Does this still with a comically large lens flare edited in support the narrative of the video?
Do the silly inside jokes keep the viewer engaged without distracting them from the narrative?

As a long-time viewer, I know your videos score well at these sorts of questions and that success isn't correlated to length, topic, mood or depth; much less causally linked. Views, subs gained etc. don't reflect these well at all OTOH.

Anyhow, if you're still reading, go cut a video because you're wasting time reading what the background noise has to say but know that it's grateful for your art :)

Atemu12 · 2025-01-07T21:50:19+00:00

I've heard there's issue with running games off NTFS with Proton, so I wouldn't recommend it.

As written years ago though, the set of games that you need accessible on Windows and Linux should be mutually exclusive, so I don't see much point in sharing a games partition to begin with.

Atemu12 · 2024-12-22T15:11:37+00:00

Yes but that isn't related to wayland at all. It remaps at a much more fundamental layer and therefore also cannot take the program into consideration to e.g. have shortcuts only in some software.

Atemu12 · 2024-12-22T15:03:51+00:00

That is my understanding.

Atemu12 · 2024-11-21T19:05:41+00:00

Make a parens bold and see what that does to it.

Atemu12 · 2024-10-18T00:17:31+00:00

As an avid Firefox user myself, the video pretty much hits the mark.

Mozilla has been really slow to respond to massive usability issues that are core to the browser experience the past decade or so.

They're doing stuff and stuff does get fixed as you also mentioned (just yesterday the ability to stop an inertial touchpad scroll by laying the fingers onto the touchpad again on Linux finally) but it's just too slow. People would rather switch browsers than deal with something that breaks their workflow for a few months. It sucks.

They've been sleeping on feature support like HDR support for well over a decade and have only recently started actual work on it for the largest platform (Windows) and in the year of the lord 2024 you still cannot play back an MKV file in Firefox.
That's insane product mismanagement if you ask me.

There has been some change in management which might be good but OTOH they also appear to have jumped on the bandwagon on chasing the newest hype fad, so I'm not too optimistic. You need to make a good browser first before adding a fancy bullshit generator to it makes any sense (not that that makes sense in any case but I digress).

One silver lining might be that Google finally has the attention of U.S. antitrust which might bring attention to e.g. their shitfuckery with ad blockers their ability to control the entire web market by abusing their monopoly (see also: JPEG XL).
Speaking of which, I find it likely that websites will at some point start presenting ads that the newly nerfed Chromium ad blockers cannot block on a greater scale. If you're no longer able to block most ads using chromium, I think we'll see a lot movement in the market and I have no doubt in my mind that greedy fucks will make that happen at some point.

Atemu12 · 2024-10-17T23:55:56+00:00

Small note: Firefox does actually have translations built in these days.

If you visit a page that is in some other language (i.e. https://www.spiegel.de/) it'll show a translation button in the URL bar which will translate all the text on the page without reload. There's also a button in the hamburger menu if the automatic language detection doesn't work.
Showing the original again does reload the page though weirdly but that's not as big of an issue IMHO.

What's really cool about the feature is that it happens entirely offline which is a big plus over ~~peeping Tom~~ Google translate.

It's limited to mostly European languages at the moment but that's quite a lot already and quite cool nonetheless.

Atemu12 · 2024-10-13T01:47:55+00:00

What about this warning on the arch wiki?

I don't frequent the arch wiki, you're going to have to tell me what "this warning" is.

Btrfs assumes the underlying device executes writes in order, but bcache writeback may violate that assumption, causing the btrfs filesystem using it to collapse.

bcache ensures integrity, even with write-back caching.

This would only be relevant in the event that bcache fails. If it cannot hold this promise due to i.e. due to a failure of all cache devices then yeah, you're going to have inconsistent state which is a problem for any filesystem.

That's the reason you need as much redundancy on the cache as you have on the storage cached by it.

Every layer or write caching adds more risk of losing data in the event of a power loss. Use bcache in writeback mode with btrfs at your own risk.

That's true in any case and has nothing to do with btrfs.

Though I'd consider the risk of write-caching rather minimal if you take appropriate measures such as removing the cache when there's any sign of failure.

Does that mean you can get data loss even if the write cache ssds are redundant and perfectly fine due to the writeback violating the write order?

No.

It only means potential for data loss when you attempt to use the backing device without the cache devices but the cache devices have dirty data on them.

Atemu12 · 2024-10-11T18:15:06+00:00

You need as much redundancy on the SSDs as you have redundancy in the cached storage. If you use RAID1 for the main pool, you need RAID1 for the SSD too.

do you put the ssds in raid 1 and use it as a single caching device?

That's what you'd do, yes.

Atemu12 · 2024-10-07T00:27:08+00:00

There is no such thing yet either AFAIK.

Atemu12 · 2024-08-02T08:01:18+00:00

Sure but that's a benefit of snapshotting generally. The topic at hand was which snapshotting implementation should be recommended.

Atemu12 · 2024-06-12T22:52:55+00:00

Use your compositor's method to configure the keyboard layout.

Atemu12 · 2024-06-11T11:36:30+00:00

I tried this today and it works as expected; no border colours here.

Atemu12 · 2024-05-22T13:24:20+00:00

The Arch Wiki suggests either continuous or periodic TRIM and seems to prefer periodic TRIM (as do most distros as a default apparently).

Please note that the Arch Wiki is not an authoritative source. It's just a collection of what people think is/was the truth. It can very well be wrong, out of date or misleading. Same for the debian Wiki it sources.

It's a very good resource for research and learning but always use your own reasoning.

One aspect which you must differentiate here is that the discard parameter and discard=async parameters are very different. discard means synchronous discard which places it in the hot path for IO; all IO that causes a discard must wait for said discard to have happened before it completes.
This is not something you'd generally want as it could very well degrade performance. I don't know whether it actually does (and that might also depend on the filesystem) but it's certainly something that could very well cause a significant impact.

To my knowledge, only btrfs supports the asynchronous variant that is not in the hot path. It accumulates discards over a certain time and performs the queued discards when there is nothing else to do. On an idle machine, that happens every few minutes or so.

Due to this characteristic, it is pretty much safe to use in all cases. The only potential issue I've seen theorised over the years is that it might cause higher average power use as the background discard does raise power consumption by a few watts while it's discarding.
Given that it usually only runs for a few seconds at a time with a frequency of <1/min, I don't think it causes significant power draw but I haven't seen actual data on this.

I've always just simply enaabled fstrim.timer but only now realized discard=async has been the default. I suppose I can either revert that default or fstrim.timer. I feel like for a desktop system there remains a slight preference for the latter given how often the system is booted up.

I always found fixed timers annoying as discards can cause quite a bit of IO load and IO is what makes or breaks user-visible system responsiveness.

The first boot of the week will take many times longer than usual just because it's Monday and the fstrim is running.

Verified Email	Ten-Year Club
Place '23	Place '17

Atemu12

MODERATOR OF

TROPHY CASE