Like you try running this in production and 3 months later find out it instantly dies if there's more than 4% packet loss between you and the DNS server or something
1. It solves a more limited set of use cases. It's perfectly reasonable to want to solve a wide range of use cases, but there's value in more limited software which solves a more limited set of use cases, too.
2. It caters to a more limited set of users. Suckless is perhaps the epitome and most extreme flavour of this, where they just excluded things like config files in favour of a config.h file. This doesn't make the software less stable, but it does make it less usable for some users.
For example, I am working on a CI system right now, as I ran out of Travis "open source credits" pretty fast and didn't care much for the alternatives (or Travis, for that matter, but it did work) and I figured there's some space for a somewhat different kind of CI. It's currently functional but unfinished at abut 1500 lines of code, and I'd be surprised if the finished version will be more than ~3000 lines.
It's smaller because it excludes features that are useful, but not for my (and I suspect many people's) use cases, and because it makes some assumptions that you roughly know what you're doing instead of abstracting everything. Combined, this drastically reduces the code size. This also means it's not useful for everyone, but I'm okay with that and it's a deliberate trade-off: not every project needs to solve all use cases or cater to all users.
So, it may be more reliable than you think by virtue of that selective counting of codebase lines.
I watched a video of a "cabin anyone can afford and build" recently. It's 120 sq ft. He isn't saying "Why isn't everyone building their house for $2000?". It's a project to show that things people consider too complex can actually be achievable from the ground-ish up.
I wouldn't call it jaded, I'd call it experienced.
I'm not an expert in those products but from what I saw people are usually aware that geohot's system is a work in progress, though so far he pulled it off because it's cheap(relatively), not worse than the competition and constantly updated.
https://comma.ai/ says it’s been driven 30 million miles (over years), has anything gone wrong?
> openpilot ALC and openpilot LDW do not automatically drive the vehicle or reduce the amount of attention that must be paid to operate your vehicle. The driver must always keep control of the steering wheel and be ready to correct the openpilot ALC action at all times.
While changing lanes, openpilot is not capable of looking next to you or checking your blind spot. Only nudge the wheel to initiate a lane change after you have confirmed it's safe to do so.
Many factors can impact the performance of openpilot ALC and openpilot LDW, causing them to be unable to function as intended. These include, but are not limited to:
Poor visibility (heavy rain, snow, fog, etc.) or weather conditions that may interfere with sensor operation. The road facing camera is obstructed, covered or damaged by mud, ice, snow, etc. Obstruction caused by applying excessive paint or adhesive products (such as wraps, stickers, rubber coating, etc.) onto the vehicle. The device is mounted incorrectly. When in sharp curves, like on-off ramps, intersections etc...; openpilot is designed to be limited in the amount of steering torque it can produce. In the presence of restricted lanes or construction zones. When driving on highly banked roads or in presence of strong cross-wind. Extremely hot or cold temperatures. Bright light (due to oncoming headlights, direct sunlight, etc.). Driving on hills, narrow, or winding roads. The list above does not represent an exhaustive list of situations that may interfere with proper operation of openpilot components. It is the driver's responsibility to be in control of the vehicle at all times.
It was a bit of an exaggeration yes, but it made my point about neglecting rarer failure cases very succinctly.
> Also, isn't splitting things into small services instead of large beasts full of hidden behavior the basis of the argument in favor of microservices?
With microservices your goal should always be simplicity rather than size. Simple code is often small, but small code is not always simple.
In fact, 3 well built microservices will usually have more lines of code between them than a single monolith that does the same job would as they have to have all the boiler plate for talking to each other and accepting RPC etc.
(Also converting a large system that's hard to reason about into microservices generally results in a large distributed system that's hard to reason about - system design is hard!)