# What do you think about the new "package base"?



## badbrain (May 1, 2019)

FreeBSD "Package Base" Is Now Ready For Testing - More Conveniently Update FreeBSD - Phoronix
					






					www.phoronix.com
				




I think it's like a punch in the face. We used to ridicule Linux and praise ourselves that we have separated ports and base upgrade mechanic. It means we admit Linux's way is practically easier, more flexible and more reasonable than our own that we finally have to adopt it. It's shameful. What about you?


----------



## tommiie (May 1, 2019)

If we admit to Linux's way being easier, more flexible and more reasonable, why is it shameful to adopt? It's shameful that you ridicule Linux users for their decisions. There is nothing shameful about admitting you were wrong and they were right.


----------



## abishai (May 1, 2019)

I think it just a refactor of freebsd-update utility.


----------



## forquare (May 1, 2019)

badbrain said:


> We used to ridicule Linux and praise ourselves that we have separated ports and base upgrade mechanic.



Did we?  I've not been here long, but when people said "_we have a separate base and third party Ports system_" that they were referring to the fact that we have a base system that is developed as a whole (as apposed to GNU/Linux which simply integrates many third party components) and the Ports system which give easy access to third part programs.
The update mechanism never even entered my mind when people spoke about Base and Ports.

Following along the conversation on the mailing lists, this _pkgbase_ is being offered to FreeBSD by iXsystems after developing it for their TrueOS/TrueNAS products.  There is also some required tooling that probably wouldn't end up in FreeBSD's Base system _as is_ and would need some additional development.  I believe that this is separate to another *pkgbase* project being developed within the FreeBSD project.

Do I care what method FreeBSD uses to update my system?  Not particularly as long as it works.  I prefer binary updates since my machines are fairly standard and not overly powerful.
I would be interested in learning more about how building _pkgbase_ works, my current understanding it that it uses ports-mgmt/poudriere.  If that eventually simplifies the system (i.e. only having to maintain ports-mgmt/poudriere infrastructure and dropping freebsd-update(8) infrastructure) then the project can hopefully be more efficient in terms of infrastructure and resources to manage/maintain/develop said infrastructure?


----------



## kpedersen (May 1, 2019)

I kinda liked that ports / packages were installed into /usr/local and if I broke anything, I could just delete that directory and start again. Obviously the base will not be moved to that directory but I did actually prefer a clear separation.

Really I am happy so long as "base" is a single package and not split into multiple. That way I can just hold back on a base update and only update packages.
I think if /bin/sh starts updating separately to /bin/awk, it is pretty much game over in terms of deterministic behaviour.

Why was this change made? Surely there were more pressing or interesting problems to be solved?


----------



## malavon (May 1, 2019)

For those who are not subscribed to the mailing list, there's more information to be found in the mailing thread. Some legitimate concerns have been raised there.

I haven't delved into this, but as far as I know it's not easy to setup your own freebsd-update() server. While this isn't very useful for i386/amd64 except for 
building customized kernels or in offline environments, it might be useful for Tier ≥2 (ARM/ARM64 etc) systems.



forquare said:


> If that eventually simplifies the system (i.e. only having to maintain ports-mgmt/poudriere infrastructure and dropping freebsd-update(8) infrastructure) then the project
> can hopefully be more efficient in terms of infrastructure and resources to manage/maintain/develop said infrastructure?


Second that. Resources are finite. Take a look at the FreeBSD Foundation financials and especially the counter on top of the page.

My opinion: I prefer having a clean (well-developed) option that works without too much hassle. 
When `freebsd-upgrade` was added to the base system, it made upgrading a lot easier. I was happy.
When the current `pkg` was added in -RELEASE and ports-mgmt/poudriere to ports, I switched from sysutils/portupgrade.  I was happy.
When staging was added to the ports system, I benefited. I was happy.

I trust the FreeBSD developers to make a good decision on PkgBase (either one of the proposals). If it wasn't clear from the text above, I'm happy with the current situation 
But I'm not against changes just because they're changes. Or at least, I am no longer. It's a process I had to learn myself, not to get stuck with what I know.


