jrudolph

To be fair, GitHub has several magnitudes higher of revenue to support that. Including from companies like mine who are paying them good money and get absolutely sub-par service and reliability from them. I'd be happy for Codeberg to take my money for a better service on the core feature set (git hosting, PRs, issues). I can take my CI/CD elsewhere, we self-host runners anyway.

I wouldn’t be surprised if Google aims to replace Google Deployment Manager with this, which never really got any traction. Azure has ARM, AWA has Cloudformation. Google betting big on terraform will be interesting considering the recent change to BSL.

If Google decides to back OpenTF that would be a huge deal.

Getting a lot of docker hub vibes from this one. HashiCorp is course within their rights. Can't be cheap to run the registry given the obscene size of some terraform providers.

$ ls -lah terraform/providers/registry.terraform.io/hashicorp/aws/5.14.0/darwin_amd64/ total 368M

Anyone have an idea of the reasons terraform needs a 370 MiB binary just to call REST APIs?

I’m pretty confident of all the players in that market AWS is the least likely to pull that move.

On netlify iirc pricing was for every git committer that was allowed to trigger a deploy.

Render.com was more lenient in a model like you describe but still we have different people manage different apps and it adds up.

The appeal of a no-ops workflow for basic frontend apps is there. We’ve got a bunch of static docs sites built with vuepress and docusaurus that are a great fit for this. Not that we can’t whip up a CDN with terraform and a CI/CD pipeline with preview environments, but my team would rather spend its energy on our core product.

However we’ve been badly burned by vercel, netlify and render.com switching their pricing models to user based instead of infrastructure based pricing. We’re migrating to AWS amplify right now, which also happens to be wonderfully integrated into our wider IT landscape with an AWS landing zone, automated internal chargeback etc. It’s 90% the same for our use case and charges only for infra at standard AWS rates.

At this point I’m starting to wonder why it isn’t more popular.

also on the same blog -> https://tracy.posthaven.com/part-i-founder-led-enterprise-sa...

German CVs basically require photos and other information

I‘not sure where you got that from, but that’s just false. Most employers I know actively ask candidates to not submit irrelevant info like photos, gender, religion etc. in their applications as any info is a liability for an employer.

Look up AGG law and how all too easy it is to get a massive slap on the wrist for even the slightest hint of discrimination. Add PII issues on top.

Other commenters have covered the workload lock-in angle pretty well. Using Kubernetes as a target platform for your application already gives you a decent shot a workload portability. Keep in mind though that some K8s APIs are leaky abstractions. You pay with lock in into K8s of course. At the end of the day, lock-in is a matter of tradeoffs.

An often overlooked angle is the "organizational lock-in" to the cloud. Adopting the cloud in any serious capacity with more than a handful of teams/applications means that you will eventually have to build up some basic organizational capabilities like setting up resource hierarchy (e.g. an AWS Organization with multiple accounts), an account provisioning process, federated authentication, chargeback... See https://cloudfoundation.org/maturity-model/ for an overview of these topics.

To be honest I have seen quite a few enterprise organizations that went through so much organizational pain integrating their first cloud provider that implementing a second provider is not really that exciting anymore. Now of course, if you plan on eventually leveraging multi-cloud anyway you can save yourself a lot of pain by setting things up with multi-cloud in mind from day one.

A good read on the topic is "Cloud Strategy" from Gregor Hohpe https://architectelevator.com/book/cloudstrategy/

notion.so, also has integrated support for mermaid diagrams, decent syntax highlighting etc.

Learn from my mistakes picking up terraform as a software engineer thinking "it's just a better YAML"

It's so saddening to see how the Kubernetes hype-cycle follows OpenStack and all the fundamental problems still seem unsolved. I sometimes feel like its just the same story playing out 5 years later, one layer up to the stack (IaaS -> CaaS) and with other fools to fall for it (with OpenStack it was sysadmins trying to run a control plane, with Kubernetes its devs trying to run infrastructure).

The abstractions we have available to build and run distributed systems may have improved, but they still suck in the grand scheme of things. My personal nightmare is that nothing better comes along soon.

- Is it the networking model that is simple from the consumption standpoint but has too many moving parts for it to be implemented?

