131–140 of 203 posts
Earlier quoted context omitted.
On every distro in the past, i’d do sudo passwd. Always worked. No idea about Alpine.
But sudo access requires you to have logged in through a user in the wheel group. That at least is not a vulnerability.
Earlier quoted context omitted.
I don't want to disparage any project or guess the motivation but there have been some undercurrents of anti-GPL sentiment at times and anti-complexity. Folks have sort of backed it up by posting some links to things that aren't as you might think. GLIBC in particular looks nothing like how you might imagine it. You can look at strlen in the K&R book and it's beautiful, like a textbook: int strlen(char s[]) { int i;…
This reminds me of a classic blog post: http://ridiculousfish.com/blog/posts/old-age-and-treachery.html All of those old Unix programs aren't fast by being simple and clean on the inside. Old age and treachery...
Earlier quoted context omitted.
> I’d think that a few megabytes of disk isn’t as valuable as the extra cpu cycles. Depends on your workload, of course. Some people want to run a huge number of containers and each isn’t compute intensive. Or maybe you don’t use libc at all in your fast path? Lots of cases it makes sense.
If you reuse the base image, the libc files will be shared anyway.
They see Alpine at 5Mb and Ubuntu at 80Mb. They mentally multiply, without realising that each of these will be pulled once for each image built on top of them.
For a large cluster it's a wash. You might as well use Ubuntu, Centos -- anything where there are people working fulltime to fix CVEs quickly.
Earlier quoted context omitted.
> Ubuntu which is only around 40mb […] I just downloaded Ubuntu 18.04 and 19.04 and they are not 40MB: $ docker image ls | grep ubuntu ubuntu 19.04 f723e3b6f1bd 76.4MB ubuntu 18.04 d131e0fa2585 102.0MB ubuntu 16.04 a51debf7e1eb 116.0MB How do you get a 40MB Ubuntu Docker image? --- I followed @sofaofthedamned — https://blog.ubuntu.com/2018/07/09/minimal-ubuntu-released But I’m still confused, where are they getting 2…
https://blog.ubuntu.com/2018/07/09/minimal-ubuntu-released Apologies, it's actually 29mb.
Earlier quoted context omitted.
You're only playing that 40mb once though. Multiple containers sharing the same parent layers will not require additional storage for the core OS layer.
Are you guys running everything on a single box? Do you get all developers to agree on which base image to build all their services from? I heard about this "oh, it's shared, don't worry" thing before. It started with 40MB. Now that supposedly shared image is half a gig. "Don't worry, it's shared anyway". Expect when it isn't. And when it is, it still slow us down in bringing up new nodes. And guess what, turns out t…
Images built from dockerfiles can do this too, but it requires some degree of centralisation and control. Recently folks have done this with One Multibuild To Rule Them All.
By the time you're going to the trouble of reinventing buildpacks ... why not just use buildpacks? Let someone else worry about watching all the upstream dependencies, let someone else find and fix all the weird things that build systems can barf up, let someone else do all the heavy testing so you don't have to.
Disclosure: I worked on Cloud Native Buildpacks for a little while.
Earlier quoted context omitted.
But sudo access requires you to have logged in through a user in the wheel group. That at least is not a vulnerability.
OK. In my experience it worked with any user account. I would install, create an account, and immediately use sudo to change the root password.
If you can do what you said with a non-wheel/sudo account, that would be a serious vulnerability.
Earlier quoted context omitted.
If you reuse the base image, the libc files will be shared anyway.
This is the part most people don't realise. They see Alpine at 5Mb and Ubuntu at 80Mb. They mentally multiply, without realising that each of these will be pulled once for each image built on top of them. For a large cluster it's a wash. You might as well use Ubuntu, Centos -- anything where there are people working fulltime to fix CVEs quickly.
Earlier quoted context omitted.
For statically linked binaries, why wouldn't you use the SCRATCH (0 kb) 'image'?
You might want at least a shell in the container for debugging?
Earlier quoted context omitted.
It's not a few megabytes, it's a few hundred to a thousand megabytes saved, on average. Multiplied by a thousand containers, and much larger layers on build servers, plus bandwidth, it makes a difference. Worst case for slower processes, things take longer. Worst case for more disk use, things start crashing. For general cases, the former is preferable.
No, it's not. With samepage merging it's nothing, let alone docker only loading the image once.