niemeyer

> Either take my code without a contract or live with the bugs

The less simplistic view of the situation is that major maintainers (corporate or otherwise) pay the price of keeping the project up for the long run, under the defined license, in all senses including the legal one. So the CLA is the way to integrate contributions without strings that remain legally attached to the author of these contributions. So the CLA is, ironically, the way for these major maintainers to say "no strings attached or wait until we fix the bugs" back to you.

I'm sad to see Stephane leaving, but it's lost in me how his departure towards doing whatever else he wants to do suddenly transforms into LXD not being open?

It was always pretty clear that something would have to get adjusted the day Stephane left the company, because it's a major project for Canonical and Stephane preferred to run some of the infrastructure himself. From his own comments in the forum:

"In theory Ubuntu Discourse should be more reliable in that it’s run by Canonical IS who has a 24/7 team of people looking after services unlike this forum where I’m the one running the infrastructure and dealing with outages."

Nothing is changing about how in the open LXD is developed.

I don't know who you talked to, but I can tell the story is richer and more interesting than that. Saying that snaps have performance issues is similar to saying that containers have performance issues. They do affect performance because doing something is always more expensive than doing nothing, and snaps do something in addition to just running a bare executable on your machine. At the same time, the kind of operation that snaps perform should not have a significant impact on a modern computer to the point of making it slow or annoying, because most of the operations are relatively simple and happen at a low level, and computers are fast.

At the same time, snaps are a new packaging format, and when you change the layout of applications to include things such as restrictions or making things read-only, suddenly all kinds of things can go wrong, and some of these can cause major performance impact.

Two easy and real examples from the snap world: early on there was a bug where .pyc files would be out of date, and the filesystem was read-only. This meant every single time the application was opened Python would recompile the entire application and fail to write its cache files in every case. Major performance impact. That was fixed.

Another one: fontconfig cache changed its format, and as a side effect applications running could not make use of the one in the system and had to rebuild their own copy every time. Extreme performance impact. That was fixed.

And the list goes on. So the point is: snaps are not slow, because there's nothing fundamental happening there to make them slow. But snap applications can be slow, of course, potentially by orders of magnitude. These are bugs, and we fix them when we see them.

That's exactly it. I work at Canonical and was part of the internal conversation around this subject. We constantly walk that fine line where we want to encourage open source work and communities around it to flourish, while at the same time we need to pay for bandwidth and people's salaries to be working on that exact technology. The irony is that for the particular case at hand, they would probably get it for free because despite being a commercial project it's a small one at that, and we love to see such initiatives taking place. At the same time, we work with major industry players that are supposed to pay the bill, for their own benefit and for everybody else's too, otherwise we just go out of business and that's no good. It took time mainly because we need to set the exact terms without arbitrary discrimination.

We'll have a more clear form for that kind of application soon, so that we can streamline such requests, community or otherwise.

> It is a pretty nifty idea but like all things made by Canonical it is basically digitized garbage.

> At least those are not made by people with a disdain for error checking.

Every single time there's a topic about Ubuntu or Canonical you seem to go straight into offensive mode. I can tell you use Fedora, but that's not typical of Fedora users and developers and no excuse.

I'm an open source developer and believer, but this kind of behavior slowly burns my soul, even more when it seems accepted. I've worked on enough projects in my life that it's absolutely certain that you use my code regularly. It's inside Go, Python, APT, and RPM by the way (hello Jeff Johnson, wherever you are), and in key libraries that you surely depend on as well. And I never heard you complaining about any of that with such anger here.

I'm also Canonical's CTO, and I was one of the key designers and developers that started snaps, and juju, and other key projects from Canonical. I usually hear such blind hate in silence, but sometimes it's just too much. I don't understand why do we do that to ourselves, as a Linux community. Why is it okay to openly offend unknown people that we almost certainly depend upon? What is it that we came here to do, again?

If it makes you happy, yes, I see it. But that doesn't make things better for anyone. We've had more interesting discussions around this issue where people could actually present good arguments towards more control, and some of these conversations resulted in the development of more control features, as presented earlier in this thread.

Also, it's important to realize that it's not me or Canonical that has control over the updates, so it's not me knowing better than you. The goal of this exercise is to have good tooling that would allow updates to flow between a publisher and a user with a better overall outcome.

That means, for example, that we are putting more pressure on publishers to get it right, because they will more quickly and obviously break people if they release something broken. There are actual high profile publishers that changed their processes because of that.

We are also putting more pressure on the tooling, because we need to be able to recover gracefully when the update does fail, and that's one of the reasons why we have a more polished transition and rollback mechanism than any package manager out there.

Yes, maybe it won't work, but it's a very interesting problem and is worth solving. Then, even if we don't fully solve it, the exercise will have been worth it, because it improved all those aspects in meaningful ways.

But I hear you... you're mad at me. Point taken. :-)

