defanor

Cloudflare refused to serve me the linked page after I enabled JS and passed the captcha, "The action you just performed triggered the security solution". Each time it happens, I wonder whether website owners then look at the statistics, see the reported blocks, and are reinforced in their belief that Cloudflare does something useful. But in this case I also wonder whether that number was derived from such blocked requests as well; whether they count me as a bad bot or just a bad person.

I like this approach, more than webrings: it forms a graph, rather than a linked list, which is more reliable, and basically what the "web" metaphor is about. So I both have a "links" page on my homepage, and trying to link relevant resources from public notes.

Embedding RDFa metadata seems potentially useful for forming a graph and helping with exploration as well, but it does not seem to be used much.

FWIW, I noticed that librust-argparse-dev is also packaged for Debian, and it comes without additional dependencies. It also builds fine when pulled from crates.io directly, while using rustc version from Debian repositories, unlike clap. So whether it is crates.io or system repositories, it may be worthwhile to spend more time looking for more lightweight and stable alternatives; most commonly suggested ones are not necessarily that.

Similarly being unhappy with pulling dependencies without using a system package manager, in part because it seemed tricky to make them work with a compiler version from system repositories, this is something I wanted to try as well, and finally tried now. After having rustc installed, had to install 157 more packages in order to get argument parsing (librust-clap-dev), but it is still faster than cargo updating its package index, and then it actually builds!

Would be even better if the dependency tree for a basic package was more modest, about 157 times smaller.

I tried saying those words in a fixed time (12 seconds) while looking at a clock now, it still does not seem hard. Appears to be easier once you attach parts of the phrase to time offsets, and probably easier yet with a teleprompter.

"H0w [...]" titles would be somewhat amusing and appropriate as a hacky way to bash those in, albeit inappropriate as being rather silly and circumventing this sort of policy.

The HN website editorializing titles automatically indeed seems wrong though: if those are bad or clickbaity titles, they probably could just not be upvoted much, maybe flagged, and otherwise dealt with using generic mechanisms, but attempting to automatically improve them does not seem to do much good. On a more optimistic note, at least those are predictable substitutions for now, and not any of the ML business.

> But if you are having one setting by the typographer and then choose to override them... yeah, it might be ugly.

