esoterae

Honestly, this is a reasonable itemization of experience with individual tools, but this reads like a recipe for Company Cake instead of a case-by-case statement of need, selection, and then evaluation. Cargo culting continues to wrap its tendrils around the industry and try to drag it into the depths of mediocrity, and this largely reads to me like a primer for how to saddle yourself with endless SaaS bills. I recognize that every situation has its nuances, but I think approaching running a company from "what tools do you use" is pretty much the biggest possible example of ignoring that maxim.

The full aphorism is:

Jack of all trades, master of none, is oftentimes better than master of one.

If a vegan LLM evangelist crossfitter comes up to you at party, which one do they talk about first?

What a remarkable stalking horse to try and kneecap right-to-repair by arguing "Please, think of the chil^H^H^H^Hhackers!"

You wouldn't download a CAR, would you? You wouldn't hack your own INSULIN pump, would you?

Face it: If it's GPL and vulnerable to interference, responsibility is squarely on the manufacturer and the fastest death-free way to prove it. If it's GPL and modified by the owner, fuck off.

I think their point was that there is no empirical definition of information as it relates to the observer. The expurimint you cite worked upon a physical system that already had a state prior to the expurimint.

If everything is information, then nothing is.

A disordered system still has state. You just don't know what it is.

The whitespace thing is actually one of python's major flaws. That feature attaches syntactic meaning to non-printing characters. From a human standpoint, there're many examples of silence having some kind of meaning. From an engineering standpoint, that entire methodology is insane. Communication needs to be positive and deliberate.

Remember that Apple SSL bug "goto fail"? That was a whitespace bug, because even if the C feature predated python, everyone's eyes had been trained to slide right off that particularly crass shortcut as python was widespread by that point.

Where does one begin with this kind of fallacy-ridden mud slinging? Appeals to both authority and majority, and guilt by location just to name the first three.

So what if "everyone in Seattle hates AI"? What gives The Author the right to simultaneously invalidate Seattle's comparatively immeasurably larger advantage in experience, qualification, and education? If even the ludicrously biased title had even the barest hint of truth to it, they've stacked the deck against themselves in credibility unless they've already mentally biased themselves to blindly dismiss anyone that doesn't mirror their own now blatant fanaticism. Which we've already established now includes all of Seattle.

So put this out on the curb with the rest of the garbage meant to inflame and divide, because on it's face it is neither reasonable nor factual.

Where do any of us stand but on the shoulders of giants?

There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious deficiencies.

  -- C. A. R. Hoare

Reading this as a pilot, this thing reads like a primer for How Not To Think.

The author might think they're being a meta-pirate by saying "oh these are all possible actions proscribed by most organizations" implying that the proscription itself is a sign of ossified incompetence, instead of identifying the underlying one-true-savior fallacy that underpins it all.

The general danger here is human error. The point of leveraging a collaborative environment is to design process to detect and remediate human error before it radiates outward into more cost. The farther it goes, generally, the higher the cost, non-linearly. It shouldn't be "never do this", but instead "if you're going to do this use every tool at your disposal to make sure it's done correctly." Siloing the entire decision tree to yourself is exactly how not to do it.

They did really well in some things like ... devops

Did they, though? I ask because the vast majority of people touting LLM as a huge win usually seem to speak from a.. DK-heavy perspective. As in, the bulk of their profession experience hasn't actually been doing the subject they're gushing about the LLM crushing.

So I ask you, what is your level of devops experience to make such a dismissive, sweeping statement? I am pointedly inquiring about my own area of expertise, in case that wasn't clear.

While we're exposing implied things, let us also expose the assumption that this was posted by a real person (:

The driver of this output is a uniform lack of comprehension all the way down.

we shouldn't focus on how a word is defined in dictionary [sic], but rather ... the ... meaning behind it.

This is a spectacularly, objectively invalid take.

Did you not notice how this started over someone saying "That's not the definition of memory safety" and then prevaricating about the bush when asked to provide their definition? Your theory that this is an argument over semantics is correct, but not fully understood.

As a touch typist that learned decades before learning vi, with Emacs in the middle, I can definitively say your blanket statement is false. And as a recovering Emacs user, I can also say the little finger thing for a repetitive key is a dangerous proposition with real potential health drawbacks.

