19 ms·

You basically need a compiler farm for fuchsia. I tried compiling it once and it took 3 hours, only to find out to need to recompile to add anything

encryptluks2 5y ago
Have you tried compiling Linux before? Imagine trying to compile MacOS or Windows. I'd say 3 hours is pretty darn good.
- bayindirh 5y ago
  It was taking three hours in 1998. Not anymore. 10 years ago, you would be able to compile your whole BSD kernel and userland (plus KDE) in a week or so, while just checking occasionally whether it's completed or not. This was on a dual core, off the shelf desktop computer.
  - hnlmorg 5y ago
    The GP was talking about whole OS, not just the kernel (just as this Fuchsia workstation is too). A week also seems pretty long for BSD. I'm sure I spun up FreeBSD with Gnome 2 in ~24hours once (it was definitely less than a week because I had a weekend to prepare it for a house party). Though admittedly I didn't compile base. But this was a machine from around 2005 sort of era, maybe even earlier.
    - bayindirh 5y ago
      I'm not a BSD person. A colleague did it back in the day. This is why I also noted "done leisurely, and without any effort to do it as fast as it's possible", since he said it he compiled it that way, without rush.
- zaarn 5y ago
  Linux does not take 3 hours even on spinning rust. I'd say one hour at worst. On my computer with the compile happening on an NVMe, it takes about 15 minutes.
  - defer 5y ago
    But that's just the kernel. This is more akin to compiling the kernel plus all packages and applications that make up the operating system.
    - deleted 5y ago
      [deleted]
  - zeusk 5y ago
    Because you're conflating kernel compile times with an entire OS? Linux userspace compilation can take 6+ hours very easily (try yourself with Gentoo). At Microsoft, our massive servers churn out nightly Windows image overnight usually 5pm-10am next morning.
  - pjmlp 5y ago
    I clearly rememeber leaving my computer to build during the night, specially when I was crazy enough to experiement with Gentoo.
  - anaisbetts 5y ago
    The Linux kernel takes 15 minutes. Compiling all of Linux (aka the equivalent of Gentoo emerge'ing e.g. gnome-desktop from whole cloth, which is what this is), would not take 15 minutes.
    - zaarn 5y ago
      But do you have to emerge the entirety of your system because you added a browser? Since that seems to be how Fuchsia's compile times are working.
- bitcharmer 5y ago
  Compiling Linux takes under 3 minutes on my workstation. 3 hours is far from pretty darn good.
  - muro 5y ago
    Kernel only
    - forty 5y ago
      A full buildroot (incl. Kernel and full toolchain) compile is not much more than that even on my laptop, when using ccache.
      - bitcharmer 5y ago
        Just rechecked because I'm getting down voted. Kernel is 90 seconds, full toolchain and xfce environment is 6 minutes
  - charcircuit 5y ago
    The default configuration took me 2 minutes and 4 seconds with a 3700X (8 cores).
    - cyberpunk 5y ago
      With the entire base userland, X, Firefox, Gnome etc? Impressive.
      - charcircuit 5y ago
        We were talking about building Linux, not building Linux + programs to run on it.
defer 5y ago
I'm not familiar with fuschia but those times are what I'd consider normal for an initial compilation of an operating system in regular consumer workstations. I work on the android operating system and very rarely compile the whole thing from scratch in development environments. Incremental builds plus adb sync (think rsync between compiled artifacts in host and device) make it into a manageable workflow. Even incrementally, it takes a few minutes to see your changes and that can be a source of frustration for newcomers who are used to instant feedback. Being productive requires making good decisions on how often and what to compile as well as strategies for filling up compilation time.
- dalbasal 5y ago
  The last sentence is an eyebrow raiser
  - defer 5y ago
    Yeah, I mentioned it because I see peers doing different things to be productive during compilation times while newcomers will stare at compiler output. Some will jump to writing documentation, take care of issue management, work on some other ticket entirely, etc.
    - spoiler 5y ago
      I'm vastly oversimplifying the issue (also I'm not a doctor), but didn't studies show that this type of multitasking is bad for our mental health and increases the likelihood of burnout?
      - defer 5y ago
        It's certainly possible, I honestly wouldn't know. Anedoctaly, I find it worse on my mental health to just sit around waiting for things to finish.
      - simonh 5y ago
        Not a doctor either, just going on articles I've read on this. The sort of multitasking that causes those problems is when both tasks need frequent attention. If you can essentially leave a task alone for several hours, with some sort of notification if there's a problem, that's fine. Even things that don't take much attention but are ongoing tasks, like doing the ironing, are fine depending what else you're combining it with.
