4 ms·

> because our industry is obsessed with abstractions "we do not break userland, period" -- Linus Torvalds not breaking existing stuff is why many abstractions

> because our industry is obsessed with abstractions "we do not break userland, period" -- Linus Torvalds not breaking existing stuff is why many abstractions exist, and even why many are put in place early on, to allow for some wiggle room without having to break all the things. people tend to prefer software that continues to work, above all else.

ClumsyPilot 4y ago
but then someone builds a bank on top of this abstraction, and sorts of shit hits the fan.
- leeoniya 4y ago
  except, it's turtles all the way down. is POSIX not an abstraction? TCP? C/gcc/llvm? glsl?
- pixl97 4y ago
  Working in the industry I do, there are a number of banks I will never used based on the terrifying lack of quality in the software they write. The SBOM on these projects could be printed out and bound as a dictionary there are so many packages included.
kelnos 4y ago
I think we should acknowledge, though, that not all abstractions are created equal. Abstractions that hide implementation details and allow people to change those implementation details without creating churn and extra work for their downstream consumers are good. Abstractions that paper over problems that you are unwilling or undisciplined enough to tackle properly are usually bad. I think the grandparent was talking about this kind.
- leeoniya 4y ago
  > Abstractions that paper over problems that you are unwilling or undisciplined enough to tackle properly are usually bad some abstractions carry decades of legacy (e.g. linux file-system hierarchy), and cannot simply be replaced. things that did not connect to the non-existent internet did not have to paper over problems that simply could not exist at that time (VMs, multi-user, multi-tenant hardware). there is plenty of deep software dependencies that are no longer maintained which still rely on these abstractions and cannot be cheaply/reasonably replaced in the field. sure, we have new abstractions since then, but only new and actively maintained software can ever make use of them, and that will only end up in systems that are also actively maintained instead of simply continuing to work with exactly zero effort.

ClumsyPilot 4y ago

but then someone builds a bank on top of this abstraction, and sorts of shit hits the fan.

leeoniya 4y ago
except, it's turtles all the way down. is POSIX not an abstraction? TCP? C/gcc/llvm? glsl?
pixl97 4y ago
Working in the industry I do, there are a number of banks I will never used based on the terrifying lack of quality in the software they write. The SBOM on these projects could be printed out and bound as a dictionary there are so many packages included.

kelnos 4y ago

I think we should acknowledge, though, that not all abstractions are created equal. Abstractions that hide implementation details and allow people to change those implementation details without creating churn and extra work for their downstream consumers are good. Abstractions that paper over problems that you are unwilling or undisciplined enough to tackle properly are usually bad. I think the grandparent was talking about this kind.

leeoniya 4y ago
> Abstractions that paper over problems that you are unwilling or undisciplined enough to tackle properly are usually bad some abstractions carry decades of legacy (e.g. linux file-system hierarchy), and cannot simply be replaced. things that did not connect to the non-existent internet did not have to paper over problems that simply could not exist at that time (VMs, multi-user, multi-tenant hardware). there is plenty of deep software dependencies that are no longer maintained which still rely on these abstractions and cannot be cheaply/reasonably replaced in the field. sure, we have new abstractions since then, but only new and actively maintained software can ever make use of them, and that will only end up in systems that are also actively maintained instead of simply continuing to work with exactly zero effort.