> Status:Resolved / Resolution: Won't Fix
What?
> it's problematic to do properly with the real Windows.
Nevertheless you can run real Windows on Qubes: https://forum.qubes-os.org/t/wip-windows-qwt-user-reports/96....
See also discussion of Spectrum OS on Qubes forum: https://forum.qubes-os.org/t/spectrum-os-discussion/1531.
Would you like to share more about your experience? How resource-intensive is it, what you do, what would a normal workflow look like with it compared to, say, a Fedora desktop?
Actual older than Plan 9 but still alive OSes have done limited and limiting choices but many have something "somewhat equivalent", for instance GNU/Linux cgroups (see FireJail, BubbleWrap etc) or FreeBSD Capsicum. Choosing anything heavyweight is a nonsense.
I love that you can explicitly compartmentalize your digital live into independent VMs with a great unified interface. I have "work" VM which contains all work stuff and "personal" VM for personal things. More thoughts from me: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15.
[0] https://www.qubes-os.org/faq/#can-i-run-applications-like-ga...
[1] https://www.qubes-os.org/security/xsa/
[2] https://www.qubes-os.org/doc/templates/#official
It’s usable and the security benefits are definitely important when working with multiple security domains (separate clients each with their own confidential data and third-party dependencies, where you don’t want one client’s malicious NPM dependency affecting the other).
However, there are cons. It’s only really usable in a stationary environment; it completely kills battery life and even basic tasks such as (non-HD) video display maxes out a single CPU core so it’s just not worth trying on a laptop. Hibernation doesn’t seem to be supported by default which becomes risky when combined with the extreme power usage.
As for performance it is pretty good for what it is. My laptop is too old to do much of anything serious anyways, 2011 x220, but with 16gb RAM I don't really have issues with day-to-day use. I can't play full screen youtube which in other Linux OSes will work so there is something about that pipeline that isn't as performant.
My usual use is running emacs and SBCL, no issues there. I give my work VM around 8gb of RAM and that is more than enough.
One nice thing I have done repeatedly, I have written up a server in my work vm, then cloned the vm with all my code in /home, then reduced the ram on the clone to just enough to run some code as a server, and tested it. Once the code is nice and I would then spin up a fresh VM from the same template but without any of the /home files to run it from, copy the right folder over, and run it for a while in long term sort of testing.
As someone who runs VMs randomly for various reasons it is nice to have them integrated into the machine. Before this I was using a Linux box with KVMs and working from within a VM anyways. Having all the VMs update with only a couple clicks is very convinient, as is making backups of them. Having them all display windows within one desktop enviornment is fantastic for such a small screen.
Only annoyance is having a couple extra clicks to pull the clipboard from one VM to another but I got used to it and it doesn't bother me anymore.
Works fine for me. Did you try alt+F11 and giving enough RAM and CPUs?
In short: we believe the Xen architecture allows for the creation of more secure systems (i.e. with a much smaller TCB, which translates to a smaller attack surface). We discuss this in much greater depth in our Architecture Specification document:
https://forum.qubes-os.org/t/qubes-gpu-passthrough/661
https://forum.qubes-os.org/t/another-2-gpu-passthrough-post/...
See also: https://github.com/QubesOS/qubes-issues/issues/4321.
https://rillabs.org/posts/installing-qubes-os
Overall an impressive and surprisingly well functioning software, given what it does.
Unfortunately - which I didn't write in the post yet, should do - is that I felt I had to switch back to a normal distro again because of a combination of a couple of annoyances:
- The need to manually redirect the USB-keyboard to each qube
- The fact that I couldn't get Debian-based Qubes to respect the font size settings
- The overall relative slowness of the system, causing some already slow software to be even slower
- The last straw: Inability to run Virtualbox VMs in Qubes (which I use to create some course content etc).
The other problem is memory. I have to decide to between Signal Desktop and development sometimes.
But it's my main machine for what I care. I love the peace of mind running random things if the need comes up. For more intensive stuff, media games etc, I have a previous machine running Ubuntu.
Why did you have to do this? In order to type in a qube? My usb keyboard just stays connected to the usb qube(sys-usb) and everything seems to work. I have never changed the qube my usb keyboard is connected to.
I recall at the beginning there was some security question you're asked related to this. Maybe you answered differently than us.
https://forum.qubes-os.org/t/fonts-are-too-small-by-default/...
> - The overall relative slowness of the system, causing some already slow software to be even slower
Often connected to the fact that hyperthreading is enabled in BIOS (and it shouldn't be).
In general, you should try to ask for help on the Qubes forums. Most problems get resolved quickly.
HOWEVER, I like that Qubes has Debian. I'm used to it, it's predictable, etc etc. Some of my work basically even depends on it. With Spectrum I'd have to be stuck with the quirks of Nix, which I understand are less friendly than Debian. If I have the option of falling back to the equivalent of a Debian template, I'd likely switch.
I still wonder why kernels can't just handle this properly.
I've seen it in both Windows and Linux systems, something takes all the CPU or I/O or RAM, and the UI is so starved that you can't kill it.
Shouldn't that already be handled by things like virtual memory, and the kernel scheduler? Why do modern OSes, that have to protect against such complicated attacks like Spectre, struggle to do what the very first multi-tasking kernels promised before I was born?
For some reason the GPU manufacturers have seen fit to limit this to expensive professional grade GPUs, but hopefully we'll see it in consumer hardware soon. Well, except I think Intel already has it in consumer chips, it's just that their GPUs are kinda shit so no one really cares.
Only laptops so far, with 4+ cores and 32+GB RAM and 500G+ disk.
It was working fine on my Lenovo T470p, and it runs pretty sweet on Lenovo P14s. Except that suspend is not working. ( Hopefully is resolved soon ).
It's always a problem with battery, but with suspend working fine it's quite easy to get a solid 30 days uptime even though you move around. ~3h runtime with ~10 vms running.
I wouldn't say it's perfect, but I wouldn't choose anything else if I would do it all over. Totally worth the extreme learning curve ;-)
>The magic SysRq key is a key combination understood by the Linux kernel, which allows the user to perform various low-level commands regardless of the system's state. It is often used to recover from freezes, or to reboot a computer without corrupting the filesystem.[1] Its effect is similar to the computer's hardware reset button (or power switch) but with many more options and much more control.
https://forum.qubes-os.org/t/dark-mode-in-debian-10-vm/3855/...
https://multicians.org/security.html
On X11 and Unix, XTerm's "secure keyboard" input makes X11 snooping impossible.
There is mlockall() but it's a loaded footgun by default, and is rlimit-ed by default because it's not something you want users on a multiuser system to be able to do willy-nilly.
Regarding the Dvorak: It's a PITA. I'm running Svorak A5 currently so the current procedure is:
* Make sure it's the default setting in each template
* Make sure it's the default in XFCE
* Run a cronjob in dom0, this make sure that newly connected USB keyboards are changed to the correct layout aswell.
* * * * * DISPLAY=:0 ~/fix-scripts-xkb
#!/bin/sh
[ "$(setxkbmap -query | grep -oP '(?<=variant: )[a-z]+')" == "svorak" ] || ( setxkbmap se svorak; echo fixed xkbmap )
If you follow this simple step, USB keyboard and mouse input should Just Work in all your Qubes: https://www.qubes-os.org/doc/usb-qubes/#how-to-create-a-usb-...
If you follow this simple step, USB keyboard and mouse input should Just Work in all your Qubes: https://www.qubes-os.org/doc/usb-qubes/#how-to-create-a-usb-...
ok...
> Normal apps like a browser, LibreOffice work fine
Without GPU acceleration, a browser won't work fine
You can use Salt to automate this work: https://www.qubes-os.org/doc/salt/.
My collegue actually runs on 16G, but he has to consider memory when starting a VM, but it's doable.
You can run on 8G, but it wouldn't be a good daily driver. But maybe if you have a very specific purpose?
24G+ is comfortable. I'm currently at 48G and have 43G "mapped" to VMs. It's very easy to use a lot of RAM!
edit: maybe i'm being a bit optimistic for sys-net, which is the vm hosting the driver for the network card: these drivers are included in the linux tree and would need to be extracted and packaged into an unikernel. But for every non-driver vm it "should be easy" to get an unikernel implementation (drivers for paravirtual devices are easy to write).
That's the issue: past IT was made human-centric, the Desktop as the center of the digital World, the humans as someone who bend his/her desktop to his/her needs and desires, with a network to communicate with other humans. Modern IT is "big player centric" and evolve just for their own needs and desires witch happen to be far from all the rest of humans.
Did you remember the big push toward full-stack virtualization (on x86) not so many years ago? Who really need it? In most cases those solutions are just ways to sell hw. Such push turn out to be unsustainable on x86 and so the container era was born, again who need it? Oh, a cloud provider that sell VPS yes, it need both full stack virtualization and various paravirtualization solutions, the rest of the world have no benefit running ks at home, often on a single physical machine. Snap/Flatpack/AppImage? Same story they serve the purpose of giving distro and community independence to commercial players but who need them?
All "modern" IT is prehistoric* respect of original Xerox/Symbolics and even AT&T IT, but sold as new not to improve our life but against our interest giving us just some crumbs and lock-in for the sake of few big players. Those in the FLOSS world who follow the trend are actually workers for free against their own interests.
The demand is "little" just because ignorance is high. And that's a classic in all society, people who know, people with culture, are always a minority, but that's does not means their "desire" are minor, they just know their interest others do not but would benefit equally. And that's why FLOSS should be mandatory and universities MUST be public and well founded to drive the research ahead of the private sector that can only pick some research to implement and sell the outcome not drive the society toward a devastating path.
When saying clicks here I assume you do the copy dance? ( ctrl+insert, ctrl+shift+c, ctrl+shift+v, shift+insert ) It sticks.. nowadays I tend to do that even in Windows.
For me it depends on the specifics of the video, usually ~10 Mbit/s 1080p x264 and YouTube at 1080p is mostly ok, but I don't even need to try 2160p content. (i5-9500T)
Qubes I think could benefit from more resources for ramp-up documentation.
Points 2 and 3 you're right about.
You can convert virtualbox VMs to qubes hvms[1] although it requires a bit of CLI work.
[1]https://www.qubes-os.org/doc/standalones-and-hvms/#convertin...
Disagreed - it does work fine. Maybe there's specific niche features that don't work but I have yet to come across them. Only problem is video decoding which works but uses lots of CPU so terrible for laptop battery life.
I think it definitely had its place before containerization but that is when it took off everywhere. It wasn’t a single push it was a years in the making process.
Linux has many and a set of low level responses to keybondings that must remain responsive that don't have a UI nor ability to kill individual applications.
To be fair in current systems Linux UIs normally remain responsive until memory exhaustion which is handled very badly. You will probably reboot before the oom killer assassinates the offender. The fix is a user space daemon like earlyoom which activates at a configurable level and targeting rather than absolute exhaustion when even killing the offender is challenging and usage has been hard for tens of minutes.
You or your environment can also set your UI process to a higher priority as far as processing and io.
If your UI doesn't remain responsive it's because your distro isn't using existing tools to achieve this.
Now you can't find that kind of computer with swappable batteries anymore and I have work in 3D to do, I don't trust Intel anymore and try to buy AMD, so I'm stuck with windows haha how time have changed.
I'd buy another box capable of running this if I needed a VM lab type setup again. Very cool for that.
A small example: IoT is now a must for modern houses with p.v. etc, Home Assistant is the most well known FLOSS solution. They suggest to deploy it via a docker image, so you need few Gb on disk just for it, relative ram etc. If you deploy via pip is just 321Mb, nothing else. Actually many system package managers support pip integration.
Not only, my entire home infra configuration is an org-mode file, easy to read, share, move just ~2000 lines, with a ks infra? I probably need around 4-5 time the lines in crappy YAML with constant babysitting to keep anything up to date. My actual infra is just two desktop, a laptop, a homeserver and few IoT devices (p.v. system, VMC controlled via ModBUS interface from the homeserver, few others goodies). The sole crappy YAML config for HA is four time* the entire NixOS infra config.
In a single click (on an org-mode link to tangle the config and on org-babel to run terminator and a script inside it) from one desktop or server I can generate a new custom NixOS iso for any other system, copy it to a tftp share for boot or on a ventoy-managed usb stick/ssd and manually boot the target machine. That machine will became the exact functional copy of the original one. With docker and classic distro? Well RH have kickstart is a bit less nightmarish than preseed and it's also limited, build a custom iso is a long process anyway, for Debian based is even longer. I do not know for Arch and co. A custom NixOS iso is just a single (or more, if I want them split) file passed to nix-build '<nixpkgs/nixos>' -A config.system.build.isoImage -I nixos-config=isoconfig.nix for Guix is just slightly longer.
With Plan 9 well, I do not even need an ISO since the infra is also the network... Countless of services and relevant network protocols are meaningless in a live plan 9, for instance sending emails potentially do not demand SMTP, the sender MUA just mount the network share of the recipient and save a file there. All is built-in in the system. Reading a website? The same: mount the exposed filesystem and open documents with your favorite viewer. Want something on another machine? Just open their relevant graphic display and there you go, no need for anydesk/bomgar/teamviewer/citrix/guacamole/*
But I can add more: no need for big cloud infra. These days we have enough bandwidth and computing power to have essentially all the real redundancies we need at home, that scale with the scale of the owner.
Since them all "modern" systems keep rediscovering in limited, limited and bug ridden ways what historical systems have done far better decades before...
I think many should just see classic advertisement like https://youtu.be/M0zgj2p7Ww4 than see it's date and where we are today...
It's not only security it's the overall design. In the past hw resources was limited an so hacks and slowness were common, hw itself being "in a pioneering phase" was full of hacks and ugliness but evolving those systems would have led us too the moon while we are still in the middle age...
P.S. Saw that same "frozen" behavior a few years earlier when trying to wipe drives from a live OS.
Not really qubes specific, you can see the same if you take an ordinary debian-stable desktop linux system with nvidia graphics card and install the xen packages, then attempt to boot into a xen enabled kernel.
"lightweight".