Will TrueOS always be following FreeBSD CURRENT?


#1

This is just a FMI (“for my information”), out of curiosity, question:

Will TrueOS always stick to the CURRENT branch of FreeBSD or will it “settle” for RELEASE when FreeBSD 12 goes RELEASE, as well?

I couldn’t find any info on that here or the TrueOS website, that’s why I’m creating a new thread - although I might have read something about it but forgot what and where…

I’m wondering if “the Moore Bros.” initially chose CURRENT because they wanted “bleeding edge” as a principle or because v12 had something they wanted that v11 just didn’t.


#2

as an end user, I believe they intend on following CURRENT.

Latest hardware support, and to help test things for FreeBSD, and move FreeBSD in a direction


#3

Yes to both. There were things in v12 that they wanted weren’t in v11, and the only way to get the newest stuff is to stick with v12. As for when v12 is released… v13 will have all the new supercool stuff we’ll want to have, so we’ll probably keep tracking with Current then as well.

We’re waiting on Rod to create and support the FreeBSD-FUTURE branch so we can follow that. :sweat_smile:

Just so there’s no confusion… I just made that up. We plan on following FreeBSD-Current for the forseeable future.


#4

i have FUTURE ready, but the real world isn’t :sunglasses:


#5

#6

You want (the) FUTURE?

You can’t handle (the) FUTURE!

:slight_smile:


#7

Does this mean that we’ll never see a fully stable TrueOS RELEASE version and that TrueOS is some kind of experiment OS? This unlike PC-BSD were we knew was stable when there was a RELEASE update.

The reason I’m asking is that when I read on this community I notice that for every CURRENT update there seems always to be some problems with things that stop working and so.

If that’s the case, thus it means that if we want a stable BSD desktop OS and not something for developers only, we have to stay with PC-BSD 10.3 or look for something else like Linux or so.

The reason I started to use PC-BSD was because I wanted a OS that was rock solid and not some, I don’t know how to put it, maybe “picked up parts” like Linux where the kernel comes from one place and then some mishmash from a lot of different developers and distributions.

But if TrueOS won’t be rock solid, but some kind of bleeding edge test OS to see if the latest and coming versions of FreeBSD works, then sadly I guess my only choice is to leave it and look for something else. However, if that’s the case I will surely miss the nice and very stable ZFS filesystem that AFAIK PC-BSD/TrueOS are the only graphical easy to use desktop OS’s that uses.

I don’t mean to be disrespectful to you developers and I don’t know if I misunderstood it all, if so, please correct me.


#8

This is a more complex issue than that question makes it appear. So bear with me while I try to explain. The issue at the end of the day is what you consider ‘stable’. Does that mean ‘no changes’ or does that mean ‘does not crash’. While many people instinctively consider those to be the same thing, they are actually quite different. Most people usually fall somewhere on the spectrum between those two options… without knowing where you define it, I’ll do my best to answer.

Right now things are unstable. This will not always be the case, but it has been right now. Usually the knee jerk reaction is to blame a rolling release model, as to why things are unstable, but that’s not accurate. A rolling release model can actually be incredibly stable, my ArchLinux (rolling release)box has been orders of magnitude more stable than my Fedora (versioned stable) box. The issue we are having with TrueOS right now is that we have some many major moving pieces at the moment. The new Intel graphics stack is currently evolving, and we are pushing that as soon as it’s out so we can help find the bugs so that it will be stable. The change to OpenRC has also been a massive shift in things and we are finding all the bugs in that as well. Normally we will not have two major pieces of the OS both undergoing massive development at the same time. We decided to run with them right now because us dealing with the fallout now will help the code become stable faster, which will lead to TrueOS become more stable sooner. Since there are so many issues, no branch is truly ‘stable’ so we’re pushing the changes out and down the branches as soon as we get them to try to help stabilize things as soon as possible.
I used to run the PC-BSD Current Edge branch before and never had issues… once we get all the major problems ironed out, the stability will be similar. We will only be pulling in new smaller things as they happen, and we can test those with in the TrueOS unstable branch.

Again, we need to get over the initial hump of all these massive changes and then things will smooth out.

The current instability wont always remain. However I’m unable to tell you at this point in time how long it might take till we iron out all the issues. With limited manpower and resources… we can’t estimate an approx date.

I certainly didn’t take any disrespect from what you wrote. You were straight forward and honest about your thoughts and asked questions to find out if what you were thinking was correct or not. That’s perfectly fine in my book. :slight_smile:


#9

Very good points made here. Stability sometimes depends on a specific hardware configuration and a users workload. The OpenRC migration is a good example of that; the team has done a good job of converting the daemons they know about or are most likely to be used, but they can’t know what packages/ports are being used by everyone.

Some of the recent posts to FreeBSD svn-src-head looks like a lot of churn and “problems” but if you read them closely, they can be extreme corner cases or affect only a single architecture (like ARM). Sometimes there are periods of instability as things change on head, but the TrueOS folks aren’t blindly following FreeBSD-12-CURRENT.

The more folks that use TrueOS and report bugs with enough information, the quicker things will stabilize. The Intel graphics is a good example of that; yes it’s not fun when your screen locks up or the system panics, but that’s the beauty of the boot environments (rolling back to one that works).


#10

TrueOS being based on CURRENT has actually been a disaster for me in comparison to PC-BSD, but I’m likely in the minority. FreeBSD 11 would actually work fine for me to the point that I’m tempted to switch to it, but getting FreeBSD working as a desktop instead of a server is not the sort of thing that I really want to have to deal with. Without something like PC-BSD or TrueOS, using FreeBSD for the desktop starts looking a lot like the pain that is Gentoo…

But the FreeBSD kernel doesn’t support any sort of modern sound card (e.g. as far as I can tell, it supports zero PCI-E sound cards, and it doesn’t support most USB sound cards, so if your sound card isn’t built into your motherboard, you’re screwed), and my motherboard doesn’t have a sound card built in, so I need oss in order to get sound working properly, and unfortunately, oss doesn’t have anyone maintaining it in ports at the moment, so it doesn’t build with CURRENT right now, whereas it does build with 11. At the current rate, I’m probably going to have to figure out how to fix that myself, but figuring out what broke it and fixing it will be a time-consuming process, and I haven’t had time to sort that out.

The other big problem for me is that the FreeBSD devs have been mucking around with the stack unwinding code. They switched to using libunwind, and when they did that, it broke D programs (they now get a bus error whenever an exception is thrown), and since I’m a D developer, that’s a big problem. I did spend enough digging into the bus errors t to figure out the that the problem was libunwind, and initially, I could rebuild the base system with a setting to turn off libunwind and revert to the old stuff. But then they got rid of that setting and disabled libunwind, which should have fixed the D programs, since it then is theoretically using the old stack unwinding code, but they didn’t simply revert it, and whatever they did, it results in the same bus errors that libunwind had any time that a D program throws an exception. So, now, I don’t even have a workaround.

I don’t know whether the problem is a FreeBSD bug or one in the D compiler or runtime, but it means that I have to do all of my programming on my linux laptop instead of my main desktop. And I’m likely going to need to find time to figure out why on earth throwing an exception results in a bus error, and I don’t know if I even know enough to figure out what’s going wrong. I probably need to figure out what mailing list the folks are on that deal with this stuff so that I can at least bring up the issue with them. But regardless, it’s another thing that I have to spend time trying to figure out in order to get my system working properly, because TrueOS is on CURRENT instead of 11.

And maybe that problem will exist in 12 if I don’t figure out how to fix it or at least figure out who to talk to about such things, and my dealing with this pain now just means that it can be fixed for 12 instead of me hitting it when 12 comes out - but it could also be that it would be fixed by the time 12 comes out anyway, and I wouldn’t have had to go through any of this if we had PC-BSD 11.

So, I can’t say that I’m at all happy with where TrueOS sits right now and the fact that we have it instead of PC-BSD 11, but the problems that I’m hitting are likely not problems that all that many folks are going to run into - especially the D-related problem. So, TrueOS is likely to be fine for many folks. And if those problems were resolved, then I’d probably be fine with TrueOS, but where I’m sitting now, I keep debating whether I should go through the pain of dealing with FreeBSD proper for a desktop or just switch over to Linux, but their ZFS support sucks in comparison to FreeBSD. So, rock meet hard place…


#11

Having been one of “those folks” who’ve rolled their own FreeBSD desktop and even used pf to set it up as a firewall for a home network, I understand where you’re coming from on the “pain” aspect.
But, I think a lot of that pain came from doing source upgrades instead of binary upgrades. If 11 gets you want you need from a working hardware POV, why not simply do binary packages for all the rest? That’s what you’re getting with TrueOS and Linux for the most part. The downside to that (my opinion) is you’re stuck with the options configured when the package was built, which may not be what you want.