IshKebab 5y ago
What does it compile? If it does stuff like compiling LLVM from scratch I can understand that.
rurban 5y ago
I need to constantly recompile my work app, and it needs a few hours. the last 2 months I did nothing else than trying to compile this app in various configurations and dependency versions to find a state which works. there was none. commercial Windows shit of course, no ccache, and most of the time McAfee antivirus interferes. just 3 hours would be very nice. clasp also needs about a day.
- jdjkfkf 5y ago
  Solution: dont run antivirus on workstation, or at the very least exclude your dev folders from scanning. Alot of your ”compile time” is antivirus eating cpu on compile artifacts.
  - hnlmorg 5y ago
    I think the charitable way to read their comment is that they're aware the AV is a problem but can't do anything about it because it is a work machine and thus likely administrated by a whole other team.
    - simonh 5y ago
      Even in that case it's worth talking to the security team about it.
      - hnlmorg 5y ago
        They may have done. I've worked at plenty of places where the corporate machine was so locked down and corporate IT was so far removed from development that I ended up using two machines: a corporate one with AD credentials and a BOYD MacBook Pro. Some places eventually allowed me to run inTune on the MBP to access some corporate services but others haven't. And I know of places that have flat out refused engineers to BOYD.
      - rurban 5y ago
        the av ticket is only a few months old yet. in this env a typical IT ticket needs 6 months. esp. when you are not allowed to talk to anyone. a windows shop.
alephnan 5y ago
I didn’t know compiler farms were a thing, but it makes perfect sense. During university, our computer security class involved finding exploits in Firefox. It took 8 hours to compile on our average student grade compute. There were probably faster incremental ways to build, but navigating the Firefox open source code base was hard to entry point as a student. Effectively, most people got to compile Firefox a few times, but no one went further than making any code changes or discoveries. Navigating the Firefox build and tool chain is probably an undergrad course in and of itself, much less make any meaningful merge request or finding a vulnerability. Overall, horribly designed curriculum. The expectation was for undergrads to find a zero day in Firefox. The professor was a researcher from Microsoft, but didn’t seem like he had realistic expectations for undergrads. Maybe they were throwing darts, hoping one student finds an novel exploit, and they can be cited. In the end, no student found an exploit or made any code changes. I was the only who found a DoS code payload for Firefox, but it was neither a zero day (poking around a known less developed API) nor high risk. It merely crashed Firefox on any webpage which contained this 2 lines of JavaScript. In the end, I got the lowest grade in the class because the professor changed the rubric after no one else found anything. Finding this exploit went from 80% of the grade to 5%, and participation credit went from 10% to 70%.
- pabs3 5y ago
  A couple of tools to make compile farms easier to use: https://distcc.github.io/ https://distcc.github.io/ https://github.com/icecc/icecream https://github.com/icecc/icecream
- lloydatkinson 5y ago
  Wow that sounds like a really frustrating and demotivating experience. Seems totally ridiculous and beyond any realistic expectations - I’m surprised nobody involved didn’t raise concerns. I had a similar but not as bad experience. The lecturer was brand new and wanted us to design a programming language after a single vague PowerPoint and the worst introduction to yacc or lex or whatever they are. We were also undergraduates. After several weeks of complaints he provided an example language and parser etc. Still it was simply too hard and in the end nobody could do it. I believe I managed to add a minor feature to his example language as my submission. I managed to get a reasonably high grade simply because I freely admitted I struggled with the entire task but could explain language theory and made comparisons with other languages I know and what features I would have added if I could. Some people totally wrote that whole module off and planned around the scoring system where one failed module in a year would just be discounted and an averaged score created.
