> We don't have magic oil filters which last even 22k miles. You should be replacing them every 6 months / 6k miles, or 12 months / 12k miles depending on your risk tolerance (some people suggest even half my short interval).
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.
That is why you mix in "Something So Feminine About A Mandolin" in once in a while. Or if you really insist on only very well known tunes "Cheese Burger in Paradise" should still count.
The vast majority of git users are using github as a central repository. There a a few other not github but serves the same purpose central repositories. Distributed sounds cool, but almost everybody wouldn't notice a thing if git was centralized.
The optimum amount of fraud is non-zero only because detection is expensive as you get close to zero. Getting less fraud needs to always be in mind. When someone gets away with fraud others will try to copy it so anything that has happened before has a much higher value to detect.
But for fraud that hasn't happened yet don't worry about it and hope nobody figures out how to do it.
AI results are generally easy to transport - just a few bytes over some fibre. Electric is harder to ship, there is only so much you can put in a wire (even high voltage DC). Widgets (car parts...) are even harder to ship and take longer which is why big things often get final assembly locally.
There have always been business owners who shouted their ideology, and others who were quiet. You might remember some cases more than others, and some have had a louder voice than others, but both go way back.
Have there been any so brazen as Musk, who used his influence to infiltrate our government and usurp the congressional power of the purse directly and illegally?
Details are different, but there have been lots of examples over the years. Andrew Jackson had his "kitchen cabinet". There was https://en.wikipedia.org/wiki/Teapot_Dome_scandal, Watergate. There are plenty of other examples. In large part if something is an example or not depends on your politics - people tend to overlook the mistakes of someone they support.
For this purpose identify is enough - as anyone who identifies will be horrified even if they otherwise don't care about the church. Many non-Catholics (including non-Christians) are also horrified even though they otherwise don't care about what the pope says at all.
I don't think supporters of the current US president would be horrified. They already support his anti-christian behavior, and seem more interested in being part of that group than they are in the religion itself.
More likely he would just assert that the Pope isn't actually the Pope, and thus any excommunications are void, and his supporters would roll with it. Some of them already believe this. Any words, true or false, which make them feel better to believe. That's religion, right? He is their true religion.
For simple projects. Make is easier for simple things I will grant. However when your projects gets complex at all make becomes a real pain and cmake becomes much easier.
Cmake has a lot of warts, but they have also put a lot of effort into finding and fixing all those weird special cases. If your project uses CMake odds are high it will build anywhere.
Also, for better or worse, cmake is pretty much the "standard" for C/C++ these days.
Fighting the standard often creates it's own set of problems and nightmares that just aren't worth it. Especially true in C++ where yhou often have to integrate with other projects and their build systems. Way easier if you just use cmake like everyone else.
Even the old hold outs, boost and google open source, now use cmake for their open source stuff.
Anyone can make a tool that solves a tiny part of the problem. however the reason no such tool has caught on is because of all the weird special cases you need to handle before it can be useful. Even if you limit your support to desktop: OS/X and Windows that problem will be hard, adding various linux flavors is even more difficult, not to mention BSD. The above is the common/mainstream choices, there Haiku is going to be very different, and I've seen dozens of others over the years, some of them have a following in their niche. Then there are people building for embedded - QNX, vxworks, or even no OS just bare metal - each adding weirdness (and implying cross compiling which makes everything harder because your assumptions are always wrong).
I'm sorry I have to be a downer, but the fact is if you can use the word "I" your package manager is obviously not powerful enough for the real world.
There are so many reasons why C/C++ build systems struggle, but imo power is the last of them. "Powerful" and "scriptable" build systems are what has gotten us into the swamp!
* Standards committee is allergic to standardizing anything outside of the language itself: build tools, dependency management, even the concept of a "file" is controversial!
* Existing poor state of build systems is viral - any new build system is 10x as complex as a clean room design because you have to deal with all the legacy "power" of previous build tooling. Build system flaws propagate - the moment you need hacks in your build, you start imposing those hacks on downstream users of your library also.
Even CMake should be a much better experience than it is - but in the real world major projects don't maintain their CMake builds to the point you can cleanly depend on them. Things like using raw MY_LIB_DIR variables instead of targets, hacky/broken feature detection flags etc. Microsoft tried to solve this problem via vcpkg, ended up having to patch builds of 90% of the packages to get it to work, and it's still a poor experience where half the builds are broken.
My opinion is that a new C/C++ build/package system is actually a solvable problem now with AI. Because you can point Opus 4.6 or whoever at the massive pile of open source dependencies, and tell it for each one "write a build config for this package using my new build system" which solves the gordian knot of the ecosystem problem.
No scripts sounds nice until you are doing something weird that the system doesn't cover. Cmake is starting to get all the possible weirdness right without scripts but there are still a few cases it can't handle.
I will categorize this as a pattern I've seen which leads to stagnation, or is at least aiming for it. Usually these are built on one or more assumption which doesn't hold. The flow of this pattern:
- Problem exists
- Proposals of solutions, (varying quality), or not
- "You can't just solve this. It's complicated! This problem must exist". (The post I'm replying to
- Problem gets solved, hopefully.
Anecdotes I'm choosing based on proximity to this particular problem: uv and cargo. uv because people said the same thing about python packaging, and cargo because its adjacent to C and C++ in terms of being a low-level compiled language used for systems programming, embedded/bare-metal etc.
The world is rich in complexity, subtlety, and exceptions to categorization. I don't think this should block us from solving problems.
I didn't say the problem couldn't be solved. I said the problem can't be solved by one person. There is a difference. (maybe it can be solved by one person over a few decades)
This is true. There is no way I could solve a problem of this scale by myself. That is why this is an open source project and open to everyone to make changes on. There is still much more to improve, this is only day 1 of release to the public.
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.
reply