Huh? You must be kidding me, there are people who have trouble with tar, enough to warrant an XKCD?
`tar xvf filename.tar` is so trivial I don't even think about it - it's just some muscle memory at this point. There's `x` for eXtract, `v` for Verbose` and `f` for the Filename to follow. I only check manpages if I need to exclude some directories or do filename transformations - because my brain is too limited to remember all those details.
also, substitute (x)tract for (c)ollect
Never forgot a tar command ever again.
But come on, how many levels of abstraction do we want to pile onto another? Namespaces, containers, Docker files, compose, swarm, k8s, helm, cloudfront, terraform, auth servers/OAuth, ad-hoc "REST" auth kludges, dynamic languages, distro- and lang package managers/ecosystems, blabla - because IT'S SO MUCH EASIER LOL. All of which are one-of-a kind snowflake solutions to self-inflicted problems on top of an O/S that is already highly portable, for good reasons. We're just kicking the can down the road, or alternatively, blow up cyclical/generational bubbles to trap freshmen and idiots. Cloud tooling seems like a zero-sum game at this point, wasting talent for three "cloud providers" to make loads of cash. The whole thing is antithetical to humanist, local-first, site autonomy principles in the name of growth for very few.
https://github.com/p8952/bocker? Last commit was 7 years ago, and even then this was more of an experiment / PoC - I really don't think this was ever meant as a viable replacement. (IMHO Bash is a horrible language as well.)
I agree with your sentiment on container/cloud tooling. It doesn't need to be this complicated, the needs of the 1% are dictating the experience for the 99%. However Docker (the basic CLI interface) and Dockerfile (the format) did a lot to bring containers to the mainstream, and you can still get quite a lot out of it by just sticking to the basics. For self-hosting simple services, or even just deploying your application, on plain old VPS/box-under-the-desk, it's still just plain brilliant; at least compared to loading files into a shotgun and aiming in the general direction of /opt, /usr/local, /home/app, /etc.
From reading, there seems to be planned support for VMs, which is where the mental click is for evading dockerfiles to me, but when creating VMs you have the same thing. The equivalent (in my mind) of this for VMs exists as Multipass, where you pass a cloud-init file for configuration.
I think it's cool for playing, but if I could create a Dockerfile in the directory of the project, as simple as "FROM ubuntu:latest" and when I run Dock it takes this Dockerfile and then builds a new image ontop of it (with all these customizations, dropping me into a shell) that is where this would shine to me. It may just be a workflow thing, but if I am building a container, I am already building Dockerfiles. They're not just for Docker, many many tools use them for containers more generically.
The painful part when building a container is when I am doing something decently involved (e.g. implementing a proprietary software daemon & driver for a German camera manufacturer that has to have custom udev rules and many, many customizations,) and just want to extend my natural terminal environment into that space to explore what's up. Then when I am done, I should be able to run docker build and get the clean, bare container. It's very rare that I just need an arbitrary container that will go away when working on a project. Periodically I may generate an ubuntu pod or something, but it goes away fast and generally lives for less than 10 commands.
With that being said, I don't mean to poo-poo, as I do really like the aesthetic, the documentation is beautiful, and the thought put into it. I just don't see where it fits into my (or many people I know)'s workflow pretty much strictly because of the Dockerfile thing. Some of the other tools look cool though, so I threw a buck or two in the hat :)
As for supporting VMs - you misunderstood. I meant support for other container engines. To me, it would most notably be BSD jails. In fact, if I get to it, I'd like to do something much more cool... Perhaps it would make sense to have a VM with FreeBSD running on a machine and then multiple BSD jails running inside - all managed by a relatively small tool-set, such as `dock` - I'd probably have to rename or fork it. But the cool part of it all is that containers won't even depend on an architecture, since they'd be running inside a VM.
With this tool, how do you even know what has been installed in the container? How do you share them, or make changes, or update them? Is this just for personal use where you don't care about sharing your work?
I was recently considering creating this specifically for FreeBSD on ARM, or at least getting FreeBSD working on QEMU+arm64 and running some jails in there.
I’ve been working with lima and colima on macOS for a Linux VM docker type wrapper and wanted a FreeBSD equivalent.
Thanks for this tool (dock), it looks great.
So a similar idea would be to overlay mount your system for that container so you can edit, and then on exit the changes vanish. Might try this actually :)
Seriously :)
I'm a nix user who'd like to see others be able to get as much value out of it as I do.
> You may not be able to run this default image under MacOSX, although dock scripts themselves are fully compatible.
Probably developers using Windows are also unable to run this script as well. So I guess they are no better off with a 1 click install with Docker Desktop.
It seems the video I saw had more than 2 steps. If it is really a 2 steps installation then it is 50 steps back when it all breaks.
The only thing I am working on right now: a way to avoid building special images for MacBooks or ARMs, but rather have a patch-tool (a bash script, essentially), which would pull any image you want from Docker Hub and then run patches on it (patches are also simple, readable Bash scripts which would work kind of like migrations for DBs), so that you will quickly have a Dock-compatible image and if you wanted a Python or a Ruby env you'd use an extra set of included patches or write your own.
It sounds more complex than it would actually work, honestly.
I've tried to run `dock` under WSL2 and install works fine, container creation works fine, but connecting through SSH fails - due the fact that Docker is really running in different VM and is not directly accessible (ssh just times out). Looks like, adding some small modifications of way of exposing ssh/connecting there should allow it as well.
On side note - bash scripting is very nicely done! But running through `shellcheck` gives some hints on safer handling, i.e.
echo "StrictHostKeyChecking no" >> ~/.ssh/dock_config_$ssh_suffix
^---------^ SC2086: Double quote to prevent globbing and word splitting.Also, thank you for trying it out and reporting it works even on Windows, pleasantly surprised.
But you are not correct in assuming this is aiming for Linux - my next goal is adding BSD jails. I see absolutely no reason why different container engines would bother user with architecture, different APIs and apps etc. And, then, I think there's actually something, that although it sounds crazy, might work wonderfully on any OS, see my comment here: https://news.ycombinator.com/item?id=31625920
That seems pretty much entirely unrelated? It just is a software project that happens to be distributed by the same umbrella project.
I have my containers built by Gitlab[1], and I jump into them with Distrobox. It honestly couldn't be simpler.
On a serious note, I think it has been made clear this isn't intended just for Docker, but any other container engine too, potentially. And from my experience using it every day, it saves a ton of time. As opposed to regular Docker usage patterns. I just navigate to my project directory and type `dock`. There is no need for any external service, such as Gitlab or even Docker Hub.
Ubuntu: Snaps.
edit: Sorry, I'm posting this from a bar and I think it sounds really arrogant :( these guys probably worked damn hard on dock so I'm cashing out and going home to try it.
The page didn't achieve conveying this clearly to me. I might be a bit obtuse today but as I went on and on reading, the question remained about why exactly this tool is not just starting from well known (and trusted) Docker images. The "trusted" part is important: I kind of trust that official Ubuntu images are not tampered with anything fishy.
Could you expand on this?
Best ideas aren't always the first ones in the queue. Remember, I built it for myself first and never thought I'd do a release, so there was no point to it initially.
This gave me a feeling that each day is less and less easy to get: that this software was not just written, but carefully crafted.
> This website was written in pure html and css by hand, contains no Javascript, doesn't use cookies, doesn't track you and still works pretty damn well.
Definitely subscribing the mentioned feeling. This is clearly an effort of the author to get away from superfluous layers, an ideal that sadly is getting lost in a world of prebuilt bloat. Props for that!
Little typo:
> with a serious of Bash scripts
Probably wanted to say "series" here right?
Thank you, typo fixed. I think there are more. I usually do try and proof-read, but there's never enough time.
[ 17:52:08 ] git clone -b stable \
> https://gitea.orion3.space/DOCK/dock.git && cd dock && \
> git submodule init && git submodule update
Cloning into 'dock'...
fatal: Remote branch stable not found in upstream origin
[ 17:52:17 ] curl https://dock.orion3.space/releases/dock_stable.tgz \
dock_s> -o dock_stable.tgz && \ tar xvzf dock_stable.tgz &&
> rm dock_stable.tgz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 235k 100 235k 0 0 87414 0 0:00:02 0:00:02 --:--:-- 87382
Command ' tar' not found, did you mean:Despite it's original idea of managing multiple versions of say Python, I find it useful when installing `starship` tool for command prompt and easily updating it later.
I worked on a project recently that did their own roll-your-own equivalent. It was in python and many of the devs didn't have a python env installed. The leaders provided everyone with an image with the env, Pycharm, and assorted configs all pre-installed. You just needed to redirect DISPLAY 0. There were a few teething moments but once it was running, it worked well.
I can see something that might help standardize setting that up being very useful.
[0] https://code.visualstudio.com/docs/remote/create-dev-contain...