I wish I could set up a filter in Zillow that automatically excluded homes that have gray engineered flooring, which flippers seem to love for some reason.
I remember the weird, pretty bad MIDI songs that shipped with my Packard Bell Pentium 166 (with MMX technology) and I didn't realize there were devices at that time that would have elevated them. A quick search on youtube shows this video comparing a Sound Blaster output with the MU80. Pretty cool!
This is good to know, I have passed through Indiana a number of times on I-70 and I've found it to be particularly flat and boring. I know there are pretty places everywhere but that stretch has felt like exactly what he was saying, a place you have to get through to go somewhere else.
That's fair and I've certainly experienced this where I live, which is north of Buffalo in latitude. Also frost heaves are no joke in non-city/non-highway roads and present another obstacle to FSD. I guess my point, if I had one, is I would hope FSD would be programmed to be as conservative as possible in adversarial winter conditions and not overreact to such conditions and that alone is enough to increase safety because humans, for various reasons, are not conservative enough. Hard to imagine for sure.
> And modern vehicles have electronic stability control, anti-lock brakes, automatic emergency braking, and several other safety systems
In ice none of these really stop overcorrection, or at least they don't in my 2020 truck on icy hill/mountain roads in Maine. And I've seen nice recent Volvos and BMWs with presumably the best safety tech in ditches up in the ski towns. The correct safe speed to drive on icy roads is not to drive at all of course, but people have to get places and people make mistakes. IME the assistive technology defaults don't do great on ice roads on some kind of up/down grade.
AFAIK drivers can still steer and brake themselves into a loss of control situation on ice regardless of safety features. So I guess I'm hoping once you take those two variables out of their hands, the FSD vehicles will be safer. Who knows though.
I went many years without a loss of control and the one time it did happen (logging roads with ice pack) was enough for me to buy Nokian studded winter tires to minimize the effect of ice as much as possible.
I think a well designed winter specific FSD system is probably more safe in snow and ice than a human. For instance downshifting to ensure wheels continue to spin on slippery surfaces, subtle corrective steering to keep the vehicle within its lane, etc. should be easier for a FSD car since it won't panic and over-correct like most people do in those situations.
And if the car reduces speed when appropriate and some assholes start tailgating it, it won't suffer the anxiety of holding up 10 cars that want to drive beyond the safe, reasonable speed for the snowy/icy conditions.
Same. I work at a place that has gone pretty hard into AI coding, including onboarding managers into using it to get them into the dev lifecycle, and it definitely puts an inordinate amount of pressure on senior engineers to scrutinize PRs much more closely. This includes much more thorough reviews of tests as well since AI writes both the implementation and tests.
It's also caused an uptick in inbound to dev tooling and CI teams since AI can break things in strange ways since it lacks common sense.
I also liked de_dust more because a well executed T rush to site A was as fun as it got on random servers before voice chat. Was awesome when it all came together and everybody worked together.
Wessels does indeed say the stone for fences most likely came from stone dumps in _cultivated_ fields that were clear cut for crop fields and, later, the sheep craze and those rocks were pushed up from the ground in those cultivated fields over the winter.
> It is a known fact that the vast majority of truck owners rarely ever use the truck bed.
I'm not here to defend brodozers, but you cannot possibly prove this statement. That a _pickup truck_ isn't hauling the majority of the time it is on the road is not some new thing. But of course there are more pickup trucks on the road than ever, so if you argument is aggregate time of all pickup trucks not doing truck things is the highest its ever been is certainly true, but you'd probably have to go back to before the 80s for that number to actually be meaningfully different per truck.
I'm certainly not arguing against your point. I didn't work at Medium but I had insight into their operations at the time and they didn't really seem to have a coherent vision to make money 12 or so years ago. My comparison of the two is more around their similar goals and audience, which was giving great (or interesting) writers a home for their projects and audiences and somehow make money. Medium was saying the financial part would happen down the line and it was a can they kicked for a long time. Medium seemed more interested in talking about their technology and aesthetics than they did on figuring out the crucial parts. Substack got it right doing what Patreon (and even Twitch) had already proved, people will pay up front for the writers/creators they love.
That said Medium did pay higher profile writers and publications to move to their platform (in some cases quite a bit of money) in a similar way that Substack has, which was to dip into the VC funded bank account.
* Patreon kind of sucks for writing / newsletters or else they could have captured part of this market. Medium was supposed to fix this but they had an epic collapse.
* Single point where subscribers can manage their subscriptions and preserve a common identity across subscriptions in the comments etc. Again, Medium/collapse.
* A rapid adoption of substack by well known online writers with loyal followings. These writers either had their own blogs or were exiting traditional media or getting dumped out by the collapse of online media (gawker network, buzzfeed news, etc). Again, could have been Medium if not for their collapse.
* I suspect Substack spent a lot of that VC money guaranteeing 2 years of X revenue for a non-trivial number of high profile writers so they would onboard.
Reading this story I didn't realize just how much they had taken over the years (I use to operate in this media space, but haven't in a long time). I'm not sure what the headcount is but that amount of money is staggering and I can only imagine it was all used to acquire DAUs and very little novel technology has been created with it.
I think Substacks first 10m/100m (their keep of rev/total rev from subscriptions) was extremely impressive and fast. But also it was a kind of low hanging fruit. There was a market already there for this and Medium/Patreon couldn't capture it. Now if they are really at 45m/450m that is much less impressive. It will be extremely hard to get to 100m/1000m and IMO impossible to get much higher than that with their current approach.
Exactly, it's hard to dismiss the broad penetration of ChatGPT in the general population. I was an AI skeptic/luddite until almost exactly a year ago when, in a span of a month or so, I had three different friends/family members who work in various administrative jobs tell me that they all used ChatGPT surreptitiously at work to get things done. Now a year later I don't know many people that don't use it at least occasionally. The ones that don't are older and I'm confident eventually they'll be using it like crazy to annoy me.
That whole stretch of Midland/Odessa on 20 is one of the most miserable landscapes I've ever driven through. The crushing heat, the off-gassing flame stacks across the horizon, the man camps, the junk and trash everywhere... all of it is grim.
> OK, but, you know... those tools were created by literal devs.
All `kubectl` does is create REST API calls to the control plane. So to be fair, what I'm grousing about can be accomplished just fine by a developer like me constructing API calls from python to update objects in k8s.
The problem is I work in devops where tooling written in proper languages with standard libraries that have things like useful arrays or robust string manipulation or ergonomic concurrency is a non-starter for some reason. The argument against that being mostly "I have to install the interpereter first".
> You'll often find that if you write ops scripts in, say Python, it's largely calling external commands.
That's a totally fine trade off for actual sane array/list functionality, robust string manipulation etc. I'd rather form shell commands in a programming language than in bash. People seem to love it.
I do not think for a second though that the average person that "knows bash well" can read and comprehend a multi hundred line bash script written by someone else as fast or even correctly has a seasoned python dev reading python written by someone else.
I'm a dev that jumped to devops and one of my pet peeves will always be the lengths devops engineers go to avoid using a real programming language. Instead of interacting with all these APIs through python, ruby, lua, go, whatever they would rather build hodgepodge systems in bash, coreutils, curl (or wget. or both!) and jq (which is the worst). Or in the case of helm, just creating a half yaml/half Go SDK for generating YAML.
Even the helm infrastructure that I work in is completely wrapped in custom shell scripts that call all sorts of other commands to populate helm variables.
But yeah it's silly that helm templates require all sorts of {{ indent | 4 }} type incantations when the final YAML output is just sent through some kind of toJSON anyway.
Similarly: though William Jarvis wasn't the first American to import Merino sheep, he was the most successful because he was able to utilize an ongoing war in Spain to circumvent around the Merino export ban in the early 1800s and get a ton of them over here, too. He was even a diplomat to Spain and probably knew better, but did it anyway.