Live data from Hacker News

DIY IP-KVM Based on Raspberry Pi

github.com

81–90 of 91 posts

Re: DIY IP-KVM Based on Raspberry Pi

#81

I'm glad projects like this exist, but I'm too lazy and more than happy to have a Pi provide a serial console and a hardware reset via GPIO over IPv6 for colocated hardware. It's much simpler ;)

I thought about building one of these, but then I just switched both of my servers to boards with IPMI

The problem with IPMI / iLO / iDRAC is that they're not secure. You can't safely put them on the Internet, so you need to pay your colocation provider for out of band connectivity and a separate drop.

To save money, I have a switch inside of my machines and have the serial console Pi on an IPv6 address. Having a fully up-to-date, modern OS makes a world of difference.

Re: DIY IP-KVM Based on Raspberry Pi

#83
post #9

I like this project but the hardware seems quite overpriced at $300+. Similar for tinypilotkvm.com. In the past I've considered making and selling a cheaper version. Aside from lack of time (or motivation), one thing which discouraged me is that I would feel bad "undercutting" someone selling open hardware.

PiKVM founder here :)

This project is a full-time job for an entire development and support team, and it's a way to keep the software open. For this money you get excellent hardware, software without any restrictions and a huge number of features. We also have a production-grade support: if you find a bug, it will be fixed quickly, and if the device fails due to a defect, we will quickly replace it.

In fact, we have developed and support all the key components of the KVM stack for Linux - the video server, kernel patches, and so on, which is also used by our competitors, like TinyPilot. But unlike them, we don't impose any licensing restrictions - for example, buying TinyPilot you find yourself bound by a subscription, and if you stop paying, your OS will no longer receive updates. With PiKVM, you don't need to do this - the device is yours forever, with updates until the end of time.

In addition, the production of large quantities of iron is quite expensive. Each device must be assembled, tested, packaged, and so on. When you do some small project, you can do it yourself, but in a large batch it inevitably has to be delegated to the factory, where each operation costs a certain amount of money.

In summary, that's where the price comes from: software, support, development, people.

Re: DIY IP-KVM Based on Raspberry Pi

#84
post #23

Earlier quoted context omitted.

TinyPilot founder here. I understand the feedback about the price. When I created the original TinyPilot,[0] I wanted a low-priced alternative to the $600 KVM over IP options I was seeing, and now I sell my devices for $400-500/unit. The thing that's tough about selling hardware is that it seems easy to produce a few units cheaply, but creating a sustainable business for it, the costs add up. You have to fulfill orde…

> provide support when the customer has trouble understanding how to connect to a device on their local network. Is it possible to order current revision of TinyPilot for someone in a remote location and connect to it on arrival through some managed service - without going through all the hoops of helping end user with setting up some form of reverse shell (e.g. either meshcentral or openvpn/wireguard for webinterfac…

PiKVM can do this. We have developed a cloud-like platform that is already being tested, and we plan to launch it before the new year's release.

Technical details here: https://www.kickstarter.com/projects/mdevaev/pikvm-v4/posts/...

If you REALLY want to try it and you have PiKVM, you can contact us at Discord (https://discord.gg/bpmXfz5) and we will give you access to the beta version.

Re: DIY IP-KVM Based on Raspberry Pi

#85
post #9

I like this project but the hardware seems quite overpriced at $300+. Similar for tinypilotkvm.com. In the past I've considered making and selling a cheaper version. Aside from lack of time (or motivation), one thing which discouraged me is that I would feel bad "undercutting" someone selling open hardware.

Note there are also alternative Pi-KVM hardware boards (in a variety of formats) from BliKVM. They don't seem to directly support the upstream project, and I believe they may have even forked some of the software from PiKVM and TinyPilot both and may or may not have provided proper attribution/recognition... so take that as you may.

[deleted]

Re: DIY IP-KVM Based on Raspberry Pi

#87
post #83
post #9

I like this project but the hardware seems quite overpriced at $300+. Similar for tinypilotkvm.com. In the past I've considered making and selling a cheaper version. Aside from lack of time (or motivation), one thing which discouraged me is that I would feel bad "undercutting" someone selling open hardware.

PiKVM founder here :) This project is a full-time job for an entire development and support team, and it's a way to keep the software open. For this money you get excellent hardware, software without any restrictions and a huge number of features. We also have a production-grade support: if you find a bug, it will be fixed quickly, and if the device fails due to a defect, we will quickly replace it. In fact, we have…

>But unlike them, we don't impose any licensing restrictions - for example, buying TinyPilot you find yourself bound by a subscription, and if you stop paying, your OS will no longer receive updates. With PiKVM, you don't need to do this - the device is yours forever, with updates until the end of time.

This is true and is a fundamental difference between PiKVM and TinyPilot.

TinyPilot charges a yearly subscription for customer support and software updates because those things have ongoing costs.

I don't think small businesses can realistically promise customers free support and updates for life. It may work in the short term, but at a certain point, it's not sustainable for a vendor to spend their limited support and dev resources on customers who purchased hardware five years ago and will never pay the vendor another dime.

Re: DIY IP-KVM Based on Raspberry Pi

#88
post #87
post #83

Earlier quoted context omitted.

PiKVM founder here :) This project is a full-time job for an entire development and support team, and it's a way to keep the software open. For this money you get excellent hardware, software without any restrictions and a huge number of features. We also have a production-grade support: if you find a bug, it will be fixed quickly, and if the device fails due to a defect, we will quickly replace it. In fact, we have…

