Discussion on ways forward linking up New Year 2024 changes to Quickget and Quickemu, including SSH via Smartphone

[zen0bit]

Continuation from Dabrown repo...

@zen0bit just to let you know that the new qqX release, out shortly, NOW 🚀 supports RiscV etc

Don't see mentioned release yet 😢

I have tested openSUSE Risc-V as up and working. It's not all automated out of the box (yet?) but proof of concept is now in place.

Will definetly try 👍❤️

I want to get all your 'new year release' integrated too. But the as the target keeps moving, and even more now with @dabrown645 ' s refactor this might be trickier. I have some ideas though. More later.

Look at newer branches instead 😉

I hope my refactor and line space reduction, in lieu of your qqX PR, is a move forward for you, BTW.

A lot nicer (+ zoom 👍)

But still not there on my small screen.

Not really study qqx source code yet.
Some better working with terminal width? (50 columns in termux)

Screen_Recording_20240207_180337_Termux.mp4

[TuxVinyards]

👋

Communication is the way forward. 👍 I get the impression that @lj3954 & @dabrown645 are not in running Central European Time which can hold things up a bit. West coast USA ? Australia? Would be helpful if they said. But also ignoring peer reviews and carrying on with errors as if they don't exist ... 🙈

I ran your cell phone screenshot vid. Is quickemu really designed to be run on a phone though? I used to use Termux a lot but Termux is fast being abandoned now. You can only get it from Fdroid now & work/maintenance is not really happening. I thought you were a big Void Linux fan ??

I have made sure that qqXcan run on a 1920x1080 standard desktop.

However, that said, there are things you can do to make qqX run on a tiny screen:

1. The installer script allows you to set custom terminal sizes
2. You can hold the phone sideways and use a low profile keyboard setting.
3. You can set the number of items that show per line, in the main settings. VM_Select_ItemsPerLine="4" is the default.
4. You can reduce the font size, maybe a touch?

See if that helps.

[zen0bit]

I ran your cell phone screenshot vid. Is quickemu really designed to be run on a phone though? I used to use Termux a lot but Termux is fast being abandoned now. You can only get it from Fdroid now & work/maintenance is not really happening. I thought you were a big Void Linux fan ??

quickemu not running in termux. Not sure about dependencies. But termux is just for sshing. To void linux of course. Don't really track termux development. But everything looks updated fairly.

