why you compile world?

[wolffnx]

That's it , why compiling world? notice any speed? only for hobby?
my case is for my "almost" TOC of have my OS running with the minimal,only what I need, in my case I notice some speed improvement in the day a day use(desktop)
I dont need ipv6(at least for now),no need to bluetooth, wifi,etc
I never try it in my servers
I hear you guys..opinions and experiencies

 

[SirDice]

That's it , why compiling world?

Because there's no other way of updating a -STABLE or -CURRENT. And some people want to create their own install, perhaps disable some features, or enable others. Or strip things down, so it can be used on small (embedded) systems perhaps. See src.conf(5) for the things you could change.

notice any speed?

That's not the point of rebuilding world.

only for hobby?

Keeping up with changes. First as a hobby, later as a professional.

I dont need ipv6(at least for now)

I would still recommend keeping it in though. Lots of third party application are relying on IPv6 being there, even if it's configured for IPv4 only.

 

[bakul]

why compiling world?

FOMO!

 

[wolffnx]

FOMO!

what this?

 

[zirias@]

Because there's no other way of updating a -STABLE or -CURRENT.

This. (I need -CURRENT for testing port builds)

And some people want to create their own install, perhaps disable some features, or enable others.

And this as well. For my -RELEASE builds, I have a lot of WITHOUT_* knobs in my /etc/src.conf. Although most of this now just saves a bit of space, so I could re-think that eventually. In the past, I had WITHOUT_KERBEROS=yes which made using MIT krb5 from ports indeed a bit easier, but I was forced to remove that for using kerberized NFS, which strictly needs the heimdal from base

 

[wolffnx]

Because there's no other way of updating a -STABLE or -CURRENT. And some people want to create their own install, perhaps disable some features, or enable others. Or strip things down, so it can be used on small (embedded) systems perhaps. See src.conf(5) for the things you could change.

That's not the point of rebuilding world.

Keeping up with changes. First as a hobby, later as a professional.


I would still recommend keeping it in though. Lots of third party application are relying on IPv6 being there, even if it's configured for IPv4 only.

Because there's no other way of updating a -STABLE or -CURRENT. And some people want to create their own install, perhaps disable some features, or enable others. Or strip things down, so it can be used on small (embedded) systems perhaps. See src.conf(5) for the things you could change.

That's not the point of rebuilding world.

Keeping up with changes. First as a hobby, later as a professional.


I would still recommend keeping it in though. Lots of third party application are relying on IPv6 being there, even if it's configured for IPv4 only.

interesting, thanks, I would love to do some proyect like embedded OS, for now the only improvement is the size of the kernel(from 26M to 17MB after compile)
yes, the first think I do is check the man page of src.conf
is too much fun..rebuild the world and kernel, with some fails in the midle of course

 

[PMc]

How else do you bring in all the bugfixes?

E.g. PR 122519,260794,260796,264858,267098,269770,276862,278338, among others

 

[wolffnx]

This. (I need -CURRENT for testing port builds)


And this as well. For my -RELEASE builds, I have a lot of WITHOUT_* knobs in my /etc/src.conf. Although most of this now just saves a bit of space, so I could re-think that eventually. In the past, I had WITHOUT_KERBEROS=yes which made using MIT krb5 from ports indeed a bit easier, but I was forced to remove that for using kerberized NFS, which strictly needs the heimdal from base

mmm I dont check the saved space..so..is like SirDice says, the speed is not the point of build world
/etc/src.conf is like a loaded gun..have to be carefull with it
mine is like this

WITHOUT_BHYVE=
WITHOUT_BLUETOOTH=
WITHOUT_CALENDAR=
WITHOUT_DMAGENT=
WITHOUT_EE=
WITHOUT_FLOPPY=
WITHOUT_GOOGLETEST=
WITHOUT_HTML=
WITHOUT_HYPERV=
WITHOUT_INET6=
WITHOUT_INET6_SUPPORT=
WITHOUT_IPFW=
WITHOUT_LOADER_GELI=
WITHOUT_LPR=
WITHOUT_MAIL=
WITHOUT_MAILWRAPPER=
WITHOUT_NVME=
WITHOUT_PPP=
WITHOUT_PROFILE=
WITHOUT_RADIUS_SUPPORT=
WITHOUT_SENDMAIL=
WITHOUT_SYSCONS=
WITHOUT_VI=

