bzt
Posts: 557
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Sat Mar 14, 2020 7:07 pm

I'm thinking of adding libudisks2 as a compilation option. I won't add it by default for sure, as it's has way too many dependencies, but might build the deb versions using that lib.

I'm asking for your opinion, what do you think about this. Would it be useful under Ubuntu and Raspbian? Linking dynamically to libudisks2.so would have the advantage to umount and open disks as normal users in exchange for additional dependencies such as udisks2, dbus, polkit and bunch of other daemons and libraries (requires the whole gnome ecosystem I'm afraid).

Cheers,
bzt

DarkElvenAngel
Posts: 725
Joined: Tue Mar 20, 2018 9:53 pm

Re: USB image writer

Sat Mar 14, 2020 8:17 pm

bzt wrote:
Sat Mar 14, 2020 7:07 pm
I'm thinking of adding libudisks2 as a compilation option. I won't add it by default for sure, as it's has way too many dependencies, but might build the deb versions using that lib.

I'm asking for your opinion, what do you think about this. Would it be useful under Ubuntu and Raspbian? Linking dynamically to libudisks2.so would have the advantage to umount and open disks as normal users in exchange for additional dependencies such as udisks2, dbus, polkit and bunch of other daemons and libraries (requires the whole gnome ecosystem I'm afraid).

Cheers,
bzt
Bzt,

It's a difficult trade. I would be willing to test it out and see what impact that has on the default install of Raspbian, I'm guessing the only other option is to just run with sudo?

I also have Linux Mint with mate I can test it on that would make flashing my Buildroot images easier.

Let me know if you just need to have flag set or it'll be it's own branch and I'll give it a go.

bzt
Posts: 557
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Sun Mar 15, 2020 12:25 pm

DarkElvenAngel wrote:
Sat Mar 14, 2020 8:17 pm
It's a difficult trade.
You don't know the half of it... Not enough that there are MANY dependencies, but under Ubuntu libudisks2's package info is incorrect, and you have to hunt down and install those dependencies manually...
DarkElvenAngel wrote:
Sat Mar 14, 2020 8:17 pm
I would be willing to test it out and see what impact that has on the default install of Raspbian,
Thank you! I'll let you know when it's ready.
DarkElvenAngel wrote:
Sat Mar 14, 2020 8:17 pm
I'm guessing the only other option is to just run with sudo?
No, the recommended solution is to properly configure your box. Sudo is always an option though, and since USBImager is really small and has no bloated dependencies, pretty risk-free too (but I would still prefer using "user" flag in fstab and "disk" setgid on USBImager, Principle of Least Privilege).
DarkElvenAngel wrote:
Sat Mar 14, 2020 8:17 pm
I also have Linux Mint with mate I can test it on that would make flashing my Buildroot images easier.

Let me know if you just need to have flag set or it'll be it's own branch and I'll give it a go.
Thanks, I don't have Linux Mint, so this is great. I won't introduce a new flag, I'll simply compile the .deb versions with udisks2 support, leaving the rest zip archives as-is.

Actually the code for supporting libudisks2 was ready yesterday (USE_UDISKS2=1 make). Umounting works, but I'm now facing a problem that its API is NOT documented at all (what they have I wouldn't call a documentation), and I'm missing a few arguments to udisks_block_call_open_device_sync(). Surprisingly I was unable to find any projects that use libudisks2, there are no examples nor tutorials at all (I've tried several search engines). The official documentation says "Argument to pass on invocation", which is, let's face it, not very helpful. Even RPi-imager uses a wrapper class instead. I've opened an issue ticket on udisks2 repo, hopefully they will respond soon explaining what on earth should be passed to that function and how.

If you or anybody else has a working example on how to open a device using libudisks2, that would be very much appreciated.

Cheers,
bzt

croft
Posts: 55
Joined: Fri Dec 13, 2019 4:58 pm

Re: USB image writer

Sun Mar 15, 2020 2:05 pm

hi
i will offer to test buster install

croft

bzt
Posts: 557
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Mon Mar 16, 2020 1:03 pm

Hi All,

New version is out. I did not change the build number, because the executable remained the same (except for the deb versions). The zip archives however updated, as a man page was added. MacOSX and Windows versions haven't changed a bit, and for them a user manual in PDF included.