lelanthran 5y ago
> You basically need a compiler farm for fuchsia. I tried compiling it once and it took 3 hours, only to find out to need to recompile to add anything Not too bad for an OS and all the utilities and programs that it comes with. The Linux equivalent will be compiling Gentoo (probably a lot longer than 3 hours, even on good hardware). In 2003, as part of a university assignment, I used a CORBA ORM called 'mico' (or 'micro', not too sure) written in glorious C++ with as much use of templates that the developers could use, and that took a full 4 days to compile on my aging 1998 laptop[1]. When I switched to an expensive 2003 desktop a few months later[2] the compilation of the same package with the same flags on the same OS (Slackware) took less than five hours. It is amazing what speed improvements we saw between 1995 and 2005. Just between 1995 (when I bought my 486 desktop) and 2000 (when I was using a pentium pro or something better than that), machines had roughly doubled in performance at the same price. I really doubt that machines from five years ago are going to be that much better than one from today. [1] As a student, I counted myself lucky to even have a laptop of my own, instead of booking time at the university lab. [2] The compilation experience convinced me to save for a few months to get something expensive with lots of RAM
- sho_hn 5y ago
  To add to this: A much more common Linux equivalent to this is "making Yocto Linux recompile your OS image". Yocto is not the only option in this space, but perhaps the closest embedded Linux development has to a standard option. Yocto is not entirely unlike Gentoo - recipes describe components of the system, which is built from source - but with the addition of a fairly sophisticated caching scheme, where the input to a recipe is hashed and the hash used to store the outcome, which is then reused in future builds (and the cache can be shared by different builders) unless the input changes. The other key feature of Yocto is that the system is composable in layers, where upper layers add, extend or override recipes from the lower layers. Layers can and are provided by different parties (e.g. BSP layers from HW vendors or their SW partners). Yocto Linux is used by projects which need to be able to guarantee that they can bootstrap their OS build, customize the build (e.g. filter out use of certain licenses or use a specific toolchain) and to manage SW supply chain (the layer idea, and then in a business contact something like RASIC for the layers). To sum it up, "rebuilding the entire Linux OS w/ caching" is absolutely the norm in embedded dev, as is having a compiler farm doing this hooked into your CI. Edge nodes like developer laptops then access the CI build farm's caches to make a local build bearable, with the caveat that you don't get incremental builds at the component level this way, so usually you still want to either dev separately against an SDK (or reuse the build root) or at least keep your components small and modular enough to not make it painful. Automotive, network equipment (e.g. routers), stage/production equipment (mixers and other networked A/V gear, etc.) and many other parts of the SW world work this way. Hacker News is mostly exposed to web development and desktop Linux/mobile app development, which are pretty different. Indeed, perhaps the most surprising thing is how different desktop Linux development is from embedded Linux development and how little cross-pollination between these communities is taking place. If you develop your for desktop Linux, the distro on your box also serves as its SDK - you just install a bunch of -dev packages from your package manager and build against the host. Or perhaps a Docker image as build env in some cases. But you generally never rebuild/bootstrap the OS, which in embedded is the primary unit of work (with mitigations such as caching). One side-effect of this is that embedded systems and desktop systems tend to approach updates/OTA differently. In the package/binary-based systems, OTAs come in via the package manager. Embedded systems historically tend to go for full system image updates with again some mitigations such as binary deltas, and then A/B partition update schemes. Or a partitioning of the update content that is orthogonal to the partitioning that goes into the OS image build. Lately there's a trend for seperating applications out into container images that get deployed seperately from the base OS image, and thoughts about containers that can move between embedded devices on the edge and the cloud infra in the back.