----------



## Sevendogsbsd (May 1, 2019)

I came to FreeBSD for a couple of reasons: sane init system, OS developed as a whole and the virtual separation of the core OS and the user apps. I personally like that there is a one set of tools to update the OS and one (or more, depending on your choice of packages or ports)  set of tools to update the user apps. As others have said, if it all goes to heck, you can delete /usr/local and the OS keeps on trucking.

I probably don't understand the implications of "pkgbase" since I am a relatively new FreeBSD user but I too trust the FreeBSD devs to make the right decisions about this.


----------



## ralphbsz (May 1, 2019)

badbrain said:


> I think it's like a punch in the face.


Wrong.  It is an idea that is being discussed and tried out.  I have only looked a little bit at it, and it seems reasonable to use large parts of the existing pkg mechanism for the base system too.  It might have unintended consequences or problems that I don't understand yet, but it is very likely that the large set of people working on it it or watching it (there are at least a dozen) will be finding those.  I like the fact that this is being tried twice, in different places by different (but overlapping) sets of people; that makes it likely that problems with one or the other implementation will be found.  The main proponent and author (Kris M) is trustworthy and right-headed.



> We used to ridicule Linux


Stop right there.  That statement is not just wrong, it is outright evil.  There is no "we" here.  Maybe you do, and you are free to say anything you want, that's freedom of speech.  I do not ridicule Linux.  I use Linux heavily.  And while I don't always like all of its aspects, and regularly speak out about its shortcomings (all I need to say is "Lennart" and "systemd"), that doesn't mean ridicule.

Honestly: If you are a member of the FreeBSD community only because you hate Linux, then I would prefer that you were not a member of the community.  Technical decisions about OSes should not be based on hate (nor on FUD or ancient history).



> ... and praise ourselves that we have separated ports and base upgrade mechanic.


The mechanics, the "how" the upgrade works, is not very important.  The important part is much more philosophical: The base is a single coherent thing.  You install either all of it or none of it, and after you install it, you have a functioning shell-based Unix-style OS with networking and the common servers.  It all has a single version number, and as long as you are using just install and update, it transitions from one version to the next mostly atomically and consistently (modulo the fact that until the next reboot, running and installed kernel version may differ).  And its version has isolation against the version of other packages.  The proposals discussed here do not touch or question those axioms.



> It's shameful.


It is not shameful to adopt a good idea when you see it.  Even if it comes from someone outside your immediate community.  Most OS development has worked that way.  Matter-of-fact, the name "Unix" is a play on words of the predecessor "Multics", from which Unix stole many good concepts (while leaving the not-so-good concepts).  The same applies to other sources of ideas, for example: If Microsoft has a good idea, let's use it if it helps, and let's not use it if it doesn't.

I really don't like the fact that so many people use "hate" as their source of technical decisions.  If you hate Linux, I would suggest that you go out for a few beers with Linus, that might make you understand things.


----------



## phoenix (May 1, 2019)

badbrain said:


> FreeBSD "Package Base" Is Now Ready For Testing - More Conveniently Update FreeBSD - Phoronix
> 
> 
> 
> ...



The base OS and the ports tree will still be completely separate.  The base OS lives in /usr/src.  The ports tree lives in /usr/ports.  Ports are installed to /usr/local.  None of that is changing.

All that's changing is that you can run `make package` under /usr/src and get a series of binary packages that can be installed, upgraded, and managed via the pkg(8) tool.  Yes, the same pkg tool that is used for installing binary packages created from the ports tree.  But they install into different spots and have different dependencies and will probably come from different repos.

This isn't turning the base OS into "just another set of packages from the ports tree" (aka the Linux distro model).  This is going to replace the freebsd-update(8) tool that does binary updates of the OS.  Nothing more.

You'll still do development of the base OS under /usr/src.  There will still be a concept of "base OS" that's usable without installing anything from the ports tree.

