Re:OpenBSD 7.3
by j_not_j on Monday April 10, 2023 @10:39AM
(#35512879)
Every six months for the last 24 or 25 years (the web pages came after the early releases so a bit of uncertainty there. Explore for yourself at https://cvsweb.openbsd.org/www/)
And even vi gets fixes these days (Fixed handling of escaped backslashes in vi(1) ex_range).
Nice. I ran into an nvi bug years ago... if ":set numbers" and ":set noleftright" and then loaded a file of more than several kilobytes it would go into a malloc loop and segfault. We tracked it down and submitted a patch (this was to FreeBSD) and was told patches to src/contrib were not accepted (nvi was still "owned" by sleepycat). Good to know that at a certain point, function can overtake form!
Re:OpenBSD 7.3
by ianai on Monday April 10, 2023 @10:38AM
(#35512870)
Is there much that absolutely can’t be ran on OpenBSD without dropping into code? With its history of sane security it might offer some useful applications now.
"Modern" .NET is not compatible with it (or as Microsoft would say, "OpenBSD is not compatible with .NET"), and there doesn't seem to be much interest in resolving that. For comparison, it is available from official repositories at least on Ubuntu, Fedora, RHEL, and Arch Linux, and I use it daily to build and host stuff for $DAYJOB.
Re:OpenBSD 7.3
by dvzk on Monday April 10, 2023 @03:32PM
(#35516373)
Yes, and this is tantamount to suggesting that Python developers should be satisfied with Python 2.0 (arguably 1.0 if you do F# development). Mono is effectively dead and abandoned, and it only exists now for historical reasons.
Re:OpenBSD 7.3
by daneel_w on Monday April 10, 2023 @03:54PM
(#35516645)
>"Yes, and this is tantamount to suggesting that Python developers should be satisfied with Python 2.0 (arguably 1.0 if you do F# development). Mono is effectively dead and abandoned, and it only exists now for historical reasons."
There's no suggestion being made here, directly or implied. I'm asking because I have no experience with .NET and am for the most part unfamiliar with both it and Mono, but my colleagues recently spent a fair bit of time to "de-dotNETify" a large chunk of our platform and move it towards running entirely on Mono, and I figured they knew what they were doing.
The "new .NET" (which used to be called .NET Core not long ago — the whole versioning scheme is a total fiasco on their part) is relatively cross-platform, but is not fully compatible with the old one (which is only available on Windows and hasn't been updated for many years). Your colleagues probably ported an old .NET project to Mono to move it off Windows. The usual thing these days is to port old projects to the "new .NET" instead, but it isn't always possible (because full compatibility between the two was a non-goal from the start).
Anyways, as dvzk has mentioned, Mono is a completely separate project and is not a replacement for current dotnet. Last time I checked, an experimental FreeBSD port was available, but MS doesn't seem to care very much about any of the BSDs.
Re:OpenBSD 7.3
by dvzk on Monday April 10, 2023 @04:59PM
(#35517345)
Sorry! I shouldn't have assumed that it was a retort. Mono's latest supported .NET framework (v4.8) is four years old, or even older if you include the general movement to .NET Core, and it only supports C# versions <= 9.0 (via Roslyn), also 2-3 years old.
msbuild, the toolchain still used by Mono, has also been widely replaced by dotnet (CLI).
It's still (decreasingly) common to use Mono for cross-platform development, especially for Unity, which hasn't yet transitioned to .NET >= 7.0.
Re:OpenBSD 7.3
by LeFantome on Tuesday April 11, 2023 @04:00AM
(#35522199)
That makes it sound like Mono has fallen behind. I would say it like this:
The original .NET platform is now called .NET Framework.
.NET Framework was ( and is ) only available for Windows. Mono is an Open Souce project to implement a cross-platform implementation of .NET Framework. In addition to MacOS, Windows, and Linux, Mono targets iOS, Android, and WASM.
Microsoft released a second .NET platform alongside Framework and called it .NET Core. Unlike Framework, Core is cross-platform, and targets Windows, Linux and MacOS.
After .NET Core 3.1, the “Core” was dropped from the name. There has been .NET 5, .NET 6, and now .NET 7 but these are all just newer versions of .NET Core.
.NET Framework is still supported but there has not been a real release in several years. Framework is stuck at version 4.x and, since .NET 5, there is really one version of .NET again ( the descendent of Core ).
As Mono implements, .NET Framework ( not core ), it still implements .NET 4.x, like the “real” .NET Framework does. Mono “only supports C# versions <= 9.0 (via Roslyn), also 2-3 years old” because those are true of the “real” .NET Framework as well.
.NET Core ( dotnet at the CLI ) has replaced .NET Framework and ( by implication ) has replaced Mono as well. That is what I think the post above is trying to say.
Except, while it is true that the “real” .NET Framework has been replaced by .NET 5+ ( by .NET Core ), Mono has not been fully replaced.
Above, I said that .NET Core targeted Windows, MacOS, and Linux. It did not target iOS, Android, or WASM ( Blazor ). Well, .NET 7 targets all those platforms. How? Well, for Windows, MacOS and Linux it uses the original .NET Core runtime. For iOS, Android, and WASM it uses the runtime for Mono!
So, Mono is alive and well inside every version of .NET since 5. It will still be there in .NET 8 as well.
That said, when people say Mono, they mean the implementation of Framework released by the Mono Project. That version, as the post above implies, is pretty dated at this point.
Re:OpenBSD 7.3
by dvzk on Tuesday April 11, 2023 @05:41PM
(#35531986)
> .NET Core ( dotnet at the CLI ) has replaced .NET Framework and ( by implication ) has replaced Mono as well. That is what I think the post above is trying to say.
dotnet build (from the modern .NET CLI) can compile .NET SDK projects that target legacy Framework versions. A csproj with a .NET.Sdk reference can use a TargetFramework of net48 or lower.
dotnet build times are an order of magnitude faster than Mono’s msbuild command, and migrated projects also receive the recent dotnet toolchain improvements (like automatic nuget restore, among many others).
Unity projects sometimes use dotnet's csc, even when the compiled libraries are executed with the Mono .NET (Framework!) 4.x runtime.
Re:OpenBSD 7.3
by dvzk on Tuesday April 11, 2023 @05:56PM
(#35532139)
> So, Mono is alive and well inside every version of .NET since 5.
The official mono project is no longer under active development since the acquisition of Xamarin and the reassignment of core Mono team members to .NET Core.
Microsoft’s zombification of Mono by lifting code into .NET doesn’t suddenly make it alive. We’re not going to someday get a .NET 8 reimplementation inside Mono.
Re:OpenBSD 7.3
by rollcat on Tuesday April 11, 2023 @10:14AM
(#35525472)
This is all for FreeBSD, the only thing it has in common with OpenBSD is the shared lineage, which diverged some 30 years ago. You can for all intents and purposes treat them as completely different operating systems (like FreeBSD and Linux).
Re:OpenBSD 7.3
by seanw444 on Monday April 10, 2023 @11:24AM
(#35513444)
There seems to be a fairly low memory limit on processes, so when I tried to run a Minecraft server on my OpenBSD system, it complained about not having enough memory to start. Turns out the value seems to be hardcoded and compiled into the kernel. So... I'm not really sure how to run high-memory processes at this point, without self-compiling it in its entirety, which I don't really feel like doing.
Re:OpenBSD 7.3
by daneel_w on Monday April 10, 2023 @02:57PM
(#35515972)
It's not pretty low, or objectively low, but it can be considered relatively low. The average amount of RAM in desktops and laptops is still <32 GiB. From this perspective it's a very high limit.
Re:OpenBSD 7.3
by nequo on Monday April 10, 2023 @07:15PM
(#35518574)
Parent was being sarcastic.
It kind of makes sense to expect 32 GB to fit every process on a desktop. But is that the main use case of OpenBSD? It would seem that the main use case would lean towards servers instead?
Re:OpenBSD 7.3
by tolciho on Monday April 10, 2023 @08:21PM
(#35519108)
Eight gigs was the least amount of memory I could buy this laptop with, and I'm using... 237M even with a few amfora and w3m running. Compiles will take more, but I stopped compiling horrible things like Firefox or Chromium years ago.
Most of the proprietary world, things like Mathematica and fast WiFi (they only support up through 802.11n, I believe), and the entirety of Steam. Things where for-profit companies make an effort to support Linux, but ignore smaller OS's. So it's a monastic experience compared to the modern Linux desktop.
(Monasteries are beautiful – still won't choose to live in one!)
Re:OpenBSD 7.3
by t-3 on Monday April 10, 2023 @12:34PM
(#35514182)
> (they only support up through 802.11n, I believe)
Some newer wifi (iwx at least) work at higher speeds, but I believe this is mostly due to hardware functionality being moved to firmware. 802.11ac should be supported, but I haven't followed closely enough to know how well and in what drivers.
Re:OpenBSD 7.3
by t-3 on Monday April 10, 2023 @03:34PM
(#35516398)
> hardware functionality being moved to firmware
Sorry for my lack of proofreading, this was not written correctly. Functions that were formerly handled in software drivers are now being handled in firmware by many wireless NICs.
Re:OpenBSD 7.3
by ksec on Monday April 10, 2023 @01:15PM
(#35514646)
If you do a search the number one problem or concern for running OpenBSD is performance. And I dont think much has changed. I dont doubt there are certain domain where you would value security over everything.
Re:OpenBSD 7.3
by kjs3 on Monday April 10, 2023 @03:03PM
(#35516045)
OpenBSD had pretty poor support for SMP for quite a while, but lots of work has gone into fixing that in the last decade. That plus how much smaller the OpenBSD footprint is than, say, Linux, and you might find these days it performs pretty well.
Is packet filtering still single threaded? I remember pf could only could only use a single core at a time which made filtering more than 1 Gb/s problematic.
Re:OpenBSD 7.3
by daneel_w on Monday April 10, 2023 @04:01PM
(#35516735)
It's threaded as of recently. Before that the performance obviously hinged on single-core performance. 1 Gbit/s sounds like lower tier laptop spec to me. My 2015 low-power Celeron test rig could do ~700 Mbit/sec through a medium complexity PF ruleset on OpenBSD versions where PF was still single-threaded.
Re:OpenBSD 7.3
by kjs3 on Monday April 10, 2023 @04:23PM
(#35516950)
I believe it is. I will, however, admit that while I use OBSD extensively for networking devices (routers, etc.), I haven't had much call for multigig networking on them. I will say that it will easily do 1G routing+PF+VLAN on rather modest hardware (J4105, dual i211 ports).
Re:OpenBSD 7.3
by mrweasel on Monday April 10, 2023 @10:39AM
(#35512875)
The POSIX standard defines ed as one of the editors that must be present for a system to be standard complaint, the other being vi I believe. You can always expect ed to be available to you on a Unix system.
It is true that all certified Unix systems follows POSIX, but it doesn't mean that non-certified systems are forbidden to follow it. Most Linux distributions have ways to turn to 98% compliant, and BSDs have always strive to follow POSIX.
Re:OpenBSD 7.3
by chungy on Tuesday April 11, 2023 @03:59AM
(#35522192)
Two of those programs predate POSIX and do not indicate that OpenBSD follows POSIX.
They are making their operating system to the design they like best. Some of it happens to coincide with what POSIX asks for, but it is merely coincidental.
Re:OpenBSD 7.3
by krylon on Tuesday April 11, 2023 @06:14AM
(#35523035)
I vaguely recall some interview with or blog post / talk by an OpenBSD developer, where they said that POSIX tended towards adopting whatever GNU/Linux did, and that the BSD crowd's interests were not taken into consideration that much.
I don't know much about the process behind POSIX/SUS, but I can understand how OpenBSD developers wouldn't be super enthusiastic about POSIX compliance if they felt their input was falling on deaf ears.
FWIW, I did use the SUS as my main reference when writing a few hobby projects, and OpenBSD gave me no problems whatsoever. macOS, on the other hand, which is a certified Unix, did not support barriers at the time (that was ~10 years ago, I have no idea if Apple added support since). (I know barriers are optional, but come on.)
Re:OpenBSD 7.3
by wahern on Monday April 10, 2023 @08:55PM
(#35519315)
There used to be a lot of bombastic rhetoric back-in-the-day, with many infamous examples coming from Linus and Theo. You can definitely find some flames resulting from a patch with the headline, "POSIX requires...". In practice, OpenBSD seems to have always and rather frequently made changes to better align with POSIX. The exceptions are when POSIX mandates a behavior that is considered wrong or worse than the OpenBSD behavior.
OpenBSD values removing needless impediments to portability, and for all the griping about POSIX, that's precisely its raison d'etre. The vast majority of POSIX conformance patches on all Unix-like systems generally go unnoticed and largely uncommented on. Over time even seemingly senseless POSIX conformance patches end up in OpenBSD simply because reducing variance is a win all by itself.
That said, POSIX conformance patches are likely to receive more attention if they come with other, more substantive features or bug fixes, especially if the POSIX-related diff imposes a backward compatibility cost. The nice things about OpenBSD is that they're not afraid to break compatibility, but they're judicious about it; too much breakage in single release cycle means it's more likely for unrecognized issues to arise.
musc libc is nominally much more "pro" POSIX than OpenBSD, but following the development mailing-lists, in practice they really seem to take similar approaches.
Re:OpenBSD 7.3
by krylon on Monday April 10, 2023 @06:01PM
(#35517926)
I wonder what benefit the certification has these days. IIUC, it used to be a requirement for contracts from large corporations and government agencies, but these days the number of commercial Unix systems is fairly small, and RHEL is so common in those environments, I wonder if it there's still places where it's required.
Love the books by mwl. Have physical copies of several of them, and the whole bunch of the ebook versions. Currently reading one of the physical copies. The one about Ed I have in ebook format only and didn’t read it yet. Will get to that one after I finish reading the physical books that I have from him.
Re:OpenBSD 7.3
by nixcraft on Monday April 10, 2023 @10:54AM
(#35513063)
In the old days, Unix rescue boot floppy disk to fix workstations or servers only included minimal text editors such as ed (i think vi was added later). So if you were a Unix admin or power user, you need to know ed to fix the dam system. The 'ed' text editor was available everywhere. These days rescue disks boot from USB or CD/DVD-ROM and may have a full desktops or operating systems running. A little bit of history, I guess. BTW, I prefer https://www.system-rescue.org/ these days to fix Linux bare metals.
Re:OpenBSD 7.3
by anyfoo on Monday April 10, 2023 @04:42PM
(#35517157)
Though in most cases, you can just type “reset” to reset your terminal to a sane state. If the problem is not the terminal’s state, but how software is trying to talk to it, setting TERM=vt100 (with a “reset” for good measure afterwards) usually works for most if not all terminals nowadays.
Re:OpenBSD 7.3
by ninjin on Tuesday April 11, 2023 @04:37AM
(#35522452)
From what I understand, at least two OpenBSD developers have their hands on PinePhone Pro devices. Not sure about any progress, but at least it shows that there is interest from the developer base.
Re:OpenBSD 7.3
by jmclnx on Monday April 10, 2023 @01:23PM
(#35514753)
About to upgrade my amd64 system.
I already upgraded my very old i386 (R51e), no issues and very easy. I am getting some mystery core dumps, will look at that later. I suspect the new "Permissions (RWX, MAP_STACK, etc.) on address space regions". but only guessing :) On the i386 I am planning on using a new "old" disk since the old disk is getting tight. Then I will worry about the dumps after an install.
Re:OpenBSD 7.3
by alberth on Monday April 10, 2023 @01:40PM
(#35514970)
I've always found building/running your app code on OpenBSD (even if it's not your target OS) - makes for a better app overall because of how strict OpenBSD is - it forces your app to run "correctly" more than any other OS.
I've been able to find and fix way more app bugs, than when I ran my software on other OS'es
Re:OpenBSD 7.3
by darknavi on Monday April 10, 2023 @05:36PM
(#35517694)
Any specific examples? I don't daily drive Linux but that sounds interesting.
Somewhat related, for Minecraft (Bedrock, C++) we compile with a ton of different tool chains and I really appreciate Clang versus MSVC for how strict the compiler can be (even with /-permissive).
Re:OpenBSD 7.3
by ninjin on Tuesday April 11, 2023 @01:53AM
(#35521343)
Ted Unangst’s “Developing Software in a Hostile Environment” talk from EuroBSDcon 2019 is a good start. Controlling malloc(3) behaviour with malloc.conf to catch initialisation and Use After Free bugs is a great example from there.
Personally, a different userland and directory structure usually also beats out Linux-isms.
Re:OpenBSD 7.3
by pedrow on Tuesday April 11, 2023 @06:31AM
(#35523154)
I have an OpenBSD install in a VM for the reason cited by ninjin:
> Personally, a different userland and directory structure usually also beats out Linux-isms.
I just upgraded from 7.2 with sysupgrade then pkg_add -u and it worked perfectly without any intervention from me. In the past I remember it needing a bit of tweaking and finger-crossing. Bravo OpenBSD!
And even vi gets fixes these days (Fixed handling of escaped backslashes in vi(1) ex_range).
6.8 was released Oct 18, 2020. (OpenBSD's 25th anniversary)
https://www.openbsd.org/68.html
There's no suggestion being made here, directly or implied. I'm asking because I have no experience with .NET and am for the most part unfamiliar with both it and Mono, but my colleagues recently spent a fair bit of time to "de-dotNETify" a large chunk of our platform and move it towards running entirely on Mono, and I figured they knew what they were doing.
Anyways, as dvzk has mentioned, Mono is a completely separate project and is not a replacement for current dotnet. Last time I checked, an experimental FreeBSD port was available, but MS doesn't seem to care very much about any of the BSDs.
msbuild, the toolchain still used by Mono, has also been widely replaced by dotnet (CLI).
It's still (decreasingly) common to use Mono for cross-platform development, especially for Unity, which hasn't yet transitioned to .NET >= 7.0.
The original .NET platform is now called .NET Framework.
.NET Framework was ( and is ) only available for Windows. Mono is an Open Souce project to implement a cross-platform implementation of .NET Framework. In addition to MacOS, Windows, and Linux, Mono targets iOS, Android, and WASM.
Microsoft released a second .NET platform alongside Framework and called it .NET Core. Unlike Framework, Core is cross-platform, and targets Windows, Linux and MacOS.
After .NET Core 3.1, the “Core” was dropped from the name. There has been .NET 5, .NET 6, and now .NET 7 but these are all just newer versions of .NET Core.
.NET Framework is still supported but there has not been a real release in several years. Framework is stuck at version 4.x and, since .NET 5, there is really one version of .NET again ( the descendent of Core ).
As Mono implements, .NET Framework ( not core ), it still implements .NET 4.x, like the “real” .NET Framework does. Mono “only supports C# versions <= 9.0 (via Roslyn), also 2-3 years old” because those are true of the “real” .NET Framework as well.
.NET Core ( dotnet at the CLI ) has replaced .NET Framework and ( by implication ) has replaced Mono as well. That is what I think the post above is trying to say.
Except, while it is true that the “real” .NET Framework has been replaced by .NET 5+ ( by .NET Core ), Mono has not been fully replaced.
Above, I said that .NET Core targeted Windows, MacOS, and Linux. It did not target iOS, Android, or WASM ( Blazor ). Well, .NET 7 targets all those platforms. How? Well, for Windows, MacOS and Linux it uses the original .NET Core runtime. For iOS, Android, and WASM it uses the runtime for Mono!
So, Mono is alive and well inside every version of .NET since 5. It will still be there in .NET 8 as well.
That said, when people say Mono, they mean the implementation of Framework released by the Mono Project. That version, as the post above implies, is pretty dated at this point.
dotnet build (from the modern .NET CLI) can compile .NET SDK projects that target legacy Framework versions. A csproj with a .NET.Sdk reference can use a TargetFramework of net48 or lower.
dotnet build times are an order of magnitude faster than Mono’s msbuild command, and migrated projects also receive the recent dotnet toolchain improvements (like automatic nuget restore, among many others).
Unity projects sometimes use dotnet's csc, even when the compiled libraries are executed with the Mono .NET (Framework!) 4.x runtime.
The official mono project is no longer under active development since the acquisition of Xamarin and the reassignment of core Mono team members to .NET Core.
Microsoft’s zombification of Mono by lifting code into .NET doesn’t suddenly make it alive. We’re not going to someday get a .NET 8 reimplementation inside Mono.
https://github.com/dotnet/runtime/issues/14537 700 comments
https://github.com/dotnet/runtime/blob/main/docs/workflow/re...
https://github.com/dotnet/runtime/issues/71338
https://github.com/dotnet/runtime/blob/main/docs/workflow/bu...
Virtual machines for non-openbsd guests? That's the only thing blocking me to fully move to openbsd.
https://man.openbsd.org/release#2._Build_and_install_a_new_k...
It kind of makes sense to expect 32 GB to fit every process on a desktop. But is that the main use case of OpenBSD? It would seem that the main use case would lean towards servers instead?
(Monasteries are beautiful – still won't choose to live in one!)
Some newer wifi (iwx at least) work at higher speeds, but I believe this is mostly due to hardware functionality being moved to firmware. 802.11ac should be supported, but I haven't followed closely enough to know how well and in what drivers.
Sorry for my lack of proofreading, this was not written correctly. Functions that were formerly handled in software drivers are now being handled in firmware by many wireless NICs.
> Fixed ed(1) to print bytes read/written and the ? prompt to stdout, not stderr.
You can expect it to be there.
Most linux distros (and most BSDs afaik) are not unix certified.
MacOS is, for that matter.
It is true that all certified Unix systems follows POSIX, but it doesn't mean that non-certified systems are forbidden to follow it. Most Linux distributions have ways to turn to 98% compliant, and BSDs have always strive to follow POSIX.
Weird fact: POSIX was actually named by RMS.
They are making their operating system to the design they like best. Some of it happens to coincide with what POSIX asks for, but it is merely coincidental.
I don't know much about the process behind POSIX/SUS, but I can understand how OpenBSD developers wouldn't be super enthusiastic about POSIX compliance if they felt their input was falling on deaf ears.
FWIW, I did use the SUS as my main reference when writing a few hobby projects, and OpenBSD gave me no problems whatsoever. macOS, on the other hand, which is a certified Unix, did not support barriers at the time (that was ~10 years ago, I have no idea if Apple added support since). (I know barriers are optional, but come on.)
OpenBSD values removing needless impediments to portability, and for all the griping about POSIX, that's precisely its raison d'etre. The vast majority of POSIX conformance patches on all Unix-like systems generally go unnoticed and largely uncommented on. Over time even seemingly senseless POSIX conformance patches end up in OpenBSD simply because reducing variance is a win all by itself.
That said, POSIX conformance patches are likely to receive more attention if they come with other, more substantive features or bug fixes, especially if the POSIX-related diff imposes a backward compatibility cost. The nice things about OpenBSD is that they're not afraid to break compatibility, but they're judicious about it; too much breakage in single release cycle means it's more likely for unrecognized issues to arise.
musc libc is nominally much more "pro" POSIX than OpenBSD, but following the development mailing-lists, in practice they really seem to take similar approaches.
vi: https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/
setting TERM=vt100 (with a “reset” for good measure afterwards) usually works for most if not all terminals nowadays
Kids these days and their 'everything is a vt100'. Perhaps true nowadays, but certainly not always (looks at his HP700/96).
https://news.ycombinator.com/item?id=30019823
[1]: https://research.exoticsilicon.com/series/pinephone_openbsd
I already upgraded my very old i386 (R51e), no issues and very easy. I am getting some mystery core dumps, will look at that later. I suspect the new "Permissions (RWX, MAP_STACK, etc.) on address space regions". but only guessing :) On the i386 I am planning on using a new "old" disk since the old disk is getting tight. Then I will worry about the dumps after an install.
see OpenBSD
I remember looking for info on FreeBSD versions and wondering what the heck RELENG was.
[0] https://www.openbsd.org/papers/asiabsdcon2009-release_engine...
I've been able to find and fix way more app bugs, than when I ran my software on other OS'es
Somewhat related, for Minecraft (Bedrock, C++) we compile with a ton of different tool chains and I really appreciate Clang versus MSVC for how strict the compiler can be (even with /-permissive).
Personally, a different userland and directory structure usually also beats out Linux-isms.
> Personally, a different userland and directory structure usually also beats out Linux-isms.
I just upgraded from 7.2 with sysupgrade then pkg_add -u and it worked perfectly without any intervention from me. In the past I remember it needing a bit of tweaking and finger-crossing. Bravo OpenBSD!