Open gailulun opened 1 month ago
The clue is in the name; not sure whether this is the project for you.
The clue is in the name; not sure whether this is the project for you.
I'm afraid it's not what you think. The developers intend to port the pikvm system, which means they don't define this project as just a "lightweight pikvm replacement with limited functions." This is a project with phased significance, so please don't put shackles on yourself.
The NanoKVM is based on the LicheeRV Nano, a tiny SBC. Many compromises had to be made to fit a complete system capable of running Linux into such a small size.
The developers intend to port the pikvm system
I am starting to doubt it, this is probably some kind of vaporware to boost SEO results. If you want PiKVM, you are stuck with either the unreasonably priced PiKVM V4 Mini/Plus or a cheap clone. Sure, PiKVM is a much more mature project, but it wasn't built for such low-power hardware, especially RISC-V.
The NanoKVM is based on the LicheeRV Nano, a tiny SBC. Many compromises had to be made to fit a complete system capable of running Linux into such a small size.
The developers intend to port the pikvm system
I am starting to doubt it, this is probably some kind of vaporware to boost SEO results. If you want PiKVM, you are stuck with either the unreasonably priced PiKVM V4 Mini/Plus or a cheap clone. Sure, PiKVM is a much more mature project, but it wasn't built for such low-power hardware, especially RISC-V.
“Many compromises had to be made to fit a complete system capable of running Linux into such a small size.” “unreasonably priced PiKVM V4 Mini/Plus ” That's the point, so we need a higher performance version.I mean, we don't have to port PikVM. This is not a project that can only use button batteries, and we don't necessarily need such low power consumption. Why should we give up future scalability and limit ourselves to busybox due to insufficient resources? RISC-V also has corresponding and developing Linux distributions and even BSD distributions available.
Believe me, this is good for everyone: the development difficulty for developers will be reduced; the company will enrich its product line; users will have more choices; and the project will have more flexibility and development potential. . .
That's the point, so we need a higher performance version.I mean, we don't have to port PikVM.
The project name "NANOKvm" implies it should be reasonable sized and rather of a compact/small size. I think they do achieve the goal very well. Especially with the very competitive, attractive price.
we don't necessarily need such low power consumption
For me, this is a plus. As such things intend to run 24/7, it might a small difference - especially in scale. Also, the fact you can power it just through almost every normal USB port is a very good plus.
Why should we give up future scalability
Enterprise built-in KVMs (like Dell iDRAC, HPE iLO, etc) are even smaller and probably hardware-wise not much more powerful. They do all they need to do, just like NanoKVM. I think there's enough features you can add without hitting a resource limitation.
limit ourselves to busybox due to insufficient resources
I like minimalism. Less attack vectors. No need to put tons of bloatware into it.
RISC-V also has corresponding and developing Linux distributions and even BSD distributions available.
If you're looking for a full-blown machine to put all kind of application and services on it, NanoKVM is probably wrong for your use-case. Here PiKVM with a Raspberry Pi might be a way better fit.
Overall: I think they achieve their goal of delivering a small NanoKVM at a competitive price very well. I'm planning to build NanoKVM inside some server chassis as a "external KVM module" (internal VGA header, power straight from PSU, etc) and it's the perfect fit.
That's the point, so we need a higher performance version.I mean, we don't have to port PikVM.
The project name "NANOKvm" implies it should be reasonable sized and rather of a compact/small size. I think they do achieve the goal very well. Especially with the very competitive, attractive price.
we don't necessarily need such low power consumption
For me, this is a plus. As such things intend to run 24/7, it might a small difference - especially in scale. Also, the fact you can power it just through almost every normal USB port is a very good plus.
Why should we give up future scalability
Enterprise built-in KVMs (like Dell iDRAC, HPE iLO, etc) are even smaller and probably hardware-wise not much more powerful. They do all they need to do, just like NanoKVM. I think there's enough features you can add without hitting a resource limitation.
limit ourselves to busybox due to insufficient resources
I like minimalism. Less attack vectors. No need to put tons of bloatware into it.
RISC-V also has corresponding and developing Linux distributions and even BSD distributions available.
If you're looking for a full-blown machine to put all kind of application and services on it, NanoKVM is probably wrong for your use-case. Here PiKVM with a Raspberry Pi might be a way better fit.
Overall: I think they achieve their goal of delivering a small NanoKVM at a competitive price very well. I'm planning to build NanoKVM inside some server chassis as a "external KVM module" (internal VGA header, power straight from PSU, etc) and it's the perfect fit.
First, a higher performance chip and an extra RAM chip does not mean that we need to change the project name to "megakvm".
Second, even USB 2.0 can provide 500mA of current, and a worst power adapter can provide 1A of current. As for electricity costs, many features may only work when you open the connection due to an unexpected crash, and will not consume current at all in the vast majority of the time.
Third, more resources do not mean that you must use so many, and you can continue to use the low-resource version.
Fourth, fewer resources means greater development difficulty, fewer available tools, and worse user experience. Of course, these are "surmountable", such as greater latency in some cases, or making developers lose more hair.
PS: I am very interested in your last sentence. Using the interface inside the chassis as much as possible will greatly improve stability and neatness.
It is probably easier said than done. More powerful hardware means more costs, more electricity you might need to serve during peak times, and more heat in a relatively small unit. It's a trade off. Granted, I don't know the chip specifications, so there might be more powerful ones with pretty much unchanged factors mentioned above...
PS: I am very interested in your last sentence. Using the interface inside the chassis as much as possible will greatly improve stability and neatness.
It's not much magic. I do have a 19" router chassis with a N305, which obviously brings no KVM. The goal running it in a datacenter makes it difficult to access if any problems occur, so NanoKVM is my plan to go:
More powerful hardware means more costs, more electricity you might need to serve during peak times, and more heat in a relatively small unit.
These are completely acceptable to me.
The above shows that there are many people who need "fat" ipkvm.
These are all our advantages.
@gailulun Get deleloping then? High performance version sounds good like you said. I'd be interested to follow your progress...
Hi, we will extend product types first(NanoKVM-Cube/PCIe/USB/DP/...), after gather enough suggestion, we will make new generation product. (It will have dual GbE next version)
Given that hardware upgrades are often difficult, I think using higher-performance hardware is a direction worth considering. For example, pikvm recommends 2GB of memory, while nanokvm currently only has a 256MB version. Using only 1/8 of the memory may become a bottleneck for later software upgrades.