Live data from Hacker News

FreeBSD 12.2-BETA1

lists.freebsd.org

1–10 of 55 posts

Re: FreeBSD 12.2-BETA1

#3
Really looking forward to tinkering with this. Is it me, or does it seem that the BSDs are really losing more and more mind share as time marches on? I have very few issues with FreeBSD or OpenBSD beyond the occasional incompatibility, and it's always something minor like suspend or sound that can fixed with a few queries.

Re: FreeBSD 12.2-BETA1

#5

Really looking forward to tinkering with this. Is it me, or does it seem that the BSDs are really losing more and more mind share as time marches on? I have very few issues with FreeBSD or OpenBSD beyond the occasional incompatibility, and it's always something minor like suspend or sound that can fixed with a few queries.

>Is it me, or does it seem that the BSDs are really losing more and more mind share as time marches on

Well BSD is dying was said already 15 years ago, BUT the project should be more responsive, an example:

You send in a patch with a updated port, and you wait 3 month until it's in the tree, in the meantime already a new version is out. I think if the users make the work and send in patches (just with a changed version-number and zero or nearly zero dependencies) some porters @ freebsd should act much quicker (some are super fast and helpfull but not as many), otherwise they will change the os or make there own fork of the package tree like i do.

Re: FreeBSD 12.2-BETA1

#6
As someone who has been using FreeBSD for a long time on various machines of mine, both physical machines in my home and VMs in the cloud, I'm wondering how many people (both in absolute numbers and in percentages) run the beta releases on their hardware.

My general impression, which stems mostly from the description I once read on the FreeBSD downloads page and from elsewhere is that if you want to help find bugs in upcoming releases you run the CURRENT branch and else you run RELEASE. But I expect that there are people running the beta releases as well who make meaningful bug reports that result in fixes prior to release versions being minted – otherwise I think they would not be making beta releases still.

I did used to run CURRENT for a while, but eventually found out that personally I wasn't making any particularly helpful bug reports based on it anyways so I went back to RELEASE.

For the VM server that I have been using for many years now for sending and receiving mail, as well as to host some websites of mine, running FreeBSD RELEASE has been working great for years.

Meanwhile, my desktop computer which is currently running FreeBSD 12.1-RELEASE is having issues where it freezes and requires a hard reboot. But I had this same kind of issue when I was running various Linux distros on this same desktop computer over the past years. I am suspecting that either it is a cause of hardware malfunction or possibly of the Nvidia driver for the graphics card, but I don't really have any way of finding out what the actual problem is. Not the least because of the fact that it will often run for a week of being powered on perfectly fine (both with FreeBSD and Linux distros) until suddenly it just completely freezes. Doesn't react to mouse, doesn't react to keyboard, doesn't respond to ping.

The fact that my desktop computer can run fine for about a week at a time makes it hard to figure out what the actual problem is. Say that I were to pull the graphics card out for example, and it ran fine for two weeks. How do I know at that point that I can really blame the graphics card and it wasn't just random chance that made it run for longer than usual this time around?

I think in order to isolate the problem I would have to build like 8 different physical machines all with the same hardware, and then say ok four of the machines I will initially run like I do with my current desktop, and four of them I will pull the graphics card out of and then have them running 24x7 for a month or until at least two of the machines with Nvidia graphics cards crashed if sooner. At that point I might conclusively say there is strong evidence of problems with the Nvidia graphics cards or with the drivers for said cards.

But if the machines without the Nvidia graphics cards were also crashing then I'd need to swap out for example all of the motherboards and I'd run the experiment for another week. An so on.

On the flip-side, if all of them ran fine for a month with the initial configuration I would conclude that probably some of the hardware in my current machine is just broken, and that there is no bigger issue at play. But all of that would cost not just a lot of time but also a lot of money. And as-is the next thing I can afford to buy is certainly not such an amount of hardware – the next thing I am going to buy when I can afford it is rather a couple of new hard-drives, as the spinning disks that hold most of my data are getting a few years old and I am getting quite nervous about them suddenly going to fail me. I've had hard-disks fail on me in the past. In particular I used to have a machine with 4x 2TB hard-drives in it to provide me with ZFS storage, and then I moved houses and I accidentally dropped my computer from about 1 meter height and last time I tried to see if the drives were working none of them showed up neither after boot nor in BIOS, neither in the original computer that I had dropped nor in the desktop computer that I have now. Well anyways it don't matter too much, none of the data was that important really. And I think said drives were making unusual noises also but I don't quite remember as it was a while ago now. But that kind of experience, along with having had some external hard-drives fail me in the past, does feed into the worry that I have for my current hard-drive as it is getting a few years old now.

