arghwhat

Also note that drivers are made far harder than screws, so it will take many screws turned rivets before a driver becomes said artisinal hole punch.

Excuse me? That derogatory tongue-in-cheek way of referring to that company is not "mealy mouthed nerdery", as everyone and their mother understands who I am referring to. The lawsuit mitigation communication I suspect you're confusing it for requires it to be genuinely unclear who you mean.

However, batteries cannot cost $1 unless you want $1 worth of battery. Modern batteries are genuinely complex devices with extremely tight assembly tolerances, and something like a phone battery should be expected to be more like 10-40 USD.

Cheapo cells exist, but they genuinely have issues like poor assembly tolerances introducing risks of it deciding to spontaneously transform into a pocket-sized smoke machine.

They describe it as a feature in their later 1942 patent (US2474994A), in the description of which they mention it to protect against powertools with poor torque control, claiming that a better screw would only be possible if power tools and their torque control were perfect and that it is therefore a required feature.

The original designs did not reference this though, so it seems more like them adopting an observed behavior as a feature - so the statement that it was originally designed to be that way is indeed off, but the company did adopt the behavior in official paperwork.

Am European, yeah but pozidriv was never used for tiny screws. We have also pretty much migrated all screw sizes to torx nowadays, so I only ever really see pozidriv on older appliances and hardware, while Philips mostly happen on imports.

You got the wrong standard. JIS B 1012 type H is Philips equivalent, but what people refer to as the JIS screw is JIS B 1012 type S. JIS B 1012 Type S ("JIS") and ISO 8764 (Philips) are entirely different screw and scredriver profiles. See https://www.peterverdone.com/jis-cross-head-screws-and-drive....

The Philips screwdriver has lobes with a large multi-stage taper that ejects the screwdriver from the screw upon torque. The JIS screwdriver lobes are in contrast almost perfect 90 degree angle with a tiny filet in the center - not dissimilar to the Frearson screw.

A Philips screwdriver will be unable to insert all the way into a JIS screw due to this taper, exactly similar to how the extra lobes on a Pozidriv screwdriver collides a Philips screw. Attempting to apply torque with this partial engagement puts you at very high risk of stripping the screw.

A JIS screwdriver however does work perfectly fine in Philips screws, often even better than the Philips screwdriver as you did away with one half of the "screwdriver ejection feature".

There's a reason that iFixit goes out of their way to make both JIS and Philips bits, and warn you in their guides. They aren't really in the business of trying to cram more bits down your throat for fun.

As mentioned elsewhere, it's also important to remember that the batteries were fully serviceable - available for purchase, nicely compartmentized and with easy connectors. The products were definitely not designed to die with their batteries. They just weren't compliant with the new rules - this is quite different than a certain fruit company that have historically made battery replacements difficult for even service technicians to complete without consequences like constant user prompts.

I imagine the various products had their specific own conflicts with the rules, like requiring too much disassembly (the Pro controller in particular has to be disassembled from the front first), or the Switch 2 holding the battery with double-sided tape. Not to mention that you might not realize that the screw are JIS spec, stripping them with the Philips screwdriver you found in your drawer. Also triwing.

To be clear, all the mentioned Nintendo products are already designed for battery replacement, with well-contained battery units and easy connectors, and the batteries are available and problem-free to replace unlike for a certain fruit company.

The redesign is because the ease of accessing the batteries did not comply with the new rules. The pro controller in particular requires almost complete disassembly to get to the module, and the Switch 2's battery uses double-sided adhesive which is finicky. Joycons can also be a bit finicky to navigate for the uninitiated.

Also, as the device is Japanese, it uses JIS screws rather than Philips (in addition to triwing), which could surprise some. These are superior for service - Philips screws are specifically designed to strip during assembly to prevent over-torquing - but they do require you to have the right, "exotic" screwdriver. As JIS screwdrivers are compatible with and superior in bite even for Philips screws, it's a good habit to just always use those instead for electronics. iFixit kits and such include them.

To my understanding (which can be wrong) these gas turbines are not backup generators, but used as primary or supplementary power sources during normal operation where the grid cannot supply (or when grid cost is unfavorable). In one clip (which is a bit sensationalist so I'll refrain from posting it as it may derail) shows a park of some ~24 large gas turbines - each of which sized like a small building - with about half in operation at that time.

Indeed, there is some noise from backup generators when tested (or in use), but with a bit of preparation, good palcement and sequential testing you can make that not too disturbing.

Three ways:

1. Build your datacenter near supply. If there were consequences to ignoring the rules or being a bad neighbor with municipality, state or federal government baring their teeth, more optimal locations with regards to supply and noise would also end up being the cheapest and safest location for them.

2. Build supply near your datacenter. Solar and wind are both very cheap right now, but requires buying more land, same for a proper gas power plant in its own building with appropriate noise and pollution treatment.

3. Make investment into infrastructure a prerequisite for the project instead of just complaining about it and making into an excuse for cutting corners.

Even if you need to have local supply, "mobile gas turbines left on trailers to pretend they're not permanently installed to avoid having to get permits" is never a necessity.

We should also keep in mind that the problem isn't datacenters, but how they are built.

Datacenters do not have to be noisy. Datacenters do not have to cheap out on cooling solutions. Datacenters do not need to be powered by mobile gas turbines left on trailers to pretend they're not permanently installed to avoid having to get permits.

Those corners being cut is not what make AI datacenters possible or competitive. That race is purely chip supply.

For reference, I work in an industrial neighborhood where there are quite a few new datacenters from big providers. The buildings are ugly for sure, but unless you're staring at it you'd have no idea it was there. I could try to pay more attention to see if I can hear it if I focus on it, but I suspect the sound of nearby rustling leaves will be too deafening to make out anything.

Then maybe install the strobe lights in all important rooms

What are important rooms?

Most people have there phone on silent/vibration anyway and recently everybody uses noise-canceling headphones outside to not be bothered by other people...

Everybody is handicapped part of the time

A phone on silent still blasts public safety warnings at full volume. A phone on vibrate can still be heard. Noise-cancelling headphones still let the outside through at a lower volume.

Very different scenario.

I have previously had to install simple things like doorbells for deaf people, which is done through a very strobe light that can be seen from almost the entire apartment... if you're not behind a closed door at least.

The idea of it being genuinely difficult for a person to be warned or notified is terrifying. Put your phone in your bag and you might as well have left it at home. Honking, people yelling or screaming for you to move out of harms way, even air sirens... You'll have no idea.

A shrinking deaf community has nothing at all to do with ethnic cleansing, and social support does not shrink for less common diseases - it's usually the opposite, with support proportional to how rare and inconvenient the disability is.

Let's try a small thought experiment: Some birth defects stem from dietary issues in the mother during pregnancy, like folic acid deficiency or alcohol consumption.

Let's imagine that we discover that deaf children are primarily caused by a particular vitamin deficiency during pregnancy. We can then either spread the information so parents can supplement, or even fortify foods and cause the community to massively decline or even disappear - or we could withold the information on the vitamins to artificially maintain the population of the deaf community.

You could even extend it to a scenario where we end up relying more and more on artificial insemination or other early processing - the impact of many dietary deficiencies happen extremely early, so to maintain the community we would then have to artificially cause said deficiency to maintain the population of the deaf community.

Heck, we can always just make people deaf later if you wanted to maintain their community. We could also make more people get into "accidents" so that the quadriplegic community is maintained. Sounds absolutely insane when you start to discuss maintaining the population of disabled communities, doesn't it?

Back to the topic, cleansing of the deaf in this context implies a hatred for deaf people in general and wanting to remove all deaf people, which is an emotion entirely unrelated to sympethesizing with the disability of being deaf and wanting to avoid causing more such disability.

There is no path that turns "I would like to terminate my pregnancy if the outcome is unfavorable" into "I would like to commit genocide on everyone whose genetics I do not like".

Granted, someone who already wishes for or aligns with the idea of ethnic cleansing might start by only publicly sharing their wish for the former to begin with, but I don't see a sensible argument for it being a natural extension of the former.

A problem is that some see 2 as a subset of 1, upset at the idea that parents would wish to terminate pregnancies early that have strong indications of defects. I do imagine a good chunk of those people are of the horribly broken belief that abortions should be outlawed altogether, so not sure how many specifically go against such "filtering".

Granted, if everyone were sequenced and had access to that information it probably wouldn't take too long before certain categorizations became a requirement on the dating profiles, and that's a slippery slope...

(Regardless, nature filters us all by genetics in several stages, and our entire concept of sexual attraction and social groupings are based on the most direct form of priliminary selection for genetics that evolution could achieve with our limited available senses.)

Hmm, yes I was conflating a few things there.

However, I'd hold that this is an extension of the USB 3 mess that predates USB-C, even if the x2 mode specifically was a USB-C addition.

The important thing for people to know is that support for USB 3.2 Gen 2x2 is practically non-existent: TB3 came before as a well-established (but premium) solution, and USB4 just two years after to commoditize it. A complicated solution with mid-tier bandwidth and none of the flexibility didn't attract attention, so support is poor.

Well, this is about USB 3.2 Gen 2x2, which is a mess created by USB IF for good old, blue USB A connectors. Not USB-C complexity.

USB 3.2 Gen 2x2 is the very rarely supported 20Gb/s variant of USB 3, and making devices now that require that for full performance is a weird decision, with high-speed capable ports generally having wider support for either USB4 or Thunderbolt3+. I imagine the reason would be that some chip with an otherwise poor market fit got cheap...

Throwing this into the mix definitely doesn't improve the USB-C "what does this port support" conundrum, but this specific one predates USB-C and is not at all something you'd normally hit.

That's not quite true, as every SoC requries quite significant software bringup for an OS that makes other software engineering tasks seem miniscule in comparison - macOS and iOS just share enough common code that it's not as big of a deal for Apple.

Also not sure why you'd label it as "M0", as trivially beats the M1 on several metrics.

No, rather that they focused on peak performance, i.e., "churn out the most raw throughput at 400W+", rather than "get as close as possible to 0W when idle or in common uses".

Very different metrics - the former is about optimizing your architecture for pushing the most operations, the latter is about being able to power as many things off as possible.

TL;DR: Low power draw for laptops and phones is about who can reduce to the lowest performance, with the most hardware turned completely off while still just barely performing the task at hand. Completely different ballgame.

Peak performance happens at peak power draw and is a matter of having as much hardware as possible pushing as many operations as possible at any given point without spontaneously combusting. Those who have the most advanced manufacturing process, or architecture with the most execution units and best able to keep all units busy wins.

Peak power efficiency is about being able to turn as much hardware off as possible, and having lower quiescent current ("leakage power"), with bigger, beefier chips naturally having higher quiescent currents.

What is talked about here is about gating hardware such that you can shave off milliwatts or microwatts when the system is completely idle, by taking tasks that otherwise use slightly larger blocks that would have to remain on and moving them to smaller, more dedicated blocks. For example, being able to play a video with most render capabilities powered down because the display server can take the output of a hardware video decoder block and feed it straight into a display controller plane.

No, the cursor just uses an overlay plane, and mobile architectures usually have far more planes (sometimes even an arbitrarily configurable amount), and more flexible hardware compositioning overall than desktop GPUs for efficiency reasons.

EDIT: Also note that there is nothing new with the Neo here, as all Macs since the M1 have used the same chip architecture as the iPhone.

Desktop GPU designs did not focus on tiny efficiency gains, and often only has a primary plane, a single overlay plane (for e.g., a video), and a dedicated cursor plane. Some even have to share a single overlay plane between all connected displays. It's a recent thing for desktop GPUs to get more flexible in this area, in part to improve laptop battery life in the cases where the laptop is almost entirely idle.

(For those unaware, a "plane" here is the entity in the display controller you configure to show a rendered graphics buffer, in a particular location and with particular transforms. You commonly have one plane that just covers the whole screen, and then sometimes put dynamic content on top in other planes so you can avoid having to redraw the main buffer when smaller bits of it change, like a video player or cursor. You could also e.g., scroll by rendering an entire document in advance and then move the plane around to reveal parts of it.)

The display controller and render device are completely distinct logical devices, even though they are often grouped in a "GPU". On mobile architectures they are quite far separated, leading to annoying problems surrounding what we on Linux call "split drm devices".

Updating plane properties such as to move the cursor plane around or disable it would by itself not block on render activities, as they are completely distinct blocks.

The render hardware could be powered down, but I doubt powering it up and compositing the cursor would take long enough to complete to cause any noticable lag.

Under the Linux APIs, updates to the display controller are done through KMS atomic commits, and one mistake you could do display-server side would be to provide a fence in this atomic commit that the scheduler will use to wait on long-running GPU work before using the provided graphics buffers. Under this API, none of the changes - including mouse movements - would then be applied until that fence is signalled. Changing plane associations can lead to resource reallocations that can be a bit heavy.

Not sure if the kernel driver in macOS works anything remotely similar to this, and the driver could also just be dumb and block on unrelated things ("let's just wait another vblank to see this apply....", "as we only need one plane now let's power down hardware and wait for that to settle..."). It could also just be windowserver that waits for work to finish on its own, not providing any cursor updates in the meantime.

The reality is that it will take reverse engineering or looking at actual code to know what's going on.

Grid voltage had no real impact, but the field rate of early monochrome broadcasts were locked to mains frequency, hence regional differences in frame rate.

NTSC was gamma 2.2, and PAL/SECAM was gamma 2.8, which was indeed initially partly caused by local manufacturing differences before international brands took over, but neither "standard" was really followed by anyone. In the end, concluding that it was all a total mess, we split the difference in the early 90's by formally defining both to gamma 2.4 in BT.709. As such, their curves are the same.

(Manufacturing derivation was outside the scope, as manufacturers did whatever was convenient or sold sets, going all over the place with their response curves regardless of what region they were from or targeted. This remains true today - see any new TVs standard color response.)

Just a nit: Post-CRTs, there is no longer a "standard gamma curve", but many different transfer functions and many errors stem from misunderstanding this.

Even within "SDR"/"sRGB", many mistakes crop up from people erroneously mixing content encoded with the piecewise sRGB transfer function with content encoded according to a plain gamma 2.2 transfer function. And this is before we are getting into e.g., incorrect blending spaces or mismatched primaries.

But yes, it is purely a matter of compression, with many options for exactly what dynamic range you need and how you want your content defined (e.g., sRGB, gamma2.2, scRGB, HLG, PQ, ...), with linear light primarily reserved as an intermediate space for color conversions and blending - something your display server and any software working with arbitrary color spaces will be using.

> The Go toolchain does not currently generate any AVX512 instructions. Thus leaving performance on the table.

This just misunderstands the documentation. Compilers do not generally emit much of any AVX512, and the docs are just stating that the Go toolchain itself never emits it at the current time.

Use of AVX512 instead usually comes from explicit intrinsics or handwritten assembly in the compilers you're thinking of, and it is the same in Go. There isn't much AVX512 code in the standard library, but it is there and the GOAMD64=v4 flag means that it does not have to use runtime CPUID feature detection.

External Go libraries like simdjson-go also actively use AVX512. AVX512 does nothing for code not written with SIMD in mind anyway.

Apple does have some good counter arguments. Where there is data, there will be bad actors who want that data - and I trust Apple far more to behave than I trust some random shell company being run by some secret service.

As a EU citizen, sharing your data between Apple and Google which puts said data under free-for-all US intelligence access - which is known to have "questionable" habits and give basically no rights or insight as a to-them foreign citizen - is effectively trusting "some secret service".

To be clear, I am not one to fear use Apple for intelligence reasons, but not through a pretense that my data is safe from it, and certainly not because I believe it would be safer than using, say, a service based in Germany or France.

I'm more concerned with data brokers trading personal data out in the open, collected with minimal control from all the other apps and webpages we use throughout our day.

I get sad reading the "What EU users are saying..." messages. A lot of them seem to be Apple fans that just bought their evasive narrative.

I fully understand that some Apple users are perfectly happy with Apple's closed garden, but they must understand that its primary and almost sole purpose is profit maximization and the counter-arguments to opening up are purely about avoiding any risk to said profit.

While there could very well have been technical considerations to be had, all their answers to DMA have been lies, non-compliance and malicious compliance, as they have no intention of discovering whether their margins relied on the walled garden or not.

I personally suspect that the impact would be quite small exactly because Apple users tend to enjoy and stay within the Apple experience (myself included when I used Apple products - there is no harm to prefering that user experience), but they don't intend to risk parting with as much as a cent regardless of what benefits users, and will happily burn money lobbying against that.

They do not have your interests in mind here, and their way of maliciously presenting this such that you as a user will be bothered and blame regulation for their "inability to deliver" is very much lobbying 101.

Go's selling point is most definitely performance, but relative to implementation effort of a given application. This is opposed to languages that focus more on maximum performance at any cost to implementation, or maximum convenience at any cost to performance.

I have seen such detailed and tidy whiteboard diagrams, but the catch is that they never occur in active discussion. It doesn't make room for scribbling, and stopping a discussion for 5-10 minutes to draw slowly and nicely doesn't make sense...

You could turn clothing descriptions into embeddings and have a fashion vector database, but doing that would mostly just net you the ability to find adjacent clothings, rather than the ability to navigate available clothing or clothing fitting certain requirements.

What was done is more like using the LLM as a personal assistant that doing long manual labor to find what you might be looking for.

This way of shopping is already a thing. "Hype and investment" goes into how the companies can monetize AI harder (ads! integrated LLM shopping! business development! premium pro max enterprise data policies!), it doesn't really focus much on how the individual can save time and money through non-flashy tasks.