does that actually matter much on anything except dirt-bike tracks, or trying to go 40mph on a horrifically bumpy track? minus some comfort advantage, of course.
like technically, sure, it's obviously true. but for performance it only really matters when you would get air time with higher mass, and the lower mass stays in contact more. commuter e-biking generally doesn't get anywhere near those speeds or bump-sizes. (trail biking: sure! I 100% believe it's a sizable consideration there)
I've never ridden a full suspension with a hub motor so I can't say, but my guess is that yes, it would make a pretty big difference with an aggressive rider or poor quality streets. It's not just keeping contact that matters, its the consistency and quality of contact, especially with a super torquey motor ready to jump at a twitch of your thumb. Its of course not necessary for commuter biking, but neither is basically anything on this premium product aside from the wheels and pedals.
Also to note, they are very much marketing it as a trail bike in addition to a commuter so it's not surprising they would spend a bit to optimize for ride quality and traction.
Not all e-bikes have a rear suspension, so the motor will feel the bumps either way pretty much the same, I would guess. Or being placed in the middle halves somewhat the shocks?
I can't speak for all EVs but my Ford with a 400v hybrid system (DC-to-DC, no alternator) was able to keep operating perfectly with no 12v battery whatsoever. There was an assembly defect where the positive terminal connecting the battery to the fuse box eventually came partially loose and would disconnect as the engine bay warmed up. It would start up fine and drive with zero issues but then completely black out as soon as the car was turned off.
High frame rates (low frame times, really) are essential to responsiveness which, for those who appreciate it, is going to make much more of a difference day to day than the odd hiccup opening a large file (not that zed does have that issue, I wouldn't know as I haven't tried opening something huge).
You probably do. Many people just never notice that. It's not about typing or reading fast either, it's just about how it feels. Typing into something with shitty latency feels like dragging my fingernails across a chalkboard.
It's the same with high dpi monitors. Some people (me included) are driven absolutely insane by the font rendering on low density monitors, and other people don't even notice a difference.
Honestly, consider yourself blessed. One less thing in the world to annoy you.
Yes, I can perceive that latency, if I am actively looking for it. No, it has absolutely no effect whatsoever on my ability to work. The latency is far, far below what could possibly affect neural feedback loops, even on the slowest editors. And it doesn’t bother me in the slightest.
Low-dpi font rendering also isn’t an issue for me, unless it is so bad as to be illegible (which no modern system is).
> Am I missing something or is this WM/compositor more suitable to smaller displays which can not show all that many windows at the same time?
IMO smaller screens are where it shines, but you can also vertically stack within a column in Niri for similar density compared to tiling if you want.
> I keep track of which terminal goes where based on (among others) location.
I think this is a pretty nice benefit of Niri actually, having a second dimension to work with makes it much easier for me to keep track of windows because I can reduce the total number of workspaces and instead rely in part of relative location to other windows without being forced to fit all of them completely on screen. When I don't need my full screen real estate I often set up splits so that a little bit of the offscreen window is still visible and it makes it effortless to remember whats there.
The requirement for making APIs immediately public only applies to connected devices under specific circumstances, which I would expect are a little more solidified at launch on account of how much integration work has to happen between different groups at Apple. AFAICT other APIs can remain private indefinitely unless they are subject to an interoperability request. Assuming the request is valid, Apple has 9-21 months to plan and implement any necessary changes to make the API public, where the time range is based on a self-assessment of the technical complexity of the request.
Because the DMA legally obligates them to share those APIs when they are necessary to implement a feature for a connected device. The goal of the regulation is to promote healthy competition for connected devices by outlawing self-preferencing by massive players. Reasonable people can disagree about the goals or the downstream effects of the DMA, but creating Private APIs for connected device features absolutely falls under the umbrella of self-preferencing.
In the same way, the EU could ask manufacturers of wireless headphones to open up and homologise their proprietary “APIs” with which they communicate with the other earpiece so you can mix&match single earpieces from different manufacturers.
The point of this regulation (DMA) is to enable more competition in important market segments. If this exact thing becames somehow very important, sure, it's possible, otherwise it's a bit contrived. What's the point?
Forcing standardization and interop is obviously good for interop, but it's bad for companies trying to innovate, because it ties their hands. The moment apple ships a v1 they have to ship an API, and then they have to support that API and can't change it. When it's private they can figure it out.
Apple already spends years in R&D before releasing anything. Many of their R&D devices never see market. Requiring them to share an API they've actually shipped to paying customers is not a significant additional hurdle. We know how to version APIs now. They can still make improvements to public APIs without hurting anyone.
Which is why DMA only applies to huge, dominant companies (the complete list: Alphabet, Amazon, Apple, ByteDance, Meta, and Microsoft) and there too it does not apply to all technologies, only for those where standardization is important to enable competition. It's much more important to have at least some competition than letting dominant companies monopolise entire markets through 'innovation' with private APIs.
It is somewhat complicated by the specific requirements of the DMA specifications for Apple:
> The interoperability solutions for third parties will have to be equally effective to those available to Apple and must not require more cumbersome system settings or additional user friction. All features on Apple will have to make available to third parties any new functionalities of the listed features once they become available to Apple.
Apple is saying, "We designed our API in a way that requires trusted headphones as part of the privacy model, and DMA would force us to give everyone access to that API."
What goes unstated is that trusted headphones aren't necessary for the feature and a company trying to meaningfully comply with the spirit of the DMA probably would have chosen to implement the API differently.
And “trusted headphones” - all headphones, including AirPods, are untrusted until paired. This entire narrative that Apple is pushing is political, not technical.
Those are fair questions. This is what Apple says in the press release:
> Live Translation with AirPods uses Apple Intelligence to let Apple users communicate across languages. Bringing a sophisticated feature like this to other devices creates challenges that take time to solve. For example, we designed Live Translation so that our users’ conversations stay private — they’re processed on device and are never accessible to Apple — and our teams are doing additional engineering work to make sure they won’t be exposed to other companies or developers either.
We know it isn't necessary because Apple believes it is possible and are working on it. That's a pretty good indication that Airpods and their associated stack are currently being treated differently for a feature which fundamentally boils down to streaming audio to and from the headphones. It's not even clear how 'securing' live translated audio is any different from 'securing' a FaceTime call in your native language. I think a reasonable reading sans more technical information from Apple is that they give Airpods more data and control over the device than is necessary, and they want us to be mad at the DMA for forcing them to fix it.
Agreed. There is no sane reason why live translation and/or its privacy properties should depend on the specific headphones used. Even if the live translation were to happen in the headphones themselves, that should only tie the availability of the feature to the headphones. The privacy implications ought to be orthogonal.
I see three possibilities. Either the whole thing is made up entirely by Apple for bad faith reasons. Or some non-technical person with bad faith motivations at Apple suffered from some internal misunderstanding. Or somebody at Apple made some incredibly bad technical decisions.
Basically, there's no way that this isn't a screw up by somebody at Apple in some form. We just can't say which it is without additional information.
Official communications to an international governmental agency are surely checked by multiple employees and subject to review by lawyers, marketing, C suite, etc.
Apple said what they said. It wasn't a mistake. It was attempted deception.
Hmm, couldn’t Apple solve this properly with better technical measures? Right now, we have “Apple swears that its first-party AI system won’t exfiltrate data even though the OS doesn’t stop it from doing so” and “Apple doesn’t trust other vendors to pinky swear not to exfiltrate data”.
But Apple could instead have a sandbox that has no Internet access or other ability to exfiltrate anything, and Apple could make a serious effort to reduce or eliminate side channels that might allow a cooperating malicious app to collect and exfiltrate data from the translation sandbox. Everyone, including users of the first-party system, would win.
You can probably pretty easily just say Prime==Performance and Performance==Efficiency, but I think the "Prime" branding is kind of a carry over from Snapdragon mobile chips where they commonly use three tiers of core designs rather than the two. They still want to advertise the tier 2 cores as fast so T3 is efficiency, T2 is performance, T1 is Prime.
As an example, the Snapdragon 700-series had Prime, Gold, and Silver branding on it's cores.
