Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Posted Sep 2, 2014 1:43 UTC (Tue) by torquay (guest, #92428)In reply to: Poettering: Revisiting how we put together Linux systems by mezcalero
Parent article: Poettering: Revisiting how we put together Linux systems
-
It's then GNOME's job to do security fixes, and push out minimally modified updates to GNOME_3_38. Then one day, you actually invest some time, want to make use of newer GNOME features, so you rebase your app onto GNOME_3_40.
Except that this won't match up to reality. The current status-quo is that as soon as Gnome version N is released, the Gnome kids don't want anything to do with Gnome version N-1, and certainly much less with version N-2 (ie. Gnome versions < N essentially become AbandonWare). I suspect a similar situation occurs in the KDE camp.
So who maintains Gnome N-1 and KDE N-1 ? A given distro to some extent, but then most distros are on a 6-12 month cycle (not including RHEL and Ubuntu LTS). In other words, a given run-time provided by a distro becomes outdated within a year. This is an awfully short time from both the developers' and users' points of view.
Sure, we can still develop against an "obsolete" run-time, but it will get no security fixes, nor fixes for critical bugs. So what exactly is the value of having multiple run-times, if essentially they're still forcing application developers to deal with broken APIs and ABIs in order to run on a security-supported run-time?
The proposal put forward by the systemd folks is certainly interesting, but I can only see it useful for having 2 run-times: (1) the Ubuntu LTS run-time, (2) and the RHEL/CentOS/Scientific run-time. Essentially it becomes an abstraction layer for the (allegedly) two most practical run-times. Every other run-time is pointless, as it provides no value over a separate distro.
Posted Sep 2, 2014 2:41 UTC (Tue)
by raven667 (subscriber, #5198)
[Link] (6 responses)
Shhh... don't tell everyone that most distros are redundant, they might get restless ... 8-)
If this scheme gets any traction I think the next question everyone will have is why they have so many different runtimes installed to get the apps they want and try to minimize and standardize, asking some hard questions about why exactly the distros are different and the API/ABIs are so broken.
The next question is one of branding, people brand themselves as a Debian, Ubuntu, Redhat, Gentoo, etc. person, like vi vs. emacs, but what point is this self-identification if the distros run co-equally on the same kernel and you can run a mix of them.
Posted Sep 2, 2014 4:00 UTC (Tue)
by mgb (guest, #3226)
[Link]
Until the TC drank the systemd kool-aid we were very happy with Debian Stable for its breadth, stability, security, and seamless upgrades between releases.
But allowing RH to leverage systemd to churn a distro into oblivion is not a smart move.
Posted Sep 2, 2014 4:50 UTC (Tue)
by NightMonkey (subscriber, #23051)
[Link] (2 responses)
Gentoo's primary reason for existence is to avoid the pitfalls that apparently have been plaguing binary distros for a decade. The task of proper dependency management is what Gentoo is just fantastic at accomplishing.
Posted Sep 2, 2014 8:28 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (1 responses)
I switched to gentoo, because when I was running the latest stable SuSE, I couldn't (for whatever reason) upgrade to the latest stable lilypond.
Now although I normally don't bother, I have full control if I need it ... (and I gather there are several linux developers who run gentoo, presumably for the same reason ...)
Cheers,
Posted Sep 3, 2014 4:54 UTC (Wed)
by speedster1 (guest, #8143)
[Link]
I know Greg KH is a long-time gentoo dev who runs it on servers and build machines; just curious what other kernel devs have mentioned running gentoo?
Posted Sep 5, 2014 19:40 UTC (Fri)
by picca (subscriber, #90087)
[Link] (1 responses)
and eventually at the end only one runtime will remain.
Who will install a gnome runtime not maintain by gnome ?
so it will reduce diversity at the end.
Posted Sep 21, 2014 14:39 UTC (Sun)
by vonbrand (subscriber, #4458)
[Link]
The Gnome developers I know do use different distributions...
Posted Sep 2, 2014 9:19 UTC (Tue)
by ovitters (guest, #27950)
[Link] (1 responses)
Regarding this proposal: Lennart mentioned somewhere else that he only expects the bare minimum of fixes to go in. Security fixes and that's it. That's so minimal that I think it is something GNOME could take up.
We still run into and rely on all the other points you made. Maybe solution is indeed to rely on LTS distributions. Have two runtimes: LTS based one, and a shorter supported one.
I do see the usefulness of this though: When GNOME is released anyone in any distribution can immediately make use of GNOME. That's a question we get fairly often. How to use latest GNOME in their current distribution. There's a lot of practicalities though; GNOME often relies on newer versions of lower level stuff (e.g. Wayland).
Posted Sep 2, 2014 11:05 UTC (Tue)
by warmcat (guest, #26416)
[Link]
Signed distro packages say "something"... maybe not much if some source packages came from sourceforge or somebody's USB stick or whatever, but something. People have rallied around distro security policy as their starting point for their system being clean, rightly or wrongly.
If Gnome put out a sort of layer of stuff I can install and run as a unit, that does sound useful, however they might sign the image but the process that sourced and created the contents is kind of opaque and unrelated to how a distro functions.
Obviously it differs but at heart this is not a million miles from "some kind of filesystem apk", and Android has to expect they are malicious, control their system access with an enforced manifest you can inspect before installation, etc. Something like that also seems to be needed here.
Posted Sep 3, 2014 10:34 UTC (Wed)
by ebassi (subscriber, #54855)
[Link] (3 responses)
I fully expect that if this scheme takes hold then we'll see upstreams coping with it, and coming up with new security teams. plus, I fully expect efforts like a Long Term Support GNOME release to happen. again, this is conditional on this scheme working: right up until now, there has been no need for upstream to cope with long term support or security rollouts, since the distributions insulated upstreams pretty much completely. as a side note, could please stop calling the GNOME project members "kids"? it comes off as patronizing and insulting.
Posted Sep 8, 2014 13:31 UTC (Mon)
by Arker (guest, #14205)
[Link] (2 responses)
Posted Sep 8, 2014 13:59 UTC (Mon)
by ebassi (subscriber, #54855)
[Link] (1 responses)
if I had a nickel every time somebody linked Jamie's CADT not ironically, I'd be a millionaire. that page is not the gospel from on high, and if you think nobody, ever, declared "bug bankruptcy" and marked stuff as obsolete or "needs reproduction with a newer version", then you, like Jamie, are kidding yourself. plus, as a user and as a maintainer, I prefer upstreams closing bugs with OBSOLETE/NEEDINFO, as opposed to bugs lying around forever. it's not like Jamie couldn't re-open bugs at the time either: he just decided to be a prick about it (jwz acting like an emo teenager instead of an adult? that literally never happened in the history of ever!) anyway, you'll note that for the past 20 years we had distributions, and for the past 20 years distributions did shield many upstreams. if things change, and responsibilities shift, processes will change — or projects will simply die. we are actually discussing this in GNOME, and have been doing that since we started generating continuous integration VM images. plus, the people doing the security updates downstream will just have to push their work upstream, like they already do. it's not like the people that comprise security and QA teams in distributions will magically cease to exist.
Posted Sep 8, 2014 14:24 UTC (Mon)
by Arker (guest, #14205)
[Link]
I do not doubt that one bit. But it sounds like you need to think about why that is true.
"if you think nobody, ever, declared "bug bankruptcy" and marked stuff as obsolete or "needs reproduction with a newer version", then you, like Jamie, are kidding yourself."
And that is just a straw man. Neither I nor Jamie nor anyone else I can think of right off has said otherwise. The issue is not declaring bug bankruptcy, the problem is a long-term, consistent pattern of ignoring bugs, avoiding maint. and refusing to fix, simply kicking every problem down the road till the next version comes out and 'bug bankruptcy' is invoked.
"it's not like Jamie couldn't re-open bugs at the time either"
There is little more pointless than re-opening or re-filing a bug with the same team that studiously ignored your bug for years already.
And this was really an old pattern already by the time jwz wrote that. Let me repeat that - 12 years ago, when jwz wrote that, this was already an old pattern.
Sure it would be different if this were a new project, or one that had a good reputation. But it's just not. GNOME has been on this past for nearly 15 years, expecting that to suddenly change seems quite irrational.
Posted Sep 9, 2014 15:19 UTC (Tue)
by jonnor (guest, #76768)
[Link]
Currently there is not much of a point in updating older upstream releases, as to get the fixes out to users, each of the NN distributions have to be involved. This process is painful, slow and largely outside control of upstream.
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Wol
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
They've spent roughly the last two decades acting like the worst stereotypes of teenagers
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
If we had runtimes, which would be distributed directly to end-users by upstream, the potential benefit of fixes would increase significatly. Thus one would at least hope it would happen more frequently.