[libre-riscv-dev] Building Docker Containers

[Luke Kenneth Casson Leighton]

On Sun, Mar 29, 2020 at 2:48 PM Immanuel, Yehowshua U
<yimmanuel3 at gatech.edu> wrote:

> We really need to start building docker containers for our setups.

no.  sorry.

i'm on a mobile broadband connection.

docker FORCES massive downloads onto people, through "overlays" over
which you have absolutely no control, even on a day-by-day basis.

my brother dan asked me to install couchdb for him, in a kubernetes container.

a simple recompile - which should have been a matter of under 2
megabytes - turned into a nightmare 1 GIGABYTE download - over my
stepfather's mobile internet connection - thanks to a quotes new
release quotes of the kubernetes API from google.

he's over 70, retired, on pension, and me using up his mobile
broadband quota and forcing to have to pay a massive 40 GBP extra that
month: this is not acceptable.

so NO.

we are *not* developing code that is for the exclusive domain of the wealthy

https://www.linuxjournal.com/content/line-length-limits

"There's very little chance that Alastair's patch will make it into
the kernel. Linus Torvalds is very strict about making sure Linux
development does not favor wealthy people. He wants developers working
on ancient hardware to have the same benefits and capabilities as
those working with the benefit of the latest gadgets."

it's the same thing here.

docker is for "fixed deployment and release".  it will be
"appropriate" (not reallly) to release docckkkaaaah files once we have
stable releases.  however given the complete lack of stability,
versioning inside docker itself, and the complete and utter lack of
security in its design, you'd need to twist my arm one hell of a lot
before i *reluctantly* agree to its use for this project.

now if _someone else_ wants to do docker files, they're more than
welcome - and learn how useful they really are.  however they're
absolutely *not* going onto the FTP server: it's only a 12 GB
partition and it's 60% used already.

regarding building of gcc for powerpc: if you're doing that, there's
something wrong.  gcc is *already* available as cross-compiled debian
packages.  i have these installed:
ii  binutils-powerpc64-linux-gnu                     2.34-5
                      amd64        GNU binary utilities, for
powerpc64-linux-gnu target
ii  cpp-6-powerpc64-linux-gnu                        6.3.0-18cross1
                      amd64        GNU C preprocessor
ii  cpp-8-powerpc64-linux-gnu                        8.4.0-1cross1
                      amd64        GNU C preprocessor
ii  cpp-9-powerpc64-linux-gnu                        9.2.1-28cross1
                      amd64        GNU C preprocessor
ii  cpp-powerpc64-linux-gnu                          4:9.2.1-3
                      amd64        GNU C preprocessor (cpp) for the
ppc64 architecture
ii  g++-6-powerpc64-linux-gnu                        6.3.0-18cross1
                      amd64        GNU C++ compiler
ii  gcc-6-powerpc64-linux-gnu                        6.3.0-18cross1
                      amd64        GNU C compiler
ii  gcc-6-powerpc64-linux-gnu-base:amd64             6.3.0-18cross1
                      amd64        GCC, the GNU Compiler Collection
(base package)
ii  gcc-8-powerpc64-linux-gnu                        8.4.0-1cross1
                      amd64        GNU C compiler (cross compiler for
ppc64 architecture)
ii  gcc-8-powerpc64-linux-gnu-base:amd64             8.4.0-1cross1
                      amd64        GCC, the GNU Compiler Collection
(base package)
ii  gcc-9-powerpc64-linux-gnu                        9.2.1-28cross1
                      amd64        GNU C compiler (cross compiler for
ppc64 architecture)
ii  gcc-9-powerpc64-linux-gnu-base:amd64             9.2.1-28cross1
                      amd64        GCC, the GNU Compiler Collection
(base package)
ii  gcc-powerpc64-linux-gnu                          4:9.2.1-3
                      amd64        GNU C compiler for the ppc64
architecture

likewise qemu,

we *don't need* to build gcc for powerpc from scratch... because we're
*specifically aiming for POWER9 interoperability*.

we _will_ need a simulator, we will need llvm-ir back-end patches, and
more besides, however docker containers are the worst, most
resource-wasteful and unstable way you could possibly choose.

i take a *snapshot* of the debootstrap chroot(s) that i create
(including the pre-downloaded packages which end up in
/var/cache/apt/archives), thus saving a huge amount of bandwidth, then
run scripts in those which install (and build) the packages and
binaries needed.

this is a stable method that is also upgradeable - *both under my
control not at someone else's whim*.

ok?

please, seriously, don't drink the docker kool-aid, ok?

best,

l.