How did they choose their email provider? Not be carefully weighing the technical options, surely. They chose whatever their friends or parents used, because with working federation it doesn’t matter.

In contrast to mastodon instances - which are very alike - email providers have differentiated on the interface and guarantees they provide and market that. People react to that.

How did they choose their email provider?

I think federated apps like Mastodon are fundamentally different than email providers. Most email providers are sustainable businesses, they earn money with adds or paid plans or whatever and have their own emails servers and clients with specific features. Self-hosted email servers are a minority. Please tell if I wrong, but I don’t think one can easily earn money with a Mastodon instance.

However I agree that both are federated.

You’re certainly not wrong, though I would argue that email, particularly as it was 20+ years ago when it went “mainstream”, is much simpler (for instance, it doesn’t require any long-term persistence or complicated access control) and therefore easier to federate successfully (in a way that humans can handle) than social networking.

In the case of Mastodon, which instance you pick does matter. Users can make posts that are only visible to others in the same instance. If you pick the “wrong” home instance, you’ll have to make another account in another instance to see the instance-private posts there. If you’re a new Mastodon user, you might not know that one instance is good for artists and another good for musicians, etc. In any case, this is as easily solvable problem by adding descriptions and user-provided reviews to each instance.

Facebook and Twitter also present single valuable targets and are thus more likely to be targeted. A hundred mastodon instances may be individually less secure due to the operators having fewer resources or less experience, but compromising a single server won’t get you as much.

Python is not a product, and you’re not a paying customer, you don’t get to say “do this instead of that” because none of the volunteer maintainers owes you to produce a language for you. Just walking by and telling people what to do with their project is at the very least impolite.

I agree with the general direction of your post, but Python is a product and it is marketed to people, through the foundation and advocacy. It’s not a commercial product (though, given the widespread industry usage, you could argue it somewhat is). It’s reasonable of users to form expectations.

Where it goes wrong is when individual users claim that this also means that they need to be consulted or their consultation will steer the project to the better. http://www.ftrain.com/wwic.html has an interesting investigation of that.

Adding syntax variations is not done at the expense of performance, different volunteers are working on what’s more interesting to them.

Regrettably, a lot of languages and ecosystems suffer greatly from the incoherence that this sort of permissive attitude creates.

Software is just as much about what gets left out as what gets put in, and just because Jane Smith and John Doe have a pet feature they are excited about doesn’t mean they should automatically be embraced when there are more important things on fire.

I find that “people working on what interests them” as opposed to taking a systematic survey of what use cases are most needed and prioritizing those is a hard problem in software projects, and I find it curious that people think this is not a problem to be solved for open source projects that are not single writer/single user hobby projects.

Python is interesting because it forms core infrastructure for many companies, so presumably they would be working on issues related to real use cases. Projects like numpy and Cython are examples of how people see an important need (performance) and go outside the official language to get something done.

“If you want something to happen in an open source project, volunteer to do it.” is also one of those hostile attitudes that I find curious. In a company with a paid product of course that attitude won’t fly, but I suspect that if an open source project had that attitude as a default, it would gradually lose users to a more responsive one.

As an example, I want to use this response from a library author as an example of a positive response that I value. This is a library I use often for a hobby. I raised an issue and the author put it in the backlog after understanding the use case. They may not get to it immediately. They may not get to it ever based on prioritization, but they listened and put it on the list.

Oddly enough, I see this kind of decent behavior more in the smaller projects (where I would not expect it) than in the larger ones. I think the larger ones with multiple vendors contributing turn into a “pay to play” situation. I don’t know if this is the ideal of open source, but it is an understandable outcome. I do wish the hostility would decrease though.

He did say “please”.

I guess you are saying my grass roots campaign to displace “Should Python have :=” with “gradual typing leading to improved performance” as a higher priority in the Python world is failing here. I guess you are right :)

Yes to all of the above. But not understanding where all the personal hostility is coming from. Apparently having the opinion that “Should := be part of Python” is much less important than “Let’s put our energies towards getting rid of the GIL and creating a kickass implementation that rivals C++” raises hackles. I am amused, entertained but still puzzled at all the energy.

Heh. I think this is an example of the Lobste.rs rating system working as it should :) I posted an immoderate comment borne of an emotional response to a perfectly reasonable reply, and end up with a +1: +4 -2 troll, -1 incorrrect :)

I recently moved to financial software development, and it seems everybody has real life experience of losing huge sums of money to a bug, and everybody, including management and trading, is willing to try practice to reduce bugs. So I became more convinced that it is the cost of bugs that matters.

While this is true, don’t you think this is sort of… pathetic? Pretty harsh, I couldn’t come up with a better word on the spot. What I mean is, this is basically “those damn suits made us do it”.

