undoware

"Error establishing a database connection"

Moreover, dang, look at the vibe you're managing. This is on you, boo:

1. A group of people repeatedly use a euphemism to attack a much smaller and less powerful group 2. When a member of that group points it out, the comment is literally faded, erased, by the editor responsible for managing the tone of that more powerful group

And before you say it, this is me assuming good faith. I know you don't hear it. You're not evil. Neither is (most of) HN.

But this is legit every day now. I've been a contributor to HN for over a decade, but now I hesitate before letting my fingers type 'news.ycombinator.com' into that location bar.

It simply hurts too much. Like someone putting glass in your porridge.

Also, I recommend reading _On Freedom: Four songs of care and constraint_ by Maggie Nelson.

On paper, yes, this is how the business works.

In practice, I've seen lots of situations where, for want of time and designers, engineers received vague instructions and were mostly left to their own devices.

Engineers were making significant contributions to the design process without noticing; and many of them were, as you might expect, not thoughtful. After all, the coder was being paid to code, right? Not their job.

You might argue that we could fix this by hiring more designers (you should anyway, but not for this reason). But without engineer understanding, you may wind up with a design team micro-managing a team of engineers.

To me, this appears to be a recapitulation of the 'architect-vs-tradesman' dichotomy seen in the building construction industry, with UX experts playing architect, and the engineers playing extremely-well-paid plumber.

Under these circumstances, no engineer wants to build anything unless it's been signed off in quadruplicate, complies with all extant regulations and guidelines, and is exactly like the last 10,000 ones like that we did. At this point, more or less, engineers and designers begin to resent one another.

It's a full-on zugzwang: The engineers begin to think of the designers as dictatorial and unrealistic dreamers who don't know enough about code, and the designers begin to think the engineers are callous boors who, yes, are hostile (or at least indifferent) to the expectable experience of the user. Which is what I take the OP was pointing to.

While other industries may be able to tolerate this kind of vibe, none of the habits of mind and culture that I just described are conducive to anything like a good UX outcome in software development.

Far better is to have engineers who are trained to make good empathic common-sense decisions. This is important for three reasons: First, it frees up design and PM cycles; second, it generates a culture where the engineer is respected as a conceptual contributor to the user's experience, and, thirdly -- and most importantly -- it creates a person who has both design and technical expertise, and can adjudicate tradeoffs between these two things without calling a meeting.