Many poor sysadmins before us have tried to implement Neutron (OpenStack Networking Service) with OvS or a bunch of half-assed vendor SDNs. Or LBaaS with HAProxy.

- Is it the storage model, CSI and friends?

I mean, the most popular CSI for running on-premise is rook.io, which is just wrapping Ceph. Ceph is just as hard to run as ever, and a lot of that is justified by the inherent complexity of providing high performance multi-tenant storage.

- Is it the bunch of controller loops doing their own things with nothing that gives a "wholesome" picture to identify the root cause?

Partially. One advantage the approach has is that it's conceptually simple, consistent and feels easy to compose complex behavior. The problem is that Kubernetes enforces very little structure, even basics like object ownership. The result is unbounded complexity. A lack of tooling (e.g. time travel debugging for control loops) makes debugging complex interactions next to impossible. This is also not surprising, control loops are a very hard problem and even simple systems can spiral (or oscillate) out of control very quickly. Control theory is hard. David Anderson has a pretty good treatise of the matter https://blog.dave.tf/post/new-kubernetes/

Compared to OpenStack, Kubernetes uses a conceptually much simpler model (control loops + CRDs) and does a much better job at enforcing API consistency. Kubernetes is locally simple and consistent, but globally brittle.

The downside is that it needs much more composition of control loops to do meaningful work, and that leads to exploding complexity because you have a bunch of uncoordinated actors (control loops) each acting on partial state (a subset of CRDs).

The implementation model of an OpenStack service otoh is much simpler because they use straight forward "workflows", working on a much bigger picture of global state, e.g. neutron owning the entire network layer. This makes composition less of a source for brittleness, not that OpenStack still has its fair share of that as well. Workflows are however much more brittle locally, because they cannot reconcile themselves in case things go wrong.

This. To be fair that info is very hard to discover on the website (I looked it up in the docs code that generates the website because I found that easier to parse like a database of all models).

I own an L10 and am very happily running valetudo on it. Someone should make a business out of selling them pre-flashed with valetudo for a less technical audience…

Was it so bad? My experience with it was resoundingly positive, and saw lots of productivity gains with a great developer experience for teams that could build apps with strong guard rails in place.

Now everyone and the kitchen sink „needs“ their own kubernetes cluster and operations teams struggle to build complex landing zones for the underlying cloud infrastructure so teams don’t shoot their own foot off all too easily…

Sorry, I accidentally posted the wrong URL, duh!

https://www.meshcloud.io/2022/04/14/degrees-of-correctness-w... is the deep link to the article.

The research, which was funded in part by the National Wildlife Federation and U.S. Department of Energy

meshcloud GmbH | Various Engineering Positions | Frankfurt, Germany | Remote work within Germany, after the Onboarding World Office | Fulltime and Permanent

Our cloud foundation platform provides control and visibility that empowers an efficient and secure multi-cloud adoption for our customers such as Volkswagen or Commerzbank. To get a tiny insight about our work: We recently launched an open-source CLI tool that provides an easy overview of multi-cloud landscapes https://github.com/meshcloud/collie-cli

We are looking for: - Fullstack Engineer (Kotlin, Spring Boot, MariaDB, RavenDB) - Cloud Engineer (Kubernetes, Terraform, Dhall, Ansible) - Frontend Engineer (Angular, TypeScript, Bootstrap) - Cloud Solution Engineer (AWS, Azure, GCP)

Feel free to take a look at our website to learn more about our benefits: https://jobs.meshcloud.io Among other things, we offer World Office (mobile working all over the world), but most importantly a working atmosphere that allows you to do your job with passion.

If you are interested in hearing more please choose a free slot in the calendar of our HR-Manager Joanna https://app.harmonizely.com/jbauer our reach out via mail to jobs@meshcloud.io

Is this a US specific problem? In Germany companies need to maintain cap tables in a mandatory public registry (Handelsregister). You can request any company’s records against a small fee (which in fairness I consider very backwards, could be more open). There are some third party providers like NorthData making this data available publicly as well.

Trying to get one right now...

Just a shoutout that vuepress 2 (or is it called vuepress-next?) can also bundle via vite. I haven't compared it to vitepress, but its reloads from markdown are also really snappy.

