Manfred

I don't think that's a convincing argument unless you are a tiny company that has to optimize for development time. You can also wonder why the frameworks you are using make this hard, because it's a pretty common to want feedback close to where the action happens.

Unfortunately it's very likely the button will be gone in favor of Face ID and it's going to use the case design of a previous model so it will get bigger. It's going to suck to operate when wearing a helmet and glasses.

It's also surprising how quickly companies are giving up their strict access control by letting employees basically search through everything. I'm used to customers asking for more fine-grained access rules, not less strict.

Given the widespread misuse of these systems (eg. "I'm going to look up my friend's bank account for fun"), that doesn't seem like a great strategy.

I think that's the biggest issue with code signing, Xcode should come with a "Sign and Notarize.app" that allows you to sign anything you point it at with a single click.

Not sure what you want to do exactly, but https://github.com/harlanc/xiu could be a fit.

Let's say I almost got into an accident and I did two things: use my brakes and close my eyes. Does that mean that closing your eyes is good for curing a rash?

I assume you mean "if the buyer will use the software in critical systems."

That's very realistic and already happens by requiring certain standards from the resulting product. For example, there are security standards and auditing requirements for medical systems, payment systems, cars, planes, etc.

I meant critical software a short-hand for something like: quality of software should be proportional to the amount of disruption caused by downtime.

Point of sale in a records store, less important. Point of sale in a pharmacy, could be problematic. Web shop customer call center, less important. Emergency services call center, could be problematic.

Nothing is without flaws, it's about limiting risk to an acceptable amount. Critical software should be held against higher standards.

All these things matter when you try to build an enduring company instead of the embrace, squeeze, and run strategy. I don't think that happens a lot any more, if we are lucky one company might keep its course for 20 years and then it gets sold or the founder moves on.

To be precise, the first study mentioned is from 2011, then 1989, 1987, then studies done in the 1990's.

Not necessarily. JSON is used in a lot of places, also for large documents in data lakes and archives. It's useful to be able to query them with tools.

It's certainly possible, but Logidze can't do that.

One solution not mentioned in the article is writing entries to something like Logstash or other similar services specifically built for handling event logs.

With AWS you also buy a scapegoat because it's much easier to explain to superiors or investors when a large cloud service has downtime than it is to explain the same cumulative downtime caused by human error in your team.

I got to borrow one those Burroughs machines when I was 16 from a collector and they were really well built, but not great for a teen that wanted color screens and games. I did learn a tiny bit of Fortran.

This is exactly the nuance and historical context that I was missing in the article :)

I will miss the handy subscription overview and a minimal amount of clicks to cancel or request a refund. I wish we could have both.

Some of these company's portfolios will be too big to keep. Imagine what would happen if YouTube stopped existing? Who has enough capital to store billions of hours of video other than Alphabet?

What is exactly the problem with individual apps in your opinion? This not a weird jab, I'm actually curious.

Acquiring something that isn't your property is not legal in most countries. It's not really relevant if it's behind a door.

From the comments I get the impression that we have all worked with someone that would have considered this an actual solution and we had to talk them out of it.

Because those are platform dependent, you can't run an ARM image on X64 for example.

I would assume they made this statement because they want to protect their brand and not because they think he is or isn't less likely to cause an accident.

It's called “civil disobedience” and sometimes it's the only way for people to leverage some sort of power.

The delivery of a text depends on the literary goal of the author.

When you created or found a new way do approach development and you want to spread that idea, you want to persuade.

Alternatively you may want to inform, for example when you teach or journal. In which case you write down the facts without embellishing them.

Finally you may want to do a critical review, then you explain the method in relation to other methods and existing practices. Pros and cons, etc.

The hope is that the reader will understand these goals and adopt it into their own beliefs as they see fit in relation on how it was presented.

One of my students in a summer school class about programming just couldn't get their head around what a variable was. These concepts are very hard to teach when you are very familiar with them and they come natural to you.

People will gladly accept bad proofs if it furthers their beliefs or identify politics. They will also argue wrongfully against correct proofs. And they will influence others.

I assume that's the point of the article; people who are not educated to identify nonsense will accept nonsense or decide to trust nothing.

This is obviously very ham-fisted, but I believe that's the idea.

The library is specifically meant for safely replacing legacy implementations and they generally aren't that well structured.

People usually commit code that is written by code assistants intermixed with their own changes. You would not be able to track it, even on first commit.