*Note*:  this is also not an official FreeBSD Project call-for-testing.  This is a call-for-testing of the iX Systems / TruOS binary package setup.  More of a proof-of-concept of one way to do base packages.  There's another project underway (the `make package` target under /usr/src) that's in development by the FreeBSD Project, and has been available for testing since 12-CURRENT.

So, you're getting your knickers in a twist over something completely unrelated to what you're thinking it is.


----------



## Vull (May 2, 2019)

Sounds like a great idea-- a logical extension of the already developed and widely tested FreeBSD pkg system, which is easily and by far the most flexible package management system I've used to date.


----------



## Beastie (May 2, 2019)

Sevendogsbsd said:


> I came to FreeBSD for a couple of reasons: sane init system, OS developed as a whole and the virtual separation of the core OS and the user apps. I personally like that there is a one set of tools to update the OS and one (or more, depending on your choice of packages or ports)  set of tools to update the user apps. As others have said, if it all goes to heck, you can delete /usr/local and the OS keeps on trucking.


In Linux there's no clear separation between the base system and third-party software because as far as a distribution maker is concerned, _everything_ from the boot manager to the web browser is essentially third-party.

FreeBSD too has (and always had) third-party software outside of /usr/local but they're considered to be part of the base simply because they're maintained by the team.

For both operating systems, it really doesn't matter whether there's just 1 tool for updates, or 2 or a dozen. What matters is how things are organized on the file system. And this will not change any time soon. So rest assured you'll still be able to `# rm -r /usr/local` if you want.


----------



## Sevendogsbsd (May 2, 2019)

I don't really need 2 tools to updates the system; It just reinforces in my mind the OS and user apps are separate. This is an informative thread, appreciate the information.

I have only removed the contents of /usr/local once; it's not something I routinely do


----------



## hukadan (May 2, 2019)

A difference that I did not realize until today and that is well discussed in the mailing list is the fact that ports will have dependencies related to other ports (like they have now) but also to base packages. I have no clue if it will be easy for ports maintainers to determine those new dependencies.


----------



## wolffnx (May 2, 2019)

If they keep the option to choice between this new feature and keep using the ports and compile the kernel...is ok
If not...bulsh#@ , but FreeBSD is ok as it is, please..please dont contaminate a excelent system


----------



## sidetone (May 2, 2019)

It will save time on removing extra components from base. Clang and formerly GCC from base take long to compile, then a port will require a newer version. Most of what is in base should be kept in, or it breaks the system, but there are things that can be removed, like cleartext services, without breaking the system, or things you know you won't choose to need at all. It's kind of fun finding which applications break which ports, to inform others about these learnings, except it's very time consuming.

When I leave Clang out of base, and install it from packages, time compiling the base is reduced to 2 to 4 hours, which is great.

Using the compiler and its utilities in base package will be beneficial to prevent redundant compiles and installs, it will speed up troubleshooting and improvements of toolchains, and will clarify better understanding of the purposes of various sourcecodes. As an example, in src.conf one option is labeled as for legacy hardware, but it is required as a dependency for drivers that run new hardware too, and that's not self explanatory.

I like being able to compile the base sourcecode myself, but it's time consuming, and takes a lot of trial and error to get it the way I like without having to start over.

The minimum required FreeBSD system shouldn't be included as options in package base. But package base could be a set of vanguard applications with better [quality] controls than ports. It can also be a good starting point to have common components, that will remove redundancy as bloated dependencies from ports.

Improvements in processor compiling speed, and addition of documentation of which ports and applications require which base components can also do away with much need for package base, except for the compiler and its toolchain.

FreeBSD can benefit from package base, but then, it should largely go back to the original way, while carrying over improvements made on the sourcecode. Then, base compilers and toolchains should either go to PCC, or they should have their own or subset package system.

I see packagebase as a temporary way to ease the transition to libressl and toolchain components for all architectures without having to slow this down by restraining to release cycles.


----------