Espresso machines, then and now, are gigantic, expensive, difficult to use, and incredibly inefficient from an energy perspective.

Interestingly that's not my experience with Moka Coffe Pots. The 2-pot Bialetti I have takes a long while to heat and is almost always too small for the heat source I have available. Electric stove fields are too wide, and camping gas heaters seem to wrap the flames more around the pot than boiling it properly. After the water is steaming, you also need to sustain the heat for a bit to let the steam travel through. In total, it feels like a lot of wasted heat energy for a little bit of coffee.

I have a Flare Espresso machine (piston, manually operated) that just requires boiling water that I can get from a more efficient source like a pot matching the stove, a water boiler or even a good thermos (!) when travelling ;-) And the result I get out of that is a "proper" espresso because you can easily hit 10 bars of pressure, by applying gentle pressure on the lever.

TL;DR: Favorite stack is Notion -> notion-markdown-cms -> VuePress -> netlify

So I've gone through a bit of journey doing docs for a product company. I feel that for a product company it's really important to own your documentation and the publishing workflow as it's a key part of your product.

GitBooks was my first stab. I liked git and markdown, however I disliked all the places where "proprietary" formatting/features crept in and once it got more closed/commercial wrt. publishing/theming pipeline we went out.

We then adopted docusaurus v1 for our product documentation. It's a great tool, but never really built custom components for it because we're not a react shop. We did integrate some nice tools to work with our markdown tool (e.g. markdown-lint, custom code snippet injectors etc). One downside of docusaurus is how much friction there is to create a new page. You have to create a markdown file, insert frontmatter, add it to sidebars.json, reload the dev server, then insert your content.

When docusaurus announced v2, we considered adopting it. Instead, we started looking into VuePress vNext. What I love about it is that its configuration is TypeScript (vs. JSON). This allows us to generate things like navbars, sidebars from code instead of manually wrangling JSON. It uses Vite for bundling and the local editing experience is therefore much faster.

As you write more and more docs, markdown editing experience becomes important. VSCode + the right plugins can get you far, but we found they all did not feel "fluent" to the point where our team _loves_ writing documentation. People often complained that our company wiki (Notion) feels much nicer, so we built a tool that allows us to use Notion as a "CMS" for our documentation: https://github.com/meshcloud/notion-markdown-cms It's really handy because that way we get perks like organizing content with databases, link pages using @mention syntax, drag & drop for screenshots etc. Publishing on netlify rounds it off.

There are quite a few options for markdown + git knowledge bases, eg. Obsidian. You can easily find more alternatives discussed here on HN by starting a search on Obsidian.

If you’re looking for more of a CMS there’s quite a few options out there, most notably static site generators like docusaurus or vuepress. Plug: I’ve built a small tool to generate the markdown from notion, which allows me to use notion as my CMS editor while keeping the generated site fully under my control. https://github.com/meshcloud/notion-markdown-cms

Awesome research. I have similar quibbles about photo finish cameras in sports and written about them [0].

There are usually tons of rules in sport about the equipment, the Race course etc . but how exactly the finish needs to be set up is often vague. In this case it was an alignment issue at fault. But the next problem is the arbitrary resolution finish cameras work at. How wide is the pixel slot? This can be the difference between calling a tie or a small margin.

[0] https://www.rowinginmotion.com/thoughts-fairness-rowing/

AWS root user accounts are kind of an achillis heel in every enterprise setup using AWS. What you typically do is MFA (bare minimum) + sharded secrets. This means you need multiple people to use the root user account. You can also hook in additional audit controls eg by automating cloud watch and sending notifications about any root user login. Alternative is that you throw away the password and vow to never use it, or set up an account recovery process (all of this may not be a great idea as it can fail when you need it most).

The situation is somewhat more relaxed with GCP Billing Accounts and Azure EA Accounts, though they have better separation of concerns than AWS (billing vs. workload access). Nonetheless, never give these passwords to finance department lest they store it in an excel sheet on a SharePoint. Access to these credentials allows anyone to suspend billing for an entire enterprise... not sure what controls the providers have in place to verify any of this before initiating automated shutdown of all workloads.

