3 ms·

Smartos is neat. I run smartos at home. Let me tell you, you are not doing smartos any favors. People don't give a shit about how great you think smartos is.

Smartos is neat. I run smartos at home. Let me tell you, you are not doing smartos any favors. People don't give a shit about how great you think smartos is. "smartos can do this", "smartos can do that". blah blah blah. Do you know what the difference is between the posted link and your comments? The stuff in the article actually works, while your "look how simple it is" comment, does not: [root@srv2 ~]# uname -a SunOS srv2 5.11 joyent_20160504T205801Z i86pc i386 i86pc [root@srv2 ~]# imgadm install image-uuid imgadm install: error (Usage): unexpected args (1): "image-uuid" [root@srv2 ~]# vmadm create -f vm.json File: vm.json does not exist. Compared to the process outlined in the article that works, and shows you how to setup the entire process to, build, rebuild, and run two separate containers. Their first command is basically $ docker run -it --rm ubuntu root@37ffd019060f:/# Which anyone with docker installed can run. Your first command returns an error message. And then you go on to say > With SmartOS, the database image can be preconfigured and published into the catalog > one XML file and svcadm import later, the thing is ready to be turned into an image, never to have to be revisited again > a single invocation of vmadm -f vm_definition.json So all you have to do is preconfigure things (how?), publish them into the catalog (whatever that is) and write both an xml and a json file (contents unknown) to start your service. If you actually cared about getting people interested in smartos, you would write a "learn-smartos-by-building-a-microservice" article and show how to actually use the fucking thing instead of ranting how terrible docker is.

Annatar 10y ago
> Do you know what the difference is between the posted link and your comments? The stuff in the article actually works, while your "look how simple it is" comment, does not: The usage I provided is a SYNOPSIS, as in synopsis from a manual page. You will note that mine is a comment, not an entire blog article (I do not have a blog). The intent behind my comment is to provide a pointer to further exploration; it is not a how to document, but rather a starting point for those who are actually willing and able to sit down and read some documentation, which is in the links I provided, and will provide the equivalent of what the author's article does, and dividends on top of that. (Less incidents in the dead of the night equals long term dividends.) My intent was that someone will read it and go off to explore it. That is not to say that I do not agree with your point, as I myself am a firm believer in examples which work. However, one must at some point have the experience to distinguish between a synopsis and a guide. A lone comment on Hacker News is not the place for an entire how to guide. > Which anyone with docker installed can run. Yes, but as with anything, there will be long term consequences: while anyone can get it up and running easily, when it comes time to put it in production, and the thing busts because there is no lifecycle management, no change management, no configuration management (sorry: dumping a bunch of files into a Docker "image" definition doesn't even come close to lifecycle management, or capability maturity model level 2[1]), no post mortem debugging facilities, no end-to-end data integrity, and performance penalty for running inside of a fully virtualized VM, the problems will start. For example, MySQL was also "easy to set up", but that didn't change the fact that the software does not work correctly[2] and that MySQL deployments later caused many organizations many problems. Just because something is easy to set up does not mean it is a good solution to deploy. Nowadays people are realizing that and migrating to PostgreSQL because that software does work correctly, but all that time, effort and money spent because of how "easy" MySQL was to get going could have been prevented in the first place. With Docker and how it is designed, and based on what I know, I can see the same types of problems which will inevitably lead to outages. And in the interest of disclosure, what is it to me? Well, argumentum ad populum is extremely spread these days, which means that lots of jobs would (and have) started springing up with Docker, which means I would be forced to work with what I know from experience is inferior technology. Since I see the problems of Docker, that means I would not be able to sleep through the night, and spend my nights in conference calls with clueless managers demanding that I fix it. I do not want that; I want to sleep through my nights, and work with slick and reliable technology like SmartOS, not a toy like Docker causing me problems down the road, and just because it was popular. You are making an indirect argumentum ad populum, which is never a good thing. > If you actually cared about getting people interested in smartos, you would write a "learn-smartos-by-building-a-microservice" article and show how to actually use the fucking thing instead of ranting how terrible docker is. If you had bothered to read the documentation in the links, you would have a pretty good idea on "how the fucking thing works", and how to build a microservice; I am sorry if you think that clicking on the links and reading through the articles is too much overhead. How is it then, that reading through that Docker article isn't overhead, and you had no problem clicking at that? [1] https://en.wikipedia.org/wiki/Capability_Maturity_Model#Levels https://en.wikipedia.org/wiki/Capability_Maturity_Model#Leve... [2] https://www.youtube.com/watch?v=emgJtr9tIME https://www.youtube.com/watch?v=emgJtr9tIME
- deleted 10y ago
  [deleted]

