What's happening to FreeBSD?

[mer]

Probably because it's new and unavailable yet.

I'm not sure how rcd will have anything to do with that.

By definition (project definition of rcd) it tries to execute service scripts in parallel. So in theory, startup in parallel instead of serial should be faster.
But yes theory and reality may not track.

 

[kirsche]

As far as I’m concerned, the pkgbase concept is a huge step backwards. Linux distributions use the same concept. I’ve upgraded Debian a number of times since Debian 6, and the operating system has ended up completely unusable sometimes. These were all standard configurations. I hope for the best but expect the wort.

 

[MG]

By definition (project definition of rcd) it tries to execute service scripts in parallel. So in theory, startup in parallel instead of serial should be faster.
But yes theory and reality may not track.

What is it trying? rc.d does things parallel also, right? So it's not a modular kernel + base configurator? I'm no HEAD user but I might try this if it's worth it. Does it offer system-wide options like entirely deleting anything sendmail-related or manpages for everything?

 

[wolffnx]

By definition (project definition of rcd) it tries to execute service scripts in parallel. So in theory, startup in parallel instead of serial should be faster.
But yes theory and reality may not track.

I trust in FreeBSD team that this is not a long term troyan horse , I dont wanna spell the cursed named...all you know

 

[wolffnx]

The new 'pkgbase' concept is good and smooth if you start from 15.0 . Once set, use pkg upgrade. But it is still tricky for normal users for major upgrade. The command pkg needs more work to do, in my opinion .

is hard, I'am not a long time user,started about 8 years ago..full time,servers and desktop
the most hard is things like

"how compile the kernel source code without make 20 steps that I dont know and are hard to learn"

"how install from ports without conflict with pkg?" (allways was wrong mixing it ,but if you need it...)

 

[astyle]

how compile the kernel source code without make 20 steps that I dont know and are hard to learn"

RTFM: https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld (Start there)

"how install from ports without conflict with pkg?" (allways was wrong mixing it ,but if you need it...)

Mixing of ports and packages is a bad idea. One way to minimize the conflict is to make sure the ports snapshot has the same time stamp as the package repo you're using. If you're using quarterly, figure out the exact timestamp of creation of that quarterly repo, and THEN get a port snapshot with that exact timestamp.

Windows doesn't have packages. Sigh.

really? It sure does, it's called Windows Store... and even if you don't use that, most of the pre-compiled stuff that you install from outside is an actual Windows package. They just go by different names: .exe, .cab, and a few others. At least do your homework and get informed about the very stuff you put on blast, buddy.

 

[drhowarddrfine]

Linux distributions use the same concept. I’ve upgraded Debian a number of times since Debian 6, and the operating system has ended up completely unusable sometimes.

Is it the same concept? According to FreeBSD developers, this solves a lot of development problems for them and makes upgrading far easier. In any case, FreeBSD development is not Debian or any Linux development and I don't think they can be compared.

 

[kirsche]

Is it the same concept? According to FreeBSD developers, this solves a lot of development problems for them and makes upgrading far easier. In any case, FreeBSD development is not Debian or any Linux development and I don't think they can be compared.

It’s not about development. FreeBSD’s strength lies in the separation of the operating system from packages. In Linux, these are mixed together, and that is precisely what will happen with pkgbase as well.

And by the way: if you’re so keen on helping developers, why not switch the entire system to containers? That makes it much easier for any developer to integrate any dependencies into any application container. Okay, simple commands like ls and grep will become huge - but it helps the developers.

 

[gnath]

Development is easy for small portion (package) only and related one . One can chose from meta package as per their need.

I think there may be some problem in starting services parallel as some may be dependent on other first. I don't know about rcd ( is it new init system ? )

 

[mer]

I think there may be some problem in starting services parallel as some may be dependent on other first. I don't know about rcd ( is it new init system ? )

Back up in post #12 of this thread lanin has a link to a forum thread about rcd. That other thread links to some stuff in a freebsd mail list.

Is it a new init system? It may become one, but at the moment I think it's more of a "new service management system" (the "service" command) which is part of the functionality of init. The descriptions of it are more Solaris SMF than the Linux thing that shall not be named.

