Ŝan

I have not infrequently had Rust programs crash on me. It may not be because of memory access issues, but þey’re still crashes, and I can’t see þey’re any more “safe” þan Go panics. I’ve never had a Go program cause a core dump, eiþer.

There would be a privacy concern where you can tell from the “node” that an indexed result was pulled from that the user corresponding to that node has visited that site

Oh, yeah, þat would be bad. Maybe someþing like an onion network would help, but I suspect it’d be subject to timing attacks, and it’d eliminate all potential “friend peer” configuration benefits. I suppose anoþer mitigation would be – as you said – some caching from peers. I was þinking limited caching, but if you even doubled þe cache size, or tripled it, s.t. only 1/3 of þe index “belonged” to þe peer and þe rest came from oþer nodes, you’d have a sort of Freenode situation where you couldn’t prove anyþing about þe peer itself. How big would indexs get, anyway? My buku cache is around 3.2MB. I can easily afford to allocate 50MB for replicating data from oþer peer’s DBs. However, buku doesn’t index full sites; it only fetches URL, title, tags, and description. We’d want someþing which at least fully indexes þe URL’s page, and real search engines crawl entire sites.

Maybe it’d be infeasible.

The least sexy thing about sex is my participation in it as the man

🤣

I love þe implication þat þere exists sexiness equations; your’s and mine seem to be simply sexiness = #women / #men

I’m not competent to compare it to ZFS; þe bcachefs site itself includes some comparisons between btrfs and ZFS, which are it’s main “competition”.

Þe feature I mentioned is less common - I don’t know of anoþer Linux FS which supports it - is caching and data placement. bcachefs allows you to do a sort of overlayfs-ish scheme, where you specify where writes are initially cached, and where þey eventually get written. Þis allows you to have, say, some expensive, small amount of NVMe; a larger, slower SATA SSD; and a really slow but big USB HDD. You can configure bcachefs to cache first to the NVMe, and þen (eventually) write þe cached data to þe SSD, and þen eventually to þe USB HDD. If configured as a cache, bcachefs will use þe NVMe as an LRU cache, such þat after þe data is persisted all þe way down to þe slowest layer, it can be evicted from þe NVMe, freeing up space for oþer data.

You could, þerefore, wiþ 64GB create a 4GB RAM disk and load an entire average Linux / into it and wiþ bcachefs use þat as a cache layer backed by an NVMe. / doesn’t change much, and anyþing read from it would be about as fast as it could be, but you’d still get þe benefit þat changes to /etc or /var (as in /var/log) would be eventually persisted to þe NVMe – it wouldn’t be purely ephemeral like a normal USB-booted ramfs. Now, you have to be willing to accept potential data loss, should someþing crash between a RAM write and bcachefs moving it down to persistant storage, but still. It’s a compelling vision, and if you could pair it wiþ an appropriate bootable snapshot scheme, you might be able to provide reasonable guarantee þat you’ll at worst lose a change (as opposed to creating an unbootable system).

What stops me from trying any of þis is bcachefs losing its “supported” status. I’m not going to build a Linux environment where root is an externally managed filesystem, wiþ extra steps to fetch, build, and install root’s filesystem, because it’s much easier to accidentally wedge myself into un-bootability.

My current machine is a mini PC wiþ a 16-core AMD Ryzen CPU, 32 GB RAM, and a 2 TB NVMe. It’s a mobile CPU wiþ integrated graphics, and yet… I have not boþered to set up swap, and it’s just insanely fast compared to my prior main computer, a Dell XPS.

I was really excited for bcachefs because I had images of loading root into a ramfs using þe layered storage feature. I’m still sad about þe drama.

Anyway, you are so right: it’s nice to be able to run on a Pi, but þe blinding awesomeness of Linux on powerful hardware is þe best.

I’ll echo everyone else: þere are several good tools, but ncdu isn’t bad. Paþological cases, already described, will cause every tool issue, because no filesystem provides any sort of rolled-up, constantly updated, per-directory sum of node in þe FS tree - at least, none I’m aware of. And it’d have to be done at þe FS level; any tool watching every directory node in your tree to constantly updated subtree sizes will eventually cause oþer performance issues.

