Hi,
Please don't take this reply personally, but I found these emails brought up some really important points to respond to.
I'm not here to say that the workstation should or shouldn't be Gnome because I'd be wasting my time. I'm just going to bring up some points that I think are important to think about and should be thought about.
On 01/30/2014 11:16 PM, Kalev Lember wrote:
I personally feel that a single default offering is a must, if Fedora is to be successful in the desktop market. We have been losing market share to Ubuntu that has one single default desktop product, and I think this is a lesson to learn from.
With all due respect can we stop and just think about this for a second?
Exactly what lessons have we learned?
Has anyone actually thought about exactly why Fedora has lost a massive amount of market share to Ubuntu? Or forget Ubuntu, any other distribution for that matter?
What do people look for when choosing a desktop or a distribution for that matter? Why do people currently choose Fedora? Maybe we should think about these things first before moving forward.
In general, for a desktop, people want something that "just works" and is "easy, simple and intuitive" to use.
Overall, can we say that about the current "workstation" offering?
Does anyone really think that taking Fedora, slicing it up in to 3 products called "Workstation", "Cloud", and "Server" is really going to make any difference in adoption of Fedora itself? In my opinion it's going to be a case of "the more things change the more they stay the same".
When I joined the Workstation WG, I did that to help build a successful product. To build a base system system that user can rely on; a base system that 3rd party vendors can reliably target with their software. Most other WG members I've talked to are also here to help build a single product.
Building a reliable product goes FAR deeper than just a working desktop. I know that you do spend time in #Fedora on the front lines as I have seen you there before. I hope that you would agree with me that there is still a lot to be desired from the current "workstation offering" (which is DE independent).
For example, disaster recovery needs a lot of work. How can we say Fedora is reliable when it is extremely difficult for a novice user to recover a broken system?
At this exact moment I am trying to help someone with this. It's a lot easier just to tell the person (who doesn't even understand how to boot into single user mode) to reinstall. We don't even have an updated rescue mode document. The last time it was updated was Fedora 16.
I do not want to downplay the value of Spins and alternative offerings, but I personally do not want to spend my time developing them, and I'd rather see if they were developed elsewhere and the Workstation WG was limited to putting together one product.
Who says you have to? There are people out there that are doing so already.
On 01/31/2014 8:50 PM, Adam Williamson wrote:
If I look at it this way, things start looking kind of awesome. For instance, it *is* an interesting idea to say "if you meet the rules of "running Fedora Workstation", you can expect that third party software that complies with (these standards) will work". Looked at as an *extra* expectation that we provide via this "Product" space, that starts looking like a cool new thing.
I now get the thinking behind your blog which was referenced on the Phoronix forums after reading this email.
http://phoronix.com/forums/showthread.php?94869-Future-Of-Fedora-Spins-Is-Qu...
3rd parties develop software for things that are popular. Unfortunately, it has been quite proven that Fedora/Gnome is not one of them.
I for one really don't think that third parties are going to now jump at the opportunity to create software because we took Gnome and put a sticker that says "workstation" on it. I'm sorry but I really just don't see it happening.
Dan
Hi
On 02/01/2014 09:31 AM, Dan Mashal wrote:
I for one really don't think that third parties are going to now jump at the opportunity to create software because we took Gnome and put a sticker that says "workstation" on it. I'm sorry but I really just don't see it happening.
The products are about a lot more than just slapping superficial labels on things.
Case in point, the workstation vs. the server:
1) Does it make sense for a server to have X and a desktop environment installed by default? Nope. Does it make sense for a desktop to have X and a desktop installed by default? Yes, that's the entire point!
2) Does it make sense for a desktop to ship out of the box with the SSH port open? Debatable. Does it make sense for a server to ship out of the box with SSH open? Yes! Does it make sense for a desktop to ship with the DLNA ports open? Yes! A lot of peripherals / media devices won't work with it OOTB otherwise. Does it make sense for a server to ship with the DLNA ports open? Nope!
3) Does it make sense for a server installation application to allow users to attach advanced storage devices such as iSCSI SANs and FCoE disks and mainframe DASD devices? Yes! Is anyone going to use a desktop with s390 direct-attached storage? Probably NOT!
4) Does it makes sense for a server to ship with Gimp, a twitter client, and a PDF scanning application OOTB? Nope. Does it make sense for a desktop? Yep!
Creating different products from the Fedora universe means that instead of different end user interest groups constantly arguing over policy decisions that only make sense for a subset of the end users, instead, we'll have focused products that have the freedom to make decisions in the best interest of their users.
~m
p.s. Maybe some of my examples are wonky, or my probably-not-as-deep-as-yours technical opinion differs from yours. You get the point. I'm not going to respond to earnest, heartfealt critiques of why using DASD storage is critical for desktop users. That's not the point I'm making.
On Sat, Feb 1, 2014 at 8:48 AM, Máirín Duffy duffy@fedoraproject.org wrote:
Hi
On 02/01/2014 09:31 AM, Dan Mashal wrote:
I for one really don't think that third parties are going to now jump at the opportunity to create software because we took Gnome and put a sticker that says "workstation" on it. I'm sorry but I really just don't see it happening.
The products are about a lot more than just slapping superficial labels on things.
I do think there is an opportunity for the Workstation product to gain traction it doesn't currently have as a result of this effort and I certainly think Fedora use in the other product areas is virtually certain to increase.
Now to get myself into trouble I would charactize the three new products as spins on steroids chosen by the project as worth the effort to focus attention on now. The overall effort goes well beyond the three new products however and we do need to figure out some things that I've not seen discussed that much to this point.
While the discussion about how we want to treat the existing spins has begun I'm afraid it still isn't happening in places that are critical to a good decision being made. The desktop spins are heavily used in promoting Fedora and have been for years. The folks doing marketing and the ambassadors working with end users at events really need to have input on this.
Assuming some of those spins continue to exist for at least the short term, that being until we have the new products in the wild and see the reaction they generate, how are we going to market this stuff? There will be an obvious desire to focus marketing effort on the new products but there will be delicate questions about marketing the other spins that in some way compete with our own featured products. Probably the wrong list for this rambling but we need to start thinking about this too if we haven't.
John
On Sat, 2014-02-01 at 09:15 -0600, inode0 wrote:
On Sat, Feb 1, 2014 at 8:48 AM, Máirín Duffy duffy@fedoraproject.org wrote:
Hi
On 02/01/2014 09:31 AM, Dan Mashal wrote:
I for one really don't think that third parties are going to now jump at the opportunity to create software because we took Gnome and put a sticker that says "workstation" on it. I'm sorry but I really just don't see it happening.
The products are about a lot more than just slapping superficial labels on things.
I do think there is an opportunity for the Workstation product to gain traction it doesn't currently have as a result of this effort and I certainly think Fedora use in the other product areas is virtually certain to increase.
Now to get myself into trouble I would charactize the three new products as spins on steroids chosen by the project as worth the effort to focus attention on now. The overall effort goes well beyond the three new products however and we do need to figure out some things that I've not seen discussed that much to this point.
While the discussion about how we want to treat the existing spins has begun I'm afraid it still isn't happening in places that are critical to a good decision being made. The desktop spins are heavily used in promoting Fedora and have been for years. The folks doing marketing and the ambassadors working with end users at events really need to have input on this.
Assuming some of those spins continue to exist for at least the short term, that being until we have the new products in the wild and see the reaction they generate, how are we going to market this stuff? There will be an obvious desire to focus marketing effort on the new products but there will be delicate questions about marketing the other spins that in some way compete with our own featured products. Probably the wrong list for this rambling but we need to start thinking about this too if we haven't.
When I went and looked at it yesterday it struck me that this really isn't a huge issue, because we *already* rather heavily segment our marketing. If you go to https://get.fedoraproject.org/ , what do you see? A big blue button for the x64 live image, and some irritating text you ignore. OK, I exaggerate, but you get the point: we actually already quite heavily promote one small-p product over all the others. Then there's a whole bunch of distinctions drawn between all the other small-p products in a fairly ad hoc way - I think the web design team actually did the best job they possibly could on this, but it's an inherently tricky job when we don't have a clear high-level strategy about what our primary products actually *are*.
So, yes, in the Products world I'm sure we'll promote the Products above everything else, but then, we already do something even more radical than that right now...
On Sat, Feb 1, 2014 at 9:48 AM, Máirín Duffy duffy@fedoraproject.org wrote:
Case in point, the workstation vs. the server:
And to be a broken record, DHCP:
https://lists.fedoraproject.org/pipermail/devel/2014-January/194416.html
On 02/01/2014 03:31 PM, Dan Mashal wrote:
In general, for a desktop, people want something that "just works" and is "easy, simple and intuitive" to use.
I agree 100% with this. And also something that meets upcoming user and hardware requirements (cloud storage, 13" 4K monitors and laptops with touchscreens on them). That is really hard, but I'm positive that fedora is moving forward in that direction with each release. As someone who works both on the desktop and the server, I'm also hopeful that by taking some of the server requirements of the desktop, you can get both better server and desktop products and not having them kind of drag each other down all the time.
Building a reliable product goes FAR deeper than just a working desktop. I know that you do spend time in #Fedora on the front lines as I have seen you there before. I hope that you would agree with me that there is still a lot to be desired from the current "workstation offering" (which is DE independent).
For example, disaster recovery needs a lot of work. How can we say Fedora is reliable when it is extremely difficult for a novice user to recover a broken system?
Yup. One of the goals in the PRD is Better upgrade/rollback control. What other issues apart from that do you think needs addressing? - Andreas
Hi,
On Sat, Feb 1, 2014 at 6:48 AM, Máirín Duffy duffy@fedoraproject.org wrote:
Hi
On 02/01/2014 09:31 AM, Dan Mashal wrote:
I for one really don't think that third parties are going to now jump at the opportunity to create software because we took Gnome and put a sticker that says "workstation" on it. I'm sorry but I really just don't see it happening.
The products are about a lot more than just slapping superficial labels on things.
Case in point, the workstation vs. the server:
- Does it make sense for a server to have X and a desktop environment
installed by default? Nope. Does it make sense for a desktop to have X and a desktop installed by default? Yes, that's the entire point!
- Does it make sense for a desktop to ship out of the box with the SSH port
open? Debatable. Does it make sense for a server to ship out of the box with SSH open? Yes! Does it make sense for a desktop to ship with the DLNA ports open? Yes! A lot of peripherals / media devices won't work with it OOTB otherwise. Does it make sense for a server to ship with the DLNA ports open? Nope!
- Does it make sense for a server installation application to allow users
to attach advanced storage devices such as iSCSI SANs and FCoE disks and mainframe DASD devices? Yes! Is anyone going to use a desktop with s390 direct-attached storage? Probably NOT!
- Does it makes sense for a server to ship with Gimp, a twitter client, and
a PDF scanning application OOTB? Nope. Does it make sense for a desktop? Yep!
Creating different products from the Fedora universe means that instead of different end user interest groups constantly arguing over policy decisions that only make sense for a subset of the end users, instead, we'll have focused products that have the freedom to make decisions in the best interest of their users.
~m
p.s. Maybe some of my examples are wonky, or my probably-not-as-deep-as-yours technical opinion differs from yours. You get the point. I'm not going to respond to earnest, heartfealt critiques of why using DASD storage is critical for desktop users. That's not the point I'm making.
Thanks. Point taken.
On Sat, Feb 1, 2014 at 6:57 AM, Andreas Nilsson lists@andreasn.se wrote:
What other issues apart from that do you think needs addressing?
Geez, way to put me on the spot here. :)
I would probably need to switch to Gnome and run it as a daily driver to tell you (I run MATE). I will go ahead and do this on my desktop and laptop for the next few weeks and try and come up with a list.
The only real thing I can think of right now really is to continue to improve the Anaconda AI/UI.
- Detecing other OSes better for dual boot. I have seen quite a few cases where a Windows installation gets broken after Fedora is installed - Another case would be someone installed Fedora with their Windows drive disconnected and now wants to add Windows to the grub menu. Maybe a wizard here would be nice that would update grub for the user. - Making the partitioning process simpler. Add a few safe guards. People have reported blowing away their partitions by accident. - Adding a ton of tool tips to the UI. Try and predict what people are thinking and try and answer their questions before they have one.
Besides that and really overhauling the rescue system you're looking at mostly improvements needed to Gnome and it's applications in itself IMO.
Dan
On 02/01/2014 10:18 AM, Dan Mashal wrote:
- Detecing other OSes better for dual boot. I have seen quite a few
cases where a Windows installation gets broken after Fedora is installed
Details / bug #? The only cases I've seen Windows get broken is actually due to something outside of Anaconda's control - Windows not available for boot in grub due to EFI-related stuff - that is easily worked around.
- Another case would be someone installed Fedora with their Windows
drive disconnected and now wants to add Windows to the grub menu.
What kind of user are you thinking about here? What level of expertise?
Maybe a wizard here would be nice that would update grub for the user.
- Making the partitioning process simpler. Add a few safe guards.
People have reported blowing away their partitions by accident.
Where is this reported? The number of safeguards in the new anaconda is massively increased compared to how the old anaconda worked. It takes a much more conservative approach than it ever did, and none of the changes to disk are committed until the user starts the install.
- Adding a ton of tool tips to the UI. Try and predict what people are
thinking and try and answer their questions before they have one.
Which UI?
~m
On Sat, Feb 1, 2014 at 7:32 AM, Máirín Duffy duffy@fedoraproject.org wrote:
On 02/01/2014 10:18 AM, Dan Mashal wrote:
- Detecing other OSes better for dual boot. I have seen quite a few
cases where a Windows installation gets broken after Fedora is installed
Details / bug #? The only cases I've seen Windows get broken is actually due to something outside of Anaconda's control - Windows not available for boot in grub due to EFI-related stuff - that is easily worked around.
- Another case would be someone installed Fedora with their Windows
drive disconnected and now wants to add Windows to the grub menu.
What kind of user are you thinking about here? What level of expertise?
I'm talking about novice users.
Maybe a wizard here would be nice that would update grub for the user.
- Making the partitioning process simpler. Add a few safe guards.
People have reported blowing away their partitions by accident.
Where is this reported? The number of safeguards in the new anaconda is massively increased compared to how the old anaconda worked. It takes a much more conservative approach than it ever did, and none of the changes to disk are committed until the user starts the install.
Most of these things I'm referencing here have been reported informally on IRC in #Fedora so I don't have bug relevant bug numbers here. Sorry about that.
- Adding a ton of tool tips to the UI. Try and predict what people are
thinking and try and answer their questions before they have one.
Which UI?
The UI in Anaconda before the user hits install.
Let me compile a more coherent list of things so that I'm better prepared to bring them up over the next few days and get back to you.
Do you have a link to the workarounds for dualboot/EFI? I'd be interested in reading up on those.
Thanks.
Dan
On 02/01/2014 11:13 AM, Dan Mashal wrote:
Do you have a link to the workarounds for dualboot/EFI? I'd be interested in reading up on those.
I don't remember the piece that had the bug (pjones would know) but the workaround was simple: go into the system BIOS and turn on the EFI boot menu instead of using grub2. Windows was in the EFI boot menu and could be booted from there; I think there was an entry in the EFI boot menu for Fedora too.
~m
On Sat, 2014-02-01 at 08:13 -0800, Dan Mashal wrote:
Do you have a link to the workarounds for dualboot/EFI? I'd be interested in reading up on those.
https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-wo...
might help, and I've been planning all week to come up with a UEFI and You wiki page for Fedora which explains the practical considerations about doing Fedora installs on UEFI-capable systems.
F21 already makes some things about UEFI-ish installs rather better: the combination of the second and third changes described at https://www.happyassassin.net/2014/01/29/coming-in-fedora-21-more-installer-... should help quite a bit in some cases.
Yesterday I was looking at adding a little 'UEFI' indicator to the boot menu when you boot a live / install medium in UEFI mode, but amazingly enough, AFAICT this *isn't actually possible* in grub without a horrible hack like sticking it in the boot menu entry itself (I was thinking more a little 'UEFI' at the bottom right of the screen). Apparently you can't just stick text into the grub screen somewhere, with console grub. Sigh.
I also have a plan to test UEFI install of Fedora alongside UEFI install of Windows and see once and for all if the Fedora UEFI grub2 can boot a UEFI Windows install, and also see if we can suppress the Fedora UEFI grub2 config from including an entry for a *BIOS* install of Windows, as mjg59 tells me you can't cross the streams like that (a UEFI bootloader can't boot a BIOS native OS install, so we probably shouldn't let you try if we can avoid it).
On Sat, Feb 1, 2014 at 7:21 PM, Adam Williamson awilliam@redhat.com wrote:
Yesterday I was looking at adding a little 'UEFI' indicator to the boot menu when you boot a live / install medium in UEFI mode, but amazingly enough, AFAICT this *isn't actually possible* in grub without a horrible hack like sticking it in the boot menu entry itself (I was thinking more a little 'UEFI' at the bottom right of the screen). Apparently you can't just stick text into the grub screen somewhere, with console grub. Sigh.
Can we switch to gummiboot for UEFI then? gurb2 is a pile of hacks upon hacks anyway.
On Sat, 2014-02-01 at 19:24 +0200, Elad Alfassa wrote:
On Sat, Feb 1, 2014 at 7:21 PM, Adam Williamson awilliam@redhat.com wrote:
Yesterday I was looking at adding a little 'UEFI' indicator to the boot menu when you boot a live / install medium in UEFI mode, but amazingly enough, AFAICT this *isn't actually possible* in grub without a horrible hack like sticking it in the boot menu entry itself (I was thinking more a little 'UEFI' at the bottom right of the screen). Apparently you can't just stick text into the grub screen somewhere, with console grub. Sigh.Can we switch to gummiboot for UEFI then? gurb2 is a pile of hacks upon hacks anyway.
Y'know, I woke up this morning and thought "what my life is really lacking is another bootloader to worry about"...
;)
On Sat, Feb 1, 2014 at 12:24 PM, Elad Alfassa elad@fedoraproject.org wrote:
On Sat, Feb 1, 2014 at 7:21 PM, Adam Williamson awilliam@redhat.com wrote:
Yesterday I was looking at adding a little 'UEFI' indicator to the boot menu when you boot a live / install medium in UEFI mode, but amazingly enough, AFAICT this *isn't actually possible* in grub without a horrible hack like sticking it in the boot menu entry itself (I was thinking more a little 'UEFI' at the bottom right of the screen). Apparently you can't just stick text into the grub screen somewhere, with console grub. Sigh.
Can we switch to gummiboot for UEFI then? gurb2 is a pile of hacks upon hacks anyway.
This is the wrong list to be having that discussion.
josh
On Sat, Feb 01, 2014 at 07:24:53PM +0200, Elad Alfassa wrote:
Can we switch to gummiboot for UEFI then? gurb2 is a pile of hacks upon hacks anyway.
gummiboot really isn't suitable as a Fedora bootloader. Its inability to read non-FAT filesystems is an absolute showstopper, as is its reliance on LoadImage()/ExecuteImage() for starting the kernel.
On 1 February 2014 22:22, Matthew Garrett mjg59@srcf.ucam.org wrote:
gummiboot really isn't suitable as a Fedora bootloader. Its inability to read non-FAT filesystems is an absolute showstopper, as is its reliance on LoadImage()/ExecuteImage() for starting the kernel.
Hi, I'm somewhat of a UEFI newbie; could you elaborate a little why non-FAT is required and why LoadImage() is a bad thing?
Thanks,
Richard.
On Sun, Feb 2, 2014 at 8:51 PM, Richard Hughes hughsient@gmail.com wrote:
On 1 February 2014 22:22, Matthew Garrett mjg59@srcf.ucam.org wrote:
gummiboot really isn't suitable as a Fedora bootloader. Its inability to read non-FAT filesystems is an absolute showstopper, as is its reliance on LoadImage()/ExecuteImage() for starting the kernel.
Hi, I'm somewhat of a UEFI newbie; could you elaborate a little why non-FAT is required [...]
Because Apple does not use FAT for UEFI partitons (they are HFS+).
On Sun, Feb 02, 2014 at 08:55:10PM +0100, drago01 wrote:
On Sun, Feb 2, 2014 at 8:51 PM, Richard Hughes hughsient@gmail.com wrote:
Hi, I'm somewhat of a UEFI newbie; could you elaborate a little why non-FAT is required [...]
Because Apple does not use FAT for UEFI partitons (they are HFS+).
Apple provide an HFS+ driver in their firmware, so gummiboot can (in that specific case) boot off HFS+. But we still leave the kernel on an ext4 partition on Apples.
On Sun, Feb 2, 2014 at 8:58 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Sun, Feb 02, 2014 at 08:55:10PM +0100, drago01 wrote:
On Sun, Feb 2, 2014 at 8:51 PM, Richard Hughes hughsient@gmail.com wrote:
Hi, I'm somewhat of a UEFI newbie; could you elaborate a little why non-FAT is required [...]
Because Apple does not use FAT for UEFI partitons (they are HFS+).
Apple provide an HFS+ driver in their firmware, so gummiboot can (in that specific case) boot off HFS+. But we still leave the kernel on an ext4 partition on Apples.
Oh OK.
On Sun, Feb 02, 2014 at 07:51:24PM +0000, Richard Hughes wrote:
On 1 February 2014 22:22, Matthew Garrett mjg59@srcf.ucam.org wrote:
gummiboot really isn't suitable as a Fedora bootloader. Its inability to read non-FAT filesystems is an absolute showstopper, as is its reliance on LoadImage()/ExecuteImage() for starting the kernel.
Hi, I'm somewhat of a UEFI newbie; could you elaborate a little why non-FAT is required and why LoadImage() is a bad thing?
/boot is (on basically every Fedora system deployed so far) not FAT, so if your bootloader doesn't read any other filesystems it's not going to be able to boot a kernel. LoadImage() is problematic because Fedora kernels aren't signed with a key that the firmware trusts, so the firmware will refuse to load the kernel.
On 2 February 2014 19:57, Matthew Garrett mjg59@srcf.ucam.org wrote:
/boot is (on basically every Fedora system deployed so far) not FAT, so if your bootloader doesn't read any other filesystems it's not going to be able to boot a kernel.
Is a FAT /boot such a bad thing? Is there a good reason why gummiboot only supports FAT and not something like ext2?
LoadImage() is problematic because Fedora kernels aren't signed with a key that the firmware trusts, so the firmware will refuse to load the kernel.
So you have to load a new key before installing? Is this such a bad thing? Sorry for all the newbie questions.
Richard.
On Sun, Feb 2, 2014 at 3:09 PM, Richard Hughes hughsient@gmail.com wrote:
On 2 February 2014 19:57, Matthew Garrett mjg59@srcf.ucam.org wrote:
/boot is (on basically every Fedora system deployed so far) not FAT, so if your bootloader doesn't read any other filesystems it's not going to be able to boot a kernel.
Is a FAT /boot such a bad thing?
For one thing, not supporting symlinks would break the OSTree model for atomic upgrades (/boot/loader -> /boot/loader.[01]).
It would be possible to fix this by pushing the atomic upgrades "protocol" down to the bootloader level, but I'd prefer to avoid patching all of the bootloaders.
On Sun, Feb 02, 2014 at 08:09:01PM +0000, Richard Hughes wrote:
On 2 February 2014 19:57, Matthew Garrett mjg59@srcf.ucam.org wrote:
/boot is (on basically every Fedora system deployed so far) not FAT, so if your bootloader doesn't read any other filesystems it's not going to be able to boot a kernel.
Is a FAT /boot such a bad thing? Is there a good reason why gummiboot only supports FAT and not something like ext2?
/boot has traditionally been a POSIX-style filesystem that supports things like symlinks, so it's not unthinkable that changing it would break some expectations. gummiboot only supports FAT because it only uses the firmware's built-in filesystem code, and that's almost always just FAT.
LoadImage() is problematic because Fedora kernels aren't signed with a key that the firmware trusts, so the firmware will refuse to load the kernel.
So you have to load a new key before installing? Is this such a bad thing? Sorry for all the newbie questions.
There's no standard UI for installing new keys, and we can't hope to document every UI that does exist, so we decided to adopt a solution that doesn't require manual intervention for this.
desktop@lists.fedoraproject.org
-
Adam Williamson -
Andreas Nilsson -
Colin Walters -
Dan Mashal -
drago01 -
Elad Alfassa -
inode0 -
Josh Boyer -
Matthew Garrett -
Máirín Duffy -
Richard Hughes