systemd-oomd Looks Like It Will Come Together For systemd 247

[k1e0x]

https://github.com/freebsd/freebsd/b...fig/ifconfig.c http://net-tools.sourceforge.net/
ifconfig on and bsd is in fact different to ifconfig on linux. So ifconfig on Linux has been developed independent of kernel work.

Now if you are after the Linux true equal to ifconfig on freebsd we are talking

https://wiki.linuxfoundation.org/networking/iproute2

The ip command. This has not been evolutionary winners. Iproute2 is a kernel.org project that was made because the independent projects like net-tools came basically a mess of what features they did and did not support and iproute2 was basically start from scratch because everything was a mess.

Network manager is in fact something different. https://www.freshports.org/net-mgmt/networkmgr/ Yes GhostBSD was first to make their own clone of Linux network manager and now other BSD are picking this up. Its not ifconfig or ip command stuff but a higher level of abstraction same with netplan.


Are you really sure.



This is kind of wrong. In large section of the datacenter and enterprise Linux not Unix because Linux is cheap. Linux has basically crushed commercial Unix out of most markets. Linux does not perfectly match Unix either.



Except this is kind of wrong in about year 2000. Linux basically defeated Unix. So its not 50 years of success. 20 years ago Unix lost it location. About year 2000 you see the body talking about Unix standards talking about using Linux syscalls going forwards. Unix to Linux move gives us how long you need to replace a model. 9-10 years of proof that the new model works so decades of proof is pointless the last decade of proof is the important bit to start growing migrations.

The reality here is what Linux did not kill of commercial Unix the BSD end up cleaning up most of the market. Unix today is basically scraps.

Posix standard that define unix if you look closely has not been updated really since 2008. Yes the 2017 release was basically bind into the 2008 standard two 2008 optional extras and that was the total of the Posix Standard 2017 changes. There is really no Posix standard work any more. So now Linux is going it own way. Some *bsd developers have been starting to see this as well.

Its basically heading on the path Unix is dead long live Linux.

Linux is (or was) a Unix type system. Another clone. There are plenty of weird Unix's out there with lots of differences between them. (and no i'm not talking about the trademark UNIX(tm) no caps here.) And in Linux's early days it had to live in a Unix dominated world. It generally followed a lot of the same conventions, has a lot of the same syscalls. The GNU userland itself is a Unix clone as well.

Somewhere around the time Linux started to gain dominance they.. for whatever reason.. decided they no longer were or wanted to be Unix.. and I feel that is a real shame.

Specifically on ifconfig, it's a policy thing. It was broken in Linux, but instead of fixing it and maintaining consistency they replaced it. This happens SOOO often in Linux. It was broken in BSD too, did they replace it? NO. They fixed it. Why? Because they want to keep that consistency.

Changing things on your users is BAD. You have to rewrite all your documentation and your tools and for what? NIH?

It's also garbage.. compare the output on FreeBSD to Linux. What one is more readable? - Why is that? I have a guess that in Linux it was designed to be scripable.. so we are back to what one is a mess of scripts?

My point is.. You can change the underlying code without changing the commands and functions and breaking everything. (that is what FreeBSD did) This is reminiscent of Windows embrace, extend and extinguish. The extend phase. Changing things to force your way of doing stuff. By not staying consistent Linux seems to be acquiring all of the characteristics that drove people to abandon Windows for Linux in the first place.

[hakavlad]

Why not fix the problem in the kernel?

Like not swap executable code when the system is near-OOM?

You can use https://github.com/hakavlad/prelockd to lock executable cod in memory.

Effects:

- OOM killer comes faster.
- Fast system reclaiming after OOM.

[tildearrow]

You can use https://github.com/hakavlad/prelockd to lock executable cod in memory.

Effects:

- OOM killer comes faster.
- Fast system reclaiming after OOM.

Really? o-o

