jj4211 @ jj4211 @lemmy.world

Posts

0

Comments

2,840

Joined

2 yr. ago

Think that's a fair assessment. On the one hand we are more connected than ever and sentiment travels fast and echo chambers let dangerous extremist thought fester. On the other hand, Germans were experiencing just a much worse actual living situation.

I'd even say all indications are that his leanings don't matter in the specifics of this event.

It's probably more informative that folks can credibly have theories for either leaning to lead to this event. Lots of reasons that could believably drive any political leaning over the edge if they are close.

I will point out one thing that should be obvious, the shooter was only 22. So it's possible he doesn't have a very baked and stable political ideology. I knew a hard core outwardly homophobic conservative at 17 who came out as gay and did theater by 20. I knew a fairly liberal person when she was about 18 that over the years got to a place where she publicly praised Trump and called COVID a hoax and the vaccine a conspiracy. No idea how that happened, even as I saw it first hand.

Given the situation, it is at least clear he was unhinged if he would get to this point, either way. I would have hoped this would be a lesson for people that people get dangerously moved by angry rhetoric, but a lot of folks are ramping up rhetoric instead.

Unfortunately, the hypothetical blue nation would have a food problem, especially if some red parts of blue states go over. Both such countries would have serious issues.

Yeah:

"The only perpetrator arguably from the Left is Black nationalist Quintez Brown."

So they did acknowledge it, but kind of gave it a pass because he wasn't "affiliated with the Democratic Party or any other mainstream reformist, progressive or leftist organisation".

I think it's still a bit up in the air about whether Tyler Robinson had a consistent ideology. He is 22, an age where political leanings can be all over the place and evolve pretty rapidly. Whatever the case, it seems he operated alone. So we can consider how much online rhetoric influenced him one way or another, but it doesn't seem like there was any organizational pressure or even a forum that had a chance to talk him into or out of his plan.

The article does make a broader point well supported by data, broadly speaking the right has gotten more violent and we don't see a similar pattern on the left. No matter which way Tyler lands or just attributed to less ostensibly political ideology, I think the trend is still valid. It's somewhat less dangerous if they can definitively establish him as a Fuentes like, but I fear he might be credibly "grown out of it".

Self hosting email is pain.

Less so about the technical piece, but high chance a peer won't fully accept your mail.

If I provide passkey support and still require a password, most users will get annoyed and not bother. If I provide it as a replacement for password, then I can get them onboard more often. I'd rather have them using passkey than sticking with password.

It's client specific and my phone requires whatever can unlock the phone and chrome requires either windows hello or a pin if under linux.

Certain implementations do whatever, and as far as the backend is concerned, there's no way of knowing, unless you want to get into the business of locking down specific vendor keys...

But I say MFA is overrated versus just getting away from generally crappy password factors. Also passkeys are less phish-able than OTP type solutions.

That's a pretty nuanced take. I don't think Trump can appreciate that level of nuance and would be outraged anyway.

I wouldn't even mind wrangling some normalized data, but it doesn't seem very normalized in their examples.

Their first example suggests "great, there's a human appropriate title and detail, and maybe this standard will say you should at least have those and they should be ready for pass through to a human operator", with extensions providing room for more sophisticated behavior.

Then the second example, no more top level detail, now there's an 'errors' array, and detail is under the children (which they don't formally describe the concept of reparenting attributes, just incidentally showing it in an example of what an implementation could do with 'extensions'). Well, at least I can still pass through the details if I find them and it will make sense right? "must be a positive integer"... Ok, nope, error information that requires the client to process a json pointer in order to manufacture some sort of actionable feedback. Again, this could be a neat optional feature, but a generic core client really has nothing they can bite into that generically applies to the standard.

The cited RFC I think is close to some ideas but softens it by trying to be open ended. If it specified mandatory top level "detail" member that is reasonably directly informative to a human operator without further processing, great, I know exactly where to find it even if I don't otherwise understand your problem type. Mandate that errors may be a collection under an 'errors' list, but otherwise identical to top level? Cool. Saying that here's some recommended members, but they are all optional and the behavior is really up to you, and you can just freely change everything you want and call it 'extensions'... Just not prescriptive enough despite the long words...

Just saying I agree, I use a USB-attached HDD enclosure because it's trivial to have a lot of hot swap HDD in that sort of product, and even the moderately slower USB-3 that some use is generally up to the task to keeping up with a handful of spinning platters.

The CPU referenced is BGA only, so it has to be bundled with MB. The platform only has soldered down memory.

So the minimal package is a motherboard with cpu, compelling gpu, and memory all down. Given the platform fits comfortably within USB-PD, then it's pretty much a slam dunk to have that motherboard have USB-PD down and skip the PSU..

The only things that naturally make sense to be maybe reasonable to be customizable are the storage, cooling, case, and maybe a solution to upgrade the GPU with a beefier discrete one.

As we push the physics more and more, systems are going to have little choice but to be a chunk of 'all in one', with the traditional build flexibility just no longer being feasible if you want top performance.

In terms of piecewise, the system builders get insane volume discounts, so it's not a given that pre-built naturally is more expensive despite it technically being a superset of the parts and efforts that go into building yourself.

Buses and trains work long distance too

It's less about the distance and more about the distribution. It's really hard to come up with solid bus routes to cover how rural America is distributed. My area has been trying repeatedly to extend the municipal mass transit into even the suburban areas and has struggled to come up with any vaguely decent coverage. You basically need people to move into a more orderly arrangement.

I only built my current system because of a special deal at my employer where you could buy a 4090 for 400 dollars, and this was only a couple of months after they came out.

Before that deal happened I was realizing that pre built was going to be cheaper for the same stuff. However finding a pre built without an expensive high end GPU that could be credibly upgraded to have a 4090 want in the cards.

Ok, got you, thought you were saying a bad url from client was inherently a backend mistake.

It's ok, as long as you make sure to use mongodb it will be webscale no matter what. But if you date use anything else, it won't be.

misdiagnosing errors originating from transport as application errors, and vice versa.

Shouldn't the response body disambiguaite clearly whose fault it is? I mean you have to anyway if you advocate for '200 for everything'. You still have that same response body whether the HTTP status code is 200 or 500.

We honor the status code while providing an error body and it's always blatantly obvious whether it's an infrastructure issue or "true backend" issue when we see an issue. In my team I can't recall anyone ever getting confused for even a little bit about whether an observed anomaly was web infrastructure or the backend, despite us setting HTTP status codes to error when, you know, we see an error.

I think the challenge is that it looks like a lot of other 'standards' I've seen: on one hand tediously specific yet on the other hand, so open ended as to largely defeat the point.

Every problem must have a 'type'. Ok, fine, so what are the semantics of the 'problem type'? Well, nothing in particular, just has to be defined, but it might be nice if it's a url telling a human about your own human thoughts on the type. Also, if you encounter multiple 'errors', you need to omit any that you arbitrarily fail to group into the same 'type' which shouldn't be subjectively too vague either, so don't think about making catch-all types so you don't have to discard some of the errors.

You can't count on the members, and a problem type may arbitrarily 'extend' to completely rearrange those members into members of child objects instead, but that's really all up to the backend to decide however they want to arrange it, with no prescribed standard for error bundling, but an example of how a backend could voluntarily implement such bundling as an implementer specific extension if they like, but again, don't bundle errors that shouldn't seem to be of a common type...

Also I think it's funny that they say do this in the name of being a good web citizen, but then say send this new mime type down, client's Accept header value be damned.

It purports to drive toward "machine-readable" problems but it seems like there's not much actually actionable and the client has to in practical terms do a bunch of bespoke handling to deal with a backend that is still pretty much open to do whatever they like.

It has a couple of reasonable seeming examples, but nothing that would make me think "Oh, you implement RFC 9457? Then I already have error handling code ready to go!"

I've seen all sorts of complex errors generated by backends that have all sorts of features like this and more (error messages with parameterized string values, json pointers to specific problematic pieces of the client request. However people just want a human readable response to pass along. I could imagine the example 'pointer' being useful to map error details to a client maintained form, but that's not even the 'standard', just a random example 'extension'...

I would argue that in your application, a wrong URL is a sever error. That error being improper handling of a client error.

That's certainly an unusual take. If you are a backend to HTTP and something throws a completely bogus URL out of left field at you, that's not by any means a backend error.

I guess your take is that it might be some sort of usability issue or such because if 95% of clients try to hit the same non-existant URL, that probably means there's some reasonable expectation that you should do something about the URL. However that's relatively more rare a sort of 'invalid URL' scenario. The vast vast majority are some sort of scanners trying bogus crap, followed by an impossibly diverse set of typos and peculiar one-off assumptions that you can't possibly reasonably cover.

I'd easily take that over '200 for everything'. If at least errors are distinct from success, I'd take that as a win. My standards have been lowered by so many '200 for everything' backends..