• 0 Posts
  • 46 Comments
Joined 3 年前
cake
Cake day: 2023年8月6日

help-circle


  • This would be a great application of btrfs. Copy over the boot-partition directly via cp /dev/nvme{0,1}n1p1 or similar.
    Then, simply add the data partition(s) to btrfs. You can then tell btrfs to migrate all data out of the old partition, and finally remove it. All in a running system.

    I have migrated the rootfs on running systems before using this method, it’s a super clean approach.

    BTRFS also nicely handles the redundancy with its checksums. Usually you can’t fix bitrot between two drives, but btrfs can tell which version is correct. Makes scrubbing easier.






  • I checked the actual code and there is no e2ee, at all.
    It has some of the basic setup stuff, like giving you a recovery file, and messages are seemingly encrypted, but everyone can decrypt everything and the platform has none of the structure to deal with all the issues proper e2e brings.

    As a very simple test: If you write a message in a server, close the tab. Make a new account and open that chat. You can read the message. Meaning anyone can.
    The way actual e2ee does this is it signs messages for anyone in the chat at that moment. Anyone new can’t read old messages unless an old member sends them the contents.

    Also this stuff is buggy in the actual functioning.

    Also it’s full of trackers and weirdly loads youtube for no reason.

    Also it’s full of nazis, the actual state is so much worse than the screenshots shown in the post. The top channels are “4chan” and “wagnersdom”.


  • This one is so generic it let’s you get around any of that very easily.
    You don’t even need to interact with the filesystem, you can just change a cron script or system library and let some other process execute it. Or you can change /etc/passwd to give yourself access to a root user, which iirc is what this dirtyfrag vulnerability proof of concept did.

    You can pretty much write to any file on the filesystem with one syscall (that is not a write syscall) and in a way that does not count as writing in any of the normal ways, so won’t even trigger file change events etc.









  • Flu and corona are both “common cold type” viruses defeating resistance in some way. For coronaviruses that method is stopping the body from building effective resistance by all means possible, so that is why vaccines tend to not work too well.
    For the flu it’s the many variations and its tendency to change further and need new antibodies.
    So I don’t think a specific flu strain is hard to make a very effective vaccine for, but ofc this doesn’t yet solve the flu problem.
    The immense speed at which mRNA vaccines can be developed might improve that in the future, where this here could be one of many steps to get regulatory approval for blanket mrna and actually be permitted to change them at that pace.

    In principle mRNA should let you crank you vaccines for new diseases/flu-strains in under a week. If this can fully stop the flu?.. I doubt it. Whatever does solve it will probably make use of this tech though.



  • Redjard@reddthat.comtoLinux@programming.devsystemd(ont)
    link
    fedilink
    arrow-up
    8
    arrow-down
    1
    ·
    1 个月前

    Try to log the stdout of your services, I dare you.

    openrc is just missing some pretty essential things. I’m not saying to copy journalctl, but at least dump stdout into some tmpfs file by default.

    To have some sane basic logging on hand if a service breaks weirdly or is misbehavingy you’d need to edit that specific service file and restart. And most of the time look up the spec of the specific service command to remove log supression.

    Unlogability alone makes openrc quite a nightmare for a lot of setups. I’ve wasted hours repeadedly that would have been 5min had I gotten the log upfront.