Poetry/uv is similar to Rust's cargo. You specify your direct dependencies in a TOML file and their version constraints and the tool takes care of the rest.
My understanding is that it's necessary given the current design of the compiler. That doesn't mean it can't be removed at some point.
It would be really nice to be able to define trait impls wherever, and it should be possible.
Don't worry, new research shows all the negatives are made up by big water. You may continue consuming as many cans as you want. Drink verification can to confirm.
Make sure you use a filesystem with snapshots, it'll save a lot of headaches.
And there’s nothing wrong with that
Agreed, it's just nice to know that going in to a massive article like this. Are these reasonable complaints, or are they just justifying a new project for themselves?
There are a ton of options, depending on what you have. In essence, a file server is really simple, you just need a computer with network access with sufficient storage. Here are options, from simplest to fanciest:
- drive plugged into your router - simplest and most ghetto
- drive that supports network access - slightly less ghetto
- buy a NAS - more money and less freedom, but much simpler than DIY
- old computer (laptop, Raspberry Pi, etc) that you have laying around with something like TrueNAS, NAS4Free or OpenMediaVault running on it
- 4, but with a general purpose OS on it (Debian, Fedora, etc) running some kind of file hosting software (samba, Nextcloud, Seafile, OpenCloud, etc)
- 4 or 5, but with new hardware
The costs can vary from free to thousands of dollars, depending on storage and compute needs and how far down the fancy scale you go (note: 3 is more expensive than 4, and comparable to 5).
Everything is running and I'm not making many changes because work got hectic. I have a few projects I'd like to tackle once I get time:
- finish migrating to podman
- get a new drive to test migrating to microos
- get more media to finally eliminate Netflix (SO is still clinging to a few shows)
- find a smaller box for my NAS - currently in a massive ATX box, but I don't want to pay an arm and a leg just for space savings
Here are my reasons:
- no Linux support - Heroic works, why doesn't Epic do what GOG do and revenue share w/ Heroic?
- exclusivity deals, which reduces options outside of EGS
- Epic's anticheat works on Linux, but their own games that use it don't, that's a pretty big slap in the face
I certainly want more competition to Steam, but that competition needs to do something other than exist for me to use it. GOG is that, and if they properly supported Linux, they'd get most of my gaming money. But they don't, so they only get some of it.
Yeah, this probably reads like a Linux fanboy post or something, but I've been using Linux longer than Steam supported it with its client, and I'll still be here if Steam leaves. It's my platform of choice, and a vendor needs to meet me here if they want my business. Valve did, so they get my money. I honestly don't need much, I just need games to work properly on my system.
a way to track them
Yes, that's what I'm suggesting. Injecting some kind of metadata that gets stripped at code gen time would probably work.
worse incremental compilation performance
Would it really be that significant?
without allocating everything on the heap
I'm talking about compile time.
Start with all of the known safe cases (basic types should be fine), then move on to more dubious options (anything that supports iteration). Then allow iterable types but don't allow iterating over a mutable reference. And so on. If it's a priority to loosen up the rules without sacrificing safety, surely some solutions could be found to improve ergonomics.
Or perhaps there could be some annotations to make a reference as "unsafe" or similar instead of just a block. If something is safe in practice but not verifiably safe, there should be a way to communicate that.
You want some annotations to break out of the safe subset of the language
The annotations would indicate that something unsafe is going on, so it's like an unsafe block, but on a reference. That way it's clear that it's not being checked by the borrow checker, but the rest of the application can be checked.
I really liked the idea of an optional, built-in GC w/ pre-1.0 Rust where specific references could be GC'd. If that were a thing in modern Rust (and the GC would only be enabled if there's a GC'd reference included), we could get a lot more ergonomics around things like linked lists.
I take it the 192.168.1 subnet is the family lan?
Why post the same image twice?