I really don't understand this take.
A script that installs all required dependencies is fine if and only if you are dedicating a machine to immich. It probably requires some version of node, with possibly hidden dependencies on some python, it uses ffmpeg, so all related libraries and executables need to be there. You then have a couple separate DBs, all communicating together.
Let's not talk about updates! What if you're skipping versions? Now your "simple install script" becomes a fragile behemoth.
I would NOT consider this if it was non docker-native.
Plus, I don't have a server with enough resources for a lot of VMs, with all of their overhead and complications, just to have one per service.
Nowadays there are many ways to run a container not just the original docker.com software, and you can do that on pretty much any platform. Even Android now!
I've never understood it either. I still deploy some things into their own respective manual deployments but for lots of things having a pre-made docker compose means I can throw it on my general app VM and it'll take 5 seconds to spin up and auto get HTTPS certs and DNS. Then I don't lose hours when I get two days into using something and realize it's not for me.
Also have you read some of the setup instructions for some of these things? I'd be churning out 1000 lines of ansible crap.
Either way since Proxmox 9.1 has added at least initial support for docker based containers the whole argument's out the window anyway.
Me neither. Docker is the platform agnostic way to deploy stuff and if I maintained software, it is ideal - i can ship my environment to your environment. Reproducing that yourself will take ages, or alternatively I also need to maintain a lot of complex scripts long-term that may break in weird ways.
These things are a proxmox home lab user's lifeline. My only complaint is that you have to change your default host shell to bash to run them. You only have to do that for the initial container creation though.
I truly want to try it, but these lines give me the heeby jeebies:
You hereby grant to us, our affiliates and our third party partners (“SPRING Parties”) an unconditional, irrevocable, non-exclusive, royalty-free, sublicensable, transferable, perpetual and worldwide license, to reproduce, use, and modify Your Content in connection with the provision and improvement of the Services and its underlying technologies, as well as for the SPRING Parties' respective business operations, in each case, to the extent permitted by applicable laws.
Which means they own everything that happens on trae and will use it for training, and then:
You represent and warrant that any names, slogans, trademarks, logos and other designations you use in association with Your Content are owned by or duly licensed to you. You hereby grant SPRING Parties a non-exclusive, royalty-free, perpetual, transferable, sub-licensable, worldwide license to use, modify, reproduce, display, and distribute your relevant names, slogans, trademarks, logos and other designations on the Services for the purposes of operating and providing the Services to you.
Which means that anything you don't own and put on trae will automagically grant them a licence to use it.
Me too, when reading "open source" I was expecting some design docs or the like.
Aside from the general confusion of the website, I haven't been able to find some of the most important information. For example, there's no diagram or immediate explanation of the general working principle and airflow path. The heat exchanger itself is published only as-is for those designs, while the author writes that he uses a custom python script tuned for the design size and his 3d printer to generate it.
When i saw this I immediately thought of studying it and reuse some of its designs for my custom use case, which does not appear to be currently possible.
At first glance it appears to be "open source" in the sense that you can buy it, but if and when something breaks you can print/reorder it easily.
There's no concept of "server" or "Change lobby" on Apex or other Battle royales.
You just queue up for a game, which lasts ~20 minutes. As you are in a 3 player team if you disconnect from the game you get a temp ban penalty, since that also degrades other players experience. So there's no disconnecting freely once a game has started.
Now imagine you're playing for 10-15 minutes just to die without really having any chance. That gets frustrating, really quickly, since winning is close to the only "reward" you get from playing the game.
It's not like a classic COD or Battlefield game, where you can feely leave or join any game/server. Once you're in you're somewhat committed, and you have no control over where or with whom you're playing against.
I have to disagree, k8s is extensively documented and the reference docs and APIs are easily accessible.
K8s at its core is a customizable, extensible, dynamic API server, with a focus on containerization.
It's built with scale and customization in mind, you're not supposed to use it only for running a few containers. I've worked for people that use it to manage VMs with custom controllers. You can change pretty much anything and fit it to your needs. All this with defined, somewhat opinionated sane defaults and conventions
I think that's not something that can be avoided, unfortunately.
Any number of things could cause a train to suddenly stop. A mechanical failure, derailment, collision, a wagon could get detached...
On roads we have millions of vehicles, carrying on average a very small amount of people, around 1.5.
For efficiency sake we have accepted the risk of staying within reaction distance instead of stopping distance between vehicles.
It is a tradeoff between the safety of lives on board and traffic requirements that is relatively easier to accept when the average number of people involved is low against massive speed and efficiency gains.
The same cannot be said for trains though. Modern trains carry upwards of 1000 passengers, often at high speeds and without all of the safety and retention systems built into modern cars.
Having one or multiple trains with this large amount of people onboard be involved in a sudden catastrophic accident is possibly not worth the efficiency gained by thess than one minute separation.
Unfortunately we cannot just think about a normal scenario of simple deceleration
> On roads we have millions of vehicles, carrying on average a very small amount of people, around 1.5. For efficiency sake we have accepted the risk of staying within reaction distance instead of stopping distance between vehicles.
No. Unsafe drivers have illegally decided this, but in most jurisdictions it is your responsibility to stop your vehicle short of the one in front of you. You should be maintaining stopping distance from your vehicle to the one in front.
> You should be maintaining stopping distance from your vehicle to the one in front.
I am not so sure. In Germany, for example, the minimum required distance to the car in front of you is "speed in km/h divided by 2 in meters". So for 100 km/h, you are required to keep a minimum distance of 50 meters. I very much doubt that you can stop a car going 100 km/h within 50 meters.
You do t need to stop a 100 km/hr car in 50 meters because, barring that sudden brick wall appearing ahead of the car in front of you, they’re not stopping in 50m either.
The 50m is the reaction buffer, not the stopping buffer.
It’s also prudent to give more leeway to vehicles you can not see around to avoid the large truck swerving to avoid the refrigerator that just fell out of the truck in front of them problem.
That's interesting, in Belgium I think it's "2 seconds", or at least that's what was promoted recently on the radio.
You should be able to sing "Last night a DJ saved my live", which is a bit more than 2 seconds. I liked that, because it's one you can actually test for while driving.
I find it a lot harder to estimate 50m while driving at 100km/h
Not really. In my country, at least, it is explicitly stated in driving theory manuals to maintain at least one reaction distance between the car in front of you.
For a car traveling at 100Km/h the stopping+reaction distance would mean more than 130m, which is a quite large and possibly impractical for higher traffic scenarios.
Maybe one of the few upsides of this tech is the customizability.
Sure, you can get a prefab house built in a week or less if you try, but it's going to be constrained by the prefab shape and layout, even with modular blocks there are still design constraints, like with https://www.wikihouse.cc.
As seen in other environments, 3D printing lets anyone design and build for their own use case. People are not all about practicality, they want to like their environment too and being able to bring up your house exactly the way you like it is great.
> 3D printing lets anyone design and build for their own use case.
That may be the case but fundamentally buildings are built to a code, which uses a design pattern (GoF book is literally inspired by architecture), so is repeatable. Customers will ask for bespoke features but none of that scales or even requires 3D printing. And the inventors, so far, are trying to woo investors by suggesting this tech is cheaper than traditional construction and/or scalable. And it so far it hasn't addressed any of that.
