-
Copying the downloaded .iso file to flashdisk takes a very, very long (unresponsive) time.
Maybe we should somehow warn about that. -
Using "zsync_curl" to d`ownload I noticed that there was quite a chunk of difference with the 3.8.44 iso ( About 2.8Gb reused and 1.2 Gb to fetch ) but that wasn't really unsurprising considering the now additional desktop.
-
A new splash screen which looks nice.
-
A fair amount of time to load the chosen (E26) desktop (again not surprising considering there's no pre-loading possible)
-
The first impression after choosing the 'light' alpha desktop is nice and very reminiscent of old E17 (maybe a tad too old fashioned for my taste but a reasonable choice)
-
Bug #1: 'scaling' doesn't work for the menus.
-
Bug #2:The top-right window options (the 3 dots) don't really work i.e they're hard to use on a high-res screen.
-
More to come, surely.
-
The 'PrtSc' key is bound to "scrot" and/or "flameshot", i.e the E16 options. I recommend using the native enlightenment screenshot tool as the standard option.
A post was merged into an existing topic: Elive 3.8.46 released
0 . That's an USB issue, not related to the iso or elive 
5 . yes, the elive e17 theme (last option in designs) has many bugs, and is not dynamically adaptable to scaling
6 . same issue about scaling
8 . it needs an update to make the Share upload to the elive server instead of E server
It also happens when copying directly to 'ventoy'. It is related to the .iso 
There's a very large file in the iso there that makes the copying or dd seem unresponsive and will have users think that the procedure is either finished or frozen....resulting in an un-bootable live system.
Hence my suggestion to warn for that seeming unresponsiveness.
PS,
the only large file I can find is the filesystem.squashfs wich has 'only' increased 0.2Gb in size ... so I'm a bit surprised I hadn't noticed this slowness before. 
dd should just be writing blocks (sized corresponding to your bs parameter) to the file. The placement and size of files doesn't matter. It's probably a USB issue. Same goes for copying; unless you're actually extracting the ISO it doesn't matter what's in it.
It's not just about copying (raw or not) .... there's something not right there.
It might be a "thunar" issue .... in both cases it copies fast enough but umounting/ejecting/syncing (take your pick) takes forever and .... pulling the drive before "thunar" has finished gives a corrupted result.
But do please tell if you have not seen this issue on multiple USB devices ..... I've used 3 different devices with he same (slow) result, which do not occur with other (also Elive) images. 
Right, yeah, that'll be either the kernel page cache or the USB's onboard write cache. You can use conv=sync with dd to get it to fsync after each write IIRC, which gives a more accurate indication of progress, but doesn't make it go any faster.
Have had this issue with floppy disks in particular which are obviously very slow but the kernel gives them a generous write cache, so writes complete instantly but take another minute when ejecting.
Which I don't really care about, nor how I could circumvent that...I can handle my own stuff.
I'm worried about the effect on Elive if it is that slow. Did you try writing the .iso to disk i.e can you negate or confirm this issue?
I get this behaviour (fast writes until it syncs) on every Linux ISO I write with dd or ddrescue without specifically requesting fsync. It's not Elive-specific behaviour.
I guess the question is: does dd exit before it's actually synced? Because if so, that's a problem. It should fsync at the end. But that would be a dd issue; I don't think it's possible for it to be related to the iso itself.
No, the question is if you can replicate or not.
If not, that would be good and I can blame my setup .... 'cause I did all my testing from the same machine.
If yes, that could e a real issue to look into.
And I said yes, I could replicate it with every Linux distro, but I was clarifying what the issue on your end was.
OK, but that still was not the question. Or ....
Is that a (round about) way of saying that you do NOT notice that that syncing seems prolonged with the latest Elive 3.8.46 compared to other distros or older versions?
Right, so it appears I missed this part. I do see this behaviour, with Elive and other distros, on multiple USBs. I don't know why it would be Elive-specific for you.
Well that wasn't my point ..... I was just worried it might be 3.8.46 specific. Apparently it isn't, so we can scratch that as a point of attention.
that's not possible try from another computer and a different USB
can be another issue (but again not the .iso), but is more likely to be a hardware issue, that's why I said to try these 2 things first
yes that's normal, the copy is async, you need to wait (no matter what) until it finishes to correctly eject it, this is especially noticeable on slow usb's, try a sandisk ultra
if you actually try from a different iso version, it doesn't happen? that would not make sense
not for me
