With a prevalence rate of < 2% (at least in Australia) this seems like an incredibly mathematically flawed take. Whilst a broad/blanket diagnosis isn't useful for making generalisations about individuals in that group, it's certainly societally useful.
All models are wrong, some are useful. Of course it has some utility, otherwise it would drop out of use on its own. The problem with big catchall symptom based diagnoses are what they drive focus towards and away from. I get that the scientific process has to start somewhere, by putting similar things in a bag, before it can tease out mechanisms and groupings. But when such simplistic models remain how doctors communicate with patients, it crowds out more nuanced understanding. Like even the word "spectrum", trying to add some depth to the pop culture model, is really just a fancy word for a single scalar.
> it crowds out more nuanced understanding. Like even the word "spectrum", trying to add some depth to the pop culture model, is really just a fancy word for a single scalar.
I just disagree with this take.
For people with autism, the broad criteria help to serve as guideposts for common experiences shared by those with autism. When doing treatment, everyone gets into the specifics of what autism means for the individual.
What you are complaining about is similar to someone complaining that cancer is too broad of a term. After all, the word cancer describes a spectrum of mutations and symptoms everywhere in the body.
How about for people "without autism" that have some of the characteristics (probably everyone), trying to examine their own mental workings (ideally more people) ?
How about for people with "mild autism" that have now been labeled by the medical system as being distinct from people "without autism", even though the main difference was merely passing some arbitrary threshold?
The difference with cancer is that cancer is an unequivocal negative. You can't be just "a little cancerous" and just embrace it. Whereas autism we're seemingly talking about variances in distinct components of what makes up intelligence. So setting some arbitrary threshold below which you're "fine" and above which you have a "problem" is really an artifact of the medical industry and larger economic system rather than actual mechanics.
I think a person is usually capable of figuring out whether some of their traits pose a "problem" in their life or not. And if they're not capable, you're probably able to figure out the answer to that question already without their involvement.
Healthy people usually don't try to find a diagnosis for their mental state.
I don’t disagree that pop culture has distilled spectrum down into a magnitude, but that isn’t how the DSM describes it or how professionals diagnose it (or in my experience how they communicate it). The metaphor is supposed to be like the light spectrum not “less autism ranging to more autism”. Severity scale is distinct to interacting traits of social issues and restricted interests and repetitive behaviors (the spectrum bit).
When I said single scalar, I was referencing the light spectrum - it is literally just less energy ranging to more energy (per photon). We just experience it so vibrantly as different colors (etc) because the difference between specific energies are quite important at the level of our existence. So unless there is a single underlying factor whose magnitude causes all of the different distinct traits of autism, it's a poor analogy.
Your comment would probably be less confusing for non-physicists if you said frequency instead of energy (I know, E=hf).
Two meanings of the word spectrum are used in this discussion, definition quoted from wiktionary:
1. "A range; a continuous, infinite, one-dimensional set, possibly bounded by extremes." "Specifically, a range of colours representing light (electromagnetic radiation) of contiguous frequencies"
2. A plot of energy against frequency, e.g. "[t]he pattern of absorption or emission of radiation produced by a substance", or the output of a Fourier transform.
You were talking about the former, BoiledCabbage the latter.
---
I agree with you that the former makes a terrible analogy of autism; and to be honest I really don't see how the latter can be an analogy of autism.
Two beams of light of equal intensity and different frequency contain equal energy not differing amounts of energy.
The actual difference in frequency is the composition of that energy.
If of course you compare a dimmer beam of light with a brighter one the dimmer one will have less energy.
So no less energy is due to lower intensity light, not due to different frequency. You can pretty trivially have 5 flashlights each with a different color of light and all with the same energy.
Sure. The varying "composition" of that energy is what forms the spectrum - it's a single scalar. You're adding one more dimension of dim/bright, making the entire description be two scalars.
Look up the definition of "spectrum", and contrast with "gamut".
I disagree - I'm not adding an additional dimension. You're implicitly including the dimension of intensity without calling it out explicitly.
The only way that two different otherwise identical light sources can output different amounts of energy is if they have different intensity.
Or put differently, in your example if you have different wavelengths and hold intensity constant then energy is also constant. It's your example that has implicitly introduced the concept of intensity without explicitly saying so.
And the evidence of that is my example. My example is exactly your example, but holding the intensity consistent between the two different light sources. If you do that, then your example fails.
Different wavelengths of light at the same intensity output the same energy. Meaning wavelength does not change the energy output by light.
Even though photons exist, light is fundamentally not a particle. Your statement would hold if light were a particle and only a particle and did not also have wavelike properties. And generally when discussing light as human perception it's the macro scale and wavelike behavior that is being discussed.
I was talking about the spectrum, not brightness or intensity. The spectrum represents a variation in just a single quantity - energy per photon, or wavelength if you prefer. The spectrum is orthogonal to brightness/intensity/power.
No, you resigned. It’s completely possible to have adult conversations and to part ways without being terminated for cause (which “fired” is a euphemism for).
It’s more than that, doing it well is still beyond sophisticated automation. Many variables that need do be constantly adjusted for. Humans are still much better at it than machines, regardless of the social element.
If true, probably not for long. Still my point is people are customer. It’s more fun to think about what won’t change. I think we will still have baristas.
Is this not essentially what docker did with cgroups? It’s incredibly tricky securing containers, I’m not at all confident process only sandboxes would be adequate.
There's a big difference between securing containers, and using them to prevent Adobe from polluting they entire system. Containers are an excellent way to provide lower guarantees of security (though still more than is there currently), with higher usability. Microvms also fit into the model very cleanly and could be used transparently when higher security was required.
The fact that VMs are necessary has shown how much OSes have failed. That we need to take an OS and package it into multiple VMs to get any real isolation is a problem that OSes should solve for.
Docker makes it really hard to do anything with cgroups. Unless you mean letting Docker manage everything about them, in which case you can configure nothing.
Systemd did the cgroups thing right. Apart from the v1/v2 thing, but if you can use only v2 then you do not need to think about it.
They do, the parent is either on an older tesla software platform or they haven't looked at settings > service and have ignored the alerts when they occur.
otoh it has a dashboard and a rim around the display to lean your hand on while you're trying to hit some ridiculously small (in a moving car) touchscreen target.
If Apple made a car, I would expect "Preferences -> Logbook -> ["Show logs", "Add Service Record...", "Save in PDF"]" menu, never heard Tesla have one in Settings menu.
> To see the miles driven since your last tire rotation or replacement, touch Controls > Service and look under Last Tire Service. After the tires on Model 3 are rotated, replaced, or swapped, update your vehicle's tire configuration by touching Reset, or by touching Wheel & Tire > Tires from the same screen. This allows your vehicle to reset the learned tire settings and improve your driving experience. This also clears and resets the tread wear alert for the vehicle until you travel 6,250 miles (10,000 km) and low tread depth is detected again.
had to look it up because I wasn't sure where it was but knew I had seen it.
Translation: Teslas, not sure which model you looked up, have such bad suspension and stearing that tires, ubder regular use, worn down inconsistently. Which shouldn't be an issue in modern cars running proper tires and tire pressure.
> Translation: Teslas, not sure which model you looked up, have such bad suspension and stearing that tires, ubder regular use, worn down inconsistently. Which shouldn't be an issue in modern cars running proper tires and tire pressure.
Ah yes, "Big Tesla" must have gotten to...checks notes...Michelin tires[0], Ford[1], Toyota[2] and more...
Your ignorance to cars and blind hatred to Tesla is showing BTW.
Inconsistent tire wear has nothing to do with the tires and all with the car so. Oh, and wrong tires (as in tires not meeting speed, load or dimension requirements), tires wrongly mounted on the rims (common among "tuners") or wrong tire preasure.
How much do you know about cars or mechanical engineering?
E.g. in Teslas user manual for the Model 3: swap tire every 10,000 km. And in other comments the last times the same question was discussed. Indirectly in the high number of inspection failures due to suspension issues.
I'm running a Model 3 with 2023.44.39 on it. In the Service menu there are a variety of exactly the things you mentioned.
In the top right corner there is "Tire Service Mileage" with an estimate of when you should service your tires. There is a reset link under that, which links into the "Wheel and Tire" service tab with more maintenance options.
Regarding the tire wear, the car is heavy with instant torque. I've had to replace my tires quite a few times, but it's the only thing that has needed much servicing for me in the past three years. I'd expect that from a new car though, and I don't have much confidence in it's longevity.
Docker is running as root, so the files written in mounted volumes get mapped to uid 0 on the host. When the agent then goes to re-use the checked out code, it can’t run ‘git clean’.
Username space remapping wasn’t adequate, for reasons I’m a bit blurry on. I think recent kernels have some better options on remapping permissions across file systems.
My take is different. I think DevOps was wildly successful, most of our infrastructure is now software that can be managed by Software Engineers. The goal posts have shifted, we now have major software challenges where as before we had hardware and operational challenges.
Well written tools and cross-functional teams that do both operations, feature work and security are still the path forward IMO, we just need to refocus on developer experience.
We tried to hire senior devs to do DevOps work, but the ones that can pass the interview and have already been at a DevOps shop are too smart to be fooled a second time.
We still use all the DevOps buzzword stacks, but we stopped doing dev ops. Instead, we are building out a really good ops team. This makes it possible to hire developers again.
Personally, I'm one of the better ops people on the developer side of the fence, but I'd need at least 2x typical principle engineer comp to take another job at a DevOps shop, and also wouldn't get even a quarter of my normal productivity.
At that point, you may as well just hire a junior undergrad graduate and burn the rest of your cash.
As a software engineer I don’t want to touch your infrastructure code. I have been lucky so far and I have been doing pure product development instead of being a devops. I do believe though in the idea of cross functional teams: designer, developer, infra engineers, managers.
And now 50% time software engineers are writing infrastructure. Don’t know what is solution but cloud-native landscape has increased cognitive overload.
The point is obviously to pay less people to do more work. What I don't get is when developers themselves are in favor of it like I constantly see with this devops stuff. There's no way they have any kind of life outside of their job. There's no way they have a wife or children, otherwise I simply don't believe for a second they would be in favor of "developers own all the things yay!".
> What I don't get is when developers themselves are in favor of it
If you're comfortable with AWS and have built things as a software developer, it becomes clear very quickly. These things are intrinsically linked, and pretending they aren't is just kicking the can down the road until you have to solve some non-trivial problem.
There have been huge innovations and value-adds over the last 10+ years in cloud and serverless, yet everywhere I've worked that silos "DevOps" from devs has already baked in the culture that devs can just avoid knowing anything about AWS, that DevOps will be the gatekeepers, and that devs can just work within the "lowest common denominator" box of tooling that those gatekeepers think is appropriate. Meanwhile, infra costs are skyrocketing but it's all good because we're mostly "cloud agnostic."
I don't want to just be closing Jira tickets. I want to actually solve business problems well. And to do that, I don't want to be constrained to someone else's "box," throwing code over the wall to them, and hoping for the best.
I get paid pretty well fixing bugs and writing code, that stuff you call "just closing Jira tickets" and "throwing code over the wall". It's also enough to fry my brain and leave me exhausted. But it's obviously worth next to nothing in your view. So yeah, I don't care. I can't figure out if you're going to have to find people a lot smarter than me to do what you're looking for, or people a lot dumber than me.
> It's also enough to fry my brain and leave me exhausted. But it's obviously worth next to nothing in your view.
It's fine up until you have to solve hard problems. Once you need autoscaling or more of a datastore than you can get from vertically scaling a relational database, your brain will be REALLY fried trying to solve those things without touching anything at the Kubernetes or AWS layer.
Or it won't really be fried, because it won't really get solved. That's the pattern I've seen more often: just keep scaling up the CPU and RAM for individual containers / instances because devs can't solve it without DevOps, and DevOps can't solve it without devs. Cloud costs keep going up, and the problem's not really solved, but at least nobody had to understand more than they wanted to.
+1 tiny teams run infrastructure that previously was responsibility of whole departments at bigco and things mostly work well. Then as soon as they face some minor, totally solvable issues everyone loses their minds.
