Closed kotp closed 7 years ago
Thanks! I'd never have realized as that's a bit of text I read very rarely. This is what makes open source work!
I have a feeling I will be spending more time in this project. :)
That's a more interesting question... The thing is, that in master, I recently added support for not being a member of the docker group https://github.com/subuser-security/subuser/issues/131 and this support meant changing the documentation for installing subuser. The new code, however, hasn't been released as a new version of subuser. So now, if I want to make changes to the website, I'd have to create a new branch and backport changes to it, then remerge later on. Technically I should do this, but I haven't. I'm not %100 convinced it is worth the effort but it might be...
I guess I can just create a new branch based on the latest release and cherry pick though. I'll go do that now.
On 01/16/2017 12:25 AM, Victor Goff wrote:
When does the site http://subuser.org/packaging.html get updated?
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/subuser-security/subuser/pull/305#issuecomment-272746611, or mute the thread https://github.com/notifications/unsubscribe-auth/ABU7-LW4rpr7fTc4cJqB2qIF_Xs3LJxsks5rSqsEgaJpZM4Lj7GJ.
I'm not sure what is wrong with me, but these things always take me forever. http://subuser.org/packaging.html
Step1: run into error because git-annex isn't installed on new computer. Step2: Bang head over fact that git-annex being configured for the repo prevents me from doing things that have nothing to do with git-annex. Step3: Update computer and install git-annex. Step5: Bang head over fact that updating docker on debian causes all running docker containers to stop, thus cuasing all of my subuser applications to close. Step6: Realize that the website building subuser image is broken. Step7: Update that image. Step8: Realize, that the image was actually fixed in a commit that came AFTER the commit that I had checked out before cherry picking. Step9: Cherry-pick fixed dev image for building website and update image Step10: Successfully build and deploy site. Step11: Realize I had rolled back farther than I wanted. Step12: cherrypick ontop of later commit. Step13: build website and deploy Step14: Sit around nervously hoping I didn't break anything.
All in all it takes an hour.
I keep on reading on HN about programmers making $100K a year, and I wonder, are these investors paying for this kind of fiddling? Kind of hillarious if that's true. Pretty sad if I'm the only one.
All for want of a change of about 16 characters. But those 16 characters make a world of meaningful difference.
And it is multiplicative. So take some joy in knowing that.
Now, to figure out if a container (or set of containers) that is set up to hold all the requirements to deploy the changes could mitigate the fluctuations in your local configuration on your system?
Well, git runs fine under subuser, so hypothetically steps1-5 could be eliminated, but for me, in practice, this doesn't work that well yet. The problem is, that despite the advertized "zero overhead" of containers, Docker containers take measurable time to start up. For example, running the command subuser run gt status:
time subuser run gt status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean 0.19user 0.04system 0:07.06elapsed 3%CPU (0avgtext+0avgdata 19556maxresident)k 0inputs+0outputs (0major+11967minor)pagefaults 0swaps
Takes like 7 seconds on my non-ssd desktop. Its not so bad on an SSD, my top of the line SSD laptop preforms the command in 2 seconds.
It is possible to kinda-sorta fix this problem by running a development terminal:
subuser run --entrypoint=/bin/bash gt timothy@3e2fe69344ca56b8705e:/pwd$ time git status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean
real 0m0.118s user 0m0.000s sys 0m0.008s
But I find that to be uncomfortable, to have to keep a separate terminal open for git or something like that. So rather than running EVERYTHING in its own subuser/Docker container, as I would like, I end up running some frequently used CLI utils normally, and git is one of those utils.
Steps6-8 are using containers, and I wouldn't have had the problem, but since I maintain the build files for those containers in the subuser git repo: https://github.com/subuser-security/subuser/tree/master/docs/docs-dev That meant that when I ran "git checkout -b update-website 0.5.13" I was working with outdated container build files and when then ran into the broken container (which is fixed in master), I ended up having to fix the same problem I had already fixed sometime between the 0.5.13 tag and master. Containers won't save you from your own stupidity.
If you want to build the website yourself, you can, using the same
container as I use:
http://subuser.org/developers/common-tasks.html#building-the-docs Which
leads me to realize, that I don't clearly state the directory in which
the user is supposed to run subuser dev docs
...
On 01/16/2017 12:34, Victor Goff wrote:
All for want of a change of about 16 characters. But those 16 characters make a world of meaningful difference.
And it is multiplicative. So take some joy in knowing that.
Now, to figure out if a container (or set of containers) that is set up to hold all the requirements to deploy the changes could mitigate the fluctuations in your local configuration on your system?
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/subuser-security/subuser/pull/305#issuecomment-272838325, or mute the thread https://github.com/notifications/unsubscribe-auth/ABU7-IzJT4snLoOwl7v_QDRQthAM6_HIks5rS1W4gaJpZM4Lj7GJ.
Ah, but don't try that dev docs command on master for the next 30min, apparently I broke it with the sudo commit :(
On 01/16/2017 12:34, Victor Goff wrote:
All for want of a change of about 16 characters. But those 16 characters make a world of meaningful difference.
And it is multiplicative. So take some joy in knowing that.
Now, to figure out if a container (or set of containers) that is set up to hold all the requirements to deploy the changes could mitigate the fluctuations in your local configuration on your system?
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/subuser-security/subuser/pull/305#issuecomment-272838325, or mute the thread https://github.com/notifications/unsubscribe-auth/ABU7-IzJT4snLoOwl7v_QDRQthAM6_HIks5rS1W4gaJpZM4Lj7GJ.
Fixeruno'd
On 01/16/2017 12:34, Victor Goff wrote:
All for want of a change of about 16 characters. But those 16 characters make a world of meaningful difference.
And it is multiplicative. So take some joy in knowing that.
Now, to figure out if a container (or set of containers) that is set up to hold all the requirements to deploy the changes could mitigate the fluctuations in your local configuration on your system?
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/subuser-security/subuser/pull/305#issuecomment-272838325, or mute the thread https://github.com/notifications/unsubscribe-auth/ABU7-IzJT4snLoOwl7v_QDRQthAM6_HIks5rS1W4gaJpZM4Lj7GJ.
:) The cobblers shoes...
Gitlab is another popular choice, gitorious is phased out.