Live data from Hacker News

Show HN: Ts-SSH – SSH over Tailscale without running the daemon

github.com

11–20 of 43 posts

Re: Show HN: Ts-SSH – SSH over Tailscale without running the daemon

#11
post #8
post #2

This is why you don't let Claude handle versioning and the release process. From v0.1.0 to v1.0.0 to v2.0.0, and then suddenly 1.2.0? Semantic versioning isn't quantum mechanics. (Even then, I'll admit it's sometimes hard for me too to decide the right increment when tagging versions. :)

- 0.0.1 -> improvements - 0.1.0 -> breaking changes - 1.0.0 -> overhaul/refactor needed I know not every case is easy but this is my rule of thumb. I've honestly never needed a major version change

That kind of goes counter to semantic versioning, where:

- x.y.Z (patch) -> backward compatible bug fixes

- x.Y.z (minor) -> backward compatible new features

- X.y.z (major) -> breaking changes

But of course it's fine to use whatever versioning scheme you like, as long as you communicate it to your consumers.

https://semver.org/

Edit: updated the version strings for clarity.

Re: Show HN: Ts-SSH – SSH over Tailscale without running the daemon

#12
post #7

I am scared that this is vibe coded and not audited in any way. tsnet is good software, but wrapping it in this way is a recipe for disaster. Please reconsider.

I agree and had the same thought. Tailscale ssh is good and I was interested in something like this but absolutely not if it’s AI generated garbage.

Re: Show HN: Ts-SSH – SSH over Tailscale without running the daemon

#13
post #11
post #8

Earlier quoted context omitted.

- 0.0.1 -> improvements - 0.1.0 -> breaking changes - 1.0.0 -> overhaul/refactor needed I know not every case is easy but this is my rule of thumb. I've honestly never needed a major version change

That kind of goes counter to semantic versioning, where: - x.y.Z (patch) -> backward compatible bug fixes - x.Y.z (minor) -> backward compatible new features - X.y.z (major) -> breaking changes But of course it's fine to use whatever versioning scheme you like, as long as you communicate it to your consumers. https://semver.org/ Edit: updated the version strings for clarity.

Minor note, but since the topic is accurate semvar: rule 4 specifies 0.x.y is a special case where anything may change at any time.

Re: Show HN: Ts-SSH – SSH over Tailscale without running the daemon

#14
post #7

I am scared that this is vibe coded and not audited in any way. tsnet is good software, but wrapping it in this way is a recipe for disaster. Please reconsider.

> I am scared that this is vibe coded Totally serious question: would you feel better about this piece of software, if you didn't know that it was vibe coded? Do we need "build without AI" stickers on every piece of software created these days?

[flagged]

Re: Show HN: Ts-SSH – SSH over Tailscale without running the daemon

#15
post #8
post #2

This is why you don't let Claude handle versioning and the release process. From v0.1.0 to v1.0.0 to v2.0.0, and then suddenly 1.2.0? Semantic versioning isn't quantum mechanics. (Even then, I'll admit it's sometimes hard for me too to decide the right increment when tagging versions. :)

- 0.0.1 -> improvements - 0.1.0 -> breaking changes - 1.0.0 -> overhaul/refactor needed I know not every case is easy but this is my rule of thumb. I've honestly never needed a major version change

Using a 3-digit version like semver, while assigning different semantics, is a recipe for confusion if anyone except you ever refers to a package using this "rule of thumb".

Re: Show HN: Ts-SSH – SSH over Tailscale without running the daemon

#16
post #11

Earlier quoted context omitted.

That kind of goes counter to semantic versioning, where: - x.y.Z (patch) -> backward compatible bug fixes - x.Y.z (minor) -> backward compatible new features - X.y.z (major) -> breaking changes But of course it's fine to use whatever versioning scheme you like, as long as you communicate it to your consumers. https://semver.org/ Edit: updated the version strings for clarity.

Minor note, but since the topic is accurate semvar: rule 4 specifies 0.x.y is a special case where anything may change at any time.

Relevant section: https://semver.org/#:~:text=How%20should%20I,next%20major%20...

Re: Show HN: Ts-SSH – SSH over Tailscale without running the daemon

#17
post #14

Earlier quoted context omitted.

> I am scared that this is vibe coded Totally serious question: would you feel better about this piece of software, if you didn't know that it was vibe coded? Do we need "build without AI" stickers on every piece of software created these days?

[flagged]

Somewhat off topic question but I ask this from time to time and maybe now is that time. Has AI started fixing everyone's software bugs and closing out all the CVE's yet?

Re: Show HN: Ts-SSH – SSH over Tailscale without running the daemon

#19
post #14

Earlier quoted context omitted.

> I am scared that this is vibe coded Totally serious question: would you feel better about this piece of software, if you didn't know that it was vibe coded? Do we need "build without AI" stickers on every piece of software created these days?

[flagged]

I feel fine if AI was used to add features to an established software. Let it loose on the linux kernel for what I care. It still somehow feels icky to use it to build something from scratch.

Re: Show HN: Ts-SSH – SSH over Tailscale without running the daemon

#20
post #14

Earlier quoted context omitted.

> I am scared that this is vibe coded Totally serious question: would you feel better about this piece of software, if you didn't know that it was vibe coded? Do we need "build without AI" stickers on every piece of software created these days?

[flagged]

No one is against using AI or coding with agents unless you don't understand what it's doing and you're incapable of reviewing the output. The problem isn't the tool, it's "coders" who unthinkingly trust it without verification.
Post reply on HN