3 ms·

I disagree. In all my experience working in corporate, most problems we solved with technology would have been better solved by having better simpler policies i

I disagree. In all my experience working in corporate, most problems we solved with technology would have been better solved by having better simpler policies in place. The real world is unnecessarily complex and messy because a lot of people in positions of authority dont know how to design good systems. This leads to tons of bullshit jobs.

qplex 8y ago
It's not inefficiency in systems design. Some jobs are simply bullshit to begin with, and what actually enables us to have them around are the very efficient systems we have.
rayiner 8y ago
What makes you think those simpler policies would work? The real world is complex and messy because people are complex and messy. It's like looking at the Windows or Linux source code and saying it "would have been better solved by having better simplier policies in place." It's superficially true in that you could have simpler designs that accomplish any given function of those operating systems. But for the most part e.g. Linux evolved the way it did for a reason, and almost none of the 20+ million lines in the source tree are "bullshit code."
- raverbashing 8y ago
  And I'd say a lot of that complexity in both cases is because of one reason: people will want to abuse the system
- rorykoehler 8y ago
  If that were true my companies current strategy of throwing change management consultants at problems rather than programmers wouldn't be half as successful as it is. Your windows /linux example is a bad one and i don't think designing /building Linux could ever be classified as a bullshit job. As for real world complexity this applies mainly to physical phenomena (self driving cars for example) and less to bureaucratic business organisational structures which is where most bs jobs also happen to exist.
- repolfx 8y ago
  Well that depends a lot on your definition of bullshit. Linux evolved the way it did for various reasons, but how many are still relevant today? Would you write a kernel in C these days? I wouldn't. There are production quality kernels written in at least C++ which benefit from its features, and it's been demonstrated that you can write entire operating systems in managed languages like Java as well. Why should we suffer an endless parade of exploitable memory bugs in kernel space? It's not technical requirements driving that. Would you write a GPLd kernel these days? I wouldn't. Not much new software is being GPLd these days, it's all Apache or similar licenses. The policy of trying to maintain every driver in-tree has caused vast amounts of time to be spent on workarounds like installers that compile things client-side, enforcement is poor, lots of time is lost due to needless recompiles, API churn, poor usability of desktop software and so on. Has Linux benefited from correspondingly amazing hardware support? No. Desktop Linux is a morass of bugs that often still can't suspend properly, and in the server realm it's now more often than not talking to virtualised hardware anyway. I could go on. There's a LOT of simplification and "bullshit work" that could be optimised out, even in the realm of a very concrete thing without much room for innovation like an OS kernel - partly because times changed but Linux didn't.
  - majewsky 8y ago
    > Would you write a GPLd kernel these days? I wouldn't. [...] I think you're arguing a strawman here. The actual reason why drivers tend to live in-tree is that the kernel-driver API changes all the time, and Linus has consistently argued that being able to do backwards-incompatible changes to the kernel-driver API has been necessary to make the drivers as good as they are.
    - repolfx 8y ago
      And yet where is Linux most used? On the server. What hardware do cloud machines have? It's not even public, much of the time. It's all talking to hypervisors. OSv is an example of going back to the drawing board for the majority of Linux's use cases and creating something radically smaller and with radically less 'bullshit' (it runs much faster as a consequence).

qplex 8y ago

It's not inefficiency in systems design. Some jobs are simply bullshit to begin with, and what actually enables us to have them around are the very efficient systems we have.

rayiner 8y ago

What makes you think those simpler policies would work? The real world is complex and messy because people are complex and messy. It's like looking at the Windows or Linux source code and saying it "would have been better solved by having better simplier policies in place." It's superficially true in that you could have simpler designs that accomplish any given function of those operating systems. But for the most part e.g. Linux evolved the way it did for a reason, and almost none of the 20+ million lines in the source tree are "bullshit code."

raverbashing 8y ago
And I'd say a lot of that complexity in both cases is because of one reason: people will want to abuse the system
rorykoehler 8y ago
If that were true my companies current strategy of throwing change management consultants at problems rather than programmers wouldn't be half as successful as it is. Your windows /linux example is a bad one and i don't think designing /building Linux could ever be classified as a bullshit job. As for real world complexity this applies mainly to physical phenomena (self driving cars for example) and less to bureaucratic business organisational structures which is where most bs jobs also happen to exist.
repolfx 8y ago
Well that depends a lot on your definition of bullshit. Linux evolved the way it did for various reasons, but how many are still relevant today? Would you write a kernel in C these days? I wouldn't. There are production quality kernels written in at least C++ which benefit from its features, and it's been demonstrated that you can write entire operating systems in managed languages like Java as well. Why should we suffer an endless parade of exploitable memory bugs in kernel space? It's not technical requirements driving that. Would you write a GPLd kernel these days? I wouldn't. Not much new software is being GPLd these days, it's all Apache or similar licenses. The policy of trying to maintain every driver in-tree has caused vast amounts of time to be spent on workarounds like installers that compile things client-side, enforcement is poor, lots of time is lost due to needless recompiles, API churn, poor usability of desktop software and so on. Has Linux benefited from correspondingly amazing hardware support? No. Desktop Linux is a morass of bugs that often still can't suspend properly, and in the server realm it's now more often than not talking to virtualised hardware anyway. I could go on. There's a LOT of simplification and "bullshit work" that could be optimised out, even in the realm of a very concrete thing without much room for innovation like an OS kernel - partly because times changed but Linux didn't.
- majewsky 8y ago
  > Would you write a GPLd kernel these days? I wouldn't. [...] I think you're arguing a strawman here. The actual reason why drivers tend to live in-tree is that the kernel-driver API changes all the time, and Linus has consistently argued that being able to do backwards-incompatible changes to the kernel-driver API has been necessary to make the drivers as good as they are.
  - repolfx 8y ago
    And yet where is Linux most used? On the server. What hardware do cloud machines have? It's not even public, much of the time. It's all talking to hypervisors. OSv is an example of going back to the drawing board for the majority of Linux's use cases and creating something radically smaller and with radically less 'bullshit' (it runs much faster as a consequence).