I wonder if this can, in the future, provide yet another alternative to building binaries with statically linked musl libc. People criticise doing that, often deservedly so, but having had to build stuff inside containers with deliberately old libc just to get the binary to run on another, older system, I find joy in having a binary that I know to run in "every $HW_ARCH Linux userland". (Of course, even then, calling newer Linux syscalls brings upon some version limitations...)
I wish to compile python from source in a way that will work in every $HW_ARCH Linux userland.
What are your advices?
What does your setup look like?
I'm really inexperienced with compiling software, but I'm playing with the idea of automating the creation of stand alone python distributions every time one is release to have a repo of it.
It looks full of gotchas though, espacially when you need to deal with ssl and tkinter.
I don’t know it’s current status but either PyOxidizer or Nuitka are the two Python compilers I’d look to for that. It is full of trade offs, but to an extent that’s many dynamic languages like Python (said as a Python developer)
If you rewrite the libc functions, maybe something could be offered like actually thread safe and safe environment variables. Or maybe that doesn't matter if no C libs are being linked in?
I really hope that we will get a libc-free Linux target. Mustang/rsix looks like a great step in this direction, similarly to steed (https://github.com/japaric/steed) before it. But I think that ideally it should be done properly in Rust proper, not in outside projects. Here a relevant issue, but there is not much progress on it: https://github.com/rust-lang/rfcs/issues/2610
If there's community interest, there is a possible path where Mustang matures to the point where it makes sense to talk about how to incrementally migrate the parts that make sense into Rust proper.
I like seeing how the Rust community is becoming more mature. Learning to live with and accept existing code was really hard for me when I started programming.
You learn over time to encapsulate and insulate to avoid other's crap code to infect your code-poems.
Less jokingly, programming has so many pain points that you learn to avoid. Simple things like reformatting a file, while a simple thing and seemingly necessary, can later end up being transformed into some of the less enjoyable mergings you have done.
The problem is, on most platforms, that is literally impossible. Go has had to roll this back on many of them due to it. Linux making this possible is actually an outlier here, not the norm.
I wish HN would remove the user-submitted title box, since it just encourages you to put your heart and soul into something that then gets overwritten by the mods anyway.
IMHO, this rule is important, but definitely simplistic. For instance, it's often important to contextualize; doing that without editorializing is subject to interpretation.
I'm not sure they could automatically determine the title for every conceivable web page. There's the tab title, but that oftentimes isn't just the article title. For example it may be "The Website | The Article"
As a joke I was thinking about making a web page that automatically updates its <title> tag to match whatever title HN chooses for its corresponding thread on the HN front page. :)
If any of you know a strategy that's applicable in general, which would result in a better-quality front page over all, I'd love to hear it. This is a global optimization problem, though. You can't judge it by local failures, and (much as I wish otherwise!) batting 100 is not an option.
"If you know of any strategy which would result in a better-quality front page over all, I'd love to hear it."
Thats a loaded question. :)
The title issue is just a small annoyance, not an indicator of overall success, and it seems like there could be an easy fix.
For example, a policy that submissions use the contents of <title> tag verbatim where possible. This should work for the majority of webpages. If not, I'd be interested in understanding why. I would think it would mean less work for a mod since then he does not have to entertain requests to change titles. Its arguable that any problem with a title (or the contents) of submitted webpage is a problem best addressed to the author of the page.
Its not that I find editorialising titles offensive, its that there is an inconsistency of enforcement of the "HN rules" where HN users are scolded (not necessarily by a mod) for editorialising titles and then elsewhere titles are mysteriously changed for no stated reason. That rises to the level of an annoyance. We might think of it as curiousity. Users just want to understand how HN works.
Maybe its impossible to be 100% consistent, and unreasonable to be expected to meet that bar, but when making (inevitable) exceptions perhaps its wise to be aware that sample bias will apply and explain why a title was changed. There might be good reasons for it.
> a policy that submissions use the contents of <title> tag verbatim where possible.
What does "where possible" mean? That would be a very different rule depending on how you define that.
There can be a lot of junk in title tags that we want to strip out, even apart from the (significant) question of linkbait.
How we handle titles on HN is a lot more consistent than people think it is - mostly what people do is notice a few things they do or don't like (probably don't!) and then quickly overgeneralize from that. This is just how humans are with data; it will always be that way and I've stopped trying to fight it.
It's tempting to apply technical solutions to avoid accusations of inconsistency, but that's generally not a good idea - you end up needing to make exceptions some of the time anyway, and then you're back to square zero - and meanwhile, a simple technical solution doesn't handle any nuances, and nuances matter.
An added feature of the "joke" would be if the auto-update of the <title> could trigger a page crawl by archive.org or similar, in order that we could view histories of changes to titles.
To be clear, I find the automatic edits to usually be useful. I left my comment to explain why I flagged the article (assuming 'dang looks at flagged posts and then has to wonder "Why is this flagged?").
I actually unflag after corrections. I think one-off flagging doesn't end up triggering any badness for the poster (and the rules for comments vs posts are different). Only once enough people flag something does anything happen.
Your reputation as a flagger goes down when you make a lot of false-flags (I don't know exactly how this is measured). I.e. your flags start counting for less
Unless you have "show dead" turned on, in which case you see it anyway. (You still can't comment on it, though.)
And, if it's dead and you see it and you don't think it should be dead, you can "vouch" for it. If enough people do that, it can lift the "flagged" status.
I think people often don't notice and then click away and go about their business. Nobody expects content they've just submitted to get silently changed under their nose.