Indeed the size calculation is incorrect. It's likely looking at the unpacked size, but snaps are never unpacked, which ironically is a difference missed by itself.

These are the actual sizes for these snaps:

  $ snap info vlc | grep stable:       
  stable:    3.0.4                   (555) 204MB -

  $ snap info libreoffice | grep stable:      
  stable:    6.1.2.1 (86) 501MB -

  $ snap info gimp | grep stable:
  stable:    2.10.6 (47) 192MB -

Yes, the article indeed is on the low end. It focuses mainly on the package sizes, and gets it very wrong as mentioned in other comments.

Yes, the size is wrong. It's looking at the unpacked size, but the snaps are never unpackaged. Here are the actual sizes for the mentioned snaps:

  $ snap info vlc | grep stable:       
  stable:    3.0.4                   (555) 204MB -

  $ snap info libreoffice | grep stable:      
  stable:    6.1.2.1 (86) 501MB -

  $ snap info gimp | grep stable:
  stable:    2.10.6 (47) 192MB -

There's a long thread with in depth discussion about this:

https://forum.snapcraft.io/t/disabling-automatic-refresh-for...

For those that understandably won't want to go through it all, the short version is that by design snaps will force the update eventually, so that a system isn't simply left behind, but since snapd came out a few years ago we've been constantly working on multiple methods to offer control over when exactly the update takes place. These are features such as:

- Fine scheduling of updates (https://forum.snapcraft.io/t/refresh-scheduling-on-specific-...)

- Disabling over metered connections (https://forum.snapcraft.io/t/snap-refresh-over-metered-conne...)

- Holding of refreshes after boot (https://forum.snapcraft.io/t/delaying-refreshes-and-registra...)

- Manual delaying of updates (can't find topic)

So, the goal is actually to offer control, but we are indeed trying to prevent systems from getting out of date for good. Maybe that's a bad idea, and if it turns out to be we can change that in the future, but we've been making an honest effort to try to fix the problems of automatic updates instead of simply giving up. Once we give up, there's no going back since the dynamics around package updates will change. We have plenty of experience around these aspects with the traditional systems.

There are self-hosted proxies, and there are publicly hosted stores, but all stores are part of the exact same hierarchy and share some of their knowledge. That's mainly a consequence of implementing the intended user experience as originally designed back then.

> I'm assuming with "LSM stacking" that you mean

The term "LSM stacking" is public. Search for it and you'll get good material.

> Are you going to convince Red Hat to

That's not how things work. Canonical and RedHat collaborate technically by improving parts of the system as necessary. Things are enabled or not based on market requirements.

> What about helping to maintain AppArmor support in Fedora?

Canonical already does that by working to upstream the patches. That helps Fedora and everybody else too.

> I'm pretty sure that everyone will say no to the idea of combining AppArmor with SELinux

Well, no need to guess.. there are open discussions about it.

> I think you missed the point. But sure, maybe. If there wasn't the CLA to get in the way...

For legal reasons that are not unique to Canonical we do require a pretty straightforward CLA to be signed. I've signed that sort of CLA myself for other large companies, both individually and in the name of Canonical, so the playing field is level here.

I don't think that was ever true?

Docs: https://docs.snapcraft.io/build-snaps/electron

Example: snap info electron-quick-start

> I don't think it's the majority _per se_ (since Ubuntu Core can't run those), but most of the popular ones likely do.

No, that's also incorrect if you slice it by popularity. We don't have a public chart easily filtered by these aspects together, but just pick some random samples.

It's also easy to see that based on the low volume of classic snap requests in the forum, vs. the volume of actual snaps published and announced in the open.

> Snaps rely heavily on Ubuntu's specific flavor of AppArmor to be able to offer full confinement,

The AppArmor patches have been largely upstreamed by Canonical, and improvements continue to float upstream constantly. So claiming it's not being reviewed isn't accurate.

> * Canonical doesn't know how to work with SELinux at all, and doesn't want to learn how to

That's disingenuous. Canonical works with many parties, and has people working on LSM stacking for example precisely to support co-existence of the systems. We also had exchanges in the forum to discuss the implementation of actual backends in snapd to support it, but Canonical indeed won't pay for the cost of implementation until there's a reason to do it. That's business as usual and pretty straightforward.

> In addition, the majority of snaps are not sandboxed at all anyway, as they operate in "classic" confinement.

That's incorrect by a huge margin. I'm curious about where you could possibly have based that opinion on? Classic snaps require manual reviews, which need to be backed by public justification. You can see every single request floating by in the store category at https://forum.snapcraft.io. That means every snap people push without talking to anyone are not classic, and thus the vast majority.

> Finally, Canonical is the sole arbiter of snaps.

Well, yes, it has created the project and maintains it actively for years now. You're welcome as a contributor.

> Disclaimer: I'm a Linux app developer that grudgingly deals with both formats. I'd rather just keep using RPMs myself

And I work on snapd (and have also worked on RPM back then, so enjoy :).

No, not really. Files at ~/.* were never readable or writable for strict snaps, even when they were granted the "home" interface, precisely for that sort of reason. The file permissions and ownership are also strictly checked by the store (no setuid bit issue). Classic snaps depend on manual approval, and need to be acknowledged by the user before being installed for that reason, etc.

I work for Canonical on snapd, so can provide some background here.

You're probably describing Ubuntu Core instead of classic Ubuntu. The UX there is oriented for devices, and it was cooked to avoid default passwords in an environment in which the device often will have no display. So once you boot, the device is in a running state, and the brand (manufacturer) that cooked the image has the choice of allowing individuals to login or not. In addition to a store account, the brand can also offer a "system-user" assertion, that is a signed document that you can present devices to get a system user in. That assertion may detail remote login, SSH keys, and also a hashed password for independent logins. That only works once on the device, though, for obvious reasons.

For generic Ubuntu Core devices the "brand" is Canonical, and for those devices you can get an assertion signed and with it log into any number of devices you want. That procedure may be done over USB storage, for example. Just insert a USB key into the device and your user credentials will be setup, even if it's completely offline. Again, that only works once on the device. If you lose the keys the device will need to be factory-reset.

Such competing efforts are actually a form of non-voluntary collaboration. rpm and deb (and apt, yum, synaptic, ...) have significantly evolved together along the years, looking at each other. This happens all the time, and is happening again here.. the snap format and snapd evolve based on previous knowledge, and it's no surprise that the linked LWN article seems quite inspired by snaps (I'm biased as a snapd designer/developer).

Let it come.. we'll be watching and picking up the good ideas too. And working hard to make sure snaps continue to win on merit, rather than lack of competition.

Yes, people are using in production. Last community meeting we had some folks reported a large server deployment in the UK (in the order of thousands of servers) that was being partly transitioned to snaps. I think that's the biggest use I've personally heard about so far.

There are some people interested in having them working on 14.04, btw. It'd be great to see that working well.

We have a sprint next week to discuss some of that. The recent focus around snaps has been on the feature set leading to Ubuntu Core 16, which is itself in freeze at this point. The features are mostly general, though, and have been landing on 16.04 and 16.10 on the way.

This was the announcement:

https://lists.ubuntu.com/archives/snapcraft/2016-October/001...

Interview processes aren't about ensuring 100% of the good candidates get hired, but rather about trying to ensure that the candidate finally selected is good.

Being several times on the hiring end of that conversation, there's a class of great people that are very hard to identify over an interview. It feels quite bad to suggest a no-go in those cases, but living through such choices, sometimes for years, increases the fear of mishaps.

These days I mainly look at track record. Involvement in projects, conversations, issues filed, quick hacks, etc. Often language or tech doesn't even matter, as long as there's flexibility and an ability to talk over problems.

If you log into one of their shared hosts you'll see custom kernel, custom packages, etc.

Indeed, or any other case where the application is granted permission to do something sensitive (camera?) and abuses that trust. Even in those cases, though, it is an improvement to know the access exists, and to have control over it.

Some more details about snap interfaces:

http://blog.labix.org/2016/04/22/snappy-interfaces

There are further details about how it works in this blog post:

http://blog.labix.org/2012/08/22/multi-doc-transactions-for-...

While it does work, it's still a workaround for the lack of first-class transactions in MongoDB. It offers a more limited API and requires care on the developer side.

Despite being the author, I do hope it gets obsoleted by more convenient first-class transaction support in MongoDB itself at some point in the near future.

The transaction does span across hosts with the linked package.

There are many different aspects to shared object support, there is support to some of these aspects today (you can link against shared libraries, for example), and there are on going conversations about supporting other models.

This is a recent thread on the subject:

https://groups.google.com/d/msg/golang-dev/0_N7DLmrUFA/qGRb8...

Where's the data showing bananas are more heavily treated than any other fruit?

Here is some actual data from 2009, with analysis for Brazil by a proper agency (ANVISA's PARA, Project for Analysis of Agrotoxic Residue in Food):

http://portal.anvisa.gov.br/wps/wcm/connect/1424b98041ebbfb7...

It's in Portuguese, but you can find a nice color table in page 7 with fruit and vegetable names (rows) and states (columns) providing an idea (red == bad).

Bananas do better than pretty much anything else tested there.

The rule was never entirely clear, but there was definitely support towards allowing Go pointers to be visible in C code, as long as they were held referenced inside Go code somewhere. See this thread, for example:

https://code.google.com/p/go/issues/detail?id=6397#c11

That said, the rule is clearly changing now, and it is not even clear to what it is changing yet (see Ian's comment in this HN thread).

Please note that the details aren't defined yet, and Ian indicates in a comment in this HN thread that some sort of pinning may exist. I also expect that to happen, given that a strict rule would break a lot of packages and turn what is today trivial into boring and slow code.