1. 15
    majkinetor avatar majkinetor edited 42 hours ago | link | on: Should We Delete Old Repositories? (2013)

    I totally disagree:

    • There are several projects I know that were grabbed again by someone after being left to rot for decade or so
    • If person online cant deduce quickly the relevance of the project by looking into different stats usually available on spot (last commit date, commit distribution/freq, languages/frameworks used…) and other relevant things, then how can that person produce any significant work in the society where astronomically high noise vs signal ratio is the norm
    • I don’t have to publish things because of others, I can and do publish them for myself. I personally benefit from easy availability of my work in the future when I want to recheck things I have done (or have a need for them again).
    • You never know how somebody can be inspired nor you can guess. This even works on self - sometimes when I see works I did 10 or more years ago, first thought is wtf, did I really do this awesome thing then immediately how did I do this, I can’t do this now…. So previous me, inspires today’s me. When I think about it, its natural and makes sense, its even completely different person.
    • Finally, I just like to keep enumerated and cataloged all the things I did along with accompanied artifacts. I collect works of others in form of music, books etc, my own work is way more important. I like to return to specific year and age and look into that stuff. Also, I like to look into all the time range and follow my own progression in what ever level of detail I feel at that moment, which is why I need entire stuff.

    So no, never delete anything you spent substantial amount of time doing. Delete experiments and weekend tryouts only.

    1.  
      chrisparnin avatar chrisparnin 35 hours ago | link

      We ended needing an old plan9 filesystem server for virtualization—same thing Docker for Mac uses. Glad some one archived and ported this!

      https://bitbucket.org/plan9-from-bell-labs/u9fs/src/default/

    1. 1
      craftyguy avatar craftyguy 3 days ago | link | on: Build and run tiny vms from Dockerfiles -- now supporting kvm and hyperkit

      Why are you reposting this?

      1. 2
        chrisparnin avatar chrisparnin 3 days ago | link

        Updating news on kvm and hyperkit support, as several requested.

      1. 1
        ac avatar ac 2 months ago | link | on: Build and run tiny VMs from Dockerfiles

        Looks like it will go nicely with orderly (which I released a few days ago) :D . This is very similar to what I am doing on one of my own projects, though I use nix packages instead of docker, the end result is the same.

        1. 1
          chrisparnin avatar chrisparnin 2 months ago | link

          Cool! Do you have a github link?

          1. 1
            ac avatar ac 2 months ago | link

            Here is orderly: https://github.com/andrewchambers/orderly which I think would go nice as a mini init system for a group of services on slim.

            My nix vm stuff is called ‘boot2nix’ but I didn’t open source it yet - it builds a vm image that is around 50 megs or so and boots very fast, like slim :). Actually slim will also work well with nix, because nix can build docker images too. The more cool lightweight tools the better, thanks for making it :).

        1. 4
          favadi avatar favadi 2 months ago | link | on: Build and run tiny VMs from Dockerfiles

          Looks interesting, but what is the use-case for this?

          1. 1
            chrisparnin avatar chrisparnin edited 2 months ago | link

            In short, one use case is for building immutable infrastructure—borrowing answer from LinuxKit:

            LinuxKit runs as an initramfs and its system containers are baked in at build-time, essentially making LinuxKit immutable. Moreover, LinuxKit has a read-only root filesystem: system configuration and sensitive files cannot be modified after boot. The only files on LinuxKit that are allowed to be modified pertain to namespaced container data and stateful partitions.

            Unlike LinuxKit, you’re not limited to just read-only filesystems. This is just a simple utility for creating bootable images given a filesystem.

            Another use case is that unlike containers, you can access hardware more readily (usb, etc.), and thus provide development/computing environments for hardware dev/etc. Other things like ip addresses and multiple NICs are easier to add and work with.

            Stripping a distribution down to its most basic core is a really fun way to learn about linux systems! Interesting education opportunities.

            The final use case is that while Docker offers a nice ecosystem for building and sharing curated file systems, it is not always super desirable to also adopt the isolation/union-fs/container/chroot paradigm for development; instead, sometimes people just don’t want to pip/apt-get install everything to run a piece of code. In short, you could use this to build persistent containers, like lxc.

          1. 3
            mwcampbell avatar mwcampbell 2 months ago | link | on: Build and run tiny VMs from Dockerfiles

            Nice. Do you plan to add support for cloud provider VM images?

            1. 4
              chrisparnin avatar chrisparnin 2 months ago | link

              We certainly plan on experimenting with different host images + filesystem combinations, so this will be on our radar.

              In the short-term, seems that exporting the instance from VirtualBox (vmdk) and upload to a provider, like digitalocean would work: https://www.digitalocean.com/docs/images/custom-images/overview/#image-requirements