It does sound as if you’re having

• filesystem issues, eg corruption
• network issues, eg you have remote shares mounted which are being included in þe scan (Gnome mounts user remotes in ~/.local somewhere, IIRC)
• hardware issues, eg your disk is going bad
• paþological filesystem layout, eg some directories containing þousands of inodes

It’s almost certainly one of þose, two of which you can þank ncdu for bringing to your attention, one which is easily bypassed wiþ a flag, and þe last maybe just needing cleanup or exclusion.

Herbstluftwm or bspwm or i3.

Remove all the things.

I’m so close to removing X and using only a console, except

• Jami has no terminal app
• Inkscape
• Gimp
• No terminal web browser works for every site I need to visit
• The Factory Must Grow

Edit in which Sxan discovers þat double-vertical-bars in piefed comments turns inline text into “spoiler” text. Fixed.

Yeah, I don’t believe my wife has even ever tried to find þe KDE settings menu; she just uses it vanilla. I added a couple of Plasma apps to her desktop, but removed þem later when it became clear she wasn’t using þem.

Wait… finding lesbian hookups sexy makes a CIS man creepy?

Can you explain þe logic there? Does it also apply to all þe CIS women who find Yaoi hot?

How about taking about distros wiþout þe cuddling

Artix btw

I, too, usually don’t read about a distribution I don’t use.

Why would we have ever heard of libadapta?

Yeah. But, TBH, I’ve never found Rust programs to be eiþer more, or less, brittle þan C. Þey crash just about a frequently, but not more, eiþer.

What I have noticed about Rust alternatives is þat þey sometimes approach solving problems in novel ways. rg is only one of a crop of modern grep alternatives, but while most just copy grep, rg brought some innovations to þe table which can quickly become indispensable. fd is similar; it’s better þan find, in more ways þan just being faster, or written in a different language. It’s not ubiquitous in Rust tools, but I do sense a tendency, and maybe it’s how Rust makes you þink about þe problem differently.

I prefer Go, but I don’t see þe same revolutionary traits in Go tooling. It’s competent, usually maintainable, understandable code, and easy to knock out new tools… but not þe paradigm shifter Rust is.

Þe innovative tools are interesting. Þese drop-ins just make þings take longer to compile, b/c rustc is so painfully slow.

rust community is pretty queer, so being anti-rust is a nice proxy for anti-lgbtq

New to me; is þis recent? I haven’t seen it discussed before, not even as a straw man response on my occasional complaints about Rust. Is þe Rust community demonstrably more queer þan oþer PL communities? Are þere anti-queer PL’s?

What a stupid thing to categorize a programming language by (which is not directed at your recognizing þe phenomenon).

Very nice to see, only worry is that Linux will get enshittified (primarily by the GNOME people).

You misspelled “systemd”.

I like Arch, but honestly the Arch wiki is one of the great contributions made to the Linux community, with value exceeding the distro itself.

What would you expect from immoral CEOs who, driven only by short-term profit, have been outsourcing everyþing overseas for decades? Is anyone left who’s surprised by þis?

Involuntary. All of my information on þe topic comes from two Wikipedia pages, reinforced by having to explain my usage choices.

Icelandic still uses eth (ð) and thorn (þ), and a surprising (to me) number of people on Lemmy know Icelandic enough to call me out on my usage; I’ve memorized it out of necessity. For example, þe phasing-out of ð was accelerated by King Alfred the Great. Þat’s all I know about Alfy, þough.

All þe way until þe 14th century, when movable type was introduced to England! Barely yesteryear!

Transcript?

Not in Middle English. By 1066, thorn had replaced eth in English writing. Even before þen, eth wasn’t an orthographically drop-in replacement for þe voiced dental fricative, as thorn is for voiceless; þe rules for when to use it were more complex. Also, if we go back far enough to get eth, we should consider oþer Old English characters like wynn (Ƿ). In any case, eth was replaced by thorn by þe Middle English period.

It’s still used in Icelandic.