I presume more countries have this, not sure about the US though (CISA maybe? CERT/CC?). CERT is the overarching org that manages local agencies like this Dutch NCSC. Though I am not sure if and how easy it is, globally, to report incidents.

I tried content-types, user-agent, but no luck. I'm not sure what the user-agent of `req` is, but the default `node-fetch/1.0` does make the response json. They are a 307, but the result is a png.

I presume the original payload may have contained information that the hackers want to keep from prying eyes. Esp. now that it landed on HN, it makes sense to take it offline and replace with an actual png to avoid people finding information in it that may harm their future hacks or so?

For me, the discipline of shallow dependencies, no-dependencies etc, was new when I came to rust.

Sure, if I pull in something like Rocket, it comes with dependencies, that have dependencies that have dependencies. But Rocket is one of the more extreme examples I know of, and even that is nowhere near the depth of a tree that common (not extreme) npm frameworks/libraries come with. Before yarn I sometimes had node-module trees that went over 50 levels deep.

The Python community doesn't have this extreme deep dependencies, but in Python it is far more common to "from foo import bar" in both libraries and in applications than to write a few hundred lines of code yourself. The Django and "lean" flask, or "simple" cli apps I worked with and on, quite commonly have hundreds of dependencies (many of which are dependencies of dependencies etc).

Within that context, rust community is far more conservative. Many of the dependencies that I use have one, maybe two of their own deps. Many none. And it's more common - IME - to see libraries that have just one level of deps - the libs a lib depends on, itself won't have deps.

Though, I guess, C or even C++ community, lacking OOTB, common and easy dependency management like cargo, will be far more conservative even.

Rather than being "flat out wrong", I'd say it very much depends (pun intended) on where you come from and compare rust with.

edit: Ironically, that makes shipping the binary a tad harder, since this "linux" version won't "magically" run on about every Linux, or mac version on mac, etc. I guess that's why its not the default, though that's just me guessing.

Fast, Safe, Lightweight, Statically linked (plop a precompiled binary in ~/.local/bin and run it), few/shallow dependencies, senior developers, "Done" software.

Now, certainly no guarantees, enough counter-examples, I know. And attributes that one can get with anything from PHP via Javascript to Lisp as well. Some attributes have stronger correlation than others too.

But, in general, "rust" has a (much) higher chance of meeting these attributes. I care about those attributes above anything else.

Huh? It does. Only libc is dynamically linked, by default, which --iirc-- all programs will commonly need anyway. All the rest is statically linked.

In fact, it takes some hoop-jumping to build dynamically linked binaries with cargo.

Why?

