usb-installation-images blueprint can be more easily implemented with my existing tool, UNetbootin?

[Geza Kovacs]

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 
>> size,
> 
> 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
> backend?
> 

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.

Regards,
Geza