Is there a process which decides what software goes in "base/world" ?

FreeBSD does not has a Linus Thorvalds who makes end decisions.
So who & how is decided what goes in base ?
I have my personal preferences but I am just "a small fly".
I like to have in base the software I use so will everybody else ...
 
I hope this type of request is smacked down every time. So far it has, thankfully. Browsers have no business being in base, ever. What kind of server needs a browser? Whether you like it or not, whether the foundation says so or not, this is a server OS. Furthermore I think they should completely abolish www and x11-wm from the ports.
 
Xorg is not in base, so there will be pretty much no GUI installer and no browser which are both common requests from new users coming to FreeBSD.

FreeBSD does not has a Linus Thorvalds who makes end decisions.
The problem is Linux Torvalds doesn't make these kinds of decisions; he only cares about the kernel so what happens with individual Linux distros is chaos and mess. Some have browsers, some don't, some have GUI installers, some don't, some are undocumented, some are deprecated, etc, etc.
 
While installing FreeBSD i had in a shell running,
Code:
elinks https://docs.freebsd.org/en/books/handbook/
Stating browsers are important to find information.
 
Think about other users which use FreeBSD as server. They don't need web browser or pretty GUI as they don't have a monitor attached. All management is done via SSH or SOL.
Even if you install the local doc (handbook) you still will need a pdf reader as ghostview (gv) to open the PDF from /usr/local/share/doc/en/books and the ghostview still need 59 other dependencies + Xorg so it will end up with ton of other software installed and every single installed software is potential security risk of having some unknown bug into it.
So i personally prefer to have a minimum possible program base and only if i need to install any additional software so to keep the overall installed apps to minimum and use only those that i really need to provide some service.
 
Think about other users which use FreeBSD as server.
Indeed. And one might argue that there should be a "user-friendly" FreeBSD. And that is fine; however that is not this project. This project is the one that these are built ontop of. You don't start with a messy user-friendly OS and strip things out to make a clean OS. It doesn't go well that way.
 
Whether you like it or not, whether the foundation says so or not, this is a server OS.
From the freebsd.org homepage:
FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.
Not that I disagree browsers and X.Org itself has no place in base, but its clear that FreeBSD is a general purpose OS.
 
this is a server OS
Has to be repeated much more often to be true ;) Have you read the first sentence from the main web page? "FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms." Nope, it isn't just a server OS.

Edit: OK, I should read to the end before writing … others wrote that already, too…
 
OP: think of other ways to solve your needs.
For me I can summarize it like so: I need a working computer (desktop or laptop, with working net and at least a web browser) in order to install a new computer.
 
While installing FreeBSD i had in a shell running,
Code:
elinks https://docs.freebsd.org/en/books/handbook/
Stating browsers are important to find information.

Sure Alain, but how hard is pkg install elinks?

Think about other users which use FreeBSD as server. They don't need web browser or pretty GUI as they don't have a monitor attached. All management is done via SSH or SOL.

I've been one of those, but now I'm mostly one if these :)

Even if you install the local doc (handbook) you still will need a pdf reader as ghostview (gv) to open the PDF from /usr/local/share/doc/en/books and the ghostview still need 59 other dependencies + Xorg so it will end up with ton of other software installed and every single installed software is potential security risk of having some unknown bug into it.

Not necessarily so; here they're at /usr/local/share/doc/freebsd/en/{books,articles}/ and for every .pdf (44 total) there's a matching .html. links works fine and is 4.5MB.

Above the freebsd directory there are 22 more .pdfs but 3850 .htm* files, so no need for X and such to read them.

So i personally prefer to have a minimum possible program base and only if i need to install any additional software so to keep the overall installed apps to minimum and use only those that i really need to provide some service.

Agreed. Others can install src, ports and packages to taste and requirements.
 
smithi last time when i check the pdf=on was default format of the docs and the default pkg provide only the pdf version. Unless you fetch the ports and build it from there without pdf=on in the port config.
 
IMO there should be less in base. No server software except for sshd. Remove the MTAs, remove NTP, remove the KDC. Rely fully on ports for this. The user should be able to select packages or groups of packages (meta packages or meta ports) to build whatever they need.

For the reset pkgbase. Not everyone needs everything.

Regarding the kernel, everything should be modules. An install loader.conf that includes everything. When installed only enough to boot the system. Let every other driver load as needed.
 
