Interesting that you think the two are mutually exclusive. Personally, I'd consider consulting advice to systematically hook an entire country onto opioids to be "useless BS" much in the same way I'd consider schemes to fix bread prices as "useless BS". Both are cases of rather obvious approaches that are not only legally and ethically bankrupt, but more importantly fundamentally unsound and unsustainable as growth strategies.
My takeaway is that this is a good example to keep in mind when considering architectural diversity, whether in software or hardware. Can your business take the hit if/when Apple/Microsoft/Amazon enter your industry, as a direct competitor, using your own platform and established userbase against you?
Being fully-invested in one distro in the first place seems like an old-school approach to me, and I'd assume that, with distros like Alpine and BusyBox (maybe even throw macOS in there), it's more common for most people to deal with multiple distros than they're giving credit for. I've more or less gotten used to the cycle of figuring out which launch system and package manager I'm dealing with for any given system and having Google/StackOverflow open for the things I forget.
I think it has less to do with everyone switching to Apple silicon and more to do with the clarification of viable business models: you either become an IP company and outsource production (AMD) or you go completely vertical and design and produce custom-designed SoCs to be used exclusively in your consumer products (Apple). The Intel model of designing and producing all-purpose commodity CPUs seems to have hit a wall due to both lack of demand and unanticipated manufacturing problems.
One of the common threads in media critiques like Manufacturing Consent and Hate, Inc. is that direct editorial control is not necessary in order to promote your agenda. Control of money and access, along with ideological indoctrination of journalists at elite universities, is all that's needed. See also my comment below about NPR listenership and trust in Amazon as an institution.
Amazon was recently polled to be the most trusted institution among US Democrats [0], which comprises the majority of NPR's listenership and donors. They know what they're doing.
I can't be the only one not shedding a single tear for the five 65-year-old tech retirees who have the time on their hands to perform manual repairs on their consumer devices.
idk if you've ever run into it, but `process.exit` has been a bit of a footgun in our node apps due to broken pipes and (sometimes) async io with `console`
The only thing that annoys me about Safari is that there's no way to disable or configure alternate search engines for the omnibar. Sending mistyped intranet urls directly to Google (or DuckDuckGo) search is a huge privacy hole.
- Do I trust my code to run on a machine where /bin/bash doesn't work?
- Do I trust my users to have their PATH configured correctly?
IME a user misconfiguring ~/.bashrc is about seven million times more likely than some theoretical argument about "portability", or even the idea that running my code on some unspecified version of bash that a mac user accidentally downloaded while screwing up a Homebrew copy/paste command is preferable to using the factory default that everyone has.
I saw this headline and kind of winced because I just finished doing battle with our webpack config(s), but top-level await, automatic Worker entry points, cjs tree shaking, and import.meta support are huge! I'm also grateful for the removal of Node polyfilling -- it tends to just add confusion when you're testing across different environments.
depending on what im doing, i'll do squashing, fixups, and commit reordering in an interactive rebase prior to merging to at least reduce the number of noise commits.
the question of trust is the wrong question to ask imo. the bigger threat is unmaintained packages and maintainers that themselves use risky code management practices (e.g., lack of 2fa on npm). that a dependency is heavily relied on does not mean its maintainer is following best practices security-wise or that they arent just as susceptible to social engineering as anyone else.
If that's actually what you wrote, I would be annoyed as a maintainer. There's an implied assumption here that "command X" was never tested and must therefore crash for everyone. In 99% of cases, "command X" runs without issue and has been tested on multiple configurations. If it turns out that "command X" crashes for you because your company's IT department misconfigured the certificate authorities on a particular Windows build image, you end up wasting massive amounts of everyone's time. After maintainers get burned by these kind of bug reports tens of times, they understandably get hostile to such low effort bug reporting.
> Between the creator and consumer, choices should be available and not restricted to any specific platform.
So don't, then. Apple doesn't force developers to make iPhone exclusive content. And consumers are not forced to use only one device. This whole issue is merely developers complaining that they want cheaper access to the most lucrative markets. It has nothing to do with consumers.
Shipping India's able-bodied workforce to the US and driving the rest of the local economy with low-wage factory jobs absolutely hampers a country's ability to govern and develop itself. The threat of pulling manufacturing out of a country becomes too great and forces governments to bend to the will of foreign investment.