Businesses that allow buggy code to ship should probably be shamed into better behavior. They exist because the bar is low, and would cease to exist with a higher bar. Driving them out of business would be generally desirable.

A boycott would need to start or be organized by developers, since developers are the only people who know the difference between a circumstance where a high-quality solution is possible but difficult, a circumstance where a high-quality solution is trivial but rare for historical reasons, and a situation where all solutions are necessarily going to run up against real, mathematical restrictions.

(Also, most code in existence isn’t being developed in a capitalist-corporate context, and the most important code – code used by everybody – isn’t being developed in that context either. We can and should expect high quality from it, because there’s no point at which improving quality becomes “more than my job’s worth”.)

Speed / Quality / Cost

Pick two

You can add on features to cars, and buildings, and the development process does sometimes go on and on forever. The difference is if your cow clicker game has a game breaking bug, typically nobody literally dies. There exists software where people do die if there are serious bugs and in those scenarios they either compromise in speed or cost.

We’ve seen this before software in other fields, and they do have this trade off as an option, you just weren’t in charge of building it. The iron triangle predates software though I do agree scope creep is a bigger problem in software it is also present in other industries.

It’s not business or management who made us build seemingly infinite layers and abstractions.

Oh it definitely was. The waterfall process, banking on IBM/COBOL/RPG, CORBA, endless piles of objects everywhere, big company apps using obfuscated formats/protocols, Java/.NET… these were middle managers and consultants forcing bullshit on developers. Those bandwagons are still going strong. Most developers stuck on them move slower as a result. The management solution is more bullshit that looked good in a PowerPoint or sounded convincing in a strip club with costs covered by a salesperson. The developers had hardly any say in it at all.

With that status quo, we typically are forced to go with two options: build the new thing on top of or within their pile of bullshit; find new niches or application areas that let us clean slate stuff. Then, we have to sell them on these whether internally or externally. Doing that for stuff that’s quality-focused rather than feature/buzzword-focused is always an uphill battle. So, quality-focused software with simple UI’s aren’t the norm. Although developers and suppliers cause problems, vast majority of status quo is from demand side of consumers and businesses.

It isn’t? Most managers I’ve met come and see me saying, we dont want to have to think about this, so build on top of this abstraction of it. They definitely do not want us wiping the slate clean and spending a lot of time rebuilding it anew, that would be bad for business.

I don’t see it that way at all. The practical implication of the Houdini features (viewed in total, not just this piece of them), at least aspirationally, will be that it’s easier to factor custom design elements into their declarative parts and their procedural parts. There’s a lot of black-box complexity within CSS as it currently stands, and it makes sense to open that up so it can be extended and modified.

You can’t just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis.

Is complicated code that solves complicated problems immune from breaking?

It’s more that some problem cannot be solved with simple code, because you can’t capture the whole complexity of the problem without writing a lot of code to capture it.

Consider tax code. Accurately following tax law is going to be messy because tax law itself is messy.

Definitely not. If you have simple but wrong, it’s no good by definition. You can “not have” fast, but essentially, you still need “fast enough”. If you can accomplish the task, and you can do so simply and correctly, but can’t work it quick enough for real-life workloads, then in those cases you might as well call it broken.

I am put in mind of the quote:

You can make simple software with obviously no defects, or complicated software with no obvious defects.

I don’t even think “correct” software is required–for many lucrative things, you have a human being interpreting the results, and oftentimes incorrect or wrong output can still be of commercial value.

That’s why we have customer support folks. :)

If the technology and processes you prefer have intrinsic merit, then why regretfully and silently abandon them?

Because when I didn’t, people were complaining about my quoting style, not understanding which part of the message was mine and which wasn’t and complaining that me stripping off all the useless bottom quote caused them to lose context.

This was a fight it didn’t feel worth fighting.

I can still use my old usenet quoting habits when talking to other old people on mailing lists (which is another technology on the way out it seems), but I wouldn’t say that the other platforms and quoting styles the majority of internet users use these days are wrong.

After all, if the maiority uses them, it might as well be the thing that finally helped the “other” people to get online to do their work, so it might very well be time for our “antiquated” ways to die off.

But HTML emails are good for one thing: providing hyperlinks without exposing URLs to people.

That doesn’t come without a huge cost. People don’t realize that they need to know the underlying URL and don’t care to pay attention to it. That leads to people going places they didn’t expect or getting phished and the like.

Those same people probably wouldn’t notice the difference between login.youremail.com and login.yourema.il.com either, though. So I’m not saying the URL is the solution but at least, putting it in front of you, gives you a chance.

As much as good web developers aim for elegant URLs, the fact remains that URLs are for machines, not people.