This can be equally viewed from the other (user's) perspective: I had the font set (along with a comfortable size), then apparently the website tried to override it, though I did not notice that. Now I had to both allow custom fonts and enable JS to see its intended font, and it is even less comfortable for me to read, adding serifs, while still having overly high lines.

The reason I mentioned Noto is to better describe what I see, though perhaps it was unnecessary. That is, I saw it in a shape I liked a little more than the one it was intended to be in.

Seeing the title, I suspected that the typography will be messed up. And indeed, instead of my preferred configured font size, it is overly large and set in pixels, the line heights are higher than I would prefer as well (the font I use, Noto Sans, already has a pretty high leading). The situation with colors and margins is similar, to accompany that.

And the reason I guessed it to be that way is because it is like that much of the time: once people focus on something that is not broken too badly, more often they mess it up, rather than improve. I think a much better advice would be just to not touch it. Maybe go roll your own crypto if you feel creative, but stop messing up fonts, colors, and the rest of interfaces: plain HTML is good and sufficient for most web publishing.

Edit: though learning about typography still should not harm. Just applying it poorly--as done most of the time--may be annoying. Also same as with colors and adjacent design subjects.

> Let me ask a more foundational question then, what is the virtue of a "stable" system?

Not introducing breaking changes too often (so that you have to adjust configuration and custom software relatively infrequently), while applying security patches and other bugfixes, and being well-tested to work together are the first ones I think of. With "breaking changes" including changes to configuration, file formats, command-line interfaces, notable behavior, as well as library interfaces. Well, I think it mostly amounts to "knowing that an existing install isn't going to get borked by an update".

Supporting multiple dependency versions and stability guarantees indeed must help with avoidance of breaking changes in libraries, assuming the latest compiler version (or a dependency restriction: either compatible packages in system repositories or if there was such dependency resolution in Cargo), though probably not so much with fixes (I imagine there is less motivation to maintain stable branches and apply fixes to those then) and with integration testing. Besides, not all software is written in Rust: other packages and ecosystems must be taken into account as well. Likely more varied ecosystems can be handled more smoothly with NixOS or GuixSD, but I am not risking to use them on anything that should be reliable yet (maybe it is the time to look into those again though). But this kind of poor compatibility with stable systems does not seem necessary, especially for a language that is supposedly a safer alternative to C, while C is about as well-integrated into--and compatible with--common (POSIX) systems as it gets. Though then again, above it was noted that our experiences with C differ, but this is how I see it.

This appears to highlight differences in our perspectives: while working with (and supporting software for) 4 most recent major Debian releases, the latest stable one feels like a fresh one to me, especially if it is updated to the latest available package versions (and minor release). The packages are not supposed to be cutting edge there, but "stable".

I also don't mean to blame Rust's ecosystem (let alone the language itself) in the sense of complaining about it, though talking about this feels that way, and I thought it might be useful to clarify: it appears to aim less "stable" and more "cutting edge" (or "experimental") versions and practices than "stable" system distributions do, and than more mature ecosystems tend to do. Likewise, I wouldn't call having a slightly older compiler version in system repositories a problem with package manager: this is a useful approach for getting a stable system, relatively well-tested and with predictable changes. Not every system has to be this way, but in some cases it is useful, some people (myself included) generally prefer those. And unfortunately those fail to play together smoothly at the moment, but I view it as an issue arising between those and their approaches, not as a problem of one of those.

Thanks! I was looking for a page like that on docs.rs, crates.io, and possibly on lib.rs as well, but missed it; that is likely to be useful in the future. Actually now I see it on crates.io as well, <https://crates.io/crates/anstream/versions>. Or maybe I saw it before, and just have not found versions <= 1.63.

> why is it immature for Rust to ship a toolchain and package manager through a sidechannel, but not Haskell?

Haskell also feels less mature to me than C, with fewer POSIX functions being readily available, but as mentioned above, with Haskell (in my experience; the experiences indeed seem to differ) it is "one or two dependencies have to be pulled from Hackage across multiple projects and system versions", while in Rust it is rather "I failed to pull common logging and argument parsing dependencies on a single up-to-date stable system, and apparently one is supposed to install and update its compiler, package manager, and libraries separately from the rest of the system". Though some use ghcup or Stack, which also aim working without a system package manager, but at least a system package manager is a viable option.

Oh, I have not tried using it from system repositories: I tried that with another library (in a hobby project) before, had issues with that, been told and generally gathered that it is easier to pull dependencies with cargo, so went straight to that this time. I see that librust-clap-dev would pull 157 other packages with it though, but will look more closely into it: I would actually prefer getting dependencies from system repositories, thanks for pointing it out.

As for newer compilers, I prefer to depend on system repositories and package manager for updates, and to stick to stable branches, so that things do not change too often. I see the appeal of rolling release distributions and cutting edge software, but not feeling comfortable using it for things that are supposed to be reliable.

Steps to reproduce, once you have cargo and rustc from Debian stable repositories: cargo init && cargo add clap && cargo run. The following happens:

    error: package `anstream v0.6.4` cannot be built because it requires rustc 1.70.0 or newer, while the currently active rustc version is 1.63.0
    Either upgrade to rustc 1.70.0 or newer, or use
    cargo update -p anstream@0.6.4 --precise ver
    where `ver` is the latest version of `anstream` supporting rustc 1.63.0

This is the one I tried to use, but failed to, since one of its dependencies required a rustc version newer than what I have here (1.63.0), and cargo was not able to pick the latest compatible version, but suggested that I do that manually instead. Which surprised me as well, since I keep hearing about it being nice, yet resolving dependencies is something other package managers (and Cabal in particular) tend to do. I tried to find what is the last version of that package supporting my compiler version, failed to do it quickly (how is one supposed to go around such a task, by the way?), and gave up.

With C, I comfortably rely on the distribution's package management, even though it is not a rolling release or anything of that sort (Debian stable). Actually not sure how that would be the case with C, if one does not try to make things incompatible intentionally: the language and the major libraries' APIs are pretty stable there.

With Haskell (used for most tasks at work) I get the tools (GHC and Cabal) and most of the dependencies from Debian stable repositories, though loading missing ones from Hackage (but slowly moving towards not relying on Hackage at all). And keeping sources compatible with package versions from Debian repositories from version 9 to 12 (4 major versions, 6 years apart). With shell scripts, sticking to POSIX; with SQL ones, avoiding extensions and also doing fine.

Recently I decided to try Rust at work as well, after using it a little as a hobby, just to replace a basic shell script with it at first. While reliability, ergonomics, and other positive sides either do not beat Haskell (which I use for most programs, except for a few small shell scripts or [PL/pg]SQL functions) or it does not matter here, I similarly ran into that "immature ecosystem" issue: apparently people are still supposed to run a nightly build or rustup, but not a compiler from stable system's repositories, let alone libraries. It was that way when Rust was really new, which was understandable, but it is odd to run into that now, and also as the article mentions, even with basic libraries: I ended up using eprintln! instead of a logging library (fortunately used it with systemd, which picks up stderr output, and did not really need to set syslog levels or additional fields), env.args instead of an argument parsing library.

Mostly agreed with the conclusion, too: the language still looks good, especially as a C alternative, and hopefully it will be usable in a more stable setting. Gradually trying it out does not feel like a pivotal decision though, that sounds overly dramatic.

Not sure if I understand this correctly; avoiding such situations altogether seems virtually impossible. For instance, if people know you can help, you are in close enough relationships to have expectations of mutual help (e.g., friends or relatives), and you do not help, it is likely to be upsetting; while severing and avoiding all close relationships (particularly with less tech-savvy people, in this example) seems like an overkill. Or do you picture that non-positioning differently?

A nice article overall, but:

> Never do something for someone that they are capable of doing for themselves.

This seems like a good approach, and as if it must be educational, yet people may become upset if you are not helping them, likely because they are not sure if they are capable of doing those things. Even seemingly simple tasks occasionally turn out harder than expected: particularly online services often malfunction, so you have to work around their issues, often employing non-trivial technical expertise, creativity, and persistence to get things done; I think such cases erode the confidence of less tech-savvy people, and dealing with this broken stuff is an unpleasant experience even for tech-savvy ones. So, sometimes by doing something for someone that they are (probably) capable of doing for themselves, you can save them from some stress. Occasionally trying to do things on their own is still needed for learning, but not necessarily all the time.

The repository's README.md links to <https://docs.streamdal.com/sdks>, which is not there.

Those SDKs are simply libraries though, aren't they? "SDK" often stands for more than that (e.g., development tools, bits of code not properly packaged), and may be appalling if you don't want to wrap a project around such an SDK, as opposed to merely incorporating a library.

But then I wonder why it has to be a library at all, limited to just 3 languages: why not to implement a more unixy interface, perhaps with named pipes? And/or a library with C API (so that it can be called from any common language), providing file descriptors to write into. With the former approach, basic named pipes or files and actual tail -f can be used, too.

The article is hidden with CSS (and apparently later shown with JS, but not shown at all if JS is disabled, and there is no indication of that), but disabling CSS or switching to reader mode helps.

I guess it helps to utilize otherwise-idle CPUs to keep you warm, hence the name.

I use XHTML, mixed with a little custom XML, and processing with XSLT to produce final XHTML [1]: all of HTML is usable that way, the generation process is customizable, the dependencies are relatively easily manageable, the involved formats are standardized.

[1] https://git.uberspace.net/homepage/

The article's complaints include complexity of JS web interfaces and "eye candy", while netdata's UI requires JS, is quite laggy and jerky, very interactive. I think munin fits better (uses the same RRDtool graphs, too), though possibly its configuration is too lengthy for the requirements.

Possibly I am missing something, but is it different from, say, nginx's `root /var/www/$http_host`? The description sounds as if a whole web server is written for that feature.

I used a shell script for that, but vaguely thought of changing to a Makefile for a while, and finally did now, thanks to the article reminding of that; it is more appropriate. Though the shell script still invokes make, and then rsync, since rsync seems less appropriate for a Makefile. But now it synchronizes fewer files.

As a side note, I am quite happy with XSLT templates to produce the pages (instead of attaching a static header, as in the article), as well as to generate indexes and an Atom feed.

Worse yet while browsing with JS off by default: the popup shows up, but cannot be closed (and does not work for subscription, either), only obscuring the page.

This sounds tricky: since users depend on authors, both depend on implementors, and so on, issues and unhappiness may easily propagate from authors to users, from implementors to both those, etc; similarly to building a project with increasing tech debt, but at multiple layers. And then there is the question of application of this approach: whether one should consider picky and advanced users, or clueless ones, diverse users or an approximated average user, and likewise further along the chain, which is likely to lead to different results.

Directory listing appears to be broken: I see pages without content when trying to browse directories [1]; observed on a few instances I tried, with a few repositories.

The code div is restricted to something like 50 characters, leading to line wrapping, if the browser window is at a width allowing about 150 characters; huge and unnecessary margins there, particularly awkward for code.

Looks like it may be nice and useful though, especially if it had a working search on top of browsing: GitHub's new search is tiring to use for skimming a new codebase now, and cloning large repositories for such skimming is inconvenient.

[1] https://gothub.frontendfriendly.xyz/microsoft/vscode/tree/ma...

There was another technique for falling asleep mentioned on HN, possibly <https://news.ycombinator.com/item?id=17905574>. It basically suggests to not think, either.