This. The amount of investment into CUDA is high enough most companies won't even consider competition, even if it was lower cost.

We desperately need more open frameworks for competition to work

The KVM just uses a devboard that's also sold separately and just happens to have a microphone, given how cheap the mics are having one extra SKU would probably just cost them more than savings.

Also I wouldn't really consider it "server room" product. Pretty much any new server has KVM, this is more "a hobbyist needing KVM for their home server"

The device is based on linux devboard so... yes

...you need a password to log in onto it to change it. That's hardly unique.

You could say "but they could make random one that is displayed on display!", but they also sell headless version with no display at all so that's not an option

I think what's most likely to happen here is that: * a developer that knew how it worked used it in code where he *wanted* to get the first line * someone just starting up copied it over and assumed that's the way to get the content of command into a variable

It's essentially complaining about using feature wrong on purpose, because the person that made mistake never learned the language.

my($var1, $var2...) is a way to multi-assign variables from an array.

and that makes perfect sense when you look at it. Perl have no multiple returns, but if you need a function that returns 2 variables it is very easy to make it work with:

    my ($bandwidth, $latency) = speedtest($host)

Perl's feature for returning different type depending on caller is definitely a confusing part but

    my @lines = `fortune`

returning lines makes perfect sense for the use case (you call external commands to parse its output, and if you do that you generally want it in lines, because then you can just do

   foreach my $line (`fortune`) {}

and it "just works".

Now you might ask "why make such shortcuts?". Well, one of big mistakes when making Perl is that it was also aimed as replacement for sed/awk for the oneliners, so language is peppered with "clever short ways to do stuff", and it's a pleasure to use in quick ad-hoc oneliners for CLI.... but then people try to use same cleverness in the actual code and it ends up with the unreadable mess people know Perl for.

the fact you can do

    my ($first_line, $second_line, ...) = `fortune`

is just the feature being.... consistent in its use "when you give it array, it will fill it with lines from the executed command"

you gave it array, and it just did what it does with arrays.

Perl made a mistake, the language was invested in depth of expression and that, in a programming language, just leads to a 1000 ways to write same thing where like... 2 of them are actually nice to read.

Pyton was ("was" was used here on purpose) the opposite, the whole "one way to do a thing" and insisting on more clean code even if more verbose.

You could write nice looking Perl code but you had to choose to do it, while Python pushed you in that direction from the start.

As much as I dislike using whitespace as flow control it also does make sure the code is always indented reasonably even if it is a newbie just starting in the language.

It didn't help that Perl, just like other languages after (PHP, JS, Python too), had a "curse of the newbie language", with many people starting with it (as at the time it was kinda only sensible choice for webpages before mod_php did a revolution in how most webpages are hosted), with no training and just winging it, which in language that puts no limits on what user can do and no guidance on what they should do... leads to that ugly one liners and line noise as a code scripts.

> the whole "one way to do a thing"

There’s a whole lot of words popularly excised (as you just did) from that line of the Zen to create a false polar opposite to Perl’s TMTOWTDI that was never actually part of Python’s philosophy.

The actual line from the Zen of Python is: “There should be one—and preferably only one—obvious way to do it.” (omissions in italics).

That is the story that Python tells about itself. Meanwhile, folks who don’t use it every day are constantly learning that it’s only true within a single version of Python, but that over the years there will be multiple, incompatible ways to do niche wild rare stuff like … iterating over a map.

...that's why I used "was". Current direction of the language mostly goes against the "Zen of Python".

Python has never actually followed the Zen of Python, which is one of my gripes with it. For example, "explicit is better than implicit" is a bad joke given how Python implicitly treats non-boolean types as booleans.

well, you'd get it at price of twice of current subscription

Yeah I don't know why people shame dung beetles with association to him

Well, there are more and less important parts of the car. I wouldn't bat an eye for 3d printed dash parts or the extreme example, a cup holder, but on flip side anywhere where there is heat is potentially bad for anything 3d printed with heat that's not metal or some hard to print high temp stuff, and anywhere where mechanical robustness = safety is spot where you want something very well tested, not "I printed it and it looks light".

but it didn't fail because of stress. It failed exactly because it was made from wrong material. If the exact same part was injection molded from the same material it would melt too