IRC channel logs


back to list of logs

<jorge[m]123><bricewge "cky:"> Esto esta muy bueno
***califax- is now known as califax
<raghavgururajan>sneek, later tell efraim: I was trying your suggestion ( but getting "Unbound variable: version-major" despite having #use-module (guix utils). Thoughts?
<sneek>Will do.
<raghavgururajan>sneek, later tell efraim: Disregard my previous message. There was a missing `,`.
<sneek>Got it.
<sneek>Welcome back efraim, you have 2 messages!
<sneek>efraim, raghavgururajan says: I was trying your suggestion ( but getting "Unbound variable: version-major" despite having #use-module (guix utils). Thoughts?
<sneek>efraim, raghavgururajan says: Disregard my previous message. There was a missing `,`.
<efraim>sneek: botsnack
<rekado>this may be useful for people trying to improve how Guix tells Python how to find packages:
<rekado>it would be great if we could finally get rid of PYTHONPATH
<PurpleSym>rekado: What’s your idea to get rid of PYTHONPATH? Custom finder? Using the site package?
***Kimapr0 is now known as Kimapr
<rekado>PurpleSym: no idea.
<rekado>there were a couple of discussions on guix-devel about this, but sadly it seems that the only consensus was that PYTHONPATH is not the right thing to use.
<NicholasvonKlitz>I keep receiving `invalid argument` errors when running any guix commands
<NicholasvonKlitz>Anyone know what could be the source of these errors?
<efraim>did you install guix as your user?
<efraim>it looks like you have a version mismatch between the system guix and something in your profile
<NicholasvonKlitz>I'm on a guix system, so not sure exactly?
<NicholasvonKlitz>Anything I could do to better diagnose this?
<efraim>`which -a guix` should only show 2 entries, ~/.config/current/bin/guix and /run/current-system/profile/bin/guix
<NicholasvonKlitz> -- yep
<efraim>so then I guess it'd be down to when the last time you ran `guix pull` and the last time you reconfigured your system would be
<NicholasvonKlitz>that was yesterday... and the issue was present before and after the upgrade
<NicholasvonKlitz>both `guix pull` and `guix system reconfigure`
<efraim>did you reconfigure using 'sudo -E' or su to root and then reconfigure?
<NicholasvonKlitz>I did `guix pull` followed by `sudo guix system reconfigure /etc/config.scm`
<efraim>that should've taken care of it, despite the possibility of your cache files being owned by root
<efraim>I'm not sure what else it could be, I'll have to think about it for a bit
<NicholasvonKlitz>hmm interesting
<NicholasvonKlitz>thanks for the help so far
<NicholasvonKlitz>do let me know if you think you have a clue what might be going on ;)
<calher>Nice install script, folks.
<rekado>NicholasvonKlitz: is GUILE_LOAD_PATH set in this environment?
<NicholasvonKlitz>`echo $GUILE_LOAD_PATH`: `/run/current-system/profile/share/guile/site/3.0:/run/current-system/profile/share/guile/site/3.0`
<ecraven>is there a reason why guix does not package grafana loki/promtail or prometheus (the server, not some exporter)? they are single-binary go programs, shouldn't they be trivial to package?
<the_tubular45>That's what I though and I tried to package a Go app, and I failed horribly :P
<efraim>All go programs need to have all their dependencies packaged too
<leoprikler>"it's just a go package" :)
<dstolfa>one day all these new languages are going to realize that static linking as the only option and rolling their own dependency system as the only option (looking at you, rust) is not doing them any favors
<the_tubular45>To be fair, Rust is going to be in the Kernel soon enough, stuff might change from there
<dstolfa>the_tubular45: i'm sure the kernel is going to have its own loader for rust modules and the likes, but that doesn't change anything in userspace and the distribution mechanism for users... that change needs to happen from upstream
<dstolfa>the_tubular45: i often find myself in a situation where i want to use something better than C and C++, and then regret ever looking into it and revert back to C and C++ because most language ecosystems are absolutely awful
<the_tubular45>I guess that's why you are using Guix, it's trying to make their ecosystem a bit more sane
<dstolfa>yeah, pretty much :)
<dstolfa>that, and containers in a sane way
*the_tubular45 Hides in docker shame
<dstolfa>sometimes you just have to use docker/podman :P
<the_tubular45>Stuff I use in Docker isn't package in Guix though, when they will be, I'll prefer Guix over docker
<rekado>NicholasvonKlitz: perhaps you could unset GUILE_LOAD_COMPILED_PATH and GUILE_LOAD_PATH and see if the warnings disappear
<NicholasvonKlitz>rekado: -- doens't help unfortunately
<PurpleSym>rekado: Hm, would be ideal if we could tell the loader/importer for every package where to look for its dependencies.
<MysteriousSilver>Am I correct to assume a license is non-free if it is *not* mentioned at <> ?
<dstolfa>MysteriousSilver: it's a good indication, but you might have to look at the license itself, as it simply might not be updated
<MysteriousSilver>hmm, the license seems to be a restricted version of AGPL, guess it is not GPL compatible, any idea? this was the license used by the program:
<dstolfa>MysteriousSilver: the SSPL is pretty controversial:
<dstolfa>(i know that OSI isn't about free software and so on... but still demonstrates that it's somewhat controversial, and i don't know if the FSF has reached any agreement on this)
<calher>dstolfa: And don't forget the Floodgap license, which requires programs to be no-cost.
<dstolfa>MysteriousSilver: Fedora also things it's a non-free license
<dstolfa>thinks, rather
<efraim>mongodb was removed because we didn't want to keep our outdated AGPL version because the SSPL was determined to be non-free
<MysteriousSilver>hmm okay, i've asked the author to relicense it
<easbarbosa>hey, will guix home support foreign system?
<easbarbosa>"It works both on Guix System and foreign distros"
<GNUtoo>hi, I'm a bit confused with some of the options of the VPN client,
<GNUtoo>There is the following option: 'auth-user-pass' and as I understand it takes a path to a file ("The option is a file containing username/password on 2 lines"),
<GNUtoo>But I'm a complete beginner to guix and scheme, and I don't really understand things like gexp and so on or how it's supposed to be used,
<GNUtoo>The idea here, as I understand it, is to somehow create a file that ends up in the image but not in the store,
<GNUtoo>so I guess that I'm supposed to generate the file somehow with lisp without having it end in the store, right?
<GNUtoo>As I understand certain lisp expression can generate things (it's probably the gexp), but how to make sure it doesn't end up in the store?
<GNUtoo>The easiest way would be to have an example I think, so is there some example in some git I could look at that uses a mechanism like that?
<civodul>GNUtoo: hi! for 'auth-user-pass' in openvpn-client-configuration, AIUI, you'd pass the name of a file that is *not* in the store, like "/etc/secret/vpn"
<civodul>the manual warns you that if you pass a file-like object, it'll inevitably end up in the store
<civodul>e.g., if you pass (plain-file "secret" "password MySecretPassword"), then other users could find it in /gnu/store, world-readable
<ecraven>so to package those go binaries, I could write my own channel that just downloads and uses the binaries, but for inclusion into guix proper, I'd need to build from source, right?
<GNUtoo>but it doesn't tell how to do that
<GNUtoo>like if I pass it the "/etc/openvpn/password.conf" name for instance, I've to generate /etc/openvpn/password.conf somehow, right?
<GNUtoo>Is the way to go somehting like that: sudo udisksctl loop-setup guix.img && sudo udisksctl mount /dev/loop0p1 && sudo install -m 660 password.conf -t /etc/openvpn/ ?
<GNUtoo>Or is there some scheme way to do it instead?
<GNUtoo>The image will be in the store somehow, so I guess that most ways won't work for instance
<civodul>ecraven: yes, Guix proper builds things from source; but note that "guix import go" might make it feasible for you to build things from source
<civodul>GNUtoo: you'd write /etc/openvpn/password.conf "by hand" and manage it "out of band"; that is, Guix wouldn't know about it
<civodul>currently that's the only way to manage secrets
<GNUtoo>Thanks a lot
*GNUtoo has to reuse his "sudo udisksctl loop-setup guix.img" python wrapper code then
<GNUtoo>btw, while I'm at it, about go, is there some good way to handle dependencies? I don't know go at all and I've added a package in Guix (matterbridge) which looks like it fetches external dependencies during the build (guix import also shows these dependencies),
<ecraven>what does "guix import" do?
<GNUtoo>ecraven: it prints out scheme code that is a valid package
<GNUtoo>for instance: guix import go
<GNUtoo>Here it prints me code that I could mostly upstream as-is in Guix, probably very few things need to be changed
<GNUtoo>If I do that for instance: guix import go the name of the package is not matterbridge but go-github-com-42wim-matterbridge in the code it generated
<GNUtoo>so for instance that needs to be changed before upstreaming it
<ecraven>ah, so there's probably guix import python and guix import perl and whatnot else?
<GNUtoo>And there is even a -r option for recursively doing that to all the package depdendencies
<GNUtoo>*depedencies as well
<GNUtoo>indeed there are many importers
<GNUtoo>I don't know go at all, though for perl and python and so on it probably requires to have what you import be a perl or python package,
<GNUtoo>like already be in the cpan or pipy package system
<GNUtoo>guix import -h shows many of the import systems it supports
<GNUtoo>here python is "pypi"
<GNUtoo>and perl "cpan"
<GNUtoo>In some cases you might still need to do things like patch the software and so on, for instance if the software you want to package uses harcoded paths in /usr/bin for instance
<GNUtoo>ecraven: since guix package and guix build can also build from a scheme file you could even generate the file with guix import and build it with guix build or guix package
<GNUtoo>(and then submit a patch with the package you want to use, assuming that the code being packaged is free software)
<GNUtoo>(and that it doesn't do weired things like steer people toward nonfree software, spy people and basic things like that, but that rarely happens in package managers like pypi I guess, and the maintainers tend to know such traps anyway)
<GNUtoo>(I at least know what is suspicious when working on Parabola)
***janneke_ is now known as janneke
<GNUtoo>Ah apparently you need to add some imports at least on the top of the genrated scm to be usable by guix build/package
<raghavgururajan>Hello Guix!
<ecraven>hm.. guix import has problems with prometheus, I'll try some of the others
<ecraven>ah, actually I just used it wrong, no need (or possibility) to use a URL schema
<GNUtoo>With go it seems to work with URL, but not with some others (like pypi)
*GNUtoo wonders how to copy a file in a system image without root permissions
<ecraven>ah, and of course prometheus doesn't just build like any normal go project, but uses its own builder :-/
<jcob_>Hi guys, good afternoon. I'm currently working on spinning myself up a usable guix system, and I'm having some trouble with nix & flatpak.
<jcob_>nix wont let me add channels (because it contains a broken reference to the bash executable) and flatpak won't give chromium/ungoogled chromium NSS certs
<jcob_>If I could solve either problem I could set up a system that suits my needs. Hahah
<ecraven>so alternatively, I could just write a package that downloads the binary, puts it into ./bin, and hope that will work?
<ecraven>how do I use the name and version of a package in a #:builder?
<ecraven>ah, I should probably use copy-build-system anyway
<Noisytoot>When I run M-x guix RET p n in Emacs, it fails with: "guix-geiser-eval: Error in evaluating guile expression: ice-9/boot-9.scm:1685:16: In procedure raise-exception:
<Noisytoot>Throw to key `match-error' with args `("match" "no matching pattern" (unbound-variable "resolve-interface" "no binding `~A' in module ~A" (python (gnu packages python)) #f))'."
<civodul>jcob_: for Nix, if you think it's a packaging issue on the Guix side, could you send details (how to reproduce the problem) to
<civodul>for flatpak, i don't know, perhaps you could ask on the flakpak channel?
<civodul>or just run "guix install ungoogled-chromium nss-certs" :-)
<jcob_>civodul I might for nix. I was hoping that I was just missing setup steps
<ecraven>if I want to package something that includes a service, is there a tutorial or example for that?
<ecraven>also, how do I best make it possible to specify a config file?
<ecraven>and parameters ;)
<civodul>ecraven: the manual has a reference on services, but i'm being told it's a bit dry:
<civodul>you could look at, say, the openssh service to get started
<civodul>i once gave a tutorial kind of talk about it
<jcob_>civodul : there was a bug already posted on the mailing list. Quickfix is to turn off sandboxed builds
<jcob_>which is super ugly
<jcob_>but it works
<civodul>jcob_: hmm i can't seem to find this one, but i found
<drakonis>someone help me out with this
<drakonis>raid5atemyhomework has a point here
<jcob_>civodul - for what it's worth, you can also just install nix by installing it for one user -- . Which meets my needs as it allows you to just install some packages with nix as-needed
<civodul>drakonis: "someone help me out" and "hello nonexistent reviewer" are likely not the most fruitful introductions
<drakonis>this isnt min ebtw
<drakonis>its not my post
<civodul>i definitely understand the frustration, though
<drakonis>i'd never write anything that rude lol
<civodul>you did write "someone help me out" (imperative tense) tho :-)
<drakonis>basically, zfs has been a blocker for a few folks to begin using guix and i had noticed the patchset languishing in the tracker
<civodul>i guess such patches are tricky because they're non-trivial and require expertise in various areas, including zfs itself
<drakonis>i did not mean to come off as confrontational
<civodul>if you have a chance, you could try the patch out and report in the issue tracker whether it worked for you
<dstolfa>it is worth pointing out that both no maintainer approach and "everything has a maintainer" approach have really annoying issues
<dstolfa>pick your poison... in a way
<civodul>yeah, it was a conscious choice to not have explicit maintainer lists on packages
<civodul>but perhaps we could have sub-system maintainers
<dstolfa>civodul: i guess it's also a matter of process around what subsystem maintainers would do. some projects basically rely on subsystem maintainers to review things for that subsystem and any OK has to go through them. this is not great if the subsystem maintainer is very busy or non-responsive for other reasons
<dstolfa>i got bit by this in another project and as a result just gave up
<civodul>yeah, there are pitfalls all around :-)
<civodul>in the end, what works is when you manage to have a dedicated group of folks, committed to be around for some time and paying attention to patches & bug reports
<civodul>it can be exhausting though, so it's best if we manage to have rotation of these roles
<dstolfa>agreed, it's difficult as free software for most is a hobby and life gets in the way
<ecraven>can I write multiple packages into one .scm file? If I run `guix package -f`, it complains if I don't return exactly one package. would I have to write my own channel for this to work?
<civodul>ecraven: "guix package -f FILE" expects FILE to return one package record
<ecraven>yes, so to put multiple related packages into one file, I'd have to use a channel, not just a file?
<civodul>if you need more, you can write a "manifest", which is essentially a set of packages
<ecraven>ah, ok, thanks, I'll look into that!
<civodul>most commands take a --manifest/-m flag
<civodul>see "guix package --export-manifest" for a start!
<ecraven>hm.. guix edit openssh doesn't show anything about a service definition, is that only part of guixsd, not of the normal package?
<ecraven>thanks! I'll look at that
<civodul>yes, services are part of Guix System
<civodul>see "guix system search openssh"
<ecraven>can I "edit" the definition for that as well?
<civodul>there's no "guix system edit" yet :-)
<civodul>but the command above shows you the source code location
<ecraven>also, has anyone succeeded in running guixsd in an LXC container? I'd like to get it to run under Proxmox, but (obviously) have no idea how to do that yet
*civodul doesn't know
<ecraven>thanks, that service definition is helpful!
<ecraven>if my package *only* produces a prebuilt binary, should I output it as :bin?
<ecraven>(and not produce an out output at all?)
<civodul>usually if there's only one output, it's the one called "out"
<iskarian>drakonis, civodul: as a relative newcomer to guix, it seems like the bigger issue is lack of process. As a patch submitter, if I know that there are concrete steps that I can take to move forward, that is less discouraging than just not getting any response. As a potential contributer who is looking to help take some of the load off of committers, I'm not sure how best to make their job easier, either. There is the criteria in "submitting
<iskarian>patches," but how do I indicate that those pass in such a way that the committer feels comfortable not repeating all those steps themself?
<iskarian>(there is an inherent trust issue, there)
<char>raghavgururajan: Is there anything else I can do to help packaging gnome stuffs?
<sneek>Welcome back char, you have 1 message!
<sneek>char, raghavgururajan says: Arch is binary-based, whereas, Guix is source-based. Also, I just saw your DM. :)
<jeko>Yoo Guixters !
<drakonis>iskarian: there is indeed space to deal with this
<leoprikler>iskarian: You can reply with stuff like "LGTM", but whether contributors agree or not is debatable :)
<iskarian>leoprikler, yes, that is what I'm getting at. Could there be a non-committer review process such that committers could have confidence in a "LGTM" that visibly follows said proess?
<civodul>iskarian: right, so committers will typically repeat some of the verifications, but it helps if you explicitly acknowledge that you already made this and that verification
<civodul>also, there *is* a non-committer review process
<civodul>too few people do that, but it's very much appreciated
***iyzsong- is now known as iyzsong
<civodul>it speeds things up noticeably
<leoprikler>For the record, what are the differences between committer and non-committer review process sans the obvious fact that the latter can't push patchesß
<civodul>that's it :-)
<civodul>perhaps it's best if it's clear to the submitter that the person doing the review isn't a committer, so they don't wonder why the patch doesn't show up instantly in the repo
<civodul>but that's all
<civodul>there's a handful of people helping out and it's super helpful
<leoprikler>Yeah, I know about zimoun.
<civodul>right, maximed too
<civodul>we also need committers to review more actually :-)
<iskarian>civodul, do you mean the checklist under "Submitting Patches"? Or is this review process elsewhere?
<leoprikler>afaik it's more or less the checklist
<leoprikler>there are some caveats when it comes to specific subsystems (*cough* rust *cough*), but once you've learned how things "ought to be", you can quickly verify that they are
<leoprikler>reporting stuff from the linter also helps, because sometimes people don't check that
<iskarian>I suppose what's kept me up (even keeping in mind the checklist) is the lack of a clearly defined formula. Both for what's appropriate to do as a non-committer reviewer, and how to communicate it concisely and politely to submitter and potential committers. Essentially, the fact that you can't effectively review until "you've learned how things ought to be". Perhaps this is more of a "me" issue? :)
<civodul>iskarian: no you're right, we've not advertised it and documented it sufficiently well, i suppose
<civodul>the reviewer checklist is roughly the same as the submitter checklist
<civodul>but perhaps it would help to have it spelled out
<civodul>but yeah, there's room for improvement
<civodul>it'd also be nice to incentivize review, for committers and non-committer
<civodul>suggestions welcome!
<iskarian>Personally, I find incentive in seeing the 'bug' list shrink rather than grow, but that's probably not universal :)
<iskarian>(aside: would some type of 'reviewed', 'committer-reviewed' or 'unreviewed' tags help?)
<dstolfa>civodul: i'm not sure how one incentivizes review without some kind of financial reward :/
<dstolfa>we all agree that review is good, but in my experience the only thing that's actually worked is paying someone to review things
<civodul>dstolfa: i don't think that's entirely true: many (most?) free software projects are volunteer-run, yet, for many, review happens
<civodul>but there's a scalability issue we're facing, for sure
<dstolfa>civodul: my experience is somewhat limited to the BSDs and FreeBSD specifically, but even if people do review things, there's never enough reviewers, especially for complex things and stuff tends to get bitrotted, sometimes bad code gets committed and then needs to be reverted, etc
<iskarian>Hmmm. Don't the larger projects usually have at least a small paid staff?
<civodul>iskarian: sure, but that doesn't mean paid staff do nothing but review
<civodul>(i for one have part of my paid work time on Guix, but i do things other than review sometimes :-))
<civodul>dstolfa: i guess it's about striking the right balance between no-review and endless-nitpicking-review
<civodul>it's tricky
<dstolfa>it is, yeah :(
<civodul>i tend to nitpick, but i also try hard to be pragmatic ;-)
<dstolfa>software is never the hard part -- it's always the social elements around it! :)
<iskarian>No, I agree it's better to be a little more thorough up-front; it just takes a lot of time
<rekado>I think I found a bug in the wrapper that “guix pack -RR” produces.
<rekado>I cannot reproduce it reliably, but the symptoms are this: after some time has passed (e.g. 10 days) it no longer rewrites file open requests and tries to access /gnu/store directly.
<rekado>I see this right now in a web site that I deployed with “guix pack -RR”
<rekado>its assets are no longer found, because — as strace reveals – they are not found at /gnu/store/…
<rekado>that’s because /gnu/store does not exist; only a locally unpacked ./gnu exists.
<rekado>when I restart the web server via the -RR wrapper everything is fine again
*rekado does that now
<civodul>rekado: hmm, interesting!
<civodul>this is using the "userns" engine?
<Rooks>Am I supposed to be running out of inodes?
<civodul>Rooks: nobody's supposed to :-)
<drakonis>userns engine?
<rekado>civodul: not sure what engine is used to be honest
<civodul>rekado: when GUIX_EXECUTION_ENGINE is unset, it tries user namespaces and falls back to PRoot
<rekado>okay, I’ll check if user namespaces are available on the host
<drakonis>that's a neat thing i didnt know about
<drakonis>well, not guix pack in particular
<drakonis>but the execution engine bit
<civodul>rekado: you can force that with "GUIX_EXECUTION_ENGINE=userns"
<rekado>looks like it’s available
<rekado>civodul: okay, I’ll try that
<Rooks>Is there a recommended way to manage inodes?
<maximed>Rooks: Deleting a bunch of files should free some inodes. There are also some ext4 settings but I'm not familiar with those
<maximed>This is on an ext4 filesystem, right?
<maximed>(This is file-system specific)
<Rooks>yes, but it seems /gnu/store used a lot?
<maximed>/gnu/store has plenty of files
<dstolfa>`guix gc` should free up a lot of stuff if it's an old system
<maximed>Maybe do "guix system delete-generations && guix package --delete-generations && guix gc" to free things
<civodul>that deletes all the old generations though
<civodul>i'd just delete old generations, with "guix gc -d 5m" say
<civodul>still, we have ext4 file systems holding several terabytes of /gnu/store
<civodul>so i'm surprised one can run out of inodes
<maximed>I ran "guix gc" a few days ago, it freed about 60GiB
<civodul>i wonder if there's a file system setting or something that could explain this
<dstolfa>civodul: i think it's just the installer defaults that are a bit annoying
<civodul>dstolfa: which ones?
<dstolfa>civodul: the main culprit is likely bytes/inode ratio, which is the `-i` flag in `mkfs.ext4`
<dstolfa>if the installer uses a default, it's 16384, which is not great. 8192 or 4096 is a much better number for something like a store
<civodul>dstolfa: ok; though i think i've always used the defaults too, weird
<dstolfa>civodul: once btrfs has trickled down from Fedora into RHEL and starts getting industry testing, guix is probably a very good target for it as a default thing in the installer (especially if coupled with a zstd mount option)
<jonsger>please no btrfs as default...
<Rooks>Okay cleaning old generations dropped inode use from 94% to 12%
<Rooks>Thanks all
<dstolfa>jonsger: well you don't have to choose it, but it beats the confusion that people get when their disk usage rapidly climbs, and especially if they run out of inodes :)
<dstolfa>obviously discussion has to happen and it's too early to do something like that
<dstolfa>but we're just talking about defaults in an installer for non-technical users
<maximed>jonsger: Why not brtfs by default?
<maximed>FWIW, it works for me, and features like "zstd" are nice
<jonsger>maximed: it brang me to much struggling. I just don't like it and see no real advantage, over something boring like ext4 or xfs
<dstolfa>jonsger: but there objectively is an advantage
<dstolfa>for example, users can't run out of inodes
<dstolfa>and zstd compression is REALLY helpful when you keep many generations and grafted packages over time around
<dstolfa>(and again, nobody's saying that other filesystems would be removed, it's just an installer default)
<jonsger>dstolfa: but out of space? did an update on RHEL last week and snapshots just blow my space away
<dstolfa>RHEL doesn't support btrfs.
<jonsger>it was oracle linux, but thats the default
<jonsger>and it was installed on btrfs...
<dstolfa>right, that's just poor configuration. honestly, i kind of expect nothing less of oracle lol
<maximed>jonsger: I don't use snapshots. I don't know how complicated that is with btrfs
<jonsger>maximed: it's just strange. So you propose using btrfs with snapshots disabled?
<dstolfa>maximed: it's just a copy-on-write filesystem. if a system defaults to snapshotting every directory on an update, especially one that contains a large, constantly changing database, things will blow up in space quickly
<dstolfa>you can set quotas and the likes
<dstolfa>jonsger: if we were to default to btrfs in the installer, snapshots wouldn't be enabled by default as guix already has "system snapshots" and will have home snapshots through guix soon. instead, providing a service type for users to specify what they want to snapshot selectively would be something useful, so they could snapshot their media and so on, set quotas, etc
<dstolfa>and again, this is not something that makes sense until btrfs has been a bit more battle tested by fedora and has trickled down into RHEL eventually
<dstolfa>but guix is a very good target for a file system that supports snapshotting, has a lot of similar files duplicated many times and lots of symbolic links, as it can't run out of inodes and supports zstd
<maximed>jonsger: I don't know what you mean with ‘snapshots disabled’
<maximed>I just use "btrfs" as a file system for saving files
<maximed>I'm not fiddling with subvolumes or snapshots
<maximed>What's strange about using btrfs without using snapshots?
<jonsger>nothing, maximed sounds like a better idea then using it with snapshots and subvolumes ^^