zare_st

But the stuff that carries TCP is IP. That's why TCP can work seamlessly, because it uses identification from a previous layer. Consider I bind a server to an ID, and not IP:port, the operating system running it must know how to communicate that via IP, so there will be a corellation map somewhere and that map needs to be synchronized between all peers that wish to host the roaming server.

Otherwise you're just switching port (16-bit) value to arbitrary 32-bit identifier.

Yeah it's a shortsighted plan. How would i set up rules on firewall if I don't know how to distingush the connections?

I don't think is wise even if you had written guarantees from their state via the business, because how your state might look at it.

It's a war, things have changed.

Absolutely no.

If a line of code belongs in a project with one file and a main() function, the presumption of impact of that code line on overall code paths is trivial.

If that line of code belongs in a library procedure used by a million LOC project, presumption cannot be done if you don't the project internals and tooling.

Rewriting entire systems or frameworks because one thinks that it's hard to implement a certain class of features is almost always a recipe for disaster.

For specific cases, asm is faster than c.

I'll show myself out

Valgrind will show these as "still reachable"

Never. Individuals with that kind of mutation have to be born per random chance, and then selected via sexual preference.

Why would systemd unit files matter for FreeBSD? FreeBSD has its own rc system and its own ports and packages and maintainers. If and when some major software starts lagging behind the upstream because of runtime issues, then it's time to discuss the alternatives. Right now such things do not happen.

FreeBSD had to mock several parts of systemd in order to port newer GNOMEs that are dependent on systemd. rc still runs this software, but unfortunately software depends on systemd sockets which is absurd design choice but here we are. Again mocking the absurd interprocess part is the way to go, as opposed to supporting entire specification and API of systemd.

"Any unix" doesn't cut it, too general, too broad. You did ask in dual sense in your original question but then you specifically stated FreeBSD as an example; so I'm answering for FreeBSD specifically.

The problem that I have with opinion in your post is an implication about groups of people - people with skills that should supposedly write a systemd clone for FreeBSD or other Unices, and people without skills that are supposedly waiting for the first group to do some work so they can enjoy systemd on *BSD or wherever. Let me be blunt here, I can assure you this is not the case. Systemd is not a factor for anyone in BSD world and it's a factor only for people that would like to migrate from Linux and retain their usual workflow and muscle memory.

Answer to question - yes, and more. Jails+rctl (available since 2012) is not cgroups it's cgroups+SELinux+APParmor. Vanilla linux container is not a security barrier, vanilla FreeBSD jail is.

In practice this means more seamless 'isolation' in Linux case but that isolation is weak. Which perfectly corresponds to FreeBSD looking at server uses 99% of the time and Linux looking at the desktop too.

About your conclusion, I don't think that's based on anything so please do write on what facts do you base the assessment that FreeBSD has no resource limiting and isolation features, and that it would be a 'separate implementation', as FreeBSD always tends to upgrade and not change tools and interfaces, and that there is not enough interest from anyone to implement it, as most major FreeBSD features are actually paid for by FreeBSD sponsors.

Yes

Organization proven to use and abuse the security via obscurity model.

Tricky? Checking if you're bound to TTY is trivial, checking whether you have a parent is trivial, checking whether interactive shell is somewhere in the tree is trivial, having some if's in signal handlers is trivial, etc.

Besides "daemon writers" could just default to foreground, because if it's ran as a daemon it is ran from a script hence nobody cares for extra option typing such as -d --daemon, it's written once in a file, as opposed to doing "program --foreground" every time you want it to run in front of you

Average person doesn't have strong opinion about some bit of data irrelevant to their life.

If there is a thing, and topic about it has reached the internet discussions, the participants will have an opinion regardless of their actual practical knowhow about the thing. They'll form their opinion otherways. Platforms like Reddit favour a master opinion due to score and moderation system, so one out of N wrong theories will surface as the master opinion.

In real life, if you ask bunch of random people about the thing they don't know, you get wildly different answers, and largely no-one will back up anyone there. Certainly not in enough force to push a confidently wrong answer up as the "people's opinion"