> how do you exactly know how javascript works inside out?
Javascript has pretty detailed specifications. They're not exhaustive, but the article here does mention that in some of the dark corner cases they compared behavior against other existing Javascript engines.
There's also a very comprehensive test suite (Test262) that comprises almost 40,000 unit tests that exercise various aspects of the language that a new implementation can use to get a pretty good view of how much their new engine conforms to the specification.
> I sat through a conference session in the late nineties trying to understand the difference between an OLE document, a COM object, and an ActiveX control.
To be brutally honest, if you were a serious Windows developer in those days (and you were even the sort who'd have sat through a conference session on the topic); there is absolutely no way in hell you'd not understand the difference between OLE, COM, and ActiveX. Conflating these things as some sort of confusing mess either shows a lack of actual experience, a lack of competency, or a desire to falsely make things seem more confusing than they were to add some meat to an article.
This article dances with some good points, but opening up with this sort of hyperbole (and then ending it with an unabashed AI slop image filled with brand new hallucinated characters of the alphabet) just totally tanks the author's reputation.
This particular vehicle was sold at an impound auction under a court order. Any existing legal ownership of the vehicle prior to the auction was extinguished.
There was a software package a couple decades ago, I want to say it was Lotus Notes but I'm pretty sure it wasn't actually Lotus Notes but something of that ilk, that would show a small, random number of asterisks corresponding to each character entered. So you'd hit one key and maybe two asterisks would show up on screen. And kept track of them so if you deleted a character, it'd remove two.
I thought that was kinda clever; it gives you feedback when your keystrokes are recognized, but it's just enough confusion to keep a shoulder surfer from easily being able to tell the length of your password unless you're hunt-and-pecking every single letter.
Yup, it was Notes, I used it at IBM. It was an unbelievably stupid idea. Every single day people were asking why their password was wrong because they were confused by the line of stars being too long.
Yeah, I remember Lotus Notes both showing multiple filler characters per keystroke and showing different keychain pictures based on the hash of what you typed. This way you could also tell you've made a typo before submitting it.
If the hash changes after every character, doesn't that make it possible for someone to determine your password one character at a time if they know what each hash was?
I'm guessing that wasn't in the threat model at the time.
Hmm. Let's say you have 64 possible characters you can use in a password and four different images. You look over someone's shoulder and see that they go "RGBYYBRYG".
What this means is that you can now reduce your search space to approximately 16^9 passwords instead of 64^9 passwords. Which is probably very helpful if you have stolen the password hash, but not if you have to guess it by entering the password manually.
Makes sense. I was under the impression there were more than 4 outputs based on what you entered. (I've seen a similar setup that shows two hex digits)
It's still baffling, since the core idea of React only makes sense as a workaround for limitations of the browser DOM. Wrapping much more flexible 'native' widget frameworks with a React layer is pure cargo culting (same with SwiftUI).
ok, granted, but microsoft already builds a first party way to orchestrate a UI comprised of native controls. Why do they invest so much effort into WinUI and C# if they're just going to use a 3rd party solution? Presumably the windows 11 start menu does not need to run on macOS or Linux.
Because it uses C++, and C++/WinRT tooling for UI development isn't there.
The team that killed C++/CX, said it isn't their problem that there aren't Visual Studio integrations like C++/CX, and eventually left C++/WinRT in maintenance and nowadays is responsible for windows-rs repo. Better not expect too much from that repo as well.
Hopping in here to suggest that instead of running a persistent whole-ass daemon, you could just configure a systemd service, set it up to trigger off a write to a fifo, and then use filesystem permissions to restrict access to who can write to the fifo to whatever user/group should be allowed to perform the operation. (You can also do it by giving those users sudo access specifically to be able to trigger the service via systemctl; but if our goal here is to eliminate the use of setuid then any solution that uses sudo fails the assignment).
The systemd service executable is just your simple C program as-is.
Persistent whole-ass daemons aren't really the way it should be done even over in Windows, because in Windows you can attach ACLs to give permissions to start a Windows service to any arbitrary users that should be able to do so; which is spiritually equivalent to the Linuxy systemd solution.
It's about being able to perceive it as a "living" moving creature and not something different.
You can understand something below the perception threshold is supposed to be a creature because you both have a far more advanced brain and you've been exposed to such things your entire life so there's a learned component; but your dog may simply not be capable of making the leap in comprehending that something it doesn't see as living/moving is supposed to be representative of a creature at all.
I've personally seen something adjacent to this in action, as I had a dog over the period of time where I transitioned from lower framerate displays to higher framerate displays. The dog was never all that interested in the lower framerate displays, but the higher framerate displays would clearly capture his attention to the point he'd start barking at it when there were dogs on screen.
This is also pretty evident in simple popular culture. The myth that "dogs can't see 2D" where 2D was a standin for movies and often television was pervasive decades ago. So much so that (as an example) in the movie Turner and Hooch from 1989, Tom Hanks offhandedly makes a remark about how the dog isn't enjoying a movie because "dogs can't see 2D" and no further elaboration on it is needed or given; whereas today it's far more common to see content where dogs react to something being shown on a screen, and if you're under, say, 30 or so, you may not have ever even heard of "dogs can't see 2D".
I mean it's a dog so you can't exactly ask them; but this was a dog that would bark at every other dog. If he wasn't barking at Hooch because Hooch was only showing up at 24 FPS, then I'm inclined to think he didn't recognize Hooch as another dog.
The use cases for YAML that don't involve any sort of scripting vastly outnumber the use cases for YAML that involve embedding scripts into a document; so it's a little unfair and inaccurate to say that "in YAML it's kind of expected".
It is more fair to say that if your document needs to contain scripting, YAML is a better choice than JSON; for the singular reason that YAML allows for unquoted multiline strings, which means you can easily copy/paste scripts in and out of a YAML document without needing to worry about escaping and unescaping quotes and newline characters when editing the document.
The more SKUs you have, the more digital shelf space you get on a shopping website. When your sole differentiating factor from your competitors is that your laptop has an "HP" logo on it and theirs has a "Dell" logo on it, your only effective strategy is to try to make sure fewer laptops with "Dell" logos on them show up above the fold in Amazon search results by creating lots of distinct SKUs to try to eat up as many of the slots on that first page of search results as possible.
Apple doesn't have to exist in that type of competitive environment. If you want a Mac, you're either getting it right from store.apple.com; or you're searching for Macs specifically -- in both cases, Apple owns all of the shopping screen real estate.
> how do you exactly know how javascript works inside out?
Javascript has pretty detailed specifications. They're not exhaustive, but the article here does mention that in some of the dark corner cases they compared behavior against other existing Javascript engines.
There's also a very comprehensive test suite (Test262) that comprises almost 40,000 unit tests that exercise various aspects of the language that a new implementation can use to get a pretty good view of how much their new engine conforms to the specification.
reply