quectophoton

Do not forget words like "Dragon" or "Figma".

You just know it's a losing battle because euphemisms will get increasingly creative. So the more you try to stop it, the more people will spread sheet.

It's interesting how I didn't even think that not having voicechat was inconvenient. At all. To me it was just how things were.

> Unless engineering is explicitly involved in the hiring process, HR will drop your resume automatically if you say "5 years of MySQL and SQLite experience" with no mention of Postgres.

I found this the hard way during these last 2 years.

They might give you the benefit of the doubt if you have led teams before, but if that's not the case, your application is going to the bottom of the list because you don't match exact keyword and have a big number next to it.

Classic communication mistake is assuming what people mean when they say $LANGUAGE.

Some people mean the language itself, others mean language + standard library, others mean language + standard library + tooling, others mean language + standard library + tooling + ecosystem.

The same people could be meaning different things at different times depending on what's in their mind at the moment.

I always appreciate that Alpine Linux maintainers disable[1] these things by default.

[1]: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/c...

Sorry, that's not allowed.

You must choose one side or the other, and fully commit to it (like everyone else in this comment section). But it's too late now, since you've already tried both sides (fully digital and fully notebook) with an open mind, that means your opinion is automatically invalid and wrong.

Them's the rules.

> Now I'm trying to think through what the actual threat model is here, and why it doesn't apply in reverse to the REST API endpoints that we also maintain. I can see the point of signing rather than an included credential if you allow webhooks to http endpoints, but is that it? Probably better to just not allow non-https delivery URLs anyway.

My best guess: Maybe signing the webhooks assumes the TLS-terminating middlewares might not be trusted? Or some other middleware between that and the final handler.

To the best of my understanding, the two options mentioned in the article require a shared secret: API keys include that secret verbatim in the request, while the signing uses the secret in an HMAC function.

If asymmetric cryptography were somehow involved, I would somewhat buy the arguments about validating the origin of the request, because only one party would be able to create a valid signature. But that's not the case here, because with HMAC both parties have access to the same secret used to create a "signature" (which is more like a salted hash, so creating and validating a signature are the same process).

So, if both parties can produce the hash for a valid signature, and the secret is known to both ends, and there's no advantage over API keys when using TLS (assuming TLS is not broken), then I can only think that the problem is what happens outside TLS.

That's why I think the threat model would be a compromised TLS-terminating proxy, or some compromised component in between TLS-terminating proxy and the final application handling the request.

Sounds like zero-trust shenanigans.

If I'm misunderstanding anything, I'm more than happy to be corrected.

Agree, saying that an HN comment is AI-generated just because it has an em-dash, is like saying a Twitter/BlueSky/etc post (or WhatsApp message, etc) is AI-generated just because it ends the sentences with a period.

"it looked like a real message but the dot at the end gave it away"

There are similar opinions with artists too. Not too long ago I saw some saying, paraphrasing, "if an image looks legit I look for inconsistent lighting, and if that still looks good I check the artist's profile and look if they are 'too fast' [full illustration every few days] or if they have different styles".

I haven't seen anything like that with code, but I wouldn't be surprised if someone said that human-written code is actually AI-generated just because the structure looks weird to the reviewer, or because it has some "what" comments (instead of "why" comments; both have their place), or things like that.

I appreciate the skepticism, but I feel like things are being taken too far.

I don't expect calendars, or time keeping in general, to change too much until we have civilizations in multiple planets (if we ever reach that point anyway). And even then, I doubt much would change here on Earth.

I think if we reach that point, we would probably look at the Earth calendars the same way we currently look at the Latin language.

I don't want to add more to your fears, but also remember that LLMs have been trained on decades worth of Python code that assumes the presence of the GIL.

> Something I’d like to see in browsers is native support for text/markdown [...]

Sadly, I can see why it's unlikely that we'd get this.