Annatar 10y ago

> Do you know what the difference is between the posted link and your comments? The stuff in the article actually works, while your "look how simple it is" comment, does not: The usage I provided is a SYNOPSIS, as in synopsis from a manual page. You will note that mine is a comment, not an entire blog article (I do not have a blog). The intent behind my comment is to provide a pointer to further exploration; it is not a how to document, but rather a starting point for those who are actually willing and able to sit down and read some documentation, which is in the links I provided, and will provide the equivalent of what the author's article does, and dividends on top of that. (Less incidents in the dead of the night equals long term dividends.) My intent was that someone will read it and go off to explore it. That is not to say that I do not agree with your point, as I myself am a firm believer in examples which work. However, one must at some point have the experience to distinguish between a synopsis and a guide. A lone comment on Hacker News is not the place for an entire how to guide. > Which anyone with docker installed can run. Yes, but as with anything, there will be long term consequences: while anyone can get it up and running easily, when it comes time to put it in production, and the thing busts because there is no lifecycle management, no change management, no configuration management (sorry: dumping a bunch of files into a Docker "image" definition doesn't even come close to lifecycle management, or capability maturity model level 2[1]), no post mortem debugging facilities, no end-to-end data integrity, and performance penalty for running inside of a fully virtualized VM, the problems will start. For example, MySQL was also "easy to set up", but that didn't change the fact that the software does not work correctly[2] and that MySQL deployments later caused many organizations many problems. Just because something is easy to set up does not mean it is a good solution to deploy. Nowadays people are realizing that and migrating to PostgreSQL because that software does work correctly, but all that time, effort and money spent because of how "easy" MySQL was to get going could have been prevented in the first place. With Docker and how it is designed, and based on what I know, I can see the same types of problems which will inevitably lead to outages. And in the interest of disclosure, what is it to me? Well, argumentum ad populum is extremely spread these days, which means that lots of jobs would (and have) started springing up with Docker, which means I would be forced to work with what I know from experience is inferior technology. Since I see the problems of Docker, that means I would not be able to sleep through the night, and spend my nights in conference calls with clueless managers demanding that I fix it. I do not want that; I want to sleep through my nights, and work with slick and reliable technology like SmartOS, not a toy like Docker causing me problems down the road, and just because it was popular. You are making an indirect argumentum ad populum, which is never a good thing. > If you actually cared about getting people interested in smartos, you would write a "learn-smartos-by-building-a-microservice" article and show how to actually use the fucking thing instead of ranting how terrible docker is. If you had bothered to read the documentation in the links, you would have a pretty good idea on "how the fucking thing works", and how to build a microservice; I am sorry if you think that clicking on the links and reading through the articles is too much overhead. How is it then, that reading through that Docker article isn't overhead, and you had no problem clicking at that? [1] https://en.wikipedia.org/wiki/Capability_Maturity_Model#Levels https://en.wikipedia.org/wiki/Capability_Maturity_Model#Leve... [2] https://www.youtube.com/watch?v=emgJtr9tIME https://www.youtube.com/watch?v=emgJtr9tIME

deleted 10y ago
[deleted]