Bzt,bzt wrote: ↑Sat Mar 14, 2020 7:07 pmI'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).
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...
Thank you! I'll let you know when it's ready.
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).
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.
Code: Select all
Drive was removed without ejecting Please use menu to eject before removal
This is awesome, thank you very much! I wish I could have a debian maintainer as well!sakaki wrote: ↑Wed Mar 18, 2020 6:51 pmHi 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.
I can just repeat myself, this is just awesome! Thanks!
Sure, is it enough to introduce DESTDIR to make install only?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.
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:Creating a versioned source release package on gitlab would also be helpful;
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: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.
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: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!).
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: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
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 withsakaki 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!)
Code: Select all
[image path] [...] [v write] [ ] compress [ ] verify [^ read] [device]
Thanks! And thanks for creating the emerge build!sakaki wrote:Anyway, thanks again for the tool, keep up the good work!
With kind regards,
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.
It already has a manpage. Try "man usbimager" after installation.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.
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:who are the core intended audience (expertise level, primary platform etc)?
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.sakaki wrote:what use case are you solving for them with your tool (if multiple cases, what is the rough % incidence of each)?
This roughly sums up, but originally I wanted to write images only.sakaki wrote:
- 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)
- to write a compressed OS image safely to a device, with verification 95%; to archive an existing filesystem device to a compressed image 5%
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:which would suggest a more wizard-style, write-centric, confirmation-loaded interface (à la Etcher), perhaps.
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:
- 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
- to write a compressed OS image with maximum efficiency 70%; to archive an existing filesystem device to a compressed image 30%
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: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).
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!sakaki wrote:Anyway please don't let this come across wrong, I think the tool is great!
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.
(emphasis added) and from FreeBSD Porter's Handbook: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.
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...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
...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 ^-^
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.bzt wrote: ↑Fri Mar 20, 2020 11:10 amNope, 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:which would suggest a more wizard-style, write-centric, confirmation-loaded interface (à la Etcher), perhaps.
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 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: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.
Thank you very very much!sakaki wrote:PS: I've given usbimager a shout out (as an alternative to Etcher) in the gentoo-on-rpi-64bit readme.
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.
Here are my thoughts.bzt wrote: ↑Sun Mar 22, 2020 11:35 amDear 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).