| *** edcragg has quit IRC | 01:33 | |
| *** gtristan has quit IRC | 06:32 | |
| *** gtristan has joined #baserock | 06:58 | |
| *** ctbruce has joined #baserock | 09:00 | |
| *** paulw has joined #baserock | 09:12 | |
| *** toscalix has joined #baserock | 09:28 | |
| *** paulw has quit IRC | 09:31 | |
| *** ssam2 has joined #baserock | 10:11 | |
| *** ChanServ sets mode: +v ssam2 | 10:11 | |
| *** gtristan has quit IRC | 10:25 | |
| *** gtristan has joined #baserock | 11:12 | |
| *** gtristan has quit IRC | 11:14 | |
| *** gtristan has joined #baserock | 11:17 | |
| ssam2 | distros devroom at FOSDEM looks fascinating this year: https://fosdem.org/2016/schedule/track/distributions/ | 12:05 |
|---|---|---|
| ssam2 | i'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 year | 12:05 |
| ssam2 | hopefully 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 |
| persia | We 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 talk | 12:18 | |
| jmacs | I think that's optimistic | 12:22 |
| persia | Perhaps. Perhaps the new distro is the "app store", broadly interpreted, so things like the cheeseship qualify. | 12:23 |
| ssam2 | what's the cheeseship? | 12:24 |
| ssam2 | I would mainly like to see a distro like the one I have now, except they stop trying to package apps and integrate xdg-app instead | 12:24 |
| ssam2 | which seems like something that might actually happen! | 12:24 |
| ssam2 | were 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 |
| persia | Sorry: cheeseshop: a place where many python packages exist | 12:30 |
| persia | CPAN would be another example | 12:30 |
| persia | https://wiki.python.org/moin/CheeseShop (except it isn't that secret) | 12:31 |
| ssam2 | I tend to think that the language-specific package repos highlight flaws in the tooling of the mainstream distros, nothing more | 12:33 |
| ssam2 | well, not just the tooling | 12:34 |
| ssam2 | but 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 means | 12:35 |
| persia | Traditional distros suffer from several issues: | 12:47 |
| persia | Firstly, 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 distros | 12:47 |
| persia | Secondly, 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 |
| persia | Thirdly, 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 |
| persia | Fourthly, 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 |
| persia | Fifthly, 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 |
| persia | And 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 ranting | 12:53 | |
| * persia also hopes that Baserock can be part of the total solution, as we grope towards it | 12:53 | |
| jjardon | persia: 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 situation | 13:01 | |
| ssam2 | arch distro engineers are definitely wizards going by the amazing quality of the Arch documentation :-) | 13:03 |
| ssam2 | but, 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 changes | 13:04 |
| persia | jjardon: 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 |
| jjardon | the key point is that Arch try to not decide; they simply package what developers (upstream) release | 13:06 |
| persia | Oh, 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 |
| persia | Yes, but packaging what upstream releases doesn't solve most of the problems I identify above. | 13:06 |
| persia | I 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 |
| gtristan | jjardon, 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 want | 13:08 |
| persia | gtristan: That creates tension, because the authors of the bleeding edge applications want features from newer platform. | 13:10 |
| jjardon | persia: 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 upstream | 13:10 |
| persia | Plus, maintenance of old platform increases the total maintenance burden. | 13:10 |
| gtristan | persia, which is why we need better design/solutions for application sandboxing | 13:11 |
| persia | jjardon: The need for coinstallable is a user issue: not supporting coinstallable is the failure of the distros. | 13:11 |
| jjardon | gtristan: yeah, Android model; I think we are getting there | 13:11 |
| persia | releasing "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 |
| gtristan | I.e. I looked into distro-agnostic bundling for Glade for exactly that reason | 13:11 |
| persia | And the lack of work done by distro engineers doesn't make them have more stellar reputations. | 13:11 |
| gtristan | there 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 Glade | 13:12 |
| persia | Again, Arch is better than many: feel free to like it. It's the centralised curated distro model that I claim is broken. | 13:12 |
| gtristan | also 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 API | 13:12 |
| gtristan | these days too, disk space and bandwidth is relatively cheap | 13:13 |
| gtristan | who cares if libreoffice is 200MB including all of it's dependencies, you only download it once until you download a new bundle | 13:14 |
| persia | I care about efficiency. | 13:16 |
| persia | I want small, efficient, systems, with minimal memory usage (so consistently ported apps), etc. | 13:16 |
| persia | I want most of my stuff to use the *same* framework, so that it can be more responsive. | 13:16 |
| gtristan | Not for my desktop/laptop | 13:16 |
| persia | I want longer battery life and less expensive devices. | 13:16 |
| gtristan | For my embedded product I develop, sure | 13:16 |
| persia | I care about these things for my desktop and laptop. | 13:16 |
| jjardon | persia: 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 |
| persia | I 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 |
| gtristan | not 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 patches | 13:17 |
| persia | jjardon: 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 |
| gtristan | and I want to run the bleeding edge of the applications that I need to use | 13:17 |
| jjardon | gtristan: not sure that's possible | 13:19 |
| gtristan | jjardon, OSX comes close with its bundles and frameworks, also you can do it on linux using AppImageKit | 13:20 |
| gtristan | jjardon, what becomes tricky is policy about what applications can access what resources and properly policing that | 13:20 |
| jjardon | gtristan: what happen when you app depends in a new feature of systemd, for example? | 13:21 |
| gtristan | jjardon, what kind of app does that ? | 13:21 |
| jjardon | gtristan: using systemd apis? gnome-logs, for example | 13:23 |
| gtristan | ok but is that really an application ? | 13:23 |
| gtristan | that should be part of your base system really | 13:23 |
| gtristan | nobody really cares either, I can use a terminal and journalctl | 13:23 |
| gtristan | jjardon, 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 stuff | 13:25 |
| gtristan | nobody needs a bleeding edge of those | 13:25 |
| jjardon | it was only an example of an app using systemd directly to show the problem I exposed | 13:26 |
| gtristan | But, if I can run a sandboxed evolution, firefox, libreoffice, apps I actually need to use, then I can run those | 13:26 |
| gtristan | jjardon, right, and I still dont believe it's an actual problem | 13:26 |
| jjardon | I 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 on | 13:28 |
| jjardon | gtristan: evo can perfectly use some systemd api directly, if the devs decide to do so | 13:28 |
| ssam2 | if sandboxing works well then I think the problem goes away, indeed | 13:28 |
| ssam2 | jjardon: not if it is written to run in xdg-app | 13:28 |
| gtristan | also, 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 latter | 13:29 |
| ssam2 | jjardon: and it would be considered broken by users, because they'd tried to do stuff that broke out of the sandbox | 13:29 |
| ssam2 | jjardon: 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/write | 13:29 |
| ssam2 | jjardon: 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 progress | 13:30 |
| ssam2 | *interfaces | 13:30 |
| *** gtristan has quit IRC | 13:50 | |
| *** toscalix has quit IRC | 14:29 | |
| *** toscalix has joined #baserock | 15:06 | |
| *** gtristan has joined #baserock | 15: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 this | 15:41 |
| ratmice______ | capdesk | 15:45 |
| gtristan | ratmice______, right, so the juice of this is the "E platform", which presumably one needs to write apps specifically for | 15: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 get | 15:47 |
| gtristan | according to a quick glance at http://www.combex.com/tech/edesk.html | 15: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 model | 15:50 |
| ratmice______ | and I think it's E-on-java which is a subset of java | 15:52 |
| gtristan | that 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 |
| gtristan | of 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 |
| persia | That's because the java community long ago decided that bundling dependency binaries was normal and expected | 15:59 |
| persia | With the result that people who use other frameworks (e.g .NET) tease Java about requiring way too much RAM. | 15:59 |
| *** ctbruce has quit IRC | 16: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 |
| gtristan | persia, yes ironically so | 16:03 |
| gtristan | instead they complain "This damn JVM causing OOM killing all my other processes !" | 16:03 |
| gtristan | hehe | 16:03 |
| persia | Right, but the *cause* of the complaint isn't that different from "I have an old version of libglib.jar" | 16:04 |
| gtristan | persia, it reinforces your argument that you want efficiency, I still believe that we can have "efficient enough" with bundling and sandboxing | 16:05 |
| gtristan | nowhere near as bad as running a jvm | 16:06 |
| gtristan | an overhead in memory for the apps you want to run bundled, sure | 16:06 |
| persia | Aside from arguments about compiler optimisation for image size, I think it is the same problem. | 16:06 |
| persia | That 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 |
| gtristan | I 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 standpoint | 16:10 |
| gtristan | it's silly to ask people to run a risky bleeding edge OS just to run this week's build | 16:10 |
| gtristan | it's equally silly to exert pressure on distro maintainers to make this possible | 16:11 |
| gtristan | hence, bundling and sandboxing seems to be the right way forward, of course there is a cost | 16:12 |
| ratmice______ | I'm not sure its helpful to differentiate bleeding edge user from maintainer | 16:17 |
| ratmice______ | I mean ideally those are the people the 'maintainer' wants to groom so he can go on vacation | 16:19 |
| gtristan | ratmice______, sure, it's the same stumbling block on both ends, provider and consumer | 16:20 |
| gtristan | just sharing my perspective | 16:20 |
| ratmice______ | so ideally they should just work how he/she does | 16:20 |
| gtristan | ratmice______, 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 |
| gtristan | well, maybe you want to distribute something on a restricted older system | 16:21 |
| gtristan | but new code, usually wants to consume the new API with the new features | 16:21 |
| gtristan | from 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 |
| gtristan | and of course, they have a 3 year old Glade installed, but want to develop using features with next year's GTK+ | 16:22 |
| gtristan | so, the answer has always been, jhbuild it, nobody ever seriously uses the Glade that is installed in /usr/bin for anything | 16:23 |
| gtristan | other than toying around I suppose | 16:23 |
| ratmice______ | right, distros generally suck at being relocatable, to ~/bin | 16:25 |
| ratmice______ | maybe i should say historically have sucked | 16:25 |
| gtristan | ratmice______, 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 it | 16:25 |
| persia | gtristan: 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 |
| persia | Mind you, it makes security support hard, but that's a different problem. | 16:26 |
| persia | The perceived risk of using a newer GTK is so high as to be impossible to discuss. This is slowly changing, but slowly. | 16:26 |
| gtristan | this one for instance, is a sloppily bundled 54MB Glade: https://people.gnome.org/~tvb/test-bundles/glade | 16:27 |
| gtristan | it should run anywhere with glibc 2.7 | 16:28 |
| gtristan | (and 64bit linux) | 16:28 |
| gtristan | oh, and fuse, and an old version of libglib | 16:28 |
| *** radiofree has quit IRC | 16:32 | |
| *** radiofree has joined #baserock | 16:34 | |
| *** tiagogomes_ has quit IRC | 17:00 | |
| *** tiagogomes_ has joined #baserock | 17:15 | |
| jjardon | Related what we were talking today; https://plus.google.com/+RichardHughes/posts/U8G4zxSYe9S | 17:24 |
| tiagogomes_ | Great :) | 17:51 |
| *** tiagogomes_ has quit IRC | 17:56 | |
| *** toscalix has quit IRC | 18:30 | |
| *** ssam2 has quit IRC | 18:40 | |
| *** faybrocklebank has quit IRC | 18:46 | |
| *** nowster has quit IRC | 18:46 | |
| *** ssam2 has joined #baserock | 18:54 | |
| *** ChanServ sets mode: +v ssam2 | 18:54 | |
| *** nowster has joined #baserock | 18:54 | |
| *** faybrocklebank has joined #baserock | 18:57 | |
| *** edcragg has joined #baserock | 19:32 | |
| *** ssam2 has quit IRC | 19:39 | |
| *** edcragg has quit IRC | 20:12 | |
| *** nowster has quit IRC | 22:27 | |
| *** faybrocklebank has quit IRC | 22:45 | |
| *** fay_ has joined #baserock | 22:58 | |
| *** nowster has joined #baserock | 22:58 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!