The Promotion Team had a bit of a discussion the other about the Haiku download experience, with @shaka444 pointing out that the current downloads page at https://www.haiku-os.org/get-haiku/r1beta2/ may be confusing for a first-time visitor. He recommends that links to download the latest stable version as well as the nightlies be added to the top of the downloads page, which could be something like this: Click here to download Beta 2 (Stable Official Release)
x86 (for older machines and BeOS compatibility)
x86_64 (for newer machines but may not run some BeOS software)
Click here to download Nightly (Cutting edge, but possibly less stable)
x86
x86_64
We could make some buttons based on the current download now button on the Haiku homepage to spice things up a bit. Since there are multiple download mirrors, we could implement some sort of script which would determine the best available mirror to download Haiku from upon clicking the proposed new buttons.
Additionally, just some other things Iâve noticed about the Haiku downloads experience (both for stable and nightly):
The header in the table showing the download mirrors on the and links doesnât display correctly when in dark mode.
The Nightly download pages (which are, from my understanding generated separately from the main site using a different generation method), arenât visually consistent with the main site and use different fonts (AFAIK the fonts change based on what platform you are viewing the site on), and donât have an auto light/dark mode - not too sure if this is intentional by design, but should we perhaps consider making these pages more consistent with the main site? Also, Iâve noticed the downloads pages do not have a favicon - might be good to add one.
The âNightly Imagesâ tab on the main site (in the same tab group where you can view the latest Source and Ticket updates etc.) doesnât do much but provide a link to the Nightly download pages. It would be nice if a script was written so the tab displays a list of the most recent nightly images and when they were built (similar to the âPackagesâ tab)
The Raw Images column in both 32-bit and 64-bit nightly downloads pages is blank - is this intentional? Have we stopped providing raw image files? Maybe it might be a good idea to remove that column if that is the case?
It would be good on the Nightly pages if we could add âdirect downloadâ buttons (one for 32-bit and one for 64-bit), that when clicked would download the latest Nightly image instantly - it would be faster for people who just want the latest Nightly image.
Generally I agree that the current download page (Get Haiku: R1/beta2 | Haiku Project) isnât great. Before you can get to the actual download link you have to go through:
A thing asking you to donate money
Some info about the current version
Instructions for updating an existing system
Instructions for writing the downloaded image to disk
At this point, probably you are already scrolling past all this without even reading it
A table of mirror locations and architectures you have to pick from
Why canât it be as simple as âclick âget haikuââ â the download starts ?
However, I donât agree with pushing the nightlies as a valid download in this case. More details below.
I still donât understand why people keep pushing first time visitors into downloading nightly builds. Nightly builds are meant as a place for developers to experiment with things and should not be used in production systems. This is why they are not linked from the homepage.
If you think the beta releases are too old, the proper solution is to have more beta releases or provide more bugfixes to them. Not tell people to run nightly builds.
We used to have this (guessing from the IP address and geolocating the user thanks to this) but I see it was removed. I think it is not possible anymore since we switched the website to Netlify? Or at least the existing script couldnât be reused and we need to adjust it.
The point of the nightly images is to allow testing a specific version of Haiku to check if/when a bug was introduced or removed. Donât make it look like they are a supported system that normal users should be running on their computer. It will crash, corrupt your hard disk, and do all kind of bad things. It is also slower than the beta release because it has more debug things enabled. Really, you donât want to use it.
I think like PulkoMandy, the user should guide to the official Release. They are get a more nightly system then updating. Are they split from each other? If not the user should informed that the update can uncomplete, broken files, if processed.
Yeah, good point - I think people have discussed an alternative to waiting a year for a new Beta release but so far nothing substantial has come out as a proposal.
Personally, testing it on VirtualBox, Iâve experienced few issues, but maybe thatâs just me - but that explains why the performance is so bad in VirtualBox.
Can you provide an image?
As for the nightlies page not beeing a dark mode, i am unsure, i didnt make css specific to that page so its possible it gets from somewhere else, Iâll investigate that at some point.
edit: found it now, better yet if you find such blatantly wrong elements would be to file a ticket, there i am more likely to see it ;ï»ż)
It is generally working but there are no guarantees and sometimes it gets badly broken. If a lot of users are using it, developers donât dare to make changes there.
There are two proposals:
Make releases more often
Merge bugfixes into the beta branch
But it also needs people actually taking care of it: nominating which fixes should be ported to the beta branch, and preparing the release schedule (probably making it less feature-based for beta releases)
I feel like having more frequent releases is a good course of action, but of course, this is dependent on whether all the developers are okay with this. I did have the thought of proposing bi-annual releases, but I wasnât too sure whether the developers would like the idea or not and whether such a proposal would be feasible/realistic.
No they canât, the bfs resizing stuff isnât merged yet duo to lack of testing, so you wouldnât get a really useable install by copying just the image since the allocated space is too little for normal use.
Itâs useable live for testing and demo purposes. To address the storage concern, we can add:
âNote: the live usb does not contain sufficient storage for day to day use. (This can be achieved by using the Haiku Installer on a bfs formatted usb drive)â
Working on and stabilizing the resizing functionality sounds like a nicer idea than advertising the live system as capable of something it cant really do currently, yes it has limited functionality, but most stuff breaks down once you cross a certain threshold (say try to install /any/ third party app to make the OS usefull)
The thought here is ease and simplicity. Getting a new user to have a hands-on test drive. Thats what most people do with an OS on a usb stick.
Resizing is the way to go, but for now it can read something like:
âNote: the live usb does not contain sufficient storage for day to day use. Work is being done on resizing the filesystem. For further information on creating a full Haiku install on a usb stick, click hereâ
As you noted the releases are way behind the nightlies. So offering nightlies to the adventurous is understandable with adequate warning!
Some Linux distros address this issue by having three levels of offerings:
Stable- equivalent to our betas
Testing- cutting edge yet generally stable
Unstable- developer testing ground
Personally I think our nightlies are more stable than any âunstableâ distro Iâve ever tried in the Linux world and may be closer to Testing than Unstable. In fact I use nightlies on bare metal as my main OS and have for the past 2 years.
To incite people to use beta over nighlies, they should be told that they are downloading Haiku and that no 3rd party software is included.
Also they should be aware that thereâs no 3rd party software built for nightlies. Except Hakilo repository, everything is built for beta. (This also should be visible somewhere).
Independently of specific Haiku revision stability, installing some 3rd party software on a nightly can results in not working things or cause app server crash.
Letâs be honest, it is working 99% of time but in some cases (for example Flat styles package), people may have to wait till a rebuild or even till next beta is release to see their software working again.
FWIW I still run R1B2 32bit as my main OS in VirtualBox, when checking things on 64bit I use the nightly version, maybe itâs not the best solution, but itâs the best I can have for myself atm.
I often download several operating systems just for interest and testing. I love to play around with new systems, most of times in Virtualbox or Qemu.
I like it if the download link is near to the top on a website, so I donât need to scroll down much or even click onto another link.
In my opinion it is a good way to place the download of the âofficialâ image on the top of a site.
Nightly, unstable or testing images should be placed after the top link.
A new user is more safe to get the âofficialâ image.
To be honest I donât like to read all the stuff around a download page. I search for the key-words âofficialâ, âstableâ or something like this. At next I look for the documentation of this system. And then, if I like to go deeper into this system, I read all the rest and perhaps look for alternative images like a nightly built.
You have answered your own question here. Betas are often way out of date, and if you would prefer people not to recommend nightlies, then you should address the reason why they do.
But I know itâs more work, and you donât have a lot of time. I do appreciate that.
One thing I have often wondered is why we donât have a ârecommended nightlyâ. That would be a recent nightly (maybe 10 days to 30 days old)that has proved to work well.
Nightlies alwyas update to the most recent release when you run pkgman. So this wouldnât work. And when you start tagging something, itâs called a release. We could do monthly releases, but this would require a lot of automation of the release process, that we donât have right now. Otherwise, we would only be doing releases, and never writing new code or fixing bugs.
The last thing I or anybody wants to do is to land the Devs with more work. But the last Beta was issued in June 2020, nearly a year ago. A lot has been done since then.
How about a quarterly release? Might that be feasible?