FreeBSD development seems lost

atax1a said:
huh, what we're hearing is that you won't use it because you have to learn how to use it. weird flex, but ok
Click to expand...
I don't use it because it doesn't show what it executes, which is elitarianism. Not really far away from the motivation for the systemd discussion in the opposition.
Start a new thread about rc.d. I can dump 1 412 lines /etc/rc with everything for a particular mfsroot llive system I made. It's generated from different code fragments by a script. It's not going to work because it assumes a boot situation with a set of binaries in a mfsroot ramdisk.
 
really struggling to understand the reasoning here. development is lost and "elitarianist" because the rc system doesn't work to your expectation, and your script-generated system doesn't work, therefore, what, exactly ???
 
atax1a said:
really struggling to understand the reasoning here. development is lost and "elitarianist" because the rc system doesn't work to your expectation, and your script-generated system doesn't work, therefore, what, exactly ???
Click to expand...
In this context it means a group dictating a standard like it's a natural presence and obscuring the actual operation of things that already existed before the group. Fortunately, we're on OSS grounds and we can do whatever we want legally.

Add for the Rust-kernel discussion: The owner of a computer should have the unconditional permission to develop unsafe. 😆💪
 
MG said:
In this context it means a group dictating a standard like it's a natural presence and obscuring the actual operation of things that already existed before the group. Fortunately, we're on OSS grounds and we can do whatever we want legally.

Add for the Rust-kernel discussion: The owner of a computer should have the unconditional permission to develop unsafe. 😆💪
Click to expand...
Isn't that already the case here? Or do I not understand the status quo because I thought that there were multiple options that could be slotted in if you so chose without necessarily having to do a ton of work It's one of the issues with systemd where it's bloated up to cover things that wouldn't traditionally be done by an init system, which makes it a lot harder for non-Linux OSes to support software that depends on it.
 
IMHO, it's kind of weird how some people seem to think that pkg base is the first step towards just casting it all out and going with the Linux Kernel+Random whatever the distro maintainer wants to bundle with it to get a distro out of it. Considering that FreeBSD is already pretty minimal in terms of the base system and you can install all sorts of stuff on top of it, I'd expect that we'd already have a million *BSD distros by now if there were any sort of real interest in doing so. Sure, there have been a few distros of sorts of the years like m0n0wall, but for the most part, they were things that tended to diverge fairly significantly from what you could do with a base system, even though there wasn't ever anything in terms of licensing or tooling to stop people from doing it. Introducing pkg base isn't going to change that. Google has been doing the same basic thing for years now where they're moving more things to play store apps that can be updated independently of the core system. So, it's not like there isn't any upside here.

Personally, having used FreeBSD on and off for over 25 years at this point, I'd expect that things that all the stuff that one could reasonably need to install the system and connect to a network is still going to be there on the disk. And if using pkg becomes any sort of a real issue for people that we'll see the same sort of support utilities to better allow the separate maintenance of the pkgs/ports from the base system. There's also the bit that nobody is talking about getting rid of ports, which pretty much guarantees that there will always be a mechanism of keeping the base system separate from the user compiled stuff just as a way of avoiding having to test every possible interaction that could happen with user compiled software anyways.

Also keep in mind that the source code for the OS is going to be available and recompiling the whole thing is something I've personally done a few times, and I have yet to successfully get the Linux kernel to compile. (Admittedly that was quite a few years ago that I last tried, so it might be easier now)
 
On a separate note. As far as flatpak/snap/whatever else goes. FreeBSD has a pretty good selection of options. It's fully possible to stick to just ports or pkgs if you want to, I was not able to do the same with Linux in the last year as inevitably there was at least one piece of software that was only available in a form other than the one that all the other software I was using was using. FreeBSD having both thin and thick jails along with VMs and what appears to be pretty decent podman support is a great way to go. I'm still learning, but I was able to get eclipse running inside of a podman container with perpetual storage to go with it.
 
hedwards said:
On a separate note. As far as flatpak/snap/whatever else goes. FreeBSD has a pretty good selection of options. It's fully possible to stick to just ports or pkgs if you want to, I was not able to do the same with Linux in the last year as inevitably there was at least one piece of software that was only available in a form other than the one that all the other software I was using was using. FreeBSD having both thin and thick jails along with VMs and what appears to be pretty decent podman support is a great way to go. I'm still learning, but I was able to get eclipse running inside of a podman container with perpetual storage to go with it.
Click to expand...
Just out of curiosity, why Eclipse inside a podman container?
The pkg version works fine except for the missing marketplace (i.e. need to manually find update sites) and for a severe lack of libs which use C wrappers and lack freebsd libs.
 
bored2tears said:
Thanks to FreeBSD jail(8) magic and it's limitless nature, you can actually isolate the software without resorting to having another copy of OS stored somewhere, and said software could be installed with pkg(8). I've done that, and I should probably write about it on forums. You can literally use your host / as jail root (though nullfs-moutned somewhere else) and then nullfs/tmpfs to allow/deny acess to filesystem. Everything else is standart jail magic -- networking, securelevel, whatever.
Click to expand...
It's called `ephemeral jails`. It's also a thing of beauty. Arguably, it's just as important and thin/thick jails, or more, but gets no word in the handbook.
 
if not someone already say it , The developers need MONEY as FreeBSD foundation too, I wish to donate but I dont got the money,
is raw but is the true,that people make a great job for the users for have what we got,they deserve it
 
fahrenheit said:
Just out of curiosity, why Eclipse inside a podman container?
The pkg version works fine except for the missing marketplace (i.e. need to manually find update sites) and for a severe lack of libs which use C wrappers and lack freebsd libs.
Click to expand...
Mostly because I'm learning how to use podman and it was easier to do than something that benefits more from it like a web browser. It's not really something that I'd particularly advise people doing for that program, or at least I haven't found a non-learning reason to do it.
loveydovey said:
It's called `ephemeral jails`. It's also a thing of beauty. Arguably, it's just as important and thin/thick jails, or more, but gets no word in the handbook.
Click to expand...
Interesting, I'm going to have to look into that. I see DtxdF posted something about that months back, I'll have to take a closer look when I have time.
 
You must log in or register to reply here.
Back
Top