It's weird to read the same HN crowd that decries monopolies and extols the virtues of competition turn around and complain about job duplication and "bullshit jobs" like marketing and advertising that arise from competition.
Why didn't ABC fund the whole shebang? I suspect the BBC has a much bigger warchest to deploy - recalling the ludicrous amounts invested into Top Gear or the numerous David Attenborough nature shows.
Even the BBC war chest appears to be dwindling. Or at least it’s become harder to produce things on their own. The latest seasons of Dr Who are produced in collaboration with Disney.
But yes, they would have had bigger reach, and we might not have gotten this far without the BBC. I just want the ABC to have got a more significant chunk.
How do you trace the origin of breaking changes, especially those arising from integration problems? For fairly busy codebases (>10 commits per day), and a certain subset of regressions, bisect is invaluable in finding the root cause. you can always do it the "hard way", so it's not the only way
I don't really ever find myself having to do that. I guess it's been a long time since I worked in an environment which did not use an "only merge to main after passing CI" workflow, and back then we weren't using git, anyway.
There was one git-using startup I worked for which had a merge-recklessly development style, and there was one occasion when I could have used `git bisect` to disprove my coworker's accusation that I had thoughtlessly broken the build (it was him, actually, and, yuck - what a toxic work environment!), but the commit in question was like HEAD~3 so it would probably have taken me longer to use git bisect than to just test it by hand.
> I don't really ever find myself having to do that. I guess it's been a long time since I worked in an environment which did not use an "only merge to main after passing CI" workflow, and back then we weren't using git, anyway.
You _never_ have bugs that slip through the test suite? That is extremely impressive / borderline impossible. Even highly tested gold-standard projects like SQLite see bugs in production.
And once you find a regression that wasn't covered by your test suite, the fastest way to find where it originated is often git bisect.
Bugs that slip through the test suite and it's important to trace the origin and it requires building more than a couple best-guess versions to find it. And even then, if it wastes an hour or two once in a blue moon that's not a big motivator for workflow changes.
You're skeptical of a far stronger claim than the one they actually made.
> I guess it's been a long time since I worked in an environment which did not use an "only merge to main after passing CI"
It's the same for me, but some integration bugs still escape the notice of unit tests. Examples from memory: a specific subset users being thrown into an endless redirect due to a cookie rename that wasn't propagated across all sub-systems on the backend, multiple instances of run-time errors that resulted from dependency version mismatches (dynamic loading), and a new notification banner element covering critical UI elements on an infrequently used page - effectively conflicting CSS position. In all these cases, the CI tests were passing, but passing tests don't mean your software is working as expected in all cases.
I also find git bisect to be useful, but very rarely and never for personal projets.
In the cases you mentioned, robust e2e and integration tests would ideally be able to catch the bugs. And for the UI issue in particular, I wouldn't think to track down the commit that caused it, but just fix it and move on.
> Dooring people aside, what do you do if someone just leaves the door open when they leave their ride?!
Continue billing them for the ride and send an app notification or phone-call to their phone.
Other potential solutions: If the door is still not closed after n minutes, plead with passers-by, or offer a passing or nearby rider the chance to earn credit by closing the door.
You make it sound like there is a way to compete against the same organizations if they funded the development of the software - it's not possible to compete against hyperscalers, period. Now that Amazon is funding a fork, is Redis, Inc in a better or worse position to compete?
> it would be great if other companies with janky licenses could see "Redis relicensed to open source and had a great boost out of it", not 'Redis relicensed to open source and it didn't help them at all".
If the other companies can't figure out that adopting a janky license and alienating the community is the self-inflicted problem, then they are beyond help. Relicensing to open source not helping the company may serve as a cautionary tale for other companies and may prevent them from repeating the same mistake. As an open source enthusiast, the worst case scenario is companies switching licenses tactically and frequently to test the waters and walking back with no consequences; I'd prefer the cost of such actions to be swift and severe.
Compromise the device of one of his contact and send him a juicy link via telegram that renders "Error: Not viewable on mobile" when opened a phone. Bonus points if the link has 0-day malware dropper
Not really, if the evil maid is sophisticated enough to bring their own firmware to reflash your devices, they could also just swap the PCB containing the controller or solder in a new chip
I chose the word counters rather than eliminate for the reason you outlined.
If you're the vendor, you can add a tamper-resistant or tamper-evident design to raise the cost of ,component-replacement attacks. Which can be countered by whole-device replacement, which in turn is countered by device identity attestation, amd so on, in an endless arms-race.
Tamper-evident stuff and device attestation solve all these problems even without preventing reflashing. If you can't check if the device has been tampered with or replaced, preventing flashing won't help. If you can, you don't need to.
Reminds me of a story told by someone who was an intern or assistant for a politician (or consultant?) way back in the day before social media. They recount their first experience watching the politician at a town hall - they were late and apologetic, and gave a speech that was funny, compelling and authentic and the crowd ate it up.
They attended the next town hall, and the principal was late again, and proceeded to give the same speech, beat for beat. The same routine was repeated dozens more times at dozens of locations with different audiences, save for the politicians staff. In truth, the politician was not as funny or as sincere as the practiced speech and routine made them seem.
All this to say; acting funny or brilliant behind closed doors without cameras rolling doesn't mean you actually are those things. It's easy to recycle the same schtick after years of honing it and figuring out what works and what doesn't, Trump has impeccable showman instincts.
With Johnson I at least had the impression that he understood the showmanship aspect of it really well. Less so with Trump, at least it seems less polished.
It indeed was Boris - thank you! It's weird to compare my faulty recollection to the actual account; only 2 occasions narrated, not dozens - though it is implied, and the narrator wasn't an intern.
reply