throwaway98434

Criticizing a religion is not the same thing as dehumanizing its followers.

Dehumanization is a defense mechanism which helps us avoid feeling the pain of realizing that humans sometimes do (subjectively) abhorrent things. It's seductive to define such people outside the bounds of humanity as it allows us to excuse treating them poorly. It is nearly always a mistake to do so, because people are, in fact, people.

There are multiple points where averaging is employed.

FMR is a close to median value. From the linked definition: "The FMR is the 40th percentile of gross rents for typical, non-substandard rental units occupied by recent movers in a local housing market"

Additionally, FMR is itself statewide average, covering both high and low cost of living areas. Low cost of living counties have units available for far below FMR values.

Low end housing in low cost of living areas can be found for under $377/mo - their estimate of affordable minimum wage rent.

FMR is a close to median value. From the linked definition:

"The FMR is the 40th percentile of gross rents for typical, non-substandard rental units occupied by recent movers in a local housing market"

Minimum wage is not a 40th percentile income.

This article like so many others makes a critical mistake in using a median price for minimum earners.

A minimum wage earner is not and should not be in the market for a median priced home.

A median wage earner would pursue a median priced home.

A bottom quartile earner would pursue homes priced in the bottom quartile. Not the median.

The title of this article is false. Minimum wage earners can often afford two bedroom homes priced at the lower end.

The unix filesystem api doesn't provide a way to interact with sectors. The primitives are files and the methods available are writing more data, or truncating.

There is no function provided for shifting the byte offset of data in a file.

You can write an entirely new file, of course, but the question has an implicit goal of doing this efficiently.

Generally speaking theft requires an intent to deprive an owner of property. It's a crime to take my bike intending to deprive me of it, but it's not a crime to take my bike while attempting to return it to me.

Property owners do not have any obligation to lock up their items.

There are sometimes very specific laws regarding found property when the owner cannot be located, generally these involve turning the property over to the state first.

At scale, rare errors will occur on a semi-regular basis.

Multi-day outages tend to be indicative of a dysfunctional internal organization.

I'm discussing the problem of collections of python scripts using /usr/bin/python and I included the state of RHEL7 as an example.

The actual subject is CoolGuySteve's build system, which is likely to look like my example of RHEL7 rather than yours of ubuntu. The vast majority of environments look like RHEL7 or CoolGuySteve's build system where #!/usr/bin/python is the norm.

Right, someone working in ubuntu distro development has done this work for those packages specifically.

Above, we're discussing some build system where someone hasn't done this work. Most collections of python code in the world (I'm going to hazard a guess significantly upward of 90%) just use /usr/bin/python or /usr/bin/env python.

That's the nature of the problem.

Trespass to chattels. This is an intentional tort: The stated goal is to impair the property of the neighbor.

CoolGuySteve complained that things will break because existing scripts assume /usr/bin/python. CoolGuySteve is correct. There is an enormous amount of work involved in changing or removing the function of /usr/bin/python.

Offering advice about how to write new software does nothing to help with the frustration he highlighted: His existing build systems will break. Build systems are especially frustrating as they tend to have hacked-together code that no one really wants to look at.

People will often work around this by installing a python2 as /usr/bin/python. At the end of the day this change results in a less predictable platform. On previous RHEL systems I know what /usr/bin/foo is -- it's predictable given the major version of the distro. But now I won't know what /usr/bin/python is on RHEL8. It will be uniquely different and that's not a good thing.

You say "you" as if you're talking to the person you're replying to. Most scripts in the world aren't authored by the person you're replying to. They're powerless to change the ocean of python out in the world.

For example, out of about 50 or so /usr/bin/python scripts I see in a RHEL7's /usr/bin I can't find a single one that runs on python3.

No individual user is going to be fixing this. It's a very silly and shortsighted move on RedHat's part.