IRC logs for #baserock for Tuesday, 2015-12-22

*** edcragg has quit IRC01:33
*** gtristan has quit IRC06:32
*** gtristan has joined #baserock06:58
*** ctbruce has joined #baserock09:00
*** paulw has joined #baserock09:12
*** toscalix has joined #baserock09:28
*** paulw has quit IRC09:31
*** ssam2 has joined #baserock10:11
*** ChanServ sets mode: +v ssam210:11
*** gtristan has quit IRC10:25
*** gtristan has joined #baserock11:12
*** gtristan has quit IRC11:14
*** gtristan has joined #baserock11:17
ssam2distros devroom at FOSDEM looks fascinating this year: https://fosdem.org/2016/schedule/track/distributions/12:05
ssam2i'm not just saying that because i have a talk in there.. seems like it's almost all stuff beyond the model of traditional distros this year12:05
ssam2hopefully all the other devrooms are boring, otherwise i'm going to feel like i'm missing out by watching talks about distros all day ;-)12:06
persiaWe are fast approaching a post-distro world, where the term "distro" ceases to mean an authoritative source for the distribution of all software consumed by end-users.12:16
* ssam2 quotes that for the talk12:18
jmacsI think that's optimistic12:22
persiaPerhaps.  Perhaps the new distro is the "app store", broadly interpreted, so things like the cheeseship qualify.12:23
ssam2what's the cheeseship?12:24
ssam2I would mainly like to see a distro like the one I have now, except they stop trying to package apps and integrate xdg-app instead12:24
ssam2which seems like something that might actually happen!12:24
ssam2were I to contribute with package stuff for said distro, i would also prefer it used a declarative packaging format instead of .spec files, but that's more of a long shot :-)12:25
persiaSorry: cheeseshop: a place where many python packages exist12:30
persiaCPAN would be another example12:30
persiahttps://wiki.python.org/moin/CheeseShop (except it isn't that secret)12:31
ssam2I tend to think that the language-specific package repos highlight flaws in the tooling of the mainstream distros, nothing more12:33
ssam2well, not just the tooling12:34
ssam2but my point is that importing stuff from pypi to the debian archive, for example, should not be so difficult as to require a complete reworking of what the word distro even means12:35
persiaTraditional distros suffer from several issues:12:47
persiaFirstly, it takes a long time for updated software to be in a distro, creating tension between upstream and distro because users complain upstream and consume distros12:47
persiaSecondly, distros have a hard time with coinstallable versions, which puts pressure on porting to current ABIs.  Unless everyone in the free software community is in sync, this ends up with a complex mess of which depends on what version of the other: for complex systems, it often means needing more than one version of an underlying library.12:48
persia(this is made more complicated by the first point, as an increasing number of upstreams validate against specific versions and then either bundle the validated versions or insist on building validated versions, making transitions more difficult)12:49
persiaThirdly, distro engineers have lost reputation: at one point they were wizards who could create an actual system from a collection of sources.  Now they are considered the tinkerers, and the creators of the sources the wizards: this leads both users and upstreams to work around distros, rather than with or within distros.12:50
persiaFourthly, the result of using a package-based distro to create a system is not deterministic, so that the result artifacts may not operate as expected, even if validated, unless one preserves the binary blob in question (which may not be possible to reliably rebuild).12:51
persiaFifthly, Different parts of consuming organisations (including individuals) define "support" differently: everyone wants absolute stability so that nothing unexpectedly doesn't work and nothing crashes; combined with all the newest features.  These lead to additional dissatisfactions with various distro's models for support.12:52
persiaAnd that there is variance in the model only encourages more workarounds by consumers that need something slightly different (as there is no wide consensus on what ought be "stable" and what ought be "featured").12:53
* persia stops ranting12:53
* persia also hopes that Baserock can be part of the total solution, as we grope towards it12:53
jjardonpersia: mmm, I think first 3 points, and probably 5, are not valid for all distros (like Arch)13:01
* gtristan hopes that application sandboxing can/will help to improve this situation13:01
ssam2arch distro engineers are definitely wizards going by the amazing quality of the Arch documentation :-)13:03
ssam2but, one reason I don't use Arch is that I'm still not quite ok with not knowing whether installing updates are going to bring security fixes, or weird UI changes13:04
persiajjardon: Looking at the Arch Linux "latest news", I see talk of dropping support for plasma 4 (item 5), an ABI transition (item 2), discussion of puppet 4.0 availablility 5 weeks ager release (item 1).  I suspect I could find the others if I looked past the first page of the wiki :)13:04
jjardonthe key point is that Arch try to not decide; they simply package what developers (upstream) release13:06
persiaOh, the discard corruption issue is item 3: as it was the arch packagers who chose the patchset with limited validation (and arch-local patches that "fixed" it)13:06
persiaYes, but packaging what upstream releases doesn't solve most of the problems I identify above.13:06
persiaI don't mean to insult arch: these issues are a side effect of the model, not of the intent of specific individuals or groups.13:07
gtristanjjardon, what I want: Run an LTS base system that is reasonably secure, gets me on the internet, etc... Run a bleeding edge version of the applications I want13:08
persiagtristan: That creates tension, because the authors of the bleeding edge applications want features from newer platform.13:10
jjardonpersia: first 3 issues doesnt exist in Arch: 1: the packages are getting updated the day are released, 1; they only suport the latest, so no "coinstallable problem" and 3: distro enginneers needs to do a much less work, as the distro is only s thin layer; patches and bugs go upstream13:10
persiaPlus, maintenance of old platform increases the total maintenance burden.13:10
gtristanpersia, which is why we need better design/solutions for application sandboxing13:11
persiajjardon: The need for coinstallable is a user issue: not supporting coinstallable is the failure of the distros.13:11
jjardongtristan: yeah, Android model; I think we are getting there13:11
persiareleasing "the day they are released", or at least within 5-6 weeks means the arch folk are on top of things, but it not being automated means that people will complain.13:11
gtristanI.e. I looked into distro-agnostic bundling for Glade for exactly that reason13:11
persiaAnd the lack of work done by distro engineers doesn't make them have more stellar reputations.13:11
gtristanthere is absolutely *no reason* that a user needs to have the latest GTK+ installed in /usr/lib, in order to run the bleeding edge of Glade13:12
persiaAgain, Arch is better than many: feel free to like it.  It's the centralised curated distro model that I claim is broken.13:12
gtristanalso it makes no sense to run Glade fro 5 years ago because it's installed on your system, you want to run it for the GTK+ app you're developing, probably against an unreleased yet API13:12
gtristanthese days too, disk space and bandwidth is relatively cheap13:13
gtristanwho cares if libreoffice is 200MB including all of it's dependencies, you only download it once until you download a new bundle13:14
persiaI care about efficiency.13:16
persiaI want small, efficient, systems, with minimal memory usage (so consistently ported apps), etc.13:16
persiaI want most of my stuff to use the *same* framework, so that it can be more responsive.13:16
gtristanNot for my desktop/laptop13:16
persiaI want longer battery life and less expensive devices.13:16
gtristanFor my embedded product I develop, sure13:16
persiaI care about these things for my desktop and laptop.13:16
jjardonpersia: Arch developers have good reputation; my point is that they are not in the middle between developer and user. At least not as much as other distros.13:17
persiaI may have memory measured in tens of gigabytes and storage measured in terabytes, but I intend to use that for something other than that people can't be bothered to port to a common ABI.13:17
gtristannot me, I want the best of both worlds, i.e. I want a 10 years maintained base system which has a paranoid policy about only introducing security patches13:17
persiajjardon: I agree with "not as much as other distros".  That they exist at all causes the issues I describe.  It cannot be helped.13:17
gtristanand I want to run the bleeding edge of the applications that I need to use13:17
jjardongtristan: not sure that's possible13:19
gtristanjjardon, OSX comes close with its bundles and frameworks, also you can do it on linux using AppImageKit13:20
gtristanjjardon, what becomes tricky is policy about what applications can access what resources and properly policing that13:20
jjardongtristan: what happen when you app depends in a new feature of systemd, for example?13:21
gtristanjjardon, what kind of app does that ?13:21
jjardongtristan: using systemd apis? gnome-logs, for example13:23
gtristanok but is that really an application ?13:23
gtristanthat should be part of your base system really13:23
gtristannobody really cares either, I can use a terminal and journalctl13:23
gtristanjjardon, most of what is "gnome core apps", you know excluding a couple of apps which are really apps, are just part of your base system; system configuration, silly clocks and stuff13:25
gtristannobody needs a bleeding edge of those13:25
jjardonit was only an example of an app using systemd directly to show the problem I exposed13:26
gtristanBut, if I can run a sandboxed evolution, firefox, libreoffice, apps I actually need to use, then I can run those13:26
gtristanjjardon, right, and I still dont believe it's an actual problem13:26
jjardonI think the other way around is where we are going today: you have a runtime that you can easily replace with new versions, and apps can choose which runtime they depend on13:28
jjardongtristan: evo can perfectly use some systemd api directly, if the devs decide to do so13:28
ssam2if sandboxing works well then I think the problem goes away, indeed13:28
ssam2jjardon: not if it is written to run in xdg-app13:28
gtristanalso, I may have the choice to build a "nicely integrated version of firefox which integrates with my gnome notifications service", but who cares about that, if I can run the one configured with --disable-system-integration but built "last week", I will surely prefer the latter13:29
ssam2jjardon: and it would be considered broken by users, because they'd tried to do stuff that broke out of the sandbox13:29
ssam2jjardon: and it's totally reasonable for the sandbox to deny access to my system logs, or anything else that I haven't *in advance* given it permission to read/write13:29
ssam2jjardon: which means that interface between sandboxed apps and the host system is NOT going to be easy to get right. but at least it's in progress13:30
ssam2*interfaces13:30
*** gtristan has quit IRC13:50
*** toscalix has quit IRC14:29
*** toscalix has joined #baserock15:06
*** gtristan has joined #baserock15:15
ratmice______gtristan: one resource access policy that actually made sense to me was the 'ask users what they think they are installing & what that entails', possibly at different times... so if a game entails full screen graphics, sound, thats all it gets, a user can then create 3 types of games such as {graphics, sound, networking} = "online game", {graphics, sound, networking, contacts.games} = "online game with friends"15:41
ratmice______I forget what it was that used this15:41
ratmice______capdesk15:45
gtristanratmice______, right, so the juice of this is the "E platform", which presumably one needs to write apps specifically for15:47
ratmice______I don't know if it had any mechanism where the application can annoy the user about stuff it wants but didn't get15:47
gtristanaccording to a quick glance at http://www.combex.com/tech/edesk.html15:48
ratmice______gtristan: probably yes, I'm only really familiar with it due to a comparison that was being made between it and one version of the android access policy model15:50
ratmice______and I think it's E-on-java which is a subset of java15:52
gtristanthat greatly simplifies the problem of sandboxing in general (i.e. inserting a trusted actor/"platform" between the OS and the apps which that platform hosts)15:53
gtristanof course, you dont hear people complaining that "I cant run your java app here because I'm stuck with an old version of /usr/lib/libglib.jar" :)15:55
persiaThat's because the java community long ago decided that bundling dependency binaries was normal and expected15:59
persiaWith the result that people who use other frameworks (e.g .NET) tease Java about requiring way too much RAM.15:59
*** ctbruce has quit IRC16:00
ratmice______right, even something like capsicum on linux is going to entail some amount of rewriting of your general c code, to disassociate identity from authority (without sandboxing everything)16:03
gtristanpersia, yes ironically so16:03
gtristaninstead they complain "This damn JVM causing OOM killing all my other processes !"16:03
gtristanhehe16:03
persiaRight, but the *cause* of the complaint isn't that different from "I have an old version of libglib.jar"16:04
gtristanpersia, it reinforces your argument that you want efficiency, I still believe that we can have "efficient enough" with bundling and sandboxing16:05
gtristannowhere near as bad as running a jvm16:06
gtristanan overhead in memory for the apps you want to run bundled, sure16:06
persiaAside from arguments about compiler optimisation for image size, I think it is the same problem.16:06
persiaThat C compiler maintainers tend to generate smaller memory footprints and Java compiler maintainers tend to optimise for throughput and execution speed is a separate issue.16:07
gtristanI just want those 2 things; long term support and stable OS in /usr, and bleeding edge versions of the apps I care about - not only from a user standpoint but also from a maintainer standpoint16:10
gtristanit's silly to ask people to run a risky bleeding edge OS just to run this week's build16:10
gtristanit's equally silly to exert pressure on distro maintainers to make this possible16:11
gtristanhence, bundling and sandboxing seems to be the right way forward, of course there is a cost16:12
ratmice______I'm not sure its helpful to differentiate bleeding edge user from maintainer16:17
ratmice______I mean ideally those are the people the 'maintainer' wants to groom so he can go on vacation16:19
gtristanratmice______, sure, it's the same stumbling block on both ends, provider and consumer16:20
gtristanjust sharing my perspective16:20
ratmice______so ideally they should just work how he/she does16:20
gtristanratmice______, as you can imagine, when you write a new GTK+ app, you want to compile against the new version which will be released in around 3 to 6 months right ?16:21
gtristanwell, maybe you want to distribute something on a restricted older system16:21
gtristanbut new code, usually wants to consume the new API with the new features16:21
gtristanfrom my perspective releasing Glade, I have so many times encountered users who are like "But my glade cant edit this UI file for the new GTK+"16:22
ratmice______right, in my case its usually that those new features are also written by me, and i hope to land the patches upstream in 3-6 months :)16:22
gtristanand of course, they have a 3 year old Glade installed, but want to develop using features with next year's GTK+16:22
gtristanso, the answer has always been, jhbuild it, nobody ever seriously uses the Glade that is installed in /usr/bin for anything16:23
gtristanother than toying around I suppose16:23
ratmice______right, distros generally suck at being relocatable, to ~/bin16:25
ratmice______maybe i should say historically have sucked16:25
gtristanratmice______, this is the whole discussion really, if I want to distribute Glade to an older system, I have to *bring new GTK+ with it*, i.e. I have to bundle it16:25
persiagtristan: I've worked with a number of organisations that *do* depend on the tools installed in /usr/bin, and then deploy to the version of libraries shipped with the platform for their development environment.  I believe this to be the majority case.16:25
persiaMind you, it makes security support hard, but that's a different problem.16:26
persiaThe perceived risk of using a newer GTK is so high as to be impossible to discuss.  This is slowly changing, but slowly.16:26
gtristanthis one for instance, is a sloppily bundled 54MB Glade: https://people.gnome.org/~tvb/test-bundles/glade16:27
gtristanit should run anywhere with glibc 2.716:28
gtristan(and 64bit linux)16:28
gtristanoh, and fuse, and an old version of libglib16:28
*** radiofree has quit IRC16:32
*** radiofree has joined #baserock16:34
*** tiagogomes_ has quit IRC17:00
*** tiagogomes_ has joined #baserock17:15
jjardonRelated what we were talking today; https://plus.google.com/+RichardHughes/posts/U8G4zxSYe9S17:24
tiagogomes_Great :)17:51
*** tiagogomes_ has quit IRC17:56
*** toscalix has quit IRC18:30
*** ssam2 has quit IRC18:40
*** faybrocklebank has quit IRC18:46
*** nowster has quit IRC18:46
*** ssam2 has joined #baserock18:54
*** ChanServ sets mode: +v ssam218:54
*** nowster has joined #baserock18:54
*** faybrocklebank has joined #baserock18:57
*** edcragg has joined #baserock19:32
*** ssam2 has quit IRC19:39
*** edcragg has quit IRC20:12
*** nowster has quit IRC22:27
*** faybrocklebank has quit IRC22:45
*** fay_ has joined #baserock22:58
*** nowster has joined #baserock22:58

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!