Understood. I somehow hoped this could be done early in the boot process to catch some cases but I understand it is too much work for an edge case.
Then I will just second brunobastardi’s suggestion up there. I don’t know what this would imply but it would be cool if somehow hrevs could be tagged as either ok or bad.
Another option not requiring work from core devs would be to write a simple optional end-user app that runs at boot just does a http post on boot with a random unique key (created once) and the active hrev version. The server would just count unique random keys and show anonymous stats. Like “253 users alive are on hrev_4423”.
This could even turn into an unofficial compatibility list, collecting some basic tech info. End user could even type a string with their computer model (Like ThinkPad T61) that the app could upload together with the alive token.
Public stats could be shown in the app itself so it feels native and a minimalist public website could show summaries visible for all. There are some privacy implications of course as the server would receive an IP address, but being opt-in and with open code that ensures nothing is kept I think we might get enough participants to get an idea of the situation. Hrevs with highers number of ‘alive’ tokens can be considered more or less safe since users have successfully booted and connected to the web.
I understand nobody is going to write this but I keep it in my little list of projects
The nightlies should be hard enough to find, so that this doesn’t happen. Developers also keep reminding people here on the forum to not use nightlies unless you really want to be helping with the debugging of such issues. Some people keep not listening to us and telling other users to use the nightlies anyway.
We don’t want to track our users. They are free to do whatever they want with their computers and the computer will not “phone home”, no matter what reasons you think could justify it. And especially so a thing that would happen automatically at first boot without a way to block it.
Strongly disagree. Using nightlies is practically essential for Haiku user who really use it, not just install once and post screenshot in social media. Nightlies contains important bug fixes and new features that are needed for some software. Releases are released too rarely to it quickly become obsolete.
sing nightlies is practically essential for Haiku user who really use it,
I can’t really agree with that. For what it is worth… at least Begasus and I run beta4 almost exclusively, without much issue. Also… kind of a requirement if we want to avoid surprises on the haikuports buildmasters
I guess we’re just not doing “cutting edge” enough work to consider the nightlies essential.
Unless you compile your own stuff “some software” definitely does not need nightlies, haikuports compiles against the last beta only.
You, as basically a developer, using a nightly does not mean normal users should do this. I know plenty of people who run beta4 and i wouldn’t recommend the buggy mess that nightlies is at times to them (those important bug fixes are more often than not against issues only present in the nightlies)
Anyhow, we’ve had this discussion over and over. It does not change anything. Nightlies will remain for developers only. Use at your own risk.
I hope that. So nightlies will remain available to everyone and not become hidden or require developer account to access as Pulkomandy suggests.
The nightlies should be hard enough to find, so that this doesn’t happen. Developers also keep reminding people here on the forum to not use nightlies unless you reall
And you (x512 and bipolar} are reinforcing my point. Yes, nightlies are useful to you and me. It’s what I run on my machine as well. But, I’m ready to accept the cost: be careful when updating (by following what is merged and keeping track of wether it’s safe), by reporting pugs or fixing problems, etc. Not all Haiku users want to do that, or even can do that. That’s why, if you go to Haiku homepage, the download button will lead you to the latest release, and this is where most people should end up, at least at first.
And also, we shoulo make releases more often so people don’t end up using the nightlies (and sometimes hitting one that just doesn’t boot).
So far “I” don’t see any use in switching to nightly, for my personal needs (as @BiPolar mentioned) everything is working fine, I don’t have problems running into HW issues (wich could be fixed in nightlies which I doubt).
Aside from system changes, I guess I’m more on bleeding edge packages then most average users are, so yes, new beta would be welcome, but I’m not pushing anything there, in contrast, I try to help out (like checking with the openssl3 package(s) where I can.
Dear All, from the discussions, other than technical, that are going on this thread, makes me wonder what was my mistake? Living with nightlies or posting an issue on this forum?
I reiterate that, I, as one who lives with Rolling linux distributions (Archlinux, Slackware current, at present Voidlinux), I will remain on nightlies
If me posting an issue causes so much agony, bitterness among developers, I will not post any thing with issues related to Kernel panic or such things, after an update
Please refrain from bitterness amongst yourselves (developers)
I regret that I posted this issue…
Sorry
I wouldn’t worry too much, @san2ban, most of us are not native speakers of English, and that can make normal discussions sound harsher than intended. At least, that’s my experience
I wonder who edited the subject line of this post
Some users get to the “regular” level, and can edit titles. I got one of mine edited, and had to revert it because the edit was worse than my original title .
It would be better to report such issues to issue tracker (https://dev.haiku-os.org/), not forum. Testing Haiku nighlies and reporting problems is definitely welcomed.
Personally I wouldn’t mind sharing anonymous data mentioned, if that would be of any use for the development team. Analytics for the sake of analytics doesn’t make much sense, but if it can bring any value to the project, I’d be happy to participate.
That would violate the GDPR of course, but @SantiagoLema mentioned opt-in in his post, and that means one has to explicitly check the checkbox (and not uncheck the checked one) with smth. like “Yes, I’d like to share the anonymous usage data with Haiku developers” before anything is actually sent.
And let me say it again, if the development team don’t see any value in that data then there’s absolutely no reasons to add it. But if you think that can improve Haiku or the development process just a tiny bit then there are users like me who’s ready to help.
Honestly, I don’t see any value in it. If the boot breaks on your hardware a ticket is very valueable. But just knowing HrevXXY was installed less than HrevXXX is not that usefull, it is very noisy data that could have all sorts of reasons, and even if the revision broke booting on say, any cpus with more than 16 cores or something like that you would have no way to correlate that Without also sending a system report,… which is even more data.
In this case I really really don’t see any value in this, best to just report a ticket. : )
As for the mechanism itself to detect a failed boot and offer a repair, it’s a good idea. Windows also does this. I don’t think it makes that much sense on the nightlies though, but on a release image it could be a good tool.
No mistake on your side. You saw a problem, you reported it, it was fixed.
The non-technical discussion is as useful as the technical one, we can share our point of views on what nightlies are for, who should use them, etc. I think it’s important that we try to agree on that and save some confusion and trouble for “unsuspecting users”, while also providing an easy way for people to try the latest code and find bugs before they get into releases. We may all be a bit too assertive in what we say, but I hope no one takes it too personally (if anyone did, sorry about it, I’ll try to make it clearer than what I write is just my opinion, and not some hard facts)
There is one more kind of Haiku users who prefer / need the nightlies - or at least some of them. I know I am of that kind, and I’m sure I’m not the only one:
When I started using Haiku, I tried to port some of my libraries (mainly image processing, object oriented OpenGL APIs, SDL-based libraries, that kind of stuff). With beta4, I had serious issues and couldn’t go far (background libraries missing or incompatible etc). I switched to nightlies hoping at least some of my problems would be solved. And BOOM, I got a nice surprise. Everything I needed was there, and I could easily compile literally all my libraries with zero issues. Granted, I could stop updating to latest nightlies now. But without at least some of them, I wouldn’t be able to use Haiku seriously for my work.
That being said, I am well aware of the nightlies danger, and I proceed carefully with each update, as I explained elsewhere. I also have backups (it’s pretty easy in Haiku),
Assuming everything I need from nightlies would be present in beta5, I might reconsider just using betas, but for now it’s nightlies or no programming in Haiku for me.
Honestly I didn’t see any “bitterness” here, just different opinions (which is perfectly fine). You should not regret posting about your issue.
I edited, as exactly hrev57762itselfis surely innocent in your (and other’s) problem described here - also as I wrote in my post above - this is a a Haiku documentation update.
I left it in the title - as you installed that specific install image where this is the last patch that’s containing - after experienced your issue with KDL. Also others mentioned here - they find it so.
Later mentioned you upgraded from hrev57755.
I used to check Gerrit’s log page - I shared above - to see what are patxhes about. (Sorry for failed first time - since then fixed the link.)
This is because I’m curious people.
What cause your issue in nightly Haiku install image this way must be between hrev57755 and hrev57762, but what is changed in hrev57762 - in itself - can be excluded.
As that was mentioned that boot option - disabling SMP - helps to boot into Haiku … avoid kernel panic KDL during boot.
This way I edited the title to reflect better the situation, however I just hint 57761 as there 3 patches committed altogether and one is relates to kernel’s SMP working - by it’s title.
Other patches are about HaikuDepot and Debugger working,
and there’s one about Haiku teams working - I have not enough (or better : any ) knowledge to exclude or include it as a root cause
This way I hinted with ‘maybe’ the hrev57761 patch can cause this issue, but I cannot be sure about it. It can be totally elsewhere.
If you have such info it is good to put this on the bugtracker, if you edit the title of the thread in this way it becomes too long and it is hard to understand what the topic is about.
