kyrofa

From the OP:

> Our payload uses a satellite transceiver for communications

This is a great idea. I had no idea about the single-use radiosondes.

There are companies out there (full disclosure, I work for one[1]) that create and maintain custom software for companies such as yours, including websites. They work with you to make sure you have exactly what you need. That direction may prove more effective than trying to bring tech talent onboard.

[1]: https://www.miriamtech.com/

Ideally, colonies that are unable to keep mites etc. under control will simply die. I expect some losses before a strong colony emerges that I can split.

I've started keeping my own chemical-free bees. My hope is to build a healthy apiary of local bees that casts swarms, which will help replenish the wild bee population around me.

Wow, some great examples in here for how to use mocks wrong. I get the impression the author has just never seen tests that use mocks properly, honestly. The various refactorings contained in here are fine, of course, but I see no reason to call the entire use of mocks an anti-pattern. They're a tool, and they need to be used properly. Let's not throw the baby out with the bath water.

Why are we building this into SSH itself? Isn't this what things like fail2ban are for?

Yikes, those things are terrifying. I'm a fledgling beekeeper, this is not a good game for me to play.

They must be reading this thread. The killer bees stung me to death despite my escaping happily and not perishing.

Indeed. I'll come back when they fix that mess.

I think you're misinterpreting my response. Of course there's value in testing operating systems within VMs. In fact, a solid chunk (if not most) of the Ubuntu install-base is VMs, believe it or not. I wasn't talking about that at all, but rather responding to the idea that, if I used a VM as my development platform, my problems would go away. In reality, in that context, it really changes nothing.

Yes that might actually help, but I can imagine the cost/benefit analysis being difficult to pull off: the costs are very real, but the benefits are less tangible. To be clear, I don't know of anyone who left because of a bad upgrade. I think a lot of folks just ran like I did, hopping from LTS to LTS after the point release (or only once their LTS was nearing EOL).

I suspect it was a lot easier to feel like that was one's duty when the company was smaller and you were closer to every piece of it. It was also probably easier to get issues resolved when you knew exactly who to talk to. Maintaining that culture as you grow is probably quite the challenge!

Perhaps I'm misunderstanding your question, but is it really dogfooding if every meaningful thing I'm doing is within a stable VM?

In general, a VM for my work doesn't change anything. It doesn't magically keep anything backed up: I still need to commit/push regularly, and so on. If the host explodes, I'm still down, even if what I'm doing is in a VM. I could immediately reinstall an older release and get set back up, but that isn't really dogfooding for an OS. I would need to report a bug and actually get the issue resolved, which generally means running in a broken state for a while to get there.

Beyond that, I've used a VM for my day-to-day work in the past, and honestly I found it maddening. I couldn't fully utilize my computer without starving the host of resources, and there were a thousand other papercuts relating to hardware access and general instability. I try to avoid that development story these days.

As you can see, my concerns here have nothing to do with losing code or data. They relate to lost productivity and not satisfying my primary duties.

> Also, no blame here.

Oh don't worry, no offense taken. It's an interesting problem: dogfooding is definitely a good way to catch problems, but if your release is unstable enough to break machines, you can end up with a wide swath of the company being unproductive. The stability of the overall release wasn't one of my core responsibilities, so naturally I gave more priority to the things that were; I needed a release that worked so I could get my job done.

There might be some cultural solutions to that. For example, if the company expects that employees are dogfooding, perhaps testing out a beta in a specific timeframe, it could be culturally expected that devs might have broken machines during that timeframe. If was that taken into account in both the schedule as well as support paths, that would make things a bit easier. Honestly, though, even if that were the case, it would still be a hard sell for me. Quite simply: I don't like failing at my duties. I would need to be convinced that this was one of my duties, and I'm not sure how the company would pull that off. And that's ignoring other very practical concerns, such as the fact that a fair number of Canonical engineers only have one work machine. Having that machine down, depending on the definition of "down," can make it difficult to get support in the first place.

