Disabling auto-indexing just makes it harder to spot the issue. (To clarify, also not a bad idea in principle, just not _the_ solution.) If the file is still there and can be downloaded, that's strictly something which should not be possible in the first place.

Yes, I'm sure most people on this website have ran into seemingly bad design choices which made sense once they knew more context. But that doesn't mean that all bad design choices are like this.

Specifically dumb oil filter placement is an example of such a case where the _only_ legitimate justification is design cost saving for the manufacturer (re-using an existing design meant for a different car).

You can maybe argue that saving on design costs (and I guess also re-tooling costs) is a saving that gets passed onto the consumer. But that consumer is unlikely to feel like they're saving much money when cars depreciate faster than ice cubes in the desert, and when their oil change is 2+ times more expensive every 6 months. Really that cost savings will only really benefit the manufacturer (well, at least until they tarnish their reputation).

Option 2: "Certainly, I do not understand the various trade offs that led to this design"

I wished at least in software tech circles there would be more of option 2 kind of thinking.

Anyone who actually drives their car regularly will be doing an oil change at least twice a year. If an oil change takes more than 30 minutes of actual labour time of an inexperienced mechanic, it's going to be a serious financial burden which will likely outweigh any 2mpg improvement.

We do - they are just a lot bigger.

You should replace the oil filter when it is no longer filtering. Replacing it early is a pure waste of money. Unfortunately the tests of do you need to change the oil filter is more expensive than just replacing the filter so just replace it before it can possibly be clogged is the right answer. Generally the manufactures recommendations are correct and you should follow what they say unless you have lab results that say otherwise.

Yeah, of course, but I am not aware of any regular car which comes stock with such filters.

The point was really that lasting 22k miles longer than stock would be an unrealistic improvement for a filter for a normal car.

> You should replace the oil filter when it is no longer filtering.

I was specifically referring to manufacturer recommendations. Of course they're conservative, they also have to account for engine wear.

And yes, you are right that ideally you'd test. Although testing the filter from what I've seen is destructive, and there's a nontrivial turnaround time.

I'd disagree that following manufacturer recommendations is a waste of money though. As you say, testing is _more_ expensive. Engine damage is even more expensive. Replacing the filter on schedule is the economical choice.

It might be strictly a waste of resources, but that's a separate concern.

filter test can be inferred from flow rate and oil analisys. Destructive testing is best if you must know - but also not helpful.

Putting some random number of hypothetical mpg improvement was clearly a mistake, but I assumed people here would be able to get the point I was trying to make, instead of getting riled up about the relationship (or lack thereof) of oil filters and fuel efficiency.

But to keep it concise: The core problem is that you are stating a truism in response to a famous counter-example to specifically that truism. The other problem being that you are stating a truism which everyone else is already familiar with.

To be concise as well: it's been duly noted by me that contributing to a conversation by attempting to bring in nuance is not always well received when you make up a hypothetical for a topic people are very touchy about.

You should be replacing your oil filters based on the manufacturer’s service schedule, there’s no rule of thumb. Look at the service manual, my car has the filter change scheduled every 10,000 miles.

Between rebuilding an engine and disassembling a bumper to replace a lightbulb most mechanics would genuinely rather be doing the lengthy but interesting work of rebuilding an engine than the lengthy and fucking boring task of disassembling a bumper to fix a lightbulb.

Moreover, even if a mechanic must charge you stupid amounts of labour cost to do a simple repair because it genuinely takes that much time, the customer might not come away with it thinking: "fuck, I bought a dumb car which is expensive to repair", they might instead come away with it thinking: "all these mechanics, quoting ridiculous prices to fix a light bulb, they must all be scammers".

ChatGPT, write me a 2010-style Hacker News front page essay about how software maintenance is just like automobile maintenance, and why nobody wants low-value maintenance work to be arduous, failure-prone, and boring.

I gagged after 2 sentences.

The obvious one is the battery, and you can argue that modern EVs have batteries so expensive that when they are dead the car becomes scrap, and - sure, whatever.

But EVs still have: cabin air filters, coolant, brake fluid, lubricants in various places (although granted, these lubricants will mostly last the service life).

At the end of the day, as long as you have a car which moves, and not a statue, it will have things which wear out and which should be easy to replace.

Engine oil and oil filters are just an example.

I spent many months redesigning, improving and rebuilding a prusa clone, not because I couldn't afford anything else, but precisely because I could afford to "waste" time and money learning and having fun.

Once I felt like the printer was in a useful state, I spent some more time getting it to a point where it could print nice ABS parts for a Voron Trident. Of course I couldn't just build a Trident. That would be too easy. Before I had even finished assembling it, it already had a number of bespoke modifications that I had designed.

And that's just the tip of the iceberg. Have you ever _looked_ at the klipper source code? It's like a fractal of weirdness. I mean it works, and clearly the person behind it is very knowledgeable about many things. But it makes for such an enormous and fun playground for improvements and redesigns. I've redesigned the entire build system for the firmware component. I've made the host component an actual (almost) normal python package. I changed a bunch of core aspects so that it could be packages for a linux distro. I am working on making the native helper a normal python native extension library too. And I am also writing some proper test rig for it.

And while I was at it, I started writing my own display software which doesn't use Wayland or X. It is going quite well actually. (Writing it in Rust)

This hobby (and, really, any hobby) has as much depth and obscurity as you are willing to look for.

You used to have to do all that tinkering because you had no choice which is not the case anymore

If your goal is just to print stuff then it doesn't really feel like a hobby, its just another tool in the workshop the same as a tablesaw or welder

The criticism is of the assumption that a world without problems theoretically could exist.

You may disagree, but you will not find a definition of such a world that everyone can agree on.

Regardless, of whether you agree (that such a definition doesn't exist) or not, if you do plan on bringing about such a utopia, and you begin to meet resistance, the question you will inevitably need to answer is: How do those who resist fit into this utopia?

The historical answer for this question, which by all appearances seems like an inevitable answer, is the reason why people criticise utopian thinking.

No matter what I do, the clock line in the log stays at 1 during tests.

Also the D latches behave very weirdly.

Please don't insult me by insinuating that I think that sysvinit is anything other than a weird esoteric init program which has, in the past and on linux distros, been the supporting piece of a garbage heap of poorly written shell scripts (and which is currently on BSDs the supporting piece of a relatively okay designed heap of shell scripts which implement a silly service management model that I also don't like).