And this third point is important for some relatively deep socioeconomic reasons -- I disagree with Hayek about a lot of things, but he was right about the value of local knowledge. (https://en.wikipedia.org/wiki/Local_knowledge_problem)

An engineer who is in the code every day may well have a better sense of what is possible (and what the tradeoffs may be) than a designer who is not on the front line. That honey-mustard combination is lost entirely on teams where engineers are not also a little bit designers, and designers are not also a little bit engineers. Think of this strategem as a 'local knowledge reuptake inhibitor'.

Thus, the aim of my programme is to create a corps of engineers who, when they see something, say something. But in order to see like a designer, you need imaginative empathy. The heart is the eye.

[pulls up chair, sits backwards]

OK so this is a question I'm arguably qualified to talk about -- I focus on usability and promoting it within a large tech company.

The problem that I see a lot is that engineers are not well-versed in what I will call 'imaginative empathy'[1], which, as I define it, is the ability to creatively conceive of end-user needs by reflecting at length on who those people are, what they desire, and what they expect, _even when the end user is a very different kind of person than the developer_, with different strengths, weaknesses, and expectations.

I'm at this moment setting up an internal programme to try to beef up imaginative empathy among engineers. My premise is that imaginative empathy is actually not hard to train for -- people in helping professions (counsellors, therapists, social workers) get pretty good at it, as do novelists; but, like any muscle, it can atrophy, and it is emphatically not something that is tested for in most interviews. Therefore, since it is not selected for, it is often not in abundance on any particular engineering team.

A book that inspired me in this approach is _Anthro-vision_, by Gillian Tett, which is a gift to anyone who makes anything for another human being, and wants them to enjoy it.

1. Empathy on its own isn't enough -- people tend to empathize most with people who are most like them. Sometimes this is enough on its own -- if you're a neovim obsessive (like me :D) and you're making an extension for other neovim obsessives, you can run on just regular empathy. But most of the code I write is not written for 'people like me', it's written for people in the general case, and that means a cognitive stretch. Imagining the Other and attempting to be of service to them requires imagination. I'm inspired in this observation by Buddhist 'metta' practice, and the ways in which the Buddhist conception of 'compassion' differs markedly from what is often called empathy by contemporary professional psychologists.

1. _The Question Concerning Technology_ by Martin Heidegger. Taught me how clean-room language reinvention can be a tool for clear thinking, and how you cannot add something without taking something away. Truth is "revealing and concealing" because it is, outside math and hard science, perspectival. Essential reading for UX engineers.

2. _Eichmann in Jerusalem_, Hannah Arendt. Made me wiser about how evil works. "Evil" is a fun word to throw around and lends itself to silly political slogans, but the real thing is no joke, is out there, and does not look like what you think.

3. _Eugene Onegin_, by Pushkin, as translated by Douglas Hofstadter (yes, that one). The man taught himself Russian by translating the Onegin to distract himself after his wife died. The foreword-essay changed how I regard language and translation.

3. _Getting Unstuck_, by Pema Chodron. I still use this shit every time I get obsessive about some coding thing. Wise AF.

4. _Getting Things Done_ by David Allen. Everything is an interface and everything is algorithmic, your only choice is whether or not to consciously intend them. You can engineer better habits.

5. A biography of Malcolm X -- I forget which one, embarrassingly, and I am in a hurry so I will not google. Whichever one came out closest to the year 2007 :)

These days tho I would grab _The Dead are Arising_ -- the most recent. It's aleady on my Kobo. Malcolm X showed me how to survive in hell and start a movement.

It's honestly like you've never seen that land.

Much of Canada -- one of the two big possible breadbaskets you said you were eyeing -- is literally forest. The forest starts where the farmland stops.

Even if you cleared the forest, the soil is worthless. It's been covered in conifers for thousands of years. It's also goopy, as it is thawing. Or sandy. Or simply too acidic.

And while it might be good enough for grasses and cattle grazing one day, that day is not today, nor tomorrow, and in the meantime, you will be quite hungry.

In the medium term: good luck replacing California's food output with northern Alberta's.

Now, one might be able to hasten the soil improvement that with some sort of complex, time-consuming terraforming ('agriforming?') process, but good luck getting that process to scale in a hurry. Or on-budget. (Have fun even making a budget for that.)

Farming is actually just incredibly hard, the land is the biggest variable. It has to be just right. You can't just declare that an area is for food production like you'd rezone a city street for residential. Nature does not care about your lines on maps.

Don't believe me? Look at the last time we tried. The same reason that turning the Amazonian rainforest into farmland has not been an awesome thing.

And who is condescending to who, here? I'm not a farmer. But neither, I suspect, are you. So why do you discount my experience? I'm from the place you were talking about.

My suspicion is that you simply cannot tolerate the ego-dystonicity of ushering in an age of starvation for our children and grandchildren. But we did it. You did it, with help.

Check the prices at your supermarket.[1] Check the collapsing populations of insects, birds, and fish. Wait for the unravel to travel further up the food chain. Tag. You're it.

And yes, it's apocalyptic. It really, really is.

If you want to throw textbooks around, please read _This Changes Everything_. Then, read _Under a White Sky_.

You will find them both in the nonfiction section.

[1] Before you get typing: yes, inflation and supply-chain disruption can be symptoms of climate change -- specifically, when both are occasioned by a pandemic, which is the sort of event that becomes more common as habitats are squeezed up against one another. There will be more, faster now. I did PhD work on this, back in '05, in the aftermath of SARS-CoV-1. Like.