## ralphbsz (May 2, 2019)

Beastie said:


> In Linux there's no clear separation between the base system and third-party software ...


You have to remember that Linux is not an operating system.  It is a kernel.  The thing with the trademarked name "Linux" is downloaded from kernel.org, and it builds just the kernel (plus modules).  For 99.99% of users, a naked kernel is not useful.

The thing that everyone commonly calls "Linux" is actually a distribution, such as RHEL or Suse.  The distributors take a version of the kernel, often patch it (in the case of RedHat quite heavily), and then package it with all the things that make it into a usable OS, for example run-time libraries (beginning with the very fundamental ones like libc), compilers, an init system, login and authentication, a shell, and basic tools.  At that point, you have what most users would call a "minimal OS".  And the distributor is then free to stack other software on top of it, such as the rest of a LAMP stack, or a GUI and DE, or server applications.  And the distributor is free to decide how to break all of this (including the kernel) into "packages".  In theory, there is nothing that prevents a Linux distributor from creating a version where kernel and base system are a single package; but I've never seen it done.

There is another thing to consider.  Here in the forum, we are in a world of tinkerers, who understand (or at least try to) the internals of the system, and try to "improve it".  We're the kind of people who worry about individual packages.  For example, in the 90s, I used to take whatever Linux version I was running (SLS, Slackware, Debian, RedHat, you name it ...), and immediately rip out the kernel and replace it with a vanilla one from kernel.org.  I was actually modifying kernel sources, and some of my modifications even made it into the official sources.  But: 99% of all users are not tinkerers or hackers.  They install something, and they want it to "work", meaning getting useful work done, with high productivity, and little hassle and anxiety.  They don't care what's underneath the blanket, or how the sausage was made.  Part of that absence of hassle and anxiety is a smooth and efficient upgrade process.  And this is where FreeBSD has (in my not at all humble opinion) great advantages: as long as you keep up-to-date, and run freebsd-update and pkg up* frequently enough (once a week?), it is very smooth.


----------



## Deleted member 30996 (May 3, 2019)

"Following their work on TrueOS, iX Systems has been working to craft FreeBSD into a "pkgbase" configuration whereby the base system and kernel are managed in package form via Pkg."

I have no use for IX Systems of TrueOS. I took a 2 year sabbatical to study on my own around 2007 and when I returned to the PC-BSD forums IX Systems had taken over the the users were seen as a data collection source from their posts.

My reports of the Firewall Manager GUI breaking pf completely ignored for over a month till the black sheep fled that feckless flock to where my words would be heard in the Security community and got results in 1-2 days. They had planned to put off a fix till the next version bump. To my knowldge, I was the only one using PC-BSD 9 Isotope with a functional pf firewall.


As if that wasn't bad enough, on June 22, 2018 I mentioned being Wexiong having been a beta tester for PC-BSD with forum number around #60 and being privileged to first hand information a PC-BSD fanboy would not during a heated discussion between factions.









						Closed - TrueOS plans on getting serious
					

I've been using PC-BSD/TrueOS since Isotope 9.  Then you saw my postings at their discourse forum last summer or thereabouts when I gave TrueOS a test drive. If not, it would be far more effective to read it yourself than for me to blab on about it. They speak for themselves.  However, there's...




					forums.freebsd.org
				




On July 1st 2018 when a post came up about opinions on Firewall managers/builders, the reliability and risk associated with using them.









						Other - Opinions on firewall builder
					

I have been messing with firewall builder and besides its QT dependencies I really like it. security/fwbuilder/ Not being a firwall guy, how would you rate this software? It works with many software firewalls. Is it complete garbage or is it good for new firewall users? Rules can be complex and...




					forums.freebsd.org
				




I checked the PC-BSD forums for my old post and had been ghosted sometime over the previous 8 days. The forums and wiki had all disappeared. I had been looking through the forums recently to view my embarrassing posts from mid to late 2000's. The Forums having been previously referred to in their documentation as a Wealth of information".

