I'm curious, what does having control over the update process give you? Isn't it replacing one unauditable black box system for another?
Are you concerned about a regression and don't want to be in the vanguard cohort?
My car/motorcycle/skateboard doesn't need over the air updates. It used to be, and still is in some cases, that a vehicle (electronic control modules and all) was sold as a finished product. Your engine control module or speed controller didn't need random firmware updates because it was a finished product that worked as intended upon delivery.
Now people are clamoring to drive software licenses and I want no part of it. This isn't about auditing the code, this is about complexity creep and having ownership.
Well, there is the "my car has been disabled in an inconvenient time/location" problem for one. It would be nice to have more audibility but I use iOS/macOS/etc so it would be disingenuous to claim that as a show-stopper.
If by "vanguard cohort" you mean "in the first wave to test the new software," then yes; I don't want to be in that group.
I feel like being concerned about your car being disabled at an inconvenient time, but not being as concerned about your phone/laptop isn't disingenuous.
They're entirely different products, costs, use cases, risk profiles.
For the most part, yes. I do fly with ForeFlight though. Losing it mid-flight would not be a disaster in its own right but the tech has saved my life a few times.
The ForeFlight team will send out a message giving an "all clear" or a "wait for us to update the app before updating to the next iOS/iPadOS release."
Google has two billion lines of proprietary code, conformant to their style guides and proprietary requirements. I can't imagine they'd poison their model with non-conformant third party source.
English still uses the cognate "strand" to mean beach or riverside. The most famous is The Strand in London, along the Thames. It's a bit archaic sounding but is not too uncommon.
Likely familiar even if you haven't heard "strand" as such with that meaning: "stranded" (run aground on the beach).
One place where you might possibly have heard "strand" meaning the beach: Lewis Carroll. "The Walrus and the Carpenter were walking on the strand: / They wept like anything to see / Such quantities of sand. / 'If this were only cleared away,' / They said, 'it would be grand.'"
The way I (L1-english) have thought usage went is: "beestje" (as in "Huisje, Boompje, Beestje") is informal for animal, but "dier" (as in PvdD*) is formal.
“Beest” is a wild animal, or a savage being. It’s quite similar to English “beast”. “Beestje” is a diminutive that is affectionately applied to animals. “Dier” is neutral (not formal) “animal”.
The article suggest that it was neither. That rather it was an engineering decision: the product did not have staffing to be properly maintained, and rather than staff it up, it was easier to turn it down.
that's backwards - organisational/cultural/management decisions made it be under-staffed, which caused the code to rot, which led to the "oh, it's understaffed and the code rotted, let's just kill it".
I think there's very good reason to look past one blog post, people, come on.
If I am a higher-up executive in Google, I'm not going to much care what the numbers on RSS look like now, it takes less half a brain to understand that Google Reader has at least a CHANCE at chewing into the bottom line hard if it takes off -- even if those chances are slim. I'd kill it quickly as possible. If I can do so early, with little fanfare, even better.
They could be exploiting an undocumented/taboo feature of reality: simply telling people a good story can cause them to believe ("There is no reason at all to assume...") things that are not necessarily true.
Google is no such place. I've worked in several product areas, and while there is no formal one-size-fits-all process, generally engineers build products specified by PM written PRDs, often informed by UXR, designed by UX. At least for the last 12 years, it's not been a wild west of rogue engineers.
For Firefox to succeed, it has to differentiate. There are two meaningful ways it does, or will do, in the near future:
1. Mobile extensions: that's a unique value prop
2. Fight for the user: manifest v3, web environment integrity, and whatever comes next are degradations in user experience, and following a different path puts FF apart
The users who should care the most, such as the HN crowd, overwhelmingly have voted and the consensus is we read some synthetic benchmarks where Chrome is faster, and we are comfortable trading our freedoms away for that.
Everybody has a price.
It's just depressing that ours was so cheap.
(Not me personally. I would use FF even if it was worse, but it performs identically to Chrome for me. I don't understand what people are even doing with their f'ing web browsers that gets them into these pathological poor performance states with FF.)
There are build systems where this guidance isn't terribly valuable.
With Bazel for example, you typically have build files in each directory, and a test target for each test class in that build. But bazel allows you to select and run targets in a collection of directories, select targets recursively, or by a variety of other criteria. Your CI systems runs targets selected implicitly, while each build expresses the test targets explicitly.
Some (not all) still applies. I just reworked the Bazel CI at $DAYJOB to simplify the entry points and just call `bazel build //...` And `bazel test //...` erc rather than a bunch of more specific targets. We've got caching etc effective enough that just testing everything is a viable default even in a tight dev loop.
Context: I tried and failed at convincing management in moving my work monorepo to bazel. We have around 5 core languages plus a bunch of dsls.
If you don't mind sharing, what languages do you build in your bazel workspace? Were you able to use hermetic toolchains for these languages without any major hiccups? Finally, do you use engflow or buildbuddy atop bazel?
Not the parent, but at my previous job we used lots of JVM languages, plus some python and a tiny bit of JS. We were not particularly successful in getting truly hermetic builds with it - a big part of was a lack of headcount actually working on it.
My main takeaway is this: if you're the only one in the room asking for bazel, it's probably a bad choice. Bazel requires a lot of investment to stay nice to use, particularly in a polyglot environment. I've experienced endless friction getting things to work "in bazel" that would otherwise be simple using language-specific tooling.
In my opinion, the benefits (caching, build speed, a single build tool) did not outweigh the costs (nonstandard tool means you are always operating in hard-mode compared to using language-specific build tools, it's a ton of work to make actually hermetic, devs often aren't familiar with it and don't like writing BUILD files, editor support is extremely lacking outside of IntelliJ).
$DAYJOB codebase is mostly C++ and Python with a bit of custom configuration DSL for code generation.
Getting hermetic Python was pretty straight forward, hermetic C++ for cross-compilation to our target hardware was a bit more challenging but not too bad.
We also have VHDL which is built outside of Bazel for now. That's a job for 2024 and, I expect, will be a much bigger challenge.
We don't use BuildBuddy or EngFlow as we have some special requirements that made it not an option. I have a couple of personal projects using Buildbuddy though and it works well.
FWIW, I have had more luck with Pantsbuild rather than Blaze.
The fact that it does dependency inference has made adoption far easier. I've found the community pretty active on Slack too.
Using it to build Python/Java/Kotlin/Go/Docker; generally pretty happy with it, though the Python support is the best and the Go support is the weakest.
