Re: Removing ARCNET stuffs
On 5/29/15 5:22 AM, David Holland wrote: > Because of these trends, I've been thinking for a while now that maybe > it's getting to be time to fork. Hello, David! I started using NetBSD because of its small base system disk and memory footprint, focus on security, support for many machine architectures, ability to scale well to large SMP machines, support for a wide range of deployments from embedded to server to desktop (it's a big time savings to only have to learn and remember how to do something on one OS instead of many), and genteel user and developer community. I value all of these things. (Some benefits I came to appreciate later were its relatively long support for a release and its package management system, pkgsrc (writing a package once and having it work on all platforms I use is a big win).) Personally, I don't have an interest in running NetBSD on vintage hardware. However, I understand and respect that some people do, and I have nothing against that. I would very much so hope for NetBSD to *not* fork! I agree with Taylor Campbell: "I suspect if people have the time and energy to make and maintain a fork, they certainly have the time to write automatic tests for the old network protocols." [1] In "Evolving Frameworks," [2] Don Roberts and Ralph Johnson suggest in the "Tree Examples" pattern that you should never write a software framework unless you have at least three applications that use it. Part of the reasoning is that these applications help you come up with the proper abstractions for the framework. If you think of NetBSD as a framework and the machine architectures and hardware as applications, then perhaps all of those "applications" can actually be a benefit to NetBSD and help it to have really nice abstractions and design. Of course, bit rot is bad, and I can certainly understand those who would like to remove things that aren't used. It's more work to maintain those things, and, in some cases, it offers a bigger attack surface to attackers. I understand the argument that something can always be restored from the attic if someone wants it, but the downside of that is that, while NetBSD advances, deleted things remain as they were when deleted and thus become more difficult to bring back over time. But if you have automatic tests as Taylor Campbell suggested, those things could potentially stay in the tree, and changes can be made to them with some level of confidence because the automatic tests still pass. Regards, Lewis [1] http://mail-index.netbsd.org/tech-kern/2015/05/29/msg018796.html [2] http://st-www.cs.illinois.edu/users/droberts/evolve.html
Re: Removing ARCNET stuffs
On 28 May, 2015, at 17:57 , Tyler Retzlaff wrote: > On 5/28/2015 12:39 PM, Robert Swindells wrote: >> Radoslaw Kujawa wrote: >> >> The same arguments might be made against the plan to remove ATM >> support. > > I've got no problem with keeping it, removing it isn't really intellectually > rewarding I thought it more of a cleanup/chore that nobody really wanted to > do. I only suggested removal because I know the code is broken. > > I guess we could at least make it compile again if we kept it and add it to > the ALL kernels. Is that enough? It's likely to still be broken and > difficult to efficiently fix without any hardware though. A long time ago I wrote code to support ATM interfaces for routers that had the hardware. I'm pretty sure they sold quite a few of those interfaces and were still selling them not that long ago; ADSL uses ATM framing and some carriers had ATM networks for backhaul until they could no longer afford to pay the switch vendors to maintain them. I think you would say those routers supported ATM, and I don't recall any complaints about that support being incomplete in some way, yet that code did nothing similar to the stuff in sys/netnatm. I know of no application which requires that and it clearly isn't necessary to do something useful with ATM interfaces that people were willing to spend (not inconsiderable) money for without it. I would be much more impressed if someone stepped up, said they knew what that code did and described what they would use it for if the code actually worked. As it is I believe that code not only doesn't work but would have no utility if it did and probably wasn't a good idea even when it was first included in the kernel and you could still buy the hardware. If someone had ATM hardware they wanted to support they still wouldn't need that code and would probably be better off if it were absent so they wouldn't think the driver should be dependent on it. If the idea of removing this causes angst I can't see how anything can be removed, ever. Dennis Ferguson
Re: Removing ARCNET stuffs
Date: Fri, 29 May 2015 10:22:35 + From: David Holland Because of these trends, I've been thinking for a while now that maybe it's getting to be time to fork. That would allow having one project that intends to stay current, with all the attendant requirements, which probably mostly doesn't make sense on vintage hardware; and another project that explicitly abandons most or all of that and instead concentrates on being the best possible traditional multiuser or workstation Unix, which does make sense on vintage hardware that was designed for (or could be adapted to) those roles, and which also makes sense on newer hardware to the extent it's consistent with the traditional role. I suspect if people have the time and energy to make and maintain a fork, they certainly have the time to write automatic tests for the old network protocols. If anyone wants to sit down and do that, I would be happy to help. If not, there already are `forks' that work: netbsd-5, netbsd-4, &c.
Re: Removing ARCNET stuffs
David Holland wrote: >On Thu, May 28, 2015 at 08:06:56PM +0200, Tom Ivar Helbekkmo wrote: > > Me, too. What NetBSD offers, that no other O/S offers, is the support > > for platforms that are no longer mainstream. I've run it on Sparc and > > VAX processors for years, and hope to continue playing with these old > > machines. I enjoy reading about others running NetBSD on even more > > exotic platforms. (Incidentally, and I run OmniNet (an ancient 2Mbps > > token ring network) between machines in my home lab that are too old to > > even run NetBSD.) > >I don't think (in general) that removing things is a good idea; but >it's increasingly difficult to keep NetBSD running on ancient >hardware. It's already infeasible to run the system compiler on most >such machines; this is only going to get worse with time. Other bloat >accumulates too, less rapidly perhaps but still so. The other day I >observed in chat that Someone(TM) needs to sit down with a slow >machine and a profiler for a while and find and kill all the >gratuitous bubble sorts, linear searches, and other things that run >too fast to be noticed on modern h/w; nobody disagreed, but on the >other hand nobody's been rushing to do it either. And other things >necessary for remaining relevant to semi-current hardware and usage, >like keeping up with X, desktop, and virtualization things, are often >in direct conflict with maintaining support for old hardware. I tried booting -current on a mac68k earlier this week, it certainly felt slower than I remembered. [snip] >Because of these trends, I've been thinking for a while now that maybe >it's getting to be time to fork. That would allow having one project >that intends to stay current, with all the attendant requirements, >which probably mostly doesn't make sense on vintage hardware; and >another project that explicitly abandons most or all of that and >instead concentrates on being the best possible traditional multiuser >or workstation Unix, which does make sense on vintage hardware that >was designed for (or could be adapted to) those roles, and which also >makes sense on newer hardware to the extent it's consistent with the >traditional role. I started using NetBSD because I wanted to use it on embedded systems. Being able to use exactly the same OS on a desktop machine for development was a big help and something that you don't really get with Linux as there are so many different source trees. Robert Swindells
Re: Removing ARCNET stuffs
Hi, On Fri, May 29, 2015 at 10:22:35AM +, David Holland wrote: > Because of these trends, I've been thinking for a while now that maybe > it's getting to be time to fork. That would allow having one project > that intends to stay current, with all the attendant requirements, > which probably mostly doesn't make sense on vintage hardware; and > another project that explicitly abandons most or all of that and > instead concentrates on being the best possible traditional multiuser > or workstation Unix, which does make sense on vintage hardware that > was designed for (or could be adapted to) those roles, and which also > makes sense on newer hardware to the extent it's consistent with the > traditional role. I would argue that this has happened already - FreeBSD and NetBSD are the results... at least from the outside, this is how it looks like, with FreeBSD focusing on few platforms but modernizing itself quite a bit (kernel preempting, zfs, ...) and NetBSD focusing on "it runs everywhere". I'm not sure the BSD worlds needs yet another fork. Now, speaking as application developer: I'd hate to see yet another BSD fork that I have to test OpenVPN on regularily, to see whether "we" or "they" broke something and system-specific parts need to be adjusted... (right now, we build and test on FreeBSD, NetBSD and OpenBSD, and various versions of those - sufficiently subtly different that there has to be system-specific code for ifconfig/route handling...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: Removing ARCNET stuffs
On Thu, May 28, 2015 at 05:01:02PM +, paul_kon...@dell.com wrote: > > But I too find it regrettable and possibly dangerous. One of my > > copious-spare-time projects is to dig up enough specs to add a DECnet > > stack to my systems; > > DECnet phase IV specs are readily available and good enough to > build interoperable implementations (which isn?t true, > unfortunately, for a lot of protocol specs). DECnet Phase IV > (DECnet/OSI) specs also have been uncovered, though they are in > more obscure spots. And DECnet nodes exist around the Internet; > the ?Hobbyist DECnet? group (?hecnet?) is the main focus of that > activity as far as I know. > > If you want pointers to documents, just ask, I can supply those. slightly relatedly, do you (or anyone else reading this) happen to know what happened to the mopd patches described in PR 3344? -- David A. Holland dholl...@netbsd.org
Re: Removing ARCNET stuffs
On 2015-05-29 08:18, Matt Thomas wrote: On May 28, 2015, at 4:15 PM, Johnny Billquist wrote: On 2015-05-28 21:19, Tom Ivar Helbekkmo wrote: paul_kon...@dell.com writes: And DECnet nodes exist around the Internet; the “Hobbyist DECnet” group (“hecnet”) is the main focus of that activity as far as I know. ...and while I'm sure Johnny Billquist can supply more details, and correct me if I'm wrong, DECnet on NetBSD seems to me to be an active component of the hecnet environment. Nope. NetBSD do not run DECnet. I run a bridge program, which I initially developed on NetBSD, but it runs on pretty much anything. Your’s don’t. :) If it doesn't, then I should fix it. Currently I'm just running it under Linux and OSX, and I know others who have run it on Windows and OpenBSD. I haven't tested on NetBSD recently, but if there is some problem it should be really easy to fix. That said, the code is just a plan, ugly hack. Oh, and DECnet on Linux is not so great either, and I believe it has been dropped from the main tree. But if anyone wants to try and get NetBSD to talk DECnet, Paul and me can certainly help in many ways. I have a Phase IV+ (so I didn’t have to much with the physical address) implementation but never got around to writing the apps. socket interface is identical to DECnet-ULTRIX. DAP is a beast as is CTERM. I could run IP protocols over, but then I have IP for that. :) If you say that you didn't fiddle with physical addresses, then you have been playing Phase V, as Phase IV requires that you manipulate the physical address. And that is also true of IV+. DAP would be really nice, but it's complex. But I like the capabilities. CTERM on the other hand is on my top-3 list of things I hate (pretty much the norm for all non-VMS people :-) ). I never committed it because I doubted there was interest. It’s probably bit rotted but I could resurrect it. Well, me for one would be interested... In a world a long time ago I was one of the kernel engineers for DECnet for ULTRIX and OSF/1 (nee Digital UNIX). It was one reason I could stand the netiso code because it was so horrible. Hey, cool. Then you should know more about this than I do. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Removing ARCNET stuffs
On Thu, May 28, 2015 at 08:06:56PM +0200, Tom Ivar Helbekkmo wrote: > Me, too. What NetBSD offers, that no other O/S offers, is the support > for platforms that are no longer mainstream. I've run it on Sparc and > VAX processors for years, and hope to continue playing with these old > machines. I enjoy reading about others running NetBSD on even more > exotic platforms. (Incidentally, and I run OmniNet (an ancient 2Mbps > token ring network) between machines in my home lab that are too old to > even run NetBSD.) I don't think (in general) that removing things is a good idea; but it's increasingly difficult to keep NetBSD running on ancient hardware. It's already infeasible to run the system compiler on most such machines; this is only going to get worse with time. Other bloat accumulates too, less rapidly perhaps but still so. The other day I observed in chat that Someone(TM) needs to sit down with a slow machine and a profiler for a while and find and kill all the gratuitous bubble sorts, linear searches, and other things that run too fast to be noticed on modern h/w; nobody disagreed, but on the other hand nobody's been rushing to do it either. And other things necessary for remaining relevant to semi-current hardware and usage, like keeping up with X, desktop, and virtualization things, are often in direct conflict with maintaining support for old hardware. Meanwhile NetBSD has a persistent problem with marketing and market positioning; to wit, we don't seem able to market and we haven't been able to formulate any notion of who to market to or for what, or why anyone should want to use NetBSD. The result of this is that the 15+-year-old market positioning of "of course it runs NetBSD" is still floating around, except it's mutated into "NetBSD is an OS for junkyard hardware". And the problem with that -- no matter how much some people enjoy working with vintage hardware -- is that it doesn't attract very many users or developers; especially since, as already noted, NetBSD is not actually a very good OS for vintage hardware. On top of this, it doesn't seem to me that there's much space in the current and near-future computing landscape for traditional Unix; the department login machine model is dead, and only a handful of oldtimers use anything that can reasonably be described as a "workstation". Meanwhile, the "desktop" software for Unix is basically warmed-over Windows NT squatting on top of (not even integrated with) a base Unix; and the way server farms are going there's increasingly little role for multiuser OSes at all. An OS project that wants to remain current has to adapt to these trends, and that means system- level and design changes that move away from the traditional multiuser Unix model that many of us are attached to. (This does not mean rushing to embrace systemd -- it means things like hotplug disks, numa-aware scheduling, filesystems for SSDs, streamlined system configuration, and different security models; it also means keeping up with moving standards like C++ and 802.11, and staying up to date with necessary 3rd party software like gcc and X11.) Because of these trends, I've been thinking for a while now that maybe it's getting to be time to fork. That would allow having one project that intends to stay current, with all the attendant requirements, which probably mostly doesn't make sense on vintage hardware; and another project that explicitly abandons most or all of that and instead concentrates on being the best possible traditional multiuser or workstation Unix, which does make sense on vintage hardware that was designed for (or could be adapted to) those roles, and which also makes sense on newer hardware to the extent it's consistent with the traditional role. At the moment NetBSD is trying to span both of these goal sets, leaning somewhat towards the latter through conservatism, and not doing either very well. I'm not at all sure that forking will improve the situation (or that forking per se is even necessary to handle both these foci) but it's probably at least worth thinking about. (I am not sure, if this fork happened, which project I'd work on; probably both.) There's one other thing I ought to mention here, which is that I have never entirely understood the point of running a modern OS on old hardware; if you're going to run a modern OS, you can run it on modern hardware and you get the exact same things as on old hardware, except faster and smoother. It's always seemed to me that running vintage OSes (on old hardware or even new) is more interesting, because that way you get a complete vintage environment with its own, substantively different, set of things. This does require maintaining the vintage OSes, but that's part of the fun... nonetheless, because I don't understand this point I may be suggesting something that makes no sense to people who do, so take all the above with that grain of salt. -- David A. Holland dholl...@netbsd.org
