You can also use QEMU/KVM without virt-manager e.g. via AQEMU (jyou might need to add your user to the kvm group beforehand).

I suggest you read our article about our releases for further info about it. Anyway, there are other important articles that explain how our distro works such as our main wiki article and FAQ.

i am also curious about this. ive used pacman in the past, most likely with parabola (or connochaet os) but above all, i am simply curious "does it really work like that?"

or in other words, how reliable is doing a full upgrade that way (how often does it hose the install in a way that requires a couple hours to fix up?) you can get the how-to from a page that says how-to, but it wont usually include the typical experiences people have in practice. which is what i gathered from the original post.

If it isn't possible, i will post a news about it or a modification in our pages. Remember that all Arch-based distros are based to work on a rolling release environment. Unlike them, we are developing a LTS distro using an Arch design that was adapted to be rolling release, that is a new paradigm in comparison to those distros. It's a new experience for us, so we are learning along the way to implement this new idea as a new Arch-based distro.

Cool, thank you for supporting Hyperbola! Since we are developing a new structural change in Milky Way v0.3 such as the migration from the systemd's file system hierarchy to FHS and OpenSSL to LibreSSL, it could cause stability issues in the next Milky Way release. So we will need help from you and other users to test those new implementations from our testing version before release in our stable one, i let you know when it's ready.

Thank you for supporting Hyperbola!

so about me: i have used pacman, and arch, parabola, connochaet os, but not recently.

and not primarily. and i have the same questions as you.

heres what im getting as the answer:

using hyperbola and expecting exactly the same behaviour that you would get from arch is going to be weird sometimes, because it is moving away from rolling, towards lts.

the command youre talking about upgrades rolling. hyperbola is moving towards lts.

these are two different things. so it might be different.

i was in your shoes a few days ago, where i kept asking the same question because it seemed like a very reasonable, very simple question (and probably was) and i kept getting replies that didnt quite answer the question.

and if im getting emulatorman right-- its not because your question isnt reasonable, its because the right answer (about hyperbola) fits a slightly different question. which is why yours keeps not getting quite answered. no one is being obtuse here, theyre just trying to give you the correct answer.

if hyperbola were something i worked on and i could give you an authoritative answer, i would say "we dont know what it will do at this time-- and this is why."

which is what im hearing as the reply. but i could be way off.

im excited though, because i like to offer people a fairly stable system. rolling is never the best option for that. it can be acceptable, but lts is the definition of the thing i like to offer (recommend to) people. which makes hyperbola a better option for me than parabola (let alone arch, i am not a systemd fan.)

"but how do you do an upgrade, then?" you might ask.

i think the answer is "we are working on it..." but again, i could be way off. im new to hyperbola, it has every mark of a work in progress, but i like the direction-- a lot. im not sure i could find an arch-like distro that was closer to what i want in a distro. from what ive learned so far.

but i will definitely have to wait to find out. i might play with hyperbola soon (its on my list) but that might not tell me everything i need to know about its development. because its a work in progress.

i never play with distros by installing first. first i remaster. then i run live. if i really like it, i try the installer. since i can do some upgrades directly onto a live dvd, how to upgrade an installed system isnt always a big deal for me. getting rid of systemd (and all redix-like garbage) is a big deal.

what happened was, a few years ago everything got pretty weird and unstable all of a sudden-- as if a weapon were dropped on the gnu/linux ecosystem. its been pretty weird ever since. everyone is working to work around that-- and its hard not to feel like that was the idea. old simple questions like "does gnome work?" the effect of what happened is far more questions end with "we dont know for sure."

4 years ago, these were simple questions with simple answers. look around, everywhere its a mess. i helped someone install debian 8, then we went to copy stuff from the usb-- vfat, of course.

wait, it wont mount vfat. check if the module is loaded. ok, rmmod, modprobe. its still not mounting. look up the problem of mounting a usb drive on a debian 8 install.

we have to reboot.

WHAT?! we have to REBOOT to mount a usb drive?

the module was right there in lsmod. it just wouldnt run without the reboot. (the reboot fixed it. it was like using anything other than debian, what a scandal.)

redix exists. i think its over a decade since things were this ridiculous.

# mount /dev/sdb1 /home/new/usb # how does this suddenly not work, in one of the most mainstream distros since the 1990s?!

no feature works all the time without a fix. thats really not what this is though. i mean the status quo of the ecosystem is a complete absurdity now. i dont blame hyperbola for that. its par for the course, its endemic these days. blame arch for this one.

every maintainer of a mainstream distribution who chose to step aside and let this take over completely dropped the ball on this. its been 3 or 4 years like this now. it will be a little bit longer.

all in all, its a really epic hack-- one of the most epic of all time. it got a much smaller pwnie than it deserved. what it really earned is some kind of alicorn princess award. ask yourself how many famous hacks took half a decade to fix, when people already knew about them?

kevin mitnick was banned from using computers and worked on social engineering, i dont think people have any idea how destructive that form of hacking can be. most of the redix threat is social engineering. some of it is just bad software design. it takes social engineering to get stuff like that into our ecosystem. and even if you get it off the computer, the damage to the ecosystem is already done.

the halloween documents werent primarily technical, they were about social engineering to disrupt progress. just look how much you can screw up with that. history gives us only small handfuls of merry prankster, whitehat social engineering experts. we need more of them. the world needs more of them. happy hacking.

He is right, this is a fine, very excellent distro. 

I do wish to ask though something, would it be possible to make a guide to installing Hyperbola on non librebootable systems with either A: /boot unencrypted and everything else encrypted, or B: /home and /root encrypted and maybe /var or C: full encryption including /boot.

I just would like to be able to use this on other laptops in the future.  Especially if the eoma68 libre laptop becomes a possibility, with risc-v or not.

I just don't know if its wise to have a vm open with an unencrypted operating system connected to my internet within my Hyperbola os.   If it does work though, I will gladly test it when I can.

PS: I did something dumb and had to reinstall Hyperbola, I did rm -r to my /home folder somehow, long story short, DO NOT DO THAT!

;p

But yeah it was an accident.  I was trying to delete something off of my flash drive and it wasn't letting me do so.

learn from my mistake

"I just don't know if its wise to have a vm open with an unencrypted operating system connected to my internet within my Hyperbola os."

im really curious, how would encrypting the os help in this situation?

i dont know how it would be a problem. your os has access to the partition once it is mounted, whether it is encrypted or not.

so as long as you are mounting a partition, the encryption should count the most (or only) when the partition isnt mounted and the os doesnt have access.

like when the machine is off, or when your secret partition is unmounted and nothing else can get to it. when youre running, i dont think encryption helps the partition your os is on-- while mounted. whats mounted in qemu that would be protected by being encrypted while still mounted?

on the other hand, you could have a partition or file on your host machine for qemu to use, and the host machine (rather than qemu) would encrypt it.

this depends on your qemu setup, but my understanding is that only unmounted partitions are really being protected. no one can touch them until theyre mounted again. i can think of any way that qemu makes you less safe in this regard-- unless you are using the same passwords from in the vm that you use on the host. the host could be better protected if it has more recent security updates than the client os. solution: use different passwords/keys for the client os. which you likely would anyway. and run updates if youre going to use the vm for everyday tasks, rather than trying the os.