It's top-down engineering. Mark commanded the desktop team to go all-in on Flutter. This is how Canonical functions.

Even when I worked at Canonical I never installed the latest LTS until at least its first point release in the summer. Maybe I'm part of the problem: if more people followed my lead, the initial release would get buggier and buggier.

The Flashbulb is one of my favorites, and makes up a significant portion of my Spotify playlists. I feel terrible for him, but from the listener side of things, it was honestly a good reminder of one of the reasons why I've always maintained a huge personal library: no one can take that from me. I didn't realize how much Spotify had turned into a crutch. Time to buy some Flashbulb.

> It means that the commit was created using the author's credentials (to the extent that you trust GitHub and its lack of bugs).

This is incorrect. If I create a merge request, and then the maintainer clicks the "squash and merge" button, that commit is associated with me, even though I'm not actually the creator of that commit at that point: the maintainer is. I believe this happens even if someone else (e.g. the maintainer) pushed commits to that merge request before squashing them together.

Yeah I've always found that to be frustrating. Someone squashes and merges MY commits, and github still shows them as validly signed, even though they aren't the commits I created. Sadly it's hard to actually filter those out: the UI makes them all look the same.

I hadn't heard of this, thank you! I'm giving it a shot now.

Because we're providing a service. We're not buddies. We're not texting our bff. I don't like to see professional emails using "lol" either.

> Unlike this email, C can be converted into Rust piecemeal and integrate with the rest of the kernel.

Did you read the entire email? Here's a quote that seems to directly contradict you:

> converting C code to Rust isn't something that can be done piecemeal, whereas with some cleanups the existing C code can be compiled as C++.

As far as I can tell, the author is correct. What is the pattern for converting C to Rust piecemeal?

It seems overly simplistic to boil this down to sexism. You're really going to tell me that I'm sexist because I think emailing a paying customer with multiple sentences ending in multiple exclamation marks comes off as unprofessional? I should be able to have an opinion about messaging and tone without involving that person's gender.

Yeah I use chronic all the time for my cron jobs so they only email me if they fail and I can still print helpful output from them. Love moreutils.

I purchased Dell's original Project Sputnik XPS 13 to be my daily driver and was dismayed at how awful the touchpad was. I couldn't disable tap-to-click, palm detection was terrible, you get the idea. I fixed it so it was bearable to use, upstreamed my patches, and ultimately got a job at Canonical thanks to the connections I made in the process.

> Building it that way is a choice. It's not mandatory.

This ^ . In GitHub Actions, I personally try to use pre-baked actions as little as possible, for exactly the reasons I outlined.

I prefer GitLab CI, but you can make a mess of that just as easily. In general, if you approach CI as I suggested, you end up with something maintainable regardless of the CI engine in use.

Fair critique, totally depends on what kind of software we're talking about and where the deployment is happening. In general though, how screwed are you if your CI environment goes down? Can you not deploy anything? That would be scary.

My point, however, was mostly that the logic necessary to deploy should live as part of your codebase, not written out in YAML. The privs necessary to deploy are a separate discussion.

I would respectfully suggest that the author is misusing CI. If you have trouble running your tests locally, you have a problem. If you have trouble deploying from your local code, you have a problem. All of those capabilities should exist as simple scripts in your project already. Once you have that done, the CI yaml is a simple glue layer that defines an order of operations, e.g.:

1. Run static tests

2. If those pass, run unit/integration tests

3. If those pass, deploy

If you find yourself screaming about YAML, you're leaning too heavily on it and need to refactor your project's scripts.

Maybe a good question to ask would be "if I had to switch to another CI system today, how hard would it be?" If the answer is "hard", perhaps you're leaning too heavily on it and need to refactor your project's scripts.

Cattle that are hard to see given the environment: https://boingboing.net/2021/10/18/the-story-of-hawaiis-invis... .