it does. I have snap shotting set for every hour, so every hour my file system creates a copy my main canonical file tree, and if some files changed in that hour, other than those files, all files are mapped to canonical file entries (same block data). for changed files, it points to their original blocks, so essentially changed files have copies. now you can write a command to delete certain amount of old backups, or oldest or however many, and there are multiple graphical implementations as well.

some example of snap shotting file systems are zfs and btrfs. in linux latter is better supported in general. zfs is a bsd project which has a openzfs implementation for linux and many distros support it too.

how about a snapshot based system? snapshots treat all changes (inode level or in some deduplicating cases, block level) from some starting point, each snapshots only saves changes.

I know every one will say snapshots are not backups, and i fully agree, but you can also implement a full mirror of relevant dirs in some external snapshot-ting file system on some other media, and like once a day or week or month, keep making snapshots.

my bad, sorry. reading humor/sarcasm over internet is a bit hard

why do we want to hate on other projects.

1000 dependencies

that is too much. i use something with 900ish, and even withh cached builds, it takes like 20 mins, we just have too much linking going on

editor does not matter for practical purposes (in my naive tests, helix is within +/- 5% of vim/nvim on most files (in terms of memory usage), i do not use any lsps). i generally do not use lsps (too much feedback for me), but even if i would, i get like 1-2% consstant cpu usage while working, whereas 0% without any lsp (averaged on 30 sec intervals).

while compiling, you have 2 options - just for testing, you can run debug build and see if it works, and once you get something reasonable, try release build, it should be feature wise practically same, but faster/more optimised (cargo buid vs cargo build --release).

in terms of crates, try to to not use many, i just try to not import if i can write a shitty wrap myself, but if you include something, try to to see cargo tree for heaviest crate, and try to make tree leaner. also, try to use native rust libs vs wrappers around system ones (in my experience, any wrapper around sys stuff uses make/cmake stuff and gets slower).

now these are all things without changing anything about runtime. if you are willing to gain more performance by trading storage space, you should do 2 things - use sccache and shared system target dir.

sccache (https://github.com/mozilla/sccache) is a wrapper around compiler, and essentially, you cache build files. if file hash remains same, and if you have same rust toolchain installed (it has not updated in breaking ways), it will reuse the earlier build files. this will often help by reusing something like 50-70% of crates which stay same (even across project).

after installing, you just go to cargo dir ($CARGO_HOME) and editting config.toml

[build]  
rustc-wrapper = "sccache"  
target-dir = "<something>/cargo/target"  

[profile.release]  
lto = true  
strip = true  # Automatically strip symbols from the binary  

[profile.release.build-override]  
opt-level = 3  
codegen-units = 16  

[target.'cfg(target_os = "linux")']  
# linker = "wild"  
# rustflags = ["-Clink-arg=-melf_x86_64"]  
linker = "clang"  
rustflags = ["-Clink-arg=--ld-path=wild", "-Ctarget-cpu=native"]  

target-dir = "<something>/cargo/target" makes it such that instead of each rust project having a separate target dir, you have same target dir for all projects. It can lead to some problems (essentially only 1 cargo compile can work at a time, and some more, but likely do not want to compile multiple projects together anyway as each crate is compiled in parallel as long as that is possible). it repeats a bit of what sccache is doing (reusing build files), but this makes it such that if same version of crate is used elsewhere, it will not even require a recompile (which sccache would have made faster anyway), but this way storage use is reduced as well.

other than that, you may see i have done added option to perform lto and strip on release builds (will make compile times even longer, but you can get a bit more performance out). I have also changed linker (default is gcc), and i use wild as linker (and wild currently requires clang on x86 stuff), it can also be a tiny bit faster. try to see if you need it or not, as lto is no silver bullet (it can reduce performance, but even in worst cases it is within 2-5% of without, but in best cases it can be more). and just generally check config params for cargo debug and release profiles (play around codegen units, i think default is a higher).

for cookies, you can try to open devtools, and then go to network tab, and there find the pdf file, and then right click, and you will find an option something in lines of ‘copy as/for cURL’, copy that, and paste somewhere. repeat exercise for some other file. this should give you some pattern as for how to make a query. it most likely just needs a bearerauth/token in header cookie, or something alike that.

in this case try to fetch a list and then fetch your cookies from browser, and use curl and scripting to fetch stuff.

try something in lines of

wget -r -np -k -p "website to archive recursive download"  

may work, but in case it does not, i would download the the page html, and then filter out all pdf links (some regex or grep magic), and then just give that list to wget or some other file downloader.

if you can give the url, we can get a bit more specific.

what does i0 even mean, like what is the sign even for

reason for them not appearing is that xmpp is a largely relaxed platform, that is, all implementations are not equally strict. some may implement certain extensions, others may implement other. encryption (omemo) is a common one that most implement, but then client (the user apps like gajim) may or may not implement them correctly, or they may have a fallback (first communication between 2 clients maybe is not encrypted), and other different problems with encryption being flaky (firstly, it is not perfect forward secrecy, it is a bit prone to failure (messages unable to decrypt), etc.), hence it is not recommended much.

gives me a good reason to say why i do not use bash

I am interested in it, because i have 3 package managers, arch, uv and cargo (binstall) so this covers me well hopefully.

Did lennart leave microsoft? Probably a good thing in general for linux (it definitely was wierd that lead for systemd was working at microsoft)

barely booting, but that is like one of the hardest step

I personally do cc0 (though i do not have much published). i can not really be bothered to do proper licensing, and my prefered license (wtfpl) is not considered good (by admins, because it has the f word , boo hoo).

in bash if it happens, it often means i have something wrong in most recent closed loop, which may or may not have closed prorperly, somethign similar with python.

i had no idea about this either, thanks for telling. I have almost no idea about server stuff.

Thank you for telling that, I absolutely had no idea about that. In my mind, it has been a almost brute force reverse engineering effect, with some help from some documentation (for example, reference metal docs) or having some open source stuff for apple stuff (if that even exists).

regarding bootloader, is it not the case that bootloader just checks for signature of os, and it does not allow you to boot anything else. I did not mean that having a bootloader unlockable means having docs, but as i get it, the general approach to get android image working is to load a gsi (generic system image), if that does not work, we swap kernel or some other system stuff from available os images (which are closed black boxes mostly). now if we can not even boot a gsi (or some other android tree for lineage os), then there is no hope in running anything. and even if gsi runs, that may still have broken stuff (eg, camera or wifi, which i know are some of common culprits).

if i am not wrong, boot process on non x86-64 is not standardised (no obivous uefi independent of os or setup). this genuinely limits the distros one can find, and mostly first party support is all you get. when first party does linux (raspberry pi or other sbcs), it is fine, and often their boot can be “used” by other third party distros (assuming license allows that). if first party does not, there is no way to get work done. something like android - if you get first party unlockable boot lock, you can hope for custom roms, without that, its playing darts where board is invisible. with apple mac, enough people had dart boards that random trial (and recovery processes) allowed them to get in. with qualcomm stuff, there is some first party support (and some second party support from nvidia who use qualcomm cpu for their servers) but qualcomm graphics is still a issue (first party support is very slow) and not enough third party interest (not enough people have qualcomm laptops for dartboards)