It's tempting to look at it that way; but that's being over-reductive. UIs of today are not the UIs of 20 years ago. Users expect much more from today's UIs, and UI toolkits necessarily get more complex as a result in order to deliver on those increased expectations.
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.
Not as much of a lack of seriousness as excusing away hallucinations as not that big of a deal in what's supposed to be a researched, scholarly body of work written by humans.
> 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.
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.
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.
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".
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.
> If I start calling "bananas" "apples" then I devalue the meaning of the word "apple". You can't differentiate which I'm referring to.
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.
> And the FAA won't become involved unless you're pointing them skyward.
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.
The best solution for dealing with AI content slop flooding your eyeballs is to hang out in places small enough to be a community -- like a local area mesh network.
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.
Depends what you're actually storing. There are plenty of cases where the timezone is not metadata; it defines how the datetime should be interpreted.
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.
It doesn't to me. It should be obvious that there are plenty of valid uses of dates and times which implicitly refer to either an exact instant in time, or the expression of a time in a certain reckoning.
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.
That's absurd. The system should be able to update itself without fear that it's going to break anything. The user should not be expected to have to set aside time to babysit an update.
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.
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.