|
I haven't jumped in yet, been dancing around the subject for some time though.
Everyone has a photographic memory; some just don't have film. Steven Wright
|
|
|
|
|
If you want to virtualize Windows Forms applications you can try the Cameyo packager, it's free for up to 50 users.
|
|
|
|
|
My only experience with Docker is swearing like one. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I'm supposed to be looking into this as an option for migrating a legacy lob desktop application. As soon as I get my server 2016 ready for production, I'll be able to check it out. I'm not about to pay for a hosted environment unless I absolutely have to. 
"Go forth into the source" - Neal Morse
|
|
|
|
|
I'v heard the term "Docker".
Never seen it. No idea what is it. Don't need it. Don't care.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Vunic wrote: Is there anybody out there who still doesnt have a need to look into this?
I did not have the need to know about it until I was asked in an interview if I was familiar with it. 
|
|
|
|
|
It is a technology we are looking at where I am employed.
Really haven't touched on it too much, I have real (not virtual) things to do; so to borrow from Rune Haako I will "send a droid", or in my case an intern.
We had one of them there walking discussions yesterday, and I was kinda like "so Docker is like the new Java, we just have containers instead of jars". But it was pointed out to me today that you can run Java inside of Docker, but not vice versa.
Director of Transmogrification Services
Shinobi of Query Language
Master of Yoda Conditional
|
|
|
|
|
I worked with it a fair bit in the past. Docker alone isn't really the only way to achieve any of the things it offers, and in my experience is downright counter productive if you end up in an organisation that tries to fit everything into Docker containers.
I'd recommend reading about The Twelve-Factor App if you're completely unfamiliar with Docker or Containers - it's basically just a set of 'best practices' for using Docker. They're ideas that actually make docker a nice enough development experience, but just downright stupid if you were to try use them all outside of Docker (e.g. all config should be environment variables) although a few of them are just good common sense rules.
All in All my conclusion was that well architected software, along with decent automation scripts for managing infrastructure and dependencies can be easier than trying to maintain dozens of different container images. Although no-one I know who advocates using Docker is actually conscious of the fact that security updates still need to be installed into their images - along with all the testing that comes with that.
|
|
|
|
|
We are in the process of introducing Docker, but for somewhat restricted use, and we will not use all facilities available.
The primary use is for compile/build jobs: Our various teams each have their requirements for compiler versions, library versions etc. For about five years, we have been running a system where each job calls a toolbox utility which switches symbolic links around, in some cases uninstalls the current tool version and installing the one required by a job, redefines environment symbols and PATH variables etc. The utility itself has gradually become quite stable, but we still have difficulties making people use it in a proper way (using Bamboo, you have to repeat the environment changes for every single job step!)
So now we will set up a new set of build agents with no build tools installed at the OS level. All tool suites shall be Dockerized. We had a tug-of-war between those who wanted each tool to be a separate Docker image, to be used like old-style individual executables activated one by one from a build script outside docker, and those who want to put a complete set of build tools into a quite large image, activating the various tools from a script interpreted by the shell within the running container.
The second group won: We will make complete toolboxes with a complete, coherent set of tools as one image. If any single tool comes in a new version, a new, complete image must be built - you cannot just update the Docker image of that tool and leave the rest. This will hopefully have a moderating, stabilizing effect on the uncontrolled proliferation of tool versions that have ridden us the last year or two.
Some projects demanded their own build machines because they were using tools that could not be version switched by the toolbox utility. We had a lot of unused processing power on those machines, while the general pool was overloaded. Now, with everything in Docker images, we will have one common pool of build machines, all of them capable of running any Docker image, and everything specific will be hidden within that image: When the job step has completed, the host is perfectly "clean", and the next invocation of the same image is virginal: Nothing from the previous run affects it. (We will not be using local volumes; all permanent storage are mounted as host volumes at container startup.)
Our second use is similar, but different: Our target testing, running physical target hardware, will need several McGyver style solutions for the interfacing. The problem with the (pre Docker) toolbox utility is that some of the device drivers refuse downgrading, and/or intstallation / activation of another version requieres manual intervention. So every time we replace the target hardware with another setup - very often an older setup, to verify that our new software works on the old hardware, or that the old software works on new hardware - reconfiguring the test environment may take hours of effort. We will now strive to put as much of the configuration into Docker images that are self contained and isolated and can be loaded in a few seconds.
We do not expect that it will be possible to Dockerize all testing software, so host will not be completely "clean" (like the compile/build machines): A test run may have some steps running in Docker, other steps running non-Dockerized software. The setups will be so tightly bound to the surrounding physical environment that the Docker images will certainly not be "portabele" (not even among our various test setups). We use Dockeer simply as a tool for easy reconfiguration of a single machine.
We are in the final planning stages of this change, so I cannot yet tell how well it will work. Most likely we will have surprises.
|
|
|
|
|
I've no need for it (and can't see where it would have been helpful on any of the past projects I've worked on). Started downloading it as per the Docker Challenge here on CP to have a preliminary play, but fortunately read the "warning" comment about it only running on Win10, so cancelled out of that...
|
|
|
|
|
Vunic wrote: Is there anybody out there who still doesnt have a need to look into this?
I have had no need as of yet. Thus far, I have treated it as the "religion du jour": newest concept that will solve ALL of the world's problems. Introduced by someone, evangelized by some, trade media goes crazy, management gets excited, eventually decreeing that we must go all in, at just about that time the press starts covering the various problems with implementing the concept.
Rinse, repeat.
|
|
|
|
|
Maybe if someone explained how Docker is of any benefit over and above packaging my Windows services so they are self-installing, or my GUI apps with an install program?
What am I missing? I have no reason yet to deploy on Linux. Windows, IMHO, is still a better choice over the long haul.
|
|
|
|
|
Us embedded and desktop/app developers don't have much use for it either. there's probably many good uses for Docker, just nothing that I want to get into.
|
|
|
|
|
Honestly,
I am waiting for Containers to support IDE Development correctly.
So we can build a container configured for a various project work, and fire it up when we need it again.
I would love to have my Development Containers in the cloud, fire them up, and work.
Shared with multiple developers, etc.
Kirk Out!
|
|
|
|
|
The nun wanted to drive up the road behind the RDS to get to the "Meeting of the families" exhibition.
The traffic cop said the road was closed to vehicle traffic.
Both were effectively saying the same thing :- Nun shall pass!
|
|
|
|
|
Did they use this roadsign[^]?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Am I the only one who was expecting another repost of the regular "show him your cross" nun joke? 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
To get that out of the way: @megaadam, this is your fault. You made me look at this code again and now everybody here must live with the consequences.
I need some inspiration for a very interesting object: A director that tells the actors (3D objects) and the crew (a graphics engine) what to do, yells 'Action!' and gives instructions while the scene plays.
The director must be able to set up the scene by
- setting up the set, both to specifications or with some room for variations
- choosing actors and their animations, again both exactly specified or with some degree of freedom
- choosing proper lighting
- choosing camera position(s) and animation(s)
Then the director must give instructions to the scene objects and the 3D engine to let the scene play as planned. The whole idea is to make every scene as variable as possible, so that the graphics always stay interesting.
These director objects already exist, but they are still hard coded and only scratch the surface of what is possible. Look at the animations in the background in my video *[^]. The asteroids or formations of other ships are changed by the director.
The scenes are loaded from XAML at the moment and the director objects control only some parts of the scenes. Hard coding should be reduced to a minimum and I need ways to tell the director what is required in a scene and where the director may get 'creative'. Any ideas?
* Yes, I have posted this before. Gimme clicks. 
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
 My apologies. Exactly how did I commit this atrocious crime? inadvertent telepathy?
... such stuff as dreams are made on
|
|
|
|
|
Sorry, it was not you who asked me to work on the game again! I must have gotten that mixed up somehow. My apologies, but I was joking anyway. That game is like a gothic cathedral and will need centuries to get finished. Getting me going again is not a bad thing at all.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
CodeWraith wrote: That game is like a gothic cathedral and will need centuries to get finished.
Create a public repository and ask people to contribute... A week from now you will have a few hundred 'Gothic cathedrals'...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
|
Getting finished would be nice, but it was not really the point up to now. I got my shot at a 3D engine, my own UI in the 3D engine and my own take on presentation layer architecture in a multi threaded environment, sever components and communication layers, all that so rock solid that no catch block in the whole thing contains anything more than a 'throw' line and it still does not crash. Getting a finished game out of it would just be the cream and the cherry on top.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
close topic
modified 22-Aug-18 4:38am.
|
|
|
|
|
Ummm, I think I posted this a few weeks ago, I did not re-post it knowingly. This means that Member13954096 has a (very) similar problem or I am in a time loop! Or maybe posts from the past are recycled... 
|
|
|
|
|
You probably should start trying to remember which sock puppet account you post stuff from... 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
