1

Topic: Clarity re releases and updates

I have read through the various pages about releases and updates, and I am still a little hazy, maybe due to terminology.  I have been using fixed release Linux's since the 1990's and have no questions about them:  You install a release, then run periodic updates on that release until its EOL.

The docs for hyperbola indicate you can upgrade any time by running pacman -Syyu (or -Syuu?), but it also mentions something simillar with respect to upgrading from v0.1.  It almost sounds as if you will someday be able to upgrade from milky way to Canis Major by doing the same.  If so, then I would be upgrading to a new release rather than simply applying updates to the current (Milky Way) release.

What I am looking for is something more along the lines of other fixed-release software.  Is Hyperbola's model the same as these, or is there a subtle difference, given it comes from a rolling-release (Arch) based distro?

I'd also like to know if VirtualBox will be supported on Hyperbola.

Thanks for your responses.

2

Re: Clarity re releases and updates

not virtualbox, but virt-manager works well for what you need.  wink just takes a bit of workarounding.

HyperbolaBSD: The Future of Secure Libre Lightweight Operating Systems!

3

Re: Clarity re releases and updates

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).

4

Re: Clarity re releases and updates

So no one is sure how the LTS will work?  Is this still being worked out?

5

Re: Clarity re releases and updates

inquisitor wrote:

So no one is sure how the LTS will work?  Is this still being worked out?

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.

6 (edited by inquisitor 2018-10-22 01:40:31)

Re: Clarity re releases and updates

Emulatorman wrote:
inquisitor wrote:

So no one is sure how the LTS will work?  Is this still being worked out?

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 have already read those pages about the release, and I find them incomplete or inconsistent.  In fact, it was reading those pages that led me to inquire here.  Please read my initial post again.  What I am asking is what distinguishes an update to the current release versus a complete upgrade from the current release to the next release.  It appears that applying the usual "pacman -Syyu" could do either, based on what is written on those pages.

I am guessing that, at this point, the actual implementation of these two paths is not fully worked out.

7 (edited by freemedia 2018-10-22 01:47:18)

Re: Clarity re releases and updates

inquisitor wrote:

What I am asking is what distinguishes an update to the current release versus a complete upgrade from the current release to the next release.  It appears that applying the usual "pacman -Syyu" could do either, based on what is written on those pages.

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.

8

Re: Clarity re releases and updates

inquisitor wrote:
Emulatorman wrote:
inquisitor wrote:

So no one is sure how the LTS will work?  Is this still being worked out?

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 have already read those pages about the release, and I find them incomplete or inconsistent.  In fact, it was reading those pages that led me to inquire here.  Please read my initial post again.  What I am asking is what distinguishes an update to the current release versus a complete upgrade from the current release to the next release.  It appears that applying the usual "pacman -Syyu" could do either, based on what is written on those pages.

I am guessing that, at this point, the actual implementation of these two paths is not fully worked out.

Hyperbola is a LTS distro, it means that reinstalling is required for a next major release. However, since it's an Arch-based distro, "pacman -Syyu" could work for those cases too, so if it's possible between Milky Way and Canis Major, i will create a migration guide like the migration between Milky Way v0.1 and v0.2 that was a drastic structural change (eg. systemd to OpenRC).

9

Re: Clarity re releases and updates

inquisitor wrote:

It appears that applying the usual "pacman -Syyu" could do either, based on what is written on those pages.

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.

10

Re: Clarity re releases and updates

Emulatorman wrote:
inquisitor wrote:

It appears that applying the usual "pacman -Syyu" could do either, based on what is written on those pages.

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.

I kind of figured this is still being developed (I mentioned this in my previous post, too).  If LTS is possible, I just hope that a minor typo does not cause a release upgrade when what I really wanted was to just apply updates to whatever release I have installed.  And that sort of typo seems very possible given that you are trying to create a fixed, stable release from a rolling distro.

I am very excited that an arch-derived distro could become LTS sometime in the future.  I have been looking for fixed release non-systemd distros for a few years now and have been very disappointed.  So far, only the Devuan-based distros seem to be candidates.

Thank you for your response.  I wait, patiently.   Please keep us posted on progress.  I would be willing to help test the mechanisms in VMs and a test box (hardware) here.

11

Re: Clarity re releases and updates

inquisitor wrote:

Thank you for your response.  I wait, patiently.   Please keep us posted on progress.  I would be willing to help test the mechanisms in VMs and a test box (hardware) here.

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. smile

12

Re: Clarity re releases and updates

Hyperbola is a LTS distro

this sounds awesome.

Emulatorman wrote:

the migration from the systemd's file system hierarchy to FHS and OpenSSL to LibreSSL,

<3

keep up the good (fantastic) work.

13

Re: Clarity re releases and updates

freemedia wrote:

keep up the good (fantastic) work.

Thank you for supporting Hyperbola! smile

14

Re: Clarity re releases and updates

I'm figuring that if there are separate, distinct repositories per release, then a simple "pacman -Syyu" would not upgrade to the next release!  (Have I just answered my own question?)

15 (edited by freemedia 2018-10-23 04:46:27)

Re: Clarity re releases and updates

inquisitor wrote:

I'm figuring that if there are separate, distinct repositories per release, then a simple "pacman -Syyu" would not upgrade to the next release!  (Have I just answered my own question?)

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.

16

Re: Clarity re releases and updates

@freemedia:  Your sentiments about the sad state of affairs in the Linux world reflects my own very, very closely.  In fact, you and I could possibly be twins, idk.

As for my own testing approach, I always install to a VM first and try things there.  If the distro/release is not well-behaved or is basically non-functional or even destructive, then I don't have to worry a lot about damage to actual hardware and drives (I mean, my data for all the other VMs and my host of course).  I like to allow any distro I am serious considering for use to "soak" a bit, assigning it to do one function or another I need done so that I will be actually using it to put some miles on it and observe its behavior, including applying some updates, etc.

VMs are oh-so handy... I don't know how many potential disasters I've avoided by creating these test environments FIRST before adopting new distros for actual hosting on hardware.    Just my own 2c, and I don't claim mine is the best in every aspect; after all, no test of any system is as realistic as running a system on actual hardware.

17 (edited by zapper 2018-10-30 03:09:22)

Re: Clarity re releases and updates

Emulatorman wrote:
freemedia wrote:

keep up the good (fantastic) work.

Thank you for supporting Hyperbola! smile

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. smile

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 wink

HyperbolaBSD: The Future of Secure Libre Lightweight Operating Systems!

18

Re: Clarity re releases and updates

Oh and by the way, I don't trust/like the idea of systemd either. hmm

HyperbolaBSD: The Future of Secure Libre Lightweight Operating Systems!

19

Re: Clarity re releases and updates

"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?

20

Re: Clarity re releases and updates

freemedia wrote:

"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?

No I mean, my os is encrypted, but the vm would not be.  That's all. Or is that not a problem?

Just wondering...

HyperbolaBSD: The Future of Secure Libre Lightweight Operating Systems!

21

Re: Clarity re releases and updates

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.

22

Re: Clarity re releases and updates

freemedia wrote:

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.

Good point I guess then I can do testing if I want to then.

HyperbolaBSD: The Future of Secure Libre Lightweight Operating Systems!

23 (edited by inquisitor 2019-03-22 09:32:21)

Re: Clarity re releases and updates

It has been a while since I posted about LTS support in Hyperbola.  I see that the wiki has been gradually receiving updates on this topic.

Again, what I am looking for is true LTS releases.   I understand full well that Hyperbola is based on Arch, which is a rolling distro.  Support for LTS requires some variation from the way Arch does things, and it was admitted in this thread that LTS support is still a work in progress.  I have no issues with any of that.

My only concern, really, is that of accidentally applying a release upgrade when I only want LTS security/bugfix patches, because that is the whole point of LTS, and nothing else.  The idea here is to simply keep an already stable release of a distro continuously stable and up to date (so far as that can be done given whatever restrictions the release constrains users to, such as a certain level of library support, etc.).   

We don't need to get into the weeds right here, necessarily, about exactly what constitutes a particular release of Hyperbola LTS.   I just want assurance that a call to pacman won't accidentally apply undesired updates that would essentially upgrade me to a new release, possibly destabilizing my system due to its having the "latest and greatest."   I need stability and reliability, not the latest bells and whistles -- VMs are good for testing those.

Thanks for the good work being done here.   Please continue to post to this thread as new developments in LTS support arise.   Meanwhile, I will be testing development releases.