OpenBSD Seeing Initial Work Land On Enabling 64-bit POWER

[kpedersen]

PS: If compilation efficiency is what you worry about, then include files are the absolutely worst approach in existence.

And yet the Rust approach, cannot work on i386 because it needs too much memory. Surely that is the worst approach in existence because all the other ones at least work?

What Rust actually relies on is static lifetime analysis..

A static lifetime analysis cannot be performed on memory that is going to be obtained at runtime and destroyed externally to Rust. This is not the appropriate solution for safety here, that is why I used the ref count example.

Try it now. Try to use this approach to wrap an OpenGL concept using a GLuint (lets say a render buffer attached to a frame buffer object) and you will see what I mean.
Hint: You cannot. Read through some ratty crate containing (probably an out of date) GL binding and you will see so much "unsafe" sections that you might even realize Rust is providing a false sense of security when it comes to system programming.

[jacob]

And yet the Rust approach, cannot work on i386 because it needs too much memory. Surely that is the worst approach in existence because all the other ones at least work?

Of course the Rust approach works on i386 and other 32 bit architectures (ARMv7). Firefox specifically can't be built on a 32 bit OS due to OOM but that occurs during linking, it is not due to the alleged and silly idea of compiling 2 million lines in one shot. The linking is obviously massive and includes C++ code as well. If all the Rust parts were rewritten in C++ (or rolled back to the original C++ code) it wouldn't change a thing. By the way the situation is more or less the same for other massive projects including LibreOffice which doesn't use Rust.

A static lifetime analysis cannot be performed on memory that is going to be obtained at runtime and destroyed externally to Rust. This is not the appropriate solution for safety here, that is why I used the ref count example.

What do you mean by "externally to Rust"? If you mean that a certain call destroys a buffer and so invalidates pointers, the Rust lifetime analysis handles precisely that perfectly well (unlike ref counting actually, which is even less suitable in a situation like this, and unlike C or C++ which have no way of knowing whether a live pointer is valid or not). If that destruction happens in foreign code called through a binding, all the binding has to do is to declare the relevant method as consuming "self".

If you mean destroyed asynchronously and unpredictably, regardless of whether it is being referenced, then writing code on such a hardware is by definition impossible in any language in the world.

Try it now. Try to use this approach to wrap an OpenGL concept using a GLuint (lets say a render buffer attached to a frame buffer object) and you will see what I mean.
Hint: You cannot. Read through some ratty crate containing (probably an out of date) GL binding and you will see so much "unsafe" sections that you might even realize Rust is providing a false sense of security when it comes to system programming.

You mean like this? https://crates.io/crates/vulkano

The case you keep repeating is simply not a problem, the notion of consuming an object in a way that renders it inaccessible is basic Rust 101. In this Vulkan binding library no unsafe sections are needed when developing an application. The library itself contains unsafe code of course, because it's unavoidable when calling into C.

You are perfectly free not to like Rust and there are as many perfectly valid reasons to choose it as there are to choose C/C++ instead, depending on the project. But this is utter bollocks.

[JustinTurdeau]

You are perfectly free not to like Rust and there are as many perfectly valid reasons to choose it as there are to choose C/C++ instead, depending on the project. But this is utter bollocks.

Rust has no ABI stability and probably never will. That rules it out as an option in many scenarios. It's also been shown time and time again that the kind of people responsible for most careless bugs in C code will simply use unsafe {} to do the exact same things in Rust. You can't fix stupidity unless you make it impossible.

As always, it comes down to the programmer. C works fine with expert programmers. Rust is irrelevant.

Next!

[aht0]

Which posts are you even referring to? Or did you just feel like having a random spergout...?

Go to "BSD, Mac OS X, Hurd & Others" subforum. Open BSD-related topics - and read. Over time you will notice certain patterns emerging.

Recent examples:
https://www.phoronix.com/forums/forum/software/bsd-mac-os-x-hurd-others/1171898-freebsd-is-off-to-a-solid-start-for-2020

"The FreeBSD Foundation raised $57k USD over this last quarter."
What a WASTE of money! These money could have help in some Linux development, rather than BSDEAD.
...
A BSDEAD fanboi lad crying in agony ~2020, noncolorized
...
Typical FreeBSD reaction. Linux, NetBSD, OpenBSD etc. are operating systems. FreeBSD is a paranoid cult.

https://www.phoronix.com/forums/forum/software/bsd-mac-os-x-hurd-others/1168304-it-s-official-but-sad-trueos-is-over-as-once-the-best-desktop-bsd-os

Lol, finally. It was nonsense to develop a dead-OS distro. BSD is dead as all the eyes are kept on Linux for years, and you can't make it better (at least until you have a big amount of money).
...
As a matter of fact BSD code is utter crap and legacy mess. They didn't even have good file system before they got ZFS (which is far from perfect) from slowlaris. They didn't even have proper locking and SMP support for long long time. Linux had SMP in 1996 while FreeBSD got it in 2000. Number of developers does indeed result in quality of code. There's so many unfixed problems in BSD, because of lack of developers. It's not even comparable.
...
I am amazed in how many people just vomits hate to freeBSD jut out of spite. How many of those have even tried it?

Even if you don't like it, why hate it? See: My neighbour has a neon pink car and I don't wish her house to burn down because of that. I just make sure not to let her choose my house' s wallpaper. Easy enough considering we don' t even talk to each other.

https://www.phoronix.com/forums/forum/software/bsd-mac-os-x-hurd-others/1178668-wireguard-ported-to-the-openbsd-kernel-looking-for-upstream-inclusion

now poor openbsd people will be less insecure

This kind of hate posting has been going on for years, once I dug in and through Google querys (Phoronix limits your ability to look at older forum topics direct) I concluded that this kind of behaviour has been going for over a decade.
Certain particular individuals are authors for such posts, some more rabid than others. Childish e-penis measuring is pretty constant (WE have so many users, you have only so many etc), then accusations and/or sneering over license, listings of superiority/inferiority of hardware support or designs..whatever.

[JustinTurdeau]

Go to "BSD, Mac OS X, Hurd & Others" subforum. Open BSD-related topics - and read. Over time you will notice certain patterns emerging.

Recent examples:
...

If you have to tell someone to go read specific subforums and only "over time" will they see any kind of pattern, it's probably not really a pattern. More like 3-4 posters who genuinely hold those opinions for whatever reason.

You're just mistaking your own searing butthurt about this particular topic as "a pattern" because you're so focused on it.