HN user

15DCFA8F

681 karma
Posts16
Comments24
View on HN

How often do you use this script?

I run once in a couple of days. Didn't automate the execution of this "meta-script" because I don't want it to run whenever I am using the resources its updating.

is there any other part that you failed or found very boring

Yes, the VM updating part. Starting each VM, waiting for them to start, updating packages via apt-get, stopping, waiting for them to stop. This was boring and done on trial and error until it just works now.

I loved sandspiel

I am not the author, just saw on lobste.rs and reposted here because I loved it too! All credits go to this guy: https://github.com/MaxBittker

I have a script called update-my-things.sh, which updates my Python’s pipsi scripts, my Python’s pew virtualenvs, my Rust toolchains, my VMs, my local software Git mirrors, etc.

All stitched together in (bad) Bash.

Debian (yes, stable) for laptops, desktops, VMs, bare metal servers, containers. Everything.

- It's a solid and trustworthy distro.

- It's general and universal, and adaptable for most uses.

- I have tons of Ansible tasks and roles developed for Debian, so pretty much anything is automated and standardizing helps a lot.

Linux 4.7 Released 10 years ago

I don't know who maintain those changelogs, but WOW, thanks for this great detailed and methodical piece of work.

Could people who use Docker in production comment on the stability state of the storage drivers?

One thing that frustrates me about Docker is that no matter which storage driver I use, problems always seems to arise.

With AUFS on Debian, I constantly had problems with starting and stopping containers (problems with mounting and umounting AUFS layers). This was on Debian Wheezy and Docker 1.[1-3] era. I don't know it is improved now.

I tried BTRFS on Debian Jessie and Arch Linux, and found it to be much slower than AUFS on every aspect (creating images, starting containers, etc). The fact that BTRFS don't share inodes caches between subvolumes may be the culprit of slower times to start applications inside containers, when there is lots of containers running from the same base image.

Next, I stumbled on Direct LVM on Debian Jessie. Initially I liked that, on "personal benchmarks", the container creation time was very constant when the number of images increased (contrary to BTRFS, that increase the time to create subvolumes when the number of images increase). But.. In a few days using this storage driver, errors start to appear about problems to creating containers, corrupted LVM thin metadata, etc.

My last try was overlay on Debian Jessie with 4.5.1 kernel on backports. Apparently there is a bug on this specific kernel version that block containers for being started...

So. In my experience, BTRFS was the most stable storage driver, besides being much more slower than AUFS and Direct LVM (on XFS).

I was used to run Arch Linux, living on the bleeding edge and on the constant moving and packages churning that a rolling release distro provides.

For some months now, I am using Debian Stable on my desktops, and the experience is being very interesting. I don't use any apt pining, and just some packages from jessie-backports (eg: LibreOffice and Intel Video Driver), besides the official stable repos.

This distro is SOLID. My desktop runs very fine, and using a stable distribution means that it will keep running fine for months (years?), instead of that constant discomfort that a rolling release creates as your machine stability and usage potentially changes each day.

Of course, things start to stay a little old, but in the end of the day, it doesn't matter for the vast majority of packages. And you can always compile and install on /usr/local some applications that you need more recent versions.

Cunningham's Law 12 years ago

This is trolling, and not posting the wrong answer. But for what I saw, trolling in Linux forums with mention of Windows can sometimes extract the best knowledges from people...

Use of Assertions 12 years ago

Python assert checking is removed when the code is run with python -O ("optimize"), so it shouldn't be used to validate user input, checking for critical conditions, etc. It is just a defensive programming and debugging tool.

Dropbox Git Hosting 12 years ago

There is a lot of potential for repository corruption, using this way. You can use Dropbox for backing up Git (or Mercurial) repositories though, with bundles:

  cd $PROJ
  git bundle create ~/Dropbox/git/proj.git --all
This would create only one file, bundling all commits, in a corruption safe way.