Now I don't have to be the Red Devils Advocate to make this case in the court of public opinion. Someone, and I have a good idea who (not Dru) saw that post, realized who I was to them and what that first hand knowledge was. Devastating for the reputation of TrueOS Admin in regard to security of their product, the of safety of their users or having put off fixing it for months..

In their effort to erase 7 years of my life as Weixiong and any sign I ever existed they make the same mistake twice. They underestimated me.

First thinking they could ignore me for a matter this serious and I would say "Baa" like everyone else in the flock did and keep quiet. Weixiong being the only person who spoke up for everyone or saw it as the serious issue it was. After a new member stated he was going to deploy it as a server Weixiong took it to a site where it would not be ignored and posted it as my real name, jitte.

The second time they thought themselves so superior in stature and status to Weixiong in every way they could ghost him and what could a lowly user like Weixiong do about it once it was already vapor? They were just too smart for Weixiong, but not jitte. None too big or powerful for Trihexagonal to fear when speaking the facts.

Out them here like they deserve with every shameful detail of the story for the FreeBSD community to see. You tried and failed to ghost Weixiong, this is the consequences of a failed action you brought on yourself. If he haunted you forever with the story it would be no worse than you deserve in his opinion.

I had never mentioned that here since joining in 2012 out of respect for PC-BSD and the time I had invested in it as professional courtesy. I never would have said a word if they hadn't thought me a fool and a speck of dust to be swept under the rug.

But their memory is no better then their scruples. They forgot I had posted the incident at Widers Security Forum, where they had no to power to undo history. I have page copies saved so don't even think about it. Weixiong is liable to post them anywhere anytime. That made it personal and everyone should know the truth of it as documented.

I feel bad for any detrimental effect or headache it caused Dru, but I only documented the facts. I don't know her personally but the person who did needs take ownership and I don't believe it to be her. Again, I would never said a word if someone hadn't thought a cover-up better than the truth. Now the truth cannot be stopped by anything but the truth about what a mistake it was. I know bigshots never apologize so accept the fact PC-BSD gave it's users the shaft.

Oh please, by all means, someone step up and try to say it was a coincidence and all in my imagination. Someone on that team with authority to delete a forum has now twice thought me stupid, so maybe I'll believe it this time. The smart thing to do is beyond someone comprehension or they never would have tried such a lame scan to begin with.

It's a black mark on not only PC-BSD Admin but your sites claim "TrueOS soars above the competition with advanced security features, such as GELI full-disk level encryption, to keep your important data safe and secure." Something best forgotten for the good of everyone's reputation so it was all erased from recorded history. Mostly.

It will be painful to own up to past mistakes, but no more painful for you than it was for what was done to Weixiong. Honesty the path to redemption and a restful spirit of vengeance. Weixiong spent 7 years of his life to beta test your product, taking 2 off to study and this is how you treat your flock? Weixiong is a restless ghost and this story his to tell as a long he feels like it till he finds peace.


Trust IX Systems or TrueOS? Not me, thanks anyway. I'm happy with FreeBSD the way it is and don't want some bastardized version that can't even make up it's mind what to be called.


----------



## cynwulf (May 3, 2019)

I don't see this as simply an issue of "not invented here".

The clear separation between base and ports should be preserved in my opinion, including the base system tools used to manage and upgrade the base system such as freebsd-update.  The base system is FreeBSD, ports is not.  Many users still build ports from source, many use only a few specific packages/ports and don't necessarily run a desktop system - TrueOS has very different goals/objectives and is focused on being easy to set up and "graphical" "out of the box" (according to their own website).

What this comes across as, to me at least, is more unnecessary reinvention of the wheel and more "monolithic" merging and streamlining efforts.  If you have a specific tool that does a job and does it well, why add even more complexity and scope to the already complex and "apt like" pkg, to take over the role of the already robust and working tool?  Why increase "attack surface", complexity and the probability of more bugs and security issues needlessly just because of some OCD thing to have "one tool".  It all seems very familiar somehow...