Starting things in parallel: some init systems have done it for a long time, it pretty much mandates that every service file has correctly defined dependencies. The service manager typically parses these and builds an idea of what depends on what, what has no dependencies and using that starts what it can simultaneously.

 

[rbranco]

It’s not about development. FreeBSD’s strength lies in the separation of the operating system from packages. In Linux, these are mixed together, and that is precisely what will happen with pkgbase as well.

This is not even wrong lol.

 

[mer]

This is not even wrong lol.

But is it strictly "right"?
pkgbase is "kernel plus userland (OS)" and I believe they are in different repos from the application packages (ports).
A way to avoid the problem is when a user does "pkg upgrade" have the default "do not look for pkgbase updates".
Then have another tool to replace freebsd-update (I believe Emrion has been prototyping one) that wraps the pkg command and just looks at pkgbase.
That way you maintain the distinction between "OS packages" and "applications packages".

Just my thoughts as I've not migrated anything to pkgbase yet; I'm just waiting for details to get shaken out through usage.

 

[drhowarddrfine]

It’s not about development. FreeBSD’s strength lies in the separation of the operating system from packages.

It IS about development and OS packages ARE separate from application packages. It's just that the method of upgrading both will be the same or similar.

 

[T-Aoki]

FreeBSD's pkg repository is like below.
Top page: Combinations of supported major version and arch is listed.

Page for 15.x, amd64: Base and ports are in separated directories.

Note that each pkgs are NOT listed in subdirectories for pkgs from ports.
Would be hidden by configurations of web server unless pkg+http(s) protocol is used.

 

[rbranco]

But is it strictly "right"?

Not even wrong - Wikipedia

en.wikipedia.org

