4 ms·

Maybe I'm just jaded by now, but these days whenever I see someone bragging about how much smaller their codebase is vs thing they want to replace, I start to w

Maybe I'm just jaded by now, but these days whenever I see someone bragging about how much smaller their codebase is vs thing they want to replace, I start to wonder what edge cases they decided don't exist. 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

vzcx 6y ago
It needs to become commonplace to include your OS, external dependencies, and any language runtime code in this count. Otherwise it's just not going to evolve into a proper demoscene.
notretarded 6y ago
It's George hotz, literally all edge cases are left to be considered as "an exercise for the reader"
- lexicality 6y ago
  And he founded a self driving vehicle startup? Oh dear...
  - jonathanstrange 6y ago
    Well, if I remember correctly his original suggestion was to use the mobile phone to steer the car, nothing could go wrong with that...
    - boogies 6y ago
      > nothing could go wrong with that... https://comma.ai/ https://comma.ai/ says it’s been driven 30 million miles (over years), has anything gone wrong?
      - quineoa 6y ago
        Also, unlike Elon tweets (from https://github.com/commaai/openpilot/blob/devel/README.md#supported-cars https://github.com/commaai/openpilot/blob/devel/README.md#su...): > 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.
  - alpaca128 6y ago
    Well at least he's not calling it autopilot(Tesla) or suggesting it to be more than it is while intentionally disabling safety features to get an unholy pile of software working(Uber). 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.
badpenny 6y ago
Also that the code is indecipherable because one of the ways they got the code size down is by playing code golf. I wouldn't call it jaded, I'd call it experienced.
arp242 6y ago
It depends on the project; I haven't looked at this one in depth specifically, but it's certainly possible to write useful things with a (much) small codebase for to replace (much) larger ones. Usually the trade-offs are: 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.
nocubicles 6y ago
Few months ago I had issue where I needed to transfer lots of files very quickly between two drives on windows server. All the available tools were slow or had some other issues. So I wrote go program which was about 50 lines or so. I know that I didn't cover like 99% of the edge cases that there are with file transfers but for my use case it was perfect. Still running strong to this date.
emptyparadise 6y ago
The downside of the opposite approach is wanting to use some tiny service for a dozen people and finding out it requires spinning up a data center's worth of virtual machines.
tlianza 6y ago
The "small codebase" claim hinges on the fact that you're not counting the lines of code in nginx, leveldb, and other external software that are glued together to make this system. Those systems may reflect the years of battle-hardening you seek. So, it may be more reliable than you think by virtue of that selective counting of codebase lines.
- DocSavage 6y ago
  They are also using a pure Go version of leveldb (github.com/syndtr/goleveldb) and not the more battle-hardened Google leveldb, RocksDB implementations, or even the dgraph-io Badger WiscKey-style approach.
unethical_ban 6y ago
Unless someone is specifically bragging about it in a "how hasn't anyone else done it", I always see these as a coding exercise. 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.
abawany 6y ago
The repo readme states: `Used in production at comma.ai.` - I have no more context than that but it seems to not be totally a weekend coding exercise though he later appears to acknowledge code quality while mentioning recovery in case of a failure.
dpedu 6y ago
I think your argument makes sense but the example you gave is far too extreme. 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?
- lexicality 6y ago
  > I think your argument makes sense but the example you gave is far too extreme. 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!)

vzcx 6y ago

It needs to become commonplace to include your OS, external dependencies, and any language runtime code in this count. Otherwise it's just not going to evolve into a proper demoscene.

notretarded 6y ago

It's George hotz, literally all edge cases are left to be considered as "an exercise for the reader"

lexicality 6y ago
And he founded a self driving vehicle startup? Oh dear...
- jonathanstrange 6y ago
  Well, if I remember correctly his original suggestion was to use the mobile phone to steer the car, nothing could go wrong with that...
  - boogies 6y ago
    > nothing could go wrong with that... https://comma.ai/ https://comma.ai/ says it’s been driven 30 million miles (over years), has anything gone wrong?
    - quineoa 6y ago
      Also, unlike Elon tweets (from https://github.com/commaai/openpilot/blob/devel/README.md#supported-cars https://github.com/commaai/openpilot/blob/devel/README.md#su...): > 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.
- alpaca128 6y ago
  Well at least he's not calling it autopilot(Tesla) or suggesting it to be more than it is while intentionally disabling safety features to get an unholy pile of software working(Uber). 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.

badpenny 6y ago

Also that the code is indecipherable because one of the ways they got the code size down is by playing code golf. I wouldn't call it jaded, I'd call it experienced.

arp242 6y ago

It depends on the project; I haven't looked at this one in depth specifically, but it's certainly possible to write useful things with a (much) small codebase for to replace (much) larger ones. Usually the trade-offs are: 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.

nocubicles 6y ago

Few months ago I had issue where I needed to transfer lots of files very quickly between two drives on windows server. All the available tools were slow or had some other issues. So I wrote go program which was about 50 lines or so. I know that I didn't cover like 99% of the edge cases that there are with file transfers but for my use case it was perfect. Still running strong to this date.

emptyparadise 6y ago

The downside of the opposite approach is wanting to use some tiny service for a dozen people and finding out it requires spinning up a data center's worth of virtual machines.

tlianza 6y ago

The "small codebase" claim hinges on the fact that you're not counting the lines of code in nginx, leveldb, and other external software that are glued together to make this system. Those systems may reflect the years of battle-hardening you seek. So, it may be more reliable than you think by virtue of that selective counting of codebase lines.

DocSavage 6y ago
They are also using a pure Go version of leveldb (github.com/syndtr/goleveldb) and not the more battle-hardened Google leveldb, RocksDB implementations, or even the dgraph-io Badger WiscKey-style approach.

unethical_ban 6y ago

Unless someone is specifically bragging about it in a "how hasn't anyone else done it", I always see these as a coding exercise. 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.

abawany 6y ago

The repo readme states: `Used in production at comma.ai.` - I have no more context than that but it seems to not be totally a weekend coding exercise though he later appears to acknowledge code quality while mentioning recovery in case of a failure.

dpedu 6y ago

I think your argument makes sense but the example you gave is far too extreme. 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?

lexicality 6y ago
> I think your argument makes sense but the example you gave is far too extreme. 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!)