git checkout
will get any version, what else is needed? It even lets them go to versions they
skipped over
now the config file needs to be saved separately, or re-created, but that’s
separate from the software.
2 Likes
Which config file? The file groundcontrol.ini is in the user’s home directory.
I really feel you should look at Docker. It is much more inline with what you want to accomplish. In a VM your making image of an entire machine, Docker is a container system, your working with a base OS and the container is a file of what is different from the base OS. It’s smaller to deploy. You would just roll a new container file with a weekly update. You can then - Roll Back by getting the previous docker file. More of a learning curve fro you, much less for the user and less overhead in DL size.
Thank you
git allows you to be on the bleeding edge, but releases are just pointers into
the git history
non-developers can ignore 99%+ of the features of git. I think what they need to
know is:
git clone - get a complete archive of the project, make the most recent version
what you see
git fetch - update your archive, don’t change what you see
git pull - update your archive, make the most recent version what you see
git checkout - make be what you see
If you do a git pull at random times between releases, you will get code at that
random point
if you do a git pull just after a release, it’s unlikely that there will be
changes.
there aren’t many bad changes that make it into the code in the first place, so
the biggest problem you are likely to have pulling a random version is that you
happen to hit the small window between pulling an update into the Firmeware and
pulling the matching update into the Ground Control software
Also note, when you download a zip at the main github page, by default, that’s
the same as doing a git clone, it’s not pulling a release, it’s pulling the most
recent code.
2 Likes
Know I’m working on something similar from a different angle. I am trying to set up a PI3 as a headless workstation with a very specific set of hardware and software, for a known cost with known working feature set. After that is working I will look at redeploying it from Docker. What this means is I’m making a “Master System” from there I can clone it. I hope to move from a physical clone to having people but their hardware and then run a script to install Docker and pull the docker image to there Pi.
I have no time table on this as there are two many variables in my life at the moment. For me the Pi will be on the Maslow as a Troubleshooting tool. If something is not doing what I think it should I can fire up the Pi to see if it can be reproduced on 2 computers. I happen to have the hardware laying around, save a battery UPS I just added to it.
I hope to prove it out as a workable solution for others to use as a primary system allowing them to remote in and not have to deal with cables.
Thank you
1 Like
@Bee,
I had a look at docker, but I can’t figure out how to get started.
But docker doesn’t allow to make a distro style iso. Or does it?
Thanks @dlang,
I almost overlooked that post.
Your post was more helpful then the youtube git turorial 
Thank you thank you.
Here is the key phrase - " Docker is a Container System". I’m not totally a Docker expert but have worked with many that are. It will not be an ISO, it will be a Container.
Let me do some research and send you some links to look at.
Thank you
1 Like
Which config file? The file groundcontrol.ini is in the user’s home directory.
which needs to be backed up separately
one way to do that would be to make a git repository in the user’s home
directory and check in groundcontrol.ini, and tag checkins to match the maslow
versions
git init - create a repository
git add groundcontrol.ini - tell git to add the current version
git commit -m’checkin message’ - tell git to make this version a commit
git tag - set a tag to the current commit called
each time you change something, do the git add, git commit steps, do a git tag
when you update ground control and your firmware
this will give you a complete history of your ini file to match everything else
1 Like
Docker doesn’t solve the problem of software in the OS, you have to duplicate
the software into your docker container
no, with docker you aren’t making something that can boot, you are making
something that runs inside an already running Linux OS
Since most people don’t already have a Linux OS running, I don’t think it helps
much
Agreed - It requires one of us to maintain the “DC” but much easier on the user for deployment. This is based on a Ubuntu image already. Downloading a new OS image each week seems a bit much in DL overhead. As I understand the objective it’s to have an easy image to deploy for users. To keep up with new users you have to re-image with each release. Users can either do their own maintenance locally or get the new image. This is why I believe deploying through Docker fits the goal better. Over time all those .ISO images will eat up space. If we just wanted to make a easy Ubuntu install we could deploy GC and it’s dependencies thorough “SNAP”.
If there is a better way to achieve the goal setup by @vertex I’m totally open to it.
BTW _ I really appreciate the primmer on Git - I’ll move a copy into the wiki when I get a chance.
2 Likes
That’s why I’m trying to build a tiny distro.
Burn it on a USB stick
boot an old PC
and start cutting
Without having to mess with anything.
There will be users who just want to cut up wood. They will then be able to return knowledge of other kinds that we also need.
I try to get something in place that people can use who aren’t that deep into messing with dev software. Using git is for myself already a move out of my comfort zone. The difference is that i like to get a bit more insight in git. But i’m 100% sure that many people really don’t want to get into all of that, And just want to work with the machine. That will be ‘the average user’
In my opinion it’s far more practical to give them a USB stick that just works even on an old PC, then sending them off with windows installers that only work half of the time. On windows boxes with all kinds of viruses, driver issues, and outdated XP stuff.
Supporting all the windows bullshit will eventually become a headache.
But building a distro is also a big job, since you don’t want people to fall into a gap where you need to start an entire linux support. It just has to work. And it just has to be simple.
Boot from USB and 15 sec later you are ready to go…
but for that it requires a good distro
Then you can log all types of PC and laptop types that people use as ‘known good’.
Build a maslow, find a computer from the known good list.
plug it all in
boot
calibrate
start cutting
and still be aware that an ideal world does not exist yet…
1 Like
I fully support the endeavor. I’m working to make it easier to get up and running on every level then it was for me. The farther we go the better Maslow will be. There is a distribution for the PI -
It boots up and quietly runs docker, you then get online and run from within the image on a web interface. It takes about 3 minutes to boot. This is an example of what I’m describing.
It’s slick how they did this.
@vertex - I applaud your effort. There are many technologies to choose from.
@dlang - You are a wealth of knowledge and you are appreciated.
Thank you
1 Like
I’m playing around with lighter distro’s like ToriOS and ubuntu Mini.iso to see what can be done to reduce the image size.
And maybe include some update / upgrade functionality (git checkout) so that it’s not needed to re-spin the entire distro once a week,
But that requires an update functionality with a tool to switch between releases.
And this has to be a decent tool. not something that i tinkered together. 
The more basic it is the more easy it is to maintain and respin.
I really like to see others respin my stuff and take it a step further. This way there will be more people who can do this, and nobody will rely on just me.
Been there, done that, not going there ever again 
life is to short for that.
I’m now growing some roots, so that someone else can take it and add the next step, if that step leaves room for me to pick it up and add more of my own then i’m happy. This way it can evolve and people can try side steps. =–> Bazaar style horizontal evolution. <–=
1 Like
It depends on if you are trying to provide the user with a way to get started
easily, or are trying to provide them the one and only way to do things.
I think providing a VM/iso image/SD card image that includes scripts for
updating things is better than providing a docker container that is unmodifiable
and is only replaced.
We are far more likely to get new scripts and enhancements from people who have
a VM/iso image than people using docker.
Docker is for when you are wanting to deploy this, and only this, with no
modifications possible, only deploying a new version
we should be sending something out that allows people to change everything.
git use should be hidden in scripts that ‘just update’ (every week by default
with a cron job if the system is left running, or manually for people who don’t
leave the system running)
bit it should be there so that when someone runs into trouble, we can easily as
them to run this command and try again (to test the latest patches and see if
things are fixed)
1 Like
I see it in differently. Are we trying to introduce users to the Maslow or Linux? I don’t see it as we have to do one or the other. Let’s do both and let the user decide if they want a Iphone X or a Galaxy8. I think it will grow to be it’s own thing as @vertex has said. I believe it will be possible to run a docker container across platforms and allow multiple versions of CG to be used in one system. I find that very powerful in troubleshooting and testing. Especially for a user that is not involved in development. The people that just want to use it. I do appreciate your side of this and we defiantly have a group that could use and grow a VM here.
Thank you
@dlang I just try to provide an option to choose from. If it proves to be userfriendly then people will use it.
If i can’t find a way to make it user friendly then nobody will use it and it will fail, and i will have wasted my time.
Thats why try a bunch of random things before i make my own choice. The Ubuntu VM is already usable but far from userfriendly.
People who want to try it can send me a private message to request a link, i don’t want to spread it to wide just yet
Maslow definately.
My ‘distro’ experiment is 100% focussed on GroundControl only.
I try to make it as non-linux as possible. But still leave the door open to people who are interested.
Tinkerers will install their own stuff on whatever they want
But i’m sure that not all users are going to be engineers.
I mean, not everyone who bought a miter saw is a mitersaw engineer.
When you buy a mitersaw you are an enduser who only needs to know how to put in a new blade.
With Maslow it is a few steps further and people are encouraged to tinker. But the average woodworker who sees the Maslow as the next new thing in the toolshed will also be a potential customer. We cannot see who is behind the order. Some people already sold the kit for this reason. It’s just a bit too much for them. And that’s not their fault. So making things a bit more easy for those people is an advantage for us all.
I really like to see those people’s ideas come to life one day. It will not be easy for them but their woodworking skills will be a great resource for us as well.
EDIT:
For those who step away for technical reasons it’s a shame they can’t build their idea’s. They did a huge effort to join in.
Thanks for that, they are still part of this community non the less. (If i may say so)
And i hope we can make it possible for them to come back one day once the project has evolved
1 Like