Hacker News new | ask | show | jobs
by adhesive_wombat 1465 days ago
If your software works only on Windows, you've written non-portable software. Likely, you have all your core logic mixed up with Windowsy UI and now you're stuck there.

If it works on Windows and Mac, you've written portable software but just can't be bothered to support Linux. At a guess the problem is that you want to ship binaries only and don't want to deal with doing all the packaging and testing for Linux.

For a consumer hardware company, one wonders what the benefit is to binaries-only unless you're hoping to charge a subscription for the software to run hardware you already bought. Or the software is such a mess internally that you'd feel ashamed of it were public (which I can understand, having seen commercial code). Or you have some security feature that you don't want to reveal (e.g. disallowing use of your software with third-party hardware). However, if someone wants to reverse your software methods, they'll find a way.

Perhaps naively, my thought would be that if you want to sell hardware and not software, an excellent consumer-grade and consumer-priced camera platform with an open hardware interface and a decent reference implementation would actually find a lot of uses on embedded (i.e. probably Linux) platforms.

6 comments

When you write drivers there's no such thing as portable code. You need to target different APIs, different environment assumptions, etc. Sure, there's some common core most likely, but I think this rant is misplaced when talking about a hardware company.

The software postprocessing is a different question and could be more common... But you're still specialising it for DX / v4l2+gui / whatever macos uses. That said... I'd kill for an independent library for video processing that specialises in camera outputs - beyond different profiles, there's no technical reason that couldn't be used independently of hardware.

Maybe in 2002, but it's a USB webcam in 2022, if you're writing your own drivers from scratch on any platform rather than using the standards-compliant ones, I'd first wonder if you haven't got a case of NIH syndrome rather than an actual case of being constrained by the standards.

But maybe they genuinely cannot use standard protocols for some reason, then sure, writing a Linux driver might not be worth it.

I'm half assuming they do something special, half responding to the comment which describes them as a hardware company. But yes, ideally a webcam should have the basic functionality available just by plugging it in, no special software needed.
The postprocessing should be done in the cam though, IMO.. And it should just give the result back ideally in a standard format.

But I would prefer better optics and sensors over AI stuff like many others have mentioned. When you have good video you have much less need to fiddle with it.

I worked for a company that did pre-infiniband HPC interconnect drivers (Myricom) in the 2000s. We supported N-different *nixes (Linux, Solaris, FreeBSD, Tru64, Aix, and probably more I'm forgetting), Mac OS X and Windows in the same codebase. At least 50% of the driver and 95% of the userspace code was OS independent. In order to do this, our drivers were not "typical" drivers. Eg, we used ioctls everywhere (even on OSX) for driver/library communication.
I don't really get this. Linux has had the same problem with audio interfaces, and you know what the solution was? Class-compliant USB peripherals. That's probably what people are asking for here: nobody wants to install additional software to make their webcam work, so why can't the processing be done on-device (especially if they're charging $200!).
If there are selling undifferentiated hardware supported by smart / magic software, they need to block people from running their fancy software on somebody else’s cheap hardware.

If they want to get paid for the magic, it will be more expensive to buy hardware from them than it is to buy equivalent hardware elsewhere. How do they get you to buy their product?

> if it works on Windows and Mac, you've written portable software but just can't be bothered to support Linux

Or they wrote different, non-portable software for each os.

My thinking was that it might use some platform-specific APIs for that AI stuff it mentions, or maybe it requires some non-standard extensions because of it. Whether that's a good design or not is kinda besides the point here.

I might be interested in this camera, and asking support will likely only generate "we only support Windows and macOS" without any nuance, so I figured I'd ask here. Better ask before spending $200.

Could you tl'dr? My naive reading of your comment doesn't help.
How heavily simplified do you need it?

Doesn't seem that hard to follow (nor an especially long read worthy of shortening) but everyone's different.

It may be confusing because it's in reply to "Does Lumina work on Linux?" but doesn't answer that question. The tl;dr of the answer would be, "there's reasons it might not work, but I don't know"