rubs face ok so here's the thing. Food grows in topsoil. As an eater of food, you need to know this. It's important: food that does not come from the ocean[1] comes from topsoil. Beef? Cows. Cows graze. Pork? Pigs are calorie batteries. They eat anything. But they don't do so great in bog. Chickens? ....yeah.

The places that you think are coming online as 'greener' locations are places where the soil just unthawed. It's not topsoil. It's not loam. It's moss and bog, where it isn't boreal forest[2]. The land is not usable for agriculture or animal husbandry. Probably won't be for thousands of years. It's the crossfade.

It's also going through massive subsidence as the permafrost melts, and is constantly belching methane. It's a soup of microrganisms, mosquitos, and (scientific term here) gunk.

--signed, a Canadian from a farmtown that was just a lil too far north. (Yes, really.)

[1] before you call loophole: yes, we're running out of that, too. Faster, in fact. Fun times. Those are some empty empty oceans.

[2] Conifers often intentionally (to the extent that plants have intent) make the soil around them acidic; this is because only conifers can survive in this soil.

The territories you're eyeballing as a future breadbasket are often currently boreal. When they're not bog. And the boreal tends to turn into bog. That subsidence. Trees hate it -- they like being vertical.

So, yeah, idk what you'd grow there, unless you eat mosquitos.

This post will not age well.

Neither will its author.

Aging requires food.

clears throat as someone whose country includes the Arctic, I am qualified to inform you that 'total environmental collapse' is accurate. Also, post-ex-facto.

You, my friend, are looking at what is colloquially known as a Big Problem.

This is the first time I've ever felt that Wayland is missing something important

I have no idea what this question is asking.

'Engineering,' like 'art,' is one of those hand-wavey words.

In fact, I have a feeling you're actually asking:

"What are the coolest brands, as perceived by engineers, and why?"

Which is about as substantial as asking what the _pinkest_ brands are, or what the most _geographically-distributed_ brands are.

Or perhaps less so -- at least we can characterize 'pink' and 'geographically distributed' as reducible terms.

This got downvoted, so it's anecdote time!

A former employer once forwarded me a deep-dive article about a guy who was archiving old '90s usenet posts. He explained the process by reference to a sample post, chosen at random, from the whole of the Usenet, '91-'99.

That guy's sample-post? A one-off I'd made, complaining bitterly about JDK licensure or something, from around 1998, when I was a loudmouth teenage Stallmanite.

It now occasionally comes up for discussion during job interviews. It came up when I applied for a work visa to USA.

Stay safe, and don't let your next job interview turn to the topic of [checks notes] resource-efficient weapons of mass destruction.

Hey all,

Quick/friendly reminder that this is a dangerous conversation to be having in public -- there is no telling what will happen to old comments in a few years (or decades,) when the disruption is further along.

Quite serious. History tends to happen when you least expect it to.

Personal web history, doubly so.

There needs to be a '+1, Insight, but I don't like It' upvote feature here, dang

Finally, as I get my proteins denatured by a quadruped-mounted face-finding energy weapon in Civil War II, I can go out singing Stallman's song.

You will be free, hackers. You will be free

my default browser is.... [sunglasses emoji] Arena

Now, I don't like to judge the moral character of display positioning, but after carefully considering the .png of the preferred solution of this article's author, I am forced to question the nature of my reality.

Excellent work. :)

seeing ImageMagick, of all hoary tools, trending on HN reminds me that I'm so old that the kids are relishing as classics the tools I regard as outdated.

This is expectable in music, but in tooling?

And with Image-frigging-Magick ?

Damn.

Looking forward to the front-page HN-trended article on `sendmail`

Thanks Wolfram, but I like my freedoms uncurated.

I literally just bought your product, thank you very much, I needed this and wondered why no one had made it yet.

Former startup CSO here. There is not enough coffee in the world to make this day not terrible for anyone whose job involves worrying about security.

