A look at the Gemini protocol: a brutally simple alternative to the web - <AUTHOR> https://toffelblog.xyz/blog/gemini-overview/ <comment><USER3> It feels like the main feature of this project is incompatibility with HTTP. The protocol is new and primitive, it's easy to write tools around it, write texts about it, etc. A small community forms, and you're part of it. You can advertise it to others, or rant against the mainstream, or whatever. But now what? You lose interest and abandon it, and eventually it dies.

We already have a transport protocol that "everybody" agrees on: HTTP. We can define a specification for a subset of it, and a subset of HTML/browser features we want, create tools around them, and form a small community.

The advantage here is that the community is not an island. Users of Big Browser can still read your latest rants. They can even learn about this project and, while perhaps not using Mom-and-Pop browser, may support it in their sites, since it wouldn't require another server; mostly just having their site work without JavaScript would be a huge step forward. Right, you don't have Google filtering based on Accessibility. The community can create a search engine that does. Now what? You just get on with your life, producing and consuming AccessibleWeb content without the gratuitous incompatibility.

<comment><USER4> I totally agree with that. It is not like some web police force is holding people at gunpoint to add javascript and angular or react. People use all those features because they want to and they find it useful.

<comment> loup-vaillant There kinda is?

While web sites can avoid JavaScript all right, browsing most sites does require JavaScript. As a NoScript user, I'm keenly aware of how many web sites simply _do not work_ without JavaScript.

And I'm not even talking about all the third party spyware.

<comment><USER5> I had to give up doing this. I couldn't manage all of the different times websites broke over just CDNs. Lord help me if the website is Ad driven.

I encourage every web developer to try running NoScript for a week. You will find it enlightening.

<comment><USER6> If you're already using uBlock Origin you can disable JS per site (or by default, like NoScript). I've found that the UI is _way_ easier to understand compared to NoScript.

<comment><USER7> uMatrix is similarly excellent (finer grained control I think is the difference).

For frequently visited sites you can save which bits you want to allow so its not as onerous as you'd think.

Blocks Google Analytics and Facebook's poison by default.

</comment></comment></comment></comment></comment></comment><comment><USER8> > Blogs, [..] are perfect for the Gemini format.

> Gemini lacks in-line images

This is the only part that I don't really understand about Gemini. Even the most basic printed publications can include illustrations. <img> got added to HTML very early on because sometimes it's hard to share some piece of information in anything but a visual form.

