# Intel guy: FreeBSD Work (week #2) - big TODO list.



## rigoletto@ (Jun 16, 2018)

FreeBSD Work (week #2)
Pointed by @drakonis on IRC.

A *big TODO list*, and I particularly like of the *inotify/fsevents* in there (hopefully more like FSEvents). 






They could also sync PF from OpenBSD, but that is none of my business.


----------



## rigoletto@ (Jun 16, 2018)

Now, if by "Performance | Decrease boot time. | parallel AP start" they mean an event based boot manager, I have been told there are some very nice ideas from Amoeba, and still Solaris SMF may be also a good source for ideas.

If the thing end up like the AIX Event Infrastructure, that would be great.

I believe Oko will probably want to comment in here.


----------



## unitrunker (Jun 16, 2018)

Did you see Colin Persival's presentation at bsdcan?

http://www.bsdcan.org/2018/schedule/attachments/453_BSDCan18.pdf


----------



## rigoletto@ (Jun 16, 2018)

So, talking about *controversial* ideas:


Assuming marino Ravenports will never be imported adopted (due to the last year controversy and eventually unknown reasons by me), make the ports system and ports-mgmt/poudriere more _smart_ like that (Ravenports). Actually, would be very interesting (my opinion) if ports-mgmt/poudriere became a build system capable to build everything the entire system, with buildsheets for: kernel, base (pkg-base is already in works), ports. If there was the possibility to create a installable image at the end, with all customizations, and a set of ports would great (and easy) when people need to set the same custom thing on several machines.
Imports from DragonFlyBSD:  VKERNEL, SWAPCACHE, the 'Extreme Scaling' _thing_, and eventually other interesting things (like SMP scaling improvements).
The first open-source AES67 (or even better RAVENNA) implementation. DOCUMENTATION.


EDIT: just to point to NextBSD, which is/was a tentative to import the Mach IPC to FreeBSD.


----------



## marino (Jun 16, 2018)

hmm, so what do you mean by "imported" with regard to Ravenports?
Anyone using FreeBSD that wants either source or binary packages from Ravenports has access to them, so I'm not sure what else needs to be done here.   Other than perhaps advertising them as an option I guess.


----------



## rigoletto@ (Jun 16, 2018)

marino said:


> hmm, so what do you mean by "imported" with regard to Ravenports?
> Anyone using FreeBSD that wants either source or binary packages from Ravenports has access to them, so I'm not sure what else needs to be done here.   Other than perhaps advertising them as an option I guess.



I mean as a officially supported, or become the official ports system. But yes, the word used was not the best one.


----------



## marino (Jun 16, 2018)

Okay, so I would say Ravenports officially supports FreeBSD. 
I never expected (nor intended) that FreeBSD would adopt it as the main repository although I can see that happening for DragonFly, small linuxen and solaris-based distributions.  I think FreeBSD has some specific requirements that Ravenports could never support (given that a major objective is that Ravenports is not anchored nor serves any OS more than another)


----------



## rigoletto@ (Jun 16, 2018)

I see, however the 'engine' is in there and with a very open license.

I sometimes wonder when will appear the first Linux _distro_ built around Ravenports: The Raven/Linux.

EDIT: I think an Arch Linux variant built around Ravenports could potentially bring some headache to Gentoo, and the utterly slow Python written Portage system. 

EDIT_2: however, I already said it before, we (at least I miss) really need a proper ports searcher like Gentoo EIX (and it does some other things too) with a nice and complete output. For now I stick with ports-mgmt/psearch which does the job.


----------



## marino (Jun 16, 2018)

hah, I beat them to flavors (aka variants) by a year, and they still don't have subpackage support.  Pride would prevent them to move to it, even though my implementation of flavors is much better.  Plus the whole Ada thing would be a deal-breaker for those people with influence.


----------



## phoenix (Jun 17, 2018)

lebarondemerde said:


> Now, if by "Performance | Decrease boot time. | parallel AP start" they mean an event based boot manager, I have been told there are some very nice ideas from Amoeba, and still Solaris SMF may be also a good source for ideas.



Parallel AP start refers to enumerating and bringing up each Application Processor in a CPU. Instead of listing each core in a 128-core system in a serial fashion, taking X seconds for each one, look at starting cores in parallel instead.

This is dealing with the part of the boot between the loader and the RC system, when only the kernel is loaded and detecting/configuring hardware.


----------



## rigoletto@ (Jun 18, 2018)

Related subject: Thread 52373


----------



## rigoletto@ (Jun 18, 2018)

Create a P2P Core/Infrastructure for content distribution [packages, ports (over portmaster(8), source code etc.)] and eventually others usages like builtin net/syncthing like capabilities..

I've posted about it already: Thread 64771

Mail lists: HERE, and a interesting reply in HERE.


----------



## rainer_d (Jun 19, 2018)

Holy cow - I just now learned about ravenports.
Can I really have multiple version of PHP installed (and used) at the same time?

That would really be a killer-feature for me.
Given that it installs everything to /raven, I could actually migrate a lot of my hosts to this without changing much.

The downsides are of course that it's not something offered by the FreeBSD project itself and that tree-updates rely on a (single) 3rd-party.

Or what other problems can people see in this?

In any case, I'll by trying to build the 2200-odd ports that I need here with ravenports and see how it turns out.


----------



## rigoletto@ (Jun 19, 2018)

rainer_d

The only real problem you will find at this point is the ports CATALOG what is far from what we have in FreeBSD. That is one of the reason I am not switched to it; however I am whiling to contribute with some ports late (when I have some free time).

The other is the fact I maintain a few ports and like to contribute in here.


----------



## rainer_d (Jun 19, 2018)

OK, you're right.
Seems that pecl-ports are missing, as is ImageMagick and GraphicsMagick.
I guess I could take the *Magick ports from FreeBSD-ports - but I also need some pecl-ports and pecl-imagick in particular.

Too bad. That would have solved a lot of problems.


----------



## Crivens (Jun 19, 2018)

As long as nobody calls these ports trees "distro", I do wear the striped shirt and say "I allow it!"


----------



## rigoletto@ (Jun 19, 2018)

Not really related but since Ada was cited, I found this free booklet at AdaCore.


----------



## rigoletto@ (Jun 20, 2018)

rainer_d

You may be interested on this Thread 62288, and eventually about ports-mgmt/synth, Thread 54690 and Thread 63525.


----------



## rainer_d (Jun 20, 2018)

Thanks. I already saw the other thread. The Google group seems to be kind-of dead - and I don't have a google-account anyway....


----------



## jrm@ (Jun 20, 2018)

marino said:


> ...my implementation of flavors is much better.


Could you elaborate on this?


----------



## rigoletto@ (Jun 20, 2018)

While marino does not reply I would like to add (I haven't played seriously with Ravenports) but the only _inconvenience_ I found in relation to the FreeBSD ports system is the lack of OPTIONS. The user really need to create/modify a custom port for that. However, that was clearly intentional and match with the objectives described on the Ravenports page.


----------



## marino (Jun 20, 2018)

well, some ports have options but mostly there's no need for them.  Generally options can be replaced with variants which is much more flexible and useful.


----------



## marino (Jun 20, 2018)

rainer_d said:


> In any case, I'll by trying to build the 2200-odd ports that I need here with ravenports and see how it turns out.



Building isn't necessary -- the FreeBSD packages are available as binaries.
The only caveat is that they aren't signed packages, so that being a dealbreaker is the only benefit of building yourself that is gained.
I do need to get around to signing these things.


----------



## giahung1997 (Jun 21, 2018)

marino: it's good that you're there. I've read and impressed about your Ravenports and tried it. I would say it's disappointed because it take hours and finally fails. I tried many times the same result. It's a long time ago, perhaps it changed  Sorry, it's the truth, and I'm not lie


----------



## rigoletto@ (Jun 21, 2018)

About AES67/RAVENNA, beyond the usual uses (HERE) I believe that can be used to implement something like THIS too.


----------



## rainer_d (Jun 22, 2018)

marino said:


> Building isn't necessary -- the FreeBSD packages are available as binaries.
> The only caveat is that they aren't signed packages, so that being a dealbreaker is the only benefit of building yourself that is gained.
> I do need to get around to signing these things.



I build PHP specifically with certain options (ZEND_THREAD_SAFTEY, MAILHEADER) and also other ports with some non-default options.
The number of ports I build with special options has decreased over time, though. But some will always stay "special".


----------



## rigoletto@ (Jun 24, 2018)

I was thinking about the "Base-Extras" concept (nothing new actually). A separated tree developed exactly like Base but optional.

This idea would allow a very minimal Base, for instance with just one firewall instead of three. The rest in that separated tree, like the two others firewalls, Heimdal, GSSAPI, etc.

In practice something along lines to the user installing the minimal and later optionally:

use freebsd-update to bring the desired extras (IDK if it would really be feasible);
download the desired extras source-code, and rebuild the system.
Eventually an image could be made available with all extras included.


----------



## rigoletto@ (Jul 6, 2018)

It seems the PARTY already started.


----------



## rigoletto@ (Aug 31, 2018)

I've just remembered another thing: *profiles and sub-profiles*.

I am not talking about _hard_ profiles like on Gentoo, that lock many behaviors of the system, but _soft_ profiles which set ( but does not lock ) some _defaults_ parameters per general user case, ie:

Default ---> today parameters

Server
     |_ Secure server
     |_ Specific user cases profiles...

Workstation
     |_ Regular desktop
     |_ Secure desktop

Then sub-profiles could also be integrated for specific areas:

Networking
     |_ 1 Gbps
     |_ 10 Gbps
     |_ 1000 Gbps

Idealistic the user could export its configurations to something like a "buildsheet" to be later easily re-create ( and eventually share ) the configurations.


----------



## puretone (Oct 25, 2019)

rigoletto@ said:


> EDIT_2: however, I already said it before, we (at least I miss) really need a proper ports searcher like Gentoo EIX (and it does some other things too) with a nice and complete output. For now I stick with ports-mgmt/psearch which does the job.



(flameSuit = On)

What's wrong with `pkg sea -o` ??


----------



## rigoletto@ (Oct 25, 2019)

puretone said:


> (flameSuit = On)
> 
> What's wrong with `pkg sea -o` ??



pkg(8) is to search packages not ports. E.g. if you build from ports and mainatain you own repositories but doesn't build *everything*, `pkg search` will just return from the ports you built and not from all possible ports.


----------



## tingo (Oct 27, 2019)

It isn't that hard to make your own search tool for ports. Here is mine (yes, it's old)

```
root@kg-core2# cat /usr/local/bin/pinfo
#!/bin/sh
# @(#)port    1.0    10-nov-2001    T. Ingolfsen / KG4, Norway
#
# Just a quick hack to get any easier way to search for ports
#
NAME=`basename ${0}`
PORTNAME="${1}"
PORTSDIR="/usr/ports"

if [ "$1" = "" ]; then
    echo " ${NAME} - find a given port in /usr/ports"
    echo "    Use with '${NAME} xxx', where xxx is the name of the port."
else
    if [ ! -d ${PORTSDIR} ]; then
        echo " ERROR: ${PORTSDIR} doesn't exist!"
        exit 0
    fi
    cd ${PORTSDIR}
    make search name=${PORTNAME}
fi
```
During it's life, it had to be renamed due to some name collision.


----------



## rigoletto@ (Oct 27, 2019)

Yeah, but I was talking about something like EIX which show supported options, what are defaults what are ON and what are not etc. and some other thingies.


----------



## puretone (Oct 29, 2019)

rigoletto@ said:


> pkg(8) is to search packages not ports. E.g. if you build from ports and *maintain* *your* own repositories but *don't* build *everything*, `pkg search` will just return from the ports you built and not from all possible ports.



Surely. Particularly with a custom repo. But that doesn't take away that `pkg sea -o` can be used for searching both local / remote repos in parallel. The approach Tingo takes is very useful, a Golden Oldie. And then there's ports-mgmt/psearch ...


----------

