SkyLinx

Hi HN,

I am the founder of SprintPulse. Like many of you, I used to dread retrospective meetings. They often turned into a repetitive cycle where we wrote down the same issues every sprint but never actually fixed them. "Better communication" was on our action item list for months.

I built SprintPulse to fix that loop. It is a tool designed not just to collect feedback, but to make sure it leads to real change.

When I looked at the tools available, I found they fell into two camps.

On one side, you have generic whiteboards like Miro or FigJam. They are great for free-form drawing, but they are too open-ended for structured retros. They don't help you track history or remind you of what you promised to fix last month.

On the other side, you have specialised retro tools. I found that while these solve the problem, they often feel outdated. The UX can be clunky, they are often loaded with complex settings you don't need, or they are just too expensive for smaller teams to justify.

I wanted to build something in the middle. A tool that has the structure and insights you need (for which AI isn't just a "me too" buzzword), but with a modern interface that doesn't require a tutorial.

- AI Analysis: Instead of just counting votes, the AI reads the feedback to spot trends and suggest action items. If the team is getting burnt out or if specific topics keep appearing without resolution, the system flags it. - Accountability: This was the main thing I wanted. SprintPulse tracks your action items from previous sprints. If you ignore a problem for three weeks, the tool brings it up. It forces you to either fix it or consciously drop it. - Clean UX: I focused on keeping it fast and lightweight, and enjoyable to use. You just log in and start the meeting.

I believe smaller teams shouldn't have to pay just to run a basic retro.

- Free Plan: We have a solid free plan for teams up to 10 users. It includes 3 retros and the core features. No credit card required to sign up. - Paid Plans: If you have a larger team or want deep historical analytics and insights, integrations with Linear, Jira and Slack, we have paid tiers.

For the HN community, I am offering 40% off any paid plan (recurring, forever) with the code HACKERNEWS.

I would love for you to take a look and tell me what you think.

Link: https://sprintpulse.io/

Thanks!

Check it out at https://github.com/vitobotta/hetzner-k3s - it's the easiest and fastest way to set up Kubernetes clusters in Hetzner Cloud!

This is with the new version not yet released of my tool https://github.com/vitobotta/hetzner-k3s.

It uses k3s as Kubernetes flavor and Hetzner Cloud as provider. For this test I used extremely high concurrency so the tool hung twice in the middle of the process because I was hitting the Hetzner API too hard, so I had to interrupt it and continue.

Excluding the time it paused/hung due to the API, I calculated around 11 minutes total for the cluster creation. This includes:

- creating all the resources (cloud instances, firewall, load balancer for the Kubernetes API)

- deploying k3s to the control plane (3 masters) and the 297 worker nodes

- installing the Hetzner Cloud Controller Manager, to link K8s nodes to the cloud instances as seen by the Hetzner control panel and be able to provision load balancers out of the box

- installing the Hetzner CSI driver, to be able to provision block storage volumes out of the box

- installing the Cluster Autoscaler, to allow configuring autoscaling node pools

- installing the Rancher System Upgrade Controller, to handle k3s upgrades very easily

I believe this is a world record, or at least I have never heard of a tool managed or not to create clusters that comes even close to mine in terms of speed. Am I wrong? I would be curious to hear if there is a tool even faster than mine.

Of course not many people need to create clusters with 300 nodes from the get go, but it was a fun experiment. In the version I will release in the coming few weeks (v2.0) I will likely limit concurrency to more sane levels to reduce the risk of hitting the Hetzner API too hard, although most people will create small clusters to begin with. During my testing, I was able to create a cluster without hanging etc with max 100 nodes. Beyond that it almost always hangs and there are retries to create/power on cloud instances. So yeah I am going to limit the concurrency just in case to perhaps 10 or 20 servers per time for real life use.

What do you think of this? Let me know! I am curious to hear feedback or any comments on the subject :)

Hi all, if you already use Kubernetes in any capacity or are you interested in it, would you mind spending a few minutes voting in a quick poll and hopefully answering a few questions? I would appreciate your help a ton because it would help me make the right decision and hopefully avoid a costly waste of time.

Everything is in a Github discussion at https://github.com/vitobotta/hetzner-k3s/discussions/296. A huge thank you in advance if you can help with this!

The new release introduces more customisation options for cluster/service CIDRs, cluster DNS, updated manifests for CSI/CCM/autoscaler, and a couple of improvement for creating large clusters. Check it out at https://github.com/vitobotta/hetzner-k3s

If you are already familiar with this tool, I'd love to know how it's worked for you so far. :)

This is my tool to quickly create k3s clusters in Hetzner Cloud.

The main change in this release allows creating node pools with any number of nodes - you are limited only by the caps on your Hetzner account. This update makes it possible to create pretty large clusters for cheap

https://github.com/vitobotta/hetzner-k3s

Looking forward to any feedback, comments or questions :)

Hi everyone, I wrote a blog post about Seafile. If you are not familiar with it it's a more reliable and faster file syncing/sharing solution than Nextcloud, which you can self host. In the post I describe how to set it up with object storage (so you don't need to worry about how much disk space you need) and Collabora Online, to be able to work on office documents alone or with other people in realtime, in the browser. I had some road bumps to figure out some bits since the documentation isn't great, so I hope it can save somone some time :) The post: https://vitobotta.com/2023/02/09/self-hosted-seafile-s3-collabora-online/

My understanding is that DNS queries via UDP (the default) should be faster, but I am seeing the opposite on two Macs I own, and other 3 people I have asked who are also on Mac, see exactly the same thing. It's weird, but queries over UDP are 3-5 times slower than queries over TCP. I cannot reproduce this on my Linux servers for example.

On my Macs I switched to DNS over TLS which is much faster than the default UDP querying for me, but I am still curious.

Can readers with Macs try as well? To test, I run the command `dig @1.1.1.1 somedomain.com` to test with UDP (with Cloudflare's public DNS in this case, and any domain you want), and the same command but with the additional argument`+tcp` to query over TCP. Try each command a few times. Which one is faster for you? UDP or TCP?

Trying to understand if it's a Mac issue. Thanks in advance!