The current state of NetBSD

[jkl]

I found the DragonFly Digest to be a great source for NetBSD news:

https://www.dragonflydigest.com/category/bsd

[ibara]

Originally Posted by Oko

While I concur that some of your logic here is correct it also contains some logical flows.

Fallacies: logical flow is something else, having to do with organizational construction.

Originally Posted by Oko

First one is that I am not aware that NetBSD project is for developers only unlike OpenBSD which publicly states that as one of its principals.

So there is a couple of things going on here. First is an understanding of Free Software as a commons and the effects of that on democracy within individual communities and the commons more broadly. I actually do work in this area; while I won't flood the forums with a laundry list of social science readings, suffice it to say these things are much more difficult to understand and complex than would seem likely by those who don't study the matter. So this is a question of governance: it turns out that even when projects claim to be community led, what community? Who is in it? What defines it? How does one move into out out of it? And to complicate matters further, different scholars have slightly different definitions which leads to different answers to all those questions (and more).
What we really see is conflicting modes of governance, and none of those modes actually account for the public at large. In my opinion they need not be accounted for. So OpenBSD stating that up front is rather redundant: you either make the position clear or you engage in cognitive dissonance. And either is fine. We certainly don't expect our software developers to also have Ph.D. level understanding of sociology, anthropology, and STS literatures. Nor should we.

The second thing addresses Julio's post which you've succinctly summarized:

Originally Posted by Oko

Apart of the semantics the fact that Amiga developer might not be compelled to do any work after her/his favorite port is officially dropped that might also translate into 10 more capable ARM or AMD developers who are now sitting on the sidelines due to constrains imposed on the project by supporting hardware with serious technical limitations like Amiga or Atari.

