HN user
GitHub also centralises abuse detection. I'm not thinking about sophisticated attacks here so much as dealing with plain old spam. That's fairly easy to deal with on a tiny scale, and possible on a huge scale, but it's a great pain at a medium scale.
It's common that if you extract a function or a module with a well defined interface, that function or module can't tell whether a "bad" input indicates an expected or an unexpected error.
For example division by zero often indicates an "unexpected" error, but it wouldn't if you were implementing a spreadsheet.
So to me the approach of using different forms of error reporting for the two kinds of error doesn't seem promising: if you imagine you had to implement division yourself, which kind of error should it report? Should you have two variants of every fallible function so the caller can choose?
Not any more, according to this article you're commenting on, no.
If a package hosted by Fedora or Debian or PyPI or crates.io, etc claims to correspond to an upstream git commit or release, then the hosting system should build the package, from the commit or release in question plus whatever package-specific config and patches are needed, and publish that.
For Debian, that's what tag2upload is doing.
They weren't in any way attempting to rely on security by obscurity.
They didn't assume nobody would guess the URL.
They did take active steps to ensure the data was only available at the correct time.
But they didn't check that their access control was working, and it wasn't.
Is this a real judge, or is an "Immigration Judge" one of those not-actually-a-judge decisionmakers employed by the executive?
I think what you've written is pretty much what the "almost all programs have paths that crash" was intended to convey.
I think "perhaps the density of crashes will be tolerable" means something like "we can reasonably hope that the crashes from Fil-C's memory checks will only be of the same sort, that aren't reached when the program is used as it should be".
It makes tab completion work.
One of the things that this group of "stewards" could do to get their costs down is get together and implement a high quality free software caching proxy that understands all their back-ends.
But that would compete with the commercial offerings of at least one of the organisations sponsoring that message. So I expect they won't do that.
It's clear from that bug tracker that you shouldn't let libxlst see untrusted stylesheets or xpath expressions.
I haven't yet seen a problem with running your own transformations against untrusted XML.
Maybe a new maintainer could aim to make the second case fully supported but not the first.
There's still work being done on the Reference, which is being maintained in the same way as it has been since the Rust documentation team was disbanded in 2020. But it's a very long way from being either complete or correct enough to reliably answer questions about Rust-the-language.
After the "write a new spec" plan was abandoned in 2024 the next stated plan was to turn the Reference into the spec, though they never got as far as deciding how that was going to work. That plan lasted six months before they changed direction again. The only practical effect was to add the paragraph identifiers like [destructors.scope.nesting.function-body].
They're currently arguing about whether to write something from scratch or somehow convert the FLS[1] into a spec.
The plan described in "Our Vision for the Rust Specification", and the linked RFC3355, were abandoned early in 2024.
The team that was formed to carry out RFC3355 still exists, though it's had an almost complete turnover of membership.
They're currently engaged in repeating the process of deciding what they think a spec ought to be like, and how it might be written, from scratch, as if the discussion and decisions from 2023 had never happened.
The tracking issue for the RFC was https://github.com/rust-lang/rust/issues/113527 . You can see the last update was in 2023, at the point where it was time to start the actual "write the spec" part.
That's when it all fell apart, because most of the people involved were, and are, much more interested in having their say on the subject of what the spec should and shouldn't be like than they are in doing the work to write it.
Also vidir, which is in the moreutils package in popular distros.
It's supposed to be 10^5 W heating per square metre, and the aeroplane's cross-section is much smaller than a square metre.
My mistake.
The support for writing CGI programs in Python is in wsgiref.handlers.CGIHandler .
The Python maintainers are removing the module _named_ cgi, but they're not removing the support for implementing CGI scripts, which is CGIHTTPRequestHandler in the http.server module.
All that was in the cgi module was a few functions for parsing HTML form data.
It would be better if there was a layer of maintainers between the free software authors and the end users that could act as a buffer in cases like this, in particular to take care of security vulnerabilities that genuinely need dealing with quickly.
Of course that's exactly what traditional Linux distributions signed up to do.
Clearly many people have decided that they're better off without the distributions' packaging work. But maybe they should be thinking about how to get the "buffering" part back, and ideally make it work better than the distributions managed to.
I agree it can be domain-specific, but I think it's more common than not that empty containers, and the number zero, are corner cases rather than typical values.
So I think it would be a decent quality-of-life improvement to make generators of the sort you suggest easily available, and have the tutorial docs use them from the start.
I've found in practice that shrinking to get the "smallest amount of detail" is often unhelpful.
Suppose I have a function which takes four string parameters, and I have a bug which means it crashes if the third is empty.
I'd rather see this in the failure report:
("ldiuhuh!skdfh", "nd#lkgjdflkgdfg", "", "dc9ofugdl ifugidlugfoidufog")
than this:
("", "", "", "")
I suggest it would be helpful if the README's intro expanded a little more on the project's scope. "for postgres" is a bit vague, and "focusing on developer experience and reliable SQL tooling." doesn't tell me much about what it actually does.
If I was coming to this project for the first time I think the questions I'd immediately like the answers to are:
- What language is this language server for? Is it just for SQL proper, or for PL/pgSQL, or writing C extensions, or what?
- What makes it PostgreSQL-specific? Is it just that it follows PostgreSQL's dialect of SQL?
- Does it expect to be told about your database's schema? And if so, do you tell it by giving it a database connection, or letting it see files defining the schema, or what?
A year or so ago I read through one smallish section (basically function calls) and filed issues for the problems I found that were easy to write up crisply.
They fixed the easy bugs:
https://github.com/ferrocene/specification/issues/453 https://github.com/ferrocene/specification/issues/454 https://github.com/ferrocene/specification/issues/455 https://github.com/ferrocene/specification/issues/458 https://github.com/ferrocene/specification/issues/459 https://github.com/ferrocene/specification/issues/460 https://github.com/ferrocene/specification/issues/461 https://github.com/ferrocene/specification/issues/463 https://github.com/ferrocene/specification/issues/464
But they didn't try to fill the gaps:
https://github.com/ferrocene/specification/issues/462 https://github.com/ferrocene/specification/issues/465 https://github.com/ferrocene/specification/issues/466
There were a lot more places where I had notes saying "it needs to say more about X" that I couldn't face trying to file issues for.
I think that part of the spec wasn't any worse than average.
The Ferrocene Language Specification has two serious problems: there are very large gaps in it, and what's present is very buggy.
If you pick a small part and look at it in isolation it typically looks quite plausible, but if you try to follow the definitions it very often just falls apart.
Beyond the basic implementation of quoting and escaping, those are things you also have to worry about if you use someone else's csv parser.
And if you implement your own, you get to choose the answers you want.
The former.
The bad documentation I come across often shows every sign of having taken the advice from this article (and others like it) to heart.
The trouble is that the advice doesn't include ways to make sure your documentation actually covers everything it has to.
What this article says is that you should have « "API documentation" for every user-facing part of your project. »
That commonly leads to "reference" pages which are very little better than the autogenerated documentation the author dismisses. The main problems tend to be that behaviour that isn't controlled by a specific command or function or configuration setting doesn't get documented at all, and that commands with complex behaviour get described using terms that themselves need further definition which isn't provided anywhere.
When I come across bad documentation (which is often), by far the most common problem I find is that the information I needed just plain isn't present.
Articles like this one really aren't helping. If you wrote a piece of software I'm using that doesn't make you my teacher. It makes you someone offering a contract, and what I need to know is what that contract says.
The first duty of your documentation is to be complete and correct. Unless you've got that sorted, no amount of "putting yourself in the student's place" is going to give adequate results.
"-let" is another one, which is sometimes used in non-childish contexts (eg in "tasklet" or "chiplet").
Apple/ARM platform development will continue downstream. If I feel like sending some patches upstream in the future myself for whatever subtree I may, or I may not.
I suppose it's possible that that could turn out well.
The situation with Apple hardware feels a bit like the early days of Linux (including the fast pace of development). There was a time when if you wanted broad hardware support it was better to run an Alan Cox kernel than a Linus kernel. And the whole point of git was to have a system that didn't require one central blessed tree.
after a quick look at the SMART stats, everything appeared normal. Later, though, the reader did a more thorough Field Accessible Reliability Metrics (FARM) test and discovered [that it wasn't]
I had a look at how to run these FARM tests, and it seems I want smartctl 7.4 (which is too new for Debian stable but available in backports).
Probably not.
Letsencrypt don't provide a way to tell them "I'm not using this certificate any more", so they send out so many false-positive warnings that they're likely to drown out any signal.
Every time I move a service to a machine using a different letsencrypt account, or add a domain to a certificate, I get an unactionable warning email.