No response from the udisks2 developers, but I've read through all the gnome docs, and if I have to summarize my experience in one word, that would be "disgusting". At first it looks like gnome is well documented, but if you take a closer look you'll see it's just lorem ipsum. Udisks2 dependencies are messed up, and pkg-configure --cflags provides incomplete command line arguments, and udisks.h does not include everything it needs (particularly it misses gio/gunixfdlist.h). Things like these accompanied by developers not responding to tickets makes me realize why do so many people hate gnome (and for a reason may I add).

Anyway, please test Raspbian and Ubuntu deb versions. If the volumes can be unmounted and the device opened, then the deb versions are 100% the same as the zip version. However if permission denied error occurs, they do not report error but fallback to libudisks2 giving another chance. I've tried this under Ubuntu, it asked for the root password and then I could write the image to disk.

Cheers,
bzt

DarkElvenAngel
Posts: 725
Joined: Tue Mar 20, 2018 9:53 pm

Re: USB image writer

Mon Mar 16, 2020 4:26 pm

Bzt,

On the standard Raspbian install your Deb will not install due to architecture not matching (arm7l) doesn't match system (armhf)

This is my everyday Raspbian install so I haven't modified anything. I tested the zip version but am still having issues with unmounting the drive.

I'm about to fire up my mint box look here for that test.
The results are not good on my Mint 19.3 Tricia amd64 libgtk-3 has no install candidate.

bzt
Posts: 557
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Mon Mar 16, 2020 6:33 pm

Thank you for your feedback!

About the umount, that's expected, the zip version does not use udisks2, and never will as it's dependency-free as much as possible. Only the deb version is compiled with udisks2 support.

Argh, I'm using 'uname -m' for machine type. I already had to replace x86_64 with amd64, now I'll replace armv7l with armhf too. Hang on, new deb within a few minutes.

Cheers,
bzt

bzt
Posts: 557
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Mon Mar 16, 2020 6:59 pm

UPDATE: I got answer from the udisks2 developers, now the final piece of the puzzle is at place! Exclusive disk access flag is properly passed with udisks2 too! :-)

