My first pass through the title was "Those windshield wipers shouldn't need to be internet-connected."
Thankfully, the article did clear that up, but the fact that my brain didn't even think, "that's a stupid idea that no one would buy that" is a bit depressing.
Well, obviously, your car can count cycles on the electromotor moving the wipers. Then you apply statistical wear and tear, maybe even geofenced, and your car orders new wipers. Same with tires. Simple as pie ;)
Not the original person, but I'd like to see the ACTUAL install instructions, a la the vscode via the microsoft repository. It's a little more work for the user, but, honestly, the user is using a CLI for managing packages - I think three lines that show clearly what's going on is reasonable.
Just showing me what it's gonna do and giving me the clear option to do that instead of curl | bash would make me feel better.
Microsoft also has a "download deb and install", which I still consider slightly better than curl | bash; it's basically the windows install flow. People who are using a GUI can just double click it, people who want to see what it's going to do can examine it, and your (unsafe) one-liner is `curl XXX.deb && dpkg -i XXX.deb`. Plus it can be shipped to a multiple machines at once easily.
Try to avoid using it until the microcode fix in a week or two. If you bought it last week, you probably haven't used it enough to permanently damage anything from the voltage issue yet.
Keep careful watch of problems in the future: the oxidation issue for the 13th gen is a physical defect not fixable by the microcode update, but we don't know how widespread it is yet (and Intel is keeping mum). If possible, it might well be worth returning and getting a 14th gen chip, which doesn't suffer from the latter problem and the former will be fixed by microcode.
No known safety issue. Both issues (the overvoltage in both 13 and 14 gen chips, and the oxidation that's limited to 13th gen) lead to system instability. How quickly these occur is unknown from the Intel reports. Claims are as little as a few weeks, but independent verification is needed on that one.
In Windows, it's kinda split between the Windows Display Driver Model (WDDM) and the Desktop Window Manager (DWM). That's not a 1:1 match, though, as those two combined cover more components of a functioning whole than X11/XOrg itself does. X11 just split the components needed to draw everything you'd need for graphical environment into a different choice of layers.
X11 got network transparency out of the box (a sibling comment touches this), and the capability of switching out the components more easily, while Windows had less work to do to smooth out the overall desktop experience.
When using Perl you should `use strict; use warnings;` and you have something approaching a real language with a lot fewer warts, in which said quine is not a valid program. It isn't the default because Perl people have an obsession about not breaking backwards compatibility.
I think the people that love perl love its expressiveness. It has a little bit of functional programming here, and a system for making an object-oriented language, and all of these handy tools and you choose which ones you need or find most readable. I've heard Ruby called a better Perl, and - as someone whose day job is largely those two things - that's completely fair.
Many moons ago, I made a case for making strict mode the default in Perl. We settled on the current backwards compatibility compromise, which is that breaking changes are hidden behind a minimum version toggle:
Eg. putting "use v5.14.0;" or similar on top of your file (or compilation unit/scope) will indeed turn on strict mode for you, along with adding a number of features as well.
At the time, also auto-toggling warnings was considered unacceptable because technically, using the warnings pragma anywhere had some edge case action at a distance. This has been remedied in some later release after I wasn't involved in the language development anymore, and from some more recent version, warnings are also part of the standard import.
I imagine you (TheDauthi) already know that, though.
Rails is magic, both in good and bad ways. The good generally outweighs the bad. And it has things (like Sidekiq) that I typically need in a project, and I don't have to waste time putting it together and can worry about getting stuff done in my developer role, and code quality in my team lead role. I do use Rust in some performance critical stuff - I used to use C++, but Rust just feels good to write, like Ruby. We have typescript on the front-end, but everything's React and React just never clicked for me in the "this feels natural to write" sense, so I don't venture into that realm often.
We don't have trouble hiring, other than the usual "not enough money in the budget" problems.
Thankfully, the article did clear that up, but the fact that my brain didn't even think, "that's a stupid idea that no one would buy that" is a bit depressing.
reply