msiemens's comments

Honestly, it's even more funny than I expected

Input: F*ck you

Output:

> I’m not sure we’re aligned on this, so let’s circle back when our priorities are better synchronized.

Alternatives:

> I’ll take that under advisement and loop in the broader team for their perspective.

> Per my previous email, I believe the current roadmap already addresses the core requirements.

> I appreciate your input, but we’ve decided to move in a different direction to better optimize our resources.

> I’m happy to discuss this further once you’ve had a chance to review the documentation I provided.

I know it's this is a rather long tangent and not the main point of the article, but regarding "Docker Swarm over Kubernetes", I've had a ton of bad experiences at my employer running a production Swarm cluster. Among them:

- Docker Swarm and Docker Compose use different parsers for `docker-compose.yaml` files, which may lead to the same file working with Compose but not with Swarm ([1]).

- A Docker network only supports up to 128 joined containers (at least when using Swarm). This is due to the default address space for a Docker network using a /24 network (which the documentation only mentions in passing). But, Docker Swarm may not always show error message indicating that it's a network problem. Sometimes services would just stay in "New" state forever without any indictation what's wrong (see e.g. [2]).

- When looking a up a service name, Docker Swarm will use the IP from the first network (sorted lexically) where the service name exists. In a multi-tenant setup, where a lot of services are connected to an ingress network (i.e. Taefik), this may lead to a service connecting to a container from a different network than expected. The only solution is to always append the network name to the service name (e.g. service.customer-network; see [3]).

- Due to some reason I still wasn't able to figure out, the cluster will sometimes just break. The leader loses its connection to the other manager nodes, which in turn do NOT elect a new leader. The only solution is to force-recreate the whole cluster and then redeploy all workloads (see [4]).

Sure, our use case is somewhat special (running a cluster used by a lot of tenants), and we were able to find workarounds (some more dirty than others) to most of our issues with Docker Swarm. But what annoys me is that for almost all of the issues we had, there was a GitHub ticket that didn't get any official response for years. And in many cases, the reporters just give up waiting and migrate to K8s out of despair or frustration. Just a few quotes from the linked issues:

> We, too, started out with Docker Swarm and quickly saw all our production clusters crashing every few days because of this bug. […] This was well over two years (!) ago. This was when I made the hard decision to migrate to K3s. We never looked back.

> We recently entirely gave up on Docker Swarm. Our new cluster runs on Kubernetes, and we've written scripts and templates for ourselves to reduce the network-stack management complexities to a manageable level for us. […] In our opinion, Docker Swarm is not a production-ready containerization environment and never will be. […] Years of waiting and hoping have proved fruitless, and we finally had to go to something reliable (albeit harder to deal with).

> IMO, Docker Swarm is just not ready for prime-time as an enterprise-grade cluster/container approach. The fact that it is possible to trivially (through no apparent fault of your own) have your management cluster suddenly go brainless is an outrage. And "fixing" the problem by recreating your management cluster is NOT a FIX! It's a forced recreation of your entire enterprise almost from scratch. This should never need to happen. But if you run Docker Swarm long enough, it WILL happen to you. And you WILL plunge into a Hell the scope of which is precisely defined by the size and scope of your containerization empire. In our case, this was half a night in Hell. […] This event was the last straw for us. Moving to Kubernetes. Good luck to you hardy souls staying on Docker Swarm!

Sorry, if this seems like like Docker Swarm bashing. K8s has it's own issues, for sure! But at least there is a big community to turn to for help, if things to sideways.

[1]: https://github.com/docker/cli/issues/2527 [2]: https://github.com/moby/moby/issues/37338 [3]: https://github.com/docker/compose/issues/8561#issuecomment-1... [4]: https://github.com/moby/moby/issues/34384

A few German companies:

- Aldi (supermarket chain), founded by the Albrecht brothers, thus ALbrecht DIskont

- Adidas, founded by ADolf DASsler

- Mercedes-Benz, named by Emil Jellinek-Mercedes after his daughter Mercedes, initially with Daimler which then merged with Benz

- Audi, founded by August Horch. Initially founded as _A. Horch & Cie. Motorwagenwerke Zwickau_, he later lost the rights to the name "Horch". He named his new company "Audi", which is a translation of his name into Latin: in German, "horch" is the imperative for "horchen" (to listen), which maps to "audi" as the imperative for "audire" in Latin

And then there are a just a ton of companies named after their founders (Porsche, Bosch, Siemens, …) but I'm not sure if these count :)

Another recommendatation in a similar vein: The Brady Heywood Podcast's Apollo 13 series [1]. It's almost 6 hours in total, includes a lot of original voice recordings and explains a lot about what's going on in the background. Really worth a listen if you're into podcasts :)

[1] E.g. https://podcasts.apple.com/us/podcast/brady-heywood-podcast/...

After seeing the demos my biggest question is: how will this not lead to people just accepting whatever GitHub Copilot suggests while introducing subtle yet catastrophic errors? Basically, how is this not going to become an alternative to just copy-pasting StackOverflow answers without verification? Especially given the IDE integration…

And to at least partially answer my own question, straight form the FAQ:

> Can GitHub Copilot introduce insecure code in its suggestions?

> There’s a lot of public code in the world with insecure coding patterns, bugs, or references to outdated APIs or idioms. When GitHub Copilot synthesizes code suggestions based on this data, it can also synthesize code that contains these undesirable patterns. This is something we care a lot about at GitHub, and in recent years we’ve provided tools such as Actions, Dependabot, and CodeQL to open source projects to help improve code quality. Similarly, as GitHub Copilot improves, we will work to exclude insecure or low-quality code from the training set. Of course, you should always use GitHub Copilot together with testing practices and security tools, as well as your own judgment.

