OpenBSD 5.1 Released

Quote:

---

Originally Posted by kraftman

Still, the features and completeness can make a difference.

---

I don't think this are only feautures:
Statically linked and striped "hello world" (only puts() used) binary.
Arch Linux: 737.2KB
OpenBSD: 83.1KB

I'm not sure if this is only because of glibc. It might be because of virtual library "linux-vdso.so". It doesn't matter anyway.

Quote:

---

Originally Posted by kraftman

Documentation says "don't overcommit", so it doesn't sound so confusing to me. ;) I never set any limits for processes, but maybe ulimit is what you are looking for.

---

This part: "The total address space commit for the system is not permitted to exceed swap + a configurable percentage (default is 50) of physical RAM"
It doesn't mention free or available RAM.

Quote:

---

Originally Posted by kraftman

Linux and OpenBSD are mostly POSIX compliant, but there are situations where POSIX says nothing and Linux (and probably BSD) has to do things on its own. The one I remember had to do something with real time and scheduling.

---

Yes, but they try to be as much as possible. Of course there are some missing parts.

Quote:

---

Originally Posted by LightBit

This part: "The total address space commit for the system is not permitted to exceed swap + a configurable percentage (default is 50) of physical RAM"
It doesn't mention free or available RAM.

---

"The total address space commit for the system is not permitted to exceed swap + a configurable percentage (default is 50) of physical RAM." It does mean it won't exceed your physical memory (RAM + swap), so it won't overcommit. It simply can't exceed the free memory and not exceed RAM + swap same time. When you have 2GB of RAM and only 1GB is free then it can't allocate more than 1GB, because it will overcommit.

Quote:

---

Yes, but they try to be as much as possible. Of course there are some missing parts.

---

I think it's better to be mostly rather than full POSIX compliant. If you are mostly compliant you overcommit POSIX limits. ;) Full POSIX compliant are some of the legacy systems.

Quote:

---

Originally Posted by LightBit

I don't think this are only feautures:
Statically linked and striped "hello world" (only puts() used) binary.
Arch Linux: 737.2KB
OpenBSD: 83.1KB

I'm not sure if this is only because of glibc. It might be because of virtual library "linux-vdso.so". It doesn't matter anyway.

---

Take a look here:

http://www.etalabs.net/compare_libcs.html

and here:

http://en.wikipedia.org/wiki/GNU_C_L..._small_devices

Quote:

---

Originally Posted by kraftman

"The total address space commit for the system is not permitted to exceed swap + a configurable percentage (default is 50) of physical RAM." It does mean it won't exceed your physical memory (RAM + swap), so it won't overcommit. It simply can't exceed the free memory and not exceed RAM + swap same time. When you have 2GB of RAM and only 1GB is free then it can't allocate more than 1GB, because it will overcommit.

---

Is it possible to overcommit physical memory (RAM + swap) without overcommiting free memory (RAM + swap)?

Quote:

---

Originally Posted by kraftman

I think it's better to be mostly rather than full POSIX compliant. If you are mostly compliant you overcommit POSIX limits. ;) Full POSIX compliant are some of the legacy systems.

---

If you are fully POSIX compliant, you can also "overcommit" POSIX limit. POSIX doesn't prohibits non-POSIX functions.

Quote:

---

Originally Posted by kraftman

Take a look here:

http://www.etalabs.net/compare_libcs.html

and here:

http://en.wikipedia.org/wiki/GNU_C_L..._small_devices

---

I was talking about glibc (because it is being used by most of distributions). I know there are alternatives.

Quote:

---

Originally Posted by LightBit

Is it possible to overcommit physical memory (RAM + swap) without overcommiting free memory (RAM + swap)?

---

This seems to be possible in modes 0 and 1, but you have to define exactly what you understand by this.

Quote:

---

If you are fully POSIX compliant, you can also "overcommit" POSIX limit. POSIX doesn't prohibits non-POSIX functions.

---

It doesn't matter, because you can be smarter than POSIX and rather trying to be fully POSIX compliant you can do some things better on your own.

Quote:

---

Originally Posted by LightBit

I was talking about glibc (because it is being used by most of distributions). I know there are alternatives.

---

Debian and Ubuntu probably use eglibc which seems to be much less bloated.

Quote:

---

Originally Posted by kraftman

Debian and Ubuntu probably use eglibc which seems to be much less bloated.

---

Size of library is the same. So it just seems.

Quote:

---

Originally Posted by kraftman

This seems to be possible in modes 0 and 1, but you have to define exactly what you understand by this.

---

I mean It's not logical, but forget about it.

Quote:

---

Originally Posted by kraftman

It doesn't matter, because you can be smarter than POSIX and rather trying to be fully POSIX compliant you can do some things better on your own.

---

This is what Microsoft did.
If everyone would speak it's own language, so they wouldn't understand each other, they would be smarter?