It’s not perception as your friend alleges nor is it a conspiracy but rather all dwellings, apartments included, require continuous maintenance. Different levels of effort at different intervals. Skip it, and problems start to compound.
By the default nature of the bathroom being a humid environment (relative to the rest of any house), my wife and I squeegee our shower after each use, and attack the tile weekly in order to keep it free of mildew.
It’s easier for both the current tenants and landlords to defer maintenance by respectively, moving to a new building that matches your expectations and renting your unit to someone whose expectations matches the current state of the unit.
Both approaches don’t require addressing the previous maintenance “debt”. That’s why it feels like it’s all downhill after the first 2 years — either inside your unit, or in the building’s common spaces, or both.
I strongly dislike SUVs but due to transporting the kids around and their friends, my wife and I have switched vehicles during the week: she drives my sedan, I drive her SUV.
Being able to transport my oldest's friends around has resulted in improved relationships for both the kids, and the parents.
"Last minute sleepover after the game? No problem, I'll take your son and his gear in my car. We'll also pick up a pizza on the way back too. Drop off his toothbrush and pajamas at your convenience, after your other children are fed and bathed."
That's a briefer version of the exchange I had with a family last week, and their response was an audible sigh of relief, many thank yous, and an invite to dinner this weekend.
Your phone calls and SMS messages that touch the phone network, likely touch Oracle. Yes, nearly all of them.
For a tech-adjacent example of an acquisition of an entrenched supplier, look at Tekelec, a telecom hardware and software vendor which Oracle purchased in 2013[1].
Tekelec had a number of products but Oracle really cared about one: the EAGLE family, which is a suite of hardware and software for handling network signaling and routing over SS7. For any customer, EAGLE sits at the core of their networks and it is why your calls actually get connected and billed correctly.
EAGLE had a customer base that included nearly all of the important global telecom carriers. From the press release:
> Tekelec’s technology enables service providers to deliver, control and monetize innovative and personalized communications services and is utilized by more than 300 service providers in over 100 countries.
Verizon[2][3] runs EAGLE STP in their core, as does AT&T[4] (f/k/a SBC). Old business win press releases from Tekelec mean Bell Canada and Rogers still likely do. Based on job postings, Vodafone and Virgin Mobile use EAGLE STP for exchanging SS7 messages to/from roaming partners. And from public RFPs, the US Department of Defense[5] runs their own private phone networks, with EAGLE STP at the core.
Given how prevalent EAGLE deployments were in the early 2000s, how SS7 is needed to make the phone network functional, and how STPs are fixtures that do NOT get swapped out often, I feel very confident in saying that Oracle has had a supporting hand in most, if not all, of the phone calls and text messages you've placed since 2013.
> I've always advocated for having a read only database connection to be available for your customers to make their own visualisations.
Roughly three decades ago, that *was* the norm. One of the more popular tools for achieving that was Crystal Reports[1].
In the late 90s, it was almost routine for software vendors to bundle Crystal Reports with their software (very similar to how the MSSQL installer gets invoked by products), then configure an ODBC data source which connected to the appropriate database.
In my opinion, the primary stumbling block of this approach was the lack of a shared SQL query repository. So if you weren’t intimately aware with the data model you wanted to work with, you’d lose hours trying to figure it out on your own or rely on your colleagues sharing it via sneakernet or email.
Crystal Reports has since been acquired by SAP, and I haven’t touched it since the early ‘00s so I don’t know what it looks or functions like today.
It's important to know that these numbers will vary based on what you're measuring, your hardware architecture, and how your particular Python binary was built.
For example, my M4 Max running Python 3.14.2 from Homebrew (built, not poured) takes 19.73MB of RAM to launch the REPL (running `python3` at a prompt).
The same Python version launched on the same system with a single invocation for `time.sleep()`[1] takes 11.70MB.
My Intel Mac running Python 3.14.2 from Homebrew (poured) takes 37.22MB of RAM to launch the REPL and 9.48MB for `time.sleep`.
My number for "how much memory it's using" comes from running `ps auxw | grep python`, taking the value of the resident set size (RSS column), and dividing by 1,024.
1: python3 -c 'from time import sleep; sleep(100)'
If it really is cargo culting, and the people buying the physical product are not keeping the manufacturers in check because they never play the vinyl, then I can see a potential situation where manufacturers ramp up to meet "demand" but at lower quality (improved profits).
The secondhand market becomes saturated with inferior pressings that are inevitably bound for landfills since they don't meet the quality/expectations of the people who actually play vinyl.
We (as an industry) went through this bad batch madness with the IBM DeskStar 75GXP hard drives, which were affectionately referred to as "IBM Deathstar"[1].
It's rare, but it's not _that_ rare. You have to make the effort to understand why it failed.
I had a situation where I deployed Toshiba SLC SSDs (that were purchased over the course of several months) and a piece of software that synchronized to disk frequently, resulting in about 1GB of writes per hour.
After ~11 months in service, most of the drives died in the same 4 week period. We were astounded that everything failed so close to each other, including instances where both drives in a RAID 1 set were toast.
We did extensive troubleshooting between the failed servers and the remaining servers and figured out that write volume (by proxy of in-service date) was the one predictor of failure. Shortly thereafter, wear leveling and TRIM became things we sought out mentions of when spec'ing out hardware.