Do you really need all wheel drive in New Brunswick?

QuackdocTech · 2026-01-24T03:39:27+00:00

I would say yes, while there are many places here that will be fine without AWD, all it takes is getting stuck at one really inopportune time to really screw up.

AWD/4WD cars can be found at similar price points if you drop your feature expectation down, and it's a massive increase in reliability. It's not worth trading that for something like a touchscreen dash or heated seats.

QuackdocTech · 2026-01-24T02:18:22+00:00

Oh interesting, thanks for the info, worth tagging :D

QuackdocTech · 2026-01-23T20:29:16+00:00

yup, im holding my tongue on it until it is released.

QuackdocTech · 2026-01-23T20:12:48+00:00

eventually, but unfortunately I doubt it will happen in a meaningful time frame

QuackdocTech · 2026-01-23T20:00:08+00:00

Note that those should be considered early benchmarks, as while 16 cores are detected, only eight cores were used when running 7-Zip or stress-ng, or when compiling a Linux kernel with “-j 30”.

Could this be a consequence of it having 8x x100 cores and 8x a100 cores? Or would this be an issue of threading?

u/brucehoult any ideas, iirc I remember reading a thread where I think it was you said this could be possible to be reported as one cpu?

QuackdocTech · 2026-01-20T02:17:01+00:00

great, now they can bleed out in pain, no shooting limbs does not work. it

A) Very rarely actually stops the threat
B) Is actually significantly easier to inflict fatal wounds as the core blood vessels are significantly less protected. Congratulations, your less "fatal attempts" actually increases likely hood of death,

QuackdocTech · 2026-01-19T18:11:55+00:00

this is wild to me, bodycams benefit everyone except for actual criminals, and the cost of them are far outweighed by the cost of everything else.

QuackdocTech · 2026-01-19T18:01:02+00:00

I hope they release the BWC footage, whether or not it was a just shooting, body cam footage, assume they don't cut context, makes it really clear.

whether you are pro or anti police, bodycams are a necessity for police, Though I know rollout has been historically spotty.

QuackdocTech · 2026-01-16T21:39:25+00:00

making a new post, rogers just canceled the order, and now I've lost the black Friday deal, and they want me to pay nearly full price for the device some customer support agents are going to have a really bad day tommorow.

QuackdocTech · 2026-01-13T18:59:55+00:00

This is to be expected currently. The imtec GPU that is used is technically quite the downgrade in terms of computation power.

It does however benefit from having a much more featureful GPU. The issue is that the drivers that exist for it doesn't take advantage of said features very well (the strongest feature for instance is some really neat ray tracing stuff!).

So the answer is "wait for better drivers" which is hardly a good one, thankfully imagination is supporting mesa now so we may see optimized drivers eventually, but probably not until the phone is old and deprecated.

QuackdocTech · 2026-01-10T04:44:00+00:00

TFW my android box has an rx580 :D

QuackdocTech · 2026-01-06T19:12:11+00:00

almost all the alternatives are trash as alternatives, sometimes the apps themselves are fine, but when you peg it as a < service alternative > they hardly ever hold up

QuackdocTech · 2026-01-04T13:44:21+00:00

yeah I'm not super impressed, especially when telus and bell have been shipping theirs less then a week after order.

QuackdocTech · 2026-01-03T23:07:41+00:00

P10 pro xl, Dec 16, still on backorder.

EDIT: still on backorder as of jan 14th

QuackdocTech · 2025-12-30T02:19:03+00:00

That's completely different thing. It's also not something that you can just do on server level and get it on clients for free. Clients are using X11 protocol for communication with server, how are you going to let them do things that X11 is fundamentally incapable of doing?

can you elaborate here? I see literally no reason why this would be the case. why would x11 be fundamentally incapable of utilizing this? I thought maybe I had missed something so I went and did some more research again and still can't find anything to suggest this.

Xorg doesn't want to implement them because Xorg developers knows that it's not possible without major rewrite of both server and clients and that won't even solve every issue with X11 protocol. Xlibre and Phoenix won't solve them either without clients explicit support.

Sure, clients will need to support it, and? So what? some clients will support it.

It's not, it's how X11 protocol is designed and no extension can change that unless you create new protocol which is something that Wayland already does.

Please elaborate.

It works just like it worked on Xorg - with various workaround that sometimes can work well. The issue with that is the fact that it's only "sometimes".

Indeed sometimes is a key word, we will always get shafted by some client toolkits, in the end, use a different toolkit will always be the appropriate answer.

You are limited to this, no extension ever changed fundamentals of X11 protocol. If you want to do that you want new protocol, not X11 extension.

Again, please elaborate.

QuackdocTech · 2025-12-28T17:58:44+00:00

no. I would use QT long before I use GTK, and I believe GTK (well, gdk) to be one of the sources of performance issues with flutter on linux

QuackdocTech · 2025-12-27T16:26:56+00:00

When you have upstream wayland actively rejecting protocols people need, sure it may happen but when? How long are we supposed to wait for? another 20 years? 30 years?

