5 ms·

Is it a bad thing? That might make the installed size large, but if it's isolated to Bazel, managed by Bazel, updated by Bazel, etc, then why does it matter wh

Is it a bad thing? That might make the installed size large, but if it's isolated to Bazel, managed by Bazel, updated by Bazel, etc, then why does it matter whether it's a JVM, a Python binary, a JS VM, or anything else?

ivankolev 7y ago
sometimes it is, in Enterprise it's very common to have invasive proxies and just yesterday I was fighting Bazel into using different than the built-in cert store. (it tries to fetch some of its components from github, and that fails if you don't use the proper certs)
hannob 7y ago
> Is it a bad thing? Yes. It makes verifiability much harder. E.g. Debian put a lot of work into making a more trustworthy build chain by introducing reproducible builds. There's no Bazel on Debian. And not on many other distros. Because getting Bazel to be built itself is a complexity nightmare. "Here, download this big blob where you have no idea how it's been built" doesn't exactly help.
- zerkten 7y ago
  Could the Bazel folks better define the composition of their blob? That way they can distribute their blob, but someone could substitute for another instance of the JVM. I'm assuming ownership of this lies with Bazel and this is more of a political/motivation problem than a technical one. Or, is that incorrect?
  - hannob 7y ago
    Sure, this is not impossible. But there's a simple fact: The more complex your build chain is the more difficult this is. And Java adds a whole bunch of complexity. Read into the bug report to get an idea what a nightmarish task this is: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782654 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782654
  - lima 7y ago
    The blob is just the JDK + Bazel + a wrapper binary. Just use their regular build artifacts instead if you want to bring your own JDK.
- danpalmer 7y ago
  I don't think bundling in components inherently changes the reproducible builds equation. In fact I think that bundling in a JVM that they know works in a particular way will likely improve the reproducibility of Bazel _setups_ and therefore builds that come out of Bazel, which is their aim.
  - DuskStar 7y ago
    "every time the NSA's compiler binary builds my code I get the same output" isn't really all that comforting. If you can't build the compiler (and/or build tool) how can you be sure that there isn't anything malicious in it? Trusting trust all over again
- new_realist 7y ago
  What’s so hard about: env EXTRA_BAZEL_ARGS="--host_javabase=@local_jdk//:jdk" bash ./compile.sh. To build the bazel binary in a reproducible way, also set SOURCE_DATE_EPOCH.
ylyn 7y ago
Next thing we know, every program is gonna ship with either a slimmed-down (!) 20MB JRE (if you use modules, otherwise it's gonna be worse), 130MB Electron runtime (this makes bundling the JRE seem like a good option), or what have you.. Wait, I think we're already in that era. Oh well. (Cue "but disk space is so cheap nowadays"...)
- sqldba 7y ago
  Isn’t the whole point of dotnet that it ships with all the executables, libraries and binaries too? I don’t know how I feel about it myself.
  - chusk3 7y ago
    You can choose to do a self-contained deployment, which bundles the runtime with your app, or a framework-dependent deployment, which requires a pre-existing shared install. Pick your poison.
- danpalmer 7y ago
  > (Cue "but disk space is so cheap nowadays"...) Sure I'll bite. There are cases where this matters, absolutely, it would also matter if the difference was between 10MB and 10GB, but we're talking about a pretty small relative difference. In return, you get the reliability of not having to worry about how your OS/configuration/other packages may interact with the software. In my opinion that's a huge productivity win, and also fits nicely with the fact that build systems should be thoroughly reproducible and do the same thing everywhere they run. There are some good, niche, reasons for not bundling things like a JVM: - If you're a strong free software advocate and need total control over the freedom in your dependencies. Debian do a lot of dependency unbundling for this reason. They're good at it, but it's not something most people care about or want to deal with the fallout of. - Memory usage optimisation by sharing libraries in memory. This has a nice benefit for native code, but unlikely to do a lot for Java processes from what I understand. This likely _could_ have a significant benefit for the Electron ecosystem given that many people now run 2-3 Electron apps at a time.
  - 7y ago
chii 7y ago
if the version shipped in bazel isn't right for you, then you're stuck with either having to customize it, or wait for it to update.
- danpalmer 7y ago
  But it doesn't have to be right for you, it only has to be right for Bazel. You wouldn't use it for anything else except Bazel, so is it a problem if it's out of date or lacking features? I think that's only a problem for the Bazel developers.
  - btilly 7y ago
    It is a problem if it has a security hole. Or if you have reason not to trust the Bazel developers. (Or trust people who might have illegitimate access to said developers' machines - for example the NSA.) See https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7... for the canonical paper on why it can be important to be able to recreate your build chain from scratch in a verified way.
sgn 7y ago
Does it also ship java binary? Is the java binary statical-linked? If not, how can we build on platform with not-mainstream libc (read Linux with musl libc like Alpine, Void)?
- tempay 7y ago
  I don’t know if this has changed but a couple of years ago you just had to try and build bazel from source which was extremely painful.

ivankolev 7y ago

sometimes it is, in Enterprise it's very common to have invasive proxies and just yesterday I was fighting Bazel into using different than the built-in cert store. (it tries to fetch some of its components from github, and that fails if you don't use the proper certs)

hannob 7y ago

> Is it a bad thing? Yes. It makes verifiability much harder. E.g. Debian put a lot of work into making a more trustworthy build chain by introducing reproducible builds. There's no Bazel on Debian. And not on many other distros. Because getting Bazel to be built itself is a complexity nightmare. "Here, download this big blob where you have no idea how it's been built" doesn't exactly help.

zerkten 7y ago
Could the Bazel folks better define the composition of their blob? That way they can distribute their blob, but someone could substitute for another instance of the JVM. I'm assuming ownership of this lies with Bazel and this is more of a political/motivation problem than a technical one. Or, is that incorrect?
- hannob 7y ago
  Sure, this is not impossible. But there's a simple fact: The more complex your build chain is the more difficult this is. And Java adds a whole bunch of complexity. Read into the bug report to get an idea what a nightmarish task this is: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782654 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782654
- lima 7y ago
  The blob is just the JDK + Bazel + a wrapper binary. Just use their regular build artifacts instead if you want to bring your own JDK.
danpalmer 7y ago
I don't think bundling in components inherently changes the reproducible builds equation. In fact I think that bundling in a JVM that they know works in a particular way will likely improve the reproducibility of Bazel _setups_ and therefore builds that come out of Bazel, which is their aim.
- DuskStar 7y ago
  "every time the NSA's compiler binary builds my code I get the same output" isn't really all that comforting. If you can't build the compiler (and/or build tool) how can you be sure that there isn't anything malicious in it? Trusting trust all over again
new_realist 7y ago
What’s so hard about: env EXTRA_BAZEL_ARGS="--host_javabase=@local_jdk//:jdk" bash ./compile.sh. To build the bazel binary in a reproducible way, also set SOURCE_DATE_EPOCH.

ylyn 7y ago

Next thing we know, every program is gonna ship with either a slimmed-down (!) 20MB JRE (if you use modules, otherwise it's gonna be worse), 130MB Electron runtime (this makes bundling the JRE seem like a good option), or what have you.. Wait, I think we're already in that era. Oh well. (Cue "but disk space is so cheap nowadays"...)

sqldba 7y ago
Isn’t the whole point of dotnet that it ships with all the executables, libraries and binaries too? I don’t know how I feel about it myself.
- chusk3 7y ago
  You can choose to do a self-contained deployment, which bundles the runtime with your app, or a framework-dependent deployment, which requires a pre-existing shared install. Pick your poison.
danpalmer 7y ago
> (Cue "but disk space is so cheap nowadays"...) Sure I'll bite. There are cases where this matters, absolutely, it would also matter if the difference was between 10MB and 10GB, but we're talking about a pretty small relative difference. In return, you get the reliability of not having to worry about how your OS/configuration/other packages may interact with the software. In my opinion that's a huge productivity win, and also fits nicely with the fact that build systems should be thoroughly reproducible and do the same thing everywhere they run. There are some good, niche, reasons for not bundling things like a JVM: - If you're a strong free software advocate and need total control over the freedom in your dependencies. Debian do a lot of dependency unbundling for this reason. They're good at it, but it's not something most people care about or want to deal with the fallout of. - Memory usage optimisation by sharing libraries in memory. This has a nice benefit for native code, but unlikely to do a lot for Java processes from what I understand. This likely _could_ have a significant benefit for the Electron ecosystem given that many people now run 2-3 Electron apps at a time.
- 7y ago

chii 7y ago

if the version shipped in bazel isn't right for you, then you're stuck with either having to customize it, or wait for it to update.

danpalmer 7y ago
But it doesn't have to be right for you, it only has to be right for Bazel. You wouldn't use it for anything else except Bazel, so is it a problem if it's out of date or lacking features? I think that's only a problem for the Bazel developers.
- btilly 7y ago
  It is a problem if it has a security hole. Or if you have reason not to trust the Bazel developers. (Or trust people who might have illegitimate access to said developers' machines - for example the NSA.) See https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7... for the canonical paper on why it can be important to be able to recreate your build chain from scratch in a verified way.

sgn 7y ago

Does it also ship java binary? Is the java binary statical-linked? If not, how can we build on platform with not-mainstream libc (read Linux with musl libc like Alpine, Void)?

tempay 7y ago
I don’t know if this has changed but a couple of years ago you just had to try and build bazel from source which was extremely painful.