> But unlike them, we don't impose any licensing restrictions - for example, buying TinyPilot you find yourself bound by a subscription, and if you stop paying, your OS will no longer receive updates. With PiKVM, you don't need to do this - the device is yours forever, with updates until the end of time. This is true and is a fundamental difference between PiKVM and TinyPilot. TinyPilot charges a yearly subscription…

Well, I don't know what you consider a short term, but PiKVM feels pretty good throughout its existence, and it has been for several years. It seems that we have set priorities differently at the start. My policy has always been that throughout the entire lifecycle of the device, the user must be sure of its security. In particular, this means that the user must receive updates. There is nothing more important than security when it comes to equipment, and I hate when a device turns into a unsafe brick after a few years. That's why we put it into the business model even before the first Kickstarter.

Another thing that made it possible to do this is the automation of all routine processes, such as testing and package builds. In PiKVM, the first component that was written was a build system to solve this issue once and for all. In this vein, I made a huge contribution to the "pre-launch" before flying. BTW, to be honest, I was somewhat surprised that you used Ansible instead of packages, it seems that this caused you a giant overhead for support.

Of course, in the future we plan to provide some paid services, but this does not concern the regular OS and access to updates at all, they should remain free.

Re: DIY IP-KVM Based on Raspberry Pi

#89
post #88
post #87

Earlier quoted context omitted.

> But unlike them, we don't impose any licensing restrictions - for example, buying TinyPilot you find yourself bound by a subscription, and if you stop paying, your OS will no longer receive updates. With PiKVM, you don't need to do this - the device is yours forever, with updates until the end of time. This is true and is a fundamental difference between PiKVM and TinyPilot. TinyPilot charges a yearly subscription…

Well, I don't know what you consider a short term, but PiKVM feels pretty good throughout its existence, and it has been for several years. It seems that we have set priorities differently at the start. My policy has always been that throughout the entire lifecycle of the device, the user must be sure of its security. In particular, this means that the user must receive updates. There is nothing more important than s…

>* BTW, to be honest, I was somewhat surprised that you used Ansible instead of packages, it seems that this caused you a giant overhead for support.*

Why didn't you tell me three years ago?!? : )

Yeah, Ansible was a huge mistake.[0] I knew it wasn't the right tool for distribution, but starting out, I just stuck with the tools I knew. We finally purged it in our last release and moved everything to standard Debian packages.

I'm glad to hear that PiKVM's stragegy has been working. I know our two projects are often pitted against each other, but I think there's ton of space for both of us to win back market share from the huge enterprise players and their consistently weak KVM offerings.

[0] https://mtlynch.io/solo-developer-year-5/#ansible-and-git-ar...

Re: DIY IP-KVM Based on Raspberry Pi

#90
post #89
post #88

Earlier quoted context omitted.

Well, I don't know what you consider a short term, but PiKVM feels pretty good throughout its existence, and it has been for several years. It seems that we have set priorities differently at the start. My policy has always been that throughout the entire lifecycle of the device, the user must be sure of its security. In particular, this means that the user must receive updates. There is nothing more important than s…

>* BTW, to be honest, I was somewhat surprised that you used Ansible instead of packages, it seems that this caused you a giant overhead for support.* Why didn't you tell me three years ago?!? : ) Yeah, Ansible was a huge mistake.[0] I knew it wasn't the right tool for distribution, but starting out, I just stuck with the tools I knew. We finally purged it in our last release and moved everything to standard Debian p…

> Why didn't you tell me three years ago

You didn't ask :P

> Yeah, Ansible was a huge mistake.

I have some experience operating large clusters and distributing software, and these damn things like Ansible have never led us to anything good. So either packages or the whole chroot (docker, whatever).

In fact, I'm a fan of the good old time-tested solutions. You know, Makefiles, packages, maximum integration with native OS tools. A lot can be done with simple tools, and although the start will be difficult, the support will be simple.

> there's ton of space for both of us to win back market share from the huge enterprise players

Ofc. In addition, users clearly benefit from competition.

Post reply on HN