We have exactly one piece of data on this case right now, which is the filed legal complaint. As a parody of corporate espionage, it's excellent, but as a piece of evidence… I would treat it with about the same seriousness as a parody of corporate espionage. Rippling has some incentive not to lie outright, but none whatsoever not to exaggerate the living heck out of everything. And so that leaves us with one unreliable document, and general background information on the parties, or "vibes" as you dismiss it. And the general background is that Rippling is litigious and clearly has a preexisting axe to grind with Deel.
> Rippling has some incentive not to lie outright, but none whatsoever not to exaggerate the living heck out of everything.
What could have been exaggerated in the honeypot story? That seems pretty damning and they would be able to provide evidence to back it up (e.g. Slack access logs and the email).
I expect that has to do with the properties of the human eye, and the fact that the lumen is defined in terms of those properties. I doubt white LEDs are significantly more efficient than any other color in terms of EM flux per watt, but a relatively large proportion of those emissions are at wavelengths to which the retina is sensitive.
Cribbing off [another comment](https://news.ycombinator.com/item?id=38222198), there's as much as 72kW of lighting being focused on a few square meters of the plane's skin. Direct sunlight at noon at the equator is roughly 1kW/m²; the artificial lighting here is well over an order of magnitude brighter than the sun.
Hence my suggestion that the Debian project distribute a script that I can run to get the firmware myself & trivially build my own install CD, and that this be prominently advertised on debian.org.
The Debian project already ships that sort of script in the current non-free firmware CD, so clearly it's not a legal issue. What it doesn't ship is the ability to run that on another machine as part of preparing an ISO to install on a fresh machine that needs the proprietary firmware.
This (and checkinstall) are stopgaps, ideally the .deb creation process would get an entirely new packaging toolchain, with the minimal arguments: dependencies, build-dependencies, sourcefile/url/repo, buildcommands.
Then a linter could tell you that a changelog.Debian.gz, man-pages and debtags are still missing, but for internal redistribution that is enough for now.
And can failed build commands continue from where they were interrupted? Always cleaning everything is terrible for iterative exploration of the package creation process. The final package should be marked as tainted of course, but always starting a minute long compile process should be skippable.
