Not really. “Industry standard” just means it’s commonly used in the industry. “Open specification” is the opposite of “vendor locked”, e.g. OAuth for authentication.
Not really. “Industry standard” just means it’s commonly used in the industry. “Open specification” is the opposite of “vendor locked”, e.g. OAuth for authentication.
Eh, things have gotten better, and there are tools that make these tools respect them.
I have good news and bad news:
A specification already exists. https://specifications.freedesktop.org/basedir-spec/latest/
I’m not saying Rust is better for all applications, but IMO Golang has a pretty bad readability due to the “simplicity” they keep adhering to. Heck, even their generics support is still pretty terrible, and that’s a fundamental feature for properly readable code.
Golang is almost never the best choice
Your experience with other extensions sadly doesn’t mean much for Pylance. It specifically has DRM implemented to prevent vscodium from loading it, just like some other MS extensions. That’s why I’m asking.
Hm, people in the GitHub issue are still complaining that it doesn’t work. Does it work fine for you?
Is there a stable way to use closed extensions (like the MS Python one) with vscodium by now? I’d love to get away from MS’ grasp, but it’s much harder if I’ll be missing out on language integrations.
Would probably be doable with a browser extension, but that’s quite a hassle.
Not sure there’s a better way to say it. I guess “the SteamOS fork of the Linux kernel” would be more explicit, but I assume most people who would read this are aware that SteamOS is built on Linux.
Well, he’s talking about the kernel they are using in SteamOS. The Deck OS is also being extended to other handhelds.
Though this also has advantages - not only will they be drawn at an appropriate resolution, they can also be styled & modified by the user. If I’m using Dark Reader and your icons are SVGs using currentColor
, they’ll render with the same color as other text. The best you can do for raster graphics is inverting them.
That sounds really cool, thanks for letting us know!
Just like the ocean is the best body of water for children who want to learn about swimming
Okay, let’s call it a semi-rolling release. Having breaking changes every 6 months is still very often for a set-and-forget system.
While I enjoy using Aurora, there were a bunch of issues popping up over the last few months (e.g. display freezes). I guess that’s the danger of a rolling release cycle, but I’m not sure it’s 100% as foolproof as it needs to be right now.
I’m not at a computer with the source on it, so if you get to it before me, how many rust drivers are there? How many that would use the rust dma wrapper?
… of course there aren’t many Rust drivers so far, since the project is still young, and it’s evidently still facing hurdles and not really accepted by everyone. But if there’s already a couple of Rust drivers and Rust has explicitly been accepted into the Kernel, we’re already past your “this would make it easier for hypothetical rust drivers that might hypothetically exist in the future”, so why argue such irrelevant points?
More broadly there are times when duplicated c code has been condensed into a library or something and added to the kernel.
And that’s what has been blocked here…
Yes, literally include the wrapper code in every rust driver that needs it then when you push the wrapper on its own you can say “this code is currently duplicated 900 times because there isn’t a rust wrapper” not “this would make it easier for hypothetical rust drivers that might hypothetically exist in the future” and no one will bat an eye!
That is what they are already doing and it’s introducing unnecessary work! There’s nothing about “hypothetical rust drivers”, it’s the case right now.
That’s how you get things added to the kernel!
Weird, how come C drivers don’t have to track these interfaces in their own trees? Why is this the way to get Rust code added to the kernel, but all other code doesn’t have to jump through these hoops?
No, sorry, you’re just wrong. An “industry standard” can be anything that’s normal in an industry, e.g. a particular tool. Photoshop for example is an industry standard, but it’s not an open standard in any way.