At present pkg should only touch /usr/local, with rare exceptions (none at all?).  So this would all change and you have the concern that the pkg tool is also touching the base system.


----------



## badbrain (May 4, 2019)

I like FreeBSD because it's something different. If someday it turned into some Linux clone of BSD license I'll left. I would consider Tribblix, I always want to try it. Let's see how it will be 

Edit: you guys overestimated about FreeBSD as a whole system developed together unlike Linux that you called LEGO. I think it's wrong. You does use and include and adapt/customize/patch third party components nothing different than Linux. The GNU userland despite being portable it main platform is Linux, hence the name GNU/Linux. They are well integrated and well fit together not any lesser extent than FreeBSD. They even more tested and stable than FreeBSD thanks to large user base and much more manpower. The marketing slogan 'developed together, well fit together' just plain nonsense. Just my 2 cents


----------



## zirias@ (May 4, 2019)

I'm looking forward to pkgbase, because it will potentially be a great tool for my usecase:

I have at home a server with many jails and (bhyve) virtual machines, a desktop, several laptops, all running FreeBSD and all using my custom-built base and custom-built ports. For the ports, ports-mgmt/poudriere does a great job building a ready-to-use package repository that can be hosted on e.g. www/nginx. For base, the official way to do binary distribution is a freebsd-update-server. Setting up your own is complicated, I gave up on this. I use a simple workaround instead, suggested here on the forums:

share /usr/src and /usr/obj readonly with NFS to all machines
copy /etc/src.conf to all machines
on all machines except the "master", only do the `make installkernel`, `make installworld` and `mergemaster` steps.
This works very well, but having a `pkg` repository for base would still be nicer 

About all this "cloning Linux" nonsense: FreeBSD is a complete and self-contained OS where toolchain, kernel and basic userland live together in one source repository and are developed together, so they always match. This has *nothing* to do with the mechanism for binary distribution. Building fine-grained packages from this one source tree just adds a bit of flexibility, you can finally leave out some components without building it all yourself. You still get the complete and well-integrated base OS. If you install it, you still have the guarantee that all the basic tools just work, that the toolchain installed is complete to (re)build anything you want, etc. pp. With Linux, all of this is in the responsibility of the "distribution" project. Nothing like that will ever happen to FreeBSD.


----------



## badbrain (May 4, 2019)

Zirias said:


> I'm looking forward to pkgbase, because it will potentially be a great tool for my usecase:
> 
> I have at home a server with many jails and (bhyve) virtual machines, a desktop, several laptops, all running FreeBSD and all using my custom-built base and custom-built ports. For the ports, ports-mgmt/poudriere does a great job building a ready-to-use package repository that can be hosted on e.g. www/nginx. For base, the official way to do binary distribution is a freebsd-update-server. Setting up your own is complicated, I gave up on this. I use a simple workaround instead, suggested here on the forums:
> 
> ...


And what you will experience is just the blessings Linux users long enjoyed   When do comparison, don't cheat by only compare with Linux kernel and think Linux distributions the way Linux From Scratch book doing. Compare with full blown OS like Debian or SUSE. And I think they are just more well integrated and well fit together than FreeBSD, and they have home grown features too, make then distinct from a whole mess of hundreds of distributions


----------



## zirias@ (May 4, 2019)

Boring troll ...


----------



## badbrain (May 4, 2019)

Zirias said:


> Boring troll ...


This is a fact, not troll. But with people always think FreeBSD is the best that even become a religious belief everything opposed to their faith is troll. If you can, please elaborate where I was wrong. I will listen carefully


----------



## zirias@ (May 4, 2019)

Given the torrent of "What you think about" threads you started, all with a lot of negative nonsense and some Linux hate, I sincerely doubt that.

I personally don't hate Linux at all, I hate some particular decisions most distributions made, but that's even off-topic for this thread. The key difference between FreeBSD and Linux you (!) started to talk about is that FreeBSD is a whole operating system while Linux is just a kernel that's combined with a GNU userland by distributors. So far so good. Pkgbase won't change anything about that.


