Sprocklem

> Granted, a lot of this boils down to whether AI learns or copys/remixes; [...]

I mean, it certainly isn't learning in the same way humans learn. Human learning involves some degree of understanding, which is wholly absent in AIs. There is, to my mind, no good reason to treat them the same because of this difference.

There is also ongoing work to add a `try_collect` method specifically for collecting into `Result`, etc. Hopefully, when this lands it will make this pattern more intuitive/obvious and eliminate some inconveniences in its use.

POSIX only guarantees write atomicity for pipes and FIFOs, not for regular files.

I was not suggesting the caller hold a mutex, but rather getenv(), which eould be transparent to the caller.

A number of libc functions return a pointer to an internal thread-local buffer, which is invalidated on subsequent calls. If the function copies the environment variable's value to such a buffer while holding the mutex controlling access to the global state, then the returned value is guaranteed to remain unaffected by other threads.

There are, however, other problems (discussed elsewhere in this thread) that complicate such an API in the context of getenv().

I recently visited my local Indigo after having not gone for a couple of years, and was surprised at how little space was dedicated to bookshelves. And even those shelves were surprisingly empty.

I'm sure that those other categories have higher margins, but I can't help but think that Indigo is shooting itself in the foot in the long term: none of those other products are paricularly good in quality or value and I can't imagine people would go to Indigo for many of those products. Instead, I get the sense that people go to Indigo for books, and see and buy those products while they are in the store. With an ever-decreasing selection of books, who knows how they're going to keep up the traffic required.

Of course, *_r is a better option, but the existing API is used so pervasively that it needs to be made thread-safe to actually avoid thread-unsafe code in, e.g, libraries.

I was suggesting that the buffer be invalidated by each subsequent call – like some other libc functions' internal buffers – although, as I noted in the edit this would need `getenv()` to be able to indicate errors (specifically ENOMEM). It currently cannot do this as currently described, because NULL is used to indicate an absent variable.

You could also require callers free the returned memory when they're done, but that would be another change of API.

The pointer isn't guaranteed to point into `environ` directly. `getenv()` could copy the value to a thread-local, (dynamically-allocated?) buffer while holding the lock.

Edit: In hindsight, a dynamic buffer would require returning ENOMEM errors (which might lead to some unexpected failures), while a static buffer would limit the value length. I think you might be right about the API being broken.

How do you propose that DNS resolution precede without opening a socket?

Greed is part of human nature, sure, but so is empathy and selflessness and a sense of justice. We certainly didn't need to build a society that rewards people for giving into one of their most selfish and cruel impulses.

Those might be better, but neither is a tag that is used in kernel commits. There is a list of specific tags that are used, and specific conditions on their use. "Reported-by:" was not a wholly arbitrary choice of words by the maintainer.

What the maintainer actually said was [0]:

> Thanks for your patch, but I wanted to fix it differently. Can you try the patch below and make sure it fixes the bug for you?

Which to me, at least, reads very differently than claiming the author's patch is worse.

[0] https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...

(Credit to nolist_policy for pointing this out upthread.)

Not quite. ChatGPT incorrectly mixes up SI and non-SI units.

Also, firefox on android will be supporting the install of any extension without using nightly and collections very soon.

Notably, the example given by GP also cannot function as a restrictive clause, since "that" is acting as a demonstrative rather than the head of a clause:

*Upon the submission of the cause the appellant made a motion (to amend its assignments of error) that motion is now granted.

The current ungrammaticality of the original example given in OP is due to the presence of "motion" within the wh-phrase (c.f., "Which motion is now granted?"), which does not have an equivalent construct for restrictive clauses using "that".

This notably differs from the example in OP by its position outside of the first sentence. AFAICT, your second sentence cannot function as a parenthetical like the example with "which motion".

Additionally, humans are unique in their ability to create complex social constructs and realities, which is a reasonable prerequisite for a potential to create novel methods of social organization.

Similarly, a list of firefox's "about:" URLs can be found in "about:about".

I think the murkiness of this recent history is more a matter of misunderstanding at the time than people misremembering after the fact.

I remember believing it prevented optionality for more than common words. I can't recall exactly when I believed this or if I ever knew it had changed to a verbatim meaning, but quotes always seemed the more natural symbol for the latter. I'm sure my belief in the obligatory-but-not-verbatim meaning of '+' was supported by its apparent contrast to '-', which excluded search results with that term, since it makes sense that the opposing symbols would have opposing meanings.

One (admittedly speculative) reason to believe that all natural spoken languages have a common ancestor derives from the fact that modern humans seem to rapidly develop new languages in the absence of an existing language, as was seen in the case of Nicaraguan Sign Language. There is no particularly compelling reason to believe that earlier homo sapiens ­– who were otherwise anatomically modern – would be any different before they began migrating out of africa. This is especially true given that all human populations do ultimately have both an apparently-innate capacity for language, and their own languages.

If this is the case, then the first language would have probably rapidly spread between the early populations in africa – if, indeed, there were multiple distinct populations at the time – and new (homo sapiens–originated) languages would have only arisen if the chain of speakers were somehow broken and children raised without access to an existing language.

