People here saying they'd rather use just text-only HTML, or HTML+CSS sans JS, don't understand that what attracts people to Gemini is the ease of implementation . The main quality of Gemini is that it is easy to understand and implement thus allowing normal developers to create clients and servers from scratch with minimal fuss. You can actually keep the whole spec in your head which is no longer something anyone ca…
Then why distribute servers and clients? Why not just a spec that everyone involved makes their own servers and clients for?
And why all this noise about how awful the web is?
There is nothing Gemini can do to prevent people from adding complexity on top of it. It's exactly how the web evolved. It did not have activex/java applets/flash/javascript at the beginning.
Lack of extension points will just mean that the extensions will be uglier.
Personally I've come to believe none of it matters and that encryption is a total waste of time, at least for the kind of stuff I would want to publish using Gemini (long-form text) where there's nothing interactive or user-specific in any request. Just the act of making a network connection gives away who you are, where you are, when you are online, and what you're reading: https://kieranhealy.org/blog/archives/2013…
Restricting Gemini to just long-form text (one way consumption) is really reducing the possibilities Gemini can have, IMO. Though the whole minimalist attitude would probably preclude most of them.
I think that this restriction is good, though. For other uses, there are other file formats (Gemini protocol supports the use of other file formats too, e.g. you can use audio/ogg or audio/opus for audio, image/png or image/xpixmap for pictures, etc; a client might not support them and a user might not want them, so really you should use text if that is suitable (I am one who would rather have an explanation in text rather than a video), although you can still have links to other files too if needed) and other protocol (e.g. NNTP for slow communication (including if you want to allow comments for your articles), IRC for fast communication, Telnet/SSH for interactive applications, and other protocol should be made up for database access then you can use a SQLite extension to access them) (the text/gemini format can include links to other protocols too).
Can't speak for the original author but if I had to guess: Files on a world writable shared network volume, as this was a "classic" in school settings ;-) No matter the decade, allow some pupils a shared network volume somewhere, they'll soon or later write a chat app with whatever programming language they can get their fingers on in that network, at least that was my experience. I did it, heard from other schools w…
Can confirm that it was still happening as late as 2019.
How did you do networking from QBasic? (And especially when running under NTVDM?)
Wow this got a lot of interest. For that we cheated - someone wrote a xommand-line Windows program called GetWeb (I think) that took in a URL, fetched it, and wrote the result to a particular filename. I believe most of the clients used that, but some (especially those written in FreeBASIC) may have done their own thing.
This is interesting as an example of something that can be done on NTVDM but generally not other DOS emulation solutions such as DOSBox. A DOS program running in NTVDM can have a Windows console application as a subprocess; other DOS emulation solutions such as DOSBox generally don't support that. So a QBASIC program running under NTVDM can use the SHELL statement to run a Windows console program.
Part of how this works is that NTVDM uses the Windows console to host DOS applications. By contrast, DOSBox shows them in a Windows GUI window, not a console window. In principle, DOSBox could display them in a console window too; that works fine for text mode applications, but it can't support graphics. But, actually, NTVDM can run graphical applications in a Windows console window – how? Well, the legacy Windows console subsystem actually supports two different kinds of console buffers – text and graphics – but only the former is documented. NTVDM creates a graphics buffer for graphical DOS applications using an undocumented CONSOLE_GRAPHICS_BUFFER flag to the CreateConsoleScreenBuffer API – http://blog.airesoft.co.uk/2012/10/things-ms-can-do-that-the... – regrettably, creating a console graphics buffer is broken on 64-bit Windows. Another method that would still work on 64-bit Windows is GetConsoleWindow to get HWND of the console Window and draw on it manually. But Microsoft is discouraging console APIs such as CreateConsoleScreenBuffer and GetConsoleWindow since they don't work with pseudoconsoles (Windows 10 equivalent to Unix ptys) – and it actually looks like in more recent Windows code the CONSOLE_GRAPHICS_BUFFER API flag is gone – see
https://github.com/microsoft/terminal/blob/fb597ed304ec6eef2... and
https://github.com/microsoft/terminal/issues/246
I understand the desire to use trust-on-first-use to get rid of certificate authorities (some of the most dispicable and untrustworthy organizations around, and the largest security hole in TLS). However trust-on-first-use basically hands any long-term man-in-the-middle a complete victory. Authoritarian regimes are going to require ISPs to mitm every connection from first use, and hand over whatever data is desired t…
Personally I've come to believe none of it matters and that encryption is a total waste of time, at least for the kind of stuff I would want to publish using Gemini (long-form text) where there's nothing interactive or user-specific in any request. Just the act of making a network connection gives away who you are, where you are, when you are online, and what you're reading: https://kieranhealy.org/blog/archives/2013…
What I think is that a "insecure-gemini:" scheme should be added, which is the same except without TLS and 6x response is not allowed (if a client certificate is required, it must redirect to the protocol with TLS).
That's all concerning the content though. If you don't want HTML and Javascript and video streaming and EPUBs on the web, you don't have to use them. None of that concerns HTTP itself, which is developed by IETF. You could fairly easily make your own web browser that uses HTTP and only reads (gem)text files and ignore the rest of the web. Or just use Lynx. Pushing your own standard seems to only add to the complexity…
> That's all concerning the content though Ah yes. Just the content. Including things like WebUSB, WebHID, and a bunch of others. > You could fairly easily make your own web browser that uses HTTP and only reads (gem)text files and ignore the rest of the web. Yes, you probably could. And it wouldn't work with most of the web.
You are again conflating HTTP and 'the web'. The stuff you are talking about for web browsers has nothing to do with the HTTP protocol. In fact, many many things use HTTP that are not part of `the web`. Most APIs these days are HTTP based, but do not exchange HTML or any web content.
According to some other blogs posted here (links are are elsewhere in this thread) the entire point of Gemini is that it's useless and annoying to use, so useless and annoying that it drives out any advertisers or businesses that would be potentially interested to use it. I understand the designer's reasons to dislike online advertising but the train of logic here seems to be "internet businesses like to make things…
Internet business got trapped in advertising due to the whole classic phenomenon of "bad money chases out good money". I.e. a similar example lies in businesses funded by VC runways for several years ; even though those businesses may not be "actually profitable", because they're getting fake profits (VC money) for several years, they're able to compete against "organically funded" businesses that are actually earnin…
Your assessment isn't wrong, but the proposed solution here is to not support any business at all, which is just as bad. Anything that is plans to supplant this and doesn't immediately approach the problem of "how are we going to pay the journalists?" is going to fail.
People here won't like this, but the only realistic alternative to the advertising model where the vendor subsidizes the content, is a DRM model where the user pays to unlock the content.