The problem with no-code is it is also usually no-ontology. It's always fun to mock 'ideology', but without a strong philosophical principle, every project will eventually morph into a hairball.

The underlying ontology behind code is, "reduce problems to a normalized form that can be stored in text, which we have gotten good at managing with snapshots and branches in DVCS".

With no-code, you don't have a normalized form to reduce to. Maybe your project is PowerBI modules or Excel-like superspreadsheets or whatever, but the 'stuff' that your project is made out of is not subjectable to the same kind of rigorous management that contemporary codebases tend to adopt.

The two analogies that come to mind are nosql, a movement which rather quickly discovered that RDBMS -- a normalized form for storing and addressing data -- was a pretty good idea, actually, for many use cases.

While NoSQL found important roles to fill, it is by no means as Big a Deal as the breathless tech media made it out to be, back in the aughts when mongodb first dropped.

The other analogy is double-entry bookkeeping. It's been around forever, and while it's not appropriate for every use case, its resilience and ability to represent complex changes in a complex system over time in a normalized way is similar to how a well-maintained codebase is represented by git (and competitors).

Code is a form for representing thoughts about changing systems which change the world in turn. It implies an ontology -- an "ideology", in the popular sense of the term -- and without that scaffolding, projects get floppy.

I'm much more excited about things like Git Copilot. Did you see the demo at Ignite, where that guy was literally just describing in English how he wanted the minecraft bot to behave, and the model wrote the (perfect) Minecraft scripting to make the bot obey?

That, IMO, is the future. Tools that create code that may or may not require tweaking, but can be still be committed to a repo, and is still something whose provenance and behaviour you can reason about, and diff-view when it changes.

Now, making the resulting code provably correct in a quick, automated way is probably the next thing I'd work on if I was in charge of Copilot development. But this will probably require changes to the languages that people use.

"Here is the code that does the thing you verbalized in English, here it is deployed, and also, here are several proofs, including a formal proof, the code does what is intended."

