Re: raid10 is killing me, and applications that aren't willingtowaitfor it to respond

2023-12-16 Thread David Christensen

On 12/16/23 07:06, gene heskett wrote:

On 12/15/23 22:58, David Christensen wrote:

On 12/15/23 18:23, gene heskett wrote:
I use the bleeding edge AppImage version of OpenSCAD, heavily, it has 
no such problems.  And no error outputs on the cli, it Just Works.



Thank you for the reply.  :-)


Do you mean the following?

https://openscad.org/downloads.html

OpenSCAD-2021.01-x86_64.AppImage.asc
No, thats quite old and slow, scroll down until you find the current 



On 12/15/23 20:00, David Christensen wrote:
> *** correction *** OpenSCAD-2023.12.09.ai17758-x86_64.AppImage


Now I need to clarify a dhcpd.conf problem. But that is another post 
entirely.  Thank you a lot David.



Post when you want to continue with the disk I/O issues.


David



Re: raid10 is killing me, and applications that aren't willingtowaitfor it to respond

2023-12-16 Thread gene heskett

On 12/15/23 22:58, David Christensen wrote:

On 12/15/23 18:23, gene heskett wrote:
I use the bleeding edge AppImage version of OpenSCAD, heavily, it has 
no such problems.  And no error outputs on the cli, it Just Works.



Thank you for the reply.  :-)


Do you mean the following?

https://openscad.org/downloads.html

OpenSCAD-2021.01-x86_64.AppImage.asc
No, thats quite old and slow, scroll down until you find the current 
linux AppImage, its much faster.




QIDISlicer gives these two errors instantly on launch from cli
Cannot register URI scheme wxfs more than once

** (qidi-slicer:24330): CRITICAL **: 12:29:20.900: Cannot register URI 
scheme memory more than once


QIDISlicer has jillions of gtk2 things:
(qidi-slicer:24330): Gtk-CRITICAL **: 12:29:21.017: 
gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar


(qidi-slicer:24330): Gtk-CRITICAL **: 04:04:12.705: 
gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton
including 50+ of the second, and many more gtk_gedget as it opens and 
works.  And I blame the packager since there is no more gtk2 in the 
debian repo's.



Which QIDISlicer -- e.g. version?


1.0.8 just released

Where did you get it -- e.g. Debian package, AppImage, source tarball, 
etc.?

From qidi's site on github



Cura, latest 5.5.0 AppImage has a few warnings but opens in about 10 
seconds and works fine from there.



Cura version and source?


From the Ultimaker site link
UltiMaker-Cura-5.5.0-linux-X64.AppImage




There are other AppImages but most either won't run or fail if writing.



We can save those for later.


digiKam v8.2.0 cannot import from my camera because (and this is a 
swag) it cannot get instant write perms. It can see everything in the 
camera, but cannot download anything. And does not report any errors 
on the cli when it fails.  It goes thru te motions, blinking all the 
lights, but gimp cannot find the images it just went thru the motions 
of downloading.



digiKam version and source?

digiKam-8.2.0-20230907T053317-x86-64.appimage, kde hosted




Shotwell has the delay, and can import from the camera.



Shotwell version and source?


Whatever is in bookworm repos for amd64/x86-64



Spectacle works in 5 secs, but kills plasma as it exits.



Spectacle version and source?


Whatever is in the bookworm repo's


Debugging issues for any of the above programs is likely going to 
require duplicating your Debian configuration.   Are you prepared to 
provide these details?



As a alternative to, or in parallel with, duplicating your Debian, 
duplicating your apps, and debugging the combination stack, you might 
want to implement a work-around -- install a hypervisor, pick one 
application, create a virtual machine, install only enough Debian to 
support that application, install that application and nothing else, and 
use the application.  Repeat for each application.  (Of course, this 
presumes you can find a hypervisor that runs without issues on  your 
Debian.)


I'm only moderatly fam with that, and don't use it anymore, but 
octoprint uses the python version on the arm64's, but don't use 
octoprint since I found klipper. The python version is a bit of a pita 
to setup but works ok if I can remember the creation order. klipper is 
at home on the arms and doesn't need that complexity.  It is also much 
more capable of handling 3d printers. Point being that it is not 
installed or used on this machine, I've only used it on the arm sbc's.


Another hypervisor idea -- do a fresh install of only enough Debian to 
support a hypervisor, install the hypervisor, then convert your existing 
Debian instance into a VM.


Since qidislicer has not been rebased since buster, setting up a 
hypervisor and installing buster on it makes more sense but I'm pushing 
qidi to rebase it on a more modern release, preferably bookworm or even 
trixie. qidi has been very helpful so far but the request for a rebase 
has so far been somewhat miss-understood due to the nuances of the 
language barrier between me, an old English only Iowa farm kid, and the 
support person I'm messaging sometimes daily, who has some difficulty 
with English idioms & "slanguage" she did not learn in school. Otoh, 
this is by far the best Chinese support person I've ever dealt with.
The slicer itself is excellent and its failures have good work-arounds 
as the whole maryann uses a web interface, any browser can run the 
printer as long as its on the local net address block.




In any case, that NVMe PCIe SSD would be ideal for VM's.


No doubt but physically installing it is a major teardown and 
re-assembly of this machine, its located under several of the other 
cards in the machine.  And local access to it is limited, so I usually 
unplug everything and lug it all to a low table in the kitchen. This 
computer is a huge tower, weighs about 45 lbs and I'm 89 with a bad back.
Now I need to clarify a dhcpd.conf problem. But that is another post 
entirely.  Thank you a