zswap is not better than modern zram in any way. And you can set up the latter with writeback anyway.

But that’s not OP’s problem since “swap gets hardly touched” in OP’s case.

The point is compression.

% swapon
NAME           TYPE      SIZE USED  PRIO
/dev/nvme0n1p2 partition   8G   0B     5
/dev/sda2      partition  32G   0B    -2
/dev/zram1     partition 3.5G 1.8G 32767
/dev/zram2     partition 3.5G 1.8G 32767
/dev/zram3     partition 3.5G 1.8G 32767
/dev/zram4     partition 3.5G 1.8G 32767
/dev/zram5     partition 3.5G 1.8G 32767
/dev/zram6     partition 3.5G 1.8G 32767
/dev/zram7     partition 3.5G 1.8G 32767
/dev/zram8     partition 3.5G 1.8G 32767

% zramctl
NAME       ALGORITHM DISKSIZE   DATA  COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram8 zstd          3.5G 293.4M 189.2M 192.5M         [SWAP]
/dev/zram7 zstd          3.5G 282.1M 187.5M   192M         [SWAP]
/dev/zram6 zstd          3.5G 284.6M 189.4M 192.9M         [SWAP]
/dev/zram5 zstd          3.5G 297.8M 197.3M 200.1M         [SWAP]
/dev/zram4 zstd          3.5G 304.9M 202.9M 206.7M         [SWAP]
/dev/zram3 zstd          3.5G 300.7M 201.9M 204.6M         [SWAP]
/dev/zram2 zstd          3.5G 311.3M 207.2M 210.6M         [SWAP]
/dev/zram1 zstd          3.5G 307.9M 210.5M 213.3M         [SWAP]
/dev/zram0 zstd          <not used for swap>

• Use zram devices equal to the number of threads in your system.
• Use zstd compression.
• Mount zram devices as swap with high priority.
• Mount disk swap partition(s) with low priority.
• Increase swapiness:

     sysctl vm.swappiness=<larger number than default>
  

• Use zramctlto see detailed info about your zram disks.
• Check with iotop to see if something unexpected is using a lot of IO traffic.

Okay. I thought for a moment that you and everyone else were not on the same page.

zram file

what zram file?

Forgot to mention that I wasn’t exactly young at the time. We just didn’t have reliable broadband internet back then in my neck of the woods. So I had to download ISOs and save them in a USB thumb drive in a uni computer lab.

Early Mandriva with KDE 3.4 or 3.5 I think, but I can barely remember anything with clarity. It couldn’t have been bad though, since I haven’t used Windows on my own devices since 😉.

From my foggy memory, I think it was good for my then nocoder self, easy to use, stable, relatively lite, and had good looks.

I missed the Mandrake and pre-Fedora Red Hat era, but not by much.

With all the surface false analogies and general lack of solid knowledge in the comments here, I truly hope that at least half of them are LLM generated.

This is cool and lies within my area of interests.

One thing that is not clear is if there will be a way to do playback outside of custom players. If a stream can’t be trivially grabbed, and/or played directly in mpv (via ffmpeg library support or otherwise), this won’t be very useful for me.

It would also be interesting to see how the video streams are encoded, if the GOP size is forced to 1 and it’s all intra frames or not, and if it’s not, how synchronization after recovery (where FEC is not enough) is done.

Hopefully this gets posted again when the code is released.

Good thing we can edit titles here.

This post is very welcome. It’s sure more relevant than many posts made in this instance.

Please continue to post whatever you like, as long as it’s on-topic.

Reads okay for the most part. But I like how we see the same point about AI as a feature in some more serious real-life projects. There, we frame it as “Rust makes it harder for a ‘contributor’ to sneak in LLM-generated crap”.

Didn’t click on your links. But LEA does this move against any network that may offer anonymization. Don’t use Tor hidden services. Don’t go near I2P. Stay away from Freenet…etc. This even includes any platform that is seen as not fully under control, like Telegram at some point.

In its essence, this move is no different from “Don’t go near Lemmy because it’s a Putin-supporting communist platform filled with evil state agents”.

Does any network that may offer anonymization (even if misleadingly) attract undesirable people, possibly including flat out criminals? Yes.

Should everyone stay away from all of them because of that? That’s up to each individual to decide, preferably after seeing for themselves.

But parroting “think of the children” talking points against individual networks points to either intellectual deficiency, high susceptibility to consent-manufacturing propaganda, or some less innocent explanations.

Apologies if I was presumptions and/or my tone was too aggressive.

Quibbling at No Moderation = Bad usually refers to central moderation where “someone” decides for others what they can and can’t see without them having any say in the matter.

Bad moderation is an experienced problem at a much larger scale. It in fact was one of the reasons why this very place even exists. And it was one of the reasons why “transparent moderation” was one of the celebrated features of Lemmy with its public Modlog, although “some” quickly started to dislike that and try to work around it, because power corrupts, and the modern power seeker knows how to moral grandstand while power grabbing.

All trust systems give the user the power, by either letting him/her be the sole moderator, or by letting him/her choose moderators (other users) and how much each one of them is trusted and how much weight their judgment carries, or by letting him/her configure more elaborate systems like WoT the way he/she likes.

Because there isn’t a solution.

This has been discussed and experimented with to death where such networks existed for a long time. Just because you never heard of them or even knew they exist doesn’t mean that they don’t.

See Freenet/Hyphanet and the three approaches (local trust, shared user trust lists, web of trust) if you want to learn something. The second one worked out the best from a performance and scalability point of view compared to the third.

Not only is IPFS not built on solid foundations, offered nothing new to the table, and is generally bad at data retention, but the “opt-in seeding” model was always a step backwards and not a good match for apps like plebbit.

The anonymous distributes filesystem model (a la Freenet/Hyphanet) where each file segment is anonymously and randomly “inserted” into the distributed filesystem is the way to go. This fixes the “seeder power” problem, as undesirable but popular content can stay highly available automatically, and unpopular but desirable content can be re-inserted/healed periodically by healers (seeders). Only both unpopular and undesirable content may fizzle out of the network, but that can only happen in the context of messaging apps/platforms if 0 people tried pull and 0 people tried to reinsert the content in question over a long period of time.

Now that others got all the technicalities out of the way, maybe ChromeOS/ChromiumOS would be something along the lines of what you’re looking for? not that anyone should choose to daily-drive it.

most Rust developers

survey participants != all rust developers

In fact, there is no reason for experienced Rust developers to participate in such surveys at all. I don’t.

Hell, the way the survey results are covered (not just here) tells me that maybe we should push for it to never be done (officially) ever again.

In case the wording tripped anyone, generators (blocks and functions) have been available for a while as an unstable feature.

This works (playground):

#![feature(gen_blocks)]

gen fn gfn() -> i32 {
    for i in 1..=10 {
        yield i;
    }
}

fn gblock() -> impl Iterator<Item = i32> {
    gen {
        for i in 1..=10 {
            yield i;
        }
    }
}

fn main() {
    for i in gfn() {
        println!("{i} from gfn()");
    }
    for i in gblock() {
        println!("{i} from gblock()");
    }
}

Note that the block-in-fn version works better at this moment (from a developer’s PoV) because rust-analyzer currently treats gfn() as an i32 value. But the block-in-fn pattern works perfectly already.

even if he wrote “half”, he would still be wrong, and still suffering from multiple levels of dissonance.