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.