I’m not sure about this… at least the whole point of DNS is to allow humans to understand URLs. Unreadable URLs seem to be a relatively recent development in the war against users.

Personally, I hate HTML in email - I don’t think it belongs there. Mainly, for the very reasons you had just mentioned.

Let’s take phishing, for example - and spear phishing in particular. At an institution where I work, people - especially those at the top - are being targeted. And it’s no longer click here-type of emails - institutional HTML layouts are being used to a great effect to collect people’s personal data (passwords, mainly). With the whole abstraction people cannot distinguish whether an email, or even a particular link, is genuine.

When it comes it the structure itself, all of that can be achieved with plain text email - the conventions used predate Markdown, BTW, and are just as readable as they were several decades ago.

Overlapping has a lot of sense if you take into account that non-trivial amount of programs only ever needed one segment, so you could use “near” pointers and shorter jump instructions that only deal with offsets.

Yes, I wrote something similar on Stack Exchange a while back:

Testing follows a common pattern in software engineering: testing is claimed to make software better/more “agile”/less buggy/etc., but it’s not really the testing which does this. Rather, good developers make software better/more “agile”/less buggy/etc. and testing is something that good developers tend to do.

In other words, performing some ritual like unit testing for its own sake will not make your code better. Yet understanding why many people do unit testing will make you a better developer, and being a better developer will make your code better, whether it has unit tests or not.

That can generate new modules rather than changes to existing ones.

It’s horses for courses; both approaches have their merits.

Well, as long as it works, I’m fine :-)

I don’t know how Unity does it (which is what I’m using now), but I suspect it’s essentially the same, and it does look crisp at any scale factor.

Code style affects readability though, it’s not just about making it look pretty (I like pretty code too though). So the choices Black makes in that regard are important. Personally I don’t think automatic formatting tools should be too concerned with line length (except maybe in some very specific contexts) and they should just work with the lines they’re fed. The rules this tool uses for splitting lines seem fairly arbitrary and it’s one of the few areas where I think a human is better off making the call.

I’m not a Go programmer, but I think gofmt handles this better?

basically having to process all user data clientside

If I go to a site, grant that site a token, couldn’t that server do processing server side?

It gets more annoying when you attempt to introduce any way of interaction between two users.

Looking at remotestorage it appears there’s no support for pub/sub, which seems like a critical failing to me. To bikeshed an example, this is how I see something like lobste.rs ought to be implemented:

• User data is stored in servers (like remotestorage) called pods, which contain data for users. A person can sign up at an existing pod or run their own, fediverse-style.

• These pods support pub/sub over websocket.

• A particular application sits on an app server. That app server subscribes to a list of pods for pub/sub updates, for whatever users that have given that application permission. On top of these streams the app server runs reduce operations and keeps the result in cache or db. A reduce operation might calculate something like, give me the top 1000 items sorted by hotness (a function of time and votes), given streams of user data.

• A user visits the site. The server serves the result instantly from its cache.

• Additionally the pub/sub protocol would have to support something like resuming broken connections, like replay messages starting from point T in time.

Anyway, given this kind of architecture I’m not sure why something like lobste.rs for example couldn’t be created - without the performance issues you ran into.

Browser cookies is something that crossed my mind after I suggested this, but my experience as a web dev makes me immediately suspect of them as durable stores. :)

I agree with your points though.

It’s a mistake to think you can “GDPR opt-in”. You can’t.

You have to prove that the data subject wants this processing. One way to do this is to ask for their consent and make them as informed as possible about what you’re doing. But they can decide not to, and they can even decide to revoke their consent at any time until you’ve actually finished the processing and erased their data.

These cookie/consent banners are worse than worthless; a queer kind of game people like Google are playing to try to waste time of the regulators.

We will put up endless ‘find-the-road-sign’ captchas if we can’t track you

I’ve switched to another search engine for the time being. It’s faster, the results are pretty good, and I don’t have to keep fiddling with blocking that roadblock on Google’s properties.

• Via is actually useful, if properly used, and can detect request loops outside your network
• Expires is actually useful if you need to expire a response at a specific date, Cache-Control doesn’t do that, it’s only use isn’t “expire my content and don’t cache”
• X-Frame-Options is needed to support older browser, IE only supports a minimal version of CSP since 10, if you support older clients, XFO is a good security addition as CSP may not be available

The repeated use of “deprecation” without obvious links to the RFCs superceding those deprecations doesn’t help. Further, the entire point of the article is pretty clearly to help advertise Fastly (which presumably wants to go after some of Cloudflare’s market).

Like, it’s an interesting read, but I’m a bit concerned about people putting their services behind providers that sanctimoniously decide to break with RFCs because it might get them more business.