Mama told me not to come.

She said, that ain’t the way to have fun.

  • 53 Posts
  • 16.8K Comments
Joined 2 years ago
cake
Cake day: June 11th, 2023

help-circle


  • sugar_in_your_tea@sh.itjust.workstoSelfhosted@lemmy.worldFirst file server
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    1
    ·
    5 hours ago

    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:

    1. drive plugged into your router - simplest and most ghetto
    2. drive that supports network access - slightly less ghetto
    3. buy a NAS - more money and less freedom, but much simpler than DIY
    4. old computer (laptop, Raspberry Pi, etc) that you have laying around with something like TrueNAS, NAS4Free or OpenMediaVault running on it
    5. 4, but with a general purpose OS on it (Debian, Fedora, etc) running some kind of file hosting software (samba, Nextcloud, Seafile, OpenCloud, etc)
    6. 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).



  • 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.







  • the orphan rule is not worse than what other languages allow

    Sure, but that doesn’t mean it can’t be better.

    Surely the compiler could delay optimizations until the entire project is built, no? Then it knows what implementations exist, and the developer could then decide how to deal with that. Perhaps the dev could decorate the trait impl as overriding all others, overriding one specific impl, etc.

    The orphan rule feels like throwing the baby out with the bathwater.

    You can still trivially violate memory safety without multithreading or concurrency

    Sure, and ideally those cases would be accounted for, or at the very least the dev could annotate each use to turn the borrow checker off for each instance, and that could print something at build time and a linter could flag over it. Unsafe blocks aren’t feasible for everything here.

    A lot of these situations are fine in practice. Give devs the ability to sidestep the rules and take responsibility for the outcome.








  • Here’s my investment portfolio:

    • 70% US - I still think US will outperform, but I’m not as confident anymore; mostly VTI with a small cap tilt using DFSV
    • 30% international - mostly VXUS, with a small cap tilt using DISV

    I think US stocks will take a beating during Trump’s presidency, provided he keeps messing with tariffs, but I think longer term the US will bounce back because we have a very attractive regulatory environment for businesses.