----------



## shkhln (May 4, 2019)

Personally, I think any person praising Debian should be banned on the spot.


----------



## zirias@ (May 4, 2019)

shkhln said:


> Personally, I think any person praising Debian should be banned on the spot.


I wouldn't go _that_ far. IMVHO, Debian made a huge mistake making some p*ware an integral part of the system. But apart from that, I still think it's the most manageable of all GNU/Linux dists. If I, for some reason, need Linux, I'll take Debian (or maybe Devuan, for the p*ware reason).

Anyways, this thread still is about pkgbase. It might be a troll attempt, but I guess we can just ignore that and, well, discuss pkgbase  I still think it's a good idea and hope for a sound outcome.


----------



## shkhln (May 4, 2019)

Zirias said:


> I wouldn't go _that_ far. IMVHO, Debian made a huge mistake making some p*ware an integral part of the system.



Nah, I'm mostly hating multiarch and a myriad of little packaging tools with overlapping responsibilities. Building a customized package from  the FreeBSD ports tree is infinitely more ergonomic and the best part is that I can actually remember the steps. In contrast I'm always confused which Debian tool does what.



Zirias said:


> Anyways, this thread still is about pkgbase. It might be a troll attempt, but I guess we can just ignore that and, well, discuss pkgbase



Except there is nothing to discuss, it's an utterly boring internal infrastructure change born out of desire to avoid maintenance of two similar tools: pkg and freebsd-update. I'm genuinely surprised this thread is not locked by this point.


----------



## sidetone (May 6, 2019)

I'd like to see a limited pkgbase, for compilers, toolchains, and for other rapidly changing developments like maybe newer video drivers. What if I can include only the video driver sets I want, like any combination of ATI, Intel, Nvidia or generic? It would also be nice to select firewalls, to include 1 or all 3 of them by choice. Just to keep the base system trim, but functional.

The install disc can be kept small, and we wouldn't need different installs for boot cd, full cd, and full dvd versions. Just 1 install cd for the running system of under 500mb.

Rapidly and constant developments have to wait for new releases, and that seems to slow it down.


----------



## kpedersen (May 6, 2019)

sidetone said:


> I'd like to see a limited pkgbase, for compilers, toolchains, and for other rapidly changing developments



I agree but actually would also suggest the opposite would work too! A pkgbase for old trusty software. We are already much of the way there with using a specific package prefix. Basically Solaris 10 package systems on steroids. Imagine this kinda thing:

/usr/2010
/usr/2015
/usr/local
/usr/latest

This means that I could use Gnome 2 installed at /usr/2015/bin/gnome-session with Texlive in /usr/local/bin/pdflatex and an experimental clang with /usr/latest/bin/clang.

It would be a massive undertaking to maintain and far more than what the community could handle by itself but certainly if every other operating system disappeared and everyone focused on FreeBSD, it could be possible. Great for digital preservation too!

But yes, offtopic too


----------



## sidetone (May 6, 2019)

kpedersen said:


> I agree but actually would also suggest the opposite would work too! A pkgbase for old trusty software. We are already much of the way there with using a specific package prefix. Basically Solaris 10 package systems on steroids system.
> ...
> It would be a massive undertaking to maintain and far more than what the community could handle by itself but certainly if every other operating system disappeared and everyone focused on FreeBSD, it could be possible. Great for digital preservation too!
> 
> But yes, offtopic too


It's not offtopic, but it's too large a topic.
The scope of pkgbase should be limited. Gnome shouldn't be included, however, there can be allowed an offsite official Gnome and other hosted pkgbase repositories. Let them do that without interfering on the base, and while being compatible on top of the original pkgbase. Gnome doesn't suit everyone's idea of efficiency, but it would be great for them to have a repository. It fits everyone's purpose of varying opinions on what an OS should be.

Pkgbase should be limited to console, perhaps with the exception of a very limited minimal windowmanager, but nothing more. Other BSD distributions have small install mediums with a simplistic windowmanager included.

