Hacker News: Melkor333

It doesn't matter if it looks good

Melkor333 — Mon, 11 May 2026 06:55:42 +0000

Article URL: https://yosemitesam.ch/it-doesnt-matter-if-it-looks-good/

Comments URL: https://news.ycombinator.com/item?id=48091841

Points: 4

# Comments: 1

Oily Pine – Chapter 1

Melkor333 — Mon, 06 Oct 2025 04:27:59 +0000

Article URL: https://yosemitesam.ch/oily-pine-01/

Comments URL: https://news.ycombinator.com/item?id=45487639

Points: 2

# Comments: 0

New comment by Melkor333 in "Tools for 2025"

Melkor333 — Mon, 03 Feb 2025 07:03:58 +0000

(blog author here) That is the kind of thinking which just unnecessarily gatekeeps innovation.

There's always someone "in control" of a server. But even more important, there's always someone (or usually a group) in control of deciding which shell should be the default on an OS. And these are the people that should be reached somehow.

And Oils is just as much a snowflake as Bash, Tcsh or Ksh. All of them are POSIX compliant (though not sure with tcsh), all of them bring own additional features. But the only shell with additional features which don't suck (by being 30yo) is from the Oils project.

New comment by Melkor333 in "Tools for 2025"

Melkor333 — Mon, 03 Feb 2025 06:52:17 +0000

> The one area where I've stopped using bash/shell is in complex shell scripts which I'm now writing in TypeScript and executing with Bun by using: #! /usr/bin/env bun

(blog author here) This is exactly what's wrong with bash (and zsh). It should NOT be hard to write a bit more complex scripts. But it's so ingrained into our heads that shell is "too hard" that people use ts/js/python/etc. And usually the UX to writing "glue code" is much worse than with a good shell like Ysh.

New comment by Melkor333 in "Tools for 2025"

Melkor333 — Mon, 03 Feb 2025 06:45:44 +0000

(blog author here) Thanks for the feedback. I've raised this issue as well in the past and I think it has already gotten better.

AFAIU there's a dedicated page planned for osh/ysh when you click on the headline which should make it much more clear.

New comment by Melkor333 in "Tools for 2025"

Melkor333 — Mon, 03 Feb 2025 06:38:28 +0000

(Blog author here) Hehe yes, Use it for a long time now! But at least in my bubble people already talk quite a bit about it, other than Oils, Radicle or Simplex :)

New comment by Melkor333 in "Bogus CVE Follow-Ups"

Melkor333 — Wed, 06 Sep 2023 04:41:35 +0000

I have been in contact with the Nist a few years ago to fix some very irrelevant issues with ImageMagick CVE's which were marked as "insecure before version 7.X" in the NVD even when the fix was backported to Version 6. It made me wonder how noone from ImageMagick, nor Debian, nor anyone else gave a fuck about correcting the NVD. It just takes a single mail with a link to the backport github commit. Debian has this link almost always in their security tracker. That could probably be automated... At the same time it showed me how arbitrary the NVD (and the whole process in general) is. Some times they wanted a bit more proof, e.g. when I claimed v6 was unaffected. I had to go as far as searching the commit introducing the vulnerability to get them to believe me (which I think is good!) - this once led me to get a CVE from "unaffected" to "wontfix" on the debian tracker because of a mistake on their site.

- You don't really know what the NIST wants until you send them a mail (and even then they respond with very short messages). Apparently the same goes for MITRE... - there is no "person" behind anything - the whole process is 100% intransparent. Noone is going to see my mails ever expect for the NIST - it seems like each distro does the same work (and noone is contributing to the NVD. Though I was looking through a narrow hole with the imagemagick stuff, others are hopefully doing it)

IMO a fully transparent (but for security reasons probably partially embargoed) process could make this whole stuff much more reasonable... But I doubt either MITRE or NIST will change anything as long as there's no competition.