leonheld

I tried reading Moby-Dick a couple years ago and it was very hard as a non-native English speaker. The only book who made me want to pick up either a dictionary or a translation.

Will try again, maybe I've gotten better!

Sadly I also get these "everything is about us" vibes about Hector sometimes. They seriously should chill a bit.

Maybe do something about the illegal mining and deforestation instead?

I hate it in the best way possible.

I'm very thankful for ripgrep, ag and fzf.

Found the robot!

> Anyway, what I really wanted to complain a bit about is the realm of software intended to be run on servers.

Okay.

> I'm not sure that Docker has saved me more hours than it's cost

I'm not sure what's the alternative for servers here. Containers have certainly saved me of a lot of headache and created very little overhead. N=1 (as it seems to be the OP).

> The problem is the use of Docker as a lowest common denominator [...] approach to distributing software to end users.

Isn't the issue specific for server use? Are you running random images from the internet on your servers?

> In the worst case, some Docker images provide no documentation at all

Well, in the same vein as my last comment, Docker is not a silver bullet for everything. You still have to take care of what you're actually running.

Honestly the discussion is valid, but I think the OP aimed at "the current state of things" and hit a very valuable tool that doesn't deserve some of the targeted cristicism I read here.

edit: my two cents for those who cannot bother and expect just because it's a container, everything will magically be solved: use official images and those from Bitnami. There, you're set.

I'm nothing without git rebase -i.

> In the larger sense, "Kubernetes-Native" is similar to "Linux-native." Kubernetes is the platform.

Let me preface that I wrote a whole thesis on Kubernetes, and the sentence "Kubernetes-Native" makes no sense to me. It's just a container.

My buzzword-meter is beeping pretty hard right now.

Can you explain why this is "Kubernetes-Native" (whatever that means)? It's not quite clear from the link.

Hey, I have a question for you (I'm assuming you know Europe/US): are the houses in Uruguay built to the same insulation standards as houses in northern/central Europe, for example?

I live in southern Brazil and I have yet to realize why we don't give a shit about proper insulation/modern heating techniques. Burning wood for heat in badly insulated homes drives me in-sa-ne during the winter months, terrible for my asthma.

And Visual Studio is probably one of the best if not the best IDEs out there.

Had to scroll down a lot to find this. Developers should be able to easily test their code, if needed, merged into a staging branch somewhere, which can be easily rebased or cherry-picked into production.

You know it's not a fair comparison due to how widespread English is and German is not.

Germany companies are so weird in this aspect, and I honestly believe it's why they kinda lost the tech race. The US is very much different in this diversity aspect, which honestly seems like a success factor.

How is a self-hosted GitLab instance less democratic than e-mail? The only difference between the two is that one is a major PITA to setup as a user.

Seriously, it's the second time someone doesn't properly read my comment:

> and until a few years ago, extremely bad integration with tools like Yocto.

I can see where your generalisation is coming from, but again, it's a generalisation. There are a bunch of nice layers that build cleanly with Linus's tree against OE master no problems. That takes work, naturally.

In one of the Yocto Summits I've been to there was literally a talk about "stop venturing the kernel". Everyone hates it. We really do fight against the major SoC vendors to stop not upstreaming stuff and it has been getting better :-)

I mean, I won't even try to rebate you, I agree with you, mostly. lol.

My only fear is that, it's really, really hard to get a safe, performant product without really knowing what you're doing. And although RPi and others do a good job at the prototyping level, it becomes messy very quick.

We're trying to be better, though, there are some nice solutions popping up here and there.

I said "until a few years ago", and AFAIK this was not done by the RPi folks themselves, but by the community. And that's perfectly okay, it's not their market, which is my whole point.

It takes a serious effort and money to maintain a layer. It's not easy to integrate and test everything.

No reachable for me as well.

> which usually is what "industry" is being referred to.

Bingo. It's always a bit hard for me to properly communicate to people that the 'industry' is not an air monitoring/grafana-prometheus/PiHole/whatever low-volume, no risk application.

Pretty much what the other comment said about the BB being proven etc.

Because of better support from TI, BB always had a more professional feel than the Raspberry Pi, specially for documentation etc. It's a fine chip, if you can source it (haven't messed with anything from Octavo, but it seems solid to me). All the software issues are pretty much solved and upstreamed at this point.

I have a bunch of experience on this but won't go into much detail because it may be a touchy topic: most companies that do $THING and use SBCs like the RPi are extremely talented at $THING, and not at embedded development. That's why, most of the time, they go into this ecosystem.

And I mean, it works! But it's an unsafe mess which generates a bunch of regulatory issues and it keeps me up at night :-)

I think you're confusing 'embedded industry' with 'embedded hobbyists', because we (the industry) don't focus on hobbyists.

The RPi really does suck from a professional use-case: no volume, no 10 year guarantee, no proper industrial certifications and until a few years ago, extremely bad integration with tools like Yocto.

The two segments do overlap sometimes, but it's definitely not the same beast. A lot of SBC vendors have provided great boards over the years (looking at Variscite, PHYTEC, Toradex, SECO et al), but the incentives, and thus the final product, are not what hobbyists expect.

Ugh, yes, but then I fall into the "too complex for bash, too simple for Python" trap. I feel like everything goes to hell the moment someone writes a Python class to deal with /something/ in a build pipeline. For bash, well, we all know where that goes... the other options are simply too obscure for me to invest in.

But I agree with your assessment, as much as the classic

script:

  - chmod +x pipeline.sh

  - ./pipeline.sh

makes me want to die.

What I really want is a 'Grand Translator' tool that allows any CI pipeline definition to be translated into any other CI pipeline definition.

I want to take any .gitlab-ci.yml and magically translate it to a github workflow, and vice-versa. I know it isn't impossible, but it's a heck lot of work to get it right with all the hidden features behind declarative pipelines.

> This sounds like a very weird edge case and it's very easy to say this sort of statement in retrospect

As someone who works on embedded devices with a lot of experience with Hardware-in-the-loop testing, this is 100% a QA oversight.

The way this feature is implemented screams "test it from boot to reboot". I wouldn't pick too much on a small company doing some basic BSP/application work for some HMI device or something like that, but this is the richest company in the world with major funds/infrastructure to be better than this.

No major accidents ever as far as I can Google (I speak Portuguese, so I searched the local web).

Linux with compositors (sometimes custom ones) for graphical applications. Weston is fairly popular, for example.

Or even nothing at all, you can run Qt6 standalone and have a very nice touch interface.

Xing is actually a big thing in Germany, akin to LinkedIn.