For FreeBSD to be like Linux at least these 2 conditions should be met:
1. Stuff coming from separate repos. FreeBSD has the FreeBSD-src monorepo.
2. Both ports & pkgbase installing to /usr. FreeBSD ports installs to /usr/local (though I wish NetBSD's /usr/pkg was used so you could use /usr/local for stuff you compile outside ports).

Having packages is better than having to edit /etc/src.conf with lots of WITHOUT_xxx lines and running `make installworld`.

pkgbase is "kernel plus userland (OS)" and I believe they are in different repos from the application packages (ports).
A way to avoid the problem is when a user does "pkg upgrade" have the default "do not look for pkgbase updates".
Then have another tool to replace freebsd-update (I believe Emrion has been prototyping one) that wraps the pkg command and just looks at pkgbase.
That way you maintain the distinction between "OS packages" and "applications packages".

I think this belongs in pkg that already knows about repos. Anything else is over-engineering it, unless I'm missing something. Packages make jails leaner & simpler.

 

[Zare]

It’s not about development. FreeBSD’s strength lies in the separation of the operating system from packages. In Linux, these are mixed together, and that is precisely what will happen with pkgbase as well.

And by the way: if you’re so keen on helping developers, why not switch the entire system to containers? That makes it much easier for any developer to integrate any dependencies into any application container. Okay, simple commands like ls and grep will become huge - but it helps the developers.

How you understand, but don't understand is beyond me.

It is exactly about development.
The FreeBSD is developed together. This distribution/update channel does not change this fact. It is the ground setup of the project that lasts for 3 decades...

Linux is a bazzar.
FreeBSD is a Cathedral.
Linux with 3rd party packages is just a bigger bazzar.
FreeBSD with packages is a Cathedral with a flea market on its square.
FreeBSD with pkgbase is a Cathedral with a market square where sacred relics are displayed outside of Cathedral, on the market square, next to the flea market.

The technological process is always a reflection of inner business processes.
The way IT systems operarate in some company is a mirror of the corporate structure of it.
The way update/3rd party packages channels work on some project is the exact carbon copy of the human structure of that project.

This is exactly why some C-level asshat cannot just come in and throw dockerization, virtualization, cloudization, AItization tantrums in some established enterprise because those patterns do not align with the human side of it.

FreeBSD, even if it tried to be Debian (in a bad way) it can't. The limits come from this world, not bits and bytes.

 

[T-Aoki]

FreeBSD ports installs to /usr/local (though I wish NetBSD's /usr/pkg was used so you could use /usr/local for stuff you compile outside ports).

If I recall correctly, ports first appeared but no package (pkg was developed far, far later) were provided. Ports was just hepler for sharing fetching, patching and building efforts within FreeBSD community.

Then, later, packages (at the moment, called packages and maybe in *.tz or *.tgz format) were started providing for convenience, included in CD-ROM image (at the moment), but not in diskettes.
So it was quite natural installing anything built using ports into /usr/local/.

There were NO upgrading tools at the beginning, so ports helped installing new softwares easily, but not much helped for upgrading.
So portupgrade, which is the very first upgrading tool on FreeBSD, was developed to attempting to solve the difficulties on upgrading.

Not 100% sure, but if I recall correctly, NetBSD introduced FreeBSD's ports framework (still far more simple than currently), and FreeBSD already started providing packages. So installing packages into /usr/pkg/ was NOT too strange (strange, though) for NetBSD.

Aftert a while, NetBSD switched frameworks from ports to their original pkgsrc, and now it is.

 

[Zare]

T-Aoki the situation I recall, without taking a look on the internet, FreeBSD had distribution packages, tarballs that have parts of the system, XFree86 was one of them, they were on the CD or FTP. Typical stateless 'packaging' like any early Linux. It also had old pkg-tools (pkg_add foo) and it had ports.

These things were introduced one by one probably in the very early versions but series 4, the ones that broke FreeBSD out to the general audience, those were FreeBSDs lauded stable features.

I remember as a noob dowloading Midnight Commander (google/yahoo "NC for Unix" then) package over 56k from ftp.freebsd.org, moving it over floppy to my "new" FreeBSD, hitting pkg_add to tell me I miss this package dependency, than doing that all over again...

Yeah, in 25-30 years things change and if you haven't been "here" in the years following late 00s you wouldn't catch the N transitional periods "we" had. People were not pleased XFree/Xorg got ditched from base at a point because of CD ISO size. People were not pleased about a ton of things and were doomsday calling even back then because even back then Linux was "going into directions" FreeBSD should stay clear of.

 

[bakul]

I believe today rcorder(8) is used by /etc/rc to make sure scripts are run in some correct order but not in parallel. That is, if both A & B require C, they will be run in order C, B, A or C, A, B. Beyond running independent scripts in parallel, I’m all for regularizing service bootstrapping as well as reducing the boilerplate code in all rc scripts.

 

[rbranco]

If I recall correctly, ports first appeared but no package (pkg was developed far, far later) were provided. Ports was just hepler for sharing fetching, patching and building efforts within FreeBSD community.

Then, later, packages (at the moment, called packages and maybe in *.tz or *.tgz format) were started providing for convenience, included in CD-ROM image (at the moment), but not in diskettes.
So it was quite natural installing anything built using ports into /usr/local/.

There were NO upgrading tools at the beginning, so ports helped installing new softwares easily, but not much helped for upgrading.
So portupgrade, which is the very first upgrading tool on FreeBSD, was developed to attempting to solve the difficulties on upgrading.

Not 100% sure, but if I recall correctly, NetBSD introduced FreeBSD's ports framework (still far more simple than currently), and FreeBSD already started providing packages. So installing packages into /usr/pkg/ was NOT too strange (strange, though) for NetBSD.

Aftert a while, NetBSD switched frameworks from ports to their original pkgsrc, and now it is.

ports is FreeBSD's baby. NetBSD adopted it and OpenBSD inherited it from NetBSD. OpenBSD's is simpler because of this.

pkgsrc is a bit messier. If you have umask 077 as root `make install` is not smart enough to avoid it. But it's also used by SmartOS (Illumos) and other operating systems, so they may have done something right. They still use RCS tags. It needs some polish.

 

[kirsche]

OK, perhaps I’m wrong. I see a difference between freebsd-update on the one hand, and Linux package managers and pkgbase on the other. I remember the same promises made by the package managers of Linux distributions, and they haven’t been kept. Of course, I can only refer to anecdotal evidence but Debian’s apt has wrecked quite a number of my systems during an dist-upgrade even with apt upgrade --without-new-pkgs before apt full-upgrade.

 

[Emrion]

Then have another tool to replace freebsd-update (I believe Emrion has been prototyping one) that wraps the pkg command and just looks at pkgbase.

To be clear on this, I didn't write pkgb-update to put a (artificial) separation between base and others packages. I did it to make the upgrade under pkgbase easy. You don't have to write a temporary conf file, guessing what to put in the URL depending the target version you want, you don't have to modify ABI var yourself to make things work, etc.

As for the separation between base and other package, it's destroyed in some ways by pkgbase. For example, if you run pkg upgrade, you also apply possible OS security patches. Is it a problem? I don't think so.

Accidental deletion of any base package is handled with the vital flag which avoid this. So it's ok for me.

Time will tell if pkgbase is a good thing or not.

 

[blackhole]

pkgbase is one thing. Whether you like it or not, nobody stepped forward to maintain freebsd-update forever.

rcd is a different matter, is it gets to be pid 1. But the proposal for that makes sense to me and the improved functionality is worth the complexity (for me).

You see this kind of argumenation a lot and it often comes from proponents of the latest solution trying to talk the previous tried and tested one into obsolescence. Not accusing you of this here by the way, I'm sure that's not your intent. it's just an observation.

I much prefer the clear separation of the base from ports/packages and always considered that a good thing with regards to any of the BSDs. pkgbase will lead to a blurring of those lines and ultimately to the same kind of thing we see in Linux distributions.

If no one is maintaining freebsd-update, then eventually that option will disappear in a future release. And on the assumption that freebsd-update is unmaintained, is this because the direction is pkgbase? Or was pkgbase developed in response to this? Or both?

This reminds me of the planned obsolesnce of X11. It was "unmaintained" because someone was paying X.org devs to work on wayland. So of course it was "unmaintained".

While apparently unmaintained, freebsd-update has alwaya worked well for me - pkg not so much and I have had far more issues with package upgrades than when upgrading base. Holding my hands up, I may be biased, but I disliked pkgng from day one. It has always fellt like a bad APT reivention. It has never seemed as intuitive or as versatile as Debian's APT tools. I have more confidence in freebsd-update to manage base system upgrades, than I would have in pkg. It may not be the perfect solution, but it's the current tried and tested one.

 

[rbranco]

As for the separation between base and other package, it's destroyed in some ways by pkgbase. For example, if you run pkg upgrade, you also apply possible OS security patches. Is it a problem? I don't think so

You can use the -r option to limit the scope to specific repos.

 

[rbranco]

You see this kind of argumenation a lot and it often comes from proponents of the latest solution trying to talk the previous tried and tested one into obsolescence. Not accusing you of this here by the way, I'm sure that's not your intent. it's just an observation.

I much prefer the clear separation of the base from ports/packages and always considered that a good thing with regards to any of the BSDs. pkgbase will lead to a blurring of those lines and ultimately to the same kind of thing we see in Linux distributions.

If no one is maintaining freebsd-update, then eventually that option will disappear in a future release. And on the assumption that freebsd-update is unmaintained, is this because the direction is pkgbase? Or was pkgbase developed in response to this? Or both?

This reminds me of the planned obsolesnce of X11. It was "unmaintained" because someone was paying X.org devs to work on wayland. So of course it was "unmaintained".

While apparently unmaintained, freebsd-update has alwaya worked well for me - pkg not so much and I have had far more issues with package upgrades than when upgrading base. Holding my hands up, I may be biased, but I disliked pkgng from day one. It has always fellt like a bad APT reivention. It has never seemed as intuitive or as versatile as Debian's APT tools. I have more confidence in freebsd-update to manage base system upgrades, than I would have in pkg. It may not be the perfect solution, but it's the current tried and tested one.

This comment is entirely subjective and lacks objective actionable items one can work on. This is the kind of comments that create tempests in a teapot like a few months ago.

You have to be more specific. pkgng ain't perfect but you can open bugs in their issue tracker on github. pkgng is better than the other BSD options. Only Illumos's pkg is better because it handles ZFS boot environments but it's slow because it's written in Python.