Hacker News Reader

Comment by rymohr | Hacker News Reader

I hate when I see people throwing in the towel like this.

As a two developer company with four separate products doing nearly $500k in ARR collectively, Kumu [1] is a living example that it doesn’t have to be this way.

We rely heavily on bash, docker and cloudformation.

We only use Ubuntu LTS and we lag a release behind so there are plenty of tutorials available when it comes time to upgrade.

After experimenting with backbone, coffee script, flow, vue and multiple redux libraries we’ve settled on rewriting everything in typescript and developing our own thin redux abstraction.

Embrace new tech that makes developers’ lives easier while hopefully making things more secure too.

I get it if that’s not possible in large enterprise companies, but please don’t throw all software under the bus. Software is and will always be fun and there are still fun companies to work for if you’re willing to take a little risk.

[1]: https://kumu.io

View on HN

I'm a bad writer. I'm not trying to throw in the towel, say software can't be fun, or that useful products can't be built within the status quo.

I can look at the product I develop and rattle off an impressive list of capabilities, talk about how well it is designed, say why it's the best product for the job on the market and talk about successes in the field. But I can also look at it and see a laundry list of design flaws, architectural limitations and unrealized enhancements that may never get time on the schedule.

The second side of the fence exists, and security people inherently spend a lot of time there. Spend enough time there and you see how the system that is the sum of all software is a mess. I'm not even saying it's a bad thing, just that it's the inescapable reality.

Your architecture is like swimming in a school of fish. By moving with the group you benefit from the successes of the group. Ubuntu, docker, typescript and delivering your product as webapp brings a lot of benefits in featureset, maintenance and training that come at a reduced cost. For the same reasons I also prefer to use as much popular off-the-shelf tooling as possible and stick to familiar designs wherever possible.

You're probably doing better than most. But even with all that benefit, the components of your system are fraught with defects and limitations that in a perfect world would already be solved problems. Both in the stack you use and your own software. And you make it work despite that. Great. That's not my point.

Not a bad writer at all. And I think all the problems you describe do exist. I'm just saying keep your head up and look too the bright side.

Be happy that you have a job that compensates you well, aligns with your values, is flexible to your personal needs, allows you to grow professionally, and enables you to reach for the goals you've set while you're here on earth.

And if that doesn't describe your job, please quit and come work with us or any other company that respects you as a human being first and a sysadmin second. Life's too short to do otherwise.

Your writing is just fine.

To me, most of the critical comments seem to miss the point that your frustration centers around the foolishness of trying "go as fast as possible" while at the same time "your shoelaces are tied together."

Docker has its own security nightmares and mis-designs -- for instance, are you using user namespaces? With LXC and LXD user namespaces are the default (and unlike Docker's design, they can use different ID mappings which blocks inter-container attacks). There are plenty of other missteps I can think of.

(I am a maintainer of runc and have contributed to Docker for a long time, as well as collaborated with the LXC folks.)

I love lxc/lxd. Its really a shame that there is little to no interest by the lxd team in supporting the oci container format.

I assume you're referring to the OCI image format (not the runtime spec). This is because the OCI image format doesn't quite meet what they want for LXD -- in particular the whole layering design that OCI uses (which was inherited from Docker) is simply wrong for them. In fact there is a strong argument that the layering design doesn't even match what OCI really wants (it effectively embeds an optimisation for "docker build" into the storage format).

I am actually working on improving the current state of OCI images[1] by using a snapshot-based tree structure -- which will also solve many problems we have in OCI that are independent from LXD. But it is possible that the LXD folks would be more interested if the OCI format more closely matched what they need.

Though it should be noted that LXC has had an OCI template for several years now[2] (and it actually uses a tool I wrote -- umoci -- to extract the OCI image).

[1]: https://www.youtube.com/watch?v=bbTxdzbjv7I [2]: https://github.com/lxc/lxc/blob/lxc-3.2.1/templates/lxc-oci....

Yeah I am aware of the oci-template. I was mostly thinking of discussions like this[1] where Stéphane says there are no plans to support anything like that in LXD.

I find the distinction between "system containers" and "application containers" to be a bit arbitrary from a technical perspective. What does it matter what I'm running as PID 1? I find both system containers and application containers to be useful.

It seems like LXD would see larger adoption if it were easy to run docker container images directly (built into the LXD tooling).

[1]: https://discuss.linuxcontainers.org/t/using-oci-templates-in...

Reply on news.ycombinator.com