I run a Ubiquiti UDM Pro as the router for my home network and slapping a few additional containers (it uses podman) on top like pi hole is doable e.g. using https://github.com/boostchicken/udm-utilities

I use it for pi hole and rclone backups.

It’s not exactly great as a home server if you want total freedom/control but it has a decent ARM SoC, a swappable 3.5“ drive bay and even though it’s got a fan I can’t hear it .

I only use it because it’s obviously running anyway and that was the least expensive way to add some things I wanted to my local network.

Ergs don’t float :-) The most important factor before converting raw erg performance (i.e average watts over a 2000m race) to water performance is to consider it in relation athlete mass. This is intuitive because more mass means more displacement creating more drag. The erg doesn’t consider any of that.

In our testing protocols we had a metric from watt vs mass called p-index. I’m not sure exactly how it’s calculated anymore but there should be a published paper about this somewhere [0].

The lightweights usually had higher p-index values than the heavyweights, though values from the top heavyweights that also did well where usually close to the lightweights. That’s just anecdotal though.

There are tons more differences. The next important factor that comes to mind is technique, obviously. My guess is the next biggest contribution to performance difference is the catch, how quickly an athlete is able to burry the blade in the water and apply force without losing precious stroke length. This requires precise timing of vertical and horizontal movement. You do it right when you see a small v shaped splash as the blade enters the water. The measurement for that is called slip angle. The erg is much less picky about that.

I already mentioned some other points in my previous post, I bet there is tons more.

[0] Volker Nolte, Dieter Altenburg and Valery Kleshnev are great starting points when it comes to rowing research. Theres plenty more if you dig in.

Certainly more accurate than most other ergs (that's how we rowers call them). However, it's not perfect. Nothing is ever perfect when it comes to measuring real world biomechanics. I did competitive rowing in my youth + I've spent a couple years building rowing technology, sensors + telemetry, so I can maybe offer a few interesting insights about their issues. Don't get me wrong, C2 ergs are great craftsmanship, built like tanks and I've spent a few hundreds hours on these machines (blaming the weather gods and the winter season).

1) The PM2 units (the old LCD ones, stock on Model C ergs) were particularly bad, suffering from some well known "issues". The sensors in them had not a high enough sample rate + high hysteresis in the sensors. That means that "pulling hard" at the catch (for non-on-the-water rowers: the beginning of a stroke cycle, when your hands are closest to the flywheel) and then backing off the handle force rewards you with higher measured power than actual.

2) This became a lot better with the PM4 generation (stock on Model D and up). However they still have another issue. The force exerted by the suspension cord that pulls the chain back into the housing is not subtracted from the measurement. The sensor only measures effective force/rpm on the flywheel. This is the reason why virtual regattas (serious competitions anyway) are always staged on brand new ergs where the suspension cords have not different levels of fatigue. The ergs are typically sold off after the events (which is of course a marketing/logistics trick just as well).

"Proper" testing on a C2 thus involves measuring handle force directly. This can be done by linking a strain gauge between handle and chain.

3) Speaking of racing events, it's pretty interesting how C2 has enabled virtual/digital racing long before "digitalising" things was a big trend. The interface that the PM4s use for regattas is based on RS485 over RJ45 (you can also use USB but that's not the recommended way for large scale > 16 seats races). The PM3 were wired using telephone/RJ11 and I think it was RS232 IIRC.

4) The single most important "calibration" on a Concept rower is the Drag Factor (the displays can show it in an advanced menu). The drag factor is essentially how fast the flywheel slows down, i.e. how much drag it has. Different ergs have different amounts of dust in them and wear on the bearings, which is why the "flap setting" really shouldn't be used as an absolute/comparable measure between machines.

Racing with a higher/lower drag factor is purely a matter of preference of the athlete and where their personal optimum for performing mechanical work lies. You can think of it like a gearing to increase resistance. In "on the water" rowing we can change gearing using inner/outer handle length of the oar on the gate to achieve a similar effect. This is very important since speed vs. the water varies a lot between boat classes from about ~4m/s in a single (1x) to ~6m/s in a 8+/4x. Our testing protocols recommended 125-140 (female-male).

