They say 2 generations need to pass between large wars reoccurrence on the planet. 1st generation that largely participated in the war will never do it again, whatever the cost. 2nd generation gets very strong message from 1st generation about true horrors of war, so it is much more careful. 3rd generation looses that direct connection and feedback from veterans, grandfathers, etc... so naturally they think of war as something that is minor inconvenience at best... And through the ignorance of 3rd generation - here we come. 80 years have passed since the last world war. Sadly, our time is up.
There is also another differentiator - companies buy insurance for all employees (i.e. in "bulk") when if everyone were to buy it privately, insurance companies will have to sell it in "retail". As is always the case with any business - bulk customers have preferential treatment, lower prices, better terms, you name it. Retail always pays it in full. While current employer based insurance model is broken, I don't think goin "full retail" will change the situation much. We'll end up in a situation similar to wireless service market - 3 major players with overpriced plans and lots of cheap MVNOs that stop having any coverage 5 miles down the highway.
I think there is a difference between features of the editor and editing method. Following your logic - if there is already Notepad, why create TextPad, Atom, Word, VSCode etc...
A couple of times i found myself clicking on various text labels just to see if it is a title or a button. All these flat minimalist designs are a step in a horribly wrong direction.
I've seen all 4 combinations of "looks like" vs "is actually" {button,static text} on a web app I was once forced to use. Some of the plain text was actually a clickable button (with NO hover effect), and some of the "buttons" (or more precisely, short actionable text with a rectangle around it) were actually just labels. Imagine the word "Order" presented in both styles, and my astonishment when I figured out which one I actually had to click.
To do this right you should also think of backups, updates, and monitoring. Self-hosting is true freedom but doing it right for things like email is akin to running a small business. On the positive side docker makes many things a breeze.
I tried with Docker before and it is not a breeze as you think it is. I tried to use Docker for Calibre-Web and it is a pain to make it work. Because Calibre-Web required to access their database in the filesystem outside of Docker. Docker provided minimal (more of lacking) information of how to expose the filesystem for Calibre-Web to use their database. Calibre-Web cannot create their own database, it relies on Calibre, standalone app, to generate the library that it need to have access to. It took me ages to finally to find a way to expose the filesystem and only provide permission to access that particular library.
I am surprised by this shortcoming of Calibre image. I guess the trade is learning how to install calibre vs. learning how to deal with docker. I'd also agree that even if you use docker and installation is easy - for any self hosted apps you are using for a long enough time you end up learning enough about them to be able to install without docker (and avoid managing docker in addition to everything else).
Calibre does have their "book sharing" solution that are built in the software. However it is more like content server. Calibre-Web is a third-party solution that are not affiliated with Kovid Goyal (creator/main developer of calibre). And Calibre-Web is basically browser version of Calibre without requiring other people to use Calibre to access Calibre-Web. So Kovid did not create this calibre-web image from what I understand.
I find I am more likely to choose it because you don't have to be super experienced in Rust to produce fast, reliable binaries. That is not the case with C/C++.
> you don't have to be super experienced in Rust to produce fast
That's an interesting take. As an old fart, I find Rust's choices new and unfamiliar. I like them, it seems very sound, but the learning curve for people used to C is real.
> ... I'll seriously consider a regular non-ML position.
What about asking for more money at the end? Multi-stage complex interview process eliminates more candidates. Some, like you say, will opt for a developer gig instead, probably because ML wasn't something they were interested in to begin with. That narrows down the list of candidates even more. Either "play the game" and ask for more money or don't play the game at all. Let employers pay extra for polished candidates.