I think you've made a fundamental mistake. Whether or not someone understands software is not based on their job title or their desires. Nor does typing to an anthropomorphized language model expand the understanding of software. It may provide the material necessary to help someone learn, but learning is a change in behavior as a result of experience. You must fail at something in order to prevail. Using LLMs to work around failures without understanding how they occurred and why those failures were possible will not provide learning, but instead prompt the same behavior: Asking an LLM. Same behavior, same result.

I'm confused; which one is it? The property owner pays 20k, or the ratepayers are subsidizing it?

Also, my pge statements now have a line item for transmission that's usually larger than my generation total. If I have 2x solar and I'm feeding my neighbor, are they paying the same "transmission" structure for the power I'm providing them?

The fact that this must occur to address even a portion of humanitarian necessity is an indelible indication that our current government systems are incompetent likely through capture.

Keyboards in aircraft instrumentation certainly do NOT predate electronic devices. Given that one-handed operation for instrumentation is almost always the primary mode of interaction, and instrument panels are really just face-plates on quite deep electronic device containers, the idea of a widescreen panel hole profile just to fit the input keys in a different format/aspect ratio does not make sense.

Some of the most interesting aviation research in the past few decades have been around human factors like psychology, perception, and cognition. If there was some substantial effect to having the buttons be arranged in a different pattern, I do legitimately hope it would have been found by now.

Do keep in mind these devices are cost-prohibitive in the extreme to design, build, and certify. The idea of having separate, parallel processes in order to have a different button layout between regional devices creates a thousand headaches of its own, both before and after production. The issue goes even further, in that just the FAA alone requires simulators of these aircraft to have replicated button look and feel criteria that would make your head spin. Is there even going to be a question as to if you're going to have to have two simulators? Will type-ratings be transferrable? Will there be separate differences training and/or currency requirements between the two distinct input methods?

Some or even most of those answers might turn out favorably for manufacturers or operators or pilots. But just having to ask them drives costs up considerably.

I always thought of it as more of a race condition.

I have realized something quite related in my growing years of experience both interviewing and observing contributors to a technical/engineering organization

Q: Given two engineers, one incompetent and one malicious, how can you tell the difference between the incompetent engineer and the malicious engineer?

A: It doesn't matter.

I think the civil burden of proof should apply here. Upon the preponderance of the evidence. Given so many studies that exhaustively show correlative effects of phthalates with metabolic and endocrine disruption, especially strongly during developmental stages, I think even that burden of proof is met.

Sure, you can't prove something doesn't exist, but you can make a reasonable determination that given exhaustive study, given correlative negative effects can be ascribed to no other known cause, and given that this is natal and pediatric health especially at stake, we should say until such time as a causative link is proven to lie elsewhere these chemicals should not be used in consumer goods out of an abundance of caution.

The redirection of that claim would be "these profits are more important than moving to protect bodily health especially for those unable to protect themselves, given what we currently know."

Honestly, no knowledge is perfect, but upon the balance we must rest our sacrosanct right to health.

Enterprise

No, it hasn't.

You forget, the reason systemd was originally rationalized for its insertion into our trees was "boot times are too slow". Its chameleon-like nature and ability to solve the hastily described problem du jour seems to be its only consistently touted feature.

Bash scripts that start processes are ephemeral. If it's signal handling you want, that was your program's problem. Either that or your program didn't fork itself, which is a fish of an entirely different feather.

And now we have this sprawling mess of complexity and headache.

Ssh and its child processes are just another agent. Agents of a model that must be up at time-of-convergence as seen from the coordinator node; a remarkably inflexible arrangement that can only be addressed with additional development not otherwise necessary.

Ruby is far, far preferable to shell for ease of idempotence and implicit convergence.

They'll just invent a better idiot.

The way in which the author structured the language used to describe things may be the most confusing thing of all. For example:

"HEAD^ and HEAD~ are the same thing (1 commit ago)"

Followed by:

"But I guess they also wanted a way to refer to “3 commits ago”, so HEAD^3 is the third parent of the current commit, and HEAD~3 is the parent’s parent’s parent."

The author's language implies a contradiction they immediately prior said doesn't exist. If these two distinct constructs were indeed different ways to define the same relationship, the second paragraph would say "^3 and ~3 are both ways of saying the third parent of the current commit, or the parent's parent's parent." Instead, they've defined the constructs as different once again.

Lungs are usually pretty reliable, but they're still working on a long-term fix for when air becomes unavailable.

Is there some large hurdle to having two sets of bdist packages, one set compiled with frame pointer support, and the other without? Like pkg vs. pkg-devel or pkg-src?

pkg-fp, and have the dependency network trigger other installations.