Ok, I've recompiled the deb versions.
  • architecture renamed to armhf
  • removed libgtk-3 dependency (I'm not happy about this, but if Linux Mint doesn't have such a package, there's not much I can do)
  • proper flags passed to udisks2
I've installed both under Raspbian and Ubuntu LTS using "sudo dpkg -i", both installed successfully, USBImager appeared in the applications menu, and I was able to start it.

Cheers,
bzt

DarkElvenAngel
Posts: 725
Joined: Tue Mar 20, 2018 9:53 pm

Re: USB image writer

Mon Mar 16, 2020 8:26 pm

Bzt,

Confirm install on Mint 19.3 Tricia was successful and unmount was successful the system only asked for a password to access the disk.

Confirm install on Raspbian Buster Pi4 B the dev was successfully installed, I had some strange behaviour however when I ran the app to backup my SD it just closed however the second run from a terminal to check for any diagnostic output worked as expected.

I'm not sure what the problem was unfortunately I cannot seem to recreate it. I will say that under Raspbian unmounting seems to be working the ejector icon on the panel complains when you remove the drive as it wasn't ejected properly, this seem untrue as I triple checked the drive was no longer mounted. The exact message reads

Code: Select all

Drive was removed without ejecting
Please use menu to eject before removal
Good work Bzt, everything seems to be working as expected. I'm removing that dirty balenaEtcher off my Linux Mint Box!

bzt
Posts: 557
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Mon Mar 16, 2020 8:58 pm

Thanks @DarkElvenAngel!

I'm not sure about that eject issue either. I think ejecting the device would be a mistake, as that would remove the device file as well. For the umounting, I've used the official example umount-udisks.c (it does not eject either).

But if the problem only appeared once and not any more, let's hope it was just a temporary issue! I won't call this a deal-breaker for the stable release, but please let me know if it reappears.

Cheers,
bzt

ps: I liked those Drizzt do'Urden novels when I was young :-)

User avatar
sakaki
Posts: 543
Joined: Sun Jul 16, 2017 1:11 pm

Re: USB image writer

Wed Mar 18, 2020 6:51 pm

Hi bzt,

first of all, nice job, and thanks for making this tool available!

I wrote a simple Gentoo ebuild for it (here); at the moment this only supports the native X build (haven't looked into the dependencies when building with libui yet ><). It seems to work fine on Gentoo under amd64 and arm64.

As such, I have bundled it with the new v1.5.4 release of gentoo-on-rpi-64bit! Here's a screenshot running on an RPi4B:

Image

Two quick points that arose during the packaging:
  • It would be nice if your Makefile supported the autotools-style DESTDIR variable in its install target. Gentoo's Portage system installs packages to a fake root directory first, and then 'merges' this with the real root directory as a separate step. I got around this by writing my own install function, but it'd be more robust to be able to use your Makefile variant.
  • Creating a versioned source release package on gitlab would also be helpful; in the absence of any such, I've used Portage's git support to pull down the source tree at a particular commit (here, 20c3fbea (this is not your most recent version, due to my manifest freeze for testing the v1.5.4 image), but a named release source tarball would be preferable.
As to the tool itself, I appreciate the stripped-down approach! Two comments, which are more issues of personal preference so feel free to ignore ^-^
  • Safeguards like not allowing writes to the current rootfs notwithstanding, tools like this naturally make one a little nervous about what they are going to do (just as using dd does, or should, make one nervous!). I wonder if adding a "please confirm" modal dialog before actually starting the write (and some text on the main dialog, informing the user they will have a chance to confirm before anything is done, visible when the app is opened) might not be useful.
  • On a similar note, while I appreciate the ability to be able to read as well as write images, the large majority use case is probably to write and verify. As such, having labels for the image path and target device might be helpful, and also perhaps re-ordering the layout vertically, so the flow (select image, select device, hit Write) is visually suggested (I understand the symmetry of the current layout though!)
Anyway, thanks again for the tool, keep up the good work!

With kind regards,

sakaki

bzt
Posts: 557
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Wed Mar 18, 2020 10:43 pm

Hi,

@Background: thanks for testing!
sakaki wrote:
Wed Mar 18, 2020 6:51 pm
Hi bzt,

first of all, nice job, and thanks for making this tool available!

I wrote a simple Gentoo ebuild for it (here); at the moment this only supports the native X build (haven't looked into the dependencies when building with libui yet ><). It seems to work fine on Gentoo under amd64 and arm64.
This is awesome, thank you very much! I wish I could have a debian maintainer as well!

About the dependencies, there's a good reason why I shipped a precompiled static library version of libui, sadly it does not go out-of-the-box (and it's build system has extra dependencies). You can use that static library if you wish (arm32 and amd64). But tbh I prefer the X11 version myself :-)
sakaki wrote:As such, I have bundled it with the new v1.5.4 release of gentoo-on-rpi-64bit! Here's a screenshot running on an RPi4B:
I can just repeat myself, this is just awesome! Thanks!
sakaki wrote:Two quick points that arose during the packaging:
It would be nice if your Makefile supported the autotools-style DESTDIR variable in its install target. Gentoo's Portage system installs packages to a fake root directory first, and then 'merges' this with the real root directory as a separate step. I got around this by writing my own install function, but it'd be more robust to be able to use your Makefile variant.
Sure, is it enough to introduce DESTDIR to make install only?
sakaki wrote:Creating a versioned source release package on gitlab would also be helpful;
I'm planning on that too. Now I'm waiting for the first stable release (which will happen pretty soon if there are no more issues), and then I'll bump the version to 1.0.0. After that versions will be incremented as usual, until then I increase the build number.
sakaki wrote:in the absence of any such, I've used Portage's git support to pull down the source tree at a particular commit (here, 20c3fbea (this is not your most recent version, due to my manifest freeze for testing the v1.5.4 image), but a named release source tarball would be preferable.
What do you mean by named release source tarball? A name containing the version string? I'll most certainly do that with the stable release.
sakaki wrote:Safeguards like not allowing writes to the current rootfs notwithstanding, tools like this naturally make one a little nervous about what they are going to do (just as using dd does, or should, make one nervous!).
Interesting, I have exactly the opposite feeling. Software that are not doing as I say but keep complaining and asking for confirmation makes me nervous :-) That's why I like dd so much. (An interesting thing, back in my university days I had two teachers having endless discussions. One was all about creating fool-proof programs, and the other were saying that programs must do as the user say, let them make mistakes so that users can learn and became non-fools. He argued that asking for confirmations slows down the work while having confident users pays off on the long run. Needless to say I agreed with the latter.)
sakaki wrote:On a similar note, while I appreciate the ability to be able to read as well as write images, the large majority use case is probably to write and verify. As such, having labels for the image path and target device might be helpful
Yes, I was thinking about labels too. But I figured since the user only able to select files for the image path, and there are only devices in the target device combobox, this is not really an issue. If someone unsure, I'd recommend to read the user manual pdf, which explains the interface in great detail.
sakaki wrote:and also perhaps re-ordering the layout vertically, so the flow (select image, select device, hit Write) is visually suggested (I understand the symmetry of the current layout though!)
Yeah, again, I was thinking about this too. At first, when there was only "write" button, the layout was as the workflow. But after "read" button was introduced, it just felt wrong, so I arranged those buttons for symmetry, "write" having an arrow pointing from the image file towards the device, while "read" having an arrow the other way around. I've experimented with

Code: Select all

[image path] [...]
[v write]   [ ] compress
[ ] verify  [^ read]
[device]
but frankly it just looked terrible.
sakaki wrote:Anyway, thanks again for the tool, keep up the good work!

With kind regards,

sakaki
Thanks! And thanks for creating the emerge build!

Cheers,
bzt

bzt
Posts: 557
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Thu Mar 19, 2020 12:30 pm

Good news, everyone! Although I'm already in my pijamas, the first stable release is out! :-)

In the last two weeks, there were no bugs and feature requests were limited to the build system only, so I'm sure USBImager is pretty stable now.

Changes:
  • Added USBImager Releases page
  • Source tarball at usbimager-1.0.0.tar.gz
  • Added DESTDIR variable to "make install" (defaults to "/usr")
  • Binaries moved to a new branch (I couldn't find a way to add binaries or links to the release on gitlab's webui)
Cheers,
bzt

User avatar
sakaki
Posts: 543
Joined: Sun Jul 16, 2017 1:11 pm

Re: USB image writer

Thu Mar 19, 2020 10:45 pm

Hi bzt,

congratulations getting the 1.0.0 release out! A few quick comments:
  • The source tarball (release) format looks perfect; I'll put out a new Gentoo ebuild for your 1.0.0 shortly using it (rather than the current git-based approach).
  • DESTDIR is ideally left unset in the Makefile (see e.g. here, here), rather than to a specific value such as "/usr". It only needs to be respected by install and (if supported) uninstall targets.
  • A manpage would be fantastic (tools like md2man make this decently easy given existing markdown documentation (which you have)). But not vital of course.
But it looks good!

As to the interface, it is your tool, so you of course get to choose ^-^

Two quick questions which I'm sure you've thought through as regards that (and apologies if I'm going through something already discussed in this thread ><):
  1. who are the core intended audience (expertise level, primary platform etc)?
  2. what use case are you solving for them with your tool (if multiple cases, what is the rough % incidence of each)?
So maybe the answers are:
  1. beginner users (who are unlikely to RTFM ^-^) on multiple platforms (Linux/MacOS/Windows) who are somewhat familiar with, or have used, Etcher (and are perhaps unhappy with the privacy implications of that tool, perceived or real)
  2. to write a compressed OS image safely to a device, with verification 95%; to archive an existing filesystem device to a compressed image 5%
which would suggest a more wizard-style, write-centric, confirmation-loaded interface (à la Etcher), perhaps.

Or maybe:
  1. expert Linux users working with disk images who want a cross-platform tool, or at least a way to recreate their CLI invocations when using e.g. work-mandated Windows 10
  2. to write a compressed OS image with maximum efficiency 70%; to archive an existing filesystem device to a compressed image 30%
which might lead to something closer to the current UI design.

BTW one way I've found useful in the past, to square the circle on confirmations is the simple expedient of a 'Don't ask me again' checkbox in the modal "Are you sure?" dialog; writing a sentinel to ~/.config/<appname>/ or similar when ticked. This allows reassurance, while not slowing down the flow for those who know the ropes (albeit being a tiny bit more fiddly to code).

Anyway please don't let this come across wrong, I think the tool is great!

And I will shut up now ^-^

Best, sakaki

bzt
Posts: 557
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Fri Mar 20, 2020 11:10 am

sakaki wrote:
Thu Mar 19, 2020 10:45 pm
Hi bzt,

congratulations getting the 1.0.0 release out!
Thank you!
sakaki wrote:DESTDIR is ideally left unset in the Makefile (see e.g. here, here), rather than to a specific value such as "/usr". It only needs to be respected by install and (if supported) uninstall targets.
You misunderstood. If DESTDIR is unset, then the install path defaults to "/usr". This way "make install" will put the executable under "/usr/bin", and "DESTDIR=/usr/local make install" will put it into "/usr/local/bin", just as it supposed to.
sakaki wrote:A manpage would be fantastic (tools like md2man make this decently easy given existing markdown documentation (which you have)). But not vital of course.
It already has a manpage. Try "man usbimager" after installation.
sakaki wrote:who are the core intended audience (expertise level, primary platform etc)?
Well, originally this tool was designed for users who have downloaded an OS image from the net and want to write it out to an USB stick / SD card. As it turned out users wanted backup functionalities, so more advanced users use this tool too, and the audience is wider than I thought.
sakaki wrote:what use case are you solving for them with your tool (if multiple cases, what is the rough % incidence of each)?
As I've said, I wanted to solve one and only one use case: write (optionally compressed) OS images to USB sticks / SD cards, regardless what system is available at the user's proposal. That's all. Then later backup was added, and the ability to send images to the RPi over USB serial line. These were not intended, rather added because of strong pressure from the users.

A very typical use case (which is very common for me): I can only buy PCs with Windows preinstalled, but I want to use Linux. When I turn on that computer, under Win I download a Gentoo live image, and with USBImager (which does not require installation and looks exactly the same as under Linux) I can write out that live image easily. Then I can boot the live image and install Linux, so that I don't have to use that spyware any longer than I absolutely have to. In this case any confirmation would just slow down the process, and would just annoy me. I imagine this scenario is well known to most (if not all) Linux users.
sakaki wrote:
  1. beginner users (who are unlikely to RTFM ^-^) on multiple platforms (Linux/MacOS/Windows) who are somewhat familiar with, or have used, Etcher (and are perhaps unhappy with the privacy implications of that tool, perceived or real)
  2. to write a compressed OS image safely to a device, with verification 95%; to archive an existing filesystem device to a compressed image 5%
This roughly sums up, but originally I wanted to write images only.
sakaki wrote:which would suggest a more wizard-style, write-centric, confirmation-loaded interface (à la Etcher), perhaps.
Nope, you're wrong about that. Selecting a file and a device does not need any manual reading (but you're correct about RTFM btw). Beginner users does not mean fools; just because they are unexperienced with the command line doesn't mean they don't want effective and easy to use applications. Also the fact they want to try out some kind of Linux (Raspbian in this case) suggests that those users are not typical mainstream end-users, rather at least a bit IT-oriented.
sakaki wrote:
  1. expert Linux users working with disk images who want a cross-platform tool, or at least a way to recreate their CLI invocations when using e.g. work-mandated Windows 10
  2. to write a compressed OS image with maximum efficiency 70%; to archive an existing filesystem device to a compressed image 30%
Most definitely not. An expert Linux user is not afraid of the command line, and they would use "dd" instead, no question about that. (Cygwin, mingw, WSL versions of dd included).
sakaki wrote:BTW one way I've found useful in the past, to square the circle on confirmations is the simple expedient of a 'Don't ask me again' checkbox in the modal "Are you sure?" dialog; writing a sentinel to ~/.config/<appname>/ or similar when ticked. This allows reassurance, while not slowing down the flow for those who know the ropes (albeit being a tiny bit more fiddly to code).
Which is exactly that kind of behavior I want to deliberately avoid. I hate programs that litters my home directory without a very good reason. USBImager right now (just like dd and the other UNIX tools) does not create files in the background, does not leave any trail, and I like to keep it that way.
sakaki wrote:Anyway please don't let this come across wrong, I think the tool is great!
No, not at all. Just because I don't agree with the recent assume-user-stupid UI trends and some of your suggestions, doesn't mean I don't appreciate your feedback! Quite the contrary actually!

Cheers,
bzt

User avatar
sakaki
Posts: 543
Joined: Sun Jul 16, 2017 1:11 pm

Re: USB image writer

Fri Mar 20, 2020 4:04 pm

bzt wrote:
Fri Mar 20, 2020 11:10 am
You misunderstood. If DESTDIR is unset, then the install path defaults to "/usr". This way "make install" will put the executable under "/usr/bin", and "DESTDIR=/usr/local make install" will put it into "/usr/local/bin", just as it supposed to.
Ah, I see where you're going with that now. Well, typically under the GNU autotools paradigm (and BSD Ports, and hence Portage) the approach would be to have a DESTDIR variable, which is normally empty, but could be set to some chroot jail / temporary staging location or whatever, and a prefix (or PREFIX) variable, which would deal with all the /usr, /usr/local type stuff if you want that to be changeable.

E.g. from the GNU automake manual:
The DESTDIR variable can be used to perform a staged installation. The package should be configured as if it was going to be installed in its final location (e.g., --prefix /usr), but when running make install, the DESTDIR should be set to the absolute name of a directory into which the installation will be diverted. From this directory it is easy to review which files are being installed where, and finally copy them to their final location by some means.
...
Prepending the variable DESTDIR to each target in this way provides for staged installs, where the installed files are not placed directly into their expected location but are instead copied into a temporary location (DESTDIR). However, installed files maintain their relative directory structure and any embedded file names will not be modified.
(emphasis added) and from FreeBSD Porter's Handbook:
PREFIX determines where the port will be installed. It defaults to /usr/local, but can be set by the user to a custom path like /opt. The port must respect the value of this variable.

DESTDIR, if set by the user, determines the complete alternative environment, usually a jail or an installed system mounted somewhere other than /. A port will actually install into DESTDIR/PREFIX, and register with the package database in DESTDIR/var/db/pkg. As DESTDIR is handled automatically by the ports infrastructure with chroot(8). There is no need for modifications or any extra care to write DESTDIR-compliant ports
These are just conventions of course, but respecting them means that e.g. Gentoo's default install function can be used, which will in turn invoke your Makefile's install target (with DESTDIR appropriately set). Which in turn makes it easier for maintainers, who don't need to write custom downstream install functions; a good thing, as these can easily get stale with respect to new upstream content...
bzt wrote:
Fri Mar 20, 2020 11:10 am
It already has a manpage. Try "man usbimager" after installation.
...like this(!) Oops, afraid I missed that you'd added a manpage after the commit (20c3fbea) I used for the 0.0.1 / 13th March version ebuild. You're putting this thing together too fast for mere mortals like me to keep up ^-^
bzt wrote:
Fri Mar 20, 2020 11:10 am
sakaki wrote:which would suggest a more wizard-style, write-centric, confirmation-loaded interface (à la Etcher), perhaps.
Nope, you're wrong about that. Selecting a file and a device does not need any manual reading (but you're correct about RTFM btw). Beginner users does not mean fools; just because they are unexperienced with the command line doesn't mean they don't want effective and easy to use applications. Also the fact they want to try out some kind of Linux (Raspbian in this case) suggests that those users are not typical mainstream end-users, rather at least a bit IT-oriented.
Guess we'll just have to agree to differ on that point ^-^ ... personally I come out more on the Steve Krug "don't make me think" end of the opinion scale on UI/UX... I don't believe simplified (in the sense of guided) interface flows represent an implicit act of condescension to users, quite the reverse in fact. But we are now in the realm of religion: given sufficient resources, usability testing of an A vs B approach is really the only way to determine what end users (rather than we developers!) really prefer. But I definitely applaud you for giving people an alternative.

Wishing you all success with this tool!

Kind regards,

sakaki

PS: I've given usbimager a shout out (as an alternative to Etcher) in the gentoo-on-rpi-64bit readme.

bzt
Posts: 557
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Fri Mar 20, 2020 7:01 pm

Hi,

Thanks @sakaki!

I'm not entirely sure what you meant by those quotes, but if you want, I can introduce the PREFIX variable as well, no probs!
sakaki wrote:
Fri Mar 20, 2020 4:04 pm
Guess we'll just have to agree to differ on that point ^-^ ... personally I come out more on the Steve Krug "don't make me think" end of the opinion scale on UI/UX...
Yes, looks like it, but don't you worry. I always thought and I'm still convinced that a computer is just a stupid machine, so it should do as told, and let the thinking to the human. The whole concept of computers deciding instead of people, and the "smart" phone, home etc. irritates me, because the truth is they are not (and in the foreseeable future will not be) smarter than people.

I know it's unorthodox and against the academy to say things like this, but I've learned neural networks, and I'm happen to be well aware how big marketing bullsh*t "AI" actually is. The rest of the world has to learn that the hard way, by suffering accidents due to a speed limit table with a tape and letting social media be flooded by fake news and hate speech. I have no doubt eventually they will realize, because AI is not working as advertised.

Oh, I have sidetracked the topic, sorry.
sakaki wrote:But we are now in the realm of religion: given sufficient resources, usability testing of an A vs B approach is really the only way to determine what end users (rather than we developers!) really prefer.
I couldn't agree more! That's the best course of action in situations like this, having an A B test. Unfortunately being a simple, Free and Open Source hobby project I don't have the resources for this :-( So for the better or worse, it is implemented in accordance to my experience.
sakaki wrote:PS: I've given usbimager a shout out (as an alternative to Etcher) in the gentoo-on-rpi-64bit readme.
Thank you very very much!

Cheers,
bzt

User avatar
sakaki
Posts: 543
Joined: Sun Jul 16, 2017 1:11 pm

Re: USB image writer

Fri Mar 20, 2020 7:18 pm

Hi bzt,

the point of the quotes was just to note that per the autotools/ports paradigm (which Gentoo's ebuild framework plays nicely with), your Makefile should ideally support:
  • a DESTDIR variable, default unset, which can be used to place the entire install tree in a fake root (but does not otherwise change any paths relative to the that root), and
  • a PREFIX (or at your option, lower-case, "prefix") variable, used to set the root-relative install stem (such as /usr, /usr/local etc); this can default to (say) /usr in the Makefile
You then install binaries (e.g.) to $(DESTDIR)/$(PREFIX)/bin etc in your Makefile.

So yes, if you could please make that minor refactor, that'd be fantastic.

Best, sakaki

emma1997
Posts: 762
Joined: Sun Nov 08, 2015 7:00 pm
Location: New England (not that old one)

Re: USB image writer

Fri Mar 20, 2020 8:08 pm

bzt wrote:
Fri Mar 20, 2020 7:01 pm
the truth is they are not (and in the foreseeable future will not be) smarter than people.
So who did actually win that Jeopardy TV episode some years ago pitting IBM Big Blue against 'smartest man in the world'?

bzt
Posts: 557
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Fri Mar 20, 2020 9:27 pm

Hi,

@sakaki: done! You should use https://gitlab.com/bztsrc/usbimager/-/a ... ter.tar.gz though, that's always the latest source.
emma1997 wrote:
Fri Mar 20, 2020 8:08 pm
So who did actually win that Jeopardy TV episode some years ago pitting IBM Big Blue against 'smartest man in the world'?
Because Jeopardy game is basically build on simple questions in English and database-lookups. Computers are good at computing (how surprising) but they are terrible at thinking, and completely incapable of recognizing abstract contextual patterns. They can't interpret languages for example. Yes, there are some tricks, but those only work with simple languages like English (I mean no offense, but the truth is the grammar of English is simple compared to other languages.) And even if they interpret a sentence correctly, they can't interpret the context. In Jeopardy all questions are independent and has all the information; there are no backreferences like in a real conversation. "AI" simply can't compute a question like "Or is it?". There's a good reason why even big blue was unable to win the Loebner gold prize. The experts of the field know this very well, that's why some of them are attacking the prize itself, because they know they'll never fulfill the requirements with neural networks.

Same goes for image recognition, "AI" is just a simple mathematical model that compares numbers that image filters split out without understanding the context of the image. That's why an "AI" can see a butterfly instead of a street manhole for example (it can't understand that the image is taken on a street rather than on a meadow) or why it falsely identifies congress members as criminals (however I'm not entirely sure it's mistaken in that last part).

Cheers,
bzt

bzt
Posts: 557
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Sun Mar 22, 2020 11:35 am

Dear All,

I'd like to make a poor man's A B test, a poll. I'm interested in your opinion.

1. Should there be an "Are you sure?" confirmation on write?

2. Should be the "verify" checked by default?

Both features were asked for, but only by one user. If more users wants these, I'll add them.

And one more question (a'la Columbo), this is really just a question nothing more, what do you think, should 7-Zip be supported? So far I know no more than one distribution that uses 7z format. The problem with 7z is that it is not well documented, the only source is that messy text in the 7z SDK (which is, btw non-portable, that's why I can't use it as-is).

Thanks,
bzt

DarkElvenAngel
Posts: 725
Joined: Tue Mar 20, 2018 9:53 pm

Re: USB image writer

Sun Mar 22, 2020 1:27 pm

bzt wrote:
Sun Mar 22, 2020 11:35 am
Dear All,

I'd like to make a poor man's A B test, a poll. I'm interested in your opinion.

1. Should there be an "Are you sure?" confirmation on write?

2. Should be the "verify" checked by default?

Both features were asked for, but only by one user. If more users wants these, I'll add them.

And one more question (a'la Columbo), this is really just a question nothing more, what do you think, should 7-Zip be supported? So far I know no more than one distribution that uses 7z format. The problem with 7z is that it is not well documented, the only source is that messy text in the 7z SDK (which is, btw non-portable, that's why I can't use it as-is).

Thanks,
bzt
Here are my thoughts.

1) Personally I don't really need a are you sure dialog box. But if one was implemented could we have a argument to disable it. For example this reminds me of rm -i but you also have the rm -f

2) This makes sense, after thinking about it I always check if for writes but not for reads.

Bonus) No, this I think this will introduce complexity into your project you choose before to leave out. I'm thinking of how you would handle filenames.