With that being said, there are some cases where something similar has happened. Most obviously are sign languages, which are believed to have had multiple origins, since it is possible for deaf people to be born among non-signing populations. Something similar in the case of spoken languages is the phenomenon of pidgins evolving into creoles mentions elsewhere in the comments, although they still retain at least some aspect of one of their parent languages. The extent to which the latter count as proto-languages is questionable.

There is a balancing act here: while beekeeping does in many ways help support the population of non-native species, you are right in noting that a lot of eurasian plant species that we rely on need domestic bees – and honey bees, in particular – to produce our food. At the same time, that modern monocrop agriculture is further exacerbating the problems faced with non-native species – especially in the case of those eurasian plant species. It seems to me that honey bees must be kept in agricultural settings – and in that case, I hope that they are kept responsibly – but the urban beekeepers discussed upthread should, perhaps, put a larger part of their effort towards keeping native species.

> We're all invasive.

Humans are absolutely not an invasive species in the americas. We may have been when we first arrived – and many native species went extinct as a result – but humans have been a part of the local ecosystems for tens of thousands of years and – where I'm from in canada – have been here since the ice sheets receded and the local ecosystem began to evolve. We are far past the point of being an invasive species and have (had?) long been integrated into the ecosystems in question.

It generally does cache built crates for future builds on the same system, so it is usually only the initial build on a given system and the build after dependencies are updated that requires rebuilding serde_derive. I honestly don't know why they thought it was worth doing.

Perhaps I should have been more explicit: sending "a commit sha and branch name" is functionally equivalent in that it contains both the information necessary to retrieve the commits and a method of responding to the new commits, but is considerably less convenient. There is an extra step in sending the commit (you must push the commit then send the relevant data using a separate email client), and the resulting email lacks both the commit message explaining what was changed and why, and the changes in question, requiring one to manually examine the commits out-of-band. This is in addition to the need for all contributors to have write-access to the repository, mentioned above.

It is, however, also functionally equivalent to a pull request, excepting again the need for write-access.

I'm not sure I phrased that correctly. The point I was trying to get across with that sentence was not so much that web UIs are bad, but that if you are using a forge with in-browser support for reviewing changes (generally in the context of pull requests), then there is little benefit to sending "a commit sha and branch name" separately. Similarly, send-email–based workflows have little need to manage the repository in the browser. Email-based workflows and pull-request-based workflows are parallel in that they provide the same features in different ways.

We can quibble about which is more convenient (admittedly I find the former better in this regard, although I recognize that this is a minority opinion), but they are IMO both more-or-less equally viable choices.

The biggest difference is the need to have shared access and it therefore does not easily allow for contributions from people without write access to the repo, although a similar workflow is possible with multiple publicly-readable repos (esp. with the help of `git request-pull`). Another advantage a send-email–based workflow has (compared to the workflow you describe, at least) is that the presence of the patch in the email makes it trivial to respond to specific code changes inline, using standard email quoting.

ETA: Many forges reintroduce the latter (commenting directly on lines of code), in which case this may not be an advantage depending on if such a forge is used. (But then you're back to using a forge, and needing to open the website to review changes in addition to using git and email.)

I strongly disagree. I've recently contributed to a project that uses an email-based workflow, and find it considerably easier to use: after a surprisingly brief one-time setup, I can contribute patches using a single `git send-email` command from the same terminal that I make my commits, and can review and comment on patches from my email client of choice (thunderbird) – all without needing to create a new account.

Applying patches is, admittedly, a little more awkward, but it can still be done in two or three steps from thunderbird (including invoking `git am`) and, I understand, some newer email clients can handle this much much better.

> It makes vastly more sense to transmit a patch attached to the specific code base state that it is intended to modify:

This is no longer a problem. `git send-email` (and `git format-patch`, if you prefer to call it directly) has for a while supported a `--base=auto` or the `format.useAutoBase` configuration option to attach the upstream commit ID to the patch. To my knowledge this is currently only to help the maintainer understand its context but there is ongoing discussion of ways to automatically use this information.

For completeness sake, throwaway201606 linked to the resonse upthread: https://www.computerworld.com/article/2567290/no-more-bull.a...

In some disciplines, at least, the background also follows a separate introduction that briefly explains the problem and the paper's contribution. This follows an explanation->conclusion order, but only explains enough to understand their contribution, before diving more deeply into prior work in the background.

Occasionally a leap second is added or removed, to account for various sources of drifts. This leap second is taken to be the last second of the day where it is inserted, so the time technically either goes 23:59:59→23:59:60→00:00:00 or 23:59:58→00:00:00, depending on if a leap second is being added or removed.

That being said, many OSes handle this in such a way that 23:59:60 doesn't appear, either by repeating 23:59:59 (so it last two seconds), or "smearing" the extra second over the course of the day (so each second on the system clock that day is just over a second long).

Edit: I'm pretty sure I read recently that they are no longer going to be adding/removing leap seconds, although I'm not 100% sure that was a definitive decision.