(Another advance I'd like to see are AST-based DVCS, rather than text diffs, but that is a story for another monologue)

[EDIT: I should mention that I happen to work at the specific Big Tech Company that makes Copilot; however, I work nowhere near the team that made it, and my opinions are emphatically my own.]

Surprisingly comfortable, for me, at least. I'm somewhat older, so I had some pre-smartphone habits to dust off and fall back upon

Surprisingly, Microsoft is pretty damn good these days.

I too have the nixos vs openbsd decision nibbling at me every time I spin something up.

Here's what helps me decide: I simulate a disaster. Since I'm just me, I do it on paper (empirical ways are best but are also the most expensive, and in a pinch, a thought experiment can illuminate as well. Not always the same things, but light is light.)

Try it -- open a scratch.txt and write about things that would happen, and then the things that would probably happen as a result of that.

The one that often comes up for NixOS is "I lose network connectivity." While NixOS is phenomenal in its ability to roll changes back, the fact that I need a stable Internet connection in order to make any change whatsoever to the current config makes that little piece of CAT-8 a SPOF for any number of unexpected (and intuitively unrelated) matters, making the overall system hard to reason about.

You can mitigate this by hosting your own NixOS channels, which is sort of the equivalent of hosting your own apt-get repo.

But, as you might expect, that's actually a fair amount of extra work. So I don't, especially not on laptops, where space can (still) be limited.

So, every time I do `home-manager switch` I need a viable network connection.

This is especially galling if you (like me) manage most of your apps with Nix' `home-manager`. Think it through; Nix manages (say) your word processor; you want to change the font size in your word processor; you edit your home.nix and hit `home-manager switch`.

But look at what this entails! My apartment building's fibre-optic cabling should never be a depenency on altering the font size in my word processor, but here I am. Ironically, for the sake of convenience.

Now, none of this is to slag on NixOS. As I mentioned above, it's my favourite way to encounter reality. I'm typing this to you on NixOS right now. For me, the pros outweigh the cons. Provided, of course, I have something less brittle than NixOS to back me up, and for me, that means OpenBSD.

I have an OpenBSD instance in the cloud and a break-glass procedure for getting into it. It backs up via another old-school friend, tarsnap. It hosts the git repos that contain my nixos and home-manager configs. If I can talk to it, I can simply zap my NixOS config onto some new edge device and be back up and running in no time.

I also typically have a NUC running OpenBSD present as well, in case that apartment-building fibre gets troublesome (again,) but not at the moment, because my beloved PCEngines device has apparently become unstable under any OS. But when I get that OBSD NUC set (back) up, it will absolutely have a NixOS channel on it, and it will serve as a firewall, a SAN, serving NixOS channels to the edge devices. It will have an actual serial port and a password on a wax-sealed bit of paper in my fireproof safe. Because I think ahead, and that's what I need to get back up and running under the worst circumstances.

I simply can't imagine a non-hardware-failure disaster that could take out an aggressively boring OpenBSD bastion instance. They are just relentless in their persistence.

As I keep saying, NixOS and OpenBSD pair together like honey and mustard. Contrastive but unexpectedly delicious.

Take-home: If you're building infra, try adding some OpenBSD to the mix. It can make the unrecoverable recoverable.

I think "attempting to forestall the emerging ecological catastrophe" is a good-enough placeholder for the next few generations.

You can worry about the meaning of life after you have secured its continuity. Prioritize.

My advice? Go with OpenBSD.

These are the folks that brought you the word 'hackathon', and OpenSSH. (Ever use ssh? Thank OpenBSD.)

These are the folks that actually bother to read not just a PR, but actual full codebases, just to make sure their pointers don't dangle.

It's been years since the DevOps space was first told to prefer 'livestock' -- disposable, nearly-identical instances -- to pets -- long-lived customized instances and servers -- but as every farmer knows, if you have lots of sheep, the job is a lot easier if you have a sheepdog. Not quite a pet, but not cattle, either.

OpenBSD is my sheepdog. It keeps my git repos, it runs my wireguard VPN, and it, above all the other systems I touch, is trusted.

But trust is ultimately about people, not about systems. Systems get their trusthworthiness from their creators, the way the moon gets light from the sun.

And in trustworthiness, the OpenBSD community has a breathtaking superpower: They can say no. They are good at saying no. Do you know how hard that is -- to have someone ask for a feature, and just tell them off? That's the hardest thing any manager ever has to do, and these guys are good at it. Rare, in FOSS space.

These are the folks that are so good at saying 'no' that they ship with a literal actual bespoke copy of 'vi', that does exactly what it is supposed to, does not take packages, and also does not have a package manager pulling in raw github HEADs. (I love you, neovim, but you are so trusting!)

OpenBSD has been around for most of my 20+ career in this industry and it's sort of always been this aggressively reliable paperweight of a distro. I'm never quite sure what to do with it (NixOS is my go-to for my workstations -- NixOS + Wayland + Sway + Alacritty + Neovim is as close to godliness as a user interface can come) but OpenBSD finds its uses, and in those uses, it is smooth and heavy and reliable, making it the perfect foil for the rest of my infra: For where NixOS is neurotic and brittle, OpenBSD is saturnine and malleable.

I think of my infra as sort of being like a knife blade, with a glittering Nixos/Wayland/Neovim edge supported by a soft, heavy core of OpenBSD.

If everything else breaks, so long as I have my OpenBSD instances, I can recover.

One final word: At my end, I just finished upgrading my instance at openbsd.amsterdam; big shoutout to that amazing team for their incredible support. (Mischa, in particular, is a force of nature, and I am fan. ;D)

thank you <3

..or it's sending a clear message that white nationalist groups tend to be violent and militarized?

The very fact that this issue presents itself to you as anything other than a damning report on the state of the union is itself telling.

Perhaps instead, think of it this way: *even Facebook*, whose Zuck repeatedly dined with the architect of Jan 6, clocks this country as having a white-nationalists-with-guns problem.

Like.