5) While everyone obsesses over watts, that's not the whole picture. To move a boat (virtual or real) you need work, not power. Since ergs don't float, their mechanics are a lot simpler than a real rowing boat. Work on an erg is handle force x distance, i.e. you integrate the force-distance curve of the handle. That means long strokes are better - the most common beginner mistake is to waste stroke length.

6) Related to 1) and 5) there's a special "erg technique" of pulling the chord up the chest as you move angle your back backwards at the end. This gains you extra stroke length and "stealing" a bit more mechanical work due to sensor hysteresis. This works on a PM4 and up too. You can only get away with this on an erg. On the water pulling off this sort of trick at race speeds will most likely eject you from the boat. It may look like a funny catapult but ejecting from the boat can 100% kill you if your head hits a rigger or blade. See [0] for a close encounter.

7a) "Ergs don't float" is a saying for another important reason. They fail to simulate the impulse exchange between rower and boat mass. This is very important for real world rowing performance because minimizing boat shell velocity fluctuations means less mechanical work required to travel the same distance [1]. This is also the reason why it's preferable to have a "front-loaded" force curve profile. Coincidentally the sensor hysteresis of the concept ergs rewards that... maybe it's engineered intentionally? :-)

7b) Anyways, Avoiding vertical shell movement is of similar importance as wetted surface (and thus drag) increases massively if you push the boat down into the water. Athletes thus have a to maintain very delicate balance between stretcher and handle forces not to offset the systems center of mass during the stroke cycle. None of that matters on an erg.

7c) And most important: Ergs don't simulate the interaction of impulse exchanges between a whole crew of rowers that can never be perfectly in sync. Concept sells "Sliders" for the C2 ergs that you can use for a single erg but also to link together multiple ergs to a crew. If you haven't tried this, I can highly recommend this as it makes it much more realistic and also a lot more challenging. From my coaching experience I can also recommend it especially to beginners. It may sound counterintuitive, but it's much less forgiving to errors in your motion sequence/force application and will thus make you a better (and more healthier!) rower much quicker.

8) Rowers are an incredible bunch of creative and resourceful people. There's so many tinkerers in the community... a shout to a couple of things in the erg space:

- Waterrower hit big thanks to House of Cards. This plus cross-fit certainly made rowing much more popular as a sport. Waterrowers are not used in serious capacity in competitive training though as far as I'm aware.

- Augletics are a bunch of former competitive rowers building an erg using a electromagnetic brake (that can support more realistic force profiles/dynamics). And you don't get that "wooooosh" sound ringing in your ears that won't go away for hours after a 90min C2 erg session...

- Biorower simulates proper sculling technique, boat rotation and uses mechanical gears instead of a flywheel

Anyhow - great to see more innovation like Aviron in the space even if it's "just" targeted at recreational/fitness use case. It's a fabulous sport and I applaud you for making it more accessible. Hope it gets people to dip their toes so they may one day decide to get their feet wet and hit their local rowing club.

[0] https://www.youtube.com/watch?v=pH2k_026KrY [1] https://www.rowinginmotion.com/drag-efficiency-rowing/

SAP _Graph_ and then it's a REST API? Not GraphQL?

I mean, both types of API have their use cases but that's just an attempt at riding the latest hype.

meshcloud | Frankfurt, Germany | Onsite & Remote (EU Only) | https://meshcloud.io

meshcloud helps some of the largest enterprises in the world manage thousands of AWS Accounts, Azure Subscriptions and GCP Projects using our multi-cloud management platform. We automate IAM, administrative processes & security policies so that DevOps Teams can enjoy private & public clouds without obstructions.

Our open positions and tech stacks:

* Fullstack Engineers: any of Kotlin, Spring, Angular, TypeScript, RavenDB

* Frontend Engineers: Angular, TypeScript, SCSS, ngrx

* Cloud Engineers: AWS, GCP, Azure, Kubernetes, dhall, ansible, terraform, SRE experience welcome

* Solution Engineers: help implement meshcloud multi-cloud management at our enterprise customers, consulting experience welcome

Careers page: https://www.meshcloud.io/jobs/

My team is 11 full-time engineers right now and growing fast, so our positions come with great growth opportunities. Remote candidates should have previous remote work experience. I'm hiring for my team, so get in touch directly at jrudolph@meshcloud.io.