USB audio device support: I’m going to mildly disagree with you on that. My sample of 1 Logitech headphones with an attached mic has always been recognized and supported in at least V10 and CURRENT of FreeBSD. plug it in, cat /dev/sndstat to see the dev info, sysctl -w hw.snd.default_unit=XXX and it worked just fine. It’s always been about buying hw that is recognized, and lots of the USB stuff is often fixed by simply adding in the correct IDs to the right kernel files for at least basic support.

I have nothing to add on D (I don’t use it).

As for ZFS support: I personally would not use Linux to do ZFS support. I would build up or buy something that already supports ZFS (ixSystems), migrate existing data sets and make them available on the network. Then all you need to do is remote mount them on your workstation.

But, I’m not trying to convince you to keep fighting against something that doesn’t work for you. The history of computers is littered with “have to break some things in order to make progress”


#12

ja myślę że mogliby połączyć siły z linuksem i pracować razem a nie osobno

[translation by moderator]
I think that they could join forces with Linux and work together rather than separately
[/translate]


#13

For your “D” programming/development, have you considered just creating a FreeBSD 11.0-Release jail on your system where you can do all your D compiles/tests?
That will let you have a functional/regularly updated desktop system (TrueOS), but your development sandbox will be a stable “-Release” environment. You could probably even install the “compat10x” package on your base/TrueOS system, and use a “10-Release” jail instead of “11-Release” so you can then run your compiled D apps on the base system too.


#14

Considering that I want a system built with X and cups and all of that fun stuff, I would be stuck configuring and rebuilding far too large a percentage of the packages for it to be even vaguely pleasant to use vanilla FreeBSD. That’s most of why PC-BSD and TrueOS exist in the first place.

I’m not going to replace my computer just because FreeBSD has problems with my sound card, and I’m not interested in shelling out for a new computer right now anyway (much as I probably will talk to IX next time rather than building my system from scratch as I’ve done historically). Also, next time I replace my system, I will probably get a server motherboard so that I can have a better CPU and more SATA connectors (since I really want my primary hard drives in my computer, not in a NAS, and I’m at pretty much the limit of what you can have with a desktop motherboard right now), and AFAIK, having a server motherboard means that I would need an external sound card, which puts me in the same boat that I’m in now anyway. Plus, I’d much prefer to have a high quality sound card, and there can be a definite quality difference between what they integrate into a motherboard and what you get with an external card. I want something that’s going to work well with my surround sound system. And as much as it sucks that FreeBSD doesn’t have the support I need built in, usually oss manages to solve the problem for me. It just doesn’t work right now thanks to changes in CURRENT.

I’ll have to look into that. It would likely partially solve the problem - particularly for running unit tests (since those throw exceptions on failure and thus definitely don’t work right now), but for some programs, having to run them in a jail like that would likely be problematic. It would be nice though to not have to do all my development on my laptop.

Regardless of the workaround though, my main point was that having TrueOS be based on CURRENT has made life harder for me rather than improving it and that from what I can see, PC-BSD 11 would have worked just fine for me. So, at least in my case, it’s been a real stability problem for TrueOS to be based on CURRENT. That being said, if the FreeBSD guys actually got better sound card drivers (which would fix one of my problems), those drivers would likely be in TrueOS fairly quickly, whereas there would have been a much larger delay for PC-BSD 11. So, depending on your hardware and what you’re trying to do, having TrueOS based on CURRENT could be a real boon. So, from where I sit, I wish that we had both PC-BSD 11 and TrueOS so that you could pick the one that worked best for your situation, and the fact that there is no “spin” or “distribution” of FreeBSD 11 geared towards desktops is frustrating. But there are only so many developers to go around.

BTW, does anyone have any idea which mailing list (or other means of communication) would be appropriate if I wanted to discuss problems with the stack unwinding code in the base with the developers likely to actually be involved in that stuff?


#15

The available FreeBSD mailing lists can be found HERE.
For something related to the libunwind changes which are only in -Current, I would guess the “freebsd-current” list is probably a good bet. Another possibility is the “freebsd-ports” list (and/or the D compiler port maintainer) for resolving issues with the ports you are having trouble with.

We have said this a few times in various places, but the current TrueOS team just does not have the manpower for maintaining an “11-Release” branch of the project in addition to the -current work. If somebody wants to step up and be responsible for this work (although realistically it will probably take a few people), we are more than happy to help you get started and provide assistance for things like automated builds, distribution under the TrueOS name, etc…