Hope they are helpful.

User avatar
davidcoton
Posts: 4881
Joined: Mon Sep 01, 2014 2:37 pm
Location: Cambridge, UK
Contact: Website

Re: USB image writer

Sun Mar 22, 2020 3:49 pm

1) I think it should be there, but I like the idea of "Don't show this again" checkbox on the confirm dialog.
2) Yes.
Bonus) No, it's too much added complexity for too little gain (although I like and use 7z as a desktop app).
Signature retired

bzt
Posts: 557
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Sun Mar 22, 2020 5:07 pm

Thanks! More opinions are welcome!

1) Bad news, I've checked. This won't be a problem for Win and X11, however under GTK and Cocoa there's no yes/no modal window. There can be only one main loop, so handling two windows would require a complete rewrite of the main_libui.c. This settles it, there will be no confirm on write, sorry. Maybe when yes/no modal gets implemented in libui.
2) Ok, then this is decided.
3) Actually adding 7z support shouldn't increase complexity, because LZMA decoder is already in place. All I need is a simple 7z parser that finds the first file in the archive (same way as pkzip and zip64 does, filenames are not important). My problem here is, the 7z format is not documented very well, and I was unable to find a minimal portable lib. It looks like I'll have to reverse engineer the format myself if I want to add support for this. The question is, does this worth it? 7z and xz are vulnerable to transmission errors so not recommended for distributing OS images nor for long-term archiving backups.

Thanks,
bzt

bzt
Posts: 557
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Mon Mar 23, 2020 3:29 pm

Dear Everyone,

USBImager 1.0.1 is out.

Changes
  • Added support for mmc block devices under Linux
  • Verify checkbox is checked by default
Since some mmcblk drivers do not handle the removable flag properly, I had to replace that check with a more complex one. Now USBImager collects devices for system directory mount points (currently "/", "/boot", "/home", "/usr", "/var") and lists all disks that are not one of these. This gives more flexibility, although might list some non-wanted devices too occasionally.

EDIT: this was quick. USBImager 1.0.2 is also out with a bugfix for mmcblk devices.

Cheers,
bzt

Return to “General discussion”