HN user
Again, I have to agree with you. I know I don't represent the majority, and I know that web apps have advantages (at least in this economy, so long as natural resources are cheaper than programmer hours). I don't argue with that. But I still find it a bit sad ;)
This is interesting, and it causes me to reevaluate my stance.
At least we have to agree on what we mean when we say that "end-to-end encryption works". I think there are `shades' of "working" if you will -- for instance, I know I mostly ignore when the key material changes in a Signal conversation, and this could be used to fool me. But then we have to talk about attack vectors and what we want to be protected from. I think it's mostly large-scale data collection and analysis rather than targeted attacks (like the CIA might do).
At any rate, thanks for setting me straight. I will read the paper!
Original author here. I have the following desiderata concerning MUA:
* it should be able to work offline (with a dedicated send/receive cycle),
* it should run fine on a Raspberry Pi (out of principle more than anything),
* it should favor plaintext mail,
* it should integrate well with all kinds of workflows and platforms (such as git email),
* it should be a veritable platform for experimentation (i.e., it should be malleable).
I think the case can be made that re-inventing the wheel can sometimes be beneficial. And e-mail to me seems rather 'underexposed' (maybe because most people think it has been a solved problem since at least Gmail).
For me, it's not just about e-mail, but our industry/discipline in general, and the state of e-mail is a good indicator in my opinion, because almost everybody uses it every day, and its implementation complexity is still rather manageable.
Besides, I'm interested in frugal computing and would like to reach a point where I can do my day-to-day stuff on a Raspberry Pi or similar device.
With respect, I do object.
End-to-end encrypted messaging does work, and Signal (among others) is proof of that.
With e-mail, either (a) you are backwards compatible and sending unencrypted (even by accident) remains a possibility, or (b) you break compatibility, but then it's no longer e-mail. (Signal is an extreme example of the latter: it just uses its own protocol.)
I find your answer a bit intrusive, to be honest. Let's just stick to the subject matter instead of telling each other how unreasonable or uptight we are, okay?
Yes, "written in C" is an issue for me, for two reasons:
* I really do want to do rapid prototyping and testing hypotheses regarding MUA UX, and C is just not suitable for this end.
* I keep reading about security vulnerabilities in common mail software caused by (among others) buffer overflows.
I don't think that MUAs benefit from C the way system software (such as the kernel) does. And compared to MUAs that run in the browser, I think that the bloat introduced by using Go or Python is still justifiable. Fortunately, there already exists a MUA written in Go (namely aerc).
Yes, I totally see your point. Gmail and similar offers are convenient, which means that native software has some very stiff competition and not a lot of adoption.
I'm interested in frugal computing, and I want my software to run smoothly on a Raspberry Pi if at all possible. So I do have some demand for a native program or, rather, set of programs.
Besides, on a principle level, I fail to see how something as simple as e-mail should need (or be allowed to use) something as complicated and resource-hungry as a web browser.
Thank you for responding, and for providing me with a link to your project. It is good to see that things like this exist in languages other than C. While some people on this thread in fact implied my constraints were unreasonable, I have to say I'm a bit fed up with all the statements on Wikipedia regarding security vulnerabilities of common mail software -- due to buffer overflows.
moi
And yet another example of feature creep in today's browsers. Now one can extend CSS with JavaScript.
Low coupling and high cohesion were the terms that I was thinking of, too.
Truly an impressive feat, and a lot of work no doubt. But why? Recently it seems to be some kind of fad to demonstrate that everything can be done inside a web browser. Again: why? Scope creep of web browsers is already beyond repair.
Interesting. For the sake of completeness, it's worth mentioning that this tutorial is from 2019.
Thanks for the tip! I guess I only used webpack because vue-cli set up my project that way.
Whenever I return to the project, hell breaks loose: "npm install" (whoops, 51 vulnerabilities!), "npm audit --fix" (what now? 72 vulnerabilities? I thought this was supposed to go down not up), initialize a fresh project with the CLI so as to get the latest possible scaffolding and then migrate stuff over from the old project etc. etc. This really appears brittle to me.
Sometimes the other party will happily oblige with your request, but only after a totally vacuous phone call that serves absolutely no purpose other than (i) signalling how much effort the other party is spending on you (ii) punishing you with synchronous communication so as to limit your potential request rate.
Have used a stack like that on one application, a rather simple "knowledge vault", a few years back. It worked very well, and at the time I liked it very much. But these days, I'm no longer fond of client-side scripting (because it gets very complex very quickly, and npm+webpack is a monster). So my next stack would be closer to BCHS [1], only with Linux, Golang, and nginx instead of BSD, httpd, and C. I might add in a tiny bit of client-side scripting such as [2], but no more npm, webpack, etc. for me.
[1] https://learnbchs.org/index.html [2] https://htmx.org/ https://unpoly.com/ https://hotwired.dev/
Settings → Language and Appearance → Advanced → untick Allow pages to choose their own fonts, instead of your selections above.
Done! Thanks for the reminder!
ActiveX was what sprang to my mind as well. But I only gave the website the most superficial look.
You have quite the nerve pointing out other people's alleged fallacies, while you yourself are doing everything in your power to interpret the statements of the Gemini community in a very onesided way. IIRC, the etiquette of this very place says:
Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
https://news.ycombinator.com/newsguidelines.html
Since this whole discussion has left constructive territory a long time ago and arguably violates these guidelines already, I will refrain from replying to this part of the discussion.
Thank you so much! I couldn't agree more.
Also, Gemini works for me, and it works for many other people. If the web is not to our liking, and we can't change the web, we can at least try something else (so far I'm just lurking in Gemini, I don't have a capsule of my own). I don't understand the problem with that.
As someone already said, Gemini is already in the "they fight you" phase (First they ignore you, then they ridicule you, then they fight you). It's like with veganism (no, I am not a vegan, though I sympathize).
convince people to use Firefox/Safari/Opera
What would that change? These browsers implement the same standards Chrome does, and on top they probably implement the non-standards that Chrome imposes, because people will still want to use Google Meet and stuff. So this at least means to convince people not to use Google Meet and stuff. This goes to show that indeed the web is broken.
convince webdevs to support/prefer non-Chromium engines
I guess the people who need convincing are not the devs, but their superiors. See https://www.baldurbjarnason.com/2021/software-crisis-2/
the unstated assumption that any new browser must be simple enough to be built by a single person, entirely from scratch, is an arbitrary technical limit based on political ideals
First of all, I'm not sure if anyone really said that it had to be achieved "by a single person". Second of all, I don't understand why its political nature should devalue the argument. At any rate, it has been argued that the web is at fault, the standards are problematic, etc., so let's not argue about minor details.
Reading this whole thread again, I want to add the following: this whole matter of whether web browsers have become too complex or not is just a tangent. The main debate revolves around the question of whether the web is broken, whatever this means, and this question is not a technical one, but a matter of taste and political attitude. Which is to be expected, because the internet is a social thing. So let's agree to disagree, maybe, but let's stop arguing about tangents the way little internet trolls do.
I don't get your polemics here. Where's the line between hard and impossible? It's no less impossible to build a web browser than it is to build pyramids, because both these things have been done before. But what does this mean? Why should we accept something that -- while theoretically not impossible -- is way harder and requires way more resources than necessary, and that is guided by the most pathological incentives (ad revenue)?
I will concede that Gemini folk sometimes have a rather narrow definition of what the "essence" of the web is, namely, that the web is basically just a medium for hypertext. In the early days of Tim Berners-Lee this was true, though. And I still think that hypertext (as opposed to "web applications") represents a nontrivial fraction of the web (see Wikipedia and, to a lesser degree, blogs).
Drew Devault makes a very valid point: that the web today is at the mercy of Google, because it depends on browser technology that has become so complex that only Google (and maybe a foundation entirely dependent on Google) can deliver it. An ad company! So we (as humanity) have to find ways to replace the web, step by step. And Drew says it right there: "Gemini [...] addresses a subset of its use-cases better than the web does." And for the other use-cases (i.e., besides hypertext), other replacements have to be found.
So I still think that the marketing is way more nuanced than you are saying.
Did ddevault specifically say that Gemini should be regarded as a replacement for the web? I never read him that way. As far as I can tell, people are constantly stressing the converse, namely that Gemini is not supposed to be the next web. It's even in the FAQ [1] -- if that's not part of the "marketing material", then I don't know what is. It would be very kind if you could provide specific citations to substantiate your claim about Gemini marketing.
[1] see 1.6 in https://gemini.circumlunar.space/docs/faq.gmi
I see, Gemini is not to make the life of content creators easier, but the life of the server and client implementers.
As far as I understand, the distinction (content creator on the one hand, server and client implementers on the other) goes against the Gemini philosophy. The idea is rather that it should be reasonably easy to be both.
The distinction between devs and users is less sharp when everything is as simple as the Gemini ecosystem. And that is precisely what they want: technology that is resilient and does not (and will never) depend on a caste of specialists and large corporations such as Google, like the web does.
I did the same thing and switched to a Nokia Flip. So far, my experience is the same. But my actual goal is the Mudita Pure [1], which is supposed to arrive soon-ish.
JetBrains Mono won the coding font tournament [1] for me, but said tournament did't have "Hack", which still looks best in my IDE (geany).
I think I found at some point that the arrows could be made correct -- at least for the SVG rendering in Firefox -- by removing the stroke (stroke-width="0").