Serious question from a fully paid up member of the tinfoil hat brigade: Why protonmail?
Don’t forget that if you’re sending messages you also have to consider the recipient. If your hardware is hosed, theirs may well be too. On that basis perhaps mail should be avoided depending on your threat model.
One option would be to use something like a BeagleBone black as it’s open source and I believe verifiable.
Another option would be to use a disconnected host for creating, encrypting and viewing messages then a separate host for relaying. This was the basis for a project I did (and cancelled) a few years back.
Yeah, I guess I’m imagining that I’d be able to give my correspondents their own copy of the setup, and instructions on how to use it. I’m definitely not expecting that emails I send to random people will magically be safe from now until the end of time.
If you’re talking about dedicated hardware at both ends, why not signal?
Signal’s proprietary central server and TOFU-oriented protocol add a lot of attack surface that doesn’t exist in other approaches.
The answer to the question “why protonmail” is mainly that I’m not sure what else to do. I have long given up hope that I’ll ever convince anyone to manually use PGP. Protonmail is a platform that I might be able to convince people to use; - has a nice UI and can conform to people’s existing habits and tools.
Edit: Reading this next to my other response does seem to make it clear that I’m confused about how other people ought to relate to the hypothetical system involved here. Obviously they can’t be allowed to just use their phones to read messages, so I’m not sure in what sense they should be allowed to stick with their existing habits.
if it’s just secure email wouldn’t spiped suffice?
Maybe there should instead be a set of “content notification”-style tags, in a different color (to indicate that they’re flags rather than community topics in themselves): One for sex, one for violence, one for classified material, maybe one for politics, and so on. This would let people decide for themselves what is NSFW in their particular context.
I think adding several tags, or a tag infrastructure is going too far. I’d much rather have a simple NSFW tag, that if it catches too much I’ll figure out later when I get home. Most of the time on lobsters there won’t be any NSFW articles, we don’t typically post NSFW things. If you wouldn’t like to see it in your workplace mark it NSFW, and if you don’t care, then don’t mark it. This is not a trigger warning solution, this is a “There are possible job consequences that would mean I can’t read this site at work”, I’d much much rather have false positives than fail to filter something because someone put it under (content warning: very specific nsfw thing that I didn’t know to filter). Adding a content warning infrastructure is a much bigger request than just a single tag.
This is a curious legal thing, but it isn’t tech related at all. Maybe a better fit over at HN or Reddit.
The “About” page suggests that what is on- and off-topic is determined by which tags exist (unfortunately? maybe incorrectly? or maybe I’m just misunderstanding). Perhaps this tag should be changed to say “tech law” if the community doesn’t want to see arbitrary interesting legal articles.
I believe that it is understood that all of those tags function in the context of technology. Otherwise we’d expect to see (further) abuse of the culture, art, law, and other tags.
Lobsters is just as much about what isn’t here as it is what is here.
Several people here are recommending CMake as an alternative. I’ve only interacted with CMake at a fairly surface level, but found it pretty unwieldy and overcomplicated (failed the “simple things should be simple” test). Does it have merits that I wasn’t seeing?
CMake can generate output both for Unix and for Windows systems. That’s one (good) reason lots of C++ libraries use CMake.
CMake is pretty nice and has nice documentation. You can also pick stuff up from reading other people’s CMakeLists. For simple projects the CMake file can be pretty compact.
I actually found the CMake documentation to be quite terrible for new users. The up-to-date documentation factually describes what the different functions do, but has very little examples of how to actually write real-world CMake scripts. There are a few official tutorials that try to do this, but they are made for ancient versions like CMake 2.6. So in order to learn how to use CMake, you are stuck reading through tons of other peoples scripts to try to deduce some common best practices.
While modern CMake is not terrible, you often have to restrict yourself to some ancient version (2.8.6 I believe is common) in order to support certain versions of CentOS/RHEL/Ubuntu LTS (and there were some big changes in CMake around 2.8.12/3.0).
Also, having string as the only data type has led to some absurd corner cases.
I’m kinda confused - the graphs at the beginning seem to show the opposite of what the author is claiming. For a given number of executions, the shorthand (in blue) seems to take more time, not less. What am I missing?
Looks like the axes are flipped. The x-axis is actually time taken, and the y-axis is the number of executions. The labels are wrong, too: notice how it says the “number of executions” is 0.000001.
This is the third or fourth post from the last few days from yegor256; All of them have been right on the line between hilariously and terrifyingly bad advice. One of them (“How much do you cost?” I think it was called) lingered in the top spot on the home page because there were so many rebuttals in the comments. This list is not a recipe for a good career or a good life.
The idea that the go language designers and implementors are nondogmatic is an interesting assertion to make, but it’d be better if there were a citation or an example. Certainly there are, famously, many more counterexamples, so it would be great to understand why the author has this belief. Is it from experience? Or is it from an ardent wish that it be true?
I am a huge fan of Go, bet businesses on it, have had great successes with it, that said…
… why the author has this belief. Is it from experience?
I have no doubt that this is the truth. I believe the core team is very willing to discuss things at length, non-dogmatically with those they consider peers (language designers, researchers). But how they dealt with the community in both tone and substance was another thing all together – they set the dogmatic “no questions” (less charitably, “we are right”) tone absolutely, and the community followed.
Or is it from an ardent wish that it be true?
Or I suspect, a hope for the future. Which is fine, if your community has issues, try to change them and the change has to start from people with voices with enough reach, rsc is one of those voices.
The go team are a bit similar to how openbsd works. If its clear you dont know what you are talking about, you will be redirected to go-nuts.
Tbh i think they are incredibly patient with lots of bad and unresearched suggestions. Good suggestiona get a great deal of consideration
rsc is just one of the Go designers/implementers, and is probably somewhat less opinionated than, say, Rob Pike.
My guess is rsc is reposting this as much as a reminder to himself as to others. Go is probably more famous for what it expressly leaves out than what it leaves in, and so remembering to say why something was left out is pretty hard versus just saying “because that’s not Go.”
[Comment removed by author]
I was surprised to come here to see a lot of objection to the Lisper’s suggestion that language designers tend to be open to talking about tradeoffs because they had to consider them during the design process. I read the point of the piece as the conclusion, asking the community to be fair and complete in talking about pluses and minuses:
But we need help from everyone. Remember that none of the decisions in Go are infallible; they’re just our best attempts at the time we made them, not wisdom received on stone tablets. If someone asks why Go does X instead of Y, please try to present the engineering reasons fairly, including for Y, and avoid argument solely by appeal to authority. It’s too easy to fall into the “well that’s just not how it’s done here” trap. And now that I know about and watch for that trap, I see it in nearly every technical community, although some more than others.
The idea that the go language designers and implementors are nondogmatic is an interesting assertion to make
I don’t think he’s actually making that assertion - he’s saying that the conversations language designers (of different languages) have amongst each other don’t appeal to dogma. Citations, then, could really only come from specific recorded conversations amongst only language designers.
There is this slightly disappointing panel with Bjarne Stroustrup, Rob Pike, Niko Matsakis (of Rust), and Andrei Alexandrescu (of C++ and D), whose most dogmatic participant seems (to me) to be Rob Pike, but if you’re hoping for an in-person flame war, it’s not there.
Replied something like this to dwc, but I’m surprised the focus here ended up on the Lisper saying that language designers are comfortable talking about tradeoffs because they had to wrestle with them while designing.
Seems like a nice enough anecdote and my reaction wouldn’t be to demand citations proving anyone’s thoughtfulness. But more fundamentally, the story was just a stop on the way to asking users to “[r]emember that none of the decisions in Go are infallible” and “present the engineering reasons fairly.” Hard for me to find that objectionable.
(my projects tend to be performance-minded reliable distributed systems)
Wow, I’m really glad I read through this discussion section - I was recently going through a new year planning exercise and wishing I had something basically identical to void.
It’s also really instructive to read about distributed system programming specifically - I’ve recently been doing stuff at work that would benefit from a lot of this structure. Thanks for writing it up!
I’ve written a TUI minesweeper game and a cellular automaton library, both basically scratch projects, around 200 lines. Nothing serious yet.
However, after using it for these, I think I will prefer it in the future for anything where I would have otherwise used C or C++, and where it’s possible to use Rust. I really like lots of things about it, but the most important ones for me apart from safety are:
Unfortunately, since Rust isn’t yet available on most embedded platforms, I don’t see any obvious near-term major projects, so I’ll keep building toys instead. My next one may be a Rust client library for ROS.
Things that would make my life easier if they were in Rust:
A cellular automation library? Could you elaborate on that?
Sure - it’s basically just a trait describing what a cellular automaton’s API needs to look like, and some boilerplate for stepping through time. I also started on an easy way to visualize 1D and 2D CAs, but didn’t finish it. Next steps (apart from the visualization library) might be a function to back-drive reversible CAs, or generate rules from given state transitions.
Ah, cellular automaton. I read automation and I was hoping you were working with cellular radios. I need some help getting started with those. Still a cool project! :D
I took honors linear algebra in college, used linear algebra for differential equations, signals, machine learning, and robotics, used it for work, used it in my free time.
I did not understand it until I watched this series.
Video lectures can be so much more than a blackboard/whiteboard facsimile, and I hope to the gods that 3blue1brown makes more in-depth lecture series like this one, and I hope even more that other educators take this series as an example of what’s possible.
Pages with lots of mathematical expressions tend to take a long time to be rendered with MathJAX; KaTeX is a similar tool that’s much faster: https://khan.github.io/KaTeX/