There are now headlights that can be “high” but block out portions of the beam directed at light sources like oncoming headlights. Can’t have them in the US though.

Unfortunately, the ecosystem around github has evolved so that most folks centralize their testing and deployment code into being executed on github infrastructure. Frankly a perversion of the decentralized design of git.

Fortunately for my team, it doesn’t matter because our process requires stuff that can’t be done from github infrastructure anyway, so we have kept the automatic testing and deployment on premise even as github is the ‘canonical’ place for the code to live.

That’s like 2 or 3 fentanyl pills, if I understand Bondi right…

Always_has_been.jpg

Notably, Phenylephrine was approved in pill form for decongestion, and is all over the place… but doesn’t do a damn thing. Trying to keep pseudoephedrine limited in the market to try to fight meth.

I don’t see anywhere where I said that…

Wow, my local Waffle House has got some fierce competition here.

Why do you seem convinced I can’t possibly be a software developer? Evidently your development career has given you one experience with a company that takes the task with a great deal of seriousness and I’ve seen that happen, but a lot of companies are not so diligent and either try to game things best they can either with like two people making git commits or an army of offshore developers that seem to quit within 6 months leaving little competency and plenty of opportunity for a bad actor to get in the door.

I do this not because it is easy, but because I am hard.

A project at work is evidently at least 25 years and counting of being about 6 months away from being successful.

By relative volume of the known things. It’s not a guarantee, but it’s highly suggestive that the more observable instances of something, the more not yet observed instances of the same thing are out there.

There are factors that can knock that out of balance, like not having access to source code making things harder to find, but those confounding factors would hide more on the closed source side than the open source side.

Probably not. 15 years is not that long, what do I know, I’m just on senior expert level.

Longevity is not a guarantee of broad exposure. It may mean you have deep exposure, but making the rounds around the industry I can’t imagine maintaining such a universally optimistic picture of commercial management of software development.

Companies run skeleton crews on crap products that don’t make money.

Companies run skeleton crews on products when they think they can get away with it. Very high profile commercial projects with a lot of analyst attention may not be able to get away with it, but some surprisingly high profile projects without quite as much scrutiny get away with more than you would guess.

This is where your lack of knowledge about products like that shines through.

I’m speaking from familiarity with the provider side of things, wondering when a customer will catch on that they can’t seem to get that awesome support unless it’s the same guy as their peers get, and suspiciously unable to get decent support for a random week in June or something.

From what you are writing you aren’t a programmer and you haven’t worked in a software corporation before

Incorrect assumption on both counts. A few companies across a couple of decades and two of those companies extensively engaging with other companies on projects to get me some exposure to closed source development organizations even at some other companies.

If OpenSSL was for-profit, it would be a corporate project with dozens if not hundreds of developers

It seems like you don’t have a very broad exposure to closed source development. Corporations frequently have a skeleton crew working on a component or entire project. You might notice if you get escalated to development enough that it’s always like the same guy or two. It’s because they might only have a couple of guys working on it. Some companies will spend more on measures to obfuscate that reality than they would spend on actually developing. Certainly some corp closed source projects are that big, but so too are many open source projects.

Hell I’ve dealt with financial institutions using proprietary software that was abandoned by their vendor 15 years prior (came up because the software no longer worked with new stuff, and the institutions demanded wrapper software for new stuff to imitate the old stuff enough to keep using the unmaintained, unpatched, zero developer project).

I also don’t think companies are holding the proprietary vendors to quite the standard you imagine, certainly not automatically. By the same logic you propose for open source “someone else must have done it”, you also have that for big companies, if not more so. “Surely they have good security practices” or “it’s so popular someone must have done that”.

Well, at least Nissan and Mitsubishi aren’t doing exactly great.

I find Stellantis utterly confounding how they still exist as they are. So much mismanagement and yet somehow still alive.

Or even a PR step

Sorry, there’s no business case for rebasing those dependencies. Please focus story points on active marketing requirements instead.

Yeah, you open a bug like that in proprietary software and it will immediately get rationalized away as having no business case to address, likely with a person with zero direct development responsibility writing a bs explanation like the small impact was due to a number of architectural changes.

Speaking as someone with years of exposure to business managed issue handling.

Evidence suggests this isn’t the case.

We know of so many more closed source backdoors despite them being harder to notice in practice. Either before they became a problem or after they have been used in an attack. So we know backdoors can get noticed even without access to source code.

Meanwhile we have comparatively fewer backdoor type findings in major open source software, despite and thanks to increased scrutiny. So many people want to pad their resume with “findings” and go hit up open source software relentlessly. This can be obnoxious because many of the findings are flat out incorrect or have no actual security implications, but among the noise is a relatively higher likelihood that real issues get noticed.

The nature of the xz attack shows the increased complexity associated with attempting to back door open source. Sneaking a malicious binary patch into test data, because the source code would be too obvious, and having to hide asking the patch in an obfuscated way in build scripts that would only apply in theory under specific circumstances. Meanwhile the closed source backdoors have frequently been pretty straightforward but still managed to ship and not be detected.

Even if we failed to detect unused backdoors, at some point someone would actually want to use their backdoor, so they should be found at some point.

You don’t have to stage a scene, you can use modern displays, optics, and sensors to inject ‘digital’ strategies into the ‘analog’ approach.

The conceptual issue here is that most attempts at denying the legitimacy of content are not by people who actually operate the given equipment.

If a celebrity claims some third party footage is fake, that celebrity is not the one that would vouch/not vouch for it. If a paparazzi does something wrong, they’d sign it and say “yes it’s authentic”.

Now maybe you can say “Canon genuine” to say it’s not the person, but the camera vendor, but again, with the right setup, you can good old analog feed doctored stuff into a legitimate sensor and get that signature.

Since the anchor for the signature almost never rests with the person who would ever contest the content, it’s of limited use.

Traditional signing is enough to say “If I trust the AP, then I trust this image that the AP signed”, no distributed ledger really suggested in this use case, since the trust is entirely around the identity of the originator, not based on consensus.

It’s awesome that it gives you cooking tips you’ll find no where else, like adding glue to improve the consistency of cheese. Or making sure you get your recommended daily serving amount of rocks.