Anyone know if there will be the availability of a QubesOS repository for i386?
I know we can use alien to do it, but hoping for something in the repository?
…why?
Because it would be very handy for people like me.
In other words, programmers that do things like I do.
Would be great to have a 32 bit repository.
Just means compiling the code to be 32 bit instead of 64 bit. Not asking for something that would be difficult to do, but just to have it added for use.
I want to have my 32 bit systems work the same way as my 64 bit systems.
Wen I am building an application that is needing to use the 32 bit system to build on, then I am coding in it, and I want seamless integration, ability to easily copy and paste from guest to guest, memory expansion when it needs it, and all the rest.
Why not?
Tell me you’re a Slackware user without telling me you’re a Slackware user 
Mad respect.
And I would love to have the COMPAQ Evo n150 with Single-Core 700MHz Intel Coppermine CPU and 320MB of RAM work exactly the same as the 64-core AMD EPYC 7742 and 4TB of RAM, but it’s just not going to happen, no matter how much I wish it would 
(I know what you actually mean, don’t worry. Your 32-bit machines are probably much more modern)
You might be able to get most of the functionality running in 32-bit, but I can’t see all of it working 1-to-1 without some heavy patching.
So just to clarify:
Q: Do you want to know if there are i686 architecture packages available for Qubes OS (I’m assuming with SSE2 instructions, unless you have some super old machines like I do)?
A: Not that I’m aware of.
Q: Do you want to know if you can compile Qubes OS to run on a 32-bit machine?
A: Some of them would definitely compile for sure, but I’m guessing you’d have to invest your whole weekend into patching…
In any case, it would be interesting to see what comes of your endeavour.
I would say there are two questions:
- can you run Qubes on i686?
No, you can not. Xen relies on virtualization functions absent in ia32 and even early generation x86-64. - can you run 32 guest on Qubes?
In theory yes, but why?
Well I was talking about GUESTS, but perhaps you didn’t read everything I wrote?
Well, I do use Slackware, but I wouldn’t put Qubes in it thoguh because Qubes and all it’s stuff requires multiple things, one of those is System-D (from what I have found so far as it keeps trying to install SystemD whenever I do anything on non-SystemD operating systems)
I can get 64 bit systems running on a 32 bit system easily, it isn’t that hard.
But I am talking about the guests, as I said in my posts.
So running a 32 bit operating system is something I do all the time, but I just want to get the Qubes functionality in there as well to make them more versatile.
I have my 8086 around, as well as my 286, and my DX2-66 and my DX4-100. As well as some other hardware.
I can use Alien, as stated earlier, to convert the packages and make them work.
I’m just asking if we could get them compiled for x86 as well so that it just there in the repository.
So yes, I can have all their system working on a 32 bit platform. It’s not hard to do.
I know that it can be compiled on and for 32 bit platforms.
I just want a repository for it and fr it to be done just normally instead of having to download all the packages, download all the dependancies, then running my decompilation script and recompilation script for the packages to then install them.
That’s what I have to do at the moment.
I have two 32 bit machines.
One RPM and one DEB.
I have all the dependancoes installed for each package in a 32 bit format.
I run Alien over the Qubes packages, and it sets them to install on a 32 bit environment.
Takes a while to do, but it does work.
Takes a while because if I don’t have the dependancy (either package or the version of the package), I have to find and isntall it myself and then restart the RPM/DEB package converson from 64 to 32 bit from that one point.
But if it is compiled by Qubes personell and set for x86 then it will work fine and everyone can use it easily and all the packages and dependancies will be available.
Well, as I said above, I already have the functionality to do it myself, just is very time consuming to do it every time I have to update just one package.
Can I run Qubes on i686,
YES I CAN.
Well I played Star Citizen on CPUs that didn’t have the later functionalities required. They said it reqiured a function on the CPU. So what did I do… I built the function into the system to not need the function in the CPU, but it just used other calls to do the same thing.
Can I run it on ARM32 and ARM64?
YES I CAN.
Yes, I do, I have 10 different variants of systems that are 32 bit running under Qubes.
Whilst we knew what you meant, we were also considering the fact that other people who don’t code (which you as a programmer obviously do, and I can totally relate to why you’re asking this) might erroneously think that you want to try and get Qubes OS running on hardware that lacks the required ISA, like a PDP-11 or something.
SIDENOTE: If you could get Qubes OS running on a PDP-11, I think that would qualify you for a Turing award 
That’s some very nice hardware. They made those things to last.
I miss the days when you powered on your machine and it beeped chirpily to tell you “everything’s fine”. Nowadays beeps mean something’s gone horribly wrong. The current generation doesn’t know what they missed out on…
I understand what you’re trying to do. I know you’re talking about guests. As someone who cross-compiles a lot, especially across different architectures, I can totally relate to your use case.
For anyone reading this who doesn’t know what we’re talking about:
What is 'cross-compiling', and why would you do it?
Cross-compiling is compiling software to work on a CPU that is a different architecture to the one you’re compiling it on. A common example is when you compile the Linux Kernel on your powerful resource-heavy amd64 machine, and then run it on your tiny RISC-V board.
If you compiled it directly on the RISC-V board, it would likely take a lot longer to compile, because it’s likely the RISC-V board doesn’t have a similar amount of resources as your powerful amd64 machine.
I do like the idea of having a 32-bit repo, though. It works well in your use case. Otherwise you’re reliant on running the entire guest as an HVM with no qubes-tools, or you’re forced to rebuild them from source (which is what the gentoo-minimal template does).
But because, we’re dealing with other human beings, what I would be concerned about from a PR point of view is someone seeing and non-amd64 architecture in the repos and that they would erroneously think that the entire Qubes OS can run on i686…and then complain to the devs.
It sounds ridiculous, but honestly, the way the universe works is "if you can imagine it, it will happen
Would it be worth considering an i686 template in the contrib repo? That way, it could have its own repo similar to the way the other templates do.
As long as it has the virtualisation technology, it can run.
If you change the boot sector and add a few bits of code, you can allow it to run on anything.
I’ll have a look at what a PDP-11 is, I don’t think I know. Then I’ll be able to let you know if I can get it running on one.
Getting it running on ARM is tough enough as it is.
So much to do to make it function correctly.
Back in the day I was playing Quake 2 in competitions on my DX266. Was a blast.
Not to mention the other older games like NetStorm, Shadow Warrior…
The hardware never failed me. And the fact that I would just write code to do whatever I wanted, even update the firmware, was just brillient.
These days they have things locked down and a lot harder to change.
I’ll be letting my daughters first PC be the same as mine…
Toshiba Brick with Orange display running DOS.
Let her play Castle, Digger, Commander Keen, Hugos House of Horrors and all those things.
See where it all came from.
Could probably just let her play those on my Qubes, but that wouldn’t have the same effect.
But I have those systems running on my Qubes anyway.
I have DOS 1-6.22
I have OS/2 WARP
I have Windows 1
I have Windows 3.11
Pretty much every version of Windows that I could hope for really from the older days.
I have my own operating systems as well that I run. (not unix based, but full systems)
I even have the operating system that the man who invented the Internet and SMS created. I run that up every now and again to see how it runs on Qubes as I have software that I use on it at times. That’s a 16 bit operating system, and it works just fine.
Yes, I do a lot of cross compiling too, it is getting more diffucult having to use Debian and all though because of the way they built the systems these days. Cross compiling just doesn’t seem to work properly any more.
I’ve tried compiling to base i386/x86 and it just errors all the time on me saying that it isn’t installed… Yet I have all the i386 packages I need installed, and the executables are there. But it just craps out. And it’s mainly because of System D. So I need to get my i386 systems up and with Qubes packages it makes life easier.
These days I just have a central file server in my networks and the guests can just access that.
So I can copy to and from that as much as I want, it consumes barely any resources on the system fortunately. Just using TinyCore (11 MB) as a micro file server.
They can easily compile it to work on the i386 systems when they do their build, just add it in to their current build process.
With the i386 tools and all, I know many people would start using Qubes.
I run servers on one of my Qubes installations, works beautifully when it’s all locked down properly.
Qubes is great for running servers, if you have decent hardware.
With the balooning features and the GUI features, it makes administration a breeze.
Having the i386 variant of packages easily available would mean that smaller server sides would be of better use.
Same variant of the server… 64 bit, 4 GB. 32 bit, 1.2 GB.
Not to mention the utilisation of the CPU. 32 bit uses it so much less.
Doesn’t have to go from 16 bit loading to 32 bit to 64 bit for running. Then the transitions don’t have to go from 64 to 32 to 16 for interpretation to the base harware. It can just be 16 bit to 16 bit direct communication.
That is what I have found out at least.
I have i386 templates all over me, from Dos to Windows, Unix to BSD, iOS to OSX.
But yes, it is worth considering to have it added to the repository.
I mean Domain-0 doesn’t need more than 2 GB of RAM. So it could actually be run as a 32 bit operating system.
At the moment I’m working on upgrading the systems away from their SystemD variants.
Does prove to be difficult.
Okay, I could get it working on a PDP-11. But unfortunately it really wouldn’t be worth anything as it would take about 376 years to load ready to boot the system.
That would be because of having to keep changing the tapes every few minutes, and rewinding the used ones before it is re-used at times.
If I program a variation of Qubes that uses my own operating system, then I could have it running easily enough. This is due to the Memory requirements of the system and what the systems have.
I have an old HP tape machine from the early 80s that used large tapes.
So I have seen and used this sort of thing in the past. So I still think it would be impracticle to do it.
2 Likes
Side note: I do not think (not until Qubes Air is ready at least) Qubes is great for servers. All the cool stuff is strongly related to the GUI, and if you strip it off it would be no better than any decent virtualization platform like Proxmox.
I completely agree. But then, that is exactly what Qubes does - the
cool GUI stuff for a single user, with some clever networking, and dom0
abstraction thrown in.
If you want to host servers, use a tool best suited for that job.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Well, I find it a lot easier than most things because I can perform more customisation on Qubes than on most other systems as XEN runs a lot faster than others for the tasks that it is to perform.
Qubes is best suited for the job. I’ve been using Qubes and hosting using it for years without issue.
Better performance when using it compared to KVM/QEMU, or VMWare. Many aren’t as good as XEN for the way I do things.
And with this, I can backup and do many things very easily.
So it works perfectly.
All in all, as a server, it’s just perfect.
I don’t know about this Qubes Air thing, have not read about it ever, or seen any news about it.
I don’t understand why @arkenoi is saying about stripping the GUI related things. I think that is a silly idea/thought to have regarding Qubes.
But what advantage does Qubes on server have over xcp-ng?
1: no WebUI for administration, I connect directly to Domain-0.
So the administration side has no immediate connection to the external internet, I actually have to utilise multiple layers of security to gain access.
I think that having the security is the best thing about it. No VNC, No direct connection to or from Domain-0 from the outside internet. Literally great security setup for the whole system.
Someone wrote a script to turn Qubes OS in a network server. The idea behind is interesting although it won’t suit everyone’s needs.
I’ve had that since Qubes 1. Thanks thoguh.
But mine is a bit more advanced than that.
And I don’t see what that really has to do with this topic…