2/ i wrote a short-ish "note" over on The Blogging Site That Shall Not Be Named in an attempt to explain to the less technologically sophisticated people in the audience what just happened with the #nx / #npm supply chain attack.

* my simplified explanation: https://substack.com/profile/96801203-michel-de-cryptadamus/note/c-149738571
* for the trve heads with opinions on things like linux distros and the Rust programming language, Wiz wrote a much more thorough explanation: https://www.wiz.io/blog/s1ngularity-supply-chain-attack

#crypto #cryptocurrency #nodejs #node #threatintel #northkorea #lazarusgroup#DPRK #hackers #hacking #ethereum #claude #gemini

everyone calm down, the enormous #NPM supply chain attack of the incredibly popular (27,000 #github stars) #nx#AI build tool thingamajig is probably aimed solely at crypto bros. if you don't have any crypto you (hopefully) don't have anything to worry about.

my fact free, completely unsupported by evidence hunch is that we will find this came from #NorthKorea (because if it's a well orchestrated attempt to steal a bunch of crypto it's pretty much always north korea).

https://universeodon.com/@cryptadamist/115102035321832152

#crypto #cryptocurrency #ethereum #npm #nodejs #node #js#javascript#webdev#DPRK#LazarusGroup #cybersecurity #infosec #threatintel #claude #gemini

everyone calm down, the enormous #NPM supply chain attack of the incredibly popular (27,000 #github stars) #nx#AI build tool thingamajig is probably aimed solely at crypto bros. if you don't have any crypto you (hopefully) don't have anything to worry about.

my fact free, completely unsupported by evidence hunch is that we will find this came from #NorthKorea (because if it's a well orchestrated attempt to steal a bunch of crypto it's pretty much always north korea).

https://universeodon.com/@cryptadamist/115102035321832152

#crypto #cryptocurrency #ethereum #npm #nodejs #node #js#javascript#webdev#DPRK#LazarusGroup #cybersecurity #infosec #threatintel #claude #gemini

2/ i wrote a short-ish "note" over on The Blogging Site That Shall Not Be Named in an attempt to explain to the less technologically sophisticated people in the audience what just happened with the #nx / #npm supply chain attack.

* my simplified explanation: https://substack.com/profile/96801203-michel-de-cryptadamus/note/c-149738571
* for the trve heads with opinions on things like linux distros and the Rust programming language, Wiz wrote a much more thorough explanation: https://www.wiz.io/blog/s1ngularity-supply-chain-attack

#crypto #cryptocurrency #nodejs #node #threatintel #northkorea #lazarusgroup#DPRK #hackers #hacking #ethereum #claude #gemini

everyone calm down, the enormous #NPM supply chain attack of the incredibly popular (27,000 #github stars) #nx#AI build tool thingamajig is probably aimed solely at crypto bros. if you don't have any crypto you (hopefully) don't have anything to worry about.

my fact free, completely unsupported by evidence hunch is that we will find this came from #NorthKorea (because if it's a well orchestrated attempt to steal a bunch of crypto it's pretty much always north korea).

https://universeodon.com/@cryptadamist/115102035321832152

#crypto #cryptocurrency #ethereum #npm #nodejs #node #js#javascript#webdev#DPRK#LazarusGroup #cybersecurity #infosec #threatintel #claude #gemini

The new integrated Markdown parser I’ve been implementing in Kitten has been kicking my ass for the past few weeks but I think I finally have it fully working and seamlessly so. Expect a new release this/next week that brings the parsing of Markdown pages (.page.md files) in your apps up to the standard of the recently-improved runtime Markdown parsing in Kitten HTML tagged-template strings (within <markdown>…</markdown> blocks).

The coolest thing is I was able to implement this without introducing any new syntax. In fact, I was able to simplify things so that you can now add arbitrary JavaScript to your Markdown pages within a multi-line script block in the YAML front matter (script: |) and use JavaScript string interpolation syntax in your Markdown (and, of course, Kitten components and conditionals, which, themselves, rely on string interpolation).

The only place where you have to deviate from standard Markdown in your Markdown pages is if you have JavaScript string interpolations or Kitten components/conditionals in code fences within your Markdown. In that case, you’ll have to escape them (e.g., <\${Component} />, \<if \${something}>something\</if>, etc.). And, to be fair, the person most impacted by this is likely me as the Kitten documentation at https://kitten.small-web.org is written in Kitten so I had a lot of escaping to do. But for any other use case, it means that things should just work and work exactly as they do in JavaScript pages (page.js files).

Anyway, so this is going to be a breaking change so I thought I’d give you (the three of you playing with Kitten right now?) a heads up. Of course, I’ll be updating the documentation to reflect all this.

