usb-installation-images blueprint can be more easily implemented with my existing tool, UNetbootin?
geza0kovacs at gmail.com
Thu Jun 26 02:09:13 BST 2008
Colin Watson wrote:
> On Tue, Jun 24, 2008 at 10:41:55PM -0700, Geza Kovacs wrote:
>> I see that the "Install Ubuntu from a USB disk" spec has been approved
>> for 8.10, and would like to help out with implementing the feature.
>> However, judging from the spec, I believe that the proposed approach of
>> writing multiple frontends for each platform on top of a Python backend
>> is a rather inefficient both in terms of maintainability and executable
> Executable size aside, Python is typically far more maintainable than
> C++ (at least for us), and we have significantly more Python than C++
> experience in the Ubuntu team.
What I meant was that a single frontend and backend codebase that works
identically on all platforms is easier to maintain than having to
maintain several GUI branches written using a different toolkit for each
platform; I wasn't referring to the relative merits of C++ vs Python;
rather that on Windows, you won't be able to use a single codebase using
the usual Python and GTK combination you're comfortable with, assuming
that this spec will eventually cover non-Ubuntu platforms.
>> and that some of my code for UNetbootin, which already performs
>> graphical USB installation from Windows/Linux, could be modified and
>> reused to yield a cross-platform solution, rather than starting to write
>> the application from scratch. I've posted the following comment at
>> http://wiki.ubuntu.com/USBInstallationImages but I'm sending in to the
>> list in case it isn't noticed:
> UNetbootin would have to be rather seriously cut down. We don't want an
> all-singing all-dancing UI here - in fact, the fewer options the better,
> I think!
I can easily change the GUI as needed to remove unneeded options; Qt
Designer is very flexible in this regard; this shouldn't be much of an
issue. I can send over some example screenshots and/or binaries of a
stripped-down, Ubuntu-rebranded version if interested.
> I haven't looked at the code, though. Evan, could you look over it and
> see what you think?
>> Additionally, Python-GTK is a rather poor choice for usage on Windows;
>> it will lead to an extremely large executable size since the Python
>> runtime and GTK libraries, which amount to several megabytes even once
>> compressed, will have to be bundled in. I believe that C++ and Qt4
>> (which UNetbootin is written in) would be a much better choice for
>> this particular task, since Qt4 has better integration with the native
>> Windows look and feel, and there will be no issues with Qt licensing
>> because Ubuntu is licensed under the GPL.
> Windows is not the only concern, and is not even the most important
> concern. We want to be able to ship this with Ubuntu (as distinct from
> Kubuntu), and we do not want to ship Qt with Ubuntu; in fact, doing so
> would make us unable to ship this application on the Ubuntu CD due to
> size constraints, which would be quite self-defeating. Even if it would
> fit, Qt is not going to have as good integration with the native Ubuntu
> look and feel as GTK.
Actually, the size of the Linux binary when dynamically linked is
roughly 100 KB. The reason the executable sizes for both the Windows and
Linux binaries are over 3 MB now is because the versions I release for
download are statically linked against Qt (and thus don't need the
external library to be installed). In fact, if I remove unnecessary
options and code and tweak the compiler and link options, I can probably
get the size of the complete, standalone statically linked Linux binary
to less than 2 MB.
As for the integration with Ubuntu's look and feel, the latest Qt 4.4
greatly improves on this over previous versions, matching the user's GTK
theme. I doubt users would notice a difference between Human and Qt with
the default Cleanlooks theme. However, if that isn't enough, further
integration is provided by the Trolltech's recent GtkStyle
http://labs.trolltech.com/page/Projects/Styles/GtkStyle (it's still
somewhat experimental, but it'll likely be ready for the masses by the
8.10 release), which is small enough to statically link in if needed;
with GtkStyle, UNetbootin is essentially indistinguishable from a GTK
application (I can attach screenshots if requested).
> Let me be very clear here: while a Windows frontend would be useful, we
> need to put Ubuntu first in this design, *not* Windows. After all, if
> you don't have another Ubuntu machine to hand, you can always just boot
> the Ubuntu live CD on a system with a CD drive, attach a USB stick, and
> run this application; that would be easy for us to document and it might
> even fit on the CD sleeve text if done properly. This is something we
> have to support, and it won't be feasible with Qt.
If the ~2 MB needed by a stripped-down, statically linked version isn't
prohibitive in terms of size, this shouldn't an issue, since the
standalone binary can thus be bundled in and run straight from the
LiveCD without needing to install additional libraries or anything.
If size is really that limited, have you considered removing the 1.4 MB
sbm.bin file in the install subdirectory and adding a download link for
it into README.sbm for anyone that might need it, since Ubuntu's minimal
RAM requirements already exceed the specs of essentially all computers
which don't support direct CD booting, so I doubt anyone is using it
(not to mention that Wubi-cdboot and countless other utilities pretty
much fulfill SBM's purpose)?
> Multiple frontends will be necessary to avoid this problem no matter
> what, so we need to start out with that assumption in the design. Is
> UNetbootin already designed with a separation between frontend and
I actually don't believe the backend-frontend separation approach will
really work that well here, because the portions of the backend designed
for Windows and Linux will be extremely different, due to the different
hardware detection and management systems (hal vs various Windows
hardware subsystem APIs) used in each. Since the system/hardware
detection and management code makes up the bulk of the backend, I doubt
that attempting to build a common backend for vastly different systems
which use different APIs, then writing multiple frontends using
different toolkits to it, requires significantly less effort than
writing seperate versions for each platform.
Nevertheless, I did maintain a degree of separation between the GUI and
backend functions, so I could likely prepare a non-GUI backend. However,
since I used Qt datatypes throughout the application, I would still need
to link in at least the Qt-Core library (though it's rather small, only
a few hundred KB). Then again, the same issue would still apply with a
(future) Python backend on Windows, since Python would still be required
no matter the frontend on Windows due to the backend code.
Thus, even if you don't believe UNetbootin is suitable for usage on the
Ubuntu version, I still think it would be better than using a Python
backend and multiple frontends for the Windows and Mac OSX versions. I
would be glad to help prepare a stripped-down version for Windows based
on it, since it will certainly be more lightweight than anything
Python-based would be, you don't consider Windows a priority at the
moment, and very little of the Python backend code written for the
Ubuntu version would be usable for Windows anyhow.
More information about the Ubuntu-installer