I can subscribe to this minimalism idea. I compile the kernel with,
Code:
nooption    COMPAT_FREEBSD4     # Compatible with FreeBSD4
nooption    COMPAT_FREEBSD5     # Compatible with FreeBSD5
nooption    COMPAT_FREEBSD6     # Compatible with FreeBSD6
nooption    COMPAT_FREEBSD7     # Compatible with FreeBSD7
nooption    COMPAT_FREEBSD9     # Compatible with FreeBSD9
nooption    COMPAT_FREEBSD10    # Compatible with FreeBSD10
nooption    COMPAT_FREEBSD32    # Compatible with i386 binaries
And everything works fine.
And,
Code:
nodevice fdc 
nodevice      ahc         # AHA2940 and onboard AIC7xxx devices
nodevice      ahd         # AHA39320/29320 and onboard AIC79xx devices
nodevice      esp         # AMD Am53C974 (Tekram DC-390(T))
nodevice      hptiop          # Highpoint RocketRaid 3xxx series
nodevice      isp         # Qlogic family
nodevice     ispfw           # Firmware for QLogic HBAs- normally a module
nodevice      mpt         # LSI-Logic MPT-Fusion
nodevice      mps         # LSI-Logic MPT-Fusion 2
nodevice      mpr         # LSI-Logic MPT-Fusion 3
nodevice      sym         # NCR/Symbios Logic
nodevice      isci            # Intel C600 SAS controller
nodevice      ocs_fc          # Emulex FC adapters
nodevice      pvscsi          # VMware PVSCSI
nodevice      amr         # AMI MegaRAID
nodevice      arcmsr          # Areca SATA II RAID
nodevice      ciss            # Compaq Smart RAID 5*
nodevice      iir         # Intel Integrated RAID
nodevice      ips         # IBM (Adaptec) ServeRAID
nodevice      mly         # Mylex AcceleRAID/eXtremeRAID
nodevice      twa         # 3ware 9000 series PATA/SATA RAID
nodevice      smartpqi        # Microsemi smartpqi driver
nodevice      tws         # LSI 3ware 9750 SATA+SAS 6Gb/s RAID controller
nodevice      aac         # Adaptec FSA RAID
nodevice      aacp            # SCSI passthrough for aac (requires CAM)
nodevice      aacraid         # Adaptec by PMC RAID
nodevice      ida         # Compaq Smart RAID
nodevice      mfi         # LSI MegaRAID SAS
nodevice      mlx         # Mylex DAC960 family
nodevice      mrsas           # LSI/Avago MegaRAID SAS/SATA, 6Gb/s and 12Gb/s
nodevice      pmspcv          # PMC-Sierra SAS/SATA Controller driver
nodevice     pst         # Promise Supertrak SX6000
nodevice      twe         # 3ware ATA RAID
nodevice      nvme            # base NVMe driver
nodevice      nvd         # expose NVMe namespaces as disks, depends on nvme
nodevice      vmd         # base VMD device
nodevice      vmd_bus         # bus for VMD children
nodevice      ppc
nodevice      ppbus           # Parallel port bus (required)
nodevice      lpt         # Printer
nodevice      ppi         # Parallel port interface device
nodevice     vpo         # Requires scbus and da
nodevice      puc         # Multi I/O cards and multi-channel UARTs
nodevice      iflib
nodevice      em          # Intel PRO/1000 Gigabit Ethernet Family
nodevice      ix          # Intel PRO/10GbE PCIE PF Ethernet
nodevice      ixv         # Intel PRO/10GbE PCIE VF Ethernet
nodevice      ixl         # Intel 700 Series Physical Function
nodevice      iavf            # Intel Adaptive Virtual Function
nodevice      ice         # Intel 800 Series Physical Function
nodevice      vmx         # VMware VMXNET3 Ethernet
nodevice      axp         # AMD EPYC integrated NIC
nodevice      bxe         # Broadcom NetXtreme II BCM5771X/BCM578XX 10GbE
nodevice      le          # AMD Am7900 LANCE and Am79C9xx PCnet
nodevice      ti          # Alteon Networks Tigon I/II gigabit Ethernet
nodevice      mlx5            # Base driver
nodevice      mlxfw           # Firmware update
nodevice      mlx5en          # Ethernet driver
nodevice      ae          # Attansic/Atheros L2 FastEthernet
nodevice      age         # Attansic/Atheros L1 Gigabit Ethernet
nodevice      alc         # Atheros AR8131/AR8132 Ethernet
nodevice      ale         # Atheros AR8121/AR8113/AR8114 Ethernet
nodevice      bce         # Broadcom BCM5706/BCM5708 Gigabit Ethernet
nodevice      bfe         # Broadcom BCM440x 10/100 Ethernet
nodevice      bge         # Broadcom BCM570xx Gigabit Ethernet
nodevice      cas         # Sun Cassini/Cassini+ and NS DP83065 Saturn
nodevice      dc          # DEC/Intel 21143 and various workalikes
nodevice      et          # Agere ET1310 10/100/Gigabit Ethernet
nodevice      fxp         # Intel EtherExpress PRO/100B (82557, 82558)
nodevice      gem         # Sun GEM/Sun ERI/Apple GMAC
nodevice      jme         # JMicron JMC250 Gigabit/JMC260 Fast Ethernet
nodevice      lge         # Level 1 LXT1001 gigabit Ethernet
nodevice      msk         # Marvell/SysKonnect Yukon II Gigabit Ethernet
nodevice      nfe         # nVidia nForce MCP on-board Ethernet
nodevice      nge         # NatSemi DP83820 gigabit Ethernet
nodevice      sge         # Silicon Integrated Systems SiS190/191
nodevice      sis         # Silicon Integrated Systems SiS 900/SiS 7016
nodevice      sk          # SysKonnect SK-984x & SK-982x gigabit Ethernet
nodevice      ste         # Sundance ST201 (D-Link DFE-550TX)
nodevice      stge            # Sundance/Tamarack TC9021 gigabit Ethernet
nodevice      vge         # VIA VT612x gigabit Ethernet
nodevice      vr          # VIA Rhine, Rhine II
nodevice      xl          # 3Com 3c90x (``Boomerang'', ``Cyclone'')
nodevice      snd_cmi         # CMedia CMI8338/CMI8738
nodevice      snd_csa         # Crystal Semiconductor CS461x/428x
nodevice      snd_emu10kx     # Creative SoundBlaster Live! and Audigy
nodevice      snd_es137x      # Ensoniq AudioPCI ES137x
nodevice      snd_via8233     # VIA VT8233x Audio
nodevice      hyperv          # HyperV drivers 
nodevice      xenpci          # Xen HVM Hypervisor services driver
nodevice      iwifw
nodevice      iwnfw
nodevice      snd_driver
nodevice      snd_ad1816
nodevice      snd_als4000
nodevice      snd_atiixp
nodevice      snd_cmi
nodevice      snd_cs4281
nodevice      snd_csa
nodevice      snd_ds1
nodevice      snd_emu10kx
nodevice      snd_envy24
nodevice      snd_spicds
nodevice      snd_envy24ht
nodevice      snd_es137x
nodevice      snd_ess
nodevice      snd_sbc
nodevice      snd_fm801
nodevice      snd_mss
nodevice      snd_maestro
nodevice      snd_maestro3
nodevice      snd_neomagic
nodevice      snd_sb16
nodevice      snd_sb8
nodevice      snd_solo
nodevice      snd_t4dwave
nodevice      snd_via8233
nodevice      snd_via82c686
nodevice      snd_vibes
Probably i've forgotten some devices i don't use.
 
