Hi,
Wow man you persevere!! Yeah Virtualbox definitely needs the default Audio driver enabled but in general the experience of doing Audio work in VM's is very sub-optimal, latencies will be 4x what they would be on a hardware machine but obviously VM's are great places to kick tires. As far as the windows once you hit "OK" in the XT-Jack Configuration dialog you can close both of those dialogs and closing the Qjackctl window should keep it running and minimize it to the panel tray..
I did ship EnergyXT in AV Linux years ago but that ended with AV Linux 6.X, in fact the next AVL 2020 release in about a month will be 64bit only and I don't think it will be worth the space on the ISO to include EnergyXT since only you and I still use it...lol. Now that I've figured out what works I will make the packages available so people can install them if they want later.
So it's been a big frustrating day... lets take it slow for a bit. I'm going to post a package of sandboxed free 32bit Linux and Windows VSTs tomorrow and the whole idea of them is to be in a separate location and only for EnergyXT to use.. Obviously the hundreds of 64bit plugins included in AV Linux are absolutely of no use whatsoever to our 32bit EnergyXT binary.
We'll get you up and running with LinuxVST plugs first and then we'll get LinVST involved so we can also use Windows plugins in the Linux version of EnergyXT.. Thank you for keeping on with things, I hope what you learn from this whole experiment will get you better acquainted with Linux Audio... Even if you prefer working in Windows it's better to judge Linux on it's actual merits in a properly set up system to get a true idea of what it's capable of..
EnergyXT 2.7 Linux (32bit) on a 64bit Machine
-
- KVRAF
- 4584 posts since 21 Sep, 2005
Yeah, deffo time to take it easy.
Phew...
We made a lot of progress.
I know VM's are sub-optimal. I'm more than happy to do USB boots or even dual boot when I feel something is worth the while. I feel that AVLinux is deffo worth that!
This is a good place to pause and take stock.
Thanks again AVLinux. Incredible work on your part.
I'll be checking in over the next few days. Taking it slow myself. Anything you need, just ask.
Phew...
We made a lot of progress.
I know VM's are sub-optimal. I'm more than happy to do USB boots or even dual boot when I feel something is worth the while. I feel that AVLinux is deffo worth that!
This is a good place to pause and take stock.
Thanks again AVLinux. Incredible work on your part.
I'll be checking in over the next few days. Taking it slow myself. Anything you need, just ask.
-
- KVRAF
- 2395 posts since 28 Mar, 2007
Is there any advantage of running this on a 64 bit Linux machine ?
Does it allow access to memory above 4 GB for instance ?
It already runs fine on my 64 bit Win 10 machine but is restricted to 32 bit VSTs and 4 GB max of memory.
Does it allow access to memory above 4 GB for instance ?
It already runs fine on my 64 bit Win 10 machine but is restricted to 32 bit VSTs and 4 GB max of memory.
-
- KVRist
- Topic Starter
- 49 posts since 15 Jul, 2014
Hi @dellboy
No the bottlenecks are all the same as they are on a Windows system so no advantage..
As a Linux user I find I can run the Linux binary of EnergyXT with JACK at lower latencies and without audio pops and clicks compared to running the Windows binary of EnergyXT with WineASIO on a Linux system in Wine. These issues may totally be related to my system and not general problems when running EnergyXT in Wine. Any way you slice this it's a bit of a house of cards kludgefest. But for me the proof of concept challenge that I could get my 32bit Linux binary running on a 64bit Linux system as well as host WinVST's 'reliably' in Linux was just kind of a fun side project..
As far as the bottlenecks go I have always used EnergyXT primarily for MIDI to get ideas structured and then I import them into Ardour or Harrison Mixbus to add the Audio parts and mix so in my case I never get anywhere close to the single CPU core or 4G memory restrictions
No the bottlenecks are all the same as they are on a Windows system so no advantage..
As a Linux user I find I can run the Linux binary of EnergyXT with JACK at lower latencies and without audio pops and clicks compared to running the Windows binary of EnergyXT with WineASIO on a Linux system in Wine. These issues may totally be related to my system and not general problems when running EnergyXT in Wine. Any way you slice this it's a bit of a house of cards kludgefest. But for me the proof of concept challenge that I could get my 32bit Linux binary running on a 64bit Linux system as well as host WinVST's 'reliably' in Linux was just kind of a fun side project..
As far as the bottlenecks go I have always used EnergyXT primarily for MIDI to get ideas structured and then I import them into Ardour or Harrison Mixbus to add the Audio parts and mix so in my case I never get anywhere close to the single CPU core or 4G memory restrictions
-
- KVRAF
- 2395 posts since 28 Mar, 2007
Before Jorgen left off developing he did implement multi CPU core in Windows.AVLinux wrote: ↑Fri Mar 06, 2020 3:46 pm Hi @dellboy
No the bottlenecks are all the same as they are on a Windows system so no advantage..
As a Linux user I find I can run the Linux binary of EnergyXT with JACK at lower latencies and without audio pops and clicks compared to running the Windows binary of EnergyXT with WineASIO on a Linux system in Wine. These issues may totally be related to my system and not general problems when running EnergyXT in Wine. Any way you slice this it's a bit of a house of cards kludgefest. But for me the proof of concept challenge that I could get my 32bit Linux binary running on a 64bit Linux system as well as host WinVST's 'reliably' in Linux was just kind of a fun side project..
As far as the bottlenecks go I have always used EnergyXT primarily for MIDI to get ideas structured and then I import them into Ardour or Harrison Mixbus to add the Audio parts and mix so in my case I never get anywhere close to the single CPU core or 4G memory restrictions
I have just looked and it is using all 6 cores on my machine.
Does this not apply to Linux ?
-
- KVRist
- Topic Starter
- 49 posts since 15 Jul, 2014
Hi,
Sorry for the confusion, The last version of XT for Linux was 2.7 and it doesn't have multicore support. This little experiment is with 2.7. You are correct that version 3.0 for Windows has multicore support (I think that was the biggest improved feature in 3.0).
That's what is sad about whatever happened with Jorgen, I think it is such a functional program to be viable all these years later and indeed I think there is even more of a market for the streamlined efficiency of XT now. Not everyone wants, needs or likes the 3 ring circuses of BitWig and other loop based DAWs. EnergyXT doesn't need a rewrite from the ground up... now that multicore is enabled a simple move to 64bit and perhaps VST3 support as well as a binary for all 3 platforms again would sell like hotcakes especially at it's modest price point..
Sorry for the confusion, The last version of XT for Linux was 2.7 and it doesn't have multicore support. This little experiment is with 2.7. You are correct that version 3.0 for Windows has multicore support (I think that was the biggest improved feature in 3.0).
That's what is sad about whatever happened with Jorgen, I think it is such a functional program to be viable all these years later and indeed I think there is even more of a market for the streamlined efficiency of XT now. Not everyone wants, needs or likes the 3 ring circuses of BitWig and other loop based DAWs. EnergyXT doesn't need a rewrite from the ground up... now that multicore is enabled a simple move to 64bit and perhaps VST3 support as well as a binary for all 3 platforms again would sell like hotcakes especially at it's modest price point..
-
- KVRAF
- 4584 posts since 21 Sep, 2005
I think it's testament to whatever programming methodology Jorgen used, that he pretty much got it right first time - that it still works so well all these years later on various systems.
I think he coded it in C++ and that would explain its speed, and cross-platform compatibility. The original XT1 was programmed in Delphi, as was/is FLStudio (iirc). Perhaps it explains its current ability to remain stable. I always think of Jorgen as a hacker, and I'm sure he is to an extent. But maybe he really understands Windows systems as well. And Linux. Perhaps he got lucky, but I doubt it. He's just an exceptional coder. From the base bare metal all the way up to the GUI.
Yeah, the GUI is kinda crude. But all those little tweaks he put in to change things around. It takes a special kind of mind to do that. To my knowledge, no other program like it exists in the DAW world. Perhaps Tracktion. Even with FLStudio they stopped all that changing about of colour schemes. They could have allowed it but they wanted to dictate. That's another argument for another day...
But Jorgen is still a visionary. Look at the work he did with XT1 to make its GUI customizable. There were a few frustrating bugs in it. But look how many people took the time to really make up some exceptional work for XT1. I am not fit to polish their boots. They didn't just mess about with colour schemes. They made up new icons. They also had to battle the far more frustrating GUI editor. I will always be in awe of the work they did. Nothing I have ever done comes remotely close. I just changed a few colour values here or there.
But back to XT2, and how well it's working on modern systems (XT3 with multicore or NOT).
The recent work done by AVLinux only proves that again (what great base code Jorgen wrote). It's shown XT2 to be in a better light than ever. Jorgen was programming for the future. The future arrived. Things still work. Stuff like multicore is nice, but for me XT3 is the slightly most unstable out of the family. Not sure if the multicore is the reason. Having said that, it's still super stable.
Cubase crashes. Studio Pro One crashes. Ableton crashes. FLStudio never used to crash, but lately it's started to do it now and again. XT is no more or less stable than these programs, depending. It doesn't work with certain plugins. It doesn't like Image-Line plugins for example and loses the GUI, but they work on reload. There aren't that many show-stoppers in XT. Waves plugins don't show a GUI, but they work perfectly well with the built in graphics shell.
@dellboy -
Is there any advantage of running this on a 64 bit Linux machine ?
You might like to check out some of the reviews on distrowatch for this particular distro:
https://distrowatch.com/dwres.php?resou ... ro=avlinux
This was the latest review:
No idea why 2018.6.25 isn't available to pick as version, it's what I'm still using, after having run versions since 2016 and installed 5.0.3 on very old hardware once. Despite the presence of some demo-ware of certain paid software, I can't but give a full 10/10 score, in its speciality, out-of-the-box linux audio production environment, there's no better. If you've ever tried optimizing any existing distro for audio use, you may appreciate the invisible work put into compiling a custom rt kernel and setting up all the right scheduling priorities, as a user you will notice a glitch free experience while your CPU power is optimally translated into DSP power at low latencies even on low- to mid range hardware. Add to this full debian compatitibility: all the repos will work, if you want to build, the toolchain is there, too, you can take this insrtallation wherever you want. Linux at its best.
We are talking about the distro in general here, but a lot of that might apply to EnergyXT as well if you run it on that system (which is kind of what you asked).
Does it allow access to memory above 4 GB for instance ?
No 32-bit program will ever be able to handle more than 4 Gigs. It's basic computer architecure and maths. Nothing to do with any program or any OS. A bit is a bit and a byte is a byte and there are only so many bits in a byte, kind of thing.
You can run 32-bit programs on 64-bit OS's but they can not utilise the extra availability to the RAM that the core OS has. It's a bottleneck, that has to be bridged.
It already runs fine on my 64 bit Win 10 machine but is restricted to 32 bit VSTs and 4 GB max of memory.
It runs fine on my WinX machine as well (64-bit).
Again, being a 32-bit program it won't be able to access 64-bit plugins without bridging, and it has no internal bridging like FLStudio or Reaper.
Same thing with access to RAM. Being 32-bit in nature, it can't access more than 4GB of RAM in its address space.
In short, unless Jorgen takes the original XT2 source code and recompiles it for x64 architecture, it will forever remain 32-bit and have the limitations thereof.
But it's not so simple to do that. You don't just reload the source in your IDE and then hit the big RED R--E--C--O--M--P--I--L--E button. It's why devs charge for upgrades to x64 compatibility. It's voodoo to us mere earthlings... (and a pain in the arse for them).
That means it can never access more than 4GB of RAM (even if loaded in a 64-bit OS) and that it can never use 64-bit plugins natively without bridging.
The multicore functionality was surprising to come after many had written off XT. But it did come and it did make a major difference for a lot of people.
For example. I wouldn't use XT3 so much for a production environment DAW like say, 2.7, but it's handy to have on a stable machine so you can load those old projects you maxed out in a new multi-core architecture to take advantage of better CPU utilization. I.e. things just run smoother. And on the whole they do. It works. Pretty well. Load any old project and it translates and it takes less system resources. Thanks again Jorgen!
But 64-bit support is something again. Who knows.
Anyway, I'm resolved to the limitations of EnergyXT2 with its 32-bit architecture. I have full on DAWs with Cubase Pro and Samplitude Pro and Studio One Pro on supercomputers running in the corner of my room. XT2 is just an exceptional program whose likes won't come around again. It's a shame it never got updated, but...
Anyway, some guy (OP) got XT2 to work on a x64 Linux system, which he already 'hacked' the kernel for to provide better RTK support. Real Time Kernel, support. See the review above in this post from distrowatch for a better explanation.
It doesn't work for everyone, and it's not officially endorsed. But it's also testament to those old school hackers, who just asked 'what if?'...
AVLinux asked that same question. Maybe he got lucky?
Shaving off a few cycles here, a few cycles there. Pretty soon we might have a real time DAW system to play with?
Please correct me if I got anything wrong, this isn't really my field. I'm always happy to have any oversights pointed out or corrected.
I think he coded it in C++ and that would explain its speed, and cross-platform compatibility. The original XT1 was programmed in Delphi, as was/is FLStudio (iirc). Perhaps it explains its current ability to remain stable. I always think of Jorgen as a hacker, and I'm sure he is to an extent. But maybe he really understands Windows systems as well. And Linux. Perhaps he got lucky, but I doubt it. He's just an exceptional coder. From the base bare metal all the way up to the GUI.
Yeah, the GUI is kinda crude. But all those little tweaks he put in to change things around. It takes a special kind of mind to do that. To my knowledge, no other program like it exists in the DAW world. Perhaps Tracktion. Even with FLStudio they stopped all that changing about of colour schemes. They could have allowed it but they wanted to dictate. That's another argument for another day...
But Jorgen is still a visionary. Look at the work he did with XT1 to make its GUI customizable. There were a few frustrating bugs in it. But look how many people took the time to really make up some exceptional work for XT1. I am not fit to polish their boots. They didn't just mess about with colour schemes. They made up new icons. They also had to battle the far more frustrating GUI editor. I will always be in awe of the work they did. Nothing I have ever done comes remotely close. I just changed a few colour values here or there.
But back to XT2, and how well it's working on modern systems (XT3 with multicore or NOT).
The recent work done by AVLinux only proves that again (what great base code Jorgen wrote). It's shown XT2 to be in a better light than ever. Jorgen was programming for the future. The future arrived. Things still work. Stuff like multicore is nice, but for me XT3 is the slightly most unstable out of the family. Not sure if the multicore is the reason. Having said that, it's still super stable.
Cubase crashes. Studio Pro One crashes. Ableton crashes. FLStudio never used to crash, but lately it's started to do it now and again. XT is no more or less stable than these programs, depending. It doesn't work with certain plugins. It doesn't like Image-Line plugins for example and loses the GUI, but they work on reload. There aren't that many show-stoppers in XT. Waves plugins don't show a GUI, but they work perfectly well with the built in graphics shell.
@dellboy -
Is there any advantage of running this on a 64 bit Linux machine ?
You might like to check out some of the reviews on distrowatch for this particular distro:
https://distrowatch.com/dwres.php?resou ... ro=avlinux
This was the latest review:
No idea why 2018.6.25 isn't available to pick as version, it's what I'm still using, after having run versions since 2016 and installed 5.0.3 on very old hardware once. Despite the presence of some demo-ware of certain paid software, I can't but give a full 10/10 score, in its speciality, out-of-the-box linux audio production environment, there's no better. If you've ever tried optimizing any existing distro for audio use, you may appreciate the invisible work put into compiling a custom rt kernel and setting up all the right scheduling priorities, as a user you will notice a glitch free experience while your CPU power is optimally translated into DSP power at low latencies even on low- to mid range hardware. Add to this full debian compatitibility: all the repos will work, if you want to build, the toolchain is there, too, you can take this insrtallation wherever you want. Linux at its best.
We are talking about the distro in general here, but a lot of that might apply to EnergyXT as well if you run it on that system (which is kind of what you asked).
Does it allow access to memory above 4 GB for instance ?
No 32-bit program will ever be able to handle more than 4 Gigs. It's basic computer architecure and maths. Nothing to do with any program or any OS. A bit is a bit and a byte is a byte and there are only so many bits in a byte, kind of thing.
You can run 32-bit programs on 64-bit OS's but they can not utilise the extra availability to the RAM that the core OS has. It's a bottleneck, that has to be bridged.
It already runs fine on my 64 bit Win 10 machine but is restricted to 32 bit VSTs and 4 GB max of memory.
It runs fine on my WinX machine as well (64-bit).
Again, being a 32-bit program it won't be able to access 64-bit plugins without bridging, and it has no internal bridging like FLStudio or Reaper.
Same thing with access to RAM. Being 32-bit in nature, it can't access more than 4GB of RAM in its address space.
In short, unless Jorgen takes the original XT2 source code and recompiles it for x64 architecture, it will forever remain 32-bit and have the limitations thereof.
But it's not so simple to do that. You don't just reload the source in your IDE and then hit the big RED R--E--C--O--M--P--I--L--E button. It's why devs charge for upgrades to x64 compatibility. It's voodoo to us mere earthlings... (and a pain in the arse for them).
That means it can never access more than 4GB of RAM (even if loaded in a 64-bit OS) and that it can never use 64-bit plugins natively without bridging.
The multicore functionality was surprising to come after many had written off XT. But it did come and it did make a major difference for a lot of people.
For example. I wouldn't use XT3 so much for a production environment DAW like say, 2.7, but it's handy to have on a stable machine so you can load those old projects you maxed out in a new multi-core architecture to take advantage of better CPU utilization. I.e. things just run smoother. And on the whole they do. It works. Pretty well. Load any old project and it translates and it takes less system resources. Thanks again Jorgen!
But 64-bit support is something again. Who knows.
Anyway, I'm resolved to the limitations of EnergyXT2 with its 32-bit architecture. I have full on DAWs with Cubase Pro and Samplitude Pro and Studio One Pro on supercomputers running in the corner of my room. XT2 is just an exceptional program whose likes won't come around again. It's a shame it never got updated, but...
Anyway, some guy (OP) got XT2 to work on a x64 Linux system, which he already 'hacked' the kernel for to provide better RTK support. Real Time Kernel, support. See the review above in this post from distrowatch for a better explanation.
It doesn't work for everyone, and it's not officially endorsed. But it's also testament to those old school hackers, who just asked 'what if?'...
AVLinux asked that same question. Maybe he got lucky?
Shaving off a few cycles here, a few cycles there. Pretty soon we might have a real time DAW system to play with?
Please correct me if I got anything wrong, this isn't really my field. I'm always happy to have any oversights pointed out or corrected.
-
- KVRAF
- 4584 posts since 21 Sep, 2005
Just downloaded the new guide.
Lots of extra information there to work with. Thanks.
I'm thinking about putting MX Linux and also AVLinux on a new machine. On to the hard disk via multi-boot. The fact they are both Debian based and seem to be working so well at the moment is a major plus.
In the meantime, it's all great and everything that they run so well in Virtual Machines. But I'd like to venture out and go a bit further. I have MX Linux working on a USB stick pretty well and I can boot from there. It would be good to get AVLinux working on a USB stick as well.
I understand there are UEFI limitations, but is there any offhand advice you could give if deciding to install on removable USB hard drives for example? Any offhand advice on USB pen drive installations?
I'm going to go through the documentation.
This is just a cheeky little question while we seem to still have your ear!
(KVR should give you a forum actually for what you are doing and trying to achieve)
Pro's/Con's between USB pen drive vs. USB hard drive vs. System HD.
Persistence?
You've already gone beyond the call of duty AVLinux.
Kudos to you.
-
- KVRist
- Topic Starter
- 49 posts since 15 Jul, 2014
Hi again,
Nice to see a review like that, to be honest I don't spend much time at Distrowatch so I missed that one, I know AV Linux bobs in and out of their top 100 which is not bad for a specialized niche distro but I try not to get distracted by such things, they don't really make the product better or worse...it is what it is
AV Linux on a USB key with UEFI? Simply use Unetbootin to copy the ISO to a 4GB+ key and the 64bit ISO has an EFI boot folder that should be picked up by a UEFI system.
USB key boot gets you about 80% there to a full experience, it is admittedly much faster than a VM and you could get some serious work done but you are running a compressed filesystem which is a bit of a bottleneck as compared to a full install especially if you install to an SSD
Much of the confusion about UEFI is because until a week ago my newest PC was 12 years old and I personally had no UEFI hardware to test on so I had to rely on User Reports. For me personally I have no UEFI booting problems both in a Virtualbox testing VM with UEFI enabled and on my new PC with a Gigabyte X399 Aorus Pro motherboard UEFI also boots and installs fine without any custom settings in the BIOS.
Persistence isn't something I've tried personally in quite some time so I need to try it again. It is detailed how to do so in the AV Linux User Manual starting at page 8: http://bandshed.net/pdf/AVL2019UserManual.pdf
By the way the full AV Linux User Manual is in your manual under 'Accessories' for future reference, the Manual is updated with every release to to keep it current.
If you do a dual boot with AVL and MX I'd suggest installing AVL first (detailed instructions for both UEFI and non-UEFI installs are in the User Manual) then install MX and let the GRUB bootloader from MX find the AV Linux install. I have to admit I run AVL and AVL only so it's been many years since I've personally done a multi boot but many users do..
Pssst... little secret... AV Linux has it's custom RT kernels in a repository and they will install and work just fine with MX Linux.. The only caveat is RT Kernels don't support 3rd party nVidia/AMD Video drivers (not just in AV Linux but across the board).
Nice to see a review like that, to be honest I don't spend much time at Distrowatch so I missed that one, I know AV Linux bobs in and out of their top 100 which is not bad for a specialized niche distro but I try not to get distracted by such things, they don't really make the product better or worse...it is what it is
AV Linux on a USB key with UEFI? Simply use Unetbootin to copy the ISO to a 4GB+ key and the 64bit ISO has an EFI boot folder that should be picked up by a UEFI system.
USB key boot gets you about 80% there to a full experience, it is admittedly much faster than a VM and you could get some serious work done but you are running a compressed filesystem which is a bit of a bottleneck as compared to a full install especially if you install to an SSD
Much of the confusion about UEFI is because until a week ago my newest PC was 12 years old and I personally had no UEFI hardware to test on so I had to rely on User Reports. For me personally I have no UEFI booting problems both in a Virtualbox testing VM with UEFI enabled and on my new PC with a Gigabyte X399 Aorus Pro motherboard UEFI also boots and installs fine without any custom settings in the BIOS.
Persistence isn't something I've tried personally in quite some time so I need to try it again. It is detailed how to do so in the AV Linux User Manual starting at page 8: http://bandshed.net/pdf/AVL2019UserManual.pdf
By the way the full AV Linux User Manual is in your manual under 'Accessories' for future reference, the Manual is updated with every release to to keep it current.
If you do a dual boot with AVL and MX I'd suggest installing AVL first (detailed instructions for both UEFI and non-UEFI installs are in the User Manual) then install MX and let the GRUB bootloader from MX find the AV Linux install. I have to admit I run AVL and AVL only so it's been many years since I've personally done a multi boot but many users do..
Pssst... little secret... AV Linux has it's custom RT kernels in a repository and they will install and work just fine with MX Linux.. The only caveat is RT Kernels don't support 3rd party nVidia/AMD Video drivers (not just in AV Linux but across the board).
-
- KVRAF
- 4584 posts since 21 Sep, 2005
AVLinux wrote: ↑Sat Mar 07, 2020 2:43 pm Hi again,
Nice to see a review like that, to be honest I don't spend much time at Distrowatch so I missed that one, I know AV Linux bobs in and out of their top 100 which is not bad for a specialized niche distro but I try not to get distracted by such things, they don't really make the product better or worse...it is what it is
AV Linux on a USB key with UEFI? Simply use Unetbootin to copy the ISO to a 4GB+ key and the 64bit ISO has an EFI boot folder that should be picked up by a UEFI system.
USB key boot gets you about 80% there to a full experience, it is admittedly much faster than a VM and you could get some serious work done but you are running a compressed filesystem which is a bit of a bottleneck as compared to a full install especially if you install to an SSD
Much of the confusion about UEFI is because until a week ago my newest PC was 12 years old and I personally had no UEFI hardware to test on so I had to rely on User Reports. For me personally I have no UEFI booting problems both in a Virtualbox testing VM with UEFI enabled and on my new PC with a Gigabyte X399 Aorus Pro motherboard UEFI also boots and installs fine without any custom settings in the BIOS.
Persistence isn't something I've tried personally in quite some time so I need to try it again. It is detailed how to do so in the AV Linux User Manual starting at page 8: http://bandshed.net/pdf/AVL2019UserManual.pdf
By the way the full AV Linux User Manual is in your manual under 'Accessories' for future reference, the Manual is updated with every release to to keep it current.
If you do a dual boot with AVL and MX I'd suggest installing AVL first (detailed instructions for both UEFI and non-UEFI installs are in the User Manual) then install MX and let the GRUB bootloader from MX find the AV Linux install. I have to admit I run AVL and AVL only so it's been many years since I've personally done a multi boot but many users do..
Pssst... little secret... AV Linux has it's custom RT kernels in a repository and they will install and work just fine with MX Linux.. The only caveat is RT Kernels don't support 3rd party nVidia/AMD Video drivers (not just in AV Linux but across the board).
Thanks for your time AVLinux. This stuff is absolute Gold to anyone serious about trying this stuff out. And even more so for beginners.
Nice to see a review like that, to be honest I don't spend much time at Distrowatch so I missed that one, I know AV Linux bobs in and out of their top 100 which is not bad for a specialized niche distro but I try not to get distracted by such things, they don't really make the product better or worse...it is what it is
Yeah, distrowatch is more hit than miss, but it's fun enough. AVLinux could be right at the top there and that wouldn't be far wrong either. It has all the programs. It does all the things most users want (instant ethernet connection) etc. etc.
I don't think most people would notice if they downloaded a copy of AVLinux instead of MX Linux. It would still do most of what they want. It's good you don't take it too seriously.
AV Linux on a USB key with UEFI? Simply use Unetbootin to copy the ISO to a 4GB+ key and the 64bit ISO has an EFI boot folder that should be picked up by a UEFI system.
I've been getting good results with other programs as well other than Unetbootin for bootable USB sticks. But it's good to hear you recommend it.
USB key boot gets you about 80% there to a full experience, it is admittedly much faster than a VM and you could get some serious work done but you are running a compressed filesystem which is a bit of a bottleneck as compared to a full install especially if you install to an SSD
Yeah, all that running in and out of the HAL and back again. I once made up a Linux Mint USB install from a VM, and it took about 12 hours to write to the stick. The funny thing is, it worked! The HAL must have been going insane, but I got a fully working install out of it.
As for the compressed file system, I take it that is something like Knoppix, which also uncompresses on the fly? Ah, edit, scrap that. I see, compressed VM disk, you mean. Yeah, definitely. Surprised it works at all some times. And works pretty well at that. But for someone hacking custom kernels, it must be quite an insult to see people like me running your stuff in VM's!
Let me metaphorically slap myself!
There you go. Sorry about that.
I have a rough idea of performance hits and don't have unrealistic expectations. Btw, I sometimes run Windows VM's from inside Knoppix (which as you know is a LiveCD environment only - no one really runs it off disk).
Much of the confusion about UEFI is because until a week ago my newest PC was 12 years old and I personally had no UEFI hardware to test on so I had to rely on User Reports. For me personally I have no UEFI booting problems both in a Virtualbox testing VM with UEFI enabled and on my new PC with a Gigabyte X399 Aorus Pro motherboard UEFI also boots and installs fine without any custom settings in the BIOS.
There's a lot of confusion about UEFI. I've been through a lot of it. Most the time if it doesn't work I just bury my head in the sand until it does work!
My BIOS resets the VM settings on the chip sometimes (VT-x instructions). What can you do. I fiddle a bit more until it starts working again.
Persistence isn't something I've tried personally in quite some time so I need to try it again. It is detailed how to do so in the AV Linux User Manual starting at page 8: http://bandshed.net/pdf/AVL2019UserManual.pdf
By the way the full AV Linux User Manual is in your manual under 'Accessories' for future reference, the Manual is updated with every release to to keep it current.
I can do all that. I usually do RTFM. Very few distros really handle persistence elegantly. MX Linux funnily enough does it pretty well. I'll work it out.
If you do a dual boot with AVL and MX I'd suggest installing AVL first (detailed instructions for both UEFI and non-UEFI installs are in the User Manual) then install MX and let the GRUB bootloader from MX find the AV Linux install. I have to admit I run AVL and AVL only so it's been many years since I've personally done a multi boot but many users do..
This is pure Gold! Thanks for the information!
I'm not ready to dive in yet, but I will be soon. I'll be trying out my trusty Terabyte Bootit Bare Metal.
Pssst... little secret... AV Linux has it's custom RT kernels in a repository and they will install and work just fine with MX Linux.. The only caveat is RT Kernels don't support 3rd party nVidia/AMD Video drivers (not just in AV Linux but across the board).
This is also a good thing to know.
The choice of MX Linux is pretty arbitrary for me. It's a nice coinkydinky that AVLinux not only runs off the same flavour of Linux, but the same stage in development. Maybe why things have worked so well.
It all falls apart at the seams on next test.
This stuff is just fun for me.
I'm not doing any production in Linux for sure.
But then again, it would be good to get a nice system going. I'm looking at Harrison Mixbus actually for my new Soundcraft USB Mixer.
https://www.youtube.com/watch?v=zScpdyvJ8JA
Video is a coupla years old now. Just looking in to options.
Thanks again for taking the time to share.
Much appreciated AVLinux!
