The protocol wars were over years ago. What we are doing now is cleaning up the battlefield of any leftover debris.

The protocol wars were over years ago. What we are doing now is cleaning up the battlefield of any leftover debris.

Sadly, too much of that debris is still festering away and often mutating into new types zombies that are hard to kill off.

Except there are some people looking to replace tcp inside data centres, coz it's too slow...

Absolutely.

Early in my career I specialised in Lotus Notes. Which had network drivers for all kinds - TCP, NetBIOS, SPX, Banyan VINES, serial connections... I don't specifically recall DECnet being in there, but that's probably because VAX was one of the few server options Notes never had...

I met Notes back in 1996. I think I only ever had one production server that used SPX - a Notes server running as an NLM on a Novell Netware server. Very very rapidly everything went to TCP/IP. A decade later, those drivers were already a historical curiosity for 99% of computer professionals working with Notes.

They got removed from later versions shortly after that.

(Yes, there were later versions of Lotus Notes, no matter what it might have seemed like. Companies just took their own sweet time deploying them...)

I'd say that TCP/IP had won by the year 2000. Everything since then has been mopping up operations...

Banyan VINES? Christ... that's a ghost from the past.

Lotus Notes .... you mean VAXNotes++. ... though the "++" is debatable :-)

There are still a few laggards running IPv4, I hear.

I'm rather uncomfortable that an individual from Microsoft has taken it upon himself to remove multiple protocols from the Linux kernel. Particularly as many seem to have been used by former Microsoft competitors.

If there's one company that knows about the clutter that backwards compatibility wreaks on an OS, it's Microsoft (reserved A: drive? Still? Really?).

I have no problem with them suggesting unmaintained and unused drivers that can be removed from the kernel. Keep in mind that, while they are there, these drivers need to be tested with each release, adding to the burden of the kernel maintainers.

Whilst I am not particularly attached to a DECnet card, it would be good if rather than removing it from the kernel and putting it in the bin (or in the depths of Git repo), if it could be isolated into a single .h and .c file and made portable and easy to maintain / re-integrate for those interested.

Yes, there is more to it than just a driver, there is much plumbing (especially for older GPUs too which is where my main thoughts are). However it could be quite a unique feature of Linux to deprecate and remove things in a less "breakful" manner.

It might not be possible, then fair enough but honestly I feel open-source operating systems are the only ones that could get close to achieving this.

Why would a network protocol require "much plumbing (especially for older GPUs"?

WTF does a GPU have to do with networking? Especially a network protocol that predates the GPU by a couple of decades.

Perhaps read my post again and you will see that I was talking about drivers in general by that point. My whole post was about seeing if drivers can be put into long term storage rather than destroyed.

Most drivers need plumbling. Network drivers need the i.e TCP/IP stack, GPU drivers need i.e the DRM/DRI stack.

As the article mentions there was no maintainer for the protocol for over a decade I'd say it was already in 'long term storage' for 10+ years.

The proposal to remove it mentions that most changes done to it were attempts to clean up.

This shows having the code in the kernel does create additional effort for the kernel programmers.

When nobody is able and willing to maintain it and nobody steps forward to say he's still using it the logical thing is to remove it to get rid of effort necessary to maintain the code in future kernel versions.

The only time I was involved with DECNet the Ethernet addresses assumed that the NIC was made by DEC and hardcoded the DEC-specific part of the MAC. If you wanted to use DECNet on some non-DEC kit you have to overwrite the MAC. How is this handled these days when the NICs are anything but DEC?

We were using HP-PA hardware and first turned on the DECNet stack in the middle of the working day. This meant that all nodes using the HP server now had invalid addresses in their caches... The clamour from the users died down as their PCs re-synchronized.

"TIf you wanted to use DECNet on some non-DEC kit you have to overwrite the MAC. How is this handled these days when the NICs are anything but DEC?"

Who gives a shit? DECNet is dead, dead, dead. Even those overseeing the everything-but-the-kitchen-sink approach of the Linux kernel recognise this. Just kill the DECnet kernel code. Kill it with fire.

I thought the underlying point with Linux was that you added whatever drivers to your installation that you wanted yourself, just like RMLoading a module on RISC OS. After all, I wouldn't expect the operating system I bought to come with a driver for my JayEx LED display board (what's that? exactly!), I'd load the driver myself when I needed it, or as /my/ default build.

