Next meeting is Wednesday, 2015-Sept-02 at 1400 UTC / 10:00am US-Eastern. Agenda additions are welcome, but might be deferred to the next meeting, since I have a big list. My plan is to get through the first four items rather quickly, and focus the meeting on Atomic. But we'll see what happens!
- i686 install media no longer "primary/blocking deliverable" for F24 - Is the text on for the workstation product on getfedora.org OK? - SecureBoot enabled causes Win 8 UEFI to not start from grub - Drop Shotwell/Transmission for F23? - What are the next steps for Atomic Workstation?
On Mon, Aug 31, 2015 at 07:10:13PM -0500, Michael Catanzaro wrote:
Next meeting is Wednesday, 2015-Sept-02 at 1400 UTC / 10:00am US-Eastern. Agenda additions are welcome, but might be deferred to the next meeting, since I have a big list. My plan is to get through the first four items rather quickly, and focus the meeting on Atomic. But we'll see what happens!
- i686 install media no longer "primary/blocking deliverable" for F24
- Is the text on for the workstation product on getfedora.org OK?
Just my $0.02 in advance of the meeting I can't make... I think it's all still pretty accurate. IIRC the text was written for F21. If we want changes, we should submit them ASAP, so as not to put the Websites or Translation teams in an unnecessary crisis mode. I personally think we could just set up to revisit in F24.
- SecureBoot enabled causes Win 8 UEFI to not start from grub
- Drop Shotwell/Transmission for F23?
My early votes to drop are +1 for Transmission, +0 for Shotwell.
- What are the next steps for Atomic Workstation?
On Mon, Aug 31, 2015 at 6:10 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
- What are the next steps for Atomic Workstation?
A decoder ring and a flow chart.
"atomic", Atomic, Atomic Host, Atomic Host model; ostree, rpm-ostree, atomic; and four lists containing the various "atomic" discussions: Fedora Cloud, ostree (gnome), Project Atomic general and Project Atomic devel. Right now I can't actually tell from posts on any of those four lists why they were originally started on those four lists, that's how similar they all seem to me.
But I admit I'm in the happy middle transition between "I grok it all" and "atomic, huh?" So my confusion is expected. But getting out of it with words alone is not working.
If it's going to be called Fedora n Atomic Workstation. Then by extension we'd have Fedora n Atomic Cloud. And yet:
https://lists.fedoraproject.org/pipermail/cloud/2015-August/005699.html
No, call it Atomic Host?
And yet the ISO is Fedora-Cloud_Atomic-x86_64-22.iso
I'm also confused about the distinction between deploying a tree to switch trees versus booting a tree implied by the different GRUB menu entries. Or if those are even the same thing.
The differences between Cloud and Cloud Atomic, are bigger than the differences between Fedora and OS X when it comes to FHS layout, mount behavior, statelessness (or lack thereof), and software installation and upgrades. (And as there's no "atomicized" variant of Workstation yet, Cloud is what I'm basing my experience on thus far.)
And btw I think ostree/rpm-ostree is badass. But that does nothing to assuage confusion. It's something of a WTF, as in, What The Feynman. If we can't get it explained better than it is right now, then we don't really understand it.
Hi,
On Tue, Sep 01, 2015 at 12:36:15PM -0600, Chris Murphy wrote:
On Mon, Aug 31, 2015 at 6:10 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
- What are the next steps for Atomic Workstation?
A decoder ring and a flow chart.
Some links that may help:
http://paul.frields.org/2015/04/02/fedora-under-construction/
Planning for an "Atomic Workstation": https://lists.fedoraproject.org/pipermail/desktop/2015-July/012567.html
http://videos.guadec.org/2015/Playing%20with%20apps%20in%20the%20sandbox/
There are also videos from the DevConf and Flock.
Some documentation:
Introduction to Linux Containers: https://access.redhat.com/articles/1353593
https://access.redhat.com/articles/rhel-atomic-getting-started
I agree that it's not easy to grasp all of that directly, maybe you can try Docker or xdg-app (see how a container is built) to see how it works in practice. Once you're convinced about the benefits of containers, the Atomic Host is the next step.
Cheers, Sébastien
On Thu, Sep 03, 2015 at 02:17:49PM +0200, Sébastien Wilmet wrote:
Hi,
On Tue, Sep 01, 2015 at 12:36:15PM -0600, Chris Murphy wrote:
On Mon, Aug 31, 2015 at 6:10 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
- What are the next steps for Atomic Workstation?
A decoder ring and a flow chart.
Some links that may help:
http://paul.frields.org/2015/04/02/fedora-under-construction/
Planning for an "Atomic Workstation": https://lists.fedoraproject.org/pipermail/desktop/2015-July/012567.html
http://videos.guadec.org/2015/Playing%20with%20apps%20in%20the%20sandbox/
There are also videos from the DevConf and Flock.
Some documentation:
Introduction to Linux Containers: https://access.redhat.com/articles/1353593
https://access.redhat.com/articles/rhel-atomic-getting-started
I agree that it's not easy to grasp all of that directly, maybe you can try Docker or xdg-app (see how a container is built) to see how it works in practice. Once you're convinced about the benefits of containers, the Atomic Host is the next step.
Also, to keep from causing more confusion, I've been calling this "rpm-ostree based Workstation." Atomic Host is kind of its own thing and probably a different release cycle than we're interested in. The underlying tech is what we care about as far as Workstation is concerned, but not something we necessarily want to push onto end-users.
On Fri, Sep 04, 2015 at 02:33:31PM -0400, Paul W. Frields wrote:
On Thu, Sep 03, 2015 at 02:17:49PM +0200, Sébastien Wilmet wrote:
Hi,
On Tue, Sep 01, 2015 at 12:36:15PM -0600, Chris Murphy wrote:
On Mon, Aug 31, 2015 at 6:10 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
- What are the next steps for Atomic Workstation?
A decoder ring and a flow chart.
Some links that may help:
http://paul.frields.org/2015/04/02/fedora-under-construction/
Planning for an "Atomic Workstation": https://lists.fedoraproject.org/pipermail/desktop/2015-July/012567.html
http://videos.guadec.org/2015/Playing%20with%20apps%20in%20the%20sandbox/
There are also videos from the DevConf and Flock.
Some documentation:
Introduction to Linux Containers: https://access.redhat.com/articles/1353593
https://access.redhat.com/articles/rhel-atomic-getting-started
I agree that it's not easy to grasp all of that directly, maybe you can try Docker or xdg-app (see how a container is built) to see how it works in practice. Once you're convinced about the benefits of containers, the Atomic Host is the next step.
Also, to keep from causing more confusion, I've been calling this "rpm-ostree based Workstation." Atomic Host is kind of its own thing and probably a different release cycle than we're interested in. The underlying tech is what we care about as far as Workstation is concerned, but not something we necessarily want to push onto end-users.
Sorry, I meant *awareness of/concerns with that tech* isn't something we necessarily want to push onto end-users.
On Fri, Sep 4, 2015 at 12:35 PM, Paul W. Frields stickster@gmail.com wrote:
On Fri, Sep 04, 2015 at 02:33:31PM -0400, Paul W. Frields wrote:
On Thu, Sep 03, 2015 at 02:17:49PM +0200, Sébastien Wilmet wrote:
Hi,
On Tue, Sep 01, 2015 at 12:36:15PM -0600, Chris Murphy wrote:
On Mon, Aug 31, 2015 at 6:10 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
- What are the next steps for Atomic Workstation?
A decoder ring and a flow chart.
Some links that may help:
http://paul.frields.org/2015/04/02/fedora-under-construction/
Planning for an "Atomic Workstation": https://lists.fedoraproject.org/pipermail/desktop/2015-July/012567.html
http://videos.guadec.org/2015/Playing%20with%20apps%20in%20the%20sandbox/
There are also videos from the DevConf and Flock.
Some documentation:
Introduction to Linux Containers: https://access.redhat.com/articles/1353593
https://access.redhat.com/articles/rhel-atomic-getting-started
I agree that it's not easy to grasp all of that directly, maybe you can try Docker or xdg-app (see how a container is built) to see how it works in practice. Once you're convinced about the benefits of containers, the Atomic Host is the next step.
Also, to keep from causing more confusion, I've been calling this "rpm-ostree based Workstation." Atomic Host is kind of its own thing and probably a different release cycle than we're interested in. The underlying tech is what we care about as far as Workstation is concerned, but not something we necessarily want to push onto end-users.
Sorry, I meant *awareness of/concerns with that tech* isn't something we necessarily want to push onto end-users.
I'm not sure I understand the last part. Users kinda need to know how the system works, is assembled, how it boots (completely different boot configuration files and scripting syntax breaking dual-boot with other Linux OS's), and they will also have something to say about the much more limited disk partitioning layouts available. I personally like that such things are more constrained, and well defined, it makes the system more reliable and easier to test. Users seem to get between agitated and apoplectic when custom partitioning won't make them a gingerbread house. So I think the details are going to matter.
On Fri, 2015-09-04 at 14:33 -0400, Paul W. Frields wrote:
Also, to keep from causing more confusion, I've been calling this "rpm-ostree based Workstation." Atomic Host is kind of its own thing and probably a different release cycle than we're interested in. The underlying tech is what we care about as far as Workstation is concerned, but not something we necessarily want to push onto end-users.
Certainly Fedora Atomic Host and Project Atomic are things of their own, and the use of term Atomic for the "Atomic Workstation" in neither coordinated, authorized, nor all that descriptive of what is involved here. So probably we need to find something else :-)
*However* - I think it's important to realize that the interesting and hard part of the project here is *not* using rpm-ostree for the base operating system. Putting Fedora Workstation images into an ostree could be done today; getting installation and updates to work is a few weeks to a few months of work but something we could very plausibly have done for Fedora 24. But what would we have then? Something that almost nobody would want to use ... certainly not developers. We'd have taken away the ability to freely mutate the operating system, and provided any sort of replacement.
Just as Fedora Atomic Host is interesting because of the ability to run applications on top of the base operating system, making a workstation run in the same model of an atomically (small a) updated base operating system requires us to figure out a compelling application development and deployment story.
For client applications, we need to plan for both development and deployment on Fedora Workstation, and the plans center around xdg-app.
For server-side applications, Fedora Workstation is the place to develop and test your applications, but the final deployment destination is *not* the workstation - so close coordination with other WGs is necessary.
The name "rpm-ostree based Workstation" is probably useful in avoiding undue publicity to something that is in the early stages of planning - but doesn't represent the overall task very well ... it's not going to be the case that we can have a bullet buried somewhere down on the list of Fedora XY features "uses rpm-ostree for system updates" - this is a fundamental change to how developers and other users use their system, and most of that change is about how applications are developed, tested, and deployed.
- Owen
On Tue, Sep 8, 2015 at 10:00 AM, Owen Taylor otaylor@redhat.com wrote:
*However* - I think it's important to realize that the interesting and hard part of the project here is *not* using rpm-ostree for the base operating system. Putting Fedora Workstation images into an ostree could be done today; getting installation and updates to work is a few weeks to a few months of work but something we could very plausibly have done for Fedora 24. But what would we have then? Something that almost nobody would want to use ... certainly not developers. We'd have taken away the ability to freely mutate the operating system, and provided any sort of replacement.
I have thought abstractly about and interim approach by leveraging the part of ostree that understands the "trees" state of an OS, and therefore manage the bootloader configuration, without the rigid immutability aspect you refer to. That's a derivative of ostree + lvmthinp and/or Btrfs snapshots. That gets us rollback with conventional mutability but can also help limit slew.
That might be too much work for its implied limited lifespan until the app dev and deploy angle for Atomic Host is sorted out and matured. It also might overstate the importance of rollbacks. Afterall, we've never had that and the world hasn't ended.
On Tue, 2015-09-08 at 10:55 -0600, Chris Murphy wrote:
On Tue, Sep 8, 2015 at 10:00 AM, Owen Taylor otaylor@redhat.com wrote:
*However* - I think it's important to realize that the interesting and hard part of the project here is *not* using rpm-ostree for the base operating system. Putting Fedora Workstation images into an ostree could be done today; getting installation and updates to work is a few weeks to a few months of work but something we could very plausibly have done for Fedora 24. But what would we have then? Something that almost nobody would want to use ... certainly not developers. We'd have taken away the ability to freely mutate the operating system, and provided any sort of replacement.
I have thought abstractly about and interim approach by leveraging the part of ostree that understands the "trees" state of an OS, and therefore manage the bootloader configuration, without the rigid immutability aspect you refer to. That's a derivative of ostree + lvmthinp and/or Btrfs snapshots. That gets us rollback with conventional mutability but can also help limit slew.
That might be too much work for its implied limited lifespan until the app dev and deploy angle for Atomic Host is sorted out and matured. It also might overstate the importance of rollbacks. Afterall, we've never had that and the world hasn't ended.
Maintaining a local rpm-ostree repository and using that to keep a history of the states of your system is certainly possible, and possibly likely useful in some circumstances.
But on one hand, you still can't, for example, update one package without rebooting. And on the other hand, it doesn't provide the biggest advantage that we can offer to users: the assurance that we've actually tested not just individual packages that we're installing on the system, but the actual same operating system that they are running.
- Owen
On Tue, Sep 8, 2015 at 11:28 AM, Owen Taylor otaylor@redhat.com wrote:
And on the other hand, it doesn't provide the biggest advantage that we can offer to users: the assurance that we've actually tested not just individual packages that we're installing on the system, but the actual same operating system that they are running.
Why is this not adequately solvable with the exist repo system by adding, e.g. "validated" and "validated-testing" repos? Then people who want the old way still use fedora+updates, testers additional use updates-testing; and those who want the new way use fedora+validated and testers use validated-testing?
On Tue, 2015-09-08 at 14:02 -0600, Chris Murphy wrote:
On Tue, Sep 8, 2015 at 11:28 AM, Owen Taylor otaylor@redhat.com wrote:
And on the other hand, it doesn't provide the biggest advantage that we can offer to users: the assurance that we've actually tested not just individual packages that we're installing on the system, but the actual same operating system that they are running.
Why is this not adequately solvable with the exist repo system by adding, e.g. "validated" and "validated-testing" repos? Then people who want the old way still use fedora+updates, testers additional use updates-testing; and those who want the new way use fedora+validated and testers use validated-testing?
Anything done by simply putting different things in repos can only address testing of individual packages, not the combination of packages on a system. There's more discussion in https://lists.fedoraproject.org/pipermail/desktop/2015-July/012567.html and the linked-to Wiki page.
One way I like to think of it, is that I can do all sorts of things to my Fedora system
- without changing package content - without breaking 'rpm -Va'
That make it misbehave in minor or major ways. As an OS developer, that's great flexiblity. As a user - that's not so good - because if any of those things happen to your system by chance or by poorly tested upgrade paths, then your system will never recover on its own.
- Owen
On Tue, Sep 08, 2015 at 12:00:11PM -0400, Owen Taylor wrote:
On Fri, 2015-09-04 at 14:33 -0400, Paul W. Frields wrote:
Also, to keep from causing more confusion, I've been calling this "rpm-ostree based Workstation." Atomic Host is kind of its own thing and probably a different release cycle than we're interested in. The underlying tech is what we care about as far as Workstation is concerned, but not something we necessarily want to push onto end-users.
Certainly Fedora Atomic Host and Project Atomic are things of their own, and the use of term Atomic for the "Atomic Workstation" in neither coordinated, authorized, nor all that descriptive of what is involved here. So probably we need to find something else :-)
*However* - I think it's important to realize that the interesting and hard part of the project here is *not* using rpm-ostree for the base operating system. Putting Fedora Workstation images into an ostree could be done today; getting installation and updates to work is a few weeks to a few months of work but something we could very plausibly have done for Fedora 24. But what would we have then? Something that almost nobody would want to use ... certainly not developers. We'd have taken away the ability to freely mutate the operating system, and provided any sort of replacement.
Just as Fedora Atomic Host is interesting because of the ability to run applications on top of the base operating system, making a workstation run in the same model of an atomically (small a) updated base operating system requires us to figure out a compelling application development and deployment story.
For client applications, we need to plan for both development and deployment on Fedora Workstation, and the plans center around xdg-app.
For server-side applications, Fedora Workstation is the place to develop and test your applications, but the final deployment destination is *not* the workstation - so close coordination with other WGs is necessary.
The name "rpm-ostree based Workstation" is probably useful in avoiding undue publicity to something that is in the early stages of planning - but doesn't represent the overall task very well ... it's not going to be the case that we can have a bullet buried somewhere down on the list of Fedora XY features "uses rpm-ostree for system updates" - this is a fundamental change to how developers and other users use their system, and most of that change is about how applications are developed, tested, and deployed.
Agreed on all counts. I was trying to find some shorthand to get away from the "one piece" model, which as you pointed out isn't that useful. Maybe "layered Workstation" is better, or something else. Anyway, I don't want to get into bikeshedding a term, just point out we should have some sane way to refer to this finished product.
On 31/08/15 05:10 PM, Michael Catanzaro wrote:
Next meeting is Wednesday, 2015-Sept-02 at 1400 UTC / 10:00am US-Eastern. Agenda additions are welcome, but might be deferred to the next meeting, since I have a big list. My plan is to get through the first four items rather quickly, and focus the meeting on Atomic. But we'll see what happens!
- i686 install media no longer "primary/blocking deliverable" for F24
- Is the text on for the workstation product on getfedora.org OK?
- SecureBoot enabled causes Win 8 UEFI to not start from grub
- Drop Shotwell/Transmission for F23?
- What are the next steps for Atomic Workstation?
Although non-member of Workstation WG, I would like to point out Shotwell has broken Facebook API as encountered on https://bugzilla.redhat.com/show_bug.cgi?id=1224562 also affecting other applications according to https://bugzilla.gnome.org/show_bug.cgi?id=748991. Only Darktable can upload pictures to Facebook.
Transmission should be only dropped from default if there is a proper alternative to download .torrent files. It is fairly lightweight and I personally failed to see the point of do so.
desktop@lists.fedoraproject.org
-
Chris Murphy -
Luya Tshimbalanga -
Michael Catanzaro -
Owen Taylor -
Paul W. Frields -
Sébastien Wilmet