OpenBSD Seeing Initial Work Land On Enabling 64-bit POWER

[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.

[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]

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!

[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.

[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]

Sure, you can say "but 32-bit is old" and that is fine. Not everyone needs to be "efficient"

PS: If compilation efficiency is what you worry about, then include files are the absolutely worst approach in existence. You are reparsing and recompiling the same code again and again and again, for each file that includes your header. With something like the STL, that means that huge amounts of nontrivial code get recompiled every time a header is included because the language/build system combo is dumb in that regard and doesn't know how to handle interfaces and inter-module dependencies. This is one of the main reasons why compilation speed in C++ is so slow (and even in C, when requiring many large headers like in modern GUI toolkits, for example).

[JustinTurdeau]

start_ptr<T> in C++ is the equivalent of Rust's Rc<T>, not Rust references. Rc pointers are rarely used in Rust, among other reasons because in C++ you really need to use some form of smart pointers to make the code (a little) less likely to crash, in Rust it's not necessary.

Rust, Rust, Rust, bla bla bla.....

Why do you cringeworthy RustBots try to turn every thread into a Rust thread? Rust is a dying research language with no future.

[JustinTurdeau]

Overall typical Phoronix. Usual crowd of Linux die-hards bashing.

The fact it's just another open-source OS is meaningless for the bunch. Rather fueling the hate posts. Sad shit.

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

[jacob]

And if the memory pointed to by blah later gets stripped out from under you? Rust doesn't control that data. The environment does.

If a pointer gets stripped out from under you then you are no worse off than in C/C++. But if you know WHEN the pointer is going to become invalid, and sometimes you do (typically by invoking a certain operation that flushes buffers, etc), then you can ensure that your pointers are consumed or that they don't outlive the data and the compiler will take care of the rest.

Its like in C++ you could have some std::shared_ptr<T> to an OpenGL wrapped texture. If the whole of OpenGL gets shut down (ie the SDL Window context is deleted), then you have a valid reference count, but to garbage (deleted) data (a no longer valid GLuint texture ID).

shared_ptr<T> in C++ is the equivalent of Rust's Rc<T>, not Rust references. Rc pointers are rarely used in Rust, among other reasons because in C++ you really need to use some form of smart pointers to make the code (a little) less likely to crash, in Rust it's not necessary.

I could have used any "safe" language. Lua (or other) and Rust have the same issues that their safety is not guaranteed due to ultimately requiring "unsafe" parts further down the stack. Lua has a garbage collector making double deletes impossible, likewise Rust has Ref counting... but neither can deal with the fact that the underlying memory can still be wiped as an (often erronious) side effect. When you write system code (i.e an OS) rather than just application code; you *need* to take this into consideration.

You just proved what I suspected, that you know next to nothing about Rust. I won't comment on Lua because I've never written any code in it, but Rust's memory safety model has nothing to do with ref counting. Ref counting does exist in Rust (Rc<T>, see above), but it's rarely used and often frowned upon. What Rust actually relies on is static lifetime analysis. The type system is extended with "lifetime" annotations and each variable, function parameter, object, object field etc. has a lifetime, implicit or explicit, that states where it is created and where it is destroyed. Knowing that sometimes invalidates a pointer, for example, means that Rust can enforce (at compile time) that that pointer or any of its aliases can't be accessed afterwards.

Of course it does. It usually means a weaker standard library so users depend on i.e NPM to do the most simple of tasks. It is the reason why web development is seen as a chaotic mess. You could argue that C and C++ have small standard libraries but because dragging in a dependency to just split a line is not quite as easy, you see much less of that kind of "dependency based" behavior.

What I "feel" has actually done me well. It helps me simply refuse to take on contracts where I might have to deal with these kinds of developers. It also allows me to predict when projects are going to fail quicker than less experienced developers so that I can avoid them.

You are confusing modules and third-party packages. Modules simply mean encapsulation, interface definition and visibility rules. Just like classes in C++, except at a coarser scale. C's include files are a poor man's imitation of proper module support. Third party libraries like those managed by NPM, or Cargo in Rust, can be implemented using modules if the language supports them, but the relationship ends there. By the way package managers are great tools, whether they are used properly or wrongly is up to those who use them.

You miss my point (or I didn't explain it well). By "all in one" approach I mean that it doesn't load all into memory and build (the reason why forward declares are needed as an example). Rust loads much more of the binary into memory in order to be able to compile.

Your example is good though; 2 million lines of Rust doesn't compile on 32-bit (not enough memory). It does with the approach C takes however. I think this is summarized well here from Theo himself:

https://marc.info/?l=openbsd-misc&m=151233345723889&w=2

Sure, you can say "but 32-bit is old" and that is fine. Not everyone needs to be "efficient"

I didn't miss your point, I pointed out that it's bogus. Of course Rust doesn't load and compile 2 million lines at once just like you wouldn't have a single giant C source file of 2 million lines. C compiles one file at a time, Rust compiles one crate at a time, where a crate can be one or (usually) several files. A C project would be split into multiple files (with include headers) and compiled separately. The Rust project would be split into multiple crates and compiled separately - no include files needed here because it has module support.

[jacob]

Overall typical Phoronix. Usual crowd of Linux die-hards bashing.

The fact it's just another open-source OS is meaningless for the bunch. Rather fueling the hate posts. Sad shit.

Exactly. It's like LLVM/GCC or GNOME/KDE. It always amazes me that those people believe that the world would be better if we had one great free operating system instead of two.