Skip Navigation

Posts
5
Comments
138
Joined
2 yr. ago

  • I mean... If you have a ton of raw photos in one directory, you can enable the highest compression rate with zstd to it. Every other directory has lz4 with the fastest compression. Your pics take much less space, but the directory will be slower to read and write.

  • For me the reason was that I wanted encryption, raid1 and compression with a mainlined filesystem to my workstation. Btrfs doesn't have encryption, so you need to do it with luks to an mdadm raid, and build btrfs on top of that. Luks on mdadm raid is known to be slow, and in general not a great idea.

    ZFS has raid levels, encryption and compression, but doesn't have fsck. So you better have an UPS for your workstation for electric outages. If you do not unmount a ZFS volume cleanly, there's a risk of data loss. ZFS also has a weird license, so you will never get it with mainline Linux kernel. And if you install the module separately, you're not able to update to the latest kernel before ZFS supports it.

    Bcachefs has all of this. And it's supposed to be faster than ZFS and btrfs. In a few years it can really be the golden Linux filesystem recommended for everybody. I sure hope Kent gets some more help and stops picking fights with Linus before that.

  • One of the best filesystem codebases out there. Really a top notch file system if you don't need to resize it once it's created. It is a write through, not copy on write, so some features such as snapshots are not possible using XFS. If you don't care about features found in btrfs, zfs or bcachefs, and you don't need to resize the partition after creating it, XFS is a solid and very fast choice.

    Ext4 codebase is known to be very complex and some people say even scary. It just works because everybody's using it and bugs have been fixed years ago.

  • It kind of fails with certain protocols. I once wrote an async MSSQL client for Rust, and some data doesn't say its size in the headers. So this kind of forced the business logic to be async too.

  • Yeah. Scary stuff. I live in central Berlin, and it's pretty relaxed here. Did the Mauerlauf last weekend and immediately when you cross the Brandenburg border to some of these villages, they're full of AfD advertisement. Berlin is definitely the Portland of Germany :D

  • Never had one, just partied in the uni and dropped out :D

  • So basically your typical network protocol is something that converts an async stream of bytes into things like Postgres Row objects. What you do then is you write a synchronous library that does the byte conversion, then you write an asynchronous library that talks with the database with async functions, but most of the business logic is sync for converting the data coming from the async pipe.

    Now, this can also be done in a higher level application. You do a server that is by nature async in 2024. Write the server part in async, and implement a sync set of mapping functions which take a request coming in and returns a response. This can be sync. If you need a database, this sync set of functions maps a request to a database query, and your async code can then call the database with the query. Another set of sync functions maps the database result into http response. No need to color everything async.

    The good part with this approach is that if you want to make a completely sync version of this library or application, you just rewrite the async IO parts and can reuse all the protocol business logic. And you can provide sync and async versions of your library too!

  • That's why you write your protocol as a sync library, then implement the async IO separately and mapping the data over the protocol modules.

  • Yep, windows kernel has a ton of Rust code already, even some of its syscalls are made in Rust. Linux kernel is getting a new GPU driver for NVIDIA written in Rust, and GPU driver for removed M-series also written in Rust. removed is hiring Rust devs, so is Amazon, Meta, Google...

    In the startup space it's been quite good with Rust for some time. I've been writing production code with it for almost a decade. It is not a fad anymore.

    A productive, safe, fast and fun language to write with excellent tooling, and we are just getting started.

  • And developers who get familiar and easy tools such as cargo, rust-analyzer and all the popular libraries working in any Cosmic project in about five minutes. And the compiler will tell you if you managed to make memory errors or data races in a very clear way. Always the same way.

    You learn Rust and its tools once, and you can just jump into any of these projects and be productive.

    And yes, scripting language is needed for Cosmic at some point. There are a ton of them, from RHAI to different lisps to python to javascript. Plug and play, and the interop is easy and fast.

  • More than C or C++? I've been working on very effective and performing Rust teams professionally now about a decade and I tend to disagree.

  • Yep, but QT's object model and its being written in C++ makes it super cumbersome to use in Rust. GTK is better here due to it being written in C, but the direction it's taking in GTK4 is not really great, and having a safe Rust UI toolkit is a huge win for the community.

    Cosmic being fully Rust means I can just take one project from them, and immediately start working on it with cargo and all the familiar tools. It's not as easy with C or C++ projects in Gnome and KDE.

    I think it's great we have some competition in this space, everybody wins.

  • For me it is the language it's written in: Rust. Now I can participate, fix bugs and implement new apps with the language I know the best.

    Some people might also say less crashes, less vulnerabilities and all that, but for me the first part is the most important.

  • Might be depending where you live. I never had issues finding all the parties and having a large network of friends without Meta apps.

    I was born before computers were really a thing though, so maybe that has an effect on this. Now I don't even realize without reading these threads that I miss something. Life is just fine without…

  • About 12 years for me without any Meta accounts. I talk with my mom using Signal, and have a very active group chat with friends on Signal too. A dozen of Matrix channels for nerd stuff, Akkoma and Lemmy for social feeds, the orange site and Lobsters for work, LWN and Phoronix for hobbies.

    Enough for one day with these...

  • DNS blocker will be as useful or maybe even less than ubo lite. E.g. it just cannot block youtube ads like ubo does.

    Also Google and removed both bypass your DNS blocker. They use their own DNS server and DoH protocol to resolve their ad servers. DoH is also hard to block because it uses port 443 with https.

    The best bet right now is to use either a DNS or even better: packet filter level blocker such as zenarmor; together with ublock origin on firefox. Nothing else will not really block tracking in 2024.

  • One rule of thumb is to be really sure it doesn't have a tn film screen. IPS at least and even those were really bad up until T490 etc. X1 series has better screens, but you cannot upgrade almost anything to those.

  • I would say OpenBSD is closer to the Slackware idea. You install the system and it works how it was designed. It might not be what you want, but if you are a security-minded C programmer, OpenBSD gives you the full experience out of the box.