1. 8

  2. 22

    This is a weird one NGL

    1. 17

      Strong “Old man yelling at clouds” vibe but I don’t hate it :P

      1. 16

        Someone complaining about a lack of attention to detail from kids these days, who gets ‘you’re’ and ‘your’ confused in bold does not present a very compelling argument.

        And I say this as someone who was born an old man and has been complaining about kids these days since before I was a teenager.

    2. 9

      From one professional to another, you’re*.

      Also, if Yocto developers aren’t interested in collaborating with their partners in the business then I would expect the business to choose something else. I’m sorry you don’t like Agile.

      1. 5

        FWIW, the article doesn’t really match with any of the Yocto people I know, except the “we need big build servers” bit.

        1. 3

          I would think not! It doesn’t match with the Yocto people I know, either.

      2. 8

        They went to a real school and endure all of the boring IT fundamentals classes

        This feels like gatekeeping, honestly. “Real school” implies the existence of “fake schools”, which invalidates anyone who hasn’t studied C and assembly and linear algebra at length.

        1. 7

          Yocto People aren’t going to live with you giving them “the same machine as the developers” so they endure 24+ hour builds and have you changing the system requirements with every sprint.

          Haha. Ask me about that time where they gave us the same machine as the developers as in, the five year-old laptops that had been retired for development use, and you had to do the builds under VirtualBox because company policy pretty much mandated Windows. Six-hour builds were the norm, occasionally interrupted by thermal shutdown.

          How come? Easy: all that time was billed to customers.

          I was on the only team where they had sane people in charge, so we could persuade the higher-ups to get a build server. Everyone else basically took six-hour lunch breaks.

          1. 6

            Is this the 2022 version of “Real Programmers Don’t Use Pascal”?

            1. 2

              I’m now kinda curious why the Yocto builds take so long. I get they’re doing a complete embedded linux build kernel and all, but it should be possible to cache a lot unless they’re changing compile flags every time.

              1. 5

                Once things are cached it can be pretty quick; I’ve got my “hack on a package and rebuild an image” cycle down to a few minutes on my current project. I’ve got the whole thing wrapped up in Earthly, it’s pretty neat. Anyway, if you’re one of those companies that can’t find Yocto People, hit me up; I like money and I’ll do the weird stuff.

                1. 1

                  In my (very limited) experience with yocto, you can indeed use caching. For yocto running a rebuild on an unchanged tree already takes long (I remember ~1hour on a non-NVMe-SSD). So that is the absolute minimum that you can use caching to achieve.

                  But then there are (real and imagined) trust-issues with running builds from a (somewhat) unclean working directory. This is easier to see if you look at just the linux kernel: You can (and many people do!) update from one version to the next using git checkout and make; sometimes this leads to build-errors to which the reaction is make mrproper; get_config; make – and then everything works again.

                  So for creating release-worthy yocto-builds, doing a git checkout; git clean -fdx is somewhat mandatory…

                  1. 1

                    I don’t know, but it seems like 1/4 of the time I change something it decides to recompile gcc.

                    And of course there’s no simple option to use system gcc.

                    1. 2

                      It’s not really a simple option: host system toolchains make builds non reproducible.

                      1. 1

                        Of course it is. You just do the same thing as it does now, where recompiling the toolchain inevitably results in recompiling every other package, except you don’t recompile the toolchain (and just recompile everything else when e.g. gcc’s hash changes).