Next steps for Gmane(home.gmane.org)
home.gmane.org
Next steps for Gmane
http://home.gmane.org/2016/08/29/next-steps-gmane/
13 comments
This is great, and I hope they keep the (or a) JavaScript-free interface, because that's the #1 advantage over things like Google Groups which defy any browser convention and you have to fight for usability. If I'm reading an archive of posts, I don't want a web application that tries to override the browser's controls and fails to deliver.
Interesting. While javascript heavy, google groups always gets the job done fine for me.
What I really dread is having to use something like the Postgres mailing list, which is painful with conversations split between multiple pages and block quote formatted so it takes mental effort to even figure out what's the previous message and what's the reply. I'm not familiar with gmane and am young enough not to have been a heavy newsgroup user.
What I really dread is having to use something like the Postgres mailing list, which is painful with conversations split between multiple pages and block quote formatted so it takes mental effort to even figure out what's the previous message and what's the reply. I'm not familiar with gmane and am young enough not to have been a heavy newsgroup user.
> block quote formatted so it takes mental effort to even figure out what's the previous message and what's the reply
You think it takes mental effort to read proper quotes, e.g. in https://www.postgresql.org/message-id/CANP8%2BjKvbe2jwOzUMGo...?
That's proper quoting style. It's incredibly readable, much more than the top-posting scourge we must deal with on so many mailing lists.
You think it takes mental effort to read proper quotes, e.g. in https://www.postgresql.org/message-id/CANP8%2BjKvbe2jwOzUMGo...?
That's proper quoting style. It's incredibly readable, much more than the top-posting scourge we must deal with on so many mailing lists.
[deleted]
Google Groups is a nightmare. It does some godawful overscroll-bounceback thing. My OS can handle scrolling just fine, thank you very much.
Try it on a slow connection and weak (or stressed) CPU. It becomes unusable.
And the amount of HTML, CSS, and JS it loads is disproportionate to the content, making me dread anytime I have to use it to read a thread. The asynchronous loading of content induces a painful delay in the workflow.
Agree 110% on the js-free being a huge positive. It's getting to the point where I want to revive those "thank you for not using AOL" flashing gifs and update them to try and start some kind of "no js" countertrend.
I fucking hate javascript.
I fucking hate javascript.
Upvoted. I don't hate JavaScript but there is no need for JavaScript on a site like that. I suggest NoScript as a way to turn on or off JS per site.
Partially offtopic. The very page at http://home.gmane.org/2016/08/29/next-steps-gmane/ is much better with JS turned off: JS loads the Raleway font which at the given size and color (#666) is too thin and not contrasted enough to be readable. I have to zoom in many times before it gets OK. The default Arial is much easier on the eyes. Raleway is not that bad on my tablet, maybe because of a higher DPI (8.4" at about 2500x1600 vs 15" at 1920x1080) or because it's AMOLED. Not bad but not good enough. Arial wins even there. With a color of #222 or darker Raleway starts the be readable, but still worse than Arial.
Partially offtopic. The very page at http://home.gmane.org/2016/08/29/next-steps-gmane/ is much better with JS turned off: JS loads the Raleway font which at the given size and color (#666) is too thin and not contrasted enough to be readable. I have to zoom in many times before it gets OK. The default Arial is much easier on the eyes. Raleway is not that bad on my tablet, maybe because of a higher DPI (8.4" at about 2500x1600 vs 15" at 1920x1080) or because it's AMOLED. Not bad but not good enough. Arial wins even there. With a color of #222 or darker Raleway starts the be readable, but still worse than Arial.
Google Groups seems like a proof of concept for GWT. Something someone design during a lazy friday afternoon. Except for the content, I have nothing positive to say about Google Groups. More often than not I prefer to not having a question answered, if the only solution is to use Google Groups.
The first iteration around 2004 was great. I think it worked without Javascript, was fast and had a clean interface (just like this site).
The current one definitely suffers from the second system effect. I also avoid it and actively search for other locations with the same content.
The current one definitely suffers from the second system effect. I also avoid it and actively search for other locations with the same content.
This may be surprising, but Sourceforge provides plain mailman lists for projects, and that's a viable alternative to Google Groups for open source projects.
Very true. Google Groups are not something I look forward to using most times.
Seconded. Being able to just read the articles from any browser was one of the great things about gmane.
I came to Gmane back when I needed to search newsgroups (NNTP) archives, then later on, mailing lists.
Maybe I'm nostalgic but I really miss the newsgroups that focused on just the messages, and could be consumed by any client, stored offline, searched, etc.
Maybe I'm nostalgic but I really miss the newsgroups that focused on just the messages, and could be consumed by any client, stored offline, searched, etc.
> "Maybe I'm nostalgic but I really miss the newsgroups that focused on just the messages, and could be consumed by any client, stored offline, searched, etc."
I don't see anything nostalgic about that, there's value in the benefits you list and rightfully associate to application-layer protocols.
A few months ago I stumbled upon a good article that praised them too, over today's "HTTP for everything", but I'm sadly unable to find it in my bookmarks. Anyway; more than anything, it lauded the interoperability that comes with those protocols.
I'm sending email from Thunderbird, and can reply minutes later from my iPad, and follow-up/search my archive at work from Outlook or Mail.app. Transmission merrily talks to uTorrent or Deluge or rTorrent. My windows box reads video files from a Samba share.
What now? Apps interfaces are at worst totally obscure (Skype), or at best exchange readable but undocumented JSON/XML over HTTP(S). Put differently: had email been designed & implemented today, we would hardly enjoy the same interoperability. There seems to be little interest around designing new protocols (and maybe little help coming from languages/libraries too?). IRC v3 ( http://ircv3.net/ ) comes to mind, but it's pretty niche. Anyway, I'm ranting. Can anyone complement from experience trying to do such protocol design/implementation today and the challenges associated with it?
I don't see anything nostalgic about that, there's value in the benefits you list and rightfully associate to application-layer protocols.
A few months ago I stumbled upon a good article that praised them too, over today's "HTTP for everything", but I'm sadly unable to find it in my bookmarks. Anyway; more than anything, it lauded the interoperability that comes with those protocols.
I'm sending email from Thunderbird, and can reply minutes later from my iPad, and follow-up/search my archive at work from Outlook or Mail.app. Transmission merrily talks to uTorrent or Deluge or rTorrent. My windows box reads video files from a Samba share.
What now? Apps interfaces are at worst totally obscure (Skype), or at best exchange readable but undocumented JSON/XML over HTTP(S). Put differently: had email been designed & implemented today, we would hardly enjoy the same interoperability. There seems to be little interest around designing new protocols (and maybe little help coming from languages/libraries too?). IRC v3 ( http://ircv3.net/ ) comes to mind, but it's pretty niche. Anyway, I'm ranting. Can anyone complement from experience trying to do such protocol design/implementation today and the challenges associated with it?
HTTP won out because it's the 'universal' protocol: you GET a resource, you say 'I prefer text/html but really anything is fine', the server puts bytes on the wire, it includes some metadata (headers, Content-Type), and then your user-agent interprets that Content-Type and displays the result. It's an extensibility advocate's dream. Using this and the jack-of-all-trades datatype HTML, we developed documents that link to other documents. When we were no longer okay with static pages, we hooked up programs that wrote HTML onto stdout and at the end of the day, everything just came across as a sequence of bytes. There's no formalized, official application-level logic to the HTTP state machine (although there are third-party attempts [1]).
Using these universal building blocks, we built applications where state transitions consists of GETs and POSTs. Eventually, when we wanted machine-structured data, we did XML-RPC, later codified into SOAP, before the backlash against hard-to-understand standards led to JSON being traded between server backends and client-side obfuscated, minified Javascript state machines.
Not enough people make new running-on-TCP or running-on-UDP protocols because new protocols are hard to design, they don't work with the one application where everyone spends 70+% of their time (the web browser), and they probably get blocked on a middlebox except if you use port 80 or 443 and fake being HTTP anyway. For all but very specialized use-cases, vomiting blobs of JSON (or if you want to feel extra good, some custom binary serialization format like protobuf or Thrift or Cap'nProto or MessagePack) across HTTP endpoints is pretty okay.
[1] https://github.com/for-GET/http-decision-diagram
Using these universal building blocks, we built applications where state transitions consists of GETs and POSTs. Eventually, when we wanted machine-structured data, we did XML-RPC, later codified into SOAP, before the backlash against hard-to-understand standards led to JSON being traded between server backends and client-side obfuscated, minified Javascript state machines.
Not enough people make new running-on-TCP or running-on-UDP protocols because new protocols are hard to design, they don't work with the one application where everyone spends 70+% of their time (the web browser), and they probably get blocked on a middlebox except if you use port 80 or 443 and fake being HTTP anyway. For all but very specialized use-cases, vomiting blobs of JSON (or if you want to feel extra good, some custom binary serialization format like protobuf or Thrift or Cap'nProto or MessagePack) across HTTP endpoints is pretty okay.
[1] https://github.com/for-GET/http-decision-diagram
HTTP "won" for the reason that port 80 was open anyway on corporate firewalls, so everything was shoehorned into it - but not for purely technical reasons.
Yet HTTP 2.0 is a bit like TCP on TCP, given its new binary only format.
Oh absolutely [1]. But the HTTP/2 endgame is likely to re-define it in terms of a protocol over QUIC, a situation the QUIC folks are eagerly anticipating [2]. This is no surprise considering both originated at Google.
QUIC is a secure transport protocol (subsuming most of the features of TCP and TLS) that runs on top of UDP (because they wanted to craft a 'better' TCP, and the only other not-blocked-by-default transport protocol is UDP).
[1] https://news.ycombinator.com/item?id=9548138
[2] https://tools.ietf.org/html/draft-hamilton-early-deployment-...
QUIC is a secure transport protocol (subsuming most of the features of TCP and TLS) that runs on top of UDP (because they wanted to craft a 'better' TCP, and the only other not-blocked-by-default transport protocol is UDP).
[1] https://news.ycombinator.com/item?id=9548138
[2] https://tools.ietf.org/html/draft-hamilton-early-deployment-...
I sadly know QUIC.
Since Google pushed it into Android Chrome, I cannot log-in into our customers WLAN infrastructure on Android 4.3 only with 4.4+ devices, not even by disabling it via the flags menu.
And some of our devices are on 4.3 and now need to make use of HSDA for network access.
Since Google pushed it into Android Chrome, I cannot log-in into our customers WLAN infrastructure on Android 4.3 only with 4.4+ devices, not even by disabling it via the flags menu.
And some of our devices are on 4.3 and now need to make use of HSDA for network access.
I will use web forums only when no email or NNTP server are available.
All of them are slower and less usable than navigating the messages via Thunderbird, or similar client.
All of them are slower and less usable than navigating the messages via Thunderbird, or similar client.
Web forums and NNTP aren't exclusive. For example D language website uses a forum-like wrapper over NNTP server: https://forum.dlang.org/
I know, I used to be a regular member there, but thanks for the remark.
> I petitioned some of our directors
What directors? I couldn't figure out from the post who Martin Danko is or who he works for.
What directors? I couldn't figure out from the post who Martin Danko is or who he works for.
The about page on gmane.org has been updated, the new owner is hosting company Yomura (Delimiter)
http://gmane.org/about/
http://gmane.org/about/
Interestingly, Yomura Holdings have almost no presence on the Internet at all. Indeed, almost the only reference to them is on forums where people ask who they are. Very odd …
This is entirely reasonable -- one of the reasons Gmane was taken down was constant threats of litigation. Keeping it a separate business entity owned by the same holding company means that a lawsuit aimed at one won't sink the other.
Not unusual though. Many people have holding companies with the sole purpose of separating the them and their "actual" company, in case of bankruptcy. Holding companies like that seldom need an internet presence, or any presence really, they only exists to provide legal protection.
The company I work of is actually owned by a series of individual holding companies, each one hold some percentage of the shares in the operating company. The holding companies mainly exists to protect the owners from bankruptcy.
The company I work of is actually owned by a series of individual holding companies, each one hold some percentage of the shares in the operating company. The holding companies mainly exists to protect the owners from bankruptcy.
Thanks so much! Gmane is such a great resource for the world.
And thanks again to Lars for his years of service.
And thanks again to Lars for his years of service.
For the uninitiated, what is Gmane? From their home page it looks like it's similar to Google Groups. Is that a fair assessment?
Gmane is a bi-directional gateway from Mailing Lists to NNTP (the 'Newsgroups' protocol), with some extra features like spam control, search, web interface, and RSS feeds.
It's also an archive of the above. This archive functionality is in common with Google Groups.
See the 'About' page [1].
[1] http://gmane.org/about/
It's also an archive of the above. This archive functionality is in common with Google Groups.
See the 'About' page [1].
[1] http://gmane.org/about/
It might not be as complete as Gmane perhaps (I didn't stop to compare them on a feature-by-feature basis), but I have been happily using http://markmail.org/ for a while as a gateway to many mailing lists.
Markmail is great. If only they could replace their Flash-based graph by some sort of <canvas>. Also, I think Gmane has more coverage in terms of number of mailing lists.
Is there a plan to make the server code free software and publicly available? It would help avoid this situation in the future:
> As part of the agreement, we have received the INN spool with all the articles but none of the code that drives the site.
> As part of the agreement, we have received the INN spool with all the articles but none of the code that drives the site.
I never use Gmane, but I'm happy to see that projects like this find people to keep them going.
I assume the old links to threads/posts will be alive again soon.
Whoah! It seems like they are! http://article.gmane.org/gmane.comp.compilers.llvm.devel/881...
lars posted some of his gmane backend code at his github, but who knows common lisp nowadays?
https://github.com/larsmagne/reticule for the NNTP gateway, gwene (in perl) for the rss parts.
https://github.com/larsmagne/reticule for the NNTP gateway, gwene (in perl) for the rss parts.
THis is really great news.
Any way we can get Gmane up on Baqqer so we can donate/support operations in some way/form?
- Founder of Baqqer
I don't have a problem with self-promotion, but if you're more interested in supporting Gmane than in promoting Baqqer, it shouldn't really matter if the donation is via Baqqer, Gratipay, Patreon, a Bitcoin address, or even just a PayPal donation link.
I don't have a problem with self-promotion, but if you're more interested in supporting Gmane than in promoting Baqqer, it shouldn't really matter if the donation is via Baqqer, Gratipay, Patreon, a Bitcoin address, or even just a PayPal donation link.
We built Baqqer for this reason. I wanted to know if we could get them on there so we can actually help. I can't really help them set-up or maintain their presence on other sites, but on Baqqer I can instantly provide them with support, features, or even minimize fees if it helps. It's win-win.
Just a member of the HN community trying to help out how I can. :)
Edit: According to your resume you've been a contributor to Gratipay.
Just a member of the HN community trying to help out how I can. :)
Edit: According to your resume you've been a contributor to Gratipay.
Totally awesome, a true philanthropist.
I can't tell if you're being facetious. :) What more can I offer than time, money, and services to help facilitate their endeavor?