smithi last time when i check the pdf=on was default format of the docs and the default pkg provide only the pdf version. Unless you fetch the ports and build it from there without pdf=on in the port config.

I'm on 12.3-RELEASE and installed docs from the .pkg with that.

If 13.x has really ditched the much smaller .html files then that's an absurd regression that would indeed mandate installing Xorg just to read local docs, when a 4.5MB binary will do the job.
 
Stating browsers are important to find information.
Discussing what the base system should include (and what not) will never get a satisfying result for more than one person. I agree to you that one should be able to get docs/informations by just having a basic installation, but that should be possible without being forced to have the network up & running - so a webbrowser won't make sense. I think there are things that could be moved to the ports tree (f.e. sendmail - makes more sense as a port (and exists as a port, too); pax - never saw anyone using this; banner - why ever a OS needs that etc.), but overall: FreeBSD did a great job so far.
 
I'm more or less with cy@ here. Maybe a bit less "radical". IMHO, base should keep its character of being a working, integrated OS. And, again, IMHO, this includes a (simple) MTA, cause stuff like e.g. cron needs it. But apart from these details, yes, keep base as small and lean as possible! I personally don't see any valid reason to have a full-featured MTA like sendmal, just for example.

As we've seen it here yet again: No, FreeBSD ist not a "server OS". It is a general purpose OS. But this of course doesn't mean you need any "desktop" stuff in base. Base is self-contained and a working ("minimal") OS. Nothing would ever depend on e.g. a web browser.

What I personally want to keep in base (other than what's strictly necessary for it to be self-contained) is "admin tools". Just as one example: cu(1). This tool allows you to access a serial console of a headless server, without owning one of these hardware serial terminals :)
 
Oh, I forgot to answer the original question. Although, the link in the first response already explains a lot :cool:.

But when specifically asking about the decision what's part of base and what isn't, well it's just applying this structure in practice. If someone thinks something should be added or removed, well, the typical way to go would be to open up a discussion on a mailing list, likely also adding a review on phabricator about the intended change. Most of the times, this will be a public mailing list, so contributors and users can add their 2 cents as well. In some specific cases, the discussion might be started on (or, later moved to) an internal mailing list... These discussions will typically reveal a tendency. Only if things can't be resolved in discussion, e.g. the "core" team (which is, of course, elected!) will finally decide stuff.

Personal opinion: FreeBSD is both more organized and more democratic than e.g. Linux, which I like very much :cool:
 
As we've seen it here yet again: No, FreeBSD ist not a "server OS". It is a general purpose OS. But this of course doesn't mean you need any "desktop" stuff in base.
Agreed. Regardless of the "mechanism", this will tend to mean that base should be even more spartan to cater to the lowest common denominator between server and client.

A server would come with more stuff than in a general purpose base.
 
I vote for "oksh" in base. Note oksh is a program without external dependencies or dynamic libraries.
In fact i copied "oksh" into /bin in order for eventual "recovery".
Do you want "sendmail" or "opensmtpd" in base is an interesting question ? Or ntpd ? Or cron ? Or syslog ?
I did not include "sendmail" in base.
I don't use base ntpd but ports ntpd.
I don't use base cron but ports fcron.
I don't use base syslog but ports syslog-ng.
 
I vote for "oksh" in base.
Won't happen. Sure, you could try to discuss this on the mailing lists, but I can predict the outcome ? ... one bourne shell in base is all it takes. It's OTOH questionable to also include a C shell (tcsh), it seems this is done mostly for "historic reasons".
Do you want "sendmail" or "opensmtpd" in base is an interesting question ? Or ntpd ? Or cron ?
Currently, there's both sendmail and dma in base for the role of an MTA. IMHO, one of them would be enough, of course prefer the minimal one (dma). I think cron is a "must have" for a self-contained working base system. Ntpd could probably be up to discussion ....
 
IMO there should be less in base. No server software except for sshd.
I mostly agree. Base should contain all the software that is required to make a minimal but functioning computer. The question here is how to define "functioning". Today, a computer that can't be networked is mostly considered useless, so we need the basic TCP/IP stack, we need setup utilities (like DHCP client and configuring the hostname and resolver).

A computer that can not be accessed is pointless and might as well not exist. In the old days, that meant that you have to be able to connect a terminal to the computer, often by serial line. Starting with the IBM PC era, that was replaced by connecting a video monitor and a keyboard. Today, a large fraction of all computers no longer have physical console connections (they are in data centers, or virtualized). So sshd is absolutely needed, as it is often the only sensible way of getting into the computer. Technically, sshd is a server (in the networking sense), but in the practical sense, it does not provide a service to other machines.

Remove the MTAs, remove NTP, remove the KDC.
Here I disagree. Within a modern Unix system, minimal functioning email is required, even within a single computer. The one example already mentioned is storing results from cron job. I think base needs to contain at the minimum a simple and preconfigured MTA and MUA. Whether that has to be sendmail or not is something worth discussing, although I come down on the side of wanting sendmail present (even tough I personally don't use it on any machine).

Similarly, in a modern networked world a computer whose clock is off is just a nuisance. A minimal but functioning NTP client needs to be present in base. That does not mean that base needs to contain a full-feature NTP; for example the capability to connect to hardware clocks (such as GPS receivers) or being an NTP server is not required for basic operation.

Cron and syslog are more examples: A basic version of both is needed for a simple system to function sensibly.

I vote for "oksh" in base.
Why? We already have a good functioning korn shell in base. It has been there for many years. In the case of shells, removing them from base is very dangerous, because there is a huge installed corpus of scripts that rely on the features of the base shell.
 
Back
Top