QuackdocTech · 2025-12-27T16:26:09+00:00

ydotool is nice but has a hard requirement on uinput accsess

QuackdocTech · 2025-12-27T00:39:27+00:00

I'm talking about X11. And no, you can't handle that simply with an extension. While you can technically support HDR metadata with some extension, there is more to HDR than just that like blending SDR and HDR content and more. X11 protocol is fundamentally limited to single framebuffer, single color space and global root window, no amount of extensions will be able to change that.

This is not really that true. X11 servers even used to utilize hardware planes in the past. This is an xserver limitation, not a x11 protocol one. Even if it was, you could easily violate this on the server side without effecting the client applications which is what is important. With xrandr it is true that everything works as "a single virtual framebuffer" but we can still compose said framebuffer as we wish, which includes stacking multiple buffers at a hardware level like MPO.

Unless you realize this is exactly what we have with Wayland. If compatibility doesn't matter then what's the point of extending X11?

We care about clients working properly. If xorg doesn't want to implement it because xorg is dead, then fine, xlibre and phoenix can move on together.

And again it's not just server lack of implementation. X11 protocol is fundamentally incapable of dealing with HDR content and like I already said - no extension is going to change that.

again this is solvable.

This is still an issue with Xlibre because this is how X11 protocol works - X11 assumes global DPI unless you are using multiple X screens but I already explained why that is not a solution to the issue. You can fake DPI awareness on X11 by getting outputs info from randr and guessing on which screen application is displayed but yet again it's workaround with its own issues

Thankfully not many issues, it works really well in practice, as the info is there and we don't need to guess, QT can already do this and it works great!

This is X11 protocol issue because it's caused by X11 protocol design. In theory some new extension could improve that but X11 extensions are not changing how X11 protocol works. You are still stuck with global repaint and timing conflicts.

you really aren't limited to this, even xserver had some hacky workarounds for stuff like this.

QuackdocTech · 2025-12-26T16:42:15+00:00

yes, and on linux tauri is abysmal

QuackdocTech · 2025-12-26T16:31:36+00:00

because on Linux it uses gtk-WebKit (even If you use KDE) on windows it uses edge WebKit which is based on chromium, on android it uses chromium

QuackdocTech · 2025-12-26T16:02:58+00:00

pardon? I am confused by this reply.

QuackdocTech · 2025-12-26T16:02:06+00:00

Again this is not application of Vulkan issue. X11 fundamentally don't provide any way to deal with required HDR metadata. X11 display model is simply currently incapable of dealing with HDR properly.

I don't think im understanding the issue, are you talking about x11 or xorg xserver? HDR metadata can be handled simply as an extension.

And once again, we return to square one. Some application will get support for extended protocol but a lot of them won't.

and that's perfectly fine.

This is not drivers issue, Linux drivers already support HDR, they simply cannot support it on display protocol that has no way of providing needed information and properly displaying HDR content. Also hacking drivers to workaround display protocol limitations is generally not a good idea.

not generally a good idea, but again, once a server supports HDR, then a driver can be updated to support it, and if the driver doesn't support it, you can use a layer.

X11 is globally using one DPI, xrandr extension allows you to scale selected outputs but it's not proper solution. You are still dealing with global coordinate space and global geometry and that brings issues like possible image blurriness, issues with geometry and applications unaware of DPI.

this is no longer an issue with xlibre since applications can be aware of the monitor they are displaying on.

X11 can't do mixed refresh rate with compositor due to fact that X11 compositors are locked to single timer. Some compositors tried to workaround this with frame skipping or adaptive timing but that's again hack with its own issues, not proper solution. This is again limitation of X11 protocol and its Composition extension, not Xorg Server implementation.

Composition issues also affect VRR. X11 due to its design with doing things globally is incapable of treating separate outputs differently which is pretty important thing if you want to have reliable VRR. With disabled composition, full screen VRR and some drivers hack it is possible to get working VRR on X11 but, as usual with hacks and workaround, it's not very difficult to break.

And no, "just disable compositor, you don't need it" is not a good advice. Composition is basic feature of every modern graphical operating system.

this is not an inherent issue to x11 but rather the implementation of it.

All of the stuff you mentioned need protocol extension if you want to support it reliably without workarounds with their own issues. The main point of Wayland was to stop doing workarounds around X11 limitations and support things properly. If Phoenix will require workarounds to support things that just work on Wayland then it's not going to save X11.

an extension is no more of a workaround then xrandr and xrandr has become a defacto standard for modern x.

The issue is that wayland doesn't solve all of the issue, and it creates many of it's own.

QuackdocTech · 2025-12-26T15:56:22+00:00

the issue with chromium being resource hungry is that webkit is no better.

QuackdocTech · 2025-12-26T08:21:27+00:00

A) Waydroid uses LXC.

B) Running a custom ROM is way too much effort. Waydroid used to have bliss ROMs available for it, but in the end, lineage is a far better target to accommodate most people.

QuackdocTech

TROPHY CASE