3 ms·

I wasn't talking about functional problems. It was a simple observation that big companies were not going to convince Linux distributors to add frame pointers a

I wasn't talking about functional problems. It was a simple observation that big companies were not going to convince Linux distributors to add frame pointers anytime soon and that what those distributors do is relevant. All of the companies involved believed that they were special and decided to build their own (poorly managed) distribution called "third party code" and having to deal with it was not my best experience working at these companies.

starspangled 3y ago
Oh, I just assumed you were talking about Google's Linux distribution and applications it runs on its fleet. I must have mis-assumed. Re-reading... maybe you weren't talking about any builds but just whether or not to oppose kernel and toolchain defaulting to omit frame pointers?
- adsharma 3y ago
  Google didn't have a Linux distribution for a long time (the one everyone used on the desktop was an outdated rpm based distro, we mostly ignored it for development purposes). What existed was a x86 to x86 cross compilation environment and the libraries involved were manually imported by developers who needed that particular library. My argument was about the cost of ensuring that those libraries were compiled with frame pointers when much of the open source community was defaulting to omit-fp.
  - dooglius 3y ago
    Would it not be easier to patch compilers to always assume the equivalent of -fno-omit-frame-pointer
    - adsharma 3y ago
      That was done in 2005. But the task of auditing the supply chain to ensure that every single shared library you ever linked with was compiled a certain way was still hard. Nothing prevented an intern or a new employee from checking in a library without frame pointers into the third-party repo. In 2024, you'd probably create a "build container" that all developers are required to use to build binaries or pay a linux distributor to build that container. But cross compilation was the preferred approach back then. So all binaries had a rpath (run time search path to look for shared library) that ignored the distributor supplied libraries. Having come from a open source background, I found this system hard to digest. But there was a lot of social pressure to work as a bee in a system that thousands of other very competent engineers are using (quite successfully). I remember briefly talking to a chrome OS related group who were using the "build your own custom distro" approach, before deciding to move to another faang.
      - cruffle_duffle 3y ago
        > or pay a linux distributor to build that container. What does this mean?
        adsharma 3y ago
        I didn't mean anything nefarious here :) Since Google would rather have the best brains in the industry build the next search indexing algorithm or the browser, they didn't have the time to invest human capital into building a better open source friendly dev environment. A natural alternative is to contract out the work. Linux distributors were good candidates for such contract work. But the vibe back then was Google could build better alternatives to some of these libraries and therefore bridging the gap between dev experience as an open source dev vs in house software engineer wasn't important. You could see the same argument play out in git vs monorepo etc, where people take up strong positions on a particular narrow tech topic, whereas the larger issue gets ignored as a result of these belief systems.

starspangled 3y ago

Oh, I just assumed you were talking about Google's Linux distribution and applications it runs on its fleet. I must have mis-assumed. Re-reading... maybe you weren't talking about any builds but just whether or not to oppose kernel and toolchain defaulting to omit frame pointers?

adsharma 3y ago
Google didn't have a Linux distribution for a long time (the one everyone used on the desktop was an outdated rpm based distro, we mostly ignored it for development purposes). What existed was a x86 to x86 cross compilation environment and the libraries involved were manually imported by developers who needed that particular library. My argument was about the cost of ensuring that those libraries were compiled with frame pointers when much of the open source community was defaulting to omit-fp.
- dooglius 3y ago
  Would it not be easier to patch compilers to always assume the equivalent of -fno-omit-frame-pointer
  - adsharma 3y ago
    That was done in 2005. But the task of auditing the supply chain to ensure that every single shared library you ever linked with was compiled a certain way was still hard. Nothing prevented an intern or a new employee from checking in a library without frame pointers into the third-party repo. In 2024, you'd probably create a "build container" that all developers are required to use to build binaries or pay a linux distributor to build that container. But cross compilation was the preferred approach back then. So all binaries had a rpath (run time search path to look for shared library) that ignored the distributor supplied libraries. Having come from a open source background, I found this system hard to digest. But there was a lot of social pressure to work as a bee in a system that thousands of other very competent engineers are using (quite successfully). I remember briefly talking to a chrome OS related group who were using the "build your own custom distro" approach, before deciding to move to another faang.
    - cruffle_duffle 3y ago
      > or pay a linux distributor to build that container. What does this mean?
      - adsharma 3y ago
        I didn't mean anything nefarious here :) Since Google would rather have the best brains in the industry build the next search indexing algorithm or the browser, they didn't have the time to invest human capital into building a better open source friendly dev environment. A natural alternative is to contract out the work. Linux distributors were good candidates for such contract work. But the vibe back then was Google could build better alternatives to some of these libraries and therefore bridging the gap between dev experience as an open source dev vs in house software engineer wasn't important. You could see the same argument play out in git vs monorepo etc, where people take up strong positions on a particular narrow tech topic, whereas the larger issue gets ignored as a result of these belief systems.