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

rigoletto@

Developer
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). :)

400sw7yu27yu5.gif


They could also sync PF from OpenBSD, but that is none of my business.
 
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. :)
 
So, talking about controversial ideas:

  1. 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.
  2. Imports from DragonFlyBSD: VKERNEL, SWAPCACHE, the 'Extreme Scaling' thing, and eventually other interesting things (like SMP scaling improvements).
  3. The first open-source AES67 (or even better RAVENNA) implementation. DOCUMENTATION.
:D

EDIT: just to point to NextBSD, which is/was a tentative to import the Mach IPC to FreeBSD.
 
Last edited:
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.
 
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. :)
 
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)
 
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. :p

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.

gentoo-portage.jpg
 
Last edited:
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.
 
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.
 
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.
 
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. :)
 
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.
 
As long as nobody calls these ports trees "distro", I do wear the striped shirt and say "I allow it!"
 
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....
 
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.
 
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.
 
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.
 
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 :rolleyes: Sorry, it's the truth, and I'm not lie :'‑(
 
Back
Top