Earlier quoted context omitted.
Thanks for the frank feedback. I agree that we have a lot of "wiggle room", as you so diplomatically put it. Out of curiosity how do you feel about the current README on Docker's repo? https://github.com/docker/docker/blob/master/README.md One problem we've encountered is that the audience for Docker is incredible broad - much broader than you might imagine when reading Hacker News for example. It is extremely common…
Big platforms tend to be different things to different people. Might help to have a different "what is docker?" page for the various roles you encounter. For CIOs: click here For developers: click here For sysadmins/devops: click here For platform providers (e.g. heroku): click here.
It's the Future
71–80 of 146 posts
Re: It's the Future
#72It really is striking how products like Docker, even while delivering incredible value, continuously fail to message themselves in an intelligible way. If you go to https://www.docker.com , you see: "Build, Ship and Run. Any App, Anywhere." Jesus Christ. I get that you're The Future, but make the value prop for me here, at least. Why should I use Docker? What parts of my stack does it replace? When does the cost-bene…
Thanks for the frank feedback. I agree that we have a lot of "wiggle room", as you so diplomatically put it. Out of curiosity how do you feel about the current README on Docker's repo? https://github.com/docker/docker/blob/master/README.md One problem we've encountered is that the audience for Docker is incredible broad - much broader than you might imagine when reading Hacker News for example. It is extremely common…
I wish the site landing page did this, too.
Re: It's the Future
#73Earlier quoted context omitted.
I find that position to be very hard to understand - devtools live or die by their adoption. A clear understanding of what a tool does is critical to its adoption. Look at, say, the homepage of Ruby: https://www.ruby-lang.org/en/ . There's a clear, two sentence explanation of what it is: A dynamic, open source programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural t…
That one-liner won't work (for me), it's missing a slash in the awk command. I have this aliased as `docker-rmi-junk` since it's so common. docker rmi -f $(docker images | grep "^ " | awk "{print \$3}") I agree with everything else you're saying completely. Although messaging a value prop is hard when you have so many use cases. We faced the same issue and ended up trying to segment users as quickly and high up in th…
docker images -f "dangling=true" -q | xargs -r docker rmiRe: It's the Future
#74Earlier quoted context omitted.
Thanks for the frank feedback. I agree that we have a lot of "wiggle room", as you so diplomatically put it. Out of curiosity how do you feel about the current README on Docker's repo? https://github.com/docker/docker/blob/master/README.md One problem we've encountered is that the audience for Docker is incredible broad - much broader than you might imagine when reading Hacker News for example. It is extremely common…
Big platforms tend to be different things to different people. Might help to have a different "what is docker?" page for the various roles you encounter. For CIOs: click here For developers: click here For sysadmins/devops: click here For platform providers (e.g. heroku): click here.
That much work means that a) they're trying to sell something because it isn't obviously better and b) they're more worried about messaging than being simple and useful.
Re: It's the Future
#75Earlier quoted context omitted.
The problem is not that they "message themselves" (gross) wrong, but that they feel like they have to "message" at all. Sales & marketing mumbo jumbo has no place in devtools -- it is at best, obfuscation -- at worst, misrepresentation.
I find that position to be very hard to understand - devtools live or die by their adoption. A clear understanding of what a tool does is critical to its adoption. Look at, say, the homepage of Ruby: https://www.ruby-lang.org/en/ . There's a clear, two sentence explanation of what it is: A dynamic, open source programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural t…
Some of the time, that is true, but not all the time, maybe not most of the time -- you are putting the cart before the horse. In fact, I would argue that this is an anti-pattern. Yes, you might use (e.g. to pick 2 unrelated domains) Hadoop or Python because they are popular, but consider how they got popular in the first place.
Devtools exist to solve a problem. You should not evaluate devtools based on the webpage or how many people are using it. That way lies Oracle enterprise. :-)
The problem with Docker's website is not that it exists. It is that it substitutes sales & marketing for just simply explaining what it is to a developer. While one could classify this under the category of "marketing", it would be a mistake -- kind of like classifying man pages as sales pitches. Just tell me what the fuck it does for god sakes and I'll decide! I could give a rats ass whether Facebook uses it, etc...
To be clear, I find Docker, the tool, useful, I just think it doesn't need "Marketing", it needs a useful webpage.[1]
Ruby was not adopted because of its webpage or its user base, it was adopted because one person bothered to look into it, liked it and decided to build a very popular web framework around it. Others saw the value in that domain and it exploded. Similar situation for Linux, which started from an FTP site and usenet posting. :-)
"The nerd-centric viewpoint that tool should succeed entirely on their own merits, with no affordances for the user, is crazy."
Unrelated to what I was talking about entirely. Affordances to the user is a merit of the tool itself. Docker could be considerably easier to use in some regards, and that would improve it's usefulness as a dev tool. However, this has nothing to do with attempting to gain marketshare with no direct relation to merit.
[1] But then Docker, the organization, is selling something, aren't they?
Re: It's the Future
#76Well these technologies are there to help bring Google type infrastructure for businesses that need it. If you're running a CRUD app just fine on Heroku you don't need to do any of this and you shouldn't. When your availability starts having problems or your data is getting too much for one machine, you start having problems of scale. Where you are in terms of scaling issues should lead you to the next iteration of t…
I'll just say it--pretty much only Amazon, Google, Facebook, Apple, Baidu, and perhaps a small handful of other companies need Google infrastructure.
Everybody else is probably just chasing shiny on their investors' dime.
Re: It's the Future
#77This hits home. While everyone is talking containers, we're running simple processes with a Linux user per instance, and I feel no need to add more complexity to our system, except I'm really struggling to automate stuff. It seems that if you aren't running a full dockerized cluster of services or outsourcing everything to a PaaS, you're left with building all the infrastructure yourself. What did people use before t…
On the one hand it is about getting more bang for your hardware buck.
On the other it is about someone getting so deep into netsec that they have developed gills.
In the bang for bucks category you have a chain of one box pr database etc.
Then noticing that the hardware sits idle most of the time, so virtualization is depolyed to pack more server on a single box to keep it in use.
Then noticing that virtualization comes with a performance overhead, so it gets replaced chroot/containerization to give the impression of unshared box.
In the netsec category it is really about namespace. Limiting the view of the world the processes gets.
This has a superficial similarity to chroot, but can go much much deeper.
And if one go deep enough, every server ends up looking like a digital fort Knox...
Re: It's the Future
#78It really is striking how products like Docker, even while delivering incredible value, continuously fail to message themselves in an intelligible way. If you go to https://www.docker.com , you see: "Build, Ship and Run. Any App, Anywhere." Jesus Christ. I get that you're The Future, but make the value prop for me here, at least. Why should I use Docker? What parts of my stack does it replace? When does the cost-bene…
Thanks for the frank feedback. I agree that we have a lot of "wiggle room", as you so diplomatically put it. Out of curiosity how do you feel about the current README on Docker's repo? https://github.com/docker/docker/blob/master/README.md One problem we've encountered is that the audience for Docker is incredible broad - much broader than you might imagine when reading Hacker News for example. It is extremely common…
To me, docker can be thought of as a process wrapper. The executable is called an image, and the running process called a container. The benefit of docker is three-fold: 1) each process thinks it has an OS to itself, which is a killer feature for native binaries that have weird dependencies 2) network (port) indirection, and 3) filesystem indirection (mounting an arbitrary host dir into an arbitrary container dir).
Against all of this is the whole question of how to really use it to develop and deploy custom software! You could, for example, develop and deploy Java without ever installing Java on the host (not even the development host). But when you are finally ready to deploy, how is that supposed to work? Which pieces are static, which dynamic? Do you bake your binary into the image, or do you mount the binary from the (remote) host filesystem?
The docker docs don't answer any of these questions, and I really think it should.
Re: It's the Future
#79Earlier quoted context omitted.
Big platforms tend to be different things to different people. Might help to have a different "what is docker?" page for the various roles you encounter. For CIOs: click here For developers: click here For sysadmins/devops: click here For platform providers (e.g. heroku): click here.
Whenever I see a product segmented that way, I'm immediately suspicious. That much work means that a) they're trying to sell something because it isn't obviously better and b) they're more worried about messaging than being simple and useful.
But useful means different things to different people. To a dev, Docker might mean you keep your environment clean, scripting of automated testing, and have platform agnostic deployments. To the CIO, Docker means your devs spend less time futzing around with their stuff and more time working on the product. Or that he can upgrade his infrastructure gradually and not have to worry about compatibility. Yes, it's the same thing, but different audiences need different messaging.
Re: It's the Future
#80Earlier quoted context omitted.
That one-liner won't work (for me), it's missing a slash in the awk command. I have this aliased as `docker-rmi-junk` since it's so common. docker rmi -f $(docker images | grep "^ " | awk "{print \$3}") I agree with everything else you're saying completely. Although messaging a value prop is hard when you have so many use cases. We faced the same issue and ended up trying to segment users as quickly and high up in th…
Or the marginally shorter: docker images -f "dangling=true" -q | xargs -r docker rmi
docker ps -q | xargs docker stats