I'd agree with that assessment and go further. Their ability to manage basic self-care is impaired. I hesitate to use my generation (Gen X) as an example, because I think we were on an extreme of borderline neglect, but there's something about Gen Z/alpha that just screams borderline abuse on the other end of that spectrum.
Yes and no. Being a child of the late 70s and early 80s I "predate" most of modern social media. We weren't connected the same way Gen Z and Alpha have been. My generation knows what it's like to not live in a social media bubble, and have the experience/knowledge of how to live without it. These kids have never had that. All they know is the narcissism and peer validation style of this new world. So in some sense "willing" is a bit strong of a word to use here.
Streaming has become the new cable: a bunch of piecemeal services with mostly terrible content and a few gems each, with their own pricing plans and ad models. I have no interest in subscribing to all of them or even most of them. There's just too much junk, too many different subscriptions to monitor, and too much deception in their ad models (if I pay for "no ads" and see a 30 second unskippable ad for the service's content before every show that's a dealbreaker--AMC+ does this).
This isn't (just) a regulator issue: it's a market issue. There just aren't many new engines produced every year, because there isn't demand for it. Owning an airplane is expensive, even on the lowest GA end. It's a hobby for the affluent and wealthy. The market just isn't that big. On the extreme side--private jets for the ultra-wealthy--it may be different (I wouldn't know; I'm a lowly 7-figure net worther, barely "rich" by this standard, and owning a private multi-engine jet is well beyond my means).
The GA engines in the aircraft I've flown (all Cirrus) do "just work". I have had trouble starting one once, but it was already hot and I had to fiddle with the mixture and throttle during and immediately after turnover. I have yet to encounter engine issues in-flight (but I don't have a ton of flying hours, either).
What's amusing to me is the juxtaposition of this old tech in the engines vs. the sophisticated avionics and surface controls in these aircraft. The Cirrus aircraft I fly have advanced garmin avionics, including terrain maps, airspace maps, ADS-B integrations, GPS navigation, autopilot, etc. Yet there I sit, fiddling with mixture, ensuring alternate/backup inputs are available in case something goes awry, and dealing with dumb non-linear responses in the throttle because the engine is using tech that's literally decades old and hasn't changed (much) in the last 50 years. There's an upside to this, I guess: I have a number of levers (literally) to pull if something is out of whack, and it creates a kind of weird redundancy/safeguard system to manage various failures. On the other hand, because all these things have to work together, it's entirely possible for weird failure modes to occur that cascade/build on each other unrecoverably.
I can't wait to get my hands on the new jet powered plane coming to the club I fly with.
There is also a demand issue aside from change-hating curmudgeons. There simply isn't a large enough market for GA planes for companies to justify the cost of research and development, and even though planes aren't cheap GA plane purchasers can still be fairly cost sensitive.
I don't know much about Blender, but the other two, at least, have had substantial contributions by paid engineers (at big, well-known corporations), and likely input from non-engineers (e.g. product staff). They're exceptions to the rule of (F)OSS.
That's a great point, too. Software applications are more than the code in them. All those other folks are required to make an application good. I think the "whatever reason" for these people is the same as for the engineers, though: they gotta pay rent, and working for free doesn't do that.
FOSS offerings are almost always worse than their commercial competitors because of one obvious thing: people (that includes software engineers) need to eat and have shelter, and for 99.9% of us that means working for a living. Companies pay people to work on products that other people buy, ideally at a profit for the company. FOSS creators are rarely compensated meaningfully compared to the effort put in. The natural consequence of this is that most good engineers are not going to put much, if any, time in developing FOSS applications. The natural consequence of that is that these offerings aren't going to be as good.
They key part you're missing is the "without checking prior experience." I taxiid, performed a takeoff, and most of the landing approach on my first training flight, too. The instructor briefed me thoroughly before the flight, inspected my logbook, etc. Every instructor I had after that checked my logbook and the school's internal note keeping system for notes during the pre-flight brief (I'd bet many did before then, too). It is absolutely not normal for a flight instructor to not do these things.
I’m not saying simulators are useless. Neither is “chair flying.” Believing that they prepare someone to pre-flight, start, taxi and takeoff and recover from a spin entered while under a hood from training day one is entirely a different matter.
It's not dangerous to hire a CFI to give lessons. Arrogance (even if it's unintentional) about one's own competence is dangerous in the pilot seat, even with a CFI in the other seat to monitor and try to take over if/when this person does something dangerous. Imagine a trainee filled with the OP's nonsense in his head thinking he can recover from a spin forcing the CFI having to fight him for control of the airplane, for example. Or maybe he lies and says he has more experience than he does, and the CFI fails to do his diligence (e.g. checking the trainee's logbook): even merely starting the engine can be a disaster waiting to unfold, much the more so taxiing or, god forbid luck get the trainee that far, takeoff.
People reading the parent comment should be skeptical. It’s very likely at minimum an embellishment. More likely it’s simply a blatant fiction. Don’t be “that guy”: years of playing desktop flight sim does not prepare a person for even the most basic maneuvering in a real plane, whether on the ground or in the air.
I’m downvoting the comment because I think it’s misleading and potentially encouraging dangerous behavior.
I’m skeptical. To the point where I’ll happily call BS. Taxiing and flying a real plane is substantially different from flying MS flight sim. The physical responses of the plane to control inputs, thrust, and external forces can only be approximated by an actual physical simulator, not a desktop video game.
There are other problems with the narrative, too. Instructors will generally get a much better idea of where the student is in their training and brief them pre-flight on the maneuvers to be practiced during the training flight. The instructor would have reviewed the trainee’s logbook, which should contain notes from prior training flights as well. Unless this instructor was exceptionally careless, he’d have discovered the commenter’s inexperience pre-flight. Also, the abnormal attitude/configuration the instructor put the plane in and the recovery described sounds dangerously close to a spin. It’s unlikely an instructor would choose this as the first hooded maneuver for a new instrument rating trainee.
I’ve worked at companies who have tried to enter this and other software markets in China. It’s an absolute nightmare. Maybe this indicates a softening of the dictatorship’s stance on this particular industry segment. But I doubt it.
Go has a lot of lower level internal implementations of things that unsafe code like this serves as a thin shim for. It’s an almost zero-cost abstraction to use such a builtin.
I’m not saying it’s good: it just is what it is. It’s silly: but so is most of go. I’ve worked with this language for several years now: I don’t like it at all. It presents a facade of simplicity, but has all sorts of hidden issues that affect performance and behavior in surprising ways.
I doubt the headline. The type of person attracted to live in the “inexpensive” cultural wasteland of the Midwest or the regressive, racist south is on average less talented than my peers in urban tech centers like the Bay Area. There might be a loss in the “low cost, (relatively) lower skill” sector of the market.
"Temporarily embarrassed millionaire"[1] describes this mindset. It is quite prevalent in America's poor. I've seen too many poor Americans exhibit this mentality to not believe it is more or less a truism at this point. The propaganda of the wealthy and connected in this country has been remarkably effective.
"To build housing in San Francisco, developers must first receive planning approval, known as entitlement, to ensure the city supports the type, size and design of housing proposed for a site. This part of the process took an average of 450 days over the last 18 months, according to recent data from the state."
Housing in the SF bay area is broken, largely due to the efforts of entrenched interests (developers and people who bought 50 years ago for an inflation-adjusted tiny fraction of current prices).
There were non-compete clauses in every employment contract I saw when I started my software career (east coast circa 2005). Companies even tried to weasel them into the independent work contracts they signed with me when I did independent contracting for a while.
I wouldn't call it disgusting. It's just typical unsafe go code. The named return parameter in `getRuntimeHasher` is irritating, as all such parameters in go code are. If you're going to return values, do so explicitly in the return statement. In go code, seeing `return` at the end of a function does not mean that the function doesn't return any values, and that can lead to harder-to-read code.
Instead if you kept the same 6 engineers around for decades you could probably scale to 100m with those same engineers.
I doubt it. Effort does not scale linearly with user scale, in my experience, primarily because features don't. This means that horizontal scalability is insufficient to go from 10M to 100M. And that means that more complex systems are required to support it--I can easily see a team of 6 very experienced engineers with deep domain knowledge of the application becoming overwhelmed as that scale change occurs.
Not sure if we’re talking about the same thing. These slower drivers aren’t any safer: they’re weaving around each other and impeding faster traffic from passing. They’re arguably more dangerous because of that. And the flow of traffic is constrained to the speed they choose, which is on average slower than it otherwise would be.
Traffic is rarely “free flowing” at any speed on these kinds of roads. Often I see “moving roadblocks”: clumps of cars going around or just under the speed limit jockeying around each other, impeding other traffic from moving around them. So-called “defensive drivers” are often unpredictably overly cautious: I’d wager they are at least an indirect cause of accidents quite often, but are severely under-represented in the statistics (if/when they’re represented at all).