deleted 5y ago
[deleted]
phendrenad2 5y ago
That seems excessive. I wonder what they're compiling. Probably building LLVM, cpython, nodejs, etc.

encryptluks2 5y ago

Have you tried compiling Linux before? Imagine trying to compile MacOS or Windows. I'd say 3 hours is pretty darn good.

bayindirh 5y ago
It was taking three hours in 1998. Not anymore. 10 years ago, you would be able to compile your whole BSD kernel and userland (plus KDE) in a week or so, while just checking occasionally whether it's completed or not. This was on a dual core, off the shelf desktop computer.
- hnlmorg 5y ago
  The GP was talking about whole OS, not just the kernel (just as this Fuchsia workstation is too). A week also seems pretty long for BSD. I'm sure I spun up FreeBSD with Gnome 2 in ~24hours once (it was definitely less than a week because I had a weekend to prepare it for a house party). Though admittedly I didn't compile base. But this was a machine from around 2005 sort of era, maybe even earlier.
  - bayindirh 5y ago
    I'm not a BSD person. A colleague did it back in the day. This is why I also noted "done leisurely, and without any effort to do it as fast as it's possible", since he said it he compiled it that way, without rush.
zaarn 5y ago
Linux does not take 3 hours even on spinning rust. I'd say one hour at worst. On my computer with the compile happening on an NVMe, it takes about 15 minutes.
- defer 5y ago
  But that's just the kernel. This is more akin to compiling the kernel plus all packages and applications that make up the operating system.
  - deleted 5y ago
    [deleted]
- zeusk 5y ago
  Because you're conflating kernel compile times with an entire OS? Linux userspace compilation can take 6+ hours very easily (try yourself with Gentoo). At Microsoft, our massive servers churn out nightly Windows image overnight usually 5pm-10am next morning.
- pjmlp 5y ago
  I clearly rememeber leaving my computer to build during the night, specially when I was crazy enough to experiement with Gentoo.
- anaisbetts 5y ago
  The Linux kernel takes 15 minutes. Compiling all of Linux (aka the equivalent of Gentoo emerge'ing e.g. gnome-desktop from whole cloth, which is what this is), would not take 15 minutes.
  - zaarn 5y ago
    But do you have to emerge the entirety of your system because you added a browser? Since that seems to be how Fuchsia's compile times are working.
bitcharmer 5y ago
Compiling Linux takes under 3 minutes on my workstation. 3 hours is far from pretty darn good.
- muro 5y ago
  Kernel only
  - forty 5y ago
    A full buildroot (incl. Kernel and full toolchain) compile is not much more than that even on my laptop, when using ccache.
    - bitcharmer 5y ago
      Just rechecked because I'm getting down voted. Kernel is 90 seconds, full toolchain and xfce environment is 6 minutes
- charcircuit 5y ago
  The default configuration took me 2 minutes and 4 seconds with a 3700X (8 cores).
  - cyberpunk 5y ago
    With the entire base userland, X, Firefox, Gnome etc? Impressive.
    - charcircuit 5y ago
      We were talking about building Linux, not building Linux + programs to run on it.

defer 5y ago

I'm not familiar with fuschia but those times are what I'd consider normal for an initial compilation of an operating system in regular consumer workstations. I work on the android operating system and very rarely compile the whole thing from scratch in development environments. Incremental builds plus adb sync (think rsync between compiled artifacts in host and device) make it into a manageable workflow. Even incrementally, it takes a few minutes to see your changes and that can be a source of frustration for newcomers who are used to instant feedback. Being productive requires making good decisions on how often and what to compile as well as strategies for filling up compilation time.

dalbasal 5y ago
The last sentence is an eyebrow raiser
- defer 5y ago
  Yeah, I mentioned it because I see peers doing different things to be productive during compilation times while newcomers will stare at compiler output. Some will jump to writing documentation, take care of issue management, work on some other ticket entirely, etc.
  - spoiler 5y ago
    I'm vastly oversimplifying the issue (also I'm not a doctor), but didn't studies show that this type of multitasking is bad for our mental health and increases the likelihood of burnout?
    - defer 5y ago
      It's certainly possible, I honestly wouldn't know. Anedoctaly, I find it worse on my mental health to just sit around waiting for things to finish.
    - simonh 5y ago
      Not a doctor either, just going on articles I've read on this. The sort of multitasking that causes those problems is when both tasks need frequent attention. If you can essentially leave a task alone for several hours, with some sort of notification if there's a problem, that's fine. Even things that don't take much attention but are ongoing tasks, like doing the ironing, are fine depending what else you're combining it with.

