|
Hello Maxime, Our company used and still occasionally uses an old commercial cross-compiler and an EDA package for Solaris Sparc 32-bit. The Sparc hardware was dying and we managed to use NetBSD 5.2 with COMPAT_SVR4 on QEMU to keep using the packages. At that time Solaris could not be started on QEMU and besides that, NetBSD has some convenient low-power mode (so the CPU does not run at 100%). We are happy with it and thankful to the NetBSD and QEMU communities.
So COMPAT_SVR4 is very useful to us but in your user case this may not mean much: Our company uses 32-bit Sparc Our company uses an old NetBSD version and have no intention to switch to a newer version I can imagine that other companies face the same problems. Some programs just have no open-source alternatives and if Solaris Sparc was chosen back in the time then you are out of luck now. I can not say whether COMPAT_SVR4 has bit-rotten, is a dirty hack or is a development burden. If so then I can imagine that it should be removed. After all, NetBSD is an operating system on its own right and should not jump through hoops to emulate another. And one can always use an older NetBSD version that did support COMPAT_SVR4 properly.
But I felt it necessary to say that the option is being used. Guus From: port-sparc64-owner%NetBSD.org@localhost <port-sparc64-owner%NetBSD.org@localhost> on behalf of Jerome Ibanes <jibanes%gmail.com@localhost>
Sent: Tuesday, September 5, 2017 3:29 PM To: Maxime Villard Cc: port-sparc64%netbsd.org@localhost Subject: Re: Someone using COMPAT_SVR4(_32) ? Maxime,
> If someone is interested in keeping these features, he or she has to show > up within a month starting from now (date of the proposal). The minimum > requirement that such a maintainer would have to reach is demonstrating, > via patches or commits, that work is being done on improving the security of > the features - fixing basic bugs, via audit for example - as well as their > reliability - being able to show the functioning of an SVR4 binary being > increased as a result of this work. > If no maintainer is forthcoming after a month, or the maintenance threshold > is not met within a month, the code may be removed. It is to be noted that > the code will still be in the source code repository, should people wish to > re-instate it in the future. If that should happen, the reasons for removing > the code in the first place will have been addressed. Thanks for the head's up. I am looking into it and will hopefully come up with a patch to address this; but my time is very limited, and I would respectfully like to ask you to extend this deadline. Jerome |