• 0 Posts
  • 153 Comments
Joined 2 years ago
cake
Cake day: June 18th, 2023

help-circle





  • Perfect explanation.

    Thank you, I try. It’s always tricky to keep network infrastructure explanations concise and readable - the Internet is such a complicated mess.

    People like paying for convenience.

    Well, I would simplify that to people like convenience. Infrastructure of any type is basically someone else solving convenience problems for you. People don’t really like paying, but they will if it’s the most convenient option.

    Syncthing is doing this for you for free, I assume mostly because the developers wanted the infrastructure to work that way and didn’t want it to be dependent on DNS, and decided to make it available to users at large. It’s very convenient, but it also obscures a lot of the technical side of network services which can make learning harder.

    This kind of thing shows why tech giants are giants and why selfhosted is a niche.

    There’s also always the “why reinvent the wheel?” question, and consider that the guy who is selling wheels works on making wheels as a full-time occupation and has been doing so long enough to build a business on it, whereas you are a hobbyist. There are things that guy knows about wheelmaking that would take you ten years to learn, and he also has a properly equipped workshop for it - you have some YouTube videos, your garage and a handful of tools from Harbor Freight.

    Sometimes there is good reason to do so (e.g. privacy from cloud service data gathering) but this is a real balancing act between cost (time and money, both up-front and long-term), risk (privacy exposure, data loss, failure tolerance), and convenience. If you’re going to do something yourself, you should have a specific answer to the question, and probably do a little cost-benefit checking.


  • But if I’m reading the materials correctly, I’ll need to set up a domain and pay some upfront costs to make my library accessible outside my home.

    Why is that?

    So when your mobile device is on the public internet it can’t reach directly into your private home network. The IP addresses of the servers on your private network are not routable outside of it, so your mobile device can’t talk to them directly. From the perspective of the public internet, the only piece of your private network that is visible is your ISP gateway device.

    When you try to reach your Syncthing service from the public internet, none of the routers know where your private Syncthing instance is or how to reach it. To solve this, the Syncthing developers provide discovery servers on the public internet which contain the directions for the Syncthing app on your device to find your Syncthing service on your private network (assuming you have registered your Syncthing server with the discovery service).

    This is a whole level of network infrastructure that is just being done for you to make using Syncthing more convenient. It saves you from having to deal with the details of network routing across network boundaries.

    Funkwhale does not provide an equivalent service. To reach your Funkwhale service on your private network from the public internet you have to solve the cross-boundary routing problem for yourself. The most reliable way to do this is to use the DNS infrastructure that already exists on the public internet, which means getting a domain name and linking it to your ISP gateway address.

    If your ISP gateway had a static address you could skip this and configure whatever app accesses your Funkwhale service to always point to your ISP gateway address, but residential IP addresses are typically dynamic, so you can’t rely on it being the same long-term. Setting up DynamicDNS solves this problem by updating a DNS record any time your ISP gateway address changes.

    There are several DynDNS providers listed at the bottom of that last article, some of which provide domain names. Some of them are free services (like afraid.org) but those typically have some strings attached (afraid.org requires you to log in regularly to confirm that your address is still active, otherwise it will be disabled).








  • They are, it just takes time to update, since it gets sent over whenever the computer gets updated.That’s why Tom Paris was annoyed that the Voyager’s replicator didn’t have his preferred tomato soup ready. It was scheduled to be loaded onto the computers on Tuesday.

    Patterns might be portable on storage devices, but that doesn’t necessarily mean they’re cross-platform, especially cross-species/technology, or maybe it would require a technical specialist to convert the pattern between systems.

    I can absolutely see this being a thing in Star Trek life. You find specific versions/recipes that you like and save them to a personal data storage device, and then when you transfer to a new command you put in a request with the local IT department to have your recipes loaded into the replicator system, which takes some time because they have to review them for safety (no malicious insiders uploading weapons labeled as “grandma’s chicken soup”) and maybe convert the pattern to work on the local replicators. There’s a support ticket queue for that, submit your files and take a number, we’ll get to you when we can.

    You can write the pattern yourself, but it is easy to get them wrong (Janeway managed to have it consistently produce charcoal).

    Absolutely, or probably try to arrange a new meal pattern using information on previously scanned & stored items. But yeah, it would require some specific knowledge and skill to get right. In the present, you can download lots of 3D-printable objects from the Internet, or if you know how to model you can design your own - the second is a lot more complicated. Most people would probably just use existing replicator patterns.


  • So, I’ve been thinking about this and finally realized I need to RTFM:

    lets say, the materials are all scanned down, and they just tile them to fill in what ever part you’re trying to fabricate. lets say they’re 1 cm3 cubes of materials. sure, the computer could tile those cubes digitally, and then cut them back into the shape you needed. But, how do you handle the gaps between the blocks? you could fill them with procedurally generated molecules/atoms, right?

    So, kind of. Page 91 says “The chief limitation of all transporter-based replicators is the resolution at which the molecular matrix patterns are stored” and “extensive data compression and averaging techniques are used” which results in “single-bit inaccuracies”.

    I think the implication is that objects are reproduced in essentially arbitrary blobs/fields which are of uniform molecular patterns (e.g. the flesh of an apple being distinct from the skin, the stem, or the seeds) but not in blocks/voxels.

    you wouldn’t need to scan materials. You can just model the atoms and procedurally generate the bonds, and then tell the replicator how to print the damn thing.

    The problem is that specifying the exact molecular structure of something complex like, say, a soufflé, would be extremely difficult and time-consuming to do manually, and probably it still wouldn’t taste or feel right when you ate it - imagine trying to reproduce a Monet by specifying manually in lines of code where each drop of each color of paint was placed on the canvas, without being able to see the finished product until you hit “print” - it would take you years, maybe decades to get it right. Getting the texture and flavor of a grilled chicken breast right would be insanely difficult to do by specifying each atom in the whole structure from scratch. Scanning a real one would be a much easier path to acceptable reproduction, hence: “a quantum geometry transformational matrix field is used to modify the matter stream to conform to a digitally stored molecular pattern matrix.” (Treknobabble but the point being that a thing is scanned and the pattern stored digitally for later reproduction)

    we know what an iron atom is and can model it.

    So yes, especially for industrial applications such as your example of a uniform steel bar, but for things with complex chemistry and physical structure it’s too difficult to specify from a “first-principles” perspective and get something that you actually want to eat.

    Maybe a higher-grade, specialized food replicator could generate food items procedurally as you suggest, or maybe it would just have a group of stored patterns for the same item that it would randomly select from (probably easier) so that the output isn’t always the same, but probably the standard Starfleet model doesn’t do this as it would be more of a luxury feature.


  • It’s not replicating unless you’re telling it to make a copy of something that already exists

    It is though. The replicator stores static patterns in a similar way to the transporter - they’re basically the same technology. To create a new replicator pattern (e.g. a cup of tea) the original cup of tea is dematerialized and the pattern saved for future reproduction. This also explains why some people complain about eating “the same replicated meal” over and over - it’s literally true, the replicator replicates the exact same cut of chicken cooked the exact same way with the exact same spice blend every time, because it’s reproducing a copy from a file. Even if it’s a perfect chicken dinner, it’s the same one you’ve had hundreds of times before.

    This also explains why every replicator in the universe can’t just reproduce anything at any time. Different models have different sets of patterns available. A restaurant-grade model (like Quark’s) might be distributed with a menu of meals prepared by chefs with good reputation and have more space dedicated for storing food patterns, whereas the Starfleet model has a menu prepared by a committee of Starfleet nutritionists (decent, healthy, but not gourmet) and also uses some pattern storage for utility items like uniforms and tricorders &etc (it’s general-purpose, not specialized for food, so its food reproduction is comparatively lower quality than Quark’s).

    Presumably the patterns are not easily interchangeable/distributable - different file formats, different scanner resolution, maybe different output options (canonically some materials are more difficult to replicate than others, so might require a specialized replicator). Quark’s replicator, being Ferengi, is probably proprietary and requires purchasing new patterns only from the original manufacturer to increase the variety.


  • They should be powered on if you want to retain data on them long-term. The controller should automatically check physical integrity and disable bad sections as needed.

    I’m not sure if just connecting them to power would be enough for the controller to run error correction, or if they need to be connected to a computer. That might be model specific.

    What server OS are you using? Are you already using some SSDs for cache drives?

    Any backup is better than no backup, but SSDs are really not a good choice for long-term cold storage. You’ll probably get tired of manually plugging them in to check integrity and update the backups pretty fast.