(Remember, Kitten is in pre-release and it’s the framework I’m building/using to create Catalyst – the Small Web hosting solution – and Yarn – a small web – peer to peer – personal site app. So Kitten isn’t the means, not the end. And, at least until the Version 1 API freeze, things can and will break. That said, there’s nothing stopping you from playing with it now and, to be fair, at this point, such breaking changes should become rarer and rarer).

kitten💕

#Kitten #SmallWeb#SmallTech #web #dev#Markdown#JavaScript#HTML#CSS#JavaScript#NodeJS

Bloody hell, finally, I think I’m done with the Markdown support rewrite in Kitten.

The Markdown rule for interpreting four spaces as code fences has been the biggest pain in my neck during this whole ordeal but, bitching aside, it means the parser is now more accurate and thus stronger for it.

If all goes well, expect a Monday release :)

https://kitten.small-web.org

kitten💕

#Kitten #SmallWeb#SmallTech #web #dev#Markdown#HTML#CSS#JavaScript#NodeJS

The new integrated Markdown parser I’ve been implementing in Kitten has been kicking my ass for the past few weeks but I think I finally have it fully working and seamlessly so. Expect a new release this/next week that brings the parsing of Markdown pages (.page.md files) in your apps up to the standard of the recently-improved runtime Markdown parsing in Kitten HTML tagged-template strings (within <markdown>…</markdown> blocks).

The coolest thing is I was able to implement this without introducing any new syntax. In fact, I was able to simplify things so that you can now add arbitrary JavaScript to your Markdown pages within a multi-line script block in the YAML front matter (script: |) and use JavaScript string interpolation syntax in your Markdown (and, of course, Kitten components and conditionals, which, themselves, rely on string interpolation).

The only place where you have to deviate from standard Markdown in your Markdown pages is if you have JavaScript string interpolations or Kitten components/conditionals in code fences within your Markdown. In that case, you’ll have to escape them (e.g., <\${Component} />, \<if \${something}>something\</if>, etc.). And, to be fair, the person most impacted by this is likely me as the Kitten documentation at https://kitten.small-web.org is written in Kitten so I had a lot of escaping to do. But for any other use case, it means that things should just work and work exactly as they do in JavaScript pages (page.js files).

Anyway, so this is going to be a breaking change so I thought I’d give you (the three of you playing with Kitten right now?) a heads up. Of course, I’ll be updating the documentation to reflect all this.

(Remember, Kitten is in pre-release and it’s the framework I’m building/using to create Catalyst – the Small Web hosting solution – and Yarn – a small web – peer to peer – personal site app. So Kitten isn’t the means, not the end. And, at least until the Version 1 API freeze, things can and will break. That said, there’s nothing stopping you from playing with it now and, to be fair, at this point, such breaking changes should become rarer and rarer).

kitten💕

#Kitten #SmallWeb#SmallTech #web #dev#Markdown#JavaScript#HTML#CSS#JavaScript#NodeJS

The new integrated Markdown parser I’ve been implementing in Kitten has been kicking my ass for the past few weeks but I think I finally have it fully working and seamlessly so. Expect a new release this/next week that brings the parsing of Markdown pages (.page.md files) in your apps up to the standard of the recently-improved runtime Markdown parsing in Kitten HTML tagged-template strings (within <markdown>…</markdown> blocks).

The coolest thing is I was able to implement this without introducing any new syntax. In fact, I was able to simplify things so that you can now add arbitrary JavaScript to your Markdown pages within a multi-line script block in the YAML front matter (script: |) and use JavaScript string interpolation syntax in your Markdown (and, of course, Kitten components and conditionals, which, themselves, rely on string interpolation).

The only place where you have to deviate from standard Markdown in your Markdown pages is if you have JavaScript string interpolations or Kitten components/conditionals in code fences within your Markdown. In that case, you’ll have to escape them (e.g., <\${Component} />, \<if \${something}>something\</if>, etc.). And, to be fair, the person most impacted by this is likely me as the Kitten documentation at https://kitten.small-web.org is written in Kitten so I had a lot of escaping to do. But for any other use case, it means that things should just work and work exactly as they do in JavaScript pages (page.js files).

Anyway, so this is going to be a breaking change so I thought I’d give you (the three of you playing with Kitten right now?) a heads up. Of course, I’ll be updating the documentation to reflect all this.

(Remember, Kitten is in pre-release and it’s the framework I’m building/using to create Catalyst – the Small Web hosting solution – and Yarn – a small web – peer to peer – personal site app. So Kitten isn’t the means, not the end. And, at least until the Version 1 API freeze, things can and will break. That said, there’s nothing stopping you from playing with it now and, to be fair, at this point, such breaking changes should become rarer and rarer).

kitten💕