maybe in the next build leave IPV6 support, thanks again SirDice for notice that

 

[T-Aoki]

Because I'm living on latest stable branch (currently 14).
And I don't want additional delays related to vulnerabilities.

Yes, for this aspect, chasing main (aka -Current) branch is clearly the best way, but sometimes catastrophic changes are made on main branch.

Changes pulled into main (-Current) branch are first merged (aka MFC) into stable branches (usually the newer the branch is, the earlier it comes) after confirmations, then merged to corresponding releng branches (aka MFS) after confirmations on stable branch. Point releases like 14.0-p1 are built after that.

My trade-off is to build latest stable branch at least once a week.

If the fix looks critical and seems to be safe to apply, I manually cherry pick it and build world/kernel before it is MFC'ed.

 

[bakul]

what this?

Fear Of Missing Out. I wasn’t being serious.

 

[bgavin]

Interesting.
I see a lot of feature in the above list, that I have no need to include.

 

[zirias@]

How else do you bring in all the bugfixes?

Except for my port testing VMs, I only run -RELEASE since the release of 11.0. In all that time the somewhat recent "ZFS mess" was the first time I really needed to include patches in my build. Don't get me wrong, there were bugs, but they're typically of the "mild annoyance" kind, with workarounds possible. So, needing a patch for a -RELEASE version actually was kind of shocking, because it is so rare. I'm pretty sure most other people's experience is similar. Therefore I consider this take unnecessarily provocative. If you really expect "bug-free" software, you'd have to look somewhere else (pure lab projects, formally proved, not able to do any real-life work ...)

I have to admit though that this ZFS topic, together with other ZFS issues that thankfully didn't seem to hit -RELEASE versions so far, left some "mixed feelings" about the move to ZOL/OpenZFS

 

[ralphbsz]

I have run only release in FreeBSD, for the last 10 or 15 years. I have never done make world on it. I have only installed packages, with a handful of exceptions where something had to be compiled from ports. The difference is probably this: I run a server as if it were a production server, where I need stability and reliability. It does not have a GUI, so I don't worry about many web-based exploits.

In contrast, on Linux I used to rebuild the kernel all the time. Even going directly to the real one from kernel.org, instead of the distribution-specific versions. That was long before Linux could be considered a stable system.

If I ever have to start compiling the kernel or the whole OS myself for a production server, I will switch to a different system.

 

[bakul]

FreeBSD h/w support often lags behind. If you bought a recently manufactured machine, -stable or -current is more likely to have support for it though still a crapshoot. Another reason is to help debug/develop something kernel related. Yet another is to build a minimal kernel. Yet another is to keep track of and play with what is changing. One other reason I compile kernel/world locally even for -release is because I am not happy with the way freebsd-update works. -stable is quite stable but occasionally it may break things. But one can get by with just running -release on a slightly older machine.

 

[PMc]

Except for my port testing VMs, I only run -RELEASE since the release of 11.0. In all that time the somewhat recent "ZFS mess" was the first time I really needed to include patches in my build. Don't get me wrong, there were bugs, but they're typically of the "mild annoyance" kind, with workarounds possible. So, needing a patch for a -RELEASE version actually was kind of shocking, because it is so rare.

Lucky You. Let's have a look:

• I *need* patches to use Kerberos-Servers with more than one realm (on the same node), because that was forgotten to implement. (usually one uses one realm for the intranet and another for the perimeter)
• I *need* patches to have my firewall work at all with interface specific rules and IPv6 linklocal addresses on the interfaces, as the interface info for local connections is mangled between lo0 and the actual interface (not sure about the current state),
• I *need* patches to have inflight reloadable firewall configs that do not drop dynamic sessions (sometimes backup up a database to the cloud takes two days, and I don't want to wait that long for a change of some firewall setting)
• I *need* patches to have my tunnels work with MTU 1500 over IPv6 through the firewalls, because a firewall needs to reassemble fragmented packets in order to inspect them and ipfw doesn't do that for v6 - otherwise I would need to use some entirely different firewall software (which may or may not support the situation).

So far just a selection of some issues where I had to spend work to get things running

I'm pretty sure most other people's experience is similar. Therefore I consider this take unnecessarily provocative.

Oh! Now it gets grotesque. Is this the googlespeak directive, where we are not allowed to say anything that somebody might interpret as negative, and that might hurt the delicate feelings of - whoever? Where we are no longer allowed to analyze facts, in other words, to do engineering - because we don't need to anymore, as Google (etc.) already know best what is good for us, and we only have to be happy and consume, in that brave new world?

If you really expect "bug-free" software, you'd have to look somewhere else (pure lab projects, formally proved, not able to do any real-life work ...)

I don't expect bug-free software. To the contrary, I expect to have to occasionally fix or workaround bugs! And I expect a supportive community where we share our experiences of hacking and workarounding and making things work - just like it was earlier, before googlespeak.
I do not expect a community of gadget-thriven consumer bots who need the guts of the technology always stay veiled before them, because they get disturbed by the bloody view of actual engineering (and instead need 16 mio rgb colors on the cpu cooler [*]).

Sorry, but this needs to be said in clear words. This is a bigger issue - I am so much pissed by everywhere getting only stupid "solution" babble, instead of engineering facts, and always being treated as a stupid consumer who should just be happy and buy all the crap and leave the thinking to others.

The trait of FreeBSD was always that if something doesn't work as expected, you can be sure that the source for /usr/bin/foobar is to be found in /usr/src/usr.bin/foobar, and you can just change it and then "make; make install" will cleanly activate the change.
This is the actual unique feature of the Berkeley, which no other OS has (anymore)!


[*] meanwhile watching the next "MAX" airplane fall from the sky - which is very much the same topic (forgotten that one at first).

 

[zirias@]

☠

 

[PMc]

Now, when I'm already at it: one also needs to compile world in oder to revert the changes which break your site.

Examples:

1.
Since ~13.1 my machine takes some 4-5 minutes longer to boot. That is because each and every jail must first run into three network timeouts before starting.
Background: somebody demanded that they need rtsold very early for their DHCP (or whatever) to work properly. Apparently this is for some desktop usecase (or whatever), and likely not for server operation or jail operation. But the "fix" was put into the code nonetheless, nondiscriminatory.
Now the rtsold request hits the local firewall in the jail at a time when firewall rules are not yet loaded. The developer then was surpized that I run my firewalls with "default to deny". I should run them with "default to accept", was the suggested workaround.

2.
Since 13.3, if you start an openvpn inside a jail, that jail may never die again. That is because the network structures cannot be unmangled for removal afterwards, because something with the usage counts is wrong.
Reason is a change sometime last year, when something with these usage counts did not work in the way that somebody expected, and so the usage count was just changed according to that demand - which now is certainly wrong, because the network structures did unmangle well before and now do no longer.

But such does not get properly analyzed and then re-designed in a way that does really work; instead, some people with a high enough rank in the cabal can just demand "I need this differently", and they get it.
Others can then spend a couple days wondering what's broken, start bisecting, and finally move the offending changes out again locally.

~~
These two are from the more unfriendly group. There are similar ones where you find site down, then search a day or two for the introduced breakage and finally identifying it, there is actually a workaround, so you just need to slightly rework your installation.
Like the decision to make bhyve delete the host's network configuration on guest reboot. Not amusing, nevertheless - specifically when the developer then adds insult to injury and explains, he cannot trust the system owners to know what they are doing when they configure their network to persist on guest reboot.

 

[wolffnx]

Fear Of Missing Out. I wasn’t being serious.

Later I found what was that on google,like a TOC ,yes, I'am crazy..but..what is normal?

 

[Crivens]

yes, I'am crazy..but..what is normal?

To quote a musician: how insane is the one who thinks of himself as normal these days?

 

[Cath O'Deray]

… no other way of updating a -STABLE or -CURRENT. …

Gentle reminder:

• for both -STABLE and -CURRENT, the pkgbase alternative.

FreeBSD Project-provided packages, and poudriere support for creating and updating jails with these packages, have positively transformed my use of 15.0-CURRENT. I simply use pkg(8), without the rigmarole of building/compiling.

Attached, a longhand example – pkg, in the midst of two runs of a poudriere command, plus use of ZFS boot environments (for uninterrupted use of my desktop environment whilst updating FreeBSD).

I'll provide shorthand in due course.

I await one minor fix, before taking a more proactive approach to supporting users of pkgbase. In the meantime there's documentation, albeit slightly outdated, primarily in the wiki.

HTH