Sorry, but as a fellow Canonical employee, speaking from a throwaway obviously, it's evident to me that you're simply not telling the truth here.
You know just as well as I do that if you criticize Snap within the company, you get fired. Especially if Mark overhears you. There is no room for criticism. You either drink the koolaid or you shutup. So, no, sorry, we're going to keep pumping out Snap and those who don't fall inline will just fall out of the company. This is how we've always done these things, despite it failing repeatedly, and Snap is no exception. Actually, Snap is in particular no exception, given how hard it's being pushed by top level management.
[An aside from the main point of this comment: your point 3 is nonsense, and any security guy will tell you the same. For packages that the main sudo-ing user executes, sandboxed or not, there still is effectively no difference between that and root. Snap's sandbox is alpha quality at best, and major platform hurdles remain to make it capable of doing anything remotely useful. Say no to auto-updating snap backdoors. Please. There's a reason why Linux has thrived and benefited with its vetted-by-distros traditional package managers.]
First, has anybody actually been fired for criticizing snaps? Your comment seems to imply through hyperbole that we don't debate inside Canonical, but in my experience that simply isn't true. In fact, I've seen a lot more intense IC to CEO debate in Canonical than anywhere else I've worked. It's not always super constructive debate, but I don't know how much better it is in any relatively small organization with the broad impact Canonical has.
Second, debate and reflexion is how these positions get refined. An idea starts out crazy and radical -- "let's make an OS which costs zero and which anybody on the planet can figure out how to use!", or "Launchpad will only support bzr", or yet again "upstart, not systemd" -- but over time it evolves towards a place of greater consensus. So I don't think we're the destination for snaps; in fact, if these blog posts are only coming out now, it signals we are rather early in the journey.
Finally, I can understand creating a throwaway account to disclose something you're not comfortable with at your workplace, but it's not cool -- nor constructive, civil or all sorts of C words -- to create one to and start with "you're simply not telling the truth". C'mon, I'm your coworker.
I want to just say I appreciate your level-headed response to the anonymous poster.
Separately... "In fact, I've seen a lot more intense IC to CEO debate in Canonical than anywhere else I've worked."
As an outsider, this makes me wonder if the CEO is too involved in day-to-day operations. (And overriding the work of those with more expertise than himself.)
Hmm, let me think a bit about how to respond to your first paragraph.
But meanwhile, I'm curious about point 3 as you seem to have facts that I lack -- when a confined snap refresh runs through snapd, is the upgrade payload not executed entirely in userspace within the sandbox? I haven't looked at the code, but my understanding of the model is that the snap can only modify its own writable areas (and do stuff like add a symlink to /snap/bin, though that's also limited). So a snap update could't, for instance, modify arbitrary files, nor read restricted ones. Whereas a dpkg install can do anything as root. Can you help clarify?
You know just as well as I do that if you criticize Snap within the company, you get fired. Especially if Mark overhears you. There is no room for criticism. You either drink the koolaid or you shutup. So, no, sorry, we're going to keep pumping out Snap and those who don't fall inline will just fall out of the company. This is how we've always done these things, despite it failing repeatedly, and Snap is no exception. Actually, Snap is in particular no exception, given how hard it's being pushed by top level management.
[An aside from the main point of this comment: your point 3 is nonsense, and any security guy will tell you the same. For packages that the main sudo-ing user executes, sandboxed or not, there still is effectively no difference between that and root. Snap's sandbox is alpha quality at best, and major platform hurdles remain to make it capable of doing anything remotely useful. Say no to auto-updating snap backdoors. Please. There's a reason why Linux has thrived and benefited with its vetted-by-distros traditional package managers.]