But back to what I was saying about trying to debug the issue with my desktop. In theory I could disconnect basically all but the RAM and the CPU from the motherboard (well, and but the fans of course :P) and boot a minimal kernel from a USB stick and have it run in RAM and let it stay powered on for four weeks and see if it crashed, and then if it doesn't to connect the SSD and the HDD to it and run it for another four weeks and see if it crashes, and then to run the regular RELEASE kernel on it for four weeks and see what happens, and after that with the graphics card connected and see what happens for the next four weeks. But all of those weeks man. I just want my desktop to work, I don't want to spend weeks with it running on its own without being available for my use.

Anyways, that brings me to something else related to the testing that people do and that is the fact that I find it kind of hard to know what hardware to pick for a FreeBSD desktop. There's things like https://www.freebsd.org/releases/12.1R/hardware.html and https://wiki.freebsd.org/Graphics and https://wiki.freebsd.org/Graphics/AMD-GPU-Matrix but they all seem kind of out of date.

If I had the money to buy the hardware for it and to pay the electric bills for it I would gladly be running a bunch of machines in different configurations of current consumer hardware and making notes and filing bug reports and hardware compatibility reports to help other users of FreeBSD and Linux. Maybe someday. Until that day I'll just have to accept that every week or so I might have to hit that hard reset button on my desktop, inconvenient as it might be.

Re: FreeBSD 12.2-BETA1

#8

As someone who has been using FreeBSD for a long time on various machines of mine, both physical machines in my home and VMs in the cloud, I'm wondering how many people (both in absolute numbers and in percentages) run the beta releases on their hardware. My general impression, which stems mostly from the description I once read on the FreeBSD downloads page and from elsewhere is that if you want to help find bugs in…

>Until that day I'll just have to accept that every week or so I might have to hit that hard reset button on my desktop

That really must be your Hardware, i have FB12.1-REL and it's rockstable on 5 different Machines from 10yo to 1 two laptops and three Workstations.

And many many VM's and two really big physical servers

Re: FreeBSD 12.2-BETA1

#9
post #5

Really looking forward to tinkering with this. Is it me, or does it seem that the BSDs are really losing more and more mind share as time marches on? I have very few issues with FreeBSD or OpenBSD beyond the occasional incompatibility, and it's always something minor like suspend or sound that can fixed with a few queries.

>Is it me, or does it seem that the BSDs are really losing more and more mind share as time marches on Well BSD is dying was said already 15 years ago, BUT the project should be more responsive, an example: You send in a patch with a updated port, and you wait 3 month until it's in the tree, in the meantime already a new version is out. I think if the users make the work and send in patches (just with a changed versi…

I do agree that the BSD ports maintainers are a fair bit slower than their Linux counterparts. Having said this, though, I do admire the way the port maintainers train up their replacements and/or add others with commit access. They mentor them. This does lead to higher code quality in the end. I fully agree with the notion that BSD is engineered whilst Linux is "grown". Good and bad to both approaches.

Re: FreeBSD 12.2-BETA1

#10
post #5

Earlier quoted context omitted.

>Is it me, or does it seem that the BSDs are really losing more and more mind share as time marches on Well BSD is dying was said already 15 years ago, BUT the project should be more responsive, an example: You send in a patch with a updated port, and you wait 3 month until it's in the tree, in the meantime already a new version is out. I think if the users make the work and send in patches (just with a changed versi…

I do agree that the BSD ports maintainers are a fair bit slower than their Linux counterparts. Having said this, though, I do admire the way the port maintainers train up their replacements and/or add others with commit access. They mentor them. This does lead to higher code quality in the end. I fully agree with the notion that BSD is engineered whilst Linux is "grown". Good and bad to both approaches.

>I do admire the way the port maintainers train up their replacements and/or add others with commit access

Yes absolutely, and it's no question that packaging is really hard work, i wanna thank everyone that works on my most beloved system, ESPECIALLY the packagers.

Post reply on HN