7:21 a.m.
What about offering liveusb-creator at the first place instead of
ISO?
Actually, this might be a great idea. Not "instead", but if we provided two
buttons instead of one:
[Download DVD image] [Download USB installer]
people would immediately saw the difference. If they were after USB installation media,
they wouldn't download a DVD image and then wonder what to do with it (as they do
now), no, they would immediately click the second button. Our USB installer is already
capable of both reusing an existing image and downloading a fresh one, so this goes well
hand in hand. And the page serving you the file could be tailored to the particular
method, so DVD download would show you basic DVD burning instructions, while USB installer
download would show you basic USB conversion instructions.
Mairin, I guess you're the best person to talk about fp.o design, what do you think?
(Please read the start of this thread). Thanks.
2:42 p.m.
New subject: the tragedy of Fedora Live USB conversion and what we can do about it
On Fri, 2014-08-01 at 08:21 -0400, Kamil Paral wrote:
> What about offering liveusb-creator at the first place instead
of ISO?
Actually, this might be a great idea. Not "instead", but if we provided two
buttons instead of one:
So I want to inject a note of caution on this one. A few of us who deal
with boot stuff - me for QA purposes, mjg59 and pjones who actually know
what's going on, and lmacken who maintains luc right now - talked this
over a few months back, and what would like to do with luc is kill it,
or at least radically revise it. It's kind of a bad tool.
We have this problem where we do the same work (make a USB stick
bootable on BIOS, UEFI and Macs, basically) three times: well when
generating the images (which is why 'dd' works reliably), pretty well in
livecd-iso-to-disk so long as you pass the right options (which is why
that tool's the best second choice), and really pretty badly in luc
(it's better than it used to be, but still not great; I don't believe it
writes Mac-bootable images, and it's easy to use an existing stick and
wind up with something non-bootable because of filesystem or MBR
issues). We need to do that work just once, ideally.
luc doesn't have anywhere near enough development resources; I think it
comes like five or six items down lmacken's priority list, and he's the
sole person working on it. I don't think that's enough support to lean
on too strongly for 'official distribution' purposes. This is why I
revised the USB instructions on the wiki to prioritize dd-style apps for
Windows and de-emphasize luc.
I think what we'd have in an ideal world is a Windows tool that distros
which ship dd-friendly images (ourselves, Arch, SUSE, Mageia...) could
share and possibly customize, but which shared the core 'dd this image
to this stick' code and maybe had a standard API you could provide a
list of your distro's images to or whatever. You can do persistent
storage with a dd-style tool, potentially; all it needs to do is dd the
image and then create empty partition(s) in the remaining spare space on
the stick and use *those* for persistence. The only thing you can't do
with dd-style writing is a non-destructive write, but that's far less
important than it used to be now you get 16GB USB sticks free with
breakfast cereal (more or less).
If we can't manage that, I'm a fan of making it more obvious from the
download pages how to get a USB stick *somehow* - some better
integration of the download page and the USB writing instructions and
existing tools - but I'm not sure the current luc is good enough and
supported enough to promote as a primary delivery mechanism.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
3:24 a.m.
New subject: the tragedy of Fedora Live USB conversion and what we can do about it
So I want to inject a note of caution on this one. A few of us who
deal
with boot stuff - me for QA purposes, mjg59 and pjones who actually know
what's going on, and lmacken who maintains luc right now - talked this
over a few months back, and what would like to do with luc is kill it,
or at least radically revise it. It's kind of a bad tool.
We have this problem where we do the same work (make a USB stick
bootable on BIOS, UEFI and Macs, basically) three times: well when
generating the images (which is why 'dd' works reliably), pretty well in
livecd-iso-to-disk so long as you pass the right options (which is why
that tool's the best second choice), and really pretty badly in luc
(it's better than it used to be, but still not great; I don't believe it
writes Mac-bootable images, and it's easy to use an existing stick and
wind up with something non-bootable because of filesystem or MBR
issues). We need to do that work just once, ideally.
luc doesn't have anywhere near enough development resources; I think it
comes like five or six items down lmacken's priority list, and he's the
sole person working on it. I don't think that's enough support to lean
on too strongly for 'official distribution' purposes. This is why I
revised the USB instructions on the wiki to prioritize dd-style apps for
Windows and de-emphasize luc.
I think what we'd have in an ideal world is a Windows tool that distros
which ship dd-friendly images (ourselves, Arch, SUSE, Mageia...) could
share and possibly customize, but which shared the core 'dd this image
to this stick' code and maybe had a standard API you could provide a
list of your distro's images to or whatever. You can do persistent
storage with a dd-style tool, potentially; all it needs to do is dd the
image and then create empty partition(s) in the remaining spare space on
the stick and use *those* for persistence. The only thing you can't do
with dd-style writing is a non-destructive write, but that's far less
important than it used to be now you get 16GB USB sticks free with
breakfast cereal (more or less).
Thanks for behind-the-scenes story, I couldn't agree more here.
If we can't manage that, I'm a fan of making it more obvious from the
download pages how to get a USB stick *somehow* - some better
integration of the download page and the USB writing instructions and
existing tools - but I'm not sure the current luc is good enough and
supported enough to promote as a primary delivery mechanism.
Even though luc has so many issues, and even though our Fedora wiki guide [1] no longer
lists is as the first option, I had the notion that it was already *the tool* recommended
by default. Because fedoraproject.org only links to our docs page [2], where it is the
first tool mentioned for both Linux and Windows users. Unfortunately I don't see fp.o
linking to [1] anywhere.
So maybe this is something we could easily improve on? Let's make those USB writing
instructions a bit more visible (because nowadays, USB booting really concerns at least
every other person). And if we're sure we don't want to recommend luc, let's
put there the "quick start" method from [1] at least for Windows, i.e.
recommending dd-alternatives like "SUSE Studio ImageWriter or Rawrite32". Could
we do something about duplication of [1] and [2]? Maybe link to [1] instead of [2] from
fp.o?
[1] https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB
[2]
http://docs.fedoraproject.org/en-US/Fedora/20/html/Installation_Guide/Mak...
Of course, I still see a lot of value in printing a reasonable dracut message in case the
boot fails (a safety net of some kind), so that would be a second thing where we can
improve things easily. I can request it in the Bugzilla, or maybe there is some volunteer
to create the patch?
4:21 a.m.
New subject: the tragedy of Fedora Live USB conversion and what we can do about it
On Mon, 2014-08-04 at 04:24 -0400, Kamil Paral wrote:
Even though luc has so many issues, and even though our Fedora wiki
guide [1] no longer lists is as the first option, I had the notion
that it was already *the tool* recommended by default. Because
fedoraproject.org only links to our docs page [2], where it is the
first tool mentioned for both Linux and Windows users. Unfortunately I
don't see fp.o linking to [1] anywhere.
So maybe this is something we could easily improve on? Let's make
those USB writing instructions a bit more visible (because nowadays,
USB booting really concerns at least every other person). And if we're
sure we don't want to recommend luc, let's put there the "quick start"
method from [1] at least for Windows, i.e. recommending
dd-alternatives like "SUSE Studio ImageWriter or Rawrite32". Could we
do something about duplication of [1] and [2]? Maybe link to [1]
instead of [2] from fp.o?
[1] https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB
[2]
http://docs.fedoraproject.org/en-US/Fedora/20/html/Installation_Guide/Mak...
So, I edit the wiki because, well, it's easy - I hit 'edit' and edit it
and it's done. (The flip side of this is that every six months or so I
notice someone's edited it with some wacky notion or other and I have to
go and try to diplomatically remove / de-emphasize that). To edit the
doc guide I'd have to go and deal with docbook and come up with a git
patch and submit it for review by docs team, which isn't really a
terribly high bar but is still harder than 'edit wiki page, now you're
done', especially when wiki syntax is more or less tattooed into my
brain.
but yeah, it does kind of suck to have both, but I understand the docs
team's reluctance to kill the docs guide when the wiki is a bit more
'wild west'ish. Not sure what the best choice would be - probably it'd
be good to get the two singing from more or less the same hymn sheet, in
the short term.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7:20 a.m.
New subject: the tragedy of Fedora Live USB conversion and what we can do about it
On Aug 29, 2014 5:21 AM, "Adam Williamson" <adamwill(a)fedoraproject.org>
wrote:
To edit the
doc guide I'd have to go and deal with docbook and come up with a git
patch and submit it for review by docs team, which isn't really a
terribly high bar but is still harder than 'edit wiki page, now you're
done', especially when wiki syntax is more or less tattooed into my
brain.
As a compromise, you could file a bug against the docs when you make a
substantive edit to the wiki page. It's still more effort than "edit wiki,
take nap", but it off loads the DocBook work to people who use it more
frequently.
Speaking as the former maintainer (or am I still listed as the maintainer
for that guide? I don't even know), I'd find that arrangement pretty
agreeable. In the Docs team, we're not always aware of changes, so
getting that information more in our faces is good.
Thanks,
BC
3526
days inactive
3554
days old
4 comments
3 participants
participants (3)
-
Adam Williamson -
Ben Cotton -
Kamil Paral