(And who are you to dictate what art is and what isn't?)

But I remember that on Linux changing some /etc/udev file helped me with some naggy bug long ago. I worked temporary in an office with several wonky USB keyboards. Whenever someone disconnected their tablet or laptop from their KB (ie shut the lid), my linux would pick it up and suddenly connect to this KB. A little googling and some trial-error and I had my linux set-up that it would only connect to whitelisted USB devices.

Which, months later, caused me insane headaches when I could not find why a new USB microphone wasn't working, despite it being advertised as "works on linux"....

We're now at the place where it's virtually impossible to run your own mailserver and have the mail delivered, consistently at Gmail and Outlook/Live/Hotmail. At least not without hours a month tuning, re-configuring, monitoring etc.

Basically, Gmail, Apple Mail, Microsoft, Yahoo (and to lesser extent, Fast-email, proton, or one of the handfull of dedicated email providers) have cemented an oligopoly. You must invest serious infrastructure, time and effort, or else your mail will be /dev/nulled (at random, often).

This "anti-spam" works, reasonably well. Because Gmail can now trust that Microsoft has measures in place to disencourage new accounts from sending large amounts of mails - and vice versa. Obviously Gmail can trust other Gmail accounts. And so they have a win-win-win.

win: No need for heavy, resource-intensive spam-training or scanning for the bulk of incoming mail - if its from a fellow BigTech, let it through. Win: an almost impossible high barrier to entry for any serious competitors. Win: Lock in, because anyone wishing to move will see their email not reach the inboxes of users at other Big Tech - aka the vast majority of inboxes.

I could, for example, imagine using roto in some of my current work on svg and visuals generation. In which case I'd be greatly helped with literals like "colors", "vec2", "angle" etc. I'd imagine that as long as other literals which I don't need, like an IP address, aren't in the way, it's still greatly beneficial to have a large lib to pick and choose from, around.

In our setup, the "sources" are more like configuration. Whereas the core, the business logic, is more like code.

Typically, one would configure with e.g. YAML. As we can see in many projects, that have a DSL, in yaml (k9s, GitHub actions, ansible, etc). But, rather than inventing another DSL in yaml, we realized we do need some logic, something very poorly expressed in yaml. And we went for Lua.

Long story to say: if your config typically has some logic in it, it makes sense to go for an embedded scripting language to provide it, rather than building it into the core domain, or to invent yet-another-yaml-amalgation (yayamla?)

But it doesn't explain the ridiculous security (scanning gates, had to take off my hat and belt, insulin pump was inspected), the prohibition of "professional" photography equipment, prohibition of own food and drinks (again, diabetes, I want to carry some lemonade and a bar for emergency), etc etc.

Is it to counter terrorism? To boost consuming at the establishments? Or is it a lame excuse thats in reality just a higher bar to entry?

But many of yhose foundations are wrong.

Mostly, because they were designed and implemented in a way that cemented them in place.

Is HTML the right abstraction for UI toolkit? If not, can we ever move towards an alternative that is? Maybe via wasm, IDK. Or css? Where we can never change the legacy (body has a margin, select is untylable) only add new, alternatives next to it (flex, datalist).

JavaScript is the only option, but it's fundamental design (weak typing, no parallelism, make it a poor choice for anything of scale. Which is why anything large or complex gets built in other languages that transpile, or that are somewhat available (wasm, webgl) as alternative.

Point being: yes, it is improving. So fast that an oldtimer like me cannot keep up. But all that improvement is tethered to foundations that are wholly unsuitable for what we want to use it for.

You are contradicting yourself. Either its a "minefield...of edge cases..." Or it's a common-sense model. Not both.

I'm convinced we're still in this minefield of edge cases, not in a situation where we've solved all this, and where the tech to build "frontend" is clean, predictable, free of historical baggage etc etc etc.

All we have done, is plaster over these foundational mistakes and invcompatibilities. We haven't solved them. React doesn't solve the fact HTML was never designed to be a UI toolkit. Next.js doesn't solve the fact that JavaScript is full of design mistakes that prohibit it from ever becoming a safe, sane, reasonable (literally) language. Tailwind doesn't solve the problem of CSS being haphazardly introduced to style a markup which was never designed to be styled. Etc.

All LLMs now do, is having the "knowledge" of the horrors under the plaster, in a statistical model that was trained on examples from an era where 99% of the examples are hardly more than plastering to fix the ever reappearing cracks in the previous layers of plaster.

E.g. with TDD, I find that a model that writes both the tests and the code, will almost always hone in on a solution, then -grudgingly- write a test for that, but quite certain with the final code "in mind" already.

So, I instruct it to use sub-agents; though I find the tooling on figuring out what context is and isn't passed between agents and subagents severely lacking.

Or, also worked pretty well, have one thread write the test. Only that. It cannot read code, it can only read the tests directory or even a subset thereof. Then another thread, entirely new context, must run the test, see it fail, start implementing and stop as soon as the test is green - it obviously cannot edit the test. Yet another new context then is instructed to refactor based on rigorous refactoring skills.

A lot of work - And ironically, skills written by agents are pretty bad, I found, so a lot of manual work. But the rewards are promising.

I mainly use mistral, so that's my reference, but I know anthropic et.al have similar models around.

Codestral is rediculously bad at conversation, but it's -for me- the best model around for "magic autocomplete". It's also pretty good at "one shot" prompt+context generations, e.g. to make "git commit log entries".

Document.AI is unusable bad in a conversation style, but really good when wired up to a simple pipeline as "replacement" for OCR or for indexing "meaning" from documents (I'm experimenting with it for my administration, to get invoices, contracts etc into a search tool).

I presume there are many others like it.

So, what you describe, is already in place. I guess mostly the "interfaces" are missing for you, or hard to discover maybe?

For example, a dedicated model with tool I'd like, is some "shell" -a zsh or bash fork or some wrapper- backed with a dedicated model, trained for "commandline interaction".

Where instead of "git commit --fixup=[opens another terminal to git log the relevant entry]", we can "git fixup the commit that fixes full names" or "ffmpeg convert some.mov to mp4 without sound but keep quality and ratio etc". Or "run any valid tar command - you have ten seconds".

I'm now using the way too heavy "devstral" for these tasks. I don't need it reasoning, conversing, apologising. I need it translating my requests into commands, then showing these to me so I can deny/allow/whitelist/blacklist them and then run them - to interpret *and show me* errors and suggest improvements or fixes etc.

Same for - indeed - translation, writing draft mails, reading documents, etc: I don't need to converse with it. I want to have buttons, shortcuts, "tab complete" etc that's "smart" enough to understand what I need and want, preferably tunable by editing "system prompts" or such and then get out of my way.

I think the company that figures this out for my IDE will win the competition-race of "AI coding tools".

Just today, I found, zed presented a button "git conflict found, resolve with AI" . When pressed, it did start a conversational thread, but its a step in the right direction.

Granted, the UI is still TUI, so items like panes, tabs, nerdtree, quickfix, :help windows etc are rendered with characters, but you can drag borders, mouse-select text, click files, focus panes by clicking, scroll-wheel, etc.