GNU developer here (MediaGoblin lead developer). GNU projects get to decide whether or not to do copyright assignment to the FSF. As an example, MediaGoblin and Guix don't require copyright assignment, while Guile does.
So I have quite a bit of bias, since I work on a specification in this area. So yes, if you want to make sure it's GNU Social (formerly StatusNet) compatible specifically, use OStatus, which is a number of protocols combined in a specific way.
The most unfortunate part of all this though is that all these different applications, GNU Social, Diaspora, Pump.io, etc all speak different protocols and aren't all really interoperable. This leads to a "fractured federation", which really isn't great. I've been participating in the W3C Social Working Group to try to standardize federation. Here's our spec, ActivityPub:
Some background: it's derivative of the "Pump API", which is sort of the successor of OStatus, in the sense that the primary author of StatusNet (now GNU Social) wrote the Pump API in response to some perceived shortcomings in OStatus. We've done a lot of analysis to make sure that the protocol can handle all the kinds of things that you expect from the "big player" social networks, but in a federated setting.
Interested? Now's a great time to research and give feedback. We're looking to move to Candidate Recommendation status shortly, which means we're looking for feedback and implementations.
PS: I'm also involved in MediaGoblin, and we definitely intend to implement there. If you're interested in a bit of news from that end, here's a moderately fresh blogpost, including info on how to give your feedback: http://mediagoblin.org/news/tpac-2016-and-review-activitypub...
This comic may have singlehandedly done terrible damage to technology standards, by spreading the meme that trying to create a unified standard never works and nobody should try.
Anyone put off by a comic is clearly not suited to the hard slog that is required to get standards written, agreed, and implemented. So i think xkcd may be doing us all a favour by discouraging those who haven't got the stamina.
The lack of understanding of this comic has done more damage. Every person suggesting a new specification should have at least some idea of why people using the existing specifications would be interested in migrating, and how.
I think ActivityPub has that to some extent, and the group reached out to existing fedsocnet implementations as part of their work. Time will tell if it was enough, or if we now indeed have yet another specification next to all the others.
Basically, I think that Lisp and Scheme have a reputation for being unapproachable. This reputation partly comes from how we structure our communities, who we reach out to, and etc. But it also depends on how we message ourselves.
There's a very conscious decision in the new design to make things look playful and inviting, to encourage experimentation. I think that's super important. It seems like it's having some effect on encouraging people to become engaged, and it certainly doesn't seem to be doing any harm to those who are already into hacking parentheses. :)
It's still in an early stage, but it works. That emacswiki post points you in the right direction, but if you use the Guix package manager, you can give it a try: "guix package -i guile-emacs"
Mostly at this point it needs people working on it and playing around with it. Considering you're fairly excited about it, maybe you should give it a spin? :)
Since I'm sure everyone is thinking, "but don't we already have Docker for everything?", I'll point out that this was addressed on one of Dave's mailing list posts, in case you're looking for a comparison!
> 1) The container tools I'm working on are completely declarative.
> 2) There are no disk images.
> 3) Software and other files shared amongst many containers are deduplicated system-wide.
> Once again the fundamental building block of every Guix tool, the immutable store, proves to be an invaluable asset in overcoming the problems of our imperative
predecessors and contemporaries.
Maybe true, but "stone-old" ideas don't mean "bad ideas". Neural networks were "stone old" until all this big data stuff went crazy and now suddenly they're on the frontpage of hacker news all the time again and people think they're the New Hotness (TM). Similar with many long-forgotten functional programming techniques which are being talked about as new stuff, much of it is refinements of old ideas, but finally hitting the mainstream.
The AI Winter is thawing... but whose lap will it fall into after the defrost? Big data mining organizations, or everyday hackers, or....?
My dream would be if Good Old-Fashioned AI (the symbolic, explainable kind Sussman is interested in) were to have the sudden redemption that neural nets had.
It was easier for neural nets, though, because they were close to a previously successful AI mechanism (machine learning with logistic regression), it's just that we had spent decades talking about them with different words for no good reason. There's a much larger gulf between GOFAI and what we do now.
Pattern matching has unbeatable performance benefits, at least for our current computers.
If you go deep in numerical calculus, you'll see that our computers are must better fit to work with continuous smooth functions than they are for discrete noise-like data. So, all the power goes to the people that turn their knowledge into a smaller set of interpolated curves. (And yes, I think that's very counter intuitive.)
Anyway, I'm not convinced this is a fundamental property of CS. It sounds at least possible that different architectures could have different constraints, and make symbolic AI viable. But it those would need to be very different architectures, not based on the Von Neuman or Turing's ideas at all.
Yes that's exactly what's happening. Hy has two levels of things mostly: a "compiler" that does the low-level mapping of base python constructs (and whatever can be mapped to AST)... here's where list-comp is implemented: https://github.com/hylang/hy/blob/master/hy/compiler.py#L137...