But there is a little detail: does this apply for processes opened after the daemon is running? (I don't see any code that automatically locks executable code in new processes but this is a good start point already)

[hakavlad]

Really? o-o

But there is a little detail: does this apply for processes opened after the daemon is running? (I don't see any code that automatically locks executable code in new processes but this is a good start point already)

If you restart it afer log-in, it will keep basic GUI code in memory. It is enough to improve performance. The demon was written recently and will be improved later.

[oiaohm]

Linux is (or was) a Unix type system. Another clone. There are plenty of weird Unix's out there with lots of differences between them. (and no i'm not talking about the trademark UNIX(tm) no caps here.) And in Linux's early days it had to live in a Unix dominated world. It generally followed a lot of the same conventions, has a lot of the same syscalls. The GNU userland itself is a Unix clone as well.

This is where everything starts going wrong. Yes Linux was designed of some of the Unix ideas but it also did thing very different. One of those was in fact very different is the way the Linux network stack was done.

Somewhere around the time Linux started to gain dominance they.. for whatever reason.. decided they no longer were or wanted to be Unix.. and I feel that is a real shame.

The reality is Linux was never a Unix or BSD. Yet people like you tried to make it something it was not k1e0x.

Specifically on ifconfig, it's a policy thing. It was broken in Linux, but instead of fixing it and maintaining consistency they replaced it. This happens SOOO often in Linux. It was broken in BSD too, did they replace it? NO. They fixed it. Why? Because they want to keep that consistency.

No the ifconfig issue is way different.

https://en.wikipedia.org/wiki/Ifconfig

The reality is ifconfig was designed for the BSD network stack so it very possible for freebsd and others to fix the issues. The reality here is the Linux kernel is a network stack written from scratch that is different to the BSD network stack. Yes the Unix systems that had ifconfig historically were also using a network stack based off BSD.

Some time you should spend time looking at
https://www.freebsd.org/cgi/man.cgi?ifconfig(8) and https://linux.die.net/man/8/ip

The reality here is the ip command provides options that the ifconfig does not. In fact worse some of the ways ifconfig does its network options does not suite the Linux networking stack at all.

Changing things on your users is BAD. You have to rewrite all your documentation and your tools and for what? NIH?

Not the case ifconfig to ip by Linux is the fact ifconfig has been a round peg with a square hole on Linux.

It's also garbage.. compare the output on FreeBSD to Linux. What one is more readable? - Why is that? I have a guess that in Linux it was designed to be scripable.. so we are back to what one is a mess of scripts?

Wrong question what one really displays the information the Linux network stack is using to the end user. Ip command does. Like it or not the Linux kernel networking stack is more complex than the BSD one. ifconfig command cannot while remaining compatible with BSD scripts. So fixing ifconfig for Linux was going to break scripts and user interactions anyhow so the iproute2 developer decided to make it a clean solid break so that old not functioning correct ifconfig could still be installed while new ip command that provides the correct information about the Linux network stack could be present.

My point is.. You can change the underlying code without changing the commands and functions and breaking everything..

iproute2 is a kernel.org project this is something you missed. Kernel.org has a mandate against breaking userspace where at all possible. There are points where avoiding breaking userspace is not possible. Ifconfig does not have to exist for a operating system to be classified as Unix. Ifconfig on Linux was always a hack and never really fitted right because it was not designed to work with the Linux kernel network stack ever instead was having BSD network stack ideas shoe horned on top of Linux kernel network stack. Same with many of the alternatives to ifconfig that were on Linux where they came from some other operating system and were shoe horned on top of Linux.

One of the biggest in the face shoe horning is the sysvinit stuff. There is no way that sysvinit design can work correctly on Linux because sysv operating system that its from had the idea that PID numbers would not be reused yet from day one Linux kernel has PID recycling. PIDFD that is been added finally in 5.3 Linux finally is working on addressing the issues PID recycling causes.

There are quite a few cases where items have been done on Linux that have really been round peg square hole issues that have been done in the goal of so called compatibility. Once these items started being replaced with items designed to work correctly with how the Linux kernel has been designed to operate people have got upset.

Something to remember Unix operating systems with PID recycling without proper handling of PID recycling is insanely common. Same with unixs providing ifconfig and another command to properly control their network stack. There is a long list of broken the Posix standard and Unix operating systems never addressed. Yes as you go and address some of the known Unix broken you will have to break compatibility with the old in places because it really never worked and making it work now will just break more.

[tildearrow]

If you restart it afer log-in, it will keep basic GUI code in memory. It is enough to improve performance. The demon was written recently and will be improved later.

Temporary idea: run the daemon with idle priority (so it does not affect performance), and trigger the lockall every 15 minutes.

[shevy]

oiaohm wrote:

> The reality is Linux was never a Unix or BSD. Yet people like you tried to make it something it was not k1e0x.

Linux is very much UNIXy. I have no idea why you claim it was not, but for anyone who likes to dig a bit
into history, I can recommend this nice youtube video:

https://www.youtube.com/watch?v=tc4ROCJYbm0

Title: AT&T Archives: The UNIX Operating System

My favourite part, and IMO the most relevant one, is when Brian Kernighan is talking and showcasing
UNIX back then. Many other oldschool UNIX veterans are dead, but Brian is still alive, in surprisingly
good health (from what I can tell) these days (he is almost 80 years old now) and still gives epic talks.

If you look at what Brian was doing back then, you instantly notice how similar the whole Linux stack
is. You can technically say that the BSD variants are closer to UNIX than "Linux" is; and we have a few
technical aspects to include, such as that Linux is actually "merely" a kernel, per se - but by and large
anyone writing "Linux was never a Unix" is just ignorant of history or deliberately trying to insinuate
that the two (Linux + UNIX) have nothing to do with one another whatsoever.

Linux is VERY similar to how UNIX was. Please don't try to leverage your own age as a reason to
retrofit history when there is overwhelming evidence available counteracting such strange
statements.

https://en.wikipedia.org/wiki/History_of_Linux#The_creation_of_Linux

[oiaohm]

oiaohm wrote:If you look at what Brian was doing back then, you instantly notice how similar the whole Linux stack
is. You can technically say that the BSD variants are closer to UNIX than "Linux" is; and we have a few
technical aspects to include, such as that Linux is actually "merely" a kernel, per se - but by and large
anyone writing "Linux was never a Unix" is just ignorant of history or deliberately trying to insinuate
that the two (Linux + UNIX) have nothing to do with one another whatsoever.

Problem here Linux was never design to be a Unix. You did not read your own reference.

https://en.wikipedia.org/wiki/History_of_Linux#The_creation_of_Linux

Yes go back and read notice that Linus in his first post about Linux is talking about minix.
I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things).

So a lot of early developers of Linux are not from the normal Unix world. But are people who got their chops under Minix. This leads to network stack having features you would expect in Minix that you would not expect BSD or a Unix. Some of Linux posix functionality errors directly match Minix ones.

So you can think of Linux as Minix done with a monolithic kernel instead of Minix microikernel.

Linux is VERY similar to how UNIX was. Please don't try to leverage your own age as a reason to
retrofit history when there is overwhelming evidence available counteracting such strange
statements.

Except this is ignoring Minix. Linux has a lot more in similarity to Minix than your traditional BSD and Unixs and it makes sense for where the early developers of Linux came from.

Claiming overwhelming evidence is really that you simple ignore a key bit of evidence that says Linux being Unix/BSD is wrong. Linux is it own development line breaking off Minix.

https://en.wikipedia.org/wiki/Unix#/media/File:Unix_history-simple.svg

Also pay for you to look at above shevy.

linux and Minix have the title Unix-Like. BSD/Unix are all under the same are the interlinking lines between rows between the BSD/Unix are all direct code sharing. Linux has not shared code with Unix/BSD that effect core behaviour. Since Linux kernel does not share code with Unix;/BSD for core behaviour you cannot expect operating systems behaviour to be as close.

Shevy being a Unix-like means Linux can be similar to Unix but that turns out to be more that Minix is so similar to Unix and the GNU user-space was modelled after Unix that makes Linux look Unix. Problem is once you scrap away the GNU userspace layer and look at the Linux kernel the shared code you expect to find between commercial Unixs and BSDs just does not exist in Linux. Why Linux is not Unix or BSD instead Linux is Unix-like coming of another Unix-like being Minix so its two generation abstracted away from the BSD/Unix stuff.

Linux being Unix-like explains why ifconfig from GNU userspace stuff on Linux really did not fit right. Ifconfig is design for something with a BSD/Unix related network stack. Linux is not a BSD/Unix related network stack not even a single line of code is in fact shared. Heck windows network stack shares more with BSD/Unix than Linux does. Way Linux kernel recycles process id numbers and does threads does not match up to how BSD/Unix would either. There is really long list of stuff that does not match up.

The hard reality for years people have tried to make the Linux kernel have a userspace on top that behaves like a Unix/BSD problem is this is never going to work properly because the Linux kernel is a independent work to BSD/Unix with its own quirks.

"Linux was never a Unix" is a true statement like it or not if you look at where it code comes from. There is no link from core Linux kernel source to anything BSD or Unix this means behaviours at times being different should be expected.

[hakavlad]

Temporary idea: run the daemon with idle priority (so it does not affect performance), and trigger the lockall every 15 minutes.

Done:

$POLL_INTERVAL_SEC=600

$STORE_SNAPSHOTS_NUM=144

https://github.com/hakavlad/prelockd/blob/master/prelockd.conf

[hakavlad]

Why not fix the problem in the kernel?

Like not swap executable code when the system is near-OOM?

Kernel-side solution: https://github.com/hakavlad/le9-patch

Also look at https://www.phoronix.com/scan.php?pa...-Linux-Low-RAM