I'm sorry but I just don't buy this argument. These things aren't so well explained monocausally. If that is really a blocker then there are most certainly other factors at play here. I'm not a NetBSD developer (though I know many high-up NetBSD people because they're either friends of mine or friends of friends) so it would only be speculation as to what those things are so I won't speculate.

Originally Posted by Oko

This might be very well how many core NetBSD developers think. If that is the case NetBSD should be pronounced Archaeological OS. As such it might be very interesting to me when I want to fire my old Atari 1000 but has no relevance for my day job.

Something not being relevant to you does not an "archaeological OS" make. Being able to surf the web with Firefox and play games on Steam does not a "modern OS" make. See the distinction?
You clearly do not know the extent to which NetBSD is used. You'd be shocked.

Originally Posted by Oko

This argument is frequently invoked by OpenBSD developers when somebody is trying to argue against some legacy ports (most recently Sparc). The major fallacy of your argument in my point of view is that unlike OpenBSD, NetBSD folks are actually doing very little native builds.

I said they would do better if they did native builds but that is their choice to make. It doesn't disqualify bugs from being found though. Just not as many. And maybe not the most severe ones.

Originally Posted by Oko

As a member of inner OpenBSD circle you know all too well that no platform can be adapted as official platform until at least two physical machines of that type are not available to developers one of which has to be located in the famous Theo's rack.

I have no idea from where you obtained this information. It's straight up wrong.

Originally Posted by Oko

Are there any images of NetBSD rack that I am not familiar with with machines in all 56 or so different architectures NetBSD is officially supporting?

No. Your point?

Originally Posted by Oko

For some of those architectures actual physical machines have never been built IIRC.

Again, and?

Originally Posted by Oko

Even with current fairly reasonable policies we saw two recent forks of OpenBSD (defunct AreieBSD and Bitrig).

Aerie is not new nor is it defunct. And you don't understand why either happened.

Originally Posted by Oko

No it is not. I use ZFS to make living and if I can't get it from NetBSD I will get it from somewhere else. Again you are using your OpenBSD mantra "OS by developers for developers and everyone else is just for good ride". NetBSD is officially not like that and some people would argue that was the main point of contention between Theo and the rest of core when he forked OpenBSD.

No no. You totally misunderstand. If the NetBSD project decides it wants to have an in-progress (or stalled, or dead) port of ZFS in their tree then it is a sad day for you and they will have it. See the point about governance earlier in this post.

Originally Posted by Oko

I see no reason for vocabulary of threats. I am not afraid of you or anybody else for that matter. I have been supporting OpenBSD financially for a while like many people who frequent this forum arguably with small but reoccurring donations. It is a tool that I use at work. It is a tool that I like using, but it is a tool, no more no less. I would be happy to support NetBSD and I started this thread being a UNIX lover. At this point I personally see no peace of NetBSD worth of my support. What I am afraid is that my opinion is not isolated.

It was an imploration to not respond without thinking.
Though you do disqualify yourself from relevancy with your penultimate sentence.

[pawaan]

I found the DragonFly Digest to be a great source for NetBSD news:

Ya true
another useful link:
http://freshbsd.org/search?project=netbsd

[fn8t]

Maybe it doesn't clear up much contention, but there are likely some agreements to be had. Obviously no BSD is addressing every type of advanced user. OpenBSD not doing it the way Net and Free are, is a good thing. This is not to say that anyone doing it wrong. If one could somehow do everything right for everyone, forks would not have very much relevance.

There may be an issue holding on to outdated or obscure architectures, when trying to implement relevant needs for an important audience. Those interested in these developments should move to the project(s) building towards their personal interest(s).

NetBSD may be limited or slowed in development by retention of legacy support. This is a clear and successful reason for the existence of OpenBSD (not even close to the only one). But, just because legacy support retards modern development, doesn't mean that the system doesn't run on modern machines with usability. This appliance of the system just isn't going to serve the needs of some users sufficiently. Again, this is why systems that can exploit platform specific capacities "rock you dirty socks off".

I can clearly see the frustrations developers might face if they work hard on one system to attain certain standards, while another platform in the same family neglects the same perfections. Its like having 3 members of a 4 member family enriched with a college education, while one member prefers to perform rock songs at a club in Amsterdam. When members of society hear of the left handed path loner, it reflect on the dignity of the entire family. If this same loner actually gets his/her stuff together and builds a major musical production company out of his/her specific interests, the rest of the family will likely still not recognize the success as relevant.

Maybe it could be agreed that NetBSD might clearly state its capacities and limitations with better distinction, thus expounding on the way(s) it is and is not like the other BSDs. This could clarify why you might expect a different experience between it and others. I suspect the concept of a "Research O.S." might do that well, if specified was the inclusion and exclusion of certain attributes to retain that title for its intended path. I admit that this doesn't forgive any lack of internal management's integration, but I really don't know the behind the scene of any BSD system to declare the internal structure of any of them.

Regarding two of the clearly differing opinions, I have a little to say. While I cannot deny that one or both of them may have some incorrect information, it is more likely that for the greater part the opinions are only restricted by the line of sight originating from their respectful sources. While not a perfect metaphor, I use cube hexahedron as a sufficient example. Depending on view ,as ascending or descending, it will appear as though it is fixed extending in either the left or right direction. It does become rather quite difficult to reconcile the different views with out losing the applied view. You'd have to release the view of the object as having three dimensions, for the simpler 2 dimension alternative. Then the incompatibilities of view just disappear.

[shep]

Complaint: NetBSD should drop smaller platforms/"cruft".

I think the issue is that their code base is so large that they lack the manpower to move it along.

Here are the time stamps from the amiga port. The most recent one is 4 months old and some are years old. Many of the commits are broadly applied device drivers that were not specific to amiga.

Contrast this with the commits for the libressl project.

An apt analogy is the passenger who is late for an airplane flight. The airline cannot afford to wait.

[darktrym]

Do you really want to compare the activity of NetBSD's Amiga platform with libressl?
LibreSSL activities are the result of bad code quality and ugly architecture of OpenSSL. After stripping much code, the team enables support of some platforms and adds now the removed features.

[fn8t]

Originally Posted by shep

I think the issue is that their code base is so large that they lack the manpower to move it along.

Here are the time stamps from the amiga port. The most recent one is 4 months old and some are years old. Many of the commits are broadly applied device drivers that were not specific to amiga.

Contrast this with the commits for the libressl project.

An apt analogy is the passenger who is late for an airplane flight. The airline cannot afford to wait.

Seems like they intend to take the old dirt road, until they can get to the airport on time without sacrificing any luggage.

[ibara]

Originally Posted by shep

I think the issue is that their code base is so large that they lack the manpower to move it along.

The important points continue to be missed. Minus a couple of good comments by Oko the replies to my posts have generally tried to make the smallest things the largest instead of engaging with the broad and important themes. fn8t has been pretty good too, though responding to those points really deserves a new thread.

Originally Posted by shep

Here are the time stamps from the amiga port. The most recent one is 4 months old and some are years old. Many of the commits are broadly applied device drivers that were not specific to amiga.

Here is a nearly 11 year old file in OpenBSD/amd64. Must be a dead arch according to you.

Originally Posted by shep

An apt analogy is the passenger who is late for an airplane flight. The airline cannot afford to wait.

That's a terrible analogy. I leave it as an exercise to the reader to understand why (replies to you have already explicated why it's terrible).