#Kitten #SmallWeb#SmallTech #web #dev#Markdown#JavaScript#HTML#CSS#JavaScript#NodeJS

🥳 New Kitten Release

Housekeeping:

• Updated runtime version to Node version 22.18.0 (latest LTS).

• Removed --experimental-global-customevent in node launch command (as CustomEvent is no longer behing the CLI flag since Node v19.0.0)

• Renamed --experimental-loader flag to --loader as the experimental prefix is no longer required.

https://kitten.small-web.org

Enjoy!

kitten💕

#Kitten#KittenRelease #SmallWeb#SmallTech #web #dev#HTML#JavaScript#CSS#NodeJS

Ah, and also, forgot to mention this change:

Improved:

• Debugging your Kitten app is now easier when you run it using `INSPECT=true kitten …` as the Node runtime is launched using the `--inspect-brk` tag instead of the `--inspect` tag. This means that execution will wait for your debugger (e.g., Chromium’s DevTools at `chrome://inspect`, etc.) to connect before starting the server. This makes it possible to hit breakpoints that might previously have been impossible to reach as they occured before you had a chance to run the debugger.

Full change log:
codeberg.org/kitten/app/src/br

🥳 New Kitten Release

Housekeeping:

• Updated runtime version to Node version 22.18.0 (latest LTS).

• Removed --experimental-global-customevent in node launch command (as CustomEvent is no longer behing the CLI flag since Node v19.0.0)

• Renamed --experimental-loader flag to --loader as the experimental prefix is no longer required.

https://kitten.small-web.org

Enjoy!

kitten💕

#Kitten#KittenRelease #SmallWeb#SmallTech #web #dev#HTML#JavaScript#CSS#NodeJS

I'm working on a #poc in plain #nodejs 👀
Not published yet, put maybe I will fight #nestjs as a competitor 🤔

This is already working AND fully written in #es2025 #esm with #tc39 decorator proposal

What do you think?

```ts
const cats: Cat[] = [
  new Cat({ id: "1aefd497-bb47-47e3-b160-cb69c5ba0ff4", name: "Kami", age: 4 }),
];

@Path("/cats")
export class CatController {
  @Get
  @Path("/")
  public list(): Cat[] {
    return cats;
  }

  @Get
  @Path("/:id")
  public getById(@PathVariable() id: UUID): Cat | null {
    return cats.find((cat) => cat.id === id) ?? null;
  }

  @Post
  @Path("/")
  public create(@RequestBody(Cat) cat: Cat): Cat {
    cat.id = randomUUID();
    cats.push(cat);
    return cat;
  }

  @Put
  @Path("/:id")
  public update(@PathVariable() id: UUID, @RequestBody(Cat) cat: Cat): Cat {
    const index = cats.findIndex((c) => c.id === id);
    if (index === -1) {
      throw new NotFoundResponseError("Cat not found");
    }
    cats[index] = cat;
    return cat;
  }

  @Delete
  @Path("/:id")
  public delete(@PathVariable() id: UUID): void {
    const index = cats.findIndex((c) => c.id === id);
    if (index === -1) {
      throw new NotFoundResponseError("Cat not found");
    }
    cats.splice(index, 1);
  }
}
```
```ts const cats: Cat[] = [ new Cat({ id: "1aefd497-bb47-47e3-b160-cb69c5ba0ff4", name: "Kami", age: 4 }), ]; @Path("/cats") export class CatController { @Get @Path("/") public list(): Cat[] { return cats; } @Get @Path("/:id") public getById(@PathVariable() id: UUID): Cat | null { return cats.find((cat) => cat.id === id) ?? null; } @Post @Path("/") public create(@RequestBody(Cat) cat: Cat): Cat { cat.id = randomUUID(); cats.push(cat); return cat; } @Put @Path("/:id") public update(@PathVariable() id: UUID, @RequestBody(Cat) cat: Cat): Cat { const index = cats.findIndex((c) => c.id === id); if (index === -1) { throw new NotFoundResponseError("Cat not found"); } cats[index] = cat; return cat; } @Delete @Path("/:id") public delete(@PathVariable() id: UUID): void { const index = cats.findIndex((c) => c.id === id); if (index === -1) { throw new NotFoundResponseError("Cat not found"); } cats.splice(index, 1); } } ```

TIL that software (especially #scripting runtimes like #Python, #Perl, and #NodeJS) running in #Alpine#Linux containers is often slower than in other distros like #Ubuntu. This is despite Alpine being faster on startup and often vastly more efficient with CPU, memory, and storage.

It mostly comes down to Alpine’s use of musl libc rather than #GNU’s glibc. musl is optimized for minimalism, not raw performance. Also, the Alpine packages are often not compiled with as many optimizations.