Pkgbase should be of high quality controls, and strict and limited software selections. Leave GPL3 out of it, and limit to GPL2 for older GCC choices when required for hardware. Let ports and offsite pkgbase repositories revolve around a lean, efficient and logical pkgbase and base system. By default, ports will become efficient, because many redundancies will already be satisfied by something basic. Packages/ports is for everything else.

FreeBSD installs have had microdistribution sets to choose from that were really from ports.


----------



## sidetone (May 10, 2019)

I misunderstood pkgbase from what I wrote above. Pkgbase is not the time saver I thought it would be. Everything still has to be built. But, it would save time for local mirror repositories.

What's not wanted is built anyway, at least for the first time. I don't see many benefits in that, unless src.conf is used as normal.

I want to trim time off of building the base, and not have to compile a compiler, then to compile or get a package for an updated one. I already trim the compiler out of base with src.conf, and be sure to have a compiler from packages.


----------



## badbrain (May 14, 2019)

Zirias said:


> Given the torrent of "What you think about" threads you started, all with a lot of negative nonsense and some Linux hate, I sincerely doubt that.
> 
> I personally don't hate Linux at all, I hate some particular decisions most distributions made, but that's even off-topic for this thread. The key difference between FreeBSD and Linux you (!) started to talk about is that FreeBSD is a whole operating system while Linux is just a kernel that's combined with a GNU userland by distributors. So far so good. Pkgbase won't change anything about that.


I could be ignorant but I'm not motivated to troll or rant. I do not hate Linux. My main OS is Linux. FreeBSD is just another option (2nd option).



sidetone said:


> I misunderstood pkgbase from what I wrote above. Pkgbase is not the time saver I thought it would be. Everything still has to be built. But, it would save time for local mirror repositories.
> 
> What's not wanted is built anyway, at least for the first time. I don't see many benefits in that, unless src.conf is used as normal.
> 
> I want to trim time off of building the base, and not have to compile a compiler, then to compile or get a package for an updated one. I already trim the compiler out of base with src.conf, and be sure to have a compiler from packages.


Many will hate me. But I really like the way of Debian. I like a bunch of .deb packages I could unpack and have a working system. I would like fbsd-base.deb to be the content of a clean and minimal installation with post installation script to set everything up for me. That way I could use debootstrap and don't have to go through many steps like we used to do to manual install fbsd from .txz from .iso media. That way I could upgrade everything as easily as apt full-upgrade. If you just copy the Linux way it's so good but it's not. Another meaningless/careless/unthoughtful move that solved nothing. Disappointed.

Base and ports should use the same compiler like on Linux. No need to bootstrap another compiler for the base. I don't care about such thing as developed as a whole or base and ports separation. Just pure worthless marketing statement.

I like to think in term of package not base nor ports. The package abstraction just like LEGO. Everything is just package and only package. With a right set of packages I could have a working system.


----------



## sidetone (May 14, 2019)

No one hates you. But We don't like hearing about Debian.


----------



## zirias@ (May 14, 2019)

Not even that. Debian is still a good option _in the GNU/Linux world_. But this completely misses the point. We DO like the self-contained base system FreeBSD provides, for good reasons that don't need to be repeated here.









						Why is FreeBSD not (more) like ....
					

As of today, FreeBSD Forums staff will actively close down (and eventually remove) topics that serve no other purpose than to complain that "FreeBSD is not (like) Linux" (or Windows, or MacOS, or any other operating system), or that "FreeBSD does not use systemd", or that "FreeBSD has no default...




					forums.freebsd.org
				




If you look at the very provocative OP in this thread, it seems completely pointless to me and shouldn't be considered any further.


----------



## hukadan (May 14, 2019)

badbrain said:


> I don't care about such thing as developed as a whole or base and ports separation. Just pure worthless marketing statement.


You can like or dislike this separation, but calling it a marketing statement shows that you are at best ill-informed.


----------

