I expect BSDisms to be dropped at some point
Uncategorized
15
Posts
2
Posters
1
Views
-
RE: https://mastodon.bsd.cafe/@stefano/115716905758059408
I expect BSDisms to be dropped at some point.
The newer FreeBSD pkgbase is slowly getting to being able to upgrade the whole system, so the mess with many tools is solved. It's catching up, really.Just put all binaries under /usr/bin and have everything else symlink to it, such as /bin, /sbin, /usr/local/bin or whatever. It has been done before.
This whole thing is mostly legacy from when we had very limited storage. Nowadays, we have terabytes on NVMe SSDs, not few kilobytes.
@CyReVolt Personally, I disagree. The separation between the base system and packages is something extremely positive in FreeBSD and NetBSD. Keeping separate what is part of the base system and required for the OS to function (/usr/bin) and external packages (/usr/local/bin) is a plus, not something legacy.
Pkgbase is not meant to change this behavior, but to unify the methodology used to manage and update the OS with that used for packages. Creating symlinks is possible, but in my view it is not a clean solution.
-
RE: https://mastodon.bsd.cafe/@stefano/115716905758059408
I expect BSDisms to be dropped at some point.
The newer FreeBSD pkgbase is slowly getting to being able to upgrade the whole system, so the mess with many tools is solved. It's catching up, really.Just put all binaries under /usr/bin and have everything else symlink to it, such as /bin, /sbin, /usr/local/bin or whatever. It has been done before.
This whole thing is mostly legacy from when we had very limited storage. Nowadays, we have terabytes on NVMe SSDs, not few kilobytes.
@CyReVolt Just to give another example of why, in my view, it makes sense: I can create thin jails with BastilleBSD in just a few seconds, knowing that the base system is fixed and that everything installed will end up in /usr/local. Everything else is read only. Very little disk usage, zero storage overhead (and the files will be cached in RAM only once, even for hundreds of jails), greater security, and simplicity when moving jails from one host to another or restoring them from backup.
-
@CyReVolt Just to give another example of why, in my view, it makes sense: I can create thin jails with BastilleBSD in just a few seconds, knowing that the base system is fixed and that everything installed will end up in /usr/local. Everything else is read only. Very little disk usage, zero storage overhead (and the files will be cached in RAM only once, even for hundreds of jails), greater security, and simplicity when moving jails from one host to another or restoring them from backup.
@stefano That's just fine. I would just do it simpler:
- have all packages (3rd party and base) in the same source tree
- define a sets of packages to be the base systemNow I can easily get rid of collisions. No more "yea but I have the SSH from my base system - or do I?" and stuff like that. Just have one and it be the latest. Keep the whole thing rolling.
If anyone needs anything different, they can always fork the whole tree and modify it, possibly file PRs to upstream. -
@CyReVolt Personally, I disagree. The separation between the base system and packages is something extremely positive in FreeBSD and NetBSD. Keeping separate what is part of the base system and required for the OS to function (/usr/bin) and external packages (/usr/local/bin) is a plus, not something legacy.
Pkgbase is not meant to change this behavior, but to unify the methodology used to manage and update the OS with that used for packages. Creating symlinks is possible, but in my view it is not a clean solution.
@stefano Yea ideally I'd do it without symlinks, just get rid of the different hierarchies altogether. The many pieces of software meant to provide a system can just go in the same place, no need to say "but xyz is not base". The user decides what their base system is.
What makes more sense to be separate is high-level GUI apps and services, such as, say, web browsers or web services.
Those can easily run in containers or whatever one wants to call it. -
@stefano That's just fine. I would just do it simpler:
- have all packages (3rd party and base) in the same source tree
- define a sets of packages to be the base systemNow I can easily get rid of collisions. No more "yea but I have the SSH from my base system - or do I?" and stuff like that. Just have one and it be the latest. Keep the whole thing rolling.
If anyone needs anything different, they can always fork the whole tree and modify it, possibly file PRs to upstream.@CyReVolt I agree that the current situation can lead to confusion, especially for users who are not fully aware of how path precedence works and what is actually being used at runtime. The approach you’re proposing certainly has some advantages and, in a way, simplifies a few things.
OpenBSD, for example, does not use a separate hierarchy, while still maintaining a very clear separation between the base system and packages. This is also why it requires all packages to be updated immediately after an OS upgrade. The separation between the base OS and packages is still very explicit and intentional.
I think the current approach is consistent with the BSD philosophy. That it can be improved is beyond doubt. However, in my view, the solution is not to make the BSDs more like Linux. Not because the Linux approach is wrong, of course, but because they represent different usage philosophies.
Linking this to the other meme you shared, and in line with my latest post on my IT Notes blog, I don’t see this as a religious war or a question of "not being Linux". Different approaches come with different pros and cons. There isn’t a single right or wrong model, it really depends on the requirements.
-
@stefano Yea ideally I'd do it without symlinks, just get rid of the different hierarchies altogether. The many pieces of software meant to provide a system can just go in the same place, no need to say "but xyz is not base". The user decides what their base system is.
What makes more sense to be separate is high-level GUI apps and services, such as, say, web browsers or web services.
Those can easily run in containers or whatever one wants to call it.@CyReVolt I think there is a more fundamental difference here.
The base system is developed and maintained by a clearly defined core team, whose responsibility is to ensure that everything works together in a coherent way. Packages, by definition, are external.From my point of view, packages are expected to work correctly on top of the base system, not the other way around. Mixing the two would blur this boundary and effectively shift additional responsibility onto the core team.
That would be a forced change and, in my opinion, an unnecessary extra burden, which goes against one of the core strengths of the BSD approach: a well-defined, cohesive base system with clear responsibilities.
-
@CyReVolt I agree that the current situation can lead to confusion, especially for users who are not fully aware of how path precedence works and what is actually being used at runtime. The approach you’re proposing certainly has some advantages and, in a way, simplifies a few things.
OpenBSD, for example, does not use a separate hierarchy, while still maintaining a very clear separation between the base system and packages. This is also why it requires all packages to be updated immediately after an OS upgrade. The separation between the base OS and packages is still very explicit and intentional.
I think the current approach is consistent with the BSD philosophy. That it can be improved is beyond doubt. However, in my view, the solution is not to make the BSDs more like Linux. Not because the Linux approach is wrong, of course, but because they represent different usage philosophies.
Linking this to the other meme you shared, and in line with my latest post on my IT Notes blog, I don’t see this as a religious war or a question of "not being Linux". Different approaches come with different pros and cons. There isn’t a single right or wrong model, it really depends on the requirements.
@stefano Agreed. I was exaggerating with the meme to a degree, because it's the impression I often get (and I think that is somewhat objective).
My gut feeling tells me that there is still a lot going to happen.
-
@stefano Agreed. I was exaggerating with the meme to a degree, because it's the impression I often get (and I think that is somewhat objective).
My gut feeling tells me that there is still a lot going to happen.
@CyReVolt Agreed. There are definitely fanboys in the BSD world too, and some people are reflexively anti-Linux regardless of the actual technical discussion, which I don’t think is healthy or useful.
That's exactly why constructive conversations like this one are positive and valuable. Different perspectives help everyone think more clearly about the trade-offs involved.
-
@CyReVolt I think there is a more fundamental difference here.
The base system is developed and maintained by a clearly defined core team, whose responsibility is to ensure that everything works together in a coherent way. Packages, by definition, are external.From my point of view, packages are expected to work correctly on top of the base system, not the other way around. Mixing the two would blur this boundary and effectively shift additional responsibility onto the core team.
That would be a forced change and, in my opinion, an unnecessary extra burden, which goes against one of the core strengths of the BSD approach: a well-defined, cohesive base system with clear responsibilities.
@stefano I stand with that core idea.
At the same time, I see a lot of extra software commonly installed - such as whatever preferred shell or modern CLI tools like rg.
And then, putting the specific FreeBSD idea of what comprises the separation aside, everything ends up in a PATH anyway.
So the end user has their own idea of a base system for themselves. And I think a good system would support them in doing that.
Maybe have the end user choose what they consider *their* base packages? -
@stefano I stand with that core idea.
At the same time, I see a lot of extra software commonly installed - such as whatever preferred shell or modern CLI tools like rg.
And then, putting the specific FreeBSD idea of what comprises the separation aside, everything ends up in a PATH anyway.
So the end user has their own idea of a base system for themselves. And I think a good system would support them in doing that.
Maybe have the end user choose what they consider *their* base packages?@CyReVolt In this respect, distributions like Alpine Linux (or smolBSD) are probably the best solutions. In practice, you get only the bare minimum needed to boot. After that, you decide what your base system should be.
-
@CyReVolt In this respect, distributions like Alpine Linux (or smolBSD) are probably the best solutions. In practice, you get only the bare minimum needed to boot. After that, you decide what your base system should be.
-
-
Oh it's a very recent thing, it seems?
https://smolbsd.org/ was featured on hn just some months ago -
Oh it's a very recent thing, it seems?
https://smolbsd.org/ was featured on hn just some months ago
Gli ultimi otto messaggi ricevuti dalla Federazione
-
è entrata in politica in un'area dileggiata dalla sinistra, si ritrova al governo con la sinistra e l'opposizione più squinternata di sempre e sfoga il suo rancore
-
Atreju e l’odio messo in scena
@giornalismo
articolo21.org/2025/12/atreju-…
La derisione del dissenso, la ridicolizzazione del conflitto sociale, la svalutazione della memoria
L'articolo Atreju e l’odio messo in scena proviene da Articolo21.
-
@afreytes what happened NOW
-
@sunumbral spaghetti!
-
@phabrizio perché difficile da installare?
-
@krans this is where some kind of global user preference setting becomes important, so that programs can default to the global user preference
-
Ma che ha Signal? Funziona malissimo: barra per scrivere che si nasconde dietro quella degli strumenti perciò è impossibile scrivere un messaggio, se ruoti il cellulare esci dall'app.
Chiaro che XMPP è meglio, ma almeno Signal che sarebbe un buon compromesso e che non è difficile come XMPP da installare...
-
@LaVi Ho delle foto da bambino/ragazzino della neve (vivo in montagna). Sono passati poi, sì e no, un po' più di una decina d'anni. Ora niente. Lo scorso anno lo zero assoluto.