If you really want to you can still build a DECnet kernel module and load that, the kernel infrastructure to do that is there.

DECnet protocol support will just no longer come out of the box with the vanilla kernel.

Did you miss reading the bit that said VMS is still alive? I doubt those maintaining it consider DECNet dead.

The NIC hardware address still has to be overwritten. DECnet uses a NIC address of AA-00-04-00-xx-yy where xx-yy are the six bits of the area address followed by the 10 bits of the node address within the area.

This (at the time elegant) fudge allowed easy DECnet routing on an Ethernet without needing dedicated routing hardware or software.

Note at the time that DECnet Phase 4 was developed 10Mbit/sec Ethernet over thick coax cable was high speed networking and the majority of the PDP-11s in use could not manage even 1 Mip - saving processor overhead was important.

It's probably worth elaborating that a little further.

There was no fundamental architectural reason to change the MAC address: endnodes sent out periodic "hello" messages that could have been used to map the 16-bit node address to a 48-bit MAC address. However, given that 1000 endnodes were permitted on a single LAN segment, it would have meant routers reserving potentially at least 6KB of space for the mapping - which is a big chunk of a 64K address space being used for other kernel things - and that endnodes (which may well be CPU-constrained) might have to look up a 48-bit key to find the associated 10-bit DECnet local area address. Fixing 32 bits of the MAC address got rid of those problems.

Interestingly, the first Phase V routers were faced with a different constraint: the change from routing vectors to link state routing made it very difficult for contemporary hardware to find room for the routing database which led to some considerable arguments in the organisation.

Also worth pointing out that DECnet made much more use of Ethernet architectural features: it used different multicast addresses to segregate endnode (host) traffic and Level 1 and Level 2 routing traffic and used different protocol types for discreet functional operations (like remote booting).

While DECnet's day has clearly gone, I do regret that accessing those Ethernet architectural features is still rather more trouble than it needs to be on Unix/Linux: there's an implicit assumption that the network is there for IP and convincing the network driver otherwise requires some effort. And, indeed, privilege/capability.

IIRC, and I'm probably wrong since it's been about 3 decades, the "AA-00-04-00-xx-yy" address was rewritten to "yy-xx-00-40-00-AA" as the MAC. That way, in hardware it would do a bit compare. First mismatch and it bailed because it was for a different address.

How is this handled these days when the NICs are anything but DEC?

In fact all Ethernet NICs can change their MAC address upon command. That's how you get "random MAC address" options as a security feature on phones or PCs.

In DECnet, the feature allows to send a packet directly to the node in question since the necessary MAC address is a calculated number.

Contrast IP over Ethernet where designers added the ARP protocol to answer the question "what is the MAC address for 192.168.111.222?" Once you have that answer you can then send a packet directly.

I joined DEC back in 1986 and was one of the first to show PATHworks to customers (anyone remember the Vaxmate?). I was friends with the USA development teamteam (I pointed out a Netbios bug and showed what the fix would be) and used DECnet for DOS all over the place. DECnet itself was pretty good - and as the article says, could be accessed all over the world. They were good days back then - shame it's all just TCP these days.

Alan

The VAXmate .... the Oztralian version along with the DECMate ....

How does a Decnet network work?

;-)

If you need a FOSS solution for DECNet, I rather suspect that FreeBSD will support it until roughly the heat death of the Universe.

I can't imagine that it adds much payload to a distro, and I don't imagine it needs much maintenance...

Why not leave it?

(Genuine question, and applicable to the other old stuff)

I think it's a case of removing unused code which may hold the potential of creating unintended interactions - given that it's also unmaintained, such a problem would not be solved that quickly. Best to park it completely, also makes the code tighter yet again.

AFAIK it'll still hang around in the archives anyway, and if anyone really wants it they're advised to put some resource into it.

I feel that there should be a funeral. Many hours of this man's life has gone silently into the night

True. Digressing slightly, OTOH, I like the silence - there's nothing I find more annoying than Windows' default habit of pinging, bleeping and making other noises during the day like a child that is desperate for attention. In other OS I can at least control what makes noise so I can limit it to things that actually matter, but in Windows I eventually resort to just killing the sound altogether.

But yes, let's not forget the gear and code that got us started. I support a two computer musea exactly for that purpose, but there isn't really a software museum now, is there?