I write a (mostly) technical blog that certainly focuses more on text content than images. I would be happy to throw away the header, sidebar and the rest of the "design" cruft (in fact my blog is perfectly usable in a browser that doesn't support CSS or Javascript) But I can't imagine having my posts without graphs, diagrams and photos inserted in the text.

If the fear is that in-line images would lead to frivolous use as ads or "useless multi-megabyte header images", then maybe a better approach would be to limit the number, or size, of images on each page? Some scientific publications do exactly that in an attempt to force the authors to focus on selecting only the most important images that need to accompany their papers.

<comment><USER9> The lack of inline links is less about aesthetics and more about predictability. When you request a gemini resource you know that there will be two things happening: a TLS handshake followed by, hopefully, the server response (hopefully with your requested document).

Adding images requires more requests and breaks the concept of "one url/document == one request". I love that I know that my client will do nothing I do not tell it to do.

If you want to use gemini and you want inline images I believe [https://proxy.vulpes.one](https://proxy.vulpes.one) does inline images of some form or other.

That said, images have other issues beyond causing page loads/requests to be unpredictable: they are an accessibility nightmare (as we have seen on the web).

<comment><USER10> > they are an accessibility nightmare (as we have seen on the web).

Audio is an accessibility nightmare for people who can't see, text is an accessibility nightmare for people who can't see or people who can't read, German is an accessibility nightmare for people who can't speak German.

At some point we have to accept that not every way something is presented is going to be equally accessible by every person, but the solution isn't to just decide we should jettison a rich form of communication because there is a small subset that can't fully benefit from it. Even books that are expected to be used by people who can see all the images usually describe the purpose of the image, what it is illustrating, and why it was included.

</comment></comment></comment><comment><USER11> A large part of HTML, and a large part of modern browsers and other web technologies, are focused on ensuring that the publisher has control over the user's experience. I really like the fact that Gemini breaks that, and I hope that the project owners mercilessly reject any attempt to introduce features that allow the server to control or influence user experience.

I would really like to see structured text that is self-descriptive (e.g. this is the document title, this is a paragraph, this is a header, bullet list, etc.) but have no ability to influence HOW those things are displayed- eventually maybe we'll have browsers that can support rich theming, etc.

Others have noted that lack of images is an oversight. Perhaps the language needs a "binary file download" structure, and if the binary in question is a media file, then the browser could choose to display it. Maybe signal with mime types?

<comment> yoz-y > A large part of HTML, and a large part of modern browsers and other web > technologies, are focused on ensuring that the publisher has control over > the user's experience.

It's also the reason why it caught on. On one hand people reject the ability to express individuality on the web, on the other a similar crowd is nostalgic about geocities and praises similar revivals. It's either one or the other.

> I would really like to see structured text that is self-descriptive (e.g. > this is the document title, this is a paragraph, this is a header, bullet > list, etc.) but have no ability to influence HOW those things are displayed- > eventually maybe we'll have browsers that can support rich theming, etc.

How about publishing markdown over HTTPS? Then make a client that renders just that?

<comment><USER12> Why's it either one or the other? You could have one browser application for no-nonsense textual or informational pages and one for wacky personal geocities/myspace style pages. Feel free to enjoy both, either separately, or if you want more integration you're free to use the underlying OS shell to switch between them, read them side-by-side, link between them, etc.

<comment> yoz-y > You could have one browser application for no-nonsense textual or > informational pages and one for wacky personal geocities/myspace style > pages.

Hence the idea of a separate markdown only browser. I don't think http is the problem here. So it would be better to reuse as much existing tech as possible.

Note: Personally I don't think it would catch on, the convenience of handling everything in one program is just too high.

</comment></comment></comment></comment><comment><USER13> I'm a Gemini newb, but I've enjoyed using the AV-98 client so far: [https://tildegit.org/solderpunk/AV-98](https://tildegit.org/solderpunk/AV-98)

If Gemini sounds like a dumb idea, I'd highly encourage you to move along. If Gemini sounds intriguing, you'll probably have fun.

Lots of opinions in this thread, but doesn't look like many armchairs have tried it. Personally, I've enjoyed the rabbit hole.

</comment><comment><USER14> I feel like the lack of image support is a missed opportunity.

I know it is an idealogical choice to _only_ have text, but being able to embed standard image formats (on a totally plain, non fancy way) would increase the utility of this hugely. They mention blogs and tutorials and recipes here - those would benefit hugely from having simple inline images within the body of the text, just like you expect in a newspaper etc.

I guess I am not the target market then.

<comment><USER15> I understand why they didn't allow inline images, but I agree with you it limits a lot of use cases.

If I were designing it, I would say: "you can have images, but they always display as a 'block element', with nothing to either side. No worries about wrapping text; no background images _under_ other elements, etc." I think that keeps the spirit of simplicity.

<comment><USER16> you can have images and they don't always display as anything. the author of the user agent decides how they are displayed. you could in-line them if you wanted to, but only a few clients do that at the moment. there are no hints to the client about how some content could, should, or should "always display as".

It's text. The client displays that text and renders links, headings, etc, however it wishes. If it really wants to, it could just not format them at all. There's a gemini client made for plan9's acme text editor that doesn't render links, and instead displays them verbatim, because the plan9 plumber can handle the hyperlinking aspect. All of that is eye candy and fluff.

If a client finds a link to an image, it can in-line it if it wants. If you wrote a client, when it found a link to an image, it would in-line it "with nothing to either side." That's not something that has to be specced.

</comment></comment></comment><comment><USER17> I would take an alternative position in this matter. What we need is a simple yet functional subset of web. The point is to be able to build a browser in a reasonable amount of time with many languages reusing some commonly used libraries, while being able to use latest Chrome to browse those websites as well.

TLS: keep it as it is. Crypto is hard and TLS is proven crypto. Mandate something like 1.2+ and be done with it. Every mature language has TLS implementation or bindings.

HTTP: use subset of HTTP/1.1. Parsing is very easy: it's just bunch of lines. Full HTTP/1.1 is hard and probably unnecessary. Things like connection reuse are not necessary and should be excluded for simplicity.

HTML: use subset of XHTML. It must be valid XML, so parsing is just one call to the XML library which is available on every language.

CSS: I don't really know, that's a tough one. Something like CSS 2 I guess. There must be a balance between complexity of implementation and richness of presentation.

JavaScript: just nope. That rabbit hole is too deep.

If you take this position to the extreme, you can even reduce HTML + CSS to some kind of markdown-like language, but I don't think that we need to go that far.

<comment><USER18> Honestly, you've just described about 95% of gemini exactly. It's TLS required (even 1.2+), line-based parsing with text/gemini content, it's actually even simpler to parse than XML, since it's line-based (just peek at first 3 characters, you know the line type from that). It doesn't use CSS or JS at all, styling is totally up to the client.

So like I said, you've basically just described gemini :)

<comment><USER17> The difference is you can't just open Gemini protocol in the browser, so you're limiting audience of your resource to a very minority. That's what I want to highlight: something that is compatible with modern web, yet simpler so alternative browsers could be implemented.

<comment><USER18> You actually _can_ open Gemini in a web browser, using a proxy like proxy.vulpes.one or portal.mozz.us. I tried to write a Firefox extension a la OverbiteWX for gemini to automatically redirect links, but my JS-fu isn't strong enough.

</comment></comment></comment></comment><comment><USER19> I think calling gemini an _alternative_ to the web has a very limited view of the web. It takes an idea someone has of what the web should be: a set of text documents. That's a very small subset of the web, not just of today.

Building separate protocols for all the various use-cases of the web would be interesting, but would still need some interconnection. But I'm not convinced that has many advantages besides not being accidentally linked to a websited of the "Old web." A problem that could be reduced by a browser extension that strictly blocks any external urls and javascript.

<comment><USER20> The separate protocol for everything is essentially what things were like prior to about 1994.

There was a protocol for searching documents, a protocol for looking up someone's email, it was all partitioned out.

The web was seen as just another fish in the pond.

After the web became big, these things still lasted for a while

However spam and crooks changed it all. Usenet became useless, DNS full domain lookups (you used to be able to get a list of all the subdomains of a domain through the command line and you could just browse then out of curiosity), using whois for email (you could just query for a name and get an email address over whois), it's all gone because there's too many snakes trying to scam people and flood the network.

Things used to be much better tools but it turns out they were too good and had no defenses. The dream of everybody connecting has sort of been retracted a bit. RMS, TBL, Torvalds, I could just send them an email in the 90s and they'd respond, it was pretty remarkable.

It's not the case any more. Not even minor players in history (such as an author from a 25 year old book) respond to my questions. People just don't do that anymore.

Spam, harassment, criminals, ill will, this all has to be a big priority if we want to try it again.

The future should be the dreams of our better angels, building better tomorrows...

<comment><USER21> > RMS, TBL, Torvalds, I could just send them an email in the 90s and they'd > respond, it was pretty remarkable.

I don't think this stopped just because of spam, harassment, or other bad behavior. A big part of it is just community size. When the community of internet users was smaller, you could interact with everyone who reached out in a reasonable amount of time. As it got bigger, that is no longer possible because of the sheer number of people.

</comment></comment></comment><comment><USER22> The web is partly broken due to the sheer expanse of it. The author of the article alludes to how they enjoys looking at the aggregator, and notes they can always find something interesting. If Gemini ever became as popular as the web, that would stop being true.

So the selling point of Gemini is that by staying rudimentary, it can limit it's appeal, and subsequently stay unpopular enough to be more like "The Old Web". I think that's worth noting, because you could get trapped into thinking this is a technology problem, but it's really a people problem.

<comment><USER23> You have a very good point.

However, Gemini does not exist in a vacuum. The web will be there. There will be social media platforms, multimedia, awesome webapps and all that. And Gemini is just text.

When you have the choice between easily consumable infinite multimedia and _just text_ , you only pick the latter when you really care about the quality of text content. It's not sexy so all the spammers, content marketers and ego boosters have nothing to gain on Gemini. And so there can be this esoteric little corner of the internet, with down-to-earth text content written by ordinary people.

</comment></comment><comment><USER24> This is hard to understand for someone not familiar with Gopher, but I'm interested in how menus are handled.

I've always wished browsers handle site menus in their chrome, so that the document can be focused on content not navigation. It's the browsers job!

For a while Opera supported these related links in the head for some pages but the dev was unable to add their own, it was limited to a small number of standard items such as Index. These were shown in a browser toolbar.

Nonstandard navigation have always been a point of friction for users as it precludes universal access by having to relearn how each site works.

<comment> vertex-four Gemini documents can contain lines that are text or lines that are links - <USER2> a menu looks like a list of links, one per line.

</comment></comment><comment><USER25> I guess I don't understand this:

How is a network protocol proof against being used to transport CSS files? Does the network stack inspect what you're shipping and ensure you're only sending 100% Pure Plain Text?

> The Gemini transport protocol is unsuitable for the transfer of large files, > since it misses many features that protocols such as FTP or HTTP use to > recover from network instability.

Isn't that TCP's job? Is this person saying Gemini doesn't use TCP?

Finally:

> Now, what does Gemini currently have to offer? The best way to find out is > to head over to the official site: gemini.circumlunar.space in your Gemini > browser.

Back in the Gopher days, my "Gemini browser" would be my Web browser. That was one of the reasons Web browsers took off: You could use them to access all of the information on the Internet, including the WWW, Gopher, Usenet, and Email. Only more recently did Mozilla morph from the Netscape Communicator software suite into the slimmed-down Firefox browser without email, spinning off Thunderbird in the process, and only _much_ later did Firefox drop Gopher support from the core binary.

<comment><USER26> > Isn't that TCP's job? Is this person saying Gemini doesn't use TCP?

maybe he's talking about higher level features, like the possibility to restart a download from a certain point, without redownloading the initial part? haven't used this since dialup days, though

<comment><USER27> I suspect that it is this partial download that they are talking about.

That said, I can't tell whether or not I've used it recently. I know I don't use it when I play with personal projects, but I don't know what other sites do because I rarely have a console pulled up in my browser when I'm just using it, rather than developing.

<comment><USER28> Its often used with bulk file downloads (e.g. curl a multi-gb file while transfering between wifi networks), as well as video streaming sometimes (buffering)

</comment></comment></comment></comment><comment><USER29> I foresee a familiar cycle playing out:

1\. Gemini is great, no spam and commercial crap

2\. Someone realises it would be great to have simple inline images, and makes a cool client that supports "gemini+img" syntax that they make up. The syntax gracefully degrades, so you can use it in your docs even if your users aren't using the new browser!

3\. Protocol is technically text-only but in reality everyone uses img-enabled browser

4\. Repeat with basic styling, then simple scripts. Eventually authors rely on more and more "optional" features and syntax extensions, and we end up with a similar feature set to what we have today.

5\. Advertisers move in as Gemini gains mainstream adoption, and we're back to www

</comment><comment><USER30> One of the things I find refreshing about Gemini is there is no standard scripting language in there and the implementations vary wildly on the client side from Rust to Lua to Python to Go as well as the server-side. It made me realize perhaps browser technology for the Web got locked into specific domain-centric technologies which have held it back. There is so much C/C++ required for JavascriptCore and friends in a modern browser there is only one real choice to code in. Mozilla has made great advancements with Rust in Firefox but still a long ways off from a total conversion. It's not that its not possible but if you want to tap into the work which has already been done in JavascriptCore or other technologies you certainly cannot just pick your own backend or language. Gemini's efforts on the other hand are being brought up in parallel and in the open so that is a major strength that the ecosystem is already much more broad from the beginning. Building a modern browser from source nowadays is an intensive process on a single mid-range workstation just due to the fact much of the extra functionality is compulsory and not opt-in. Many of these modules were meant to be pluggable but somewhere along the way they became coupled dependencies of each other. A good example is Electron where in theory it should be just the things you need and a subset of a browser where applicable but instead you need the whole browser engine every single time.

</comment><comment> _-___________-_ I've spent the last few hours browsing Gemini, and it feels more like the early web than anything I've experienced in the decades since. I love it.

</comment><comment><USER31> Here we go again. Solving social problems with technical staff.

<comment><USER32> Protocols are actually part of the glue between technical and social domains.

</comment></comment><comment><USER33> Why not just set up a site that only allows markdown with plain pages and get all the benefits you list without a new protocol?

<comment> DC-3 Gemini's creator solderpunk wrote about this here [1].

[1] gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/why-not- just-use-a-subset-of-http-and-html.gmi

<comment><USER34> I'm sure that would be an interesting read, is it available on a usable protocol?

<comment> vertex-four You can read it with a Gemini browser, along with a lot of other content! There's a list of clients at [https://gemini.circumlunar.space/clients.html](https://gemini.circumlunar.space/clients.html), along with SSH and HTTP bridges.

<comment><USER34> Aha nice one!

I'm still not sold on it (you're allowed to do websites without js/css!), but the effort and skill involved is commendable

<comment><USER35> True, but before you visit that website, you don't know anything about how the site was implemented, or what JS is going to run, or whethere there will be a big autoplay video advert, etc.

When you visit a gemini URL, you know how it's going to serve you a limited capability, text based document, styled according to your own rules.

</comment></comment></comment></comment></comment></comment><comment><USER36> Gemini is awesome and fun. Sure, it's kind of a toy, but's that's kind of the point.

Go read the mailing list. Implement a client in your favorite language, or that weird language you've been wanting to try...

Write a blog, or some fan fiction, or a screed or some poetry. (There's a choose-your-own-adventure you can play.)

Have fun with it.

</comment><comment> gray_-_wolf One thing I don't agree with the protocol (on technical level) is that absent of content-length or of some end-of-message marker.

> The server closes the connection after the final byte, there is no "end of > response" signal like gopher's lonely dot.

This just seems like a bad idea, especially if one is on shitty connection.

<comment><USER37> I share your concern.

Since the response body is not encoded, there's no safe end-of-response marker byte(s) to use.

So content-length seems like the way to go. But knowing content-length ahead of time is difficult for dynamically generated content (CGI is supported after all), so they also need something similar to HTTP chunked encoding, which does complicate things _a little_.

I understand that keeping the Gemini _client_ simple to implement is one of their design goals, but I don't think the same is true for the Gemini _server_. So I hope that they would consider adding these to the protocol. They could probably stuff the content-length or the word "chunked" in the <META> string.

<comment> gray_-_wolf But since they explicitely state that it is not suitable for _large_ content, server could just cache it until it has it all. Most clients will likely wait for whole response anyway.

I feel like that would strike reasonable balance. Client are still simple (arguably _more_ simple since they don't have to guess if they got everything) and the protocol is still trivial. For dynamic content, it would increase time-to-first-byte and ram usage on server, but both imho would not be an issue for the type of content gemini aims for.

<comment><USER37> I agree that always sending content-length would be ideal, if it didn't come with the extra work and costs on the server that you mentioned.

Chunked encoding is simple enough to implement, avoids all those issues, and would allow a Gemini server to serve more requests faster given the same resources, or to run on hardware with more limited resources such as embedded. So I think it's well worth the _slight_ cost in simplicity.

</comment></comment></comment></comment><comment><USER38> I wrote an ncurses-based gemini and gopher client a while ago: [https://github.com/jansc/ncgopher](https://github.com/jansc/ncgopher) I really like the gemini protocol because of its simplicity and its text-based nature. Spending most days in a terminal, text consumption is so much easier with a gemini client then e.g. lynx for webpages (which won't work 99% of the time).

</comment><comment><USER39> I've been thinking about something similar for a while, but kind of disagree with Gemini's scope and implementation. I think that the lack of inline images is too limiting. In my opinion, a good replacement for the WWW should have the following features:

\- ToS that strictly prohibits commercial use and advertising. We have the WWW for that, no need to duplicate it.

\- Uses HTTPS or something similar. This allows use of efficient servers like Nginx.

\- Based on a virtual display with fixed dimensions and orientations, 2-3 aspect ratios and vertical/horizontal orientation. Fixed virtual pixel solution. Every page is fixed in size and in the length of unicode text it can display.

\- Uses a structured document format with a limited number of logical tags. The client displays the page as it likes (no styling directives in the document markup). Every page written in this format is compiled into an efficient and compressed binary representation for transmission.

\- Limited number of links, overlays, and images per page. Input fields with validation should be allowed. Inline images and movies are limited in size.

I'm planning to implement something like this in my forthcoming virtual Lisp machine (z3s5.com), though it's going to be a bit less general and probably not be based on HTTPS.

</comment><comment><USER40> Last time this was posted I started working on a Gemini client:

[https://github.com/electronstudio/2face](https://github.com/electronstudio/2face)

Currently it's TUI, but will add GUI eventually. It's fun to have a protocol small enough you can implement it yourself, but I currently have a weird bug where some Gemini servers work and others don't because they don't seem to follow the SSL spec.

</comment><comment><USER41> No mention of JS; not even a Gemini server in Node[0]. Finally a sane place to hang out! Kidding, but only half. The 'everything must be done in JS' is fairly annoying imho.

[0][https://portal.mozz.us/gemini/gemini.circumlunar.space/softw...](https://portal.mozz.us/gemini/gemini.circumlunar.space/software/)

<comment><AUTHOR> A Gemini implementation in JS: [https://github.com/derhuerst/gemini](https://github.com/derhuerst/gemini)

<comment><USER41> Great, doesn't disappoint; includes horrible emoji's :]

<comment><AUTHOR> Emoji's are part of Unicode. Not bloat.

<comment><USER41> I wasn't thinking of bloat; it just looks unprofessional, in my opinion, and it is also very related to people who work with js almost exclusively.

</comment></comment></comment></comment></comment><comment><USER42> I see a lot of comments expressing that all we need is markdown plus this or that little bit. I think that's unreasonable. It might suit Joe developer just fine for reading blogs and news, but the world benefits enormously from the ability to build complex software applications at low cost. Imagine the alternative: Welcome to Mario's Pizza - you can order right from your own computer after we mail a disc* to your house (*requires Windows 8 or newer)!

Also, some of the CSS and JS hatred is piffle. Publishers absolutely abuse these languages and it gets pretty bad on news websites especially. But I do not find that most or even many of the sites I visit perform badly on my hardware (2016 iPhone SE and a 2017 MBP). They work fine. Moreover, I appreciate nicely designed and competently implemented experiences on the modern web.

I have no interest in trading the modern web - warts and all - for some spartan plaintext utopia.

</comment><comment><USER43> I think this might be _too_ simple. In particular, the absence of a way for the client to specify a desired language or supported mime types, query strings as the only way for the client to send data (what about uploads? Or non-idempotentent requests like registration?),and the absence of compression all seem to go a little too far to me (compression could be done using a parameter to the mime type).

And really,why replace http? The complaint seems to be mostly with html, so why not just makr a gemini text format,build some browsers that use that as the default instead of html and specify semantics for how tls works, like custom status codes to request a client certificate and recommend TOFU certificate trust. And maybe specify certain headers that shouldn't be used, like cookie.

<comment><AUTHOR> The intention isn't to replace HTTP entirely. By using an incompatible protocol, a hard line is drawn.

</comment></comment><comment><USER44> The web has become much more than a protocol for reading documents: controls that communicate both ways with the server so that they can be also updated in real time is a really useful aspect that won't make them go away anytime soon. I rather wonder if the browser is the best interface for that, or if html is the best protocol for that use. The answer would probably be obvious: "one software doing all is cheaper to produce and maintain than two or three doing each one its own business (and we can still blame the user hardware for the added slowness)."

</comment><comment><USER45> I still don't understand the point of this project.

I mean QUIC is here, waiting for us.

Why throwing away 30 years of HTTP ideas . If images and cookies are to be forbid that should be made from the web developper decision.

Choosing Gemini is like accepting restriction by law. I feel like this is old behaviour, that confidence and responsability is the way forward.

In a way Gemini could have been published by writer of European Union , North Korea or Soviet Union laws, I can't belive this is a US products, as it contains too much to liberty constrain ;)

<comment><USER46> > If images and cookies are to be forbid that should be made from the web > developper decision.

Unfortunately even today that's not 100% under your control. I don't have to accept cookies nor load images from your site with the proper settings or browser.

You seem to be forgetting HTTP is a user-initiated protocol and while a lot of it is hidden behind Javascript and common browser features, ultimately it's the user agent that initiates everything. You as a web developer can only control the files on your webserver, put cookies in headers (which the user agent has to send back to you) and possibly take advantage of some other Javascript features like DOM storage (which I can turn off).

I'm 100% on board with Gemini being a 'liberty constrain' for those who put information online - honestly it's not necessary for remote systems to be executing code on my system just to display text. Yes, you can't monetize it as easily. That's a feature, not a bug, for a user like me.

</comment></comment><comment><USER47> How is introducing yet another new technology, incompatible with what everyone else is using, any better than just creating a minimalist static HTML website?

<comment><USER48> Because the problem is the technology everyone else is using

The issue isn't bloated websites as much as the web itself.

<comment><USER47> How is the issue not bloated websites? You can easily create a text only website in HTML which is compatible with every existing internet capable device. All technology can be misused, it isn't necessarily a problem with the underlying technology. By introducing yet more standards and technologies, you end up creating bloat and fragmentation of a different kind.

<comment><USER49> There is also an allure of having a client that will never run some weird god- know-what-doing javascript code.

Of course you can just disable javascript in your HTTP browser. But as the author states, it's easier to write a completely new client than to disable all the bloat in e.g. firefox.

<comment><USER47> Agreed, but like I've said elsewhere the effort would be better spent modifying an existing browser to be lightweight. That would gain more widespread adoption than a whole new client-server protocol. You'd also gain the benefit of better interoperability with screen readers and such like.

<comment> vertex-four Nobody involved in Gemini wants "widespread adoption", because that inevitably means big commercial organisations coming into the space where right now they're having a lovely time building a community.

Screen readers handle Gemini just fine - one of the clients I've tried outputs text and buttons in a GTK window, another literally just outputs text into a terminal and takes command line input, if a screenreader couldn't handle that I'd be horrified. The format is paragraph-based, there's very little styling, no guessing at what the main content on a page is.

</comment></comment></comment></comment></comment></comment><comment><USER50> I've recently switched from Markdown to ASCIIDoc ... the article makes it sound like the browser is optimized for text but isn't it really the server that's rendering the text that's sent? In this case, I like the idea of minimal styling mostly because my eyes are getting old but as others have stated, why isn't this specification a small subset of the existing internet?

</comment><comment><USER51> > Gemini, being a recent protocol, mandates the use of TLS. There is no > unencrypted version of Gemini available.

Mandating the reliance on third parties in the protocol itself does not seem to be a great choice. If I have a simple webpage which I use as a daily diary, why should I go to the trouble of asking a random third party to provide me with a certificate?

<comment> vertex-four Gemini does SSH-style TOFU, you don't ask a third party for the certificate. From the spec: "Clients can validate TLS connections however they like (including not at all) but the strongly RECOMMENDED approach is to implement a lightweight "TOFU" certificate-pinning system which treats self-signed certificates as first- class citizens."

</comment></comment><comment><USER52> I was just talking to someone about an idea like this. I even thought about making a Gtk+ widget for it, having no idea this existed. I really like the idea of viewers being the ones who decide presentation and something like Markdown (with images and videos) could work well for that. I'm not sure why we'd need a new protocol for it though, other than to escape the web.

</comment><comment><USER53> It's like wearing clothing.

If I wear a polo and dress pants, and I'm on the train at 8am, I'm going to white collar work. If I wear jeans at the same time and have my partner with me, I'm a middle class, middle aged, probably-parent on personal business that could probably be described as "running an errand". If I'm a 42 year old man wearing bright purple halter top, with black lipstick and combat boots on the train at 8am--you don't know me! Where the hell am I going? How am I living? You don't understand how to talk to me, so don't bother unless you are a 27 year old woman with red eye liner, green air, blue lipstick and a brady bunch t-shirt on! We wouldn't understand each other!

Elaborate protocol jokes aside, it's an apt analogy. It works--for some people, some of the time. They are dreamers living life waiting for a tomorrow that may never come, but the cause gives them their identity. Chances are that Bob and Linda still have to straighten up on Monday mornings and assimilate to the general protocol. But that's the world we live in, is it not?

I like it. I don't like to deal with it when I'm at the bank or the brokerage, but Friday night, it's alright with me.

I don't begrudge their them identities. However, it's a weak, unopinionated protocol. No inline images? Just because you support them doesn't mean they don't exist.

Users will have their inline images, and they will build clients, and the protocol will be defined. If not by you, then by someone else.

That _is_ the story of the modern web, and that is, funny enough, how we got here.

Nostalgia isn't productive. A new protocol isn't insurmountable, but it has to be native to the time you are living in. You don't need to necessarily inline videos and graphics, but you need to define how these should be handled, or at the very least, the boundaries of the protocol. Waxing whimsically at people creating readers to handle inline images in an ad hoc way... lol, why? Why are they doing this?! They were just bemoaning the current state of the web! My god, have some foresight!

Make a protocol, make a browser, define the boundaries and perhaps adjacent protocols, set your browser roadmap accordingly. Stop when you feel the coverage of the desired space is sufficient. If that's text-only, fine. But you must have answers to how an image or video should be served to the good people of this community.

<comment><USER54> The thing is, when the web grew up, there was no not-web. Gemini occupies a swim lane, and if you want more, even a gemini page can link to a web page to do the heavy lifting of the modern web. So aside from making the bear dance, there's little interesting in forcing inline images. It will be not that the bear dances well, but that it dances at all, right? There is definitely a part of the Gemini community--from what I've seen--that is really excited to see the http 0.9 grow up that they missed the first time. But so far cooler heads are using their persuasion to knock most of that urge down. What will save gemini from turning into the modern web is that the modern web will be _right there the whole time_. I guess the perverse server and client could collude to deform the gemini protocol to look like http, but why? "=> [http://www.mysite/recipe-with-inline-images/](http://www.mysite/recipe-with- inline-images/) Step by step recipes " in your .gmi file would do this so much better.

</comment></comment><comment><USER55> If anyone is interested I have an idea along these lines under runvnc/noscriptweb on GitHub. [https://github.com/runvnc/noscriptweb](https://github.com/runvnc/noscriptweb)

Its probably going to stay as just an idea because other projects have priority.

</comment><comment><USER56> What if the problem statement (what is something like this trying to solve) is:

1\. No tracking beyond what the server gets via standard logging 2\. Document styling control in the hands of the user agent 3\. Navigation control in the hands of the user agent 4\. Compatibility with existing web browsers would be a bonus

Points 2 and 3 imply some kind of semantically-clear markup. Would definitely want to think of forward/backward compatibility (something the web has been fairly good at).

Point 1 means no cookies, likely nothing like JS, images need to come from the same server (either packaged in the initial request or forced to come from the same host).

Point 4 is a nice to have and may be possible if this is built on a subset of HTML and HTTP. One possibility is that if the server receives a request that looks like it's coming from a standard browser, it can serve up the page with some JS and CSS that fill in the stuff that would normally be done by the user agent.

IMHO, something built on a stack that looks like that would be a better fit for 2020 than something based off of Gopher's approach.

</comment><comment><USER57> Could most of this not be achieved by adding a markdown mode to Firefox? Whenever text/markdown content type is received it would display it using a stylesheet set by the user. It could skip cookies, etc in this mode to reduce, if not completely eliminate, tracking.

<comment><USER54> I'm waiting for folks to look at gemini, see only part of what they want, and make markdown-native web protocol, a wiki protocol, basically. I think that would be very cool, and it is what drew me to gemini before I figured out it was really super-gopher. Like what if there was a mediawiki protocol? You'd have your tables! Anyway, there's no one stopping anybody for trying to make that happen. The true interwiki promised in the days of c2, could actually happen!... if some people want to make it happen.

</comment></comment><comment><USER58> A better approach to Gemini would be to create a UGC web app that allows people to create simple, text-only, markdown-enabled content that does not track users. And I think plenty of those exist already. It would be the circa 2004 era blogging platforms.

<comment><USER59> My understanding of Gemini's raison d'être is that the JavaScript-laden app- filled WWW is an anti-feature so doing anything with Gemini and web apps would be contradictory.

Probably won't stop someone from trying.

<comment><USER60> Well, there's nothing stopping you from serving HTML/CSS/JS web apps over the Gemini protocol.

(Nothing stopping you from building a browser that handles gemini format documents and does special things with JS links, either, though to avoid accidental execution issues you would probably need to extend the format to distinguish "links I want to execute" from other links.)

<comment><USER59> All of that goes without saying, so the only real question is whether Gemini can resist the scourge of the modern web.

<comment><USER54> I'd like to say again that by competing with the modern web to do things that gemini isn't good at, gemini gets to _lose_ those contests, and this should limit the success of efforts to to make dancing bears out of gemini.

</comment></comment></comment></comment></comment><comment><USER61> If you want to show circuit diagrams, have you considered the Parallax Propeller font?

</comment><comment><USER62> This would be interesting for a terminal based web alternative. A practical use would be something like O'Reilly's Safari Books Online.

The author mentions that fancy Gemini reader apps could allow linking to images, since that some terminals allow images to be displayed[1] that would fit nicely too.

Why not just use text based websites and something like w3m? Well it's hard to tell when opening a link in the terminal will be useful and when it would be better to open the link in a "real" browser like Firefox.

e.g. after a git push to github I'm provided with a link to create a PR. I really when I click that link I really want it to open in Firefox.

[1] Off the top of my head Kitty and iTerm2 both allow image display from apps such as the ranger file manager.

</comment><comment><USER63> I agree with some of your thoughts and thank you for putting this together. In order for this to be successful (and I truly wish it becomes so; I very much miss the internet before the web sometimes), it needs to work side by side with http. By that, I mean your web browser needs to become a 'dual' browser and be able to switch back and forth between the two seamlessly and documents built for the two protocols need to be able to link back and forth between the two protocols. If a browser can do that, my question then becomes, is it even worth it or fo we just need more web sites out there that focus on their text and their usability?

<comment><USER54> there are gateways if all you want is to peek into gemini web, as several people have noted. How does that ruin anything?

</comment></comment><comment><USER55> I just wish they had not insisted on TLS and closing connections. It defeats the purpose to me because you are going to be delayed constantly by new TLS startups.

<comment><USER10> If the expected use case is to spend a long time reading a document with no images, is that much of an issue?

</comment></comment><comment><USER64> > a brutally simple alternative to the web

Yip and gemini's markup is so simple that it is useless for me. :-(

Combining a restricted HTML maybe with 1-file-only limit (use data url for insets) with gemini's protocol could make sense for me.

"rHTML" like PDF, all in one file, maybe a bit JS for rendering maths, but maybe there are other/better ways to do it (no maths in PICs please!).

Or brutally different? Distribute DVIs over gemini://?

I like the 1-file-only style in the dimension gemini and apart from not yet having automated images to data-url-conversion, ... _sigh_ ...my image-less HTML stuff already is 1-file-only.

</comment><comment><USER65> This seems to be RSS with extra server setup but no images.

</comment><comment><USER66> Hey, no tables, even basic? If this protocol is to be like 'library', instead of a 'mall', it definitely should have tables.

<comment><AUTHOR> Even Markdown hasn't sorted this out yet though.

CommonMark currently has no tables, it's up to other markdown dialects to add it.

Related discussion: [https://talk.commonmark.org/t/tables-in-pure- markdown/81](https://talk.commonmark.org/t/tables-in-pure-markdown/81)

<comment><USER66> Well, html had it sorted out three decades ago...

</comment></comment></comment><comment><USER67> Are there other projects similar to Gemini? Of these projects, which is most likely to still exist 5 years from now?

<comment><USER54> I don't know, are there? I don't know, do you?

</comment></comment><comment><USER61> Would this help usability over a slow link (let's say a 9600bps radio modem), or is Gopher better for that purpose?

<comment><USER9> Gopher will be faster by nature of gemini using TLS. However, gopher is inherently less secure than gemini. If you are wanting the TLS, gemini _should_ load your document faster than the https (even with minimal headers included for the https version, there is still more header overhead to just make the request and there is a lot more header overhead in most responses).

</comment></comment><comment><USER68> > although Gemini lacks in-line images, you can still use in-line links to > images

this is telling. not only it's inconvenient, but claiming link to images are good enough for blog and recipe pages makes me think the audiences are completely misunderstood.

weird because text driven interface like airline reservations still exist and porting them on a common protocol would provide immediate tangible benefits today without the backward thinking about media

<comment><USER9> I do not think it is inconvenient at all, it is just different that what people have come to expect.

<comment><USER68> inline illustrations predate internet by hundreds years. imagine a child book but all the images are in the appendix.

it is the definition of inconvenient. it's usable, but it's not like inline media is a modern or even contemporary concept.

</comment></comment></comment><comment><USER69> Call me a cynic, but isn't Gemini like HTTP before it grew any of the features that made HTTP useful?

I don't get it.

<comment><USER70> You're pretty much correct. Even in this thread there are people saying "oh the Gemini browser can decide whether to render inline images", which is exactly what Mosaic did.

The main advantage this has is that it will not get popular enough to experience the scope creep that the web did so will probably remain relatively pure.

</comment></comment><comment><USER71> Pity the client scripting thing is absent.

Then again, which script would you use?

The overall web itself is going WASM for a lot of projects. Pure javscript that is actually readable isn't exactly common now either as more frameworks build multiple layers on top.

I see this as an interesting step sideways. Less is more and all that. Perhaps check in 2 years from now and see what major shifts it caused.

</comment><comment><USER72> What network instability recovery features are there in http and ftp? I thought that was all in tcp?

<comment><USER73> The author is probably thinking about HTTP partial/range requests ("resumable downloads"); they can recover even if the TCP connection is closed.

<comment><USER72> That makes sense. You don't get this in ftp thou right?

</comment></comment></comment><comment><USER74> This seems like a fair enough idea, except that there should be provision for "rich content boxes" that might contain images, forms, WebGL or other things that Gemini intentionally forgoes.

Having a "web browser" that can't do interactive content at all (no, server- side CGI doesn't count) is a non-starter in 2020. What if I need an interactive chart?

<comment><USER54> You could make a regular http web page for your interactive chart...

</comment></comment><comment><USER28> This seems almost identical to http/0.9, and early versions of html

Soo umm. Just use netscape 2.0 (+modern TLS)

<comment><AUTHOR> If one were after a minimalist browser they would be better of with something like NetSurf. But that puts it at odds with 90% of the current web.

Everything I find on Gemini will be compatible with my browser.

</comment></comment><comment><USER75> Regarding the quote at the end of the blog post:

      "When I picture it in my head I think of the early web as more of a library.
      Over time it has transitioned into a shopping mall."
      - chris_f (Hacker News comments)

There are still books in a shopping mall. You have to know where to look and not get distracted at every corner, though.

<comment><USER76> You're confusing a library with a bookstore. Libraries are repositories of information that one can browse.

</comment></comment><comment><USER77> Can Gemini be used for something like HN? e.g. nested threads? (or that's basically Usenet?)

<comment><USER18> There's a list of mirrored services here: [https://portal.mozz.us/gemini/gempaper.strangled.net/mirrorl...](https://portal.mozz.us/gemini/gempaper.strangled.net/mirrorlist/) (http link) gemini://gempaper.strangled.net/mirrorlist/ (gemini link)

I think it gets updated semiregularly.

<comment><AUTHOR> Good link thanks!

Added to article.

</comment></comment></comment><comment><USER78> Just make a regular old HTTP(S) site. You can host plain text files and they'll work just fine in any modern browser. Or you can use a subset of HTML and CSS for accessibilty reasons (screen readers, etc).

</comment><comment><USER79> Is gemini featureful enough to build a sign-up form where I could pay for stuff? I ask only because it seems like the commitment of commercial players seems like a prerequisite for the success of stuff like this.

<comment><USER9> The almost full and complete point of this is to REMOVE the ability of "commercial players" from having a role or interest in the platform at all. They have already ruined the web and society as a whole (but that gets into a whole argument for/against capitalism... take a wild guess where I stand).

<comment><USER79> I'm not a great fan of capitalism, but really my favourite thing about it is the seeming inability of commercial players to surveil. I don't like the idea of building in the price of content as being nothing - I want to donate to bloggers etc.

A way around this is to mix gemini and http in a single browser. Only one can be rendered on a page, but they can link to one another, with a warning when you transition between the two. So blogs could have a donate button that just hits paypal etc.

</comment></comment></comment><comment><USER80> I'd find it an effort to standardize text/terminal-friendly accessible HTML+CSS much more appealing. And the TLS requirement seems to make it harder to get started for pure "fun" projects.

<comment><USER81> One of the goals of the project seems to eliminate all of the ways the current web can violate user's privacy. Without encryption, I dont think Gemini could claim to be better.

</comment></comment><comment><USER82> > Gemini, being a recent protocol, mandates the use of TLS.

and also

> it misses many features that protocols such as FTP or HTTP use to recover > from network instability

What? These statements are at totally different levels of the OSI model.

<comment><USER83> About TLS: it means the spec requires Gemini to be encapsulated in TLS; the same way RFC 2616 recommends HTTP be encapsulated in both TCP and IP ("HTTP communication usually takes place over TCP/IP connections"). Yes, technically they are abstraction violations, but they are commonplace for network protocols.

about network instability: it doesn't refer to congestion and packet loss handling in TCP, but to the "Range" feature of HTTP, which allows downloading only a subset of a file, to resume an interrupted TCP connection.

</comment></comment><comment><USER84> Won't work. As soon as it gains any traction hackers/crackers will figure out how to exploit people. Marketers will figure out how to optimise it to sell you crap you don't need. Left wing/ Right wing censors and moderators will silence at least a portion of the users if not the whole project because "reasons". Oh yeah, the government will also be there to ensure that you can't do anything without them knowing about it.

Honestly the web could be great with the technologies that are out now. At this very moment. But it isn't.

</comment><comment><USER85> How the web today is how it has evolved. I think it is hard to change the flow of water.

I mean, for example, if Gemini evolved, it would still somehow be what the web became!

<comment><USER19> I feel similar. Projects like gemini work, because they are niche, not despite it. If it became mainstream similar forces that drive the web to what it is woule take hold.

<comment><USER86> Yeah, designers would hack around the limitations until the hacks become official (against the original protocol inventors' intent, if necessary), because every company wants to control the experience of their content to an unreasonable degree. I recently turned off the "Allow pages to choose their own fonts" setting in Firefox, and it's refreshing to read text in O(1) rather than O(N) fonts. Now if only similar tweaks were as easy to apply to web forms, menus etc.

</comment></comment></comment><comment><USER87> The linked site is perfectly fine on the Web.

</comment><comment><USER88> sounds like another gimmick but okay

</comment><comment><USER89> > <URL> is a UTF-8 encoded absolute URL, of maximum length 1024 bytes.

This is never a good idea.

</comment><comment><USER90> Breaking: Sacred texts from 680 B.C. are a simple alternative to high-budget Hollywood movies

JK, interesting read but the idealism is stronggg.

</comment><comment><USER91> Meanwhile, the other post at the top of HN is a visual explanation of sphere eversion [1] that relies on the web being a system for distributing _sandboxed applications_, and so would be completely impossible in this Gemini system.

[1] [https://rreusser.github.io/explorations/sphere- eversion/](https://rreusser.github.io/explorations/sphere-eversion/)

</comment><comment><USER92> Don't get this fad of hate to be honest. The web, fucked as it is, works. Obviously there's a load of cruft because humans will try and exploit any system, but if our only problems are our Macbooks spinning their fans up a bit, it's a beef that really only irks purists. Day to day, talking to people, people don't bitch about the web other than about invasive adverts.

Frankly I think a lot of commentary stems from backend people being annoyed that frontend people earn a bunch of money for work they deem insignificant.

</comment><comment><USER93> > I have really come to hate the World Wide Web. It is bloated at every level!

I have to admit that this opening statement almost stopped me reading the rest of the article. Which is a pity, because Gemini does sound like an interesting endeavour. I went searching (via the bloated World Wide Web) and found the Gemini FAQ page ([https://gemini.circumlunar.space/docs/faq.html](https://gemini.circumlunar.space/docs/faq.html)) which (in my opinion) makes a much better argument for considering this alternative approach to delivering content over the wire.

> I could totally see Gemini being used as an alternative particularly for the > non-comerical individuals who use text as a primary medium. Blogs, poems, > recepies, tutorials are perfect for the Gemini format.

The one big thought I had - as a content developer (I write poems: I will never apologise for this) - as I read through the FAQ was: "Yet another distribution channel to maintain" ... because Gemini reminds me (probably unfairly) of WAP and its Wireless Markup Language. Back in the day I was very keen to inflict my poems on everybody in the world: I posted them on Usenet (mainly RAP), various web-based bulletin boards, a Blogger Blog (with a blogroll!) and, of course, my own poetry website. Reaching out to a mobile- centred audience was the next logical step. But the mechanics of the effort defeated me, and I soon grew to truly detest WML and its stupid limitations.

I suppose, in 2020, adding another communications channel to my current website's toolchain should be a lot easier ... but I don't want to do the work. If the people around Gemini can get more passionate content creators to do the necessary work, then maybe it will have an interesting/exciting future?

<comment> vertex-four If you're seeing Gemini as a "distribution channel", it's... probably not really for you? What's there, right now, is a community of people, sharing ideas and talking to each other. Pretty much all the content there was made to be shared with that community. And I very much have the impression they'd like to keep it that way as long as possible.

<comment><USER93> I'm glad they're building Gemini - a monoculture of anything is an unhealthy environment and projects like Gemini can help break up our current HTML/CSS/JS monoculture. But it is also a distribution channel: a method for content creators to get their content out to content consumers.

At the moment the 'coolest' way for poets to share their poems with their readers is through Instagram[1]. I've tried it; I don't like it. But I don't resent the poets who have made the channel work for them - anything that gets people reading more poems is a Win in my book!

[1] - [https://www.vogue.co.uk/article/best-poets-on- instagram](https://www.vogue.co.uk/article/best-poets-on-instagram)</comment></comment></comment>


Self-contained linux applications - <AUTHOR> http://flatpak.org/ <comment><USER2> interesting, this is by the way xdg-app rename for people who were wondering</comment>


Ask HN: What's the best javascript charting library?  - <AUTHOR>

I know this question has been asked several times on HN.
http://news.ycombinator.com/item?id=1847515 http://news.ycombinator.com/item?id=854926 http://news.ycombinator.com/item?id=2764708
But since all the posts are almost 2-3 years old, I'd like to ask it again, as there must have been major changes in the technologies and libraries since then.
Requirements: -Support as many chart types as possible. -Cross browser compatibility. -Rich and interactive
Thanks. <comment><USER2> These are the most important once (had the same question 2 days ago) :

<https://developers.google.com/chart/> (free) <http://g.raphaeljs.com/> (free) <http://www.flotcharts.org/> (free) <http://www.jqplot.com/> (free) <http://www.highcharts.com/> (paid for commercial use)

</comment><comment><USER3> Google charts ([https://google- developers.appspot.com/chart/interactive/docs...](https://google- developers.appspot.com/chart/interactive/docs/gallery)), Flot (<http://www.flotcharts.org/>) are some of the popular options

</comment><comment><USER4> I would recommend Highcharts - <http://www.highcharts.com/>. Their api is great, really simple to use with a shit load of graph options.</comment>


Ask HN: Wordpress or alternatives?  Security? - <AUTHOR> Hi HN long time lurker 1st time poster.
Over and over the question of "should we use Wordpress" comes up in my life working with startups.  It's easy for everyone to work with, lots of themes, SEO works well. But security is a constant headache.
What do people use?  I've used Jekyll and Laravel in the past, but I need marketing people to be able to write and publish posts and edit pages.
Is there a good alternative? If the answer is "just use wordpress", any novel approaches for keeping it secure?  I'm checking out ManageWP for auto updates, and the possibility of doing private WP and publishing to static as well.
Thanks! <comment><USER2> I love WordPress but you're right... it can be a PITA when it comes to security, not to mention a host of other issues.

I, too, have been looking for alternatives for certain projects, and while I can't specifically recommend any yet, as far as keeping WordPress secure goes I've always found that folks who consistently run into issues always seem to either choose poorly when it comes to basic security (i.e. crappy passwords, only ever using the Admin user, etc.) OR they haven't done any basic WordPress security hardening.

WordPress has a decent intro to making itself more secure here: [https://codex.wordpress.org/Hardening_WordPress](https://codex.wordpress.org/Hardening_WordPress), but if you just look up "wordpress hardening" in your search engine of choice you'll find a ton of resources to get you going.

</comment><comment><USER3> I actually moved from Word Press to BlogSpot a few years ago. I like it a lot better. It is very user friendly for non-tech people and you can add authors, who have fewer permissions than admins. You can use a third party domain to make it a .com.

You can edit the HTML if you don't like their themes. A non coder can also do quite a lot to change the look, layout and functionality.

Google now handles backend updates and security for me. It is vastly less of a headache for me than Word Press was.

Full disclosure: I am not a programmer and I am not actually qualified to assert that BlogSpot is _more secure._ I just like it as a platform and I don't understand why it has such a terrible reputation as something you should not take seriously.

</comment><comment><USER4> If you're looking or a CMS for Jekyll (or Hugo) sites, we're developing [https://forestry.io](https://forestry.io)

A lot of our users are building very high-performant, secure, static sites with these tools.</comment>


Groovy Array: it just keeps going...and going... - <AUTHOR> http://svn.codehaus.org/groovy/trunk/groovy/groovy-core/src/main/org/codehaus/groovy/runtime/ArrayUtil.java

<comment><USER2> I just went to post that... can anybody explain to me what exactly is going on? I'm not familiar with Groovy, and I try to forget Java when I can, but this just plain doesn't make any sense.

<comment><USER3> They're aiming for compatibility with Java 1.4, which doesn't have varargs. In java 1.5 you could just write

      public static Object[] createArray(Object... args) {
        return args;
      }

<comment><USER4> I remember discovering this and deciding to eliminate it as part of an effort to compress the groovy jar file a bit more (long story, but basically I was running some Groovy in an applet, every byte counts).

I thought I'd found a jackpot and that killing this class would surely eliminate a nice chunk of byte code. To my amazement it makes almost no difference. With pack200 the redundancy of all these methods is totally stripped out. It took me an hour or so of work and I think it made less than 200 bytes difference in the end.

</comment></comment></comment><comment><USER5> There are some similar horrors in the source code for Clojure. [https://github.com/clojure/clojure/blob/master/src/jvm/cloju...](https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java)

Java is a harsh mistress. This is why dynamic languages on the JVM are nice, so I never have to write code like this myself.

<comment><USER6> I can't be sure, but in the Clojure case it appears to be done for performance reasons. The final definition of invoke uses varargs for everything after 20, so it's not an issue of compatibility.

</comment></comment><comment><USER7> This is what _comments_ were made for!

I'm sure it's legitimate, but you'd have to be insane to look at that code and not question why it exists.

<comment><USER8> One could also say you'd have to be sophomoric to assume the person who put if there didn't do so for a good reason.

<comment><USER7> As I said, I'm sure that it's legitimate, but it's definitely not good code, and I'd rather not have it lurking in my codebase for years on end. If you don't know the original motivation behind writing something like that, you can't really remove it for fear of the original bug cropping up again without you noticing.

(I guess, then this is also what test cases are for...)

</comment></comment></comment><comment><USER9> I'm curious: Why don't people just use `new Object[]{arg1, arg2...}` ?

It's one letter longer than `createArray(arg1, arg1...)`, doesn't require you to include that chunk of code, is _infinite_ in length, and allows you to statically-type it in your type of choice. Heck, it's _the same code_ , just removing a layer of indirection.

edit: noticed it's one character longer, not the same length. Maybe that's why?

<comment><USER10> This isn't regular code. This is code for the groovy runtime.

<comment><USER9> So, why don't the Groovy runtime programmers just write `new Object[]{arg1, arg2...}` ?

<comment><USER11> I suspect this is code meant to be called by generated bytecode, and generating the bytecode to call said function is easier than generating the bytecode to make a new object[]?

<comment><USER12> It's been a while since I generated JVM bytecode (oh my, five years), but I don't recall there being array initializer instructions. In other words, the new Object[] {...} statement probably translates to a whole bunch of array- write operations on the caller side whereas with a method call you just push them all on the stack and invoke the utility method.

</comment></comment></comment></comment></comment><comment><USER10> It's probably generated. Here's a one-liner in Groovy to generate the class body:

       (0..249).each { println "public static Object[] createArray(${(0..it).collect{'Object arg'+it}.join(', ')}) {\n\treturn new Object[]{\n\t\t${(0..it).collect{'arg'+it}.join(', ')}};\n}\n" }

Sorry it's not the most readable thing ;)

</comment><comment><USER13> Can't you use variadic function parameters?

        public static Object[] createArray(Object... args) {
            return args;
        }

I haven't done any Java in a while, so I'm just piecing this together from StackOverflow examples (with compiling, of course).

<comment><USER6> Since Java 1.5, yes. Perhaps it's an issue of backwards compatibility.

</comment></comment><comment><USER14> I need to instantiate an array with 251 members. Guess I'm out of luck

</comment><comment><USER15> And this is why I like dynamic languages.

<comment><USER16> Groovy _is_ a dynamic language. This is what it has to do behind the curtains, and even then only for backwards compatibility.

Your own favorite dynamic language is most likely doing worse things deep inside the runtime code where you can't see it.

</comment></comment><comment><USER17> This is a good example of how projects turn out that are outsourced and get billed by a lines-of-code metric.

(just as an example ... I'm aware that this is not the case here)

<comment><USER12> If it's not a case here, how could this be a _good example_? This is an example of generating code to work around a limitation. You can approve or disapprove of the whole situation, but it does have technical merit.</comment></comment>


Toura Mulberry - <AUTHOR> http://mulberry.toura.com/ (Native mobile apps w/ familiar web technologies & simple CLI) <comment><USER2> Wow. The coolest thing about the video for me was seeing WEINRE in action. WEINRE allows you to use a web inspector (like Chrome's) on your desktop to debug an HTML5 app running on your device. This is the first I've heard of it.

<http://phonegap.github.com/weinre/>

</comment><comment><USER3> Looks pretty damn awesome, imo, and I'm planning to play with this in December after some current commitments are over. I'm betting there will be even more awesomeness baked in by then. :)

</comment><comment><USER4> Taking a look at this really makes me wish that HP would either open source their Enyo mobile app JavaScript framework or find a good home for it.

There are some great ideas in this framework (such as the YAML layout) that Enyo could use.

<comment><USER5> I saw a presentation on Enyo at CapitolJS, where I also announced that Toura would be open-sourcing Mulberry, and indeed, there are a lot of similarities. I too would like to get some clarity about what HP intends to do with it :)

</comment></comment><comment><USER6> I'm new to this kind of things. So how does this work? Does the result consist of a app that "only" has a embedded HTML renderer and it loads your HTML/JS/CSS files in there, or do they somehow translate your HTML stuff into whatever the native language for the chosen platform is (obj-c,java,...)?

Also I noticed they link to PhoneGap on this page, how are this two products related?

<comment><USER5> Basically, Toura Mulberry uses PhoneGap as a wrapper around a "single-page" application that's powered by the Mulberry JavaScript/HTML/CSS framework. The command-line tools in Mulberry help you quickly scaffold the structure, content, and customizations for your app. The "builder" portion of Mulberry takes your content, prepares it to be consumed by the JS/HTML/CSS framework, and places it inside a PhoneGap project template so that it can be "built" for testing and submission to app stores.

This is all explained in a bit more depth here: [https://github.com/Toura/mulberry/wiki/An-Overview-of-the- Mu...](https://github.com/Toura/mulberry/wiki/An-Overview-of-the-Mulberry- Tools). Hope this helps :)

<comment><USER6> thanks!

</comment></comment></comment><comment><USER7> Cool!</comment>


Vaio to Start Selling Laptops in the US (again) This Spring - <AUTHOR> http://www.anandtech.com/show/10006/vaio-to-start-selling-laptops-in-the-us-this-spring <comment><USER2> Somehow having 8 gb RAM with no upgrade option doesn't signal high end machine to me.</comment>


Checklist for Black Women Applying to Jobs - <AUTHOR> https://zora.medium.com/6-steps-on-how-i-apply-for-jobs-as-a-black-woman-in-america-3092e82793c4 <comment><USER2> > I don't want to be the only Black person; that's asking for more trauma. > I've got enough to last me a lifetime. I don't want to be tokenized in a > position that has no power, cannot measurably enact change, and is lauded as > one I should be grateful for in order to have the only Black seat at the > table.

Wait until they hear about the legendary Ursula Burns ex-CEO of Xerox who worked her way up as an intern through merit. Louise Broni-Mensah of Shoobs took the startup route and is now part of YC W14.

One could argue about the soft-bigotry of low expectations of the persons situation in all the medium comments in the post. It's more than possible to do this in the US, especially your own startup.

Notable other Women in general: Katrina Lake of Stitch Fix puts many so-called 'tech companies' in shame in having IPO'ed and being both profitable and having zero debt. Ginni Rometty was ex-CEO of IBM and so on and so forth.</comment>


New source (type?) of startup capital debuts in Austin - <AUTHOR> http://www.abjentrepreneur.com/news/2011/02/new-source-of-capital-debuts-in-austin.html?ana=from_rss&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+abje_news+(ABJ+Entrepreneur+News)

<comment><USER2> Seems different-enough-to-be-risky. Is the revenue share capped in total size/duration? (Otherwise, how is it handled in the event of acquisition?)</comment>


Lessons learned building a multiplayer game in NodeJS and WebGL - <AUTHOR> http://codeofrob.com/entries/lessons-learned-building-a-multiplayer-game-in-nodejs-and-webgl.html

<comment><USER2> The author mentions defensive object cloning, which is, in general, an unpleasant way of doing things. Using immutable data structures makes for a far saner development experience (although with Javascript as the underlying target, it probably means some automatic defensive copying anyway...).

Using mutable state obviously generates far, far less garbage, and we've run into all sort of problems of bumping up against the GC in trying to have fast- enough javascript, so it is tempting from a performance POV. Would be wonderful if immutable structures can eventually co-exist nicely with GC implementations.

Great article, thanks for writing it!

<comment><USER3> Unfortunately there aren't any particularly efficient ways to do immutable values in JS right now. readonly properties tend to behave in poor ways (like silently discarding attempted writes, or slowing down jitted code) and immutability forces you to create way more object instances than you would otherwise (which, as the post mentions, tends to perform poorly due to the relative immaturity of JS GCs.)

At this point I consider this to be a bigger problem than it was when I wrote about it [1]. On the upside, it's possible to use tools like Emscripten or LLJS to produce JavaScript code that doesn't suffer from these downsides because it doesn't rely on the JavaScript GC or heap, but that introduces its own issues.

Ultimately, JS engines either need dramatically better garbage collectors or, the language needs to evolve to the point that an ordinary piece of JavaScript isn't going to place tons of pressure on the collector. Proposals like Binary Data [2] will help pave the way here but it may ultimately take the addition of value types that behave like structs in C/C#.

[1] [http://www.luminance.org/blog/code/2011/06/18/performance- ch...](http://www.luminance.org/blog/code/2011/06/18/performance-challenges- in-compiling-code-to-javascript)

[2] <http://wiki.ecmascript.org/doku.php?id=harmony:binary_data>

</comment></comment><comment><USER4> I'm a web developer, but am just about to jump into making a multiplayer HTML5 game, just for fun.

But after reading this post, and the one linked at the bottom [1], I'm thinking maybe this is going to be pretty valuable professionally. It should give insight from a completely different vantage point on what it means to write good code. By the way, you really should read that other post, too. It offers some interesting ideas to think about.

[1] [http://codeofrob.com/entries/a-relaxed-attitude-towards- the-...](http://codeofrob.com/entries/a-relaxed-attitude-towards-the- pragmatic-delivery-of-okay-software.html)

</comment><comment><USER5> >If you're going to deploy a long running node application that is going to be running a constant load, don't deploy it to either: A really low budget VPS

My multi-user node.js chatroom (<http://ponyplace.ajf.me/>) sustains around 60 concurrent users at any given time on a $5/month (not oversold) VPS. It can sustain a lot more than that too (151 at its highest yet after a 4chan raid).

The secret I find is in not letting your web server gobble up your memory. Don't use Apache, for example. I use nginx.

<comment><USER6> Hey, I noticed the traffic spike and came to say hello.

The thing about a chatroom and load, is that your server is effectively just message passing, and if there is any CPU spike, that is all it is - a spike, which VPSs for the most part are fine with.

When you are executing physics and logic 30 times a second _constantly_ regardless of load (so I made a mistake in phrasing there in my blog post), then you will be throttled on a cheap VPS because you're no longer being a good citizen - which was my point in that post if I recall correctly.

To my recollection, this hasn't got much to do with memory at all. I hope this clarifies what I meant to say a bit more.

<comment><USER5> Ah. I thought your point was more about VPSes and guaranteed vs burst RAM, which would be an issue. I see your point.

</comment></comment></comment><comment><USER7> The game is giving a 503.

<comment><USER8> This blogpost is old and the EC2 instance is not there anymore. I guess this was posted to give attention to the code.

<comment><USER4> ...which is available here: <https://github.com/robashton/HoverBattles>

I just downloaded it and am gonna see if I can get it to run...

Edit: to run the game, download the code, and open the folder in your terminal, and run:

> npm install > npm install socket.io > mv config/keys.json.example > config/keys.json > node server.js

Then open your browser and navigate to <http://localhost:8000>

<comment><USER6> Yeah, that's pretty much it - I don't really want to keep dozens of domain names and DNS entries for pet projects lying around when they're only going to get 10 hits a day and the code is all available :-)</comment></comment></comment></comment>


Weather in your terminal, with ANSI colors and Unicode symbols - <AUTHOR> https://github.com/fcambus/ansiweather <comment><USER2> Obligatory reference to the awesome Powerline[1]. If you don't want to use Python there's also tmux-powerline[2] and vim-airline[3].

I've been using these for the last couple of years.

[1] [https://github.com/Lokaltog/powerline](https://github.com/Lokaltog/powerline)

[2] [https://github.com/erikw/tmux-powerline](https://github.com/erikw/tmux- powerline)

[3] [https://github.com/bling/vim-airline](https://github.com/bling/vim- airline)

EDIT: typo, spacing and autocorrect :/

</comment><comment><USER3> I put ansiweather in the AUR[1] for Archlinux users.

[1] - [https://aur.archlinux.org/packages/ansiweather- git/](https://aur.archlinux.org/packages/ansiweather-git/)

<comment><USER4> Thank you kind Sir!

</comment></comment><comment><USER5> We're dyin' over here in the Seattle area: Current weather in Redmond => 282.77 °F

Maybe try metric? Current weather in Redmond => 282.77 °C

Perhaps it doesn't know about Redmond, WA. Let's try Seattle: Current weather in Seattle => 286.5 °F

It also seems to think it's sunny in Seattle right now. Umm, no.

EDIT: ah, no space after the comma in your location, otherwise it thinks you're on the surface of Venus.

<comment><USER6> The weather service reports the temperature in Kelvin.

<comment><USER7> Then why does Moscow report at -2? Russia's gotten so cold it's below absolute zero..

The comma edit does the trick.

</comment></comment></comment><comment><USER8> I am thinking more and more about moving back to a text-only interface - previously I was very happy with mutt, tin, lynx (and links and w3m), centericq, etc, but only bash and vim stuck with me.

Yet with the advent of unicode, there are fewer needs for a graphical interface - stay for a weather app. A clutter-free desktop consisting of mostly bash, along with gnu screen (or the likes) and ssh (or the likes) to remotely connect to home, now that would be efficient!

Even better - a few weeks ago, I found out that for math stuff, stata on OSX can be used with a command-line.

[PS: As usual Frederic, totally awesome :-)]

<comment><USER9> >Yet with the advent of unicode, there are fewer needs for a graphical interface - stay for a weather app

Of course the line between graphical and text-only is blurry. I'd argue that even small inline graphics are still graphics and thus not text- _only_ , no matter how they are technically implemented (unicode or some "real" graphics).

Personally I don't think we have to resort for using the unholy mixture of 70s and todays tech that console apps represent to get clutter-free desktop experience. More importantly I think we could get even more clean interfaces using full graphical capabilities if we'd get a good design ideology/guidelines to build upon. Just because mainstream GUI apps are stuck on WIMP idea doesn't mean that it would be the only way to approach GUI.

<comment><USER10> As far as I can tell, only modern equivalent of the terminal _(a generic input /output device/program that can be used as the standard front end to an endless array of applications)_ that has gained any appreciable traction is the web browser. Any "modern terminal, but not actually a terminal" experience, using current tech, is going to be built on top of a web browser.

The browser is just the terminal though _(which to be fair is a large piece of the puzzle)_ ; we still don't have the shell analog. The inadequacy of ChromeOS does not make me hopeful. ChromeOS is to the browser what midnight commander is to the terminal.

<comment><USER11> > Any "modern terminal, but not actually a terminal" experience, using current > tech, is going to be built on top of a web browser.

You're describing Steven Wittens' TermKit proof-of-concept: [http://acko.net/blog/on-termkit/](http://acko.net/blog/on-termkit/)

</comment></comment></comment></comment><comment><USER12> For April Fools' I released cloudyfs -- weather reports in your file system. Its pretty primitive, but functional. Pardon my haskell, it's lousy.

[http://github.com/bhickey/cloudyfs](http://github.com/bhickey/cloudyfs)

</comment><comment><USER13>
         % cat ~/.ansiweatherrc
         location:Pittsburgh,Pa
         units:metric

         jim@lilly /home/jim/projects/external/ansiweather (master)[0] {+00% 58C} Mon 2013-10-21 15:39:50 0
         % ./ansiweather
          Current weather in Pittsburgh => 17.68 °C ☀  - Humidity => 33 % - Pressure => 1014 hPa
        jim@lilly /home/jim/projects/external/ansiweather (master)[0] {+00% 59C} Mon 2013-10-21 15:39:52 0
         % cat ~/.ansiweatherrc
         location:Pittsburgh,Pa
         units:imperial

         jim@lilly /home/jim/projects/external/ansiweather (master)[0] {+00% 58C} Mon 2013-10-21 15:40:00 0
         % ./ansiweather
          Current weather in Pittsburgh => 61.89 °F ☀  - Humidity => 47 % - Pressure => 985.97 hPa

Interesting that the humidity and pressure are different when using different units (err, the humity and pressure are in the same units regardless of the units setting, but the values are different).

<comment><USER14> Given that 17.68 C is only 63.83 F, i think you just hit two different data points.

<comment><USER13> That's my point. When you switch which units are used 2 different data points are used. (Though, I didn't say it that clearly.)

I didn't even think to convert the temp though, good call.

</comment></comment></comment><comment><USER15> Did not work for me with the default .ansiweatherrc. I had to remove the fetch_cmd:... and use curl -s instead and then it worked.

[https://github.com/fcambus/ansiweather/issues/3](https://github.com/fcambus/ansiweather/issues/3)

Thanks for this, I had written a script to pull the weather from another site and placed it in my conky. It works but is quite ugly.

</comment><comment><USER16> ./ansiweather: line 76: jq: command not found

If you run into that on ubuntu, there does not appear to be an ubuntu package for jq. Binaries and source are available at [http://stedolan.github.io/jq/download/](http://stedolan.github.io/jq/download/)

<comment><USER17> If you are on OS X and use Homebrew, install with 'brew install jq'

<comment><USER18> There is also prebuilt OSX binaries, [http://stedolan.github.io/jq/download/](http://stedolan.github.io/jq/download/)

</comment></comment></comment><comment><USER19> How often does it make a http request? Every time PS1 is printed?

<comment><USER15> If you put it in your PS1 then it will make a request every time your PS1 is printed, but it shouldn't be hard to have it cache and check timestamps.

</comment></comment><comment><USER20> The author obviously does not live in California. I rarely check the weather since I know that it will be more or less the same as yesterday , or the day before, or the day before that...

<comment><USER21> After I moved out of LA, I realized there is a thing called weather forecast.

<comment><USER22> I guess that helped with the smog forecast withdrawal.

</comment></comment></comment><comment><USER23> I realize this is a weird question, but I've never understood the point of having an applet show you the current weather. Does your home have no windows?

<comment><USER3> That's an interesting question that I hadn't really thought about before. Aside from just being generally curious about the exact weather conditions, here are some things that I use it for:

1\. I live in a small apartment, so during the humid summers in New England with computer equipment running, it stays consistently hot. The A/C is running more often than not. In those cases, it's nice to get a quick gauge of the temperature/humidity. For example, it might guide me in whether I want to have a cigar in the evening.

2\. I find it useful to ascribe a quantitative value to weather like temperature, since it gives me an idea of what I need to wear if I'm going to be outside for any length of time. e.g., low 50s I can get by comfortably at an idle position with shorts, shoes and a sweatshirt, but low 40s requires pants to stay comfortable. It can be difficult to tell that by just stepping outside for a few seconds...

Sorry about the long-winded response, but your question was curiously provocative!

</comment></comment><comment><USER24> Most of us weather/radio nuts in the US have been doing something similar for over a decade or more. There's several scripts written in Perl or Python that grab data from NOAA. (Or you can just program your ICOM with the local frequency and script it to respond to the CLI...)

</comment><comment><USER25> I need this as an emacs extension. Would fit right next to my nyan cat progress bar.

<comment><USER26> And now you can have it there! [https://github.com/aaron- em/weatherline.el](https://github.com/aaron-em/weatherline.el)

</comment></comment><comment><USER27> Ack! I love this, so lightweight. I don't mean to do a pony request here, but can anyone think of an easy way to get this into a garden-variety windows 7 desktop, like through a rainmeter script or news ticker?

<comment><USER28> Not what you asked, but Win7 has a desktop weather gadget.

More along the lines that you asked ...

\- Install cygwin and run it in a bash terminal there. Probably some tweaking required, may or may not work. cygwin's minterm does display unicode.

\- Translate it into python and run it from a dos terminal (or from cygwin). I don't think the regular cmd.exe or powershell will display unicode (I could be wrong), but a replacement like conemu does (just checked). If you like this weather thing you'll like conemu better anyway.

</comment></comment><comment><USER29> Alternatively, [http://robobunny.com/projects/weatherspect/html/](http://robobunny.com/projects/weatherspect/html/) ;)

</comment><comment><USER30> Reminds me of a project a friend of mine did recently for the hackMIT hackathon: [http://hackmit.challengepost.com/submissions/18025-bashwunde...](http://hackmit.challengepost.com/submissions/18025-bashwunderground-b8) Has ASCII-art, but I don't think he's put the source up anywhere.

</comment><comment><USER31> This is great!

I just made a pull request to add the ability to see the forecast for the upcoming week as well: [https://github.com/fcambus/ansiweather/pull/11/files](https://github.com/fcambus/ansiweather/pull/11/files)

</comment><comment><USER32> I had to use an underscore for a space in my city name in the config file. It would be nice if it linked to the list of city names available. But I think the program is pretty awesome!

<comment><USER33> Go to [http://openweathermap.org](http://openweathermap.org) and find your city, then copy the name it says.

</comment></comment><comment><USER34> Great to see the weather in the title bar of my xterm, I often don't have the strength to look out the window.

</comment><comment><USER35> Nice idea !

Now I can have a weather icon in my prompt.

</comment><comment><USER36> Disappointed

         _( )_          _
       _(     )_      _( )_
      (_________)   _(     )_
        \  \  \    (_________)
          \  \       \  \  \
                       \  \</comment>


Elon Musk Takes a Swing at the S.E.C., in a Tweet - <AUTHOR> https://www.nytimes.com/2018/10/04/business/elon-musk-sec-tweet.html <comment><USER2> "Mr Musk has excellent attorneys. He should listen to them"

Somebody give this guy a donut.

For real though, how does Musk have any public goodwill any more? He blatantly committed a crime, scoffed at the charges, quickly caved when the stakes were raised, and continues to mock the authorities.

<comment><USER3> I think it's because what he's trying to make are high on a lot of peoples priorities, morally. I like Tesla as a battery company. I like Space-X. I want to root for the guy. I wish he wouldn't do things like this...

But I'm really rooting for him to go get funding and to put out the _exact same tweet_ with no intent on following through.

<comment><USER2> But like, he isn't Tesla. He isn't SpaceX. I agree that those are cool companies and I'm happy that they exist, but any ultrarich dude could have put up the startup capital for them. They could ditch him and be just fine. They're both profitable, they don't need his charity to survive, and his leadership is dragging their reputation down.</comment></comment></comment>