I'd guess that the issue is running the `%install` and `%check` stages of the .spec file. The Python library rpy (to pull a random example from Marcin's PRs) runs rpy's pytest test suite and had to be modified to avoid running vector tests on RISC-V.
Obviously a solvable problem to split build and test but perhaps the time savings aren't worth the complexity.
Maybe the tests could be run with user-mode qemu instead of the whole thing running under qemu or on RISC-V hardware. Could possibly be more or less seamless with binfmt_misc being set up in the builders.
> If any Linux distro manages to replicate even 80% of the smoothness and functionality of a Mac trackpad experience, I'll switch
I find Niri to be a great WM for trackpad use if you are amenable to a scrollable-tiling workflow. All gestures are inertial like MacOS and to my fingers they often feel snappier and more natural than their macOS equivalents. Scrolling is consistent and natural, though which apps have inertial scrolling is definitely hit-or-miss. It perfectly recognizes three and four finger gestures. PikaOS (debian-based) and CachyOS (arch-based) both offer Niri as an option if you want to give it a try.
For context, my experience is on a 4 year old thinkpad which admittedly is probably best case for driver support but is definitely not the best touchpad hardware on the market.
Thanks for the recommendation! I've been playing around with Niri for the past hour and I have to say there's a lot here that I like. I'm still going to need to figure out how to adjust the trackpad gesture sensitivity a bit (which doesn't seem especially straightforward to do) - but this is considerably more buttery than anything I've experienced before on Linux
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.
https://github.com/dockcross/dockcross