| lotuspsychje | good morning | 01:46 |
|---|---|---|
| === JoeBk_ is now known as JoeBk | ||
| === JoeBk_ is now known as JoeBk | ||
| ducasse | morn | 06:40 |
| marcoagpinto | morn | 06:41 |
| ducasse | hi marcoagpinto \o | 06:42 |
| marcoagpinto | :) | 06:42 |
| marcoagpinto | I had to order printing paper from Amazon DE | 06:42 |
| ducasse | what are you up to? | 06:42 |
| marcoagpinto | it is out of stock here in Portugal | 06:43 |
| ducasse | oh wow | 06:43 |
| marcoagpinto | for the price I paid it should be "gold paper" | 06:44 |
| marcoagpinto | :( | 06:44 |
| ducasse | i bought a pack of 500 sheets years ago, finally running low now | 06:46 |
| ducasse | i print very little though, mostly manuals or reference materials | 06:48 |
| marcoagpinto | well, ducasse, I could order from Amazon ES (Spain) but I noticed that they also sell 100 sheets instead of 500 | 06:52 |
| marcoagpinto | and in most cases I am not sure if the item is 100 sheets or 500, so I can't risk | 06:52 |
| marcoagpinto | I look at the photo and it doesn't appear there the number of sheets | 06:53 |
| marcoagpinto | in Portugal they are 500 sheets | 06:53 |
| ducasse | they're almost all 500 here | 06:53 |
| marcoagpinto | here too | 06:53 |
| marcoagpinto | :) | 06:53 |
| ducasse | or boxes of 2500 | 06:53 |
| marcoagpinto | yes | 06:53 |
| marcoagpinto | but the damn Amazon ES sells a lot of 100 sheets | 06:54 |
| marcoagpinto | I didn't know that even existed | 06:54 |
| marcoagpinto | except for some special papers | 06:54 |
| marcoagpinto | like 200 gr or 120 gr, I can't remember | 06:54 |
| marcoagpinto | I am not going to pay 20 or 30 EUR for paper and when it arrives is 100 sheets | 06:55 |
| marcoagpinto | ahhh... 20 or 30 EUR of postage costs | 06:55 |
| marcoagpinto | :) | 06:55 |
| marcoagpinto | sorry... it is postage costs | 06:55 |
| marcoagpinto | the paper costs 5 EUR | 06:56 |
| marcoagpinto | :) | 06:56 |
| marcoagpinto | but the question is if it is 100 sheets or 500 | 06:56 |
| ducasse | i should buy paper too, i'm almost out | 06:59 |
| ducasse | i have some documentation i need to print | 06:59 |
| ogra | mort, lets take it here, lets not spam #ubuntu with non-support stuff | 09:30 |
| mort | is there anything more to discuss | 09:30 |
| ogra | dunno, you seem to base your snap experience on a few desktop test packages we added to the image to collect info about issues ... you cant really judge server snaps based on that | 09:31 |
| mort | I base my snap experience on my snap experience, which is mainly the snap packages you force down my throat | 09:32 |
| mort | I had to compile my own chromium because you broke your chromium package by replacing it with a snap | 09:32 |
| ogra | heh ... nobody forced anything | 09:32 |
| mort | well, you remove apt packages I depend on and replace them with snaps | 09:32 |
| ogra | what exactly is broken about it | 09:32 |
| mort | it doesn't launch in wayland | 09:32 |
| mort | https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1897454 | 09:33 |
| ubottu | Launchpad bug 1897454 in chromium-browser (Ubuntu) "[snap] Chromium has Wayland support disabled" [Low, Confirmed] | 09:33 |
| mort | reported in 2020, confirmed, low priority | 09:33 |
| mort | you don't care | 09:33 |
| ogra | well ... enabling wayland support for it by default breaks it on the raspberry pi in a way it becomes unusable | 09:33 |
| mort | boo hoo, don't make it a snap then | 09:33 |
| ogra | that has nothing to do with the snap | 09:34 |
| mort | wait, I think you're misunderstanding, I'm not talking about "by default" | 09:34 |
| mort | I would be fine making a .desktop file which launches it with `--enable-features=UseOzonePlatform --ozone-platform=wayland` | 09:34 |
| mort | but that also doesn't work in the snap package because the snap doesn't let it talk to the wayland server | 09:35 |
| mort | that wouldn't be an issue if it wasn't a snap | 09:35 |
| ogra | well, submit a patch to the wrapper shellscript to make it disable the "DISABLE_WAYLAND" variable when --ozone-platform=wayland is set ... | 09:36 |
| ogra | here is the source https://git.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source/tree/launcher/chromium.launcher?h=dev | 09:36 |
| mort | but this is the thing | 09:37 |
| mort | you break shit | 09:37 |
| mort | why | 09:37 |
| mort | just don't make it a snap and it doesn't break | 09:37 |
| ogra | start paying money and we can hire another full time dev to maintain it ... | 09:38 |
| mort | and there is no `DISABLE_WAYLAND` in that source, I'm not sure what you're talking about | 09:38 |
| mort | you've spent way more money building the snap system than you would spend compiling chromium | 09:38 |
| mort | I understand that building a proprietary walled garden style app store is important for canonical, but it's not important for its users | 09:38 |
| ogra | yes, in 2014 we started building snaps for embeded, industrial, could etc | 09:39 |
| ogra | *cloud | 09:39 |
| ogra | they became a commercial success quickly | 09:39 |
| mort | I really don't understand the embedded use-case, why would you use snap packages there instead of just installing the libraries you need to the system image | 09:39 |
| ogra | since customers understand the advantages | 09:39 |
| mort | but you support like 0 SoCs | 09:39 |
| ogra | in 2016 we decided to also try them for dekstop packages ... | 09:39 |
| mort | which was a failure | 09:39 |
| mort | well, it was user-hostile | 09:40 |
| ogra | not really ... it saves immense maintenance costs | 09:40 |
| mort | maybe canonical considers it a success because you get to have your walled garden | 09:40 |
| ogra | i.e. maintaining chromium means you need to build it against 4 different release on 6 architectures and need to test it against these ... with the release cadence of chromium this means you need to have a full time dev 5x8 working on it to have it tested and verified on all these arches | 09:42 |
| mort | look at any discussion online about snaps, everyone hates it, everyone sees that it drastically increases application startup time, everyone sees that it breaks integration with the rest of the system in all kinds of ways | 09:42 |
| mort | I know you like to dismiss all the concerns as FUD | 09:42 |
| mort | but they're actually based on really crappy experiences people in the real world are having | 09:42 |
| ogra | well, the same week we announced snaps for desktop, fedora decided to rename the until then idly "xdg-apps" project to flatpak ... i only started seeing hate posts after this ... | 09:43 |
| mort | and the "it runs on proprietary closed-source back-end infrastructure and prevents users from adding other repositories" thing is a real concern which a lot of people have real philosophical problems with, that's not FUD either | 09:44 |
| ogra | (and back then flatpaks were equally non-functional for desktop apps) | 09:44 |
| ogra | you are aware that there is nothing propriaetary, right ? | 09:44 |
| mort | you only see hate posts after you announced snaps for desktop? What a surprise | 09:44 |
| mort | oh? Where's the source code for the snap back-end | 09:44 |
| ogra | it is a webserver and a postges DB | 09:44 |
| mort | so where's the source code | 09:45 |
| ogra | what ? our server scripts and DB setup ? | 09:45 |
| ogra | you can easily implement that yourself | 09:45 |
| ogra | there are at least two projects doing that | 09:45 |
| ogra | the snap server API is open and well documented | 09:45 |
| mort | presumably there's some server software which reads the database, and some server software which somehow manages the database? | 09:45 |
| ogra | its a few oython scripts ... that provide a REST API | 09:46 |
| mort | sure | 09:46 |
| mort | that's not a sarcastic "sure", that's a "that may be the case but I don't care" | 09:47 |
| ogra | that REST API is well documented ... akll you need is apache/ngnix and a DB .... and probably xdelta3 for the by-default delta downloads | 09:47 |
| rs2009 | hi everyone, was wondering if any of the old nux docs are still online (found a few IRC meetings logs related to Nux on the Ubuntu Wiki, but couldn't find anything else related) | 09:48 |
| ogra | https://forum.snapcraft.io/t/announcing-project-kebe-open-source-snap-store-start/25088 | 09:48 |
| mort | I just don't understand the insistence on keeping it closed, it's not like throwing it up on some public git repo would be a big deal | 09:49 |
| ogra | mort, do you knwo how canonical makes money ? | 09:49 |
| rs2009 | mort: would be great if you could tell me where the source code for archive.ubuntu.com is hosted | 09:49 |
| rs2009 | lol | 09:49 |
| mort | ogra: deals with enterprise customers, IoT/embedded, support contracts, that sort of stuff? | 09:50 |
| mort | I'm guessing here | 09:50 |
| ogra | rs2009, https://code.launchpad.net/launchpad ... | 09:50 |
| ogra | mort, it sells infrastructure and services around this ... | 09:51 |
| mort | if your way of money causes you to make user-hostile decisions, that's bad | 09:51 |
| ogra | mort, for snaps that means dedicated stores for enterprise customers ... | 09:51 |
| mort | if I complain that google has a really unethical global surveillance network you can't respond to that with "yeah but it's okay because that's how they make money", that's kind of the problem | 09:51 |
| ogra | why ? | 09:52 |
| ogra | i would reply with exactly that | 09:52 |
| mort | because something doesn't become okay just because it makes money? | 09:52 |
| ogra | and you are free to use alternatives | 09:52 |
| rs2009 | ogra: /s (and that's not even the source code of the APT server's generation scripts itself, which simply isn't available) | 09:52 |
| rs2009 | so not sure why everyone wants the source code for Canonical's server | 09:52 |
| ogra | rs2009, yeah 🙂 | 09:52 |
| mort | ogra: but I understand, there's an extremely deep moral difference between us which makes our opinions fundamentally incompatible | 09:53 |
| mort | you think anything is morally okay as long as it makes some rich dude richer | 09:53 |
| mort | I don't | 09:53 |
| ogra | mort, well, i work in opensource companies since 25y ... therre are not many working models to make money and the ubuntu/canonical way is the morally best one i know, else i wouldnt still be here | 09:54 |
| ogra | lol | 09:54 |
| mort | but you think google's surveillance is morally okay purely because it makes google richer, you presumably think amazon's horrible treatment of its workers is okay because it makes bezos richer, etc | 09:55 |
| mort | if that's your moral system, we can't agree on anything | 09:55 |
| ogra | mark has not made a cent with canonical or ubuntu in 18y | 09:55 |
| ogra | quite the opposite | 09:55 |
| mort | but that wasn't your argument was it | 09:55 |
| ogra | no, it was yours | 09:55 |
| mort | you explicitly supported the idea that google's practices are ethical because it makes them money | 09:56 |
| ogra | no, i support the idea that companies need to make money to pay their devs | 09:56 |
| mort | but you reject the idea that there are ethical and unethical ways of making money | 09:56 |
| mort | well | 09:57 |
| mort | more and less ethical | 09:57 |
| ogra | i wouldnt work for google (i declined often enough ...) | 09:57 |
| rs2009 | mort: many of your arguments against snaps are now invalid (the startup time is much faster with the different compression algorithm, the size for many snap packages is smaller than those for regular APT and flatpak packages etc) | 09:57 |
| mort | you think google's global surveillance network is okay because that's how they make money | 09:57 |
| mort | that makes your opinion on ethics irrelevant in my book | 09:57 |
| ogra | no, but it is not my job to regulate them ... thats a matter of having laws against it | 09:58 |
| rs2009 | also, upgrading Ubuntu with snaps installed is way easier than upgrading Ubuntu with PPAs added | 09:58 |
| ogra | google makes money because you use their products ... | 09:58 |
| ogra | if you really feel hats morally wrong, dont use them | 09:58 |
| mort | but you wouldn't support laws regulating their behavior if you think their behavior is ethical and unproblematic | 09:58 |
| mort | OH | 09:59 |
| ogra | its capitalism ... | 09:59 |
| mort | I suppose I should quit my job then | 09:59 |
| mort | because we use google for our email | 09:59 |
| ogra | see | 09:59 |
| ogra | and you even pay them | 09:59 |
| ogra | i guess | 09:59 |
| mort | probably | 09:59 |
| mort | so your solution to systemic issues are: | 10:00 |
| ogra | unlike google canonical releases all their source code ... for the bits it can not release it puts out enough documentation that something like https://forum.snapcraft.io/t/announcing-project-kebe-open-source-snap-store-start/25088 is possible | 10:00 |
| mort | just don't use products from companies which does anything unethical and don't work for companies which does business with any companies which does anything unethical | 10:00 |
| mort | if I did that I literally couldn't participate in society | 10:00 |
| mort | do you think that's realistic | 10:01 |
| ogra | probably ... | 10:01 |
| mort | and if you use any products from an unethical company you forfeit your right to complain about that company | 10:02 |
| rs2009 | mort: Canonical released the source code for Launchpad long ago when people were complaining about it not being open-source | 10:02 |
| mort | rs2009: yeah, that makes sense, because public pressure is actually one of the things which can make companies change | 10:02 |
| mort | but ogra is arguing against the concept of criticizing companies | 10:02 |
| ogra | mort, not really | 10:03 |
| rs2009 | mort: what was the benefit to open-sourcing it? | 10:03 |
| mort | well for one there's one less proprietary service ubuntu users rely on? | 10:03 |
| ogra | i'm not talking against free speech 🙂 | 10:03 |
| mort | ogra: you're saying I shouldn't criticize canonical, I should either use ubuntu and shut up or not use ubuntu and shut up | 10:04 |
| mort | same with google, I should either use google products and shut up or not use google products and shut up | 10:04 |
| ogra | huh ? | 10:04 |
| rs2009 | mort: hardly anyone contributed to Launchpad after Canonical open-sourced it, nor did anyone even fork it | 10:04 |
| ogra | i never said anything like that | 10:04 |
| mort | then what you're saying is incoherent | 10:04 |
| mort | > google's behavior is ethical because it makes them money; > it is not my job to regulate them ... thats a matter of having laws against it; > if you really feel that's morally wrong, dont use them | 10:05 |
| ogra | i'm saying that the world is not black or white and that you should take into account that there must be a business model somehow if companies want to pay their devs | 10:05 |
| mort | I can't read this as anything other than "don't complain about companies" | 10:05 |
| ogra | and that some are more open and others are not | 10:06 |
| mort | dude, you literally don't think it's unethical to build a global surveillance network for profit | 10:06 |
| mort | purely because it makes money | 10:07 |
| ogra | depends how you use it | 10:07 |
| mort | it really doesn't | 10:07 |
| ogra | if you make the profit flow back to the people that you benefitted from to build it, if you make it improve society etc ... | 10:09 |
| mort | rs2009: anyways, if you're against the concept of open source unless it brings practical benefits to the authors of the software then a lot of software probably shouldn't be open source in your eyes | 10:09 |
| mort | I kind of view it as a good in and of itself that a piece of software is open-source | 10:10 |
| rs2009 | mort: the problem is that the Snap Store is too hard for the devs to open source (unless you want Canonical to release their password and API keys for libs like AWS S3) | 10:11 |
| mort | no | 10:11 |
| mort | I would actually be very surprised if canonical stores their API keys in the source code | 10:11 |
| mort | usually you read it from some config file or environment variables or something | 10:12 |
| rs2009 | the open-sourcing of Launchpad didn't help pretty much any regular Ubuntu user | 10:13 |
| mort | so? | 10:14 |
| ogra | anyway, my point initially was that canonical opensources everything it develops and documents the bits it does not opensource to enable people to re-implement them on their own | 10:14 |
| rs2009 | mort: just wondering, why aren't you complaining that the source code for the Ubuntu and Debian APT archives aren't released? | 10:14 |
| ogra | being an infrastructure company it will indeed to open up the implementation details of the infrastructure it makes money from | 10:15 |
| ogra | s/to open/not open/ | 10:15 |
| mort | rs2009: my understanding is that apt arcives are literally just an apache file server | 10:15 |
| mort | that's already open source | 10:15 |
| mort | apt repos* | 10:15 |
| ogra | same for the snap store ... its a web server, some python and a database | 10:16 |
| mort | and there's no reason for that python code, the database schema, etc to not be open source | 10:16 |
| ogra | what is unreleased is the glue between them, but it is well enough documented that people implement their own copy of it | 10:16 |
| ogra | mort, to what benefit ? | 10:17 |
| rs2009 | mort: then why isn't the source code for the APT repos too not released? (they too are made up of a web server, some python and a database) | 10:17 |
| ogra | mort, to push fragmentation and insecure packages like flatpak ? | 10:17 |
| mort | ogra: fragmentation and insecure packages? Wat | 10:17 |
| mort | how would an open source snap back-end infrastructure cause fragmentation and insecure packages | 10:18 |
| ogra | mort, while flatpak has some similar security bits to snaps ... there is nothing that enforces them, so 90% of flatpaks do not enable them | 10:18 |
| mort | I think you mixed up your arguments, this is an argument against the idea of letting the user add their own repos, not an argument against open source back-end infrastructure | 10:18 |
| ogra | mort, every single upload to the snap store undergoes a deep security review | 10:18 |
| rs2009 | mort: I guess you thought that people manually updated the dist files and uploaded the debs everytime they were generated in Launchpad to archive.ubuntu.com | 10:18 |
| mort | ogra: sure? | 10:18 |
| ogra | yes | 10:19 |
| mort | I literally don't understand why you're saying this | 10:19 |
| ogra | to point out that fragmentation breaks security | 10:19 |
| mort | but why are you talking about fragmentation all of a sudden | 10:19 |
| ogra | i'm trying to point out why there is/needs to be a centralized snap store | 10:20 |
| mort | yes but that wasn't the argument we were having | 10:20 |
| rs2009 | mort: well, I guess you only care about the Snap server not being open-source as it's one of the hottest topics on r/linux | 10:20 |
| ogra | it is part of the reason why the glue is not public | 10:20 |
| mort | I think there should be a way to configure extra repos but we were talking about how the back-end infrastructure is proprietary now, which isn't related to whether or not you can add your own repos | 10:21 |
| mort | rs2009: I prefer open-source software to proprietary software. This shouldn't be controversial. | 10:21 |
| rs2009 | mort: reposting this: then why isn't the source code for the APT repos too not released? (they too are made up of a web server, some python and a database) | 10:22 |
| mort | rs2009: I haven't looked too much into it, but I would actually be surprised if the system debian uses to build its packages and generate an apt-style folder structure isn't open-source | 10:23 |
| rs2009 | mort: well, many of the scripts which connect to their build servers simply aren't public | 10:24 |
| mort | I don't know whether that's true or not, but if you have some articles or something detailing the closed parts of debian's infrastructure I would actually be interested to read it | 10:27 |
| rs2009 | mort: well, I think you should ask this question in #launchpad (where you'll get answers from Launchpad's maintainers) | 10:28 |
| mort | for me it looks like they have buildd which is used by debian, and reprepro which is more aimed at people who aren't debian creating their own repos | 10:31 |
| mort | not entirely sure what's missing | 10:32 |
| rs2009 | well, the people in #launchpad can answer your question better | 10:35 |
| mort | well you brought it up | 10:35 |
| mort | I'm just asking you to support your claim that there's anything significant in debian's back-end infrastructure that's closed | 10:35 |
| mort | or, comparable to the closed parts of snap's back-end; whether that's significant or not is obviously more subjective | 10:36 |
| rs2009 | mort: you asked if it was possible for me to send anything that supports what I said. Like I said earlier, this topic is not frequently discussed, so you can confirm what I said with the devs in #launchpad | 10:37 |
| rs2009 | back to my original question: was wondering if any of the old Nux docs were archived? | 10:38 |
| ogra | i think Nux was only a very short lived thing ... and was not used for very long | 10:38 |
| ogra | https://launchpad.net/nux ... | 10:39 |
| mort | anyways | 10:40 |
| mort | for everything ubuntu still has apt packages for, I wish the apt packages were kept up to date | 10:40 |
| mort | that shouldn't be controversial | 10:40 |
| ogra | but they are not up to date | 10:40 |
| mort | exactly | 10:40 |
| ogra | and thats the point of snaps 🙂 | 10:40 |
| mort | so you're literally admitting that the point of snaps is to sabotage apt packages | 10:41 |
| ogra | (because it is extremely hard to keep them up to date in the archive) | 10:41 |
| ogra | no, it is to overcome their limitations | 10:41 |
| mort | how is it so hard? | 10:41 |
| mort | don't you get most of them from debian anyways | 10:41 |
| ogra | yes, but they need to build against the dependencies | 10:42 |
| ravage | mort, i know this is not really the point here anymore but nodejs offers its own deban packages. so if you dont want to use the snap use their deb packages | 10:44 |
| ogra | mort, debian packages often need certain versions of libs ... most of the time these libs are not available in the version you need in an old archive ... so you cant "just build" new software for universe without bumping them to a new version ... | 10:45 |
| ogra | ... which in turn might break other packages that are not compatible with the newer libs | 10:46 |
| ogra | a distro is like a clockwork, you cant just randomly replace gears | 10:47 |
| mort | I'm aware of that, building a complete linux system is work | 10:47 |
| ogra | snaps solve that but providing rolling versions of i.e. GTK/GNOME libs and Qt libs your app can link against | 10:47 |
| ogra | through frameworks | 10:47 |
| ogra | or if you can not/do not want to use these frameworks you can bundle your own libs | 10:48 |
| mort | yeah, snap solves it by installing 100 different versions of qt and gtk and everything else onto the user's machine, most of which have security issues or other bugs | 10:48 |
| ogra | again ... not black and white 🙂 | 10:48 |
| mort | well, it's how it works isn't it | 10:49 |
| ogra | not really | 10:49 |
| ogra | if you have a security issue that allows an attacker to take over the host, thats not really critical in the snap context for example | 10:49 |
| mort | it is | 10:49 |
| mort | snaps generally don't use confinement | 10:50 |
| ogra | since what you could take over here would only be the readonly app environment, never the host | 10:50 |
| ogra | WHAT !?! | 10:50 |
| mort | nah | 10:50 |
| ogra | who told you that ? | 10:50 |
| mort | my own experience | 10:50 |
| ogra | every single snap des | 10:50 |
| mort | well | 10:50 |
| mort | "classic" confinement | 10:50 |
| mort | where they have full filesystem access | 10:50 |
| ogra | aha | 10:50 |
| ogra | classic is special and needs a full review by the ubuntu security team before you can even upload it | 10:51 |
| ogra | (and is extremely hard to package= | 10:51 |
| ogra | ) | 10:51 |
| ogra | 98% of snaps are not classic | 10:51 |
| ogra | and the 2% that are underwent a long winded review and *must* come from an upstream ... and need to fulfill a certain set of criteria | 10:52 |
| mort | I have this experience relatively frequently: 1) run some command I don't have; 2) command-not-found tells me to install the snap; 3) I try to install it with snap; 4) snap tells me it's using classic confinement and that I should be very careful with it; 5) I try to figure out who packaged it; 6) I find out it's some random person or group I don't | 10:52 |
| mort | know anything about and have no reason to trust | 10:52 |
| ogra | https://forum.snapcraft.io/t/process-for-reviewing-classic-confinement-snaps/1460 | 10:53 |
| ogra | all publically documented btw | 10:53 |
| ogra | also freel free to look at all teh snaps that fail security review on upload https://forum.snapcraft.io/c/store-requests/19 | 10:54 |
| ogra | (and need a special review) | 10:54 |
| ogra | ... and this happens literally on every upload | 10:54 |
| rs2009 | ogra: Nux was actually the core of Unity7 (and is still being used and maintained) | 10:55 |
| rs2009 | wanted to make a few changes and couldn't find any docs related to Nux's widgets in the Ubuntu Wiki | 10:55 |
| ogra | rs2009, except that the upstream maintainer gave up on it AFAIK | 10:55 |
| rs2009 | ogra: yep, that's true | 10:56 |
| ogra | (but you shoudl be able to contact neil thrugh LP) | 10:56 |
| rs2009 | most of Unity7's elements like the dash and launcher use Nux though for the blur and other features | 10:56 |
| rs2009 | ogra: Neil doesn't seem to have been active since late 2010 | 11:03 |
| ogra | mort, btw, regarding the numbers of different confinement types: https://snapstats.org/confinements | 11:03 |
| mort | why are the numbers so fluctuating | 11:04 |
| ogra | i wonder the same ... would be a question for diddledani | 11:05 |
| ogra | probably the store query doesnt run very consistent or some such... they used to be less wiggly | 11:06 |
| ogra | either way, you can see the relation between strict and classic there | 11:06 |
| mort | is node strict? | 11:07 |
| ogra | nope, cant be strict and comes from a vetted publisher ... | 11:07 |
| ogra | (i use node in a lot of strict projects, but to use it as a system-wide interpreter it needs to be classic ... like a compiler etc) | 11:08 |
| mort | right | 11:09 |
| mort | those are the kinds of tools I've usually been told by command-not-found to download snaps of | 11:10 |
| ogra | which is fine, especially in case of node ... which is well maintained by the upsream | 11:10 |
| mort | well, snap doesn't seem to think so at least, it always says classic packages may put your system at risk | 11:11 |
| ogra | you can see if a publisher is vertted in the output of "snap info node" ... if there is a green check mark next to the publisher name, they have been verified to be the actual upstream | 11:11 |
| mort | yet it may put your system at risk | 11:12 |
| ogra | thats a general thing for classic snaps since they *are* not confined we need to make the user know | 11:12 |
| ogra | perhaps the message should be worded less scary 🙂 file a bug | 11:12 |
| mort | it's a very strange user experience at least | 11:12 |
| mort | > node | 11:12 |
| mort | > hey you should run `snap install node` | 11:13 |
| mort | > snap install node | 11:13 |
| mort | > OMG this package is dangerous and puts your system at risk, if you're really really sure run `snap install --classic node` | 11:13 |
| ogra | theoretically *every* univers package should spill such a warning too ... nothing in there gets tested, they just get synced from debian blindly | 11:13 |
| mort | there's a long-standing assumption in the linux world that your distribution is trusted | 11:14 |
| ogra | ... like add-apt-archive should tell you that ou give the PPA owner full root access to your machine | 11:14 |
| mort | add-apt-repository should absolutely come with more warnings yeah | 11:14 |
| ogra | but today only snap install --classic does that | 11:15 |
| ogra | while technically applicable of all the other use cases too | 11:15 |
| mort | but `snap install --classic` doesn't differentiate between trusted classic packages and untrusted classic packages | 11:15 |
| ogra | s/pf/for/ | 11:15 |
| ogra | there are no untrusted classic packages | 11:15 |
| mort | well all of them warn you that they may harm your system, which means they're not trusted | 11:15 |
| ogra | right, which s nonsense as i said above, the message should be re-worded | 11:16 |
| mort | I'm pretty sure I was once asked to install a classic confinement package from snapcrafters | 11:16 |
| ogra | they are trusted but will not use any confinement and have full access to your system ... yet their publishers are vetted before upload is allowed | 11:16 |
| mort | which seems to be a pretty loosely organized group of people who make snap packages | 11:17 |
| ogra | but that would be a pretty long essage to print 🙂 | 11:17 |
| ogra | snapcrafters are truted packagers that have a longer record of packaging before they can joind the group ... | 11:17 |
| ogra | it is the MOTU of snaps | 11:17 |
| ogra | like MOTU cares for universe, they maintain snaps as a "distro team" | 11:18 |
| ogra | (every commit at https://github.com/snapcrafters/ gets team reviewed) | 11:19 |
| mort | would be useful if this kind of information was available anywhere when trying to decide whether to trust a package which may harm your system or not | 11:20 |
| ogra | 👍 | 11:20 |
| mort | now, I have a question | 11:21 |
| mort | is it ubuntu's goal that other distros should be able to adopt snaps? | 11:21 |
| mort | I mean in the same way that ubuntu is, where it's trying to be a pretty core part of the experience | 11:22 |
| ogra | we have a few people only focusing on cross distro support, so indeed | 11:22 |
| ogra | but nobody can dictate distros to include snaps | 11:22 |
| mort | do you experience that many other distros are interested in deeply integrating such a canonical-centric product where the only one who can respond to a security incident is canonical and the only one who can accept or remove packages is canonical? | 11:23 |
| ogra | but in general snaps work on roughly 30 distro types | 11:23 |
| ogra | there are a few | 11:23 |
| ogra | manjaro for example includes snapd by default | 11:24 |
| mort | but is their goal also to get users to use snaps for everything, making snaps the preferred way to get development tools, web browsers, gui apps, etc | 11:24 |
| ogra | it would be great if more adopted it ... but there is that troll army that pushes against it | 11:25 |
| mort | here we go again | 11:25 |
| mort | all concerns regarding snaps is just FUD from trolls | 11:25 |
| mort | if the situation was turned on its head, and red hat made snaps, would canonical really have no qualms at all about deeply integrating a packaging system where canonical has no agency to respond to security incidents or upgrade packages or anything like that | 11:26 |
| ogra | mort, many are | 11:26 |
| ogra | dunno ... the point is that most people do not know that flatpak was redhats reaction on the already cmmercially successful snaps ... | 11:27 |
| ogra | snaps are years older | 11:27 |
| ogra | you could even buy IoT gateways running the snap only based Ubuntu Core a year before flatpak existed | 11:28 |
| mort | ok but this is just a lie | 11:28 |
| mort | flatpak is from 2015 | 11:29 |
| ogra | from 2016 | 11:29 |
| mort | "Initial releaseSeptember 2015; 6 years ago" | 11:29 |
| mort | probably under the name xdg-app | 11:29 |
| ogra | the same week we announced desktop support in snaps redhat announced flatpak as a packaging system | 11:29 |
| ogra | i remember that very well | 11:29 |
| ogra | yes, there was xdg-apps before ... maintined by a single guy ... not very popular | 11:30 |
| mort | and you thought they just, what, threw together flatpak in a couple of days in order to be able to announce it the same week as canonical announced snaps | 11:30 |
| ogra | no, they renamed xdg-apps i wrote so above when we started talking 🙂 | 11:30 |
| mort | do you fault red hat for wanting a packaging system that's less canonical-centric | 11:31 |
| ogra | either way ... flatpak does not even remotely have the snap feature set ... it would/could never be a replacement for snaps | 11:31 |
| ogra | it is a nice tool to deliver some desktop apps, but that is about it | 11:31 |
| mort | so? | 11:31 |
| ogra | snaps are way more | 11:32 |
| mort | you're the one who brought up flattpak | 11:32 |
| ogra | no, i brought up trolling 🙂 | 11:32 |
| mort | and flatpak | 11:32 |
| mort | I don't know why you brought up flatpak | 11:32 |
| Jeremy31 | Sounds like competition | 11:33 |
| mort | like, it's a fun story that redhat rebranded their existing snap-like project when snap launched, but I don't understand what makes it relevant to the discussion | 11:33 |
| ogra | snap like ?!?! | 11:33 |
| mort | yes | 11:33 |
| ogra | snap is a packaging system ... you can package kernels, servers etc ... flatpak is a desktop app delivery mechanism ... | 11:34 |
| ogra | there isnt even remotely a relation ... beyond the fact that both use containerization | 11:34 |
| mort | why would anyone make a snap of a server system? | 11:35 |
| ogra | mort, see Ubuntu Core ... | 11:35 |
| mort | I wouldn't want to have each new deployment of my server system go through canonical | 11:35 |
| mort | I would want to be able to just deploy a new version of my server software | 11:35 |
| ogra | theer also are tons of server snaps in the store | 11:35 |
| mort | oh, like nextcloud and such | 11:35 |
| ogra | thats one example, yeah | 11:36 |
| mort | yeah that makes sense, there the server software is the product that the user should install themselves | 11:36 |
| mort | I was thinking about the case where you run a server and write software for that server | 11:36 |
| ogra | you can do that too | 11:36 |
| mort | yeah but you wouldn't want to | 11:36 |
| ogra | i do that all the time here at home | 11:37 |
| ogra | as do our customers | 11:37 |
| mort | and all your changes to your server system goes through canonical..? | 11:37 |
| mort | what if you need a quick fix for something | 11:37 |
| ogra | i commit a change in my git tree ... the rest is automatic | 11:38 |
| ogra | then i switch my QA machine to the edge channel and test the released snap from that gommit | 11:38 |
| ogra | *commit | 11:38 |
| ogra | if it is fine, i release it to the stable channel with a click or single cmdline call and my servr machine picks it up | 11:39 |
| mort | what if it's a server I don't want available to everyone else, either because it's just some personal thing which nobody else would want to use or because it's some proprietary thing | 11:39 |
| ogra | i mark my snap as private and nobody else can see it | 11:39 |
| mort | seems like an extremely weird workflow | 11:40 |
| ogra | if i do not want to go through canonical at all, i make a little script that installs th snap with the --dangerous flag (to tell snpd it does not come from a store) | 11:40 |
| mort | is it any more dangerous to install a snap from a snap file than to install an unvetted snap from the snap store? | 11:41 |
| ogra | depends | 11:41 |
| mort | on what | 11:41 |
| ogra | if your locally built snap is --classic | 11:41 |
| ogra | 😉 | 11:41 |
| mort | well no | 11:41 |
| mort | it wouldn't be more dangerous to install an unvetted --classic snap from the snap store than to install it from a file | 11:42 |
| ogra | if it is strict it has to function within the limits of the snap interface system | 11:42 |
| mort | there just (allegedly) aren't unvetted --classic snaps on the store as a matter of policy | 11:42 |
| ogra | there are no unvetted classic snaps in the store 🙂 | 11:42 |
| mort | that's what I just said | 11:42 |
| ogra | right, i was typing while you hit enter 😉 | 11:43 |
| mort | anyways | 11:43 |
| mort | what does this have to do with trolls again | 11:43 |
| Jeremy31 | Everything involves the trolls | 11:44 |
| mort | I'm sure a flatpak evangelist could come up with ways in which they could make a flatpak out of their server software and run that on their server, using a similar workflow to yours | 11:44 |
| ogra | not really | 11:44 |
| mort | why do you say that | 11:44 |
| ogra | because flatpack is not designed like that | 11:45 |
| mort | how so | 11:45 |
| ogra | it needs desktop integration | 11:45 |
| mort | does it | 11:45 |
| ogra | yes | 11:45 |
| mort | what does that even mean | 11:45 |
| mort | flatpak needs an X server? or | 11:45 |
| ogra | (which is the reason something like silverligt exists ... because you can not cover the low level with flatpak) | 11:46 |
| ogra | yu can not package system serrvices as flatpak ... nor can you package a rootfs as flatpak ... or a kernel ... or a bootloader | 11:46 |
| ogra | (or something that reads your sensors or an AP or your industrial controller software) | 11:47 |
| mort | is there no such thing as full filesystem access in flatpak? | 11:47 |
| ogra | fltapak is for desktop apps ... and it is good at that | 11:47 |
| mort | but if you can have filesystem access then you can read IIO devices | 11:48 |
| ogra | but it is not much more than that wihout changing it by 180° | 11:48 |
| mort | you aren't substantiating anything you're saying | 11:48 |
| mort | what mechanism makes it impossible to read /sys/bus/iio or /sys/class/gpio or the like from within a flatpak-packaged application | 11:49 |
| ogra | no mechanism ... and you can have a gui app that reads these just fine | 11:50 |
| ogra | you can not have a system service like that though | 11:50 |
| mort | then what prevents you from packaging an app which doesn't create a window | 11:51 |
| ogra | nothing ... but it would be useless | 11:51 |
| mort | or connect to an X or wayland server | 11:51 |
| mort | why | 11:51 |
| ogra | what wuld it do ? | 11:51 |
| mort | whatever it wants? | 11:51 |
| ogra | how | 11:51 |
| mort | if you have filesystem access you can do almost anything | 11:51 |
| ogra | it can not run on its own ... there is no cli support afaik | 11:51 |
| mort | uh there's `flatpak run` which works from the cli | 11:52 |
| ogra | you need to launch it through a .desktop file | 11:52 |
| ogra | oh have they grown that ? it was not there the last time i looked | 11:52 |
| ogra | (which was admittedly quite a while ago) | 11:53 |
| ogra | stil does not help you with yur headless AP out in the wods | 11:54 |
| ogra | *woods | 11:54 |
| mort | so I looked at their git repo and the "run" subcommand was there at least when it was rebranded from xdg-app to flatpak | 11:57 |
| mort | so maybe some early development version of xdg-app was missing "run", but flatpak has always had it | 11:58 |
| ogra | interesting | 11:58 |
| ogra | either way, my comment still stands ... wont help you on an IoT device or industrial controller or iin a cloud instance | 11:59 |
| mort | but I keep asking, what exactly is the mechanism which prevents you from using flatpak for that | 11:59 |
| ogra | that your only access to the system is through graphical portals if you actually want to run confined doesnt help either | 11:59 |
| mort | but we're not talking about being confined, you'd presumably have filesystem access | 12:00 |
| ogra | you could surely hack together some systemd usnit that calls flatpak run ... | 12:00 |
| ogra | confinement is the core of filesystem access | 12:00 |
| ogra | at least in snaps ... | 12:00 |
| mort | well then confinement wouldn't even be an issue if you can still have access to sysfs and whatever | 12:01 |
| mort | idk if flatpak lets you bind to network sockets but I assume there's some mechanism to do so | 12:01 |
| ogra | in snaps this access id fully mediated | 12:01 |
| ogra | though an interface | 12:01 |
| ogra | *through | 12:01 |
| ogra | ... by the kernel ... | 12:02 |
| mort | everything's mediated by the kernel, but I assume you're referring to the various namespacing features | 12:02 |
| ogra | no, to seccomp and apparmor | 12:03 |
| ogra | but yeah, namespaces are in use as well ... as are cgroups | 12:03 |
| mort | honestly it just sounds that you're salty that redhat doesn't want to cede all control of their distro over to canonical | 12:04 |
| ogra | lol | 12:04 |
| ogra | i dont care about redhat | 12:04 |
| mort | yet you focus so much on flatpak | 12:04 |
| ogra | i do care about the fact that the trolling started shortly after flatpak was anounced and i find that very depressing | 12:05 |
| mort | I'm not convinced what you're referring to as "trolling" actually is trolling | 12:05 |
| mort | snaps suck for all kinds of really good reasons | 12:05 |
| ogra | the two mechanisms could live side by side happily and it makes me sad to see so much FUD being spread ... and that this drowns all the cool bits and pieces snaps provide | 12:05 |
| mort | there is no FUD | 12:06 |
| mort | snaps just have serious problems | 12:06 |
| ogra | snaps have a few problems with the desktop implementation that are constantly fixed by a big team of developers | 12:06 |
| mort | I know you don't care about open source but the back-end not being open source is a real thing for many people who care about open source | 12:06 |
| mort | the fact that canonical controls the only snap repo is another serious problem | 12:07 |
| mort | that distros can't really add their own snap repos | 12:07 |
| ogra | i do care about opensource, not sure what makes you think i dont ... i'D work for google, aplle or MS if i wouldnt | 12:07 |
| mort | well you don't seem to think it's valuable that things are open source | 12:07 |
| mort | a lot of people don't like mandatory auto-updates | 12:08 |
| ogra | all my work is opensource, all work i have ever done for canonical is opensource | 12:08 |
| ogra | you can manage your updates just fine, you can hold them, and schedule them ... there is even a gnome extension for that | 12:09 |
| mort | yet you think it's good that all snap activity goes through a proprietary front-end interacting with a proprietary back-end | 12:09 |
| ogra | eventually you *will* get the new version though, since we guarantee upstreams that their users will not be left on insecure old version | 12:09 |
| mort | you can't have an apt-style experience where all your packages are updated when you tell them to update | 12:09 |
| mort | right | 12:10 |
| ogra | because snap is not deb | 12:10 |
| mort | so mandatory auto-updates | 12:10 |
| mort | that's what I said | 12:10 |
| ogra | yes, but you have all the abilities to do then at a convenient time or hold them back until it fits | 12:10 |
| mort | except for if the mandatory auto-update hits at an inopportune time | 12:10 |
| ogra | yet there are no security cameras out there running Ubutu Core that could be part of the next big botnet attack | 12:11 |
| ogra | then why did you pick that time, you have two months to do the upgrade | 12:11 |
| mort | I don't care about the IoT use-case, I use yocto not ubuntu core | 12:11 |
| mort | essentially, you're saying the user's machine is really canonical's machine, canonical should be able to dictate that you have to upgrade to a new version which you may not want | 12:11 |
| ogra | (btw thare are about 100 SoC supported by canonical ... we just do not provide reference images for each and ever of them) | 12:12 |
| ogra | since you mentioned there are no SoCs) | 12:12 |
| ogra | no a users machine is the users' ... but you should not stay on insecure versions of software | 12:12 |
| mort | https://ubuntu.com/core/docs/supported-platforms there are 7 there, 4 of which are raspberry pi and one is generic x86 | 12:13 |
| ogra | yes, with well tested reference images ... | 12:13 |
| ogra | to test out UC | 12:13 |
| mort | you said ubuntu core supports 100 SoCs | 12:13 |
| mort | but that's the list of supported platforms | 12:13 |
| mort | their word | 12:13 |
| ogra | no, that is the list of reference test images | 12:13 |
| mort | no, that's the list of supported platforms | 12:13 |
| mort | everything on the page says "supported platforms" | 12:14 |
| ogra | https://ubuntu.com/blog/nxp-and-canonical-to-demo-ubuntu-core-on-the-ls1043a-at-embedded-world | 12:14 |
| ogra | just one example | 12:14 |
| mort | great | 12:15 |
| ogra | there are also a lot of qualcomm SoCs nvidia etc etc | 12:15 |
| mort | but clearly it's not a supported platform | 12:15 |
| ogra | it definitely is | 12:15 |
| mort | then why isn't it in the list of supported platforms | 12:15 |
| ogra | you just have to roll the images yourself or engage with canonical ... we cant provide demo images for every SoC | 12:15 |
| mort | but if it's a supported platform, why isn't it in the list of supported platforms | 12:16 |
| ogra | https://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ | 12:16 |
| ogra | here are a few others | 12:16 |
| ogra | (and three levels up there are more) | 12:16 |
| mort | these are all great but they're clearly not supported platforms | 12:16 |
| mort | they may be platforms ubuntu core happens to work with | 12:17 |
| ogra | they use a supported kernel and rootfs ... | 12:17 |
| mort | yet they're not supported platforms | 12:17 |
| ogra | sure they are due to that fact | 12:17 |
| mort | then where on the list of supported platforms are they | 12:18 |
| mort | another thing, when I last looked into ubuntu core, I found out that you actually can't update the version of ubuntu the device is running | 12:19 |
| mort | that seems wild to me | 12:19 |
| mort | just running 16.04 in 2032 | 12:19 |
| ogra | on the list you can get when engaging with canonical ... or on the list someone on forum.snapcraft.io can give you if you ask about rolling your own images | 12:19 |
| mort | maybe add the other supported platforms to the list of supported platforms | 12:19 |
| ogra | yeah, i'm lazy and havent moved them to UC 18/20 ... would be an hour of work i didnt invest | 12:19 |
| mort | I wasn't talking about your images specifically | 12:20 |
| ogra | well, supported on that webpage means that each sigle update of each single snap is fully tested and QAed against that image, as i said, we cant do that for every supported SoC but that doesnt mean the others can not be run with supported snaps | 12:21 |
| mort | just that, from what I understood, if you decide to build an IoT device on Ubuntu Core, you can never upgrade the ubuntu version on a device in the wild | 12:21 |
| mort | the only update mechanism is updating the snap | 12:21 |
| ogra | you can ... from UC20 on you can re-model to a new release | 12:21 |
| ogra | 16 and 18 did not support that, this is true | 12:22 |
| mort | ah | 12:22 |
| mort | I also understood that you're not allowed to run your own distribution server, you *must* use canonical's, and if you want it to not be a public snap, you must pay canonical heaps of money | 12:22 |
| ogra | heaps ... | 12:23 |
| mort | I don't remember the exact figure, just that I thought it sounded like a lot for something which seems obvious | 12:23 |
| ogra | $15k/year for an IoT store ... | 12:24 |
| mort | right | 12:24 |
| mort | that's quite a lot | 12:24 |
| ogra | which is rather cheap | 12:24 |
| ogra | not really | 12:24 |
| mort | it is | 12:24 |
| mort | and you still don't even get to run your own upgrade server | 12:24 |
| mort | (iirc) | 12:25 |
| ogra | how much do you pay for ... say a three headcount yocto team to keep your OS up to date and safe ? | 12:25 |
| ogra | you do | 12:25 |
| mort | oh don't get me wrong, $15k/year is cheap for an OS support team type thing | 12:26 |
| ogra | the store is your upgrade server ... you can use a snap proxy for in-house management ... you can use an air-gapped snap-proxy for full control ... (the systems and packages still need to auth against the central server, but nothign else) | 12:26 |
| mort | it's a whole lot to pay for the privilege of hosting your own server | 12:26 |
| ogra | its a bargain if you do not need to care for the OS at all and all your devs need to do is commit to git and trigger tests | 12:27 |
| ogra | you can fully focus on the apps | 12:27 |
| mort | but that's not what's being paid for | 12:27 |
| ogra | it is ... at least that is how the customers i work with see it | 12:27 |
| mort | it seems weird tho to have a cost structure where you pay for taking load off of canonical's servers and get nothing in return | 12:28 |
| ogra | peace of mind is what you get in return | 12:28 |
| ogra | a guarantee that your systems are always on and never fail | 12:28 |
| mort | do you get more peace of mind by running your own upgrade server than by using canonical's?? | 12:28 |
| ogra | (snaps have built-in rollback on failure, that includes kernel and rootfs) | 12:29 |
| mort | cool, so do all other decent iot upgrade systems | 12:29 |
| ogra | dunno, do you get more peace of mind runnign your critical infra on AWS ? | 12:29 |
| ogra | most companies do that today and save on maintaining their own datacenter | 12:29 |
| ogra | do they ? | 12:30 |
| mort | I would say there's a peace of mind benefit to running servers on AWS rather than having your own servers | 12:30 |
| ogra | i havent seen a builtin mechanism like that in yocto | 12:30 |
| ogra | you need to use something like mender, know what yu are doing and integrate it yourself | 12:30 |
| ogra | or pay mander | 12:30 |
| ogra | not much different | 12:30 |
| ogra | just less work on your side if you pick core | 12:31 |
| mort | or use rauc or swupd | 12:31 |
| ogra | well, external tools you need to integrate yourself | 12:31 |
| mort | yes | 12:31 |
| ogra | so you nee in-house knowledge | 12:31 |
| mort | I'm not saying there's no value in having it integrated as a package | 12:31 |
| ogra | which many companies do not want to invest in | 12:31 |
| mort | I'm not even saying ubuntu core is a bad deal | 12:32 |
| mort | just that, specifically, $15k/year is a lot of money to pay to be allowed to take load off of canonical's servers | 12:33 |
| ogra | it isnt ... snaps and core are commercially well successfull ... and thanks to that canonical can provide the technology for free to the community, even for desktop snaps that are not relly producing a lot of return value | 12:33 |
| ogra | the 15k are for using a brand store (or leaf store) *on* canonicals servers | 12:34 |
| mort | oh | 12:35 |
| ogra | nothing takes load off | 12:35 |
| mort | so you don't even get to run your own upgrade server | 12:35 |
| ogra | you then *can* use the proxy variants for in-house | 12:35 |
| ogra | stuff | 12:35 |
| ogra | for th 15k you get storage, consulting, help with snap packaging and support | 12:36 |
| ogra | (and peace of mind ideed 😄 ) | 12:36 |
| mort | but why shouldn't you be allowed to just run your own upgrade server | 12:36 |
| ogra | you are ... remember the link above i gave ... there are companies runing their completely own infra and snapd | 12:37 |
| ogra | ... and they dont pay 🙂 | 12:37 |
| ogra | that same company actually also has yocto based systems using all apps as snaps o top | 12:37 |
| ogra | *on top | 12:38 |
| ogra | (there is snapd for yocto too ... ) | 12:38 |
| mort | I'm not sure which of the links you're referring to | 12:38 |
| ogra | https://forum.snapcraft.io/t/announcing-project-kebe-open-source-snap-store-start/25088 | 12:39 |
| mort | so you're saying ubuntu core allows you to point your system at a different snap store | 12:40 |
| mort | because that's not the impression I'm getting from any of the official docs | 12:40 |
| mort | they all talk about how you should get a brand store and whatever | 12:40 |
| ogra | it is opensource ! you can do whatever you want with it 😉 | 12:41 |
| ogra | and no, i'm not saying this is limitied to ubuntu core ... | 12:41 |
| ogra | you could run their snapd on your desktop and use their snaps from their store | 12:42 |
| mort | if we're talking about forking snapd and maintaining a fork which points to a different repo I'm assuming we're in a territory where system upgrades get harder | 12:43 |
| ogra | not harder than with the unpatched snapd | 12:43 |
| ogra | more insecure perhaps | 12:43 |
| mort | well it'd be as secure as your upgrade system is | 12:43 |
| ogra | nope | 12:43 |
| mort | s/system/server/ | 12:43 |
| ogra | as secure as your upload checks are | 12:44 |
| ogra | since the reviews and checks happen on upload | 12:44 |
| mort | what additional checks could canonical possibly do | 12:44 |
| mort | why would one want canonical to have to review our system image before we could deploy them to customers | 12:44 |
| ogra | not additional ... having another server means the other could do less | 12:45 |
| mort | ok, what sort of checks does canonical do | 12:45 |
| mort | when we're talking about the binary artefacts of an embedded system's software | 12:45 |
| ogra | we're talking about a well defined interface system ... some of them are harmless (lets say audio playback, that only givey you playback access to pulses socket) ... some are not .. these are blocked on upload | 12:46 |
| ogra | no matter what he artefacts are ... the access to the outside world is what matters | 12:47 |
| mort | what's the attack vector this is protecting against | 12:47 |
| mort | a rogue employee putting malicious code in their company's product? | 12:47 |
| ogra | taking over yur machine, spying on your security data (passwords etc) | 12:47 |
| ogra | seeing any data from other apps | 12:47 |
| mort | there are no other apps | 12:48 |
| ogra | talking to the outside world | 12:48 |
| ogra | ?? | 12:48 |
| ogra | sure there are ... | 12:48 |
| ogra | on every system | 12:48 |
| mort | we're talking about IoT devices where company A makes some hardware and puts their software on it and sells it to customers as an appliance | 12:48 |
| mort | you can't really protect against company A being malicious in that case | 12:48 |
| ogra | yeah, that system still runs systemd, or whatever else plumbing stuff | 12:48 |
| mort | if the systemd is malicious you have serious problems | 12:49 |
| ogra | sight | 12:49 |
| mort | wait | 12:49 |
| ogra | *sigh even | 12:49 |
| ogra | i mean the app accessing and manipulating systemd | 12:49 |
| ogra | you asked about "what other apps are there" | 12:50 |
| ogra | a snap can not do that by default | 12:50 |
| mort | but what is this protecting against | 12:50 |
| ogra | it can not take over yur machne | 12:50 |
| mort | what "your machine" | 12:50 |
| ogra | ... and hook it up to a botnet | 12:50 |
| mort | we're talking about software running on IoT devices as appliances where the same company makes the hardware and the system image | 12:50 |
| ogra | the host machine ... whatever that is | 12:50 |
| mort | what "host machine" | 12:51 |
| ogra | be it an IoT device or a desktop | 12:51 |
| mort | the smart fridge? | 12:51 |
| ogra | yeah | 12:51 |
| mort | but now you're just talking about sandboxing your software so that it can't do that much if it gets compromised | 12:51 |
| mort | what checks does canonical do | 12:51 |
| ogra | i'm talking about the interface system | 12:51 |
| ogra | canonical checks which interfaces to the outside world a snap attempts to use | 12:52 |
| ogra | and depending on the interface used, lets the snap into the store or not | 12:52 |
| mort | but that's an automated check? | 12:52 |
| ogra | *interfaces | 12:52 |
| mort | and, what | 12:52 |
| ogra | that bit is automated | 12:52 |
| ogra | if you fail that check you go into manual review | 12:52 |
| mort | are you protecting against if the company tries to install a malicious app using an interface it shouldn't to their own devices | 12:52 |
| ogra | right | 12:53 |
| ogra | thats independednt of "a company" thats a general thing for every snap | 12:53 |
| mort | but we're talking about IoT | 12:54 |
| ogra | snaps can use all the harmless interfaces just fine ... if they go beyond that you have to get approval from the ubuntu security team | 12:54 |
| mort | why do I need approval from the ubuntu security team to do what I want on my product | 12:54 |
| ogra | the target totally does not matter .. could be IoT, server, cloud or desktop | 12:54 |
| ogra | it is a general mechanism | 12:55 |
| mort | but we're talking about how this is a benefit in the context of IoT, not how it's a benefit in the context of desktop apps | 12:55 |
| ogra | for everyone ... even in brand stores | 12:55 |
| mort | and it sounds like you're saying that this protect the company with the IoT product from themselves | 12:55 |
| ogra | what is the difference ? | 12:55 |
| ogra | you want the apps properly secured in either use-case | 12:55 |
| ogra | and thus the same checks apply everywhere | 12:55 |
| mort | the difference here is that the authors of the software are also the ones selling the devices they ship with | 12:55 |
| mort | I'm not understanding what the threat model is | 12:56 |
| ogra | for a brand store customer it is easier to get things granted ... after all it is thir store | 12:56 |
| mort | is the threat model that the company writes malicious software for their own product | 12:56 |
| ogra | secure confinement of applications is the model | 12:56 |
| mort | is the threat model that the company writes malicious software for their own product | 12:56 |
| ogra | no | 12:56 |
| mort | "secure confinement of applications" isn't a threat model | 12:56 |
| mort | the "brand store customer" is the person who decided to buy a smart fridge which, under the hood, happens to run ubuntu core, but the customer has no interaction with any brand store of any kind | 12:57 |
| ogra | the threat model is a programmer accidentially allows access the app should not have and rips open an unexpected security hold | 12:57 |
| ogra | *hole | 12:57 |
| mort | right, so sandboxing | 12:57 |
| mort | is the solution to that | 12:57 |
| mort | we can have that without canonical's security team being involved?L | 12:58 |
| ogra | well it is not the sandboxing but the model of granting fine grained holes into that sandboxing | 12:58 |
| mort | yes | 12:58 |
| mort | but that's not something which requires involvement from a canonical security team | 12:58 |
| ogra | and these holes are either secured because the interface is properly mediated or they are broader and require security team review | 12:59 |
| mort | what even does a "security team review" mean | 12:59 |
| mort | what can you do with the binary artefact to determine that it's safe | 12:59 |
| ogra | nothing except for the bits granted by the interfaces | 13:00 |
| mort | so what value does the security team add | 13:00 |
| mort | in an iot context | 13:01 |
| mort | I understand the value in a desktop context where the person owning and operating the device and the person writing the software are different people and where I as a user of my laptop want to know that if some random developer wants to do something malicious they can't because their app is sandboxed | 13:01 |
| ogra | in an iot context with a brand store it reviews if your app really needs that much permissions, starts a conversation with the developer, reviews if you could not be better off using a different, more secure interface etc | 13:02 |
| ogra | in the end a brand store customer can always overrule this, the point is that you get a free security team review and probaly adjust your "best practices" to do it in a safer way | 13:03 |
| mort | but if their interaction is limited to what interfaces you use to interact with the outside world... | 13:03 |
| ogra | in th case of the global store you have to give very hard reasons and explanation about why you want to use that interface ... and might in the end not getting it granted but have to ask your users to connect it manually in a concious way of what they are doig | 13:04 |
| ogra | it is not different to androis or IOS in the end | 13:04 |
| mort | but like | 13:05 |
| mort | apple doesn't have to get permission from someone else to push out a new iOS version | 13:05 |
| ogra | (and eventually desktop snaps will have popups on first start asking you to allow access to i.e. your location) | 13:05 |
| mort | in an iot context, the person publishing the snap is in the role of Apple, not in the role of some app developer who wants to publish to the app store | 13:05 |
| ogra | not really | 13:05 |
| mort | yea really | 13:05 |
| ogra | in the iot context most customers use the OS as is | 13:06 |
| ogra | and focus on the apps | 13:06 |
| mort | imagine if apple had to get permission from canonical to push out a new iOS version | 13:06 |
| ogra | so it is exactly the same | 13:06 |
| ogra | but customers dont have to get such a permission | 13:06 |
| * ogra wonders what makes you think that | 13:06 | |
| mort | what makes me think what | 13:06 |
| mort | in the ubuntu core world, the core OS (in iOS, Darwin) would be provided by Canonical, and everything on top of that (the UI, the system services, whatever) would be provided as a snap by Apple | 13:07 |
| mort | right? | 13:08 |
| mort | Apple would be the company producing an IoT product which uses Ubuntu Core, so the lock screen and the home screen and the notifications menu and everything would have to be implemented as some snap which runs on boot | 13:09 |
| ogra | right | 13:10 |
| mort | right | 13:10 |
| mort | so Apple would have to publish iOS and have canonical review it | 13:11 |
| ogra | you get the bare rootfs and kernel ... and typically package the bootloader and image info in a so called gadget snap you maintin | 13:11 |
| mort | just seems weird | 13:11 |
| ogra | you also get full control over when something releases | 13:11 |
| ogra | and your snaps undergo upload checks ... for which you can get exceptions after an initial review/discussion | 13:12 |
| ogra | ... in case you use some more privileged interfaces | 13:12 |
| ogra | same model as IOS or android use | 13:12 |
| mort | except that you also use that model for the system, not just apps | 13:13 |
| ogra | apps run confined and have interfaces to talk to the outside world | 13:13 |
| ogra | well, the base snap (rootfs) has no restrictions ... neither does the kernel snap ... | 13:13 |
| ogra | both obviously run unconfined | 13:14 |
| ogra | and come from canonical | 13:14 |
| mort | yeah exactly, so "system" stuff, like the home screen in iOS, would be a snap | 13:14 |
| ogra | yeah, in case of UC it would be an app running on ubuntu-frame (Mir) | 13:15 |
| mort | huh, you still use mir for that do you | 13:15 |
| ogra | mir is used a lot in digital signage, yeah | 13:15 |
| mort | I heard that mir was not dead and was transitioning to become a wayland compositor but i didn't realize canonical actually used it in official products | 13:15 |
| ogra | well, ubuntu-frame 🙂 Mir is a dead name 🙂 | 13:15 |
| mort | how does it compare to, say, weston? | 13:16 |
| ogra | yep, lots of PoS systems and digital signage setup use it, often in tens of thousans of deployments | 13:16 |
| ogra | i never used weston ... but i built a lot of dig. signage and it it very easy to use there | 13:17 |
| mort | weston is also very easy to use, it shows wayland windows like you'd expect and that's kind of all a kiosk/embedded/signage display server needs to do | 13:18 |
| ogra | (only needs a few extra lines in your snapcraft.yaml to have it hok up to it ... building a kiosk that way is a breeze) | 13:18 |
| ogra | well, does wesn come with an OSK builtin ? | 13:18 |
| ogra | *weston | 13:18 |
| mort | not that I'm aware of; I wasn't thinking of that, I'm not working on devices with touch input | 13:19 |
| ogra | or the ability to easily set up multi-monitor etc | 13:19 |
| ogra | https://github.com/ogra1/electron-kiosk-wayland/blob/main/snap/snapcraft.yaml is a simple electron based kiosk in 100 lines of yaml running on top of ubuntu-frame | 13:21 |
| mort | I suppose I'd be most interested in how performance compares | 13:22 |
| mort | and things like memory use and system image bloat | 13:25 |
| ogra | there is no runtime difference ... startup depends on the compression you pick though | 13:25 |
| ogra | line 88 might interest you in the snapcraft.yaml above though ... and brings us back to how we started that conversation 😉 | 13:26 |
| mort | heh, well it probably makes a lot of sense when you're all in on snaps anyways | 13:38 |
| ogra | 🙂 | 13:40 |
| === JoeBk_ is now known as JoeBk | ||
| leftyfb | LinuxAspy = Kolusion | 16:05 |
| ogra | fun | 16:09 |
| ogra | i assumed some troll | 16:09 |
| leftyfb | You assumed correct :) | 16:27 |
| ogra | (i didnt assume Kolusion ... 🙂 ) | 16:28 |
| leftyfb | ogra: spent any time with the raspiOS on the cutiepi? | 20:22 |
| ogra | i played with the shipped and the first update images ... | 20:24 |
| ogra | the cutiepi-shell is essentially just a browser yet ... that will still take some time to get ready | 20:24 |
| ogra | and the raspios underneath is ... well ... an lxde desktop on a tiny screen | 20:25 |
| ogra | 22.04 runs great on it and is nicely touch friendly ... but is lacking itegration for the AD converter that manages the power and button ... tats what i'm poking at currently, getting a gnome extension working to have a battery meter and to get the power button events | 20:26 |
| ogra | (not knowing when that thing will shut down because the battery ran out is rather off-putting 🙂 ) | 20:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!