[shep]

Here is a nearly 11 year old file in OpenBSD/amd64. Must be a dead arch according to you.

Somehow I do not see this. You link to one file out of thousands. I linked to a time stamp summary of several hundred amiga port files that shows the most recent to be 4 months old. Looking at the 4 month old commit, it is a device driver that was broadly applied to multiple architectures.

Do you really want to compare the activity of NetBSD's Amiga platform with libressl?
LibreSSL activities are the result of bad code quality and ugly architecture of OpenSSL. After stripping much code, the team enables support of some platforms and adds now the removed features.

Both are coding projects whose development relies on the time and effort of volunteers. If we are talking about the viability of the NetBSD amiga port, I would suggest that the frequency of the commits are an indicator. Someone invested time and effort to strip the code, rewrite the functionality and add it back. An even stronger indicator is whether someone tests the code to see that it not only compiles, but runs as intended.

I periodically try NetBSD on mainstream i386/x86_64 hardware. Although I enjoy nearly 100% success with OpenBSD/FreeBSD/Debian/Slackware, the odds that NetBSD will boot after install are about 80%. When I install mainstream binaries from pkgsrc, the chances that something like a Desktop or LibreOffice will run are about 50%. In part due to the lack of testing, large amounts of code that compiles but does not run exists within the project. What are the odds that NetBSD 6.15 will run on Oko's Amiga 1000?

Like Oko, I do not wish to see NetBSD wither away. But if I ever get a 64 bit arm board, NetBSD will not be the first OS I try to run on it.

[fn8t]

Amiga requirements:

NetBSD/amiga is the port of NetBSD to the Amiga line of personal computers by Commodore and Amiga International and to the DraCo by MacroSystem GmbH.

Development activity on NetBSD/amiga continues at a speed dependent on people's spare time. Currently, NetBSD/amiga runs on any Amiga [1] that has a Motorola 68020 or better CPU with some form of MMU, and on 68060 DraCos. For 68020 and 68030 systems, a FPU is recommended but not required. 68LC040, 68040V and 68LC060 systems don't work correctly at the moment.

Due to the MMU requirement, it will not run on A500, A600, A1000, A1200, A2000, A4000/EC030, CDTV or CD32 out of the box. You must install a CPU board on them to run NetBSD.

The minimum RAM requirement is about 24 MB FASTMEM, the minimum hard disk space needed is about 250 MB, depending on how much system components you install. Check the install document for more details.

It does suck that you've had failures on mainstream devices. What kind were they?

[muflon]

Originally Posted by shep

But if I ever get a 64 bit arm board, NetBSD will not be the first OS I try to run on it.

On HP xw6200 with dual Xeon's Noctuna 3 Ghz + 2GB RAM; Ubench test on OpenBSD amd64 5.5 / 5.6 shows poor performance on memory bandwidth, compared to NetBSD amd64 6.1.5, OpenBSD is slow.

The same on Dell PowerEdge750 but with 32 bit architecture.

Edit: I'm sorry shep. I missed the 'arm board'...

[ibara]

Originally Posted by shep

Somehow I do not see this. You link to one file out of thousands. I linked to a time stamp summary of several hundred amiga port files that shows the most recent to be 4 months old. Looking at the 4 month old commit, it is a device driver that was broadly applied to multiple architectures.

The point is maybe you should be looking elsewhere for the "signs of life" that you seem to care about so much. You're looking somewhere that will always give you the wrong impression every time.

Originally Posted by shep

Both are coding projects whose development relies on the time and effort of volunteers. If we are talking about the viability of the NetBSD amiga port, I would suggest that the frequency of the commits are an indicator.

A pretty terrible indicator. Because you'll get the wrong impression every time.

A decently better one would be to just read the mailing list. The amiga one is still happening. Hey, here's a link to an email from THIS YEAR about an amiga native building pkgsrc packages. Huh. I guess people still do native compiling on it. Wouldn't be surprised if the same group also did native builds of NetBSD.
Looks like pretty decent coverage to me.

Originally Posted by shep

What are the odds that NetBSD 6.15 will run on Oko's Amiga 1000?

Probably pretty good, seeing as there are people doing just that and look there's even an active official mailing list to go if he has problems.

Originally Posted by shep

Like Oko, I do not wish to see NetBSD wither away.

You have an odd way of showing it.

Originally Posted by shep

But if I ever get a 64 bit arm board, NetBSD will not be the first OS I try to run on it.

I know. Helping is difficult. Best to run off to some perceived safe place.

[fn8t]

Originally Posted by muflon

On HP xw6200 with dual Xeon's Noctuna 3 Ghz + 2GB RAM; Ubench test on OpenBSD amd64 5.5 / 5.6 shows poor performance on memory bandwidth, compared to NetBSD amd64 6.1.5, OpenBSD is slow.

The same on Dell PowerEdge750 but with 32 bit architecture.

Edit: I'm sorry shep. I missed the 'arm board'...

Yeah.... But, that might be just enough to stir the pot more anyway.

[Oko]

Originally Posted by fn8t

Amiga requirements:



It does suck that you've had failures on mainstream devices. What kind were they?

I am very familiar with Amiga 2000. It is an awesome machine which a friend of mine and I used to do video editing around late 1988 perhaps early1989. I remember attaching high end consumer Sony Betamax camcorder downloading videos of our friends and then adding speech bubbles to it. Not until DVDs and Blueray I saw anything close in terms of video quality. I think we also used for some audio mixing. Matt Dillan who is now DragonFlyBSD project leader became famous by writing C compiler for Amiga which we used on that machine. I mean it was fantastic real computer not a toy. After Atari 1000 and Amiga 2000 I directly switched to MicroVAX 3100 and Tru64 UNIX and never looked anything else. For the record took MPlayer and mancoder long time to get even close to the state we had with Amiga in late 80s. I have never run NetBSD though on them. IIRC OpenBSD also supported both arches for a while.

[shep]

A pretty terrible indicator. Because you'll get the wrong impression every time.

I believe you initially used this as an indicator of viability:

So I went and read the NetBSD CVS logs, clearly something none of you bothered to do, and there's real activity going on in the Amiga port. Go look for yourself: NetBSD/amiga. If people want to work on it, great! You don't get to control what other people voluntarily work on. Remember: the equation isn't "they work on amiga or they work on something else" it's "they work on amiga or they don't work."

I did look at the link and posted what I saw

Here are the time stamps from the amiga port. The most recent one is 4 months old and some are years old. Many of the commits are broadly applied device drivers that were not specific to amiga.

I also looked at this link:

A decently better one would be to just read the mailing list. The amiga one is still happening. Hey, here's a link to an email from THIS YEAR about an amiga native building pkgsrc packages. Huh. I guess people still do native compiling on it. Wouldn't be surprised if the same group also did native builds of NetBSD.
Looks like pretty decent coverage to me.

You have to put this in the context that pkgsrc 6.0_2014Q3 is current and that pkgsrc 6.0_2014Q1, in your link, was the last to have any builds (July 2014). 6.0_2014Q2 had NO amiga builds

You seriously need to look at the links you are giving to support your position. I will also reiterate: I do not want this to degenerate into a flame war. I believe that NetBSD has big problems.

[ibara]

Originally Posted by shep

I believe you initially used this as an indicator of viability:

You seem to be confused over relativity of activity. You tried to compare activity of NetBSD/amiga to LibreSSL. Sorry but that's simply unacceptable if you want people to not laugh at you. Absolute commits is useful for saying "is anyone looking here?" which is how I used it. Then you argued for relative commit activity, first about "look at how old the oldest and newest commits are" then compared to LibreSSL. Both are totally inappropriate.

Originally Posted by shep

You have to put this in the context that pkgsrc 6.0_2014Q3 is current and that pkgsrc 6.0_2014Q1, in your link, was the last to have any builds (July 2014). 6.0_2014Q2 had NO amiga builds

The only two platforms that have pkgsrc 6.0_2014Q3 builds are i386 and x86_64. Sparc has a 6.0_2014Q2 build. arm, m68k, sparc64, and vax have 6.0_2014Q1 builds. So is sparc less dead than sparc64, which is equally as dead than amiga? It looks like building packages aren't a priority for NetBSD other than i386 and x86_64. That's their decision.

Originally Posted by shep

You seriously need to look at the links you are giving to support your position. I will also reiterate: I do not want this to degenerate into a flame war. I believe that NetBSD has big problems.

I have. It seems your understanding is lacking. Or maybe you can stop whining and do something to help out. Or at least go whine to someone from NetBSD.

[fn8t]

Originally Posted by Oko

I am very familiar with Amiga 2000. It is an awesome machine which a friend of mine and I used to do video editing around late 1988 perhaps early1989. I remember attaching high end consumer Sony Betamax camcorder downloading videos of our friends and then adding speech bubbles to it. Not until DVDs and Blueray I saw anything close in terms of video quality. I think we also used for some audio mixing. Matt Dillan who is now DragonFlyBSD project leader became famous by writing C compiler for Amiga which we used on that machine. I mean it was fantastic real computer not a toy. After Atari 1000 and Amiga 2000 I directly switch to MicroVAX 3100 and Tru64 UNIX and never looked anything else. For the record took MPlayer and mancoder long time to get even close to the state we had with Amiga in late 80s. I have never run NetBSD though on them. IIRC OpenBSD also supported both arches for a while.

The Amiga carved out some pretty solid coders too. No toy solders.

[fn8t]

Seems like this thread has just been waiting to happen.

[shep]

You seem to be confused over relativity of activity. You tried to compare activity of NetBSD/amiga to LibreSSL. Sorry but that's simply unacceptable if you want people to not laugh at you. Absolute commits is useful for saying "is anyone looking here?" which is how I used it. Then you argued for relative commit activity, first about "look at how old the oldest and newest commits are" then compared to LibreSSL. Both are totally inappropriate.

I am not confused.

Commits are code that someone look at, thought about, revised and submitted for testing. As I write this LibreSSL has had 3,525 commits since its inception in April 2014. I would say that is an active project.

Stagnant code that is that is cycled through a build system is at best automated activity. Show me a commit to the NetBSD amiga port that is less than 5 months old.
No package builds in 5 months means either that no one tried or the builds failed and no one bothered submit patches. The existence of 6.15 base amiga iso just means the build system churned one out. It does not mean it runs and it certainly does not mean that the NetBSD/amiga port is an active project.

[Oko]

I really feel bad that to someone outside this forum it might seem that we singled out Amiga and Atari NetBSD port in this thread as an example of something that NetBSD is doing wrong. I have deep sentimental feelings about both platforms and NetBSD is only true UNIX which still runs on them. That is really cool. What is not cool is that I in a true UNIX shop have no use for a single NetBSD amd64 or even better ARM 64 machine. I do have one old legacy Debian host running Xen Dom0 which is crying to be replaced with a BSD machine.