lal

It was a private conversation which Amjad himself stated he intended to turn into a public lawsuit. There should be no expectation of privacy here.

someone else on the internet writing a function does not make the c programming language more complicated. c's (lack of) library namespacing, which is responsible for this confusion, is, frankly, one of those valid critiques, but this is gibberish.

I don't think any of this is close to fair. "C is simple" and "it takes some work to do stuff in C sometimes" aren't mutually exclusive, in fact the former necessarily implies the latter. C is simple, which means it doesn't have a pre-written obscure built-in or convoluted syntax to handle every possible thing you might want to do in the language. You're going to have to write some of the code in your project yourself. That doesn't mean C isn't simple. I don't think I have to get into why writing a string-parsing function isn't quite the same thing as writing your own programming language.

And C has libraries too, to be fair. So if you prefer the "choose between 25 competing libraries that all provide the desired functionality but half of them are deprecated or don't work" workflow a lot of people are used to from C++ or whatever you can do that. Lots of people use libraries in C. In fact, as you might be aware, your OS's package manager doubles as the C language's third-party package manager. There has been plenty of "already-written C code," because it's a language that has been ubiquitous in computing for fifty years.

I'm not sure where these same tired critiques bubble up from but I see them constantly and they don't make sense. There are a number of entirely valid and damning critiques to be made of the C ecosystem but "there aren't any libraries written in C" and "oh, so you say C is simple, huh? Have you tried using it?!" aren't among them.

You're not going to be a 20 year veteran C developer and then suddenly just today learn about some obscure built-in, and that's what is meant by "simple" here, and that's a good thing.

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.

as an early gemini convert this is one of the reasons I wish solderpunk would split the gemini protocol and text/gemini mimetype specs. gemini can serve more than text/gemini (e.g. markdown as you suggest), so embedding the text/gemini mimetype into the protocol spec seems rather like embedding the html spec into the http one

i don't know if you understand what you're saying?? are you suggesting the binary content of a png file be inserted into the text-readable markup for a document? this doesn't make any sense. in-line images are linking to other resources. nobody just copy-pastes the hex content of an image into their website's html, because it will end up being 95% of the file size and a nightmare to look at in your editor.

the markup might be clean but it's pretty ugly and network inefficient because it's full of boilerplate that is only required because html also supports 1000 times more nonsense than this site uses, so you have to type <p></p> to render every line of that text, or <a href=""></a> to just render a link. you need to do <h></h> for headings. if all you want to do in your content is those things, that markup is ridiculous.

in terms of semantics it is almost entirely dissimilar except that it's line-oriented. instead of having any of the content type fields or whatever which enforce half of gopher's grammar, links are just "=> gemini://some.url/tunes.mp3", and when you hit that content it gives you a header with a mime type telling you it's an mp3. so now you don't need any of the structure of gopher and can treat literally everything but links as raw text, and clients can optionally format some agreed-upon subset of markdown, and otherwise, that subset of markdown is so readable without formatting that you don't even really need it.

this means you can create a far simpler protocol semantically: requests are just the uri, responses are just a header of a two digit response code and the mime type, and the rest of the response is just the content as raw text. that's the entire protocol grammar.

the screen refreshed every time you browsed to new content or did something that required accessing new content, as one would intuitively expect

gemini doesn't at the moment have any formalized systems for client-side scripting, effectively eliminating the need for that, and most of the gemini community seems pretty opposed to ever implementing such a thing, so it doesn't seem like that will ever change.

This is more intended to be a comfier gopher than a less-shitty http. Most of its early adherents are ex-phloggers attracted to its features relative to gopher, not ex-webbers attracted to its lack of client-side scripting or whatever.

The fact that this has attracted a fair number of gopher users (who have always very strongly opposed http/s) would seem proof enough of it's success, imo, at least within particular circles, and at least within the context of its goals. It was never intended to draw people away from the web, it was intended to be a sort of superpowered gopher.

Think of it more as a beefed-up Gopher than a pared-down web.

Fortunately the article is wrong because the signers are almost all either: 1) long-retired and out of the game entirely, 2) not trained in the field or qualified at all, or 3) known quacks who have peddled this kind of thing for years, or some combination of the three, and the articles cited are all written by that same population (and often published in no-name journals that I could probably get published in) or don't say what the author claims they do (many of the articles explicitly state that they found no connection whatsoever).

So I guess the moral of the story is "don't believe everything you see in pop science magazines," although I would have hoped nobody did to begin with(?)

I can think of very few science cranks I've ever seen who didn't have some kind of data. That means nothing. Data isn't a magical, pure, and perfect substance that emerges from the aether.

The maintainer says they have to pay for rent. Whether advertising in your open source project is good or not, wanting money to pay your landlord for rent isn't rent-seeking just because you saw the word rent in it. I'm assuming you hadn't heard of the term rent-seeking before and just read the two words and decided it must mean "looking for money to pay your rent".

Rent-seeking is a term with a specific definition [0] and "I need to pay my rent" isn't it. In simple terms, rent-seeking refers to the behavior of the landlord, not the behavior of a tenant. It may even be a term that applies to this situation, but the dev saying they need to pay their rent is entirely unrelated.

[0] https://en.wikipedia.org/wiki/Rent-seeking

I had a 2017 mbp, two months in, the left hook thing on the J keycap broke. It still stayed on for the most part so I was fine. The minus key was next, but both hooks broke so it just loosely flapped and fell off if the laptop was tipped. I 2-sided-taped under and it was mushy but worked. About 4 months in, the spacebar started sending double inputs like 10% of the time. I learned to watch out for it.

About a year in left shift literally just stops working over the course of about a half hour. The button under the keycap is apparently just done. I use karabiner to remap (only when karabiner is running) left ctrl to left shift and caps lock to left ctrl (just using capslock as shift is painful). One OS update later I get an error message that the keyboard is unrecognized. When it finishes rebooting the remapping is now permanent for some reason and unalterable (I don't have any reason to want to though because it's the only way I can write capital letters without right shift).

A year and a half in, it's working one night, then the next morning I open it and it's showing rainbowy artifacts everywhere that only appear when the screen is past like a quarter way open.

I finally go to an Apple store, where they take it and basically say "yeah all of that is stuff that happens, we'll check what it is and let you know". I get notified that it will be 700$ to replace the display module which they say is at fault.

I just took it back and paid 50$ for the diagnostics and bought an XPS13. Life is good. My mbp works if attached to an external monitor or projector.

But Apple needs Netflix far more than Apple needs whatever you think it would gain by losing Netflix.

It hasn't been established whether this has "accomplished" anything at all or if it's a false positive. That's what's being discussed in the Twitter thread.