drysart
You can use the same API to configure and run code in a WSL Container as you would to run them in an LXC container on Linux, or Seatbelt sandbox on MacOS; or in a MicroVM or a Hyperlight VM.
Those who understand law know that formal verifiers cannot replace a judge, because every facet of law (the writing of it, the interpretation of it, the application of it, and the enforcement of it) has to account for all the vagueries of human existence.
No formal verifier can account for definitions that need to expand as the scope of human endeavor expands. No formal verifier can determine mens rea. No formal verifier can determine if something is obscene. No formal verifier can determine someone's mental competence. No formal verifier can cover all mitigating factors. No formal verifier can apply mercy where mercy is needed.
body { --resolution-scale: 1; }
@media (min-resolution: 2dppx) { body { --resolution-scale: 2; } }
@media (min-resolution: 3dppx) { body { --resolution-scale: 3; } }
.myPixelSizedElement { width: calc(96px * var(--resolution-scale)); }
And if you don't agree, this is Windows we're talking about. Nothing's stopping you from creating your application with Win32 except for the fact that it's going to look and feel like an application from 20+ years ago.
> 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.
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.
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.
React Native is a way of orchestrating a UI comprised of native controls.
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.
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".
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.
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.
In French, potatoes are called what translates to English as "apple of the earth". Nobody confuses a pomme de terre with an apple, because nobody calls a potato an apple without the adjective attached.
That's what the additional adjective as part of the title is for; like how apples and potatoes are vaguely related in that they're both plant-based food but are otherwise entirely different; turning "software engineer" into a compound term that has the extra word is specifically to differentiate it from expectations of it not having the extra word.
Software engineering is legitimately engineering going by the etymological meaning of engineering; but it's not really one going by some of the other (mostly orthogonal) things we've layered onto the term in many contexts over the years. It's creation through ingenuity. It has as much claim to the word as part of its title as any other usage of the word does.
The point here is that 'skyward' is where the laser's beam goes when you're trying to aim it at a camera up on a pole. It's practically impossible to point a non-fixed position laser at something a non-trivial distance higher than you without spilling a large amount of laser beam into whatever happens to be behind your intended target; which is very often the sky.
AI slop thrives in anonymity. In a community that's developed its own established norms and people who know each other, AI content trying to be passed off as genuine stands out like a sore thumb and is easily eradicated before it gets a chance to take root.
It doesn't have to be invite-only, per se, but it needs to have its own flavor that newcomers can adapt to, and AI slop doesn't.
For example: your local mom and pop corner store's daily opening and closing times. Storing those in UTC is not correct because mom and pop don't open and close their store based on UTC time. They open and close it based on the local time zone.
A birthday doesn't have a time zone because the concept of a birthday is more about the date on the calendar on the wall, not any universally understood singular instant in time; and so what matters most when it comes to your birthday is where you are. Your birthday doesn't move to the day before or after just because you travel to the other side of the globe.
A deadline has a time zone because when your boss says he wants the project done by 4PM, he means 4PM wherever you both currently are -- and the specific instant in time he referred to doesn't change if you get on a train and move a time zone over before that 4PM occurs.
And it may in fact be time zone and not just UTC with an offset; because if your boss tells you he wants a certain report on his desk by 4PM every day; when your local time zone goes into daylight saving time, it doesn't suddenly mean the report needs to be filed by 5PM instead.
In the first of these cases, the date itself has no time zone and is valid in whatever context its being read from. In the second, the instant in time might be expressed in UTC time with or without a specific offset. In the third, each of the successive instants in time may shift around with respect to UTC even while it continues to be referred to with one constant expression.
None of these are subjective interpretations. They're a consequence of the fact that as humans we've overloaded our representation of date/time with multiple meanings.
Windows isn't perfect in this respect by any means, but it sure seems like it handles updates a lot better than the distros that have been mentioned in this thread; in that Windows at least takes steps to examine your hardware first and to not apply updates where it's known something has fallen out of support.
Windows also, apparently unlike these mentioned distros, maintains a Last Known Good configuration so if an update does start causing failures, it can automatically roll itself back (or, at worst, can manually be rolled back). There are some distros that do similar, particularly immutable distros; but honestly this sort of thing should be table stakes to the point that if a distro doesn't do it, it should be laughed out of the room.
There is absolutely no acceptable excuse for any operating system to break itself in an update.
There's a lot of lore you pick up with Javascript when you start getting into serious optimization with it; and one of the first things you learn in that area is to avoid changing the shapes of your objects because it invalidates JIT assumptions and results in your code running slower -- even though it's 100% valid Javascript.
There's a lot of prerequisites for DOM access from WASM that need to be built first before there can be usable DOM access from within WASM, and those are steadily being built and added to the WASM specification. Things like value references, typed object support, and GC support.
Taking the website down entirely or just blanking it out is a very, very different matter than replacing it with a different message; and doubly so when the different message is actively harmful to the customer. Unless the designer's contract with the customer explicitly allowed them to do this, this sort of thing is a slam dunk legal case of either vandalism (using a physical metaphor) or in the UK as in this example, a criminal violation of the Computer Misuse Act.
Not to mention that it's an enormous red flag that will scare away other potential customers for this designer; because it demonstrates that you're very willing to sabotage their operations.
And on top of your other concerns, this quoted bit smells an awful lot like 'security through obscurity' to me.
The people we really need to worry about today, state actors, have plenty of manpower available to watch every commit going into the kernel and figure out which ones are correcting an exploitable flaw, and how; and they also have the resources to move quickly to take advantage of them before downstream distros finish their testing and integration of upstream changes into their kernels, and before responsible organizations finish their regression testing and let the kernel updates into their deployments -- especially given that the distro maintainers and sysadmins aren't going to be moving with any urgency to get a kernel containing a security-critical fix rolled out quickly because they don't know they need to because *nobody's warned them*.
Obscuring how fixes are impactful to security isn't a step to avoid helping the bad guys, because they don't need the help. Being loud and clear about them is to help the good guys; to allow them to fast-track (or even skip) testing and deploying fixes or to take more immediate mitigations like disabling vulnerable features pending tested fix rollouts.