• 4 Posts
  • 101 Comments
Joined 1 year ago
cake
Cake day: June 11th, 2023

help-circle













  • I found it hard to follow despite C# being my main driver.

    Using ref, in the past, has been about modifiable variable references.

    All these introductions, even when following C# changes across recent versions, were never something I actively used, apart from the occasional adding ref to structs so they can contain existing ref struct types. It never seems necessary.

    Even without ref you use reference and struct types, where reference content can be modified elsewhere. And IDisposable for object lifetimes with cleanup.



  • Release must be documented

    It’s not a must [unless you put it into a contract], it’s a should or would be nice

    Many, if not most, projects don’t follow a good, obvious, transparent, documented release or change management.

    I wish for it, too, but it’s not the reality of projects. Most people don’t seem to care about it as much as I do.

    I agree blind acceptance/merging is problematic. But for some projects (small scope/size/personal-FOSS, trustworthy upstream) I see it as pragmatic rather than problematic.



  • I would consider three four approaches.

    1. Commit and push manually and deliberately

    I commit changes early and often anyway. I also push regularly, seeing the remote as a safe and remote (as in backup) baseline and reference state.

    The question would be: Do I switch when I’m still exploring things in the workspace, without committing when switching or moving away from it, and I would want those on the other PC? Then this would not be enough.

    2. Auto-push all local git references into a separate space on the git remote

    Git branches are refs, commit pointers, just like other refs are. And they can be put under arbitrary paths. refs/heads/ holds branches. I can replicate and regularly update all my branches under refs/pcreplica/laptop/*. And then on the other PC, list or fetch those, individually, or all of them, regularly automatically, or manually.

    git push origin refs/heads/*:refs/pcreplica/laptop/*
    git ls-remote
    git fetch origin refs/pcreplica/laptop/*:refs/laptop/*
    

    3. Auto-push the/a local branch like you suggested

    my concern here would be; is only one branch enough? is only the current branch enough?

    4. Remoting into the other system

    Are the systems both online? Can I remote into / connect into it when need be?



  • we should just write the code how it should be

    Notably, that’s not what he says. He didn’t say in general. He said “for once, [after this already long discussion], let’s push back here”. (Literally “this time we push back”)

    who need a secure OS (all of them) will opt to not use Linux if it doesn’t plug these holes

    I’m not so sure about that. He’s making a fair assessment. These are very intricate attack vectors. Security assessment is risk assessment either way. Whether you’re weighing a significant performance loss against low risk potentially high impact attack vectors or assess the risk directly doesn’t make that much of a difference.

    These are so intricate and unlikely to occur, with other firmware patches in line, or alternative hardware, that there’s alternative options and acceptable risk.