Basically, they seem to hope that people will either be really careful about the suggested code or have existing code analysis workflows that would catch errors

I brought down production for a project — by running the deployment CI pipeline for already deployed commit. A couple of minutes later, production was thoroughly dead.

Turned out that my coworker had set up the CI process to use a PHP-based zero downtime deployment scheme where each release was deployed into a folder with the commit hash as name and then a symlink was updated to point the web root to this new release folder.

But, critically, he also configured CI to delete old releases at the end of the deployment pipeline - by removing all release folders older than three days. And by re-deploying a commit older than three days, after uploading the code and updating the symlink, the release‘s folder was considered old and deleted at the end of the pipeline, leaving the webserver with an empty directory as web root.

> JSON, which is [...] unambiguous about its types

With the one exception that with floatig point values the precision is not specified in the JSON spec and thus is implementation defined[1] which may lead to its own issues and corner cases. It for sure is better than YAML's 'NO' problem, but depending on your needs JSON may have issues as well

[1]: https://stackoverflow.com/questions/35709595/why-would-you-u...

> Easy and simple are near-universally conflated.

That’s an interesting statement as it doesn’t always work in other languages. In German (my native language) my first instinct was to translate both words as “einfach” which contains both concepts. In fact, in my online dictionary of choice the word “einfach” is the first entry for both “easy” and “simple”. So if Germans conflate these two it might be because of the language they speak :) But more to the point, I’m wondering how universal the distinction between easy and simple is when other languages cannot express that distinction as easily as in English.

I've talked to a couple of homeless people in a large city in Germany and the impression I seems to largely match your assertion. Most people I talked to who are homeless were from eastern Europe who tried to make a better living in Germany but failed. There were also some with drug or alcohol problems or had some sort of mental issues.

But there was also a man who was bullied out of the company where he had worked for 21 years. I guess he didn't see homelessness coming for him. Also there was an older woman who lived in her car because she was forced out of the apartment where she lived for her whole life and she refused to accept moving to a different apartment. She had a reputable job, it was after she retired that all these issues came up. So I guess that even here there is no absolute guarantee that one wouldn't end up homeless.

As the maintainer of a moderately popular project on GitHub I'm torn in this. I often get issues where I try to solve the user's problem and think I have answered the question or provided a solution, but don't get any reply from the reporter when asking if it is solved, sometimes for years. I configured Stale Bot with a IMO generous delay so the user has enough time to at least give a short reply if the issue persists. If it does, I'll gladly add a 'pinned' tag to keep Stale Bot away from it. But in the end the bot just does what I'd do by hand anyway.

If it's configured with a short timeout and with preventing further comments, I totally agree. That's rally annoying. But maybe there are circumstances where it's actually useful.

I guess it depends. I have a German engineering degree and took a business administration course as a part of that. And in one of the first lectures our professor told us that The formal goal of the company is to maximize profit. Which seems to be just a more formal way of expressing Greed is good. But then again, this might be influenced by American business culture…

Did you consider putting the "center" of the detector somewhere other than in the middle of the vector? what would happen if you had 6 before, and 2 after, or 5 before, and 3 after? Another thought I had: for performance reasons, it might be nice to have something more compact than a one-hot vector for each letter. Have you looked at determining sets of characters which have a similar impact on hyphenation, and encoding them together?

These are interesting suggestions! It sure would be interesting to do actual research on how to optimize the hyphenation even more. It also would be interesting to play with the hyperparameters and network architecture to see what impact they have on the hyphenation accuracy. Alas, I'm a student so time is rather scarce.

PS: do you have the extracted list of wiktionary hyphenations sitting in a text file somewhere that you could put up? I'm fixin' to quickly compare the accuracy to TeX's German hyphenation (once the 30+GiB TeXLive repository finishes downloading).

Sure! The GitHub repository actually contains a Rust program to process a Wiktionary XML dump into a word list for training, but if you want to skip straight ahead, I've uploaded the dataset I used to https://gist.githubusercontent.com/msiemens/2aac63cf8d1b88c4... [6 MB, licensed under CC BY-SA 3.0].

PPS: You could improve the display of code blocks in your site on desktop by adding [...]

Thanks for the suggestion, I'll look into it!

That word would be Nahrungsmittelunverträglichkeit again. I just tested it and LaTeX (with `\usepackage[ngerman]{babel}`) does the same mistake as pyphen in the article (it hyphenates the word as Nah-rung-smit-telun-ver-träg-lichkeit).

To be fair, in day-to-day use problems like these will be corner cases as to my knowledge LaTeX tries to avoid hyphenation and even if it has to split a word, it has a good chance of getting it right. Also, to me this project's focus was more on learning about neural networks than creating a better hyphenator.

I guess I can see why many researchers are not inclined to publish their code. I've worked as a research assistant in the institute of microelectronics of my university for a year and the code quality was somewhere between mediocre and downright terrible. And that's not to mention the absence of sane software engineering standards like bug tracking or code reviews.

Fun fact: mitsuhiko also asked a fork of Tip4Commit to remove his projects. Now their page states [1]:

> This project has been disabled. It doesn't accept donation and it will not distribute tips.

> Reason: Project author request: https://github.com/sigmike/peer4commit/issues/110

On the other hand, Tip4Comment has only this notice [2]:

> Project maintainers have decided not to notify new contributors about tips and they probably don't like this way of funding.

[1]: http://prime4commit.com/projects/129

[2]: https://tip4commit.com/github/mitsuhiko/flask