First, browsers would need to agree on which flavor of Markdown, what extensions, and so on. After all, Markdown is almost like the CSV of text formats, with everyone doing their own thing ("almost" because you can still assume that some basic things work as you'd expect).

Only with that, I can already see the backlash no matter what they choose to do here. Too minimal, and get complains about not being too useful. Choose some extensions, get complains about being bloated. Make any attempt to have a thoughtful discussion about pros and cons (short and long term), get shut down with "don't let perfect be the enemy of good".

If we can get past that and finally agree on one specific set of features, there's still the question of whether it's actually worth it or not. The difference between Markdown and PDF is that reading PDFs directly in the browser is a common enough activity, but reading Markdown directly is only going to benefit the tiny audience of the small percentage of software devs that exist in the world, and maybe 5 weird people. Everyone else with a blog would just use the WYSIWYG from their CMS.

That's why I wouldn't be surprised if I don't see native Markdown rendering during my lifetime.

On first visit:

* "Please wait while we verify that you're not a bot, for which we'll need to associate a unique identifier with your browsing session." (logged in or not)

* The validation needs to do a quick redirection to an external centralized service, because if they can already identify that you're not a bot, you save CPU cycles, and you care a lot about carbon footprint after all.

* Redirect back to the original website, passing the "proof of not-a-bot" somewhere in the URL. This is just a string.

* The website absolutely needs to load the external script `https://proof-validation.example.com/that-unique-string.js` for totally legit purposes obviously related to detecting bot behavior, "somehow".

Half-joking because I don't think this would fly. Or maybe it would, since it's currently trendy to have that PoW on first visit, and users are already used to multiple quick redirections[1] (I don't think they even pay attention to what happens in the URL bar).

But I'm sure we'd get some creative workarounds anyway.

[1]: Easy example: A post on Xitter (original domain) -> Shortened link (different domain) -> Final domain (another different domain). If the person who posted the original link also used a link shortener for tracking clicks, then that's one more redirection.

I might be remembering wrong on where the problem was exactly, but it was either the generated code, or the code for the Fennel transpiler itself.

I just know that I tried to use it without loading Lua's libraries (i.e. without calling the `luaL_openlibs` function or equivalent) and was unable to.

> I just copy the compiled lua into the place the program expects to find lua scripts.

Yeah most existing programs just load all Lua libraries by default, so that's generally not an issue.

My post is more from the point of view of embedding a restricted Lua interpreter into a program (i.e. only Lua-the-language, not Lua-the-language-plus-its-libraries) while still supporting Fennel.

---

EDIT: Just checked, the Fennel code `(lambda [foo bar] bar)` compiles to Lua code that calls `_G.assert`.

> Fennel's approach of compiling to Lua while maintaining meta-programming capabilities is elegant.

Yeah, it is very nice to work with.

The only tiny "complaint" I have is that it doesn't compile to pure Lua, but instead assumes you'll be running it together with Lua's libraries.

I say this because, for me, the places where I'd like to use Fennel have a lot of overlap with the places where I'd like to use Lua without loading any of the provided libraries (e.g. embedding Lua into other software, instead of using it standalone).

"Let's invent a thing inventor, said the thing-inventor-inventor after being invented by the thing inventor."

— bill wurtz, 2017, in the video "history of the entire world, i guess"

> I deploy to single node swarms, and it's a zero boiler plate solution.

Yup, it's basically like a "Docker Compose Manager" that lets you group containers more easily, since the manifest file format is basically Docker Compose's with just 1-2 tiny differences.

If there's one thing I would like Docker Swarm to have, is to not have to worry about which node creates a volume, I just want the service to always be deployed with the same volume without having to think about it.

That's the one weakness I see for multi-node stacks, the thing that prevents it from being "Docker Compose but distributed". So that's probably the point where I'd recommend maybe taking a look at Kubernetes.

Nah, I'll maybe start taking them seriously when they can draw someone grating cheese, but holding the cheese and the grater as if they were playing violin.

And it gets worse.

For now they are probably paying to use residential IP addresses that they get from other services that sell them (and these services get them from people who willingly sell some of their bandwidth for cents).

But I think it won't be long before we start seeing the AI companies having each their own swarm of residential IP addresses by selling themselves a browser extension or mobile app, saying something like:

"Get faster results (or a discount) by using our extension! By using your own internet connection to fetch the required context, you won't need to share computing resources with other users, thusly increasing the speed of your queries! Plus, since you don't use our servers, that means we can pass our savings to you as a discount!"

Then in small letter saying they use your connection for helping others with their queries, or being more eco-friendly because sharing, or whatever they come up with to justify this.

As much as I like BitTorrent, people (usually) don't want to provide open access to information; what they (usually) want is to be an "open" gateway to that information, as long as they are the centralized point of distribution whose name appears in the URL bar, and as long as they control when they can remove access to that information.

Creating a torrent is not showy enough, because the credit is "just" another file and/or a comment in the torrent metadata.

Granted, they usually do that because they want to "kindly" advertise a way to donate to them (EDIT: or to track you, or other similar goals), and there's nothing wrong with trying to get donations, but there's clearly a conflict of interest at play here.

MCP = Model Context Protocol

(I didn't know what MCP was.)

The way I would describe it is: "How do you like applying to new jobs and doing interviews? Now imagine that being half your job."

To save you a click: this is just LWN quoting the Mozilla post from a few days ago.

The title is misleading.

I thought this was about Mozilla reverting the TOS to how they were before the whole thing started, because that's what the title sounds like.

But nope. This is about their (failed) damage control. You know, the post where they said:

> Mozilla doesn’t sell data about you (in the way that most people think about “selling data”)

Infrastructure as well.

I don't think anyone sane would let "prompt engineers" anywhere near their Terraform/OpenTofu/Pulumi/$OTHER code.

Giving write access to people who depend on LLMs (as in "can do almost nothing without it") is a recipe for disaster. Even giving write access to a junior is less scary than that, in comparison.

Next update will be like

    async def handle_connection(chat):
        if chat.username == "brendanfinan":
            await asyncio.sleep(432)
            await chat.wait_until(received_message_count_greater_than=8)
            await chat.respond("sorry I was afk")
            await asyncio.sleep(166)
            await chat.respond("not reading all that tho, im happy for you")
            await asyncio.sleep(14)
            await chat.respond("or sorry that happened")
            await asyncio.sleep(8)
            await chat.quit()
            return

        # ...

Unless someone can vouch for you at the company you're applying to, that's unfortunately the game that job seekers have to play.

> You can't even get hired if you're proficient in a language, but don't know framework X.

You can't even get past the very first screening filter. If job asks for, say, 5 years of experience with React, it doesn't matter if you have experience in any other frameworks but "only" 4yoe with React or less. You won't pass the first filter because 4<5.

Sucks if you don't want to lie.

> I've been programming JavaScript since like 1997. Sure, I'll pick up React no problem, but I won't be touching it unless I'm paid, because React is a disgrace.

At the beginning of the month I had an interview for a role that needed to extract a Node.js project to its own microservice. I have literally done this in production (but not Node.js). I have also migrated another project from NoSQL to SQL (but the project was not Node.js). I have developed microservices currently used in production (from design to Terraform to implementation).

But long story short, I didn't pass the initial interview because I haven't been paid to use Node.js during a recent 5-year job. The interviewer even asked, quoting to the best of my memory (and translating to English), "sorry, but none of this was with Node.js?". They were hyperfocused on Node.js as specific tech.

Previous production experience with Node.js? Experience with JavaScript/TypeScript in general? Doesn't matter.

That was not even worth the benefit of allowing me to pass to the technical interview to let me prove myself. And I wouldn't have even minded a live coding/pair-programming exercise.

It means I still need to work better on how I market myself to non-tech people.

> You want to be hired as Go dev? Better know how to use gRPC and Kafka.

And you better know Kubernetes (for some reason), or enjoy working on cryptocurrency projects.

You forgot GitHub:

One hamburger menu on the top left, with things related to your account, like repositories or the GitHub marketplace.

One hamburger menu on the top right (using your profile picture instead of the hamburger icon), with things related to your account, like repositories or the GitHub website.

And between those two menus there's no-man's-land.

The title mentions Germany, but seems to be happening in several countries.

EDIT: For the record, I'm not a fan of linking to Reddit, but I don't know if there's any official announcement.

Newer generations growing up more familiar with Japanese culture (e.g. anime), videogames, and non-retro cultural references, naming things after words they find pleasant (for a lack of better word) to hear.

I've been wanting to make a no-build webapp using Mithril.js[1][2], with plain-JS type annotations that don't require build steps (TypeScript's JSDoc syntax [3], but I'm looking forward to the proposed type annotations[4]). With something like this, type-checking would still require running a command when using Node.js, but it's just an optional developer dependency since the code would still be just standard JavaScript.

But in the end I've not done that because I figured it's more effort than it's worth, compared to just doing server-side rendering with other backend languages and just using JS where needed (not necessarily "raw" JS, I just mean it as in "not having a full-page component").

I'm just letting you know that there are definitely some people like me that would like if more JS tooling didn't require a build step or specific runtimes (like Deno or Bun) as a hard dependency.

[1]: https://github.com/MithrilJS/mithril-node-render

[2]: https://github.com/StephanHoyer/mithril-isomorphic-example/

[3]: https://www.typescriptlang.org/docs/handbook/jsdoc-supported...

[4]: https://github.com/tc39/proposal-type-annotations