Using obtainium for updating (if apk isn't available from sources, using f-droid)

Not touched really usable daily driving linux phone yet. (hopefully soon. So no void on my phone yet. (tried on pinephone pro, but not really usable since battery with use like mine is for few hours)

Will look at items per line..

I think I will not bother you any more (at least with my termux edge case 😀)

Because I thinking about getting new laptop from tuxedo computers...

And now is qqX nice enough 👍

[zen0bit]

Impatient to test RiscV through qqX..
🥸

[lj3954]

👋

Communication is the way forward. 👍 I get the impression that @lj3954 & @dabrown645 are not in running Central European Time which can hold things up a bit. West coast USA ? Australia? Would be helpful if they said. But also ignoring peer reviews and carrying on with errors as if they don't exist ... 🙈

I ran your cell phone screenshot vid. Is quickemu really designed to be run on a phone though? I used to use Termux a lot but Termux is fast being abandoned now. You can only get it from Fdroid now & work/maintenance is not really happening. I thought you were a big Void Linux fan ??

I have made sure that qqXcan run on a 1920x1080 standard desktop.

However, that said, there are things you can do to make qqX run on a tiny screen:

1. The installer script allows you to set custom terminal sizes

2. You can hold the phone sideways and use a low profile keyboard setting.

3. You can set the number of items that show per line, in the main settings.  `VM_Select_ItemsPerLine="4"` is the default.

4. You can reduce the font size, maybe a touch?

See if that helps.

I was extremely sick when you left those comments, so I was in no position to work on fixing anything. I did mean to reply later on, but I never got around to it. You raise a valid point that other software may have the name chunkcheck. That's why in my new rewrite of quickemu, I'm renaming it to the generic name 'verifyRecoveryImage' instead (not to mention, leaving in a subdirectory which wouldn't be in PATH). I could not care less, however, about errors of CPU instructions missing that don't actually affect anything (for all I care you could just pipe those to /dev/null), or inefficient methods of checking various statistics about the host system, which I didn't write.

I've stated in a now-closed issue on dabrown645's repository that I think their quickget will make implementation of new features significantly more difficult, so I'm now working on my own rewrite instead. I do not like the arrays being used for pieces of info like URLs which can have special characters (I already had experienced an issue with that), and I don't like the hardcoded nature of everything and how working around it essentially means rewriting all quickget functions in your plugin. I'm also not sure using source to take functions out of a 'plugin' is the best idea, so instead, I'm using full scripts for this plugin concept in order to offer far more control to whoever is implementing operating systems. I'm currently working on a template in addition to my quickget which will likely have have 150-200 lines at the bottom to handle as many features as possible just by modifying a couple of variables.

And yes, my timezone is PST.

[TuxVinyards]

@lj3954

Thank you for replying.

"You raise a valid point that other software may have the name chunkcheck. That's why in my new rewrite of quickemu, I'm renaming it to the generic name 'verifyRecoveryImage' instead (not to mention, leaving in a subdirectory which wouldn't be in PATH)."

Pleased to read that. 👍

Of note, thinking continuity and staying positive on this, @dabrown645 has opted for '/usr/share/quickemu' if you want any link up, later maybe. I would like to think that there is a 'we' and that there is a certain sense of collective responsibility and community ....

"I could not care less, however, about errors of CPU instructions missing"

We need to get the best out of the quickemu system. This also includes not using obsolete legacy CPU's like Penryn.

"or inefficient methods of checking various statistics about the host system, which I didn't write."

We need to care about the whole of quickget, not just the little bit that we are adding on to it. The CPU flags function is destined to malfunction. I still want to know exactly what caused Penryn to be offered to me instead of Haswell, in your code. Or whether or not this particular function was behind it.

"so I'm now working on my own rewrite instead. "

Whether you do this ALL on your own remains to be seen. You have made some good contributions but, intentionally or otherwise, your attitude to others can often seem very dismissive. So far, I am not finding you to be the easiest of people to work with. Your "I could not care less" take on the code is not very inspiring either.

I haven't tried adding a distro to @dabrown645 's code. It does look a tad more complex than the original. But it does look organised. And I like modular. @zen0bit doesn't seem to have any problems with it, so I am going with that for now.

qqX will remain independent to quickemu. I hope you take into consideration when you craft your version of quickget that it won't be used if we can't all work with it.

[lj3954]

This also includes not using obsolete legacy CPU's like Penryn.

Do these cause issues with anything on the VM? A couple of missing instruction errors in the console are none of my concern, I will not spend any time "fixing" that when there's so much work that could be done fixing actual issues and adding features.

We need to care about the whole of quickget, not just the little bit that we are adding on it

I've proposed many pull requests to fix real issues in quickemu and quickget, parts of the code I did not have anything to do with previously. However, an inefficient or poorly written check which hasn't been known to lead to any issues isn't something I'm going to focus on. You can propose these fixes if you'd like, since they apply to code that's already existing in the main branch.

I hope you take into consideration when you craft your version of quickget that it won't be used if we can't all work with it

I'm re-implementing all parameters and error messages, down to the word, if possible. The functionality should be completely identical to the original quickget, with the exception of a very small selection of operating systems (including Windows, probably Fedora, and a few others) which will print out editions for each release, rather than for the entire operating system. This is the default behavior of @dabrown645's version, though, so it shouldn't interfere with anything more. I was completely inspired by that, since it was one of the main gripes I had while implementing Windows languages. I don't believe it should be the default for all operating systems, though, since the majority have the same editions for every release.

Everything beyond that should just be new features, such as architectures. I'm focusing on making everything as perfect as possible before adding any actual operating systems. Implementation of new operating systems will be as easy as possible, and it'll allow individual plugins to easily take complete control of the downloading process if necessary, one of the major issues I had while trying to write plugins for @dabrown645's. The major feature I'm working on implementing right now is caching releases, editions, and other data which may be fetched from the internet for some operating systems. The data will expire after 7 days (which may be too short, I'll figure that out), and there'll be parameters to override the cache. I've been thinking about this type of feature for quickget for months, and a rewrite gives me a perfect excuse to work on it. Once again, my intention is to make sure none of this will result in any change to quickget's behavior.

Whether you do this ALL on your own remains to be seen.

Most of this work is just re-implementation of already existing code in quickemu. You can check out my progress on my refactorQuickget branch. I'm the majority of the way to basic functionality, although much still has to be changed. I don't want any operating systems to be implemented until my template is fully complete, since much will change. I don't plan for operating system additions to entirely be done by me, but I have a very clear vision of the initial featureset, and I want to make sure the vast majority of the OS implementation is already done by the template. I don't want any workarounds to have to be performed, like using strange loops to fill every key in an array with a blank value. Or manually filling in 23 of these blank values, as in the arcolinuxl plugin from the other refactor. I don't want any of that. I think all of this has to be worked out before adding operating systems, not after it. Otherwise, you're going to run into just as many limitations as the original quickget. Refactoring the code like that and re-implementing every single operating system is completely pointless and nothing more than a waste of time if you don't have anything to show for it.

[TuxVinyards]

On MacOS:

"This also includes not using obsolete legacy CPU's like Penryn."

"Do these cause issues with anything on the VM? A couple of missing instruction errors in the console are none of my concern, I will not spend any time "fixing" that when there's so much work that could be done fixing actual issues and adding features."

Yes, these problems do cause issues. Things like USB mice not working are quite noticeable, for example.

No, you don't have to "spend time fixing them". If you re-read my peer review, you will find that I have already done most of the work for you. Any more discussion should be moved there.

quickemu-project/quickemu#886 (comment)

[TuxVinyards]

Both you, @lj3954 and @dabrown645 have less errors in your code than we have in the current quickget. But you should both make better use of shellcheck:

Zoom on screenshot to see line numbers and details ....

[TuxVinyards]

Technical discussion aside, I am finding @dabrown645 's template much easier to follow and understand.

The main array has all the moving parts contained in one place and there is no 'sed' gibberish that needs to be unravelled either.

[TuxVinyards]

"The major feature I'm working on implementing right now is caching releases, editions, and other data which may be fetched from the internet for some operating systems. "

We could reduce the maintenance load if we had a system in place whereby users can open the distros main download page in a browser, select an ISO and then have quickget set it up for them.

Scraping the net for download links, especially deep links, may work generally on sites like 'cdimage.ubuntu.com' but minor distros will always have problems.

[TuxVinyards]

"The functionality should be completely identical to the original quickget"

" This [also] is the default behavior of @dabrown645's version"

Whichever version we all end up gravitating to, not forgetting @flexiondotorg and stalwarts like @philclifford here, there will always be a space for alternative versions here at qqX.

Please make use of qqX's ability to change quickemu and quickget versions in the main settings. 🚀

[lj3954]

Technical discussion aside, I am finding @dabrown645 's template much easier to follow and understand.

The main array has all the moving parts contained in one place and there is no 'sed' gibberish that needs to be unravelled either.

Everything below the 'config_additions' function will not be present in the final template. I'm writing it to handle basically every single possible combination of features. Nearly all of that will be moved to a separate file and run from within the plugin using source. For operating systems which just have hardcoded releases, editions, and URL/ISO/HASH (which is the majority), the only fields that will need to be filled are the homepage, whether or not they require an edition to be inputted, and the aforementioned URL/ISO/HASH. I've just committed further changes to make the template easier to fill out, moving the place of the (current and future) code which determines whether to use the data in the fetch_info function in the fetch_from_cache function, which once again will not be visible to the OS implementer.

Sed was only used to determine the name of the OS (and once again was not part of the code that anyone implementing an OS would have to modify), but it's definitely not the best solution. Instead, I'm going to be exporting the OS, RELEASE, and EDITION variables so that the plugin, run within a subshell, has access to all of this information.

[lj3954]

"The major feature I'm working on implementing right now is caching releases, editions, and other data which may be fetched from the internet for some operating systems. "

We could reduce the maintenance load if we had a system in place whereby users can open the distros main download page in a browser, select an ISO and then have quickget set it up for them.

Scraping the net for download links, especially deep links, may work generally on sites like 'cdimage.ubuntu.com' but minor distros will always have problems.

Are you suggesting that we somehow embed a browser and determine the first URL clicked which has 'iso' in it? I don't think that's practical. There's too many different browsers that a system could have installed or not installed, and I don't think xdg-open-url will allow anything like that. If you mean a "custom" OS option which allows the user to input a URL, that's a possibility and the plugin system could certainly enable something like that to be created. Or, a plugin could open a website directly itself and wait for the user to come back and input a URL for an ISO.

[zen0bit]

Invitation to oSoWoSo was sended to you...

Hopefully, if you don't mind bit closely.

With enabled actions, discussions etc.

I want invite to this discussion about quickemu refactoring also @HikariKnight (passthrough)

[zen0bit]

Apropo
I also made Lets say "overhall" of quickget on my dev branch with nice help message, os info instead of homepages, linting and other changes.

Not yet finalized..!

Not modular but should be implemented..

[zen0bit]

But i think we should discuss quickemu/quickget refactoring in quickemu if not in my org...

[zen0bit]

My first replies here was because was qqX related...

[HikariKnight]

Invitation to oSoWoSo was sended to you...

Hopefully, if you don't mind bit closely.

With enabled actions, discussions etc.

I want invite to this discussion about quickemu refactoring also @HikariKnight (passthrough)

not really sure how much i can contribute here, quickpassthrough does set up the host system for gpu passthrough (with restrictions, due to the inherent complexity of passthrough, so identical cards are not supported and single gpu passthrough is not supported) but is otherwise detached from quickemu as it does not really care how you do your virtualization in the end.

It is just the configuration for quickemu that stopped up as i got no feedback (in quickemu-project/quickemu#812) on it so it has been left on the wayside.
Ideally the first config format implementation in my discussion would be the more sensible one as it would leave using the correct arguments to quickemu (should lets say qemu create a new argument which does passthrough better, then quickemu would handle that since it is what does the interaction with qemu in the end).

Functionally everything is there and you just need to supply qemu with the arguments to use the gpu you have reserved for passthrough as mentioned in HikariKnight/quickpassthrough#14

I will have a re-read through this when i am more awake and have a bit more time as it is almost 4am here 😅
But do feel free to ping me if you are curious about anything!

[lj3954]

Apropo I also made Lets say "overhall" of quickget on my dev branch with nice help message, os info instead of homepages, linting and other changes.

Not yet finalized..!

Not modular but should be implemented..

I think your OS info is no good. It's difficult to read and would be somewhat annoying to implement OSes for. I'm leaving it to individual variables instead, which are far more convenient when they're all in one place. I'm pretty sure I have basic functionality ready in my quickget, if you'd like to test it. Architectures and the prepare_image and config_additions functions aren't quite yet functional in quickget, but everything else should be fine. I don't believe anything major is going to be changing in the template from this point.

[zen0bit]

Anytime I am accepting advices from experienced user. My bash knowledge and linux in general is still very limited. 😳

will try..

[zen0bit]

I am also thinking 🤔 about quickemu website. What about creating it in way similar to repology? Just about distros/OSes instead. So plugins will be used for both website and qg also.

Simplest as posible web database of distros with editions, releases and links. Could be then more easily updated and tested with github action. I think best will be leave web scraping in web and quickget should have all actual releases offline. Download from web only Images nothing else.

[zen0bit]

Also working on q
quickemu/quickget TUI using charmbracelet gum

work now stoped due to a lot of changes around.. So currently not working. But will be easily changed after base code will be defined.
q blob

But you can test my "Work In Progress" easy TUI.

❤️ If you leave feedback in repo

It is preparation for quickemu builded as AppImage

[TuxVinyards]

But i think we should discuss quickemu/quickget refactoring in quickemu if not in my org...

Sometimes things just happen spontaneously. It's how it is. I don't think we need to make things overly formal. We are starting to get heads together here, so it's probably best to stay on this thread for now, while we have focus. Who knows what will prompt the next thread, or where. 🤣

It would be great if we could have some input from @dabrown645 I did invite him but he doesn't seem to have made any comments or commits on his own repo either?

The BIG problem is of course @flexiondotorg 's absence .... He does have a discussion page that we could use, theoretically. I have just looked and found it littered with spam going back for weeks. 🙈

[TuxVinyards]

"The major feature I'm working on implementing right now is caching releases, editions, and other data which may be fetched from the internet for some operating systems. "

We could reduce the maintenance load if we had a system in place whereby users can open the distros main download page in a browser, select an ISO and then have quickget set it up for them.
Scraping the net for download links, especially deep links, may work generally on sites like 'cdimage.ubuntu.com' but minor distros will always have problems.

Are you suggesting that we somehow embed a browser and determine the first URL clicked which has 'iso' in it? I don't think that's practical. There's too many different browsers that a system could have installed or not installed, and I don't think xdg-open-url will allow anything like that. If you mean a "custom" OS option which allows the user to input a URL, that's a possibility and the plugin system could certainly enable something like that to be created. Or, a plugin could open a website directly itself and wait for the user to come back and input a URL for an ISO.

I have an idea to use qqX's already existent web browse abilities in the quickget interface section. This can be then linked to qqX's right click actions. You simply right click on the downloaded ISO and a dialog opens where you can choose the install directory and fine tune the .conf

At the CLI however, we could have an install API something like quickget --install-here "my-distro.iso" to use in current directory, where someone has already downloaded things.

If anyone wants to script an API function for this, that would be great.

[zen0bit]

I made auto exporting quickget commands for all distros straight to .desktop files.
desktop files use yad. to choose release and edition. then download ISO. so just two choices from list and click ok.

one desktop file per distro

Was done for exporting .desktop files in distrohopper

PS: There is also different project for downloading ISOs linux-downloader for inspiration

linux-downloader supports

Arch-based:	     DEB-based:		  RPM-based:	    Other:		     Source-based:	 Containers and DCs:  BSD, NAS, Firewall:  Not linux:
0 = archlinux	 17 = debian	  34 = fedora	    51 = alpine	     68 = gentoo	 76 = rancheros	      83 = freebsd	       97 = openindiana
1 = manjaro	     18 = ubuntu	  35 = centos	    52 = tinycore	 69 = sabayon	 77 = k3os	          84 = netbsd	       98 = minix
2 = arcolinux	 19 = linuxmint	  36 = opensuse	    53 = porteus	 70 = calculate	 78 = flatcar	      85 = openbsd	       99 = haiku
3 = archbang	 20 = zorinos	  37 = rosa	        54 = slitaz	     71 = nixos		 79 = silverblue      86 = ghostbsd	       100 = menuetos
4 = parabola	 21 = popos		  38 = altlinux	    55 = pclinuxos	 72 = guix		 80 = photon	      87 = hellosystem	   101 = kolibri
5 = endeavour	 22 = deepin	  39 = mandriva	    56 = void	     73 = crux		 81 = coreos	      88 = dragonflybsd	   102 = reactos
6 = artix	     23 = mxlinux	  40 = mageia	    57 = fourmlinux	 74 = gobolinux	 82 = dcos	          89 = pfsense	       103 = freedos
7 = arco	     24 = knoppix	  41 = clearos	    58 = kaos	     75 = easyos		 		     	  90 = opnsense	   
8 = garuda	     25 = kali		  42 = alma 	    59 = clearlinux	    			 		              91 = midnightbsd	   
9 = rebornos	 26 = puppy		  43 = rocky	    60 = dragora	    			 		              92 = truenas	   
10 = archlabs	 27 = pureos	  44 = qubes	    61 = slackware	    			 		              93 = nomadbsd	   
11 = namib	     28 = elementary  45 = nobara	    62 = adelie	    			 		                  94 = hardenedbsd	   
12 = obarun	     29 = backbox	  46 = ultramarine  63 = plop	    			 		                  95 = xigmanas	   
13 = archcraft	 30 = devuan	  47 = springdale   64 = solus	    			 		                  96 = clonos	   
14 = peux	     31 = jingos	  48 = berry	    65 = peropesis	    			 		      			   
15 = bluestar	 32 = cutefishos  49 = risios	    66 = openmamba	    			 		      			   
16 = xerolinux	 33 = parrot	  50 = eurolinux    67 = pisi	    			 		      			   

[zen0bit]

It would be great if we could have some input from @dabrown645 I did invite him but he doesn't seem to have made any comments or commits on his own repo either?

The BIG problem is of course @flexiondotorg 's absence .... He does have a discussion page that we could use, theoretically. I have just looked and found it littered with spam going back for weeks. 🙈

And also @philclifford should join discussion

[TuxVinyards]

PS: There is also different project for downloading ISOs linux-downloader for inspiration
linux-downloader supports

Linux-Downloader was interesting. Just been looking .... Quite a few errors in the code even when you add an SC2034 disable. It would also benefit from using 'sort' to get things alphabetical. The distro function side load file has all the distros all jumbled up too.

Interesting nonetheless. When did you find that?

[TuxVinyards]

"I made auto exporting quickget commands for all distros straight to .desktop files.
desktop files use yad. to choose release and edition. then download ISO. so just two choices from list and click ok."

The trouble with Yad is that it has got out-of-date as and has a lot of issues too. It only runs GTK3. Not a very good look.

I have been looking at GTK4, possibly Gnome Builder. But then the everything starts to get more complicated and less and less people can contribute and join in.

https://wiki.gnome.org/Apps/Builder

I am not very keen on 'Gum' and 'Lipstick' either. Bit gimmicky. All bright flashing pastel colours. The code is not very well written either. I personally like interfaces to be less of the star attraction. They should exist discreetly in the background.

[zen0bit]

Apropo I also made Lets say "overhall" of quickget on my dev branch with nice help message, os info instead of homepages, linting and other changes.

Not yet finalized..!

Not modular but should be implemented..

I think your OS info is no good. It's difficult to read and would be somewhat annoying to implement OSes for. I'm leaving it to individual variables instead, which are far more convenient when they're all in one place. I'm pretty sure I have basic functionality ready in my quickget, if you'd like to test it. Architectures and the prepare_image and config_additions functions aren't quite yet functional in quickget, but everything else should be fine. I don't believe anything major is going to be changing in the template from this point.

I see it as feature proposal.
Implementation could be changed after consent

[zen0bit]

Interesting nonetheless. When did you find that?

A lot of my time gets searching through github and elsewhere for potential usefull software.
(Since I am missing years in linux ecosystem, don't know whats available, and it's constantly changing anyway)

Also helps me (I get daily trending repos for bash, go and rust into github notification)

link

[zen0bit]

"I made auto exporting quickget commands for all distros straight to .desktop files.
desktop files use yad. to choose release and edition. then download ISO. so just two choices from list and click ok."

The trouble with Yad is that it has got out-of-date as and has a lot of issues too. It only runs GTK3. Not a very good look.

I leaved yad (Dont work properly under wayland) for gum (GUI for TUI) (Also like easybashgui)

I have been looking at GTK4, possibly Gnome Builder. But then the everything starts to get more complicated and less and less people can contribute and join in.

https://wiki.gnome.org/Apps/Builder

I will rather don't use big dependencies since I am WM guy
But will look more at builder

I am not very keen on 'Gum' and 'Lipstick' either. Bit gimmicky. All bright flashing pastel colours. The code is not very well written either. I personally like interfaces to be less of the star attraction. They should exist discreetly in the background.

Feature completnes and easy of use. Thats mostly all which matter to me.
(You can choose whatever colors you want. Their pastels are just theirs, you don't have to use them at all)
Since I am not go developer (Can't discuss code)

[TuxVinyards]

BTW update on the qqX dev branch:

I noticed that the setting I said about the other day, for the number of VM's per line, didn't extended to the download interface. I added another setting that allows you to regulate the number of items per line in the quickget section as well now.

I am holding back on publishing a dev branch because there will need to be a fair bit of documentation to go with the new functions. I am still musing on whether to start a Wiki or whether to leave things to a how-to thread as an issue.

I also want to get an Arm distro running too. At least as proof of concept.

[zen0bit]

I am not very keen on 'Gum' and 'Lipstick' either. Bit gimmicky. All bright flashing pastel colours. The code is not very well written either. I personally like interfaces to be less of the star attraction. They should exist discreetly in the background.

Feature completnes and easy of use. Thats mostly all which matter to me. (You can choose whatever colors you want. Their pastels are just theirs, you don't have to use them at all)

And I already implemented colors etc customization in q 💪

[zen0bit]

BTW update on the qqX dev branch:

I noticed that the setting I said about the other day, for the number of VM's per line, didn't extended to the download interface. I added another setting that allows you to regulate the number of items per line in the quickget section as well now.

I am holding back on publishing a dev branch because there will need to be a fair bit of documentation to go with the new functions. I am still musing on whether to start a Wiki or whether to leave things to a how-to thread as an issue.

I also want to get an Arm distro running too. At least as proof of concept.

I dare to say that if your program needs documentation, it might be worth considering making it simpler?

😳 Just noob question for more bash experinced users

[TuxVinyards]

BTW update on the qqX dev branch:
I noticed that the setting I said about the other day, for the number of VM's per line, didn't extended to the download interface. I added another setting that allows you to regulate the number of items per line in the quickget section as well now.
I am holding back on publishing a dev branch because there will need to be a fair bit of documentation to go with the new functions. I am still musing on whether to start a Wiki or whether to leave things to a how-to thread as an issue.
I also want to get an Arm distro running too. At least as proof of concept.

I dare to say that if your program needs documentation, it might be worth considering making it simpler?

😳 Just noob question for more bash experinced users

Unfortunately, the whole topic of non-x86 is very complex. I intend flagging this as for advanced users. The reasons for the docs will be to provide a follow these steps tutorial for a least one or two distros.

[TuxVinyards]

[zen0bit]

Wanna touch that sooner then later 😳

[zen0bit]

Other interesting new project also usinq qemu/KVM virtualbox-kvm

VirtualBox with KVM Backend

[zen0bit]

Interesting nonetheless. When did you find that?

When?
Looks like around Mar 21, 2023 😊

[zen0bit]

Can you move this conversation into discussion @TuxVinyards ?

Much better sorting etc..

[TuxVinyards]

Other interesting new project also usinq qemu/KVM virtualbox-kvm

VirtualBox with KVM Backend

Saw this in my news feed this morning, may be same as you.

Early days for this project. Needs to be a lot more mature. The OS and CPU host spec is quite tight and changes have to be made too. I probably couldn't even build it either, if I wanted to try it. Says GCC 12 or less. I have 13.2 🙄

[TuxVinyards]

Can you move this conversation into discussion @TuxVinyards ?

Much better sorting etc..

So, according to this link here, I can : https://docs.github.com/en/discussions/managing-discussions-for-your-community/managing-discussions#converting-issues-based-on-labels

But if the other people we need are not even going to join in here, we might be coming to an end on this anyway. 😕

If others turn up and want me to convert this, I will have go and see if it works.

We have covered some good ground though. I think some solid outcomes have emerged. 🚀

I note that you have since made a link to this issue/discussion here: quickemu-project/quickemu#925

Lets wait for others to catch up and work behind the scenes to consolidate a little more.

[TuxVinyards]

Closing this now. I think we have all moved on.

I still have concerns but I might be prepared to wrap or mod Rust code if I need to go with the flow ... Let's see what happens ...