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.
Pretty much all electric cars have single speed transmissions, so there's no downshifting. And modern vehicles have electronic stability control, anti-lock brakes, automatic emergency braking, and several other safety systems. It's pretty hard to overreact with those enabled. The main issue is that people exceed safe speeds for the conditions, making them unable to brake or turn in time to avoid a collision.
Right now, most self-driving software will refuse to activate in conditions of poor visibility. I've had that happen with Tesla's FSD, though in that case it was snowing so much that the road should have been closed. Also when the snow is deep enough that your front bumper becomes a plow, it will refuse to activate.
> 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.
on the contrary, no amount of safety systems can compensate for a loss of traction on ice and snow.
The surest way to be safe on snow covered roads is to not drive at all. Also, none of the electronic trickery is a replacement for real winter tires, which many people do not buy.
The problem with places that have real winters is that lanes migrate. They are not absolutely positioned. Nor are the sides of the road edges which may project well out into the street and parked cars even further. No road markings visible. Humans make their own lanes. This situation can happen for many weeks-long periods in a typical winter in, say, Minneapolis or Buffalo suburbs.
If a self-driving car does the right thing staying "in lane" while all the human drivers do the wrong thing flocking to new emergent paths (which swing back and forth across the "lanes"), then the self-driving car is wrong and dangerous. I'm not talking about when it's actively snowing either. I mean the snow on the ground just remaining there, covering things.
It's not about dealing with slippage or skill driving, it's about complete lack of context markers. I don't think any current or near future self-driving solution can adapt to this.
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.
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.
I vividly remember the thrill of taking out the entire T rush to site B myself in about two seconds during a clan match (not that high level ;)). It was like dominoes falling down in a neat row. It was quite unexpected to rush to site B; the other four of my team were already at site A.
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.
Not sure what you mean by "prove this statement" but answering questions like this is exactly why organizations do consumer research. To wit [1]:
> According to Edwards’ data, 75 percent of truck owners use their truck for towing one time a year or less (meaning, never). Nearly 70 percent of truck owners go off-road one time a year or less. And a full 35 percent of truck owners use their truck for hauling—putting something in the bed, its ostensible raison d’être—once a year or less.
The hauling figure is useless without specifying what they mean.
Usually these “studies” redefine hauling to mean something specific like hauling loose dirt or something extremely heavy.
If you can read a quote claiming 2/3 of truck owners don’t “put something in the bed” more than once a year then and not realize that something is wrong with these statistics then you’re missing something.
The question is not whether they "put something in the bed" — it's whether they use the bed in such a way that the trunk or back seat of a smaller vehicle would be unsuitable.
The Telo appeals to me. I've resisted getting a truck because I like a smaller vehicle and don't want to have undue impact and because I've listened to arguments like this before.
But I was offroad last weekend. I move sheets of plywood a couple of times per year and either need to beg my wife to help or sit around waiting at Home Depot for the truck to be available. I have stuff to move for robotics comps that I'm always barely able to get there by cramming it in my car + begging a couple of parents to help out. Dealing with the bike rack is hard. Ordering things like Ikea furniture for delivery is expensive, latent, and not exactly low impact iself.
Yah, 90% of the time I need a car, but 10% of the time I need a little more and there's enough friction around making it work that I would pull the trigger on something like this.
On the other hand I don't think I could say "frequently" to any of those questions.
1. An ideal society would be structured such that you wouldn't need to buy a truck you use as a car 90% of the time. But that society doesn't exist here, and you shouldn't feel guilty about living by incentives you didn't create. Maybe you do need a truck!
2. But we're not talking about people who compromise to make 10% of their trips more convenient; we're talking about people who never use their truck for truck things. A car would be better choice for them 100% of the time, yet they still drive a truck.
There’s a quote from some consulting firm that goes around claiming 2/3 of truck drivers don’t “put something in the bed” more than once a year.
It’s a laughable claim for anyone who thinks about it for more than a second.
The way they usually get to these numbers is by redefining what “hauling a load” means to be something extremely heavy or for loose fill materials. So if someone routinely hauls a couple mountain bikes in the bed of their truck or gets a few 2x4s from the lumber yard it wouldn’t count.
The company in question has been doing their survey for two decades. It’s a private data set, but has been reported on by multiple serious news outlets which will have their own data scientists looking over the data, e.g. Axios: https://www.axios.com/ford-pickup-trucks-history
You can also verify the data is coming from real drivers, by searching for “New Vehicle Experience Study” and seeing all the posts from users who receive the survey and think it’s some kind of scam.
> So if someone routinely hauls a couple mountain bikes in the bed of their truck or gets a few 2x4s from the lumber yard it wouldn’t count.
Even if that’s the case, the truck owners doing this probably don’t need a full size truck. A 90s-era small truck or maybe even a kei truck would suffice, and yet more often than not the trucks in question are the likes of F-150s.
Agreed, unfortunately small trucks are increasingly harder and harder to find. A 90s truck also won’t have the amenities that a modern truck has.
I think if they are just hauling mountain bikes, they could get a small hitch installed and purchase a high-quality bike rack. A roof rack can carry 2x4s very well.
A rack mount on a normal European-sized car is perfectly sufficient for a couple bicycles, I have one, and a trailer for my enduro motorcycle, or a fridge, or anything else I occasionally transport. Anything bigger and I'll rent an actual truck.
> So if someone routinely hauls a couple mountain bikes in the bed of their truck or gets a few 2x4s from the lumber yard it wouldn’t count.
If that's all you're doing, anything more than a Maverick is overkill. Bike racks and wood delivery are a thing. Shit you can fit a mountain bike in the back of a sedan. I see people doing this at trailheads all the time.
Those suburban moms don't need a Yukon to take their two kids to soccer practice either.
I dislike the whole "justify why you like X" thing. People can always find the flimsiest of reasons why they want to prohibit things they don't like and then demand others justify why they should get to keep what they have. Just simply liking something never seems enough for those fighters against joy.
I really don't like pick up trucks. I also think most of their practical uses can be achieved with other vehicles. But that shouldn't concern me. If the owner of the car gets joy out of it, then that should be enough. I don't have to like what others like, and they don't have to like what I like.
>If the owner of the car gets joy out of it, then that should be enough.
For most things, yes, absolutely! However, considering the dangers of huge trucks it is very valid to have concerns about them. An exaggerated analogy: if the owner of a gun gets joy out of free firing it into the air that should be enough.
Respectfully, if you don’t know how long a 2x4 is, I think it would be very reasonable to look this up, as it will make you much better equipped to make this argument.
I generally agree with what you are saying, and frequently haul 2x4s without my truck - but the solution to that is a long flatbed trailer, not a Thule hitch attachment.
it does depend a lot on what you buy it for, but obviously 8' is a good benchmark.
But honestly... at 8' I'm not sure why you're bothering with anything (unless you're getting a lot of them), i usually just threw 8 footers in my Honda Fit and closed the hatch.
Ironically most pickup truck beds are shorter than 8' and most likely a 8' piece of lumber would have to lay diagonally sticking out over one of the edges.
Still good for occasional piece of furniture, lots of lumber, or plywood.
The shortest bed f150 you can buy is 5.5ft, with a 2ft tailgate, trivially hauling 8ft with just a few inches overhang with the tailgate down, and easily doing 10ft lumber.
Again, I think pickup trucks are idiotically oversized and dangerous to pedestrians, but arguing against them by repeating things that anyone that uses a pickup knows is nonsense is not helping win over any detractors.
To be clear, I am not arguing against pickup trucks. The reason I bring up the bed length is a personal pet peeve thing. I have some amount of OCD going on, and I will be damned if I will ever approve of a truck that can't fit a piece of lumber in its bed without leaving the tailgate open that can fit into a Ford Fiesta with the trunk closed.
I am fully aware of why and how people use pickup trucks and I have no beef with that on cultural grounds. But if I were to get one it would be a long bed truck and I would sacrifice the cab space if needed.
Exactly, because my car can do that. You can put your shopping in the flatbed but you wouldn’t claim you were “using” the flatbed or “hauling” a pint of milk and a load of bread…
* 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.
Did Medium have a way to pay authors? Maybe it would have been easy to add but saying "A could have been B if only" I think misses the picture. Yahoo could have been Google if only they'd chosen a different algo. Flickr could have been Instagram if only they'd made a mobile app with filters. Etc...
I think it's precisely because substack launched with a way to let readers sponser the authors directly they liked that it took off. Medium had a partner program but that's not the same.
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.
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.
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.
You'll often find that if you write ops scripts in, say Python, it's largely calling external commands.
When that's the case, bash if often the better choice, especially if you know it well. It has an excellent REPL, is easy to trace and is already installed everywhere.
> 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.
> the lengths devops engineers go to avoid using a real programming language
OK, but, you know... those tools were created by literal devs. Not in yaml, in a "real language"! So apparently devs thought they needed that.
The argument should be towards all people - we love creating new abstractions and "simplify things", but we suck at honest evaluation of the impact of our creations.
Still: I absolutely hate Helm templating and think that the very existence of "helpers" (even in a default chart!) is an abomination.
> 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".
Now we get to the point - you are unhappy with how your org/team handles it. Would that be better description? Don't put all DevOps in one basket. It's a messy term anyway.
Many orgs and many teams allow that. That's why alternatives to Helm exist like cdk8s, or Pulumi for rest of infra.
For Kubernetes there is such a variety of tools, it's overwhelming. The only problem to tackle is that Helm/Argo is so popular, that alternatives are hard to sell regardless of real benefits.
Look at how big is a scene of Operators for k8s - this is where the programmable part of k8s went. You configure operators with their own CRDs (usually) that can be static/plain declarative text. Then you write actual code of the operator that deals with all the complexity of enforcing that state. For me this is where typically what you are talking about goes, while high level "non programmable" code sits in yaml in a other repo for others to maintain. Maybe this is where you should also go, standardize your work for others to consume in a form of operator?
I fully get neglect in adopting more complex tooling. sh, curl, sed, awk... those things are present almost everywhere and it's not that hard to get lucky and make a script that will run on almost everything your org has. And it actually might be fine for a decade or so.
I myself could not do code (even scripting) because one of my companies literally treated scripting in anything as development which was strictly regulated (so forbidden for any non dedicated dev role). Or an org that had not a single server in whole DC that has Python 3, years after it's release. Or more recent: some damn Ubuntu LTS that can't be easily upgraded to just 2-3 minor versions that this cool k8s library uses. Maintaining python versions on VMs is a pain in the ass, especially if your org has strict controls. Internet access to pip is not granted as well. UV gets the job done nowadays, if it's allowed, but long story short: that "fear of real language" can be as much lack of knowledge/skills as pragmatism that came from painful experiences.
.jpg){kind=link}
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.
reply