HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


When Linux goes wrong - Comments

Login / Search

 [ Join | More ]
 

When Linux goes wrong

Posted 06 February 2013, 5:11 PM
Our server's email wasn't going out for a couple of days, and it just clicked with me this morning when I wondered why I wasn't notified about some new issues posted on the tracker.

I thought I'd be a bit technical about what happened, and then a bit philosophical about why in 2013 we're still all dealing with such arcane software.

So, what happened?

We installed some new packages on the server, to…

Read more


Avatar

Chris said

…these systems are plumbed together via these ageing software components that are filled with unneeded complexity that only exists for legacy reasons…

Chris said

How about stopping re-inventing the wheel all the time, throwing out what came before and always starting from scratch?

Damned if you do (have legacy support), damned if you don't ;)

I think email, as a standard, is the worst of all legacy systems out there. It's too popular to die, it's relatively nuanced and convoluted, every corner case must be supported since someone will be relying on it, it doesn't handle forward compatibility well (there's no graceful fallback for ignoring unknown commands, there's no standard way to declare support for arbitrary extensions, or to discover the capabilities of someone else, and so on). I agree that mail daemons are notoriously difficult beasts, but these problems with email make a lot of this complexity unavoidable. For example, the lack of a security model requires orthogonal extensions like TLS, but the lack of graceful handling of unknown commands means that we can't just enable TLS globally, as servers which don't support it will choke. We can't discover which servers support it, since there's no capability discovery, and this also prevents us notifying connected hosts that we require it. The only way around this is to configure it all by hand :(

If everyone could, overnight, be switched to an alternative which had a decent security model, it would be a monumental huge efficiency gain (in terms of processor usage, network usage and manpower). Sadly, that's not gonna happen :(

1 guests and 0 members have just viewed this: None
Control functions:

Quick reply   Contract

Your name:
Your message: