The problem here is that there isn't too much recycling being done. In the process of trying to become profitable companies seem to destroy their products so thoroughly that there isn't much left to salvage by the end.
It's like railway investors deciding that selling off all the metal from the left side of the track is the best way to recoup their losses. By the time that's done, there really isn't much of value left for anyone to pick up and use.
> Instead most users are reliant on the device manufacturing seeing the financial incentive to provide updates.
Most users are reliant on this regardless. Few people possess the technical ability, much less time, to perform these tasks. Making the platform "open" and pointing to that as a solution would also be a way of weaseling out of that responsibility to users.
The number of people who could use a fairly simple third party to to update their operating system on their phone is much, much larger than the number who can figure out how to obtain root access or unlock their bootloader using a technique that varies depending on exact model number and firmware version.
Obviously there are users who will be left behind, but that is an issue for novice users of ANY free and open source software.
> It's annoying that the media continues to incorrectly spin Android's security updates problem as somehow caused by its open ecosystem
That isn't "spin". Android's ecosystem is (largely) controlled by the phone carriers in this context. Their "open" system is a fractured jumble of closed systems with indifferent maintainers.
If Google took it up, Apple's method here would be a solution. Were Google to force carriers into supporting security updates on Google's terms, we wouldn't see this kind of issue.
Nobody making the Android/iPhone comparison in this context cares about "openness". That's largely a foregone conclusion on both devices. They care about the effective and timely distribution of security updates.
> GNU/Linux distros are free open source software, and don't suffer from these sorts of update problems.
Why on earth would NPR compare Linux distributions (which the general public has basically never heard of) to smartphones? It might be "more accurate", but it's not an accessible comparison.
> That isn't "spin". [then some correct statements, but not relevant to spin]
See also my other comment about words having false connotations, regardless of intent.
> Nobody making the Android/iPhone comparison in this context cares about "openness".
I don't know why you just assert this so nonchalantly. Clearly some people care, because they keep repeatedly associating closed systems with security update mechanisms, even though we have plenty of open systems with relatively good security update mechanisms. That is in fact my whole point; other people keep veering off on a tangent.
> it's not an accessible comparison.
What is "accessible" is very transient, dependent on the environment and cultural background. Those of us who are interested in balance and accuracy, have to make it accessible. Not doing so is irresponsible.
If every browser vendor fully and correctly implemented a standard on their first try, you'd have an excellent point.
As it is right now, even people that develop towards standards still have to choose between deviating from those standards to support a wider audience or sticking to the standards and turning away users.
Well, if you need the performance increase, the yes. Otherwise your options are to (maybe) tweak your current implementation so it continues to work or rewrite the functionality to be compatible with the view layer. This is the same trade-off you make with React since it's basically the same technology.
> so that those in the continuing lane feel morally obligated to let those queued up in.
I'm pretty well convinced that we'd never hit critical mass of drivers that feel morally obligated to even moderately inconvenience themselves to benefit the merging of others. That merge pattern is a recipe for stalled traffic in the right hand lane.
Well, Clojure also was a mess when I tried it (2 years ago maybe?). Leiningen (a/the build system) was pretty slow, and I couldn't find a way to use the language in a more lisp-like way easily, like editing a few files and (re)loading them into a running REPL (other than iterating through all buffers in Emacs and loading/evaluating them manually; there may have been other problems as well, I don't remember). You know, like you can edit a few Java files in Eclipse, press shift-ctrl-s, and have the new code hot-deployed into your debugging session.
Maybe the people who wrote the Clojure tutorials considered that question to be SO natural they didn't even mention it, but I found it very unintuitive. And running a very slow tool on every code change and waiting for the build and then starting the program is very unnatural and un-lisp-like.
Common Lisp is a bit old by now, but it's always been very stable and fast. Maybe Racket is a more modern+mature Lisp family member that's nice to try.
I also tried getting into Clojure around that time. I was coming from CL where we have nice things like conditions and restarts, dynamic variables, and CLOS -- being able to hit an error in the debugger, inspect the slot of the instance of some object that caused the error and recompile the class definition to fix the error without restarting the program is really nice (all of the running instances are updated). I was not used to Clojure's unhelpful tracebacks.
I don't understand what age has to do with anything... CL is still a good language.
I'd also say that one might do well to explore it, even if you don't plan to use it for everything. I'm definitely a Lisp neophyte (Scheme in college, no Common lisp, and then ~6 years with some lisp-like proprietary framework), but there are some things I really miss from it.
As some have said, it's worth learning because of the way it can change the way you think about things. It sounds hokey and trite, or like someone's trying to be smug ("I'm in the secret lisp club!"), but I genuinely feel profoundly grateful to have been exposed to Lisp. (To be fair, I also really like programming in Python for _many_ of the same reasons I enjoyed programming in Lisp.)
To me, logic says you should call the airline and see specifically how they're rerouting the flight to avoid this kind of danger. If you can't get an answer, don't get a satisfactory answer, or don't know how to tell what answer would satisfy you, book another flight.
In general, flying is safer than either driving or walking in urban areas. But most flights don't happen over not-technically-but-actually-definitely war zones. So ... make sure whatever flight you're on avoids the area entirely.