IshKebab 5y ago

What does it compile? If it does stuff like compiling LLVM from scratch I can understand that.

rurban 5y ago

I need to constantly recompile my work app, and it needs a few hours. the last 2 months I did nothing else than trying to compile this app in various configurations and dependency versions to find a state which works. there was none. commercial Windows shit of course, no ccache, and most of the time McAfee antivirus interferes. just 3 hours would be very nice. clasp also needs about a day.

jdjkfkf 5y ago
Solution: dont run antivirus on workstation, or at the very least exclude your dev folders from scanning. Alot of your ”compile time” is antivirus eating cpu on compile artifacts.
- hnlmorg 5y ago
  I think the charitable way to read their comment is that they're aware the AV is a problem but can't do anything about it because it is a work machine and thus likely administrated by a whole other team.
  - simonh 5y ago
    Even in that case it's worth talking to the security team about it.
    - hnlmorg 5y ago
      They may have done. I've worked at plenty of places where the corporate machine was so locked down and corporate IT was so far removed from development that I ended up using two machines: a corporate one with AD credentials and a BOYD MacBook Pro. Some places eventually allowed me to run inTune on the MBP to access some corporate services but others haven't. And I know of places that have flat out refused engineers to BOYD.
    - rurban 5y ago
      the av ticket is only a few months old yet. in this env a typical IT ticket needs 6 months. esp. when you are not allowed to talk to anyone. a windows shop.

alephnan 5y ago

I didn’t know compiler farms were a thing, but it makes perfect sense. During university, our computer security class involved finding exploits in Firefox. It took 8 hours to compile on our average student grade compute. There were probably faster incremental ways to build, but navigating the Firefox open source code base was hard to entry point as a student. Effectively, most people got to compile Firefox a few times, but no one went further than making any code changes or discoveries. Navigating the Firefox build and tool chain is probably an undergrad course in and of itself, much less make any meaningful merge request or finding a vulnerability. Overall, horribly designed curriculum. The expectation was for undergrads to find a zero day in Firefox. The professor was a researcher from Microsoft, but didn’t seem like he had realistic expectations for undergrads. Maybe they were throwing darts, hoping one student finds an novel exploit, and they can be cited. In the end, no student found an exploit or made any code changes. I was the only who found a DoS code payload for Firefox, but it was neither a zero day (poking around a known less developed API) nor high risk. It merely crashed Firefox on any webpage which contained this 2 lines of JavaScript. In the end, I got the lowest grade in the class because the professor changed the rubric after no one else found anything. Finding this exploit went from 80% of the grade to 5%, and participation credit went from 10% to 70%.

pabs3 5y ago
A couple of tools to make compile farms easier to use: https://distcc.github.io/ https://distcc.github.io/ https://github.com/icecc/icecream https://github.com/icecc/icecream
lloydatkinson 5y ago
Wow that sounds like a really frustrating and demotivating experience. Seems totally ridiculous and beyond any realistic expectations - I’m surprised nobody involved didn’t raise concerns. I had a similar but not as bad experience. The lecturer was brand new and wanted us to design a programming language after a single vague PowerPoint and the worst introduction to yacc or lex or whatever they are. We were also undergraduates. After several weeks of complaints he provided an example language and parser etc. Still it was simply too hard and in the end nobody could do it. I believe I managed to add a minor feature to his example language as my submission. I managed to get a reasonably high grade simply because I freely admitted I struggled with the entire task but could explain language theory and made comparisons with other languages I know and what features I would have added if I could. Some people totally wrote that whole module off and planned around the scoring system where one failed module in a year would just be discounted and an averaged score created.

lelanthran 5y ago

> You basically need a compiler farm for fuchsia. I tried compiling it once and it took 3 hours, only to find out to need to recompile to add anything Not too bad for an OS and all the utilities and programs that it comes with. The Linux equivalent will be compiling Gentoo (probably a lot longer than 3 hours, even on good hardware). In 2003, as part of a university assignment, I used a CORBA ORM called 'mico' (or 'micro', not too sure) written in glorious C++ with as much use of templates that the developers could use, and that took a full 4 days to compile on my aging 1998 laptop[1]. When I switched to an expensive 2003 desktop a few months later[2] the compilation of the same package with the same flags on the same OS (Slackware) took less than five hours. It is amazing what speed improvements we saw between 1995 and 2005. Just between 1995 (when I bought my 486 desktop) and 2000 (when I was using a pentium pro or something better than that), machines had roughly doubled in performance at the same price. I really doubt that machines from five years ago are going to be that much better than one from today. [1] As a student, I counted myself lucky to even have a laptop of my own, instead of booking time at the university lab. [2] The compilation experience convinced me to save for a few months to get something expensive with lots of RAM

sho_hn 5y ago
To add to this: A much more common Linux equivalent to this is "making Yocto Linux recompile your OS image". Yocto is not the only option in this space, but perhaps the closest embedded Linux development has to a standard option. Yocto is not entirely unlike Gentoo - recipes describe components of the system, which is built from source - but with the addition of a fairly sophisticated caching scheme, where the input to a recipe is hashed and the hash used to store the outcome, which is then reused in future builds (and the cache can be shared by different builders) unless the input changes. The other key feature of Yocto is that the system is composable in layers, where upper layers add, extend or override recipes from the lower layers. Layers can and are provided by different parties (e.g. BSP layers from HW vendors or their SW partners). Yocto Linux is used by projects which need to be able to guarantee that they can bootstrap their OS build, customize the build (e.g. filter out use of certain licenses or use a specific toolchain) and to manage SW supply chain (the layer idea, and then in a business contact something like RASIC for the layers). To sum it up, "rebuilding the entire Linux OS w/ caching" is absolutely the norm in embedded dev, as is having a compiler farm doing this hooked into your CI. Edge nodes like developer laptops then access the CI build farm's caches to make a local build bearable, with the caveat that you don't get incremental builds at the component level this way, so usually you still want to either dev separately against an SDK (or reuse the build root) or at least keep your components small and modular enough to not make it painful. Automotive, network equipment (e.g. routers), stage/production equipment (mixers and other networked A/V gear, etc.) and many other parts of the SW world work this way. Hacker News is mostly exposed to web development and desktop Linux/mobile app development, which are pretty different. Indeed, perhaps the most surprising thing is how different desktop Linux development is from embedded Linux development and how little cross-pollination between these communities is taking place. If you develop your for desktop Linux, the distro on your box also serves as its SDK - you just install a bunch of -dev packages from your package manager and build against the host. Or perhaps a Docker image as build env in some cases. But you generally never rebuild/bootstrap the OS, which in embedded is the primary unit of work (with mitigations such as caching). One side-effect of this is that embedded systems and desktop systems tend to approach updates/OTA differently. In the package/binary-based systems, OTAs come in via the package manager. Embedded systems historically tend to go for full system image updates with again some mitigations such as binary deltas, and then A/B partition update schemes. Or a partitioning of the update content that is orthogonal to the partitioning that goes into the OS image build. Lately there's a trend for seperating applications out into container images that get deployed seperately from the base OS image, and thoughts about containers that can move between embedded devices on the edge and the cloud infra in the back.

deleted 5y ago

[deleted]

phendrenad2 5y ago

That seems excessive. I wonder what they're compiling. Probably building LLVM, cpython, nodejs, etc.