Yeah, as someone who had to implement a protocol stack to talk to a X.400 server, it was not fun at all. Weird encodings, monster spec, all sorts of weird server-specific stuff that you had to do exactly right if you wanted the server to accept your email.
Compared to that, when I implemented RFC821/822 (i.e. SMTP) mail, the hardest part was the weird line-encodings, but other than that, the spec was ___so___ nicely readable and pragmatic.
A couple of years later ipv6 became unnecessary. A big driver for ipv6 at the time was routers not being able to manage the increasing size of the core routingtable. Then 2 years later betterhardware and routing table compression became available and ipv6 became unnecessary.
Uh, no it didn't? Routing table size is still something of a problem, especially as v4 continues to fragment more and more, but also the main driver was insufficient IP addresses in v4 and that problem hasn't even slightly gone away.
I was there, reading the ipv6 mailing list eagerly. Address space exhaustion was a smaller problem because NAT was pretty primitive, so called carrier grade NAT was not even a thing yet. But cisco had the largest routers and their biggest was not big enough for the core router fabrics projected growth. And there was not enough demand (yet) for very large routers fir cisco to want
to design and build the nevessary chips. The IPv6 people thought they held all the cards and could mandate whatever they wanted.
But of course, it was s very long time ago and my memory may be inexact.
That might well have been a more immediately pressing issue, but they did know that v4 was going to be too small and that they still needed to work on v6.
I might be saying something obvious here, but address space exhaustion and size of the core routing table are really two sides of the same problem anyway. The way to keep the routing table size down is to give everybody a small number of big allocations instead of a big number of small allocations, but that consumes more address space since the allocations have to be rounded up to at minimum the next integer power of 2 (and really more, to accommodate growth).
So what were the contrived reasons? I navigated getting coolwsd built before, but never quite got my user management layer for Nextcloud perfected to the point of going live... I thought it was a good piece of kit, but was a little bit skeptical of the branding divergence at the time. Something about it kinda just felt like drama waiting to happen. Was that it do you think? Or something else. Will keep an eye on the project regardless.
Not from the board, (implies board of directors), but from TDF membership (board of trustees). This essentially means you have no voting power and no benefits, but you're still free to still contribute by fixing bugs, adding new features, mentoring, code review,... ("community"). This are all the things that would benefit TDF by getting more money from donations (and then use that money for useful things that are mentioned in this TDF blog post).
I read it, and was hoping I would be more sympathetic to their side, but it was essentially 'they violated the rules our newly added non-contributor board members set, and by those rules, we kicked them out'.
Essentially this 100% confirms the Collabora story, just elaborates a bit on how the administrative takeover was done.
Not just this, it the way the vote was announced seems very, very bad. Italo may have found legal issues, but one of the things he said was that legal action was being taken by Collabora. That… doesn’t seem to be the case.
Italo and co removed some very dedicated contributors from the TDF. What an absolute disaster.
I suspect that Time Machine is no longer used by a sufficiently large % of their customer base for them to care, and they are slowly sunsetting it. They are quite aggressive about that sort of thing, so I expect it to to deprecated in favour of iCloud soon.
Or.... smoking may be indicative of people from poorer backgrounds, where health is generally lower. (cant say for sure, but thats the case where I am from)
Compared to that, when I implemented RFC821/822 (i.e. SMTP) mail, the hardest part was the weird line-encodings, but other than that, the spec was ___so___ nicely readable and pragmatic.