Henry, I think you're going to be a whole lot happier with NetBSD or OpenBSD on 32-bit Sun SPARC hardware than trying to coax SunOS into a usable state for the modern, unfortunately rather hostile, Internet. However, I think you're also going to want to make use of the cross-compilation tools provided, i.e., build software on [ugh] fast x86 or ARM hardware rather than wait for the old SPARCs to grind through it. I hope you have cheap electic power service where you are - old Suns run warm and use a lot more electricity per cycle than modern processors. The other way: emulation on modern power-efficient hardware, e.g., with qemu. Erik

On Wed, 13 Mar 2024 at 16:49, Kevin Bowling <kevin.bowling(a)kev009.com> wrote: Thank you, I just subscribed to sun-rescue. I have greybeard syndrome about Discord - I just don't trust that it's going to be a useful resource. -Henry

On Wed, 13 Mar 2024 at 17:27, Will Senn <will.senn(a)gmail.com> wrote: Thanks Will! You may also be interested in https://john-millikin.com/running-sunos-4-in-qemu-sparc as another resource about running SunOS 4 in QEMU. I have considered moving my setup to QEMU, especially as it would be very easy to create a hard drive image since I am using a SCSI2SD board, but there is something about running these things on the original hardware that is difficult to leave behind. -Henry

On Wed, Mar 13, 2024, 19:29 Alexis <flexibeast(a)gmail.com> wrote: Perhaps I should elaborate. The communities I came of age with were Usenet and mailing lists. While not perfect, they were the (almost) universally recognized central repositories of group knowledge, especially if you did not want to pay for support from a manufacturer. Now, I find that there is a fragmentation happening. There are those of us who still cling to mailing lists - like this one! - and those who are willing to navigate the realms of increasingly compartmentalized other forms of community, Discord included. The fact that there is not a recognized central repository of unpaid support for a product, like sun-managers, I find to be frustrating. -Henry

Henry Bent <henry.r.bent(a)gmail.com> writes: i basically agree. i won't dwell on this too much further because i recognise that i'm going off-topic, list-wise, but: i think part of the problem is related to different people having different preferences around the interfaces they want/need for discussions. What's happened is that - for reasons i feel are typically due to a lock-in-oriented business model - many discussion systems don't provide different interfaces/'views' to the same underlying discussions. Which results in one community on platform X, another community on platform Y, another community on platform Z .... Whereas, for example, the 'Rocksolid Light' BBS/forum software provides a Web-based interface to an underlying NNTP-based system, such that people can use their NNTP clients to engage in forum discussions. i wish this sort of approach was more common. Alexis.

On Thu, Mar 14, 2024 at 11:44:45AM +1100, Alexis wrote: This is a bit off-topic, and so if we need to push this to a different list (I'm not sure COFF is much better?), let's do so --- but this is a conversation which is super-improtant to have. If not just for Unix heritage, but for the heritage of other collecvtive systems-related projects, whether they be open source or proprietary. A few weeks ago, there were people who showed up on the git mailing list requesting that discussion of the git system move from the mailing list to using a "forge" web-based system, such as github or gitlab. Their reason was that there were tons of people who think e-mail is so 1970's, and that if we wanted to be more welcoming to the up-and-coming programmers, we should meet them were they were at. The obvious observations of how github was proprietary, and locking up our history there might be contra-indicated was made, and the problem with gitlab is that it doesn't have a good e-mail gateway, and while we might be disenfranchising the young'uns by not using some new-fangled web interface, disenfranchising the existing base of expertise was even worse idea. The best that we have today is lore.kernel.org, which is used by both the Linux Kernel and the git development communities. It uses public-inbox to archive the mailing list traffic, and it can be accessed via threaded e-mail interface, as well as via NNTP. There are also tools for subscribing to messages that match a filtering criteria, as well as tools for extracting patches plus code review sign-offs into a form that can be easily consumed by git. Of course none of this is a substitute for hiring a technical writer working with keye developers to create architecture documentation so that when a key developer retires (or gets hit by a bus) that critical knowledge doesn't get lost. This requires real investment, and while some communities might have a large corporate-funded foundation who might be able to fund that sort of thing, one of the things we've found is that there are real limits to the sort of documentation work that can be done by volunteers. (For example, right now the Linux kernel documentation maintainer is also the owner and editor for the Linux Weekly News, and Jon is keenly aware of the limits of what he can do in his copious spare time. And none of us is getting any younger....) So it's a real problem, and I think it's one that needs a lot more conversation, both within various open source projects, and perhaps between different projects to exchange some techniques for better preserving lore. After all, it would be great if we could make things easier for the next generation's *-Heritage-Society. :-) - Ted