arde

Very interesting, I like its design better. Could you comment on whether bupstash supports ACLs (POSIX, xattr, etc.)? According to issue #25 it does, but I couldn't find documentation on how to exclude it when restoring, viewing it, etc.

It's the spike protein that would mutate so as not to be attached by antibodies, but it would still attach to cell receptors (probably different ones).

Yes, new mRNA vaccines could be produced and distributed, thereby generating even more tolerance as this article shows and making things even worse for people's immune systems if so. The point is these vaccines are generating resistance to the virus but at the same time, unlike traditional ones, they are making the immune systems tolerant of the virus. The infection is incompletely suppressed, symptoms are mild or imperceptible, but the virus is getting passed on despite being partly suppressed.

The emergence of new strains is favored when there is a large medium (the reservoir population of people, tolerant but infected and shedding) where the virus can proliferate (thus plenty of viral code copying, where mutations happen) and where there is selective pressure (i.e., an advantage to the new strain such as being able to enter cells even more effectively because of the lack of interference compared to the current strain) for a mutated virus to thrive.

It would be harder to tackle because it would be even more infective than the current strain (given the tolerance that has been introduced in the population) but at the same time more aggressive (because more cells being entered would mean more damage to the body) and maybe with different kinds of damage (because it could trigger autoimmune responses, they say, although I'm not sure how that argument goes).

I'm not an expert on this so I cannot elaborate further, but that's the idea as far as I grasp it. We'll see, I guess.

My chosen solution to all this is Dendron. It's not perfect yet, but I found it better than the rest.

Some argue that precisely that mechanism generates evolutionary pressure for the virus to mutate so as to avoid being attached to by the antibodies but still being able to enter the cell (maybe through a different receptor, and there exist some viable candidates for this). The fact that such a large population has been vaccinated with mRNA vaccines, it is thought, has created a huge reservoir for the virus to attempt such a mutation because all those people get infected and shed the virus while being mostly asymptomatic or experiencing mild symptoms. New strains should soon appear if this is correct, and some other dire predictions are made in that case (see Geert Vanden Bossche).

He may have said that about Don Quijote, but it may well have been just another humorous comment by him. He was known for his dry humor and deadpan delivery. He was extremely learned, no doubt about it, but the reader has to keep in mind that about half of the elaborate citations and detailed references he uses in his writings were simply his fabrications, his way to play with the reader's ability to make out reality from fiction. He loved labyrinths, and putting people in them. Source: born and raised in Argentina, having a Literature professor as mother and another one as wife.

"Like the workplace itself, for most of us the stock market is simply another arena of capital extraction". So, to the author, workplace is an arena of capital extraction. Although the comparison is uncalled for, I'm glad of this candid Marxism because it lets me put this opinion piece in perspective. Given that bias I don't think I'll spend time reading it unless I'm bored.

Logseq forces to use too many bullets for my linking. I prefer Dendron, although it takes a bit of an effort at first.

Get your iron ass over to Errius.

I swear by my Herman Miller Embody chair. I used to have severe lower back pain, and this chair has helped me eliminate the pain by keeping a healthy posture. It's the only chair I found that locks my sitting position, keeping my hips the right way no matter how many hours I have to spend on it and still allowing healthy back movements.

Next time their plans should include some firefighting robots.

The CAP theorem strikes again.

What I like about HN is that comments are frequently even better than the linked content. This is a fine example.

Stephen Wolfram says they're impossible: https://www.youtube.com/watch?v=P7kX7BuHSFI&t=4387

What I'd like to know is if lucid dreaming attains the same quality of rest as normal dreaming. I doubt long-term effects of lucid dreaming have been studied.

I don't think I follow you, could you please explain what you mean a bit further?

I suppose Halley asked him about something anybody in Taiwan would know about the sky there, but not common knowledge for people in France.

Gwack-ah-MOH-leh

Check out, for example, the case of Martin Armstrong, held for 7 years in contempt of court for not producing items he said he didn't have. Eventually he had to enter a plea agreement and serve an additional 5-year term.

All of the classic papers I can think of have already been mentioned, but even though it's too recent to pass judgment a new contender may well be "Deep Learning and Quantum Entanglement: Fundamental Connections with Implications to Network Design" - https://arxiv.org/abs/1704.01552

It is a very good incentive for small kids as long as they are interested in watching TV and in the particular content shown. But not all kids like to stay quiet watching TV, some really need physical exertion and can't sit down.

Of course I referred to the language learning process in toddlers. By the time they reach school it's a different process, and they learn a lot of other subjects too.

> language ability seems to largely be a function of exposure and there's only so much time to go around.

There's an important shortcoming in that reasoning: it assumes that time is fully dedicated to learning whichever language is being used. Furthermore, it doesn't consider the possibility that learning a language may benefit from learning a different one.

Based on my observations while raising my kid bilingual, that's probably not the case. When she learnt a new word in a language, she usually asked for it in the other language too so she could learn both. At 6 years old, she now has much better language skills in both languages compared to her peers. There may have been a period at about 2 or 3 years old that her skills weren't outstanding but she was still perfectly fine by her age's norm (which accounts for quite a bit of variance). My guess is that, after learning a few basics, new language is learnt sporadically with lots of "waiting" time in between, and thus there's practically no time conflict in learning two languages except maybe at the very start.

Regarding that research, I can see that human interaction should more efficient but that doesn't imply that screen time should be ineffective. And my kid is a counterexample, because it did bootstrap her English. She had no other source since we live in Argentina and we practically didn't talk to her in English. For a while she had some serious British accent because she was hooked on Peppa Pig, but now she sounds mostly American.

> screen time doesn't count

Absolutely false. Screen time is an excellent way of exposing the child to a language and thus learning to distinguish the phonemes that make it up. It can be argued that screen time alone doesn't help too much in learning to speak a language (if by screen we mean a non-interactive one, of course). But it's great for listening comprehension.

Source: starting when she was a baby, I let my kid watch as much TV as she wanted as long as it was in English and not in our language (Spanish). She watched about 2 hours a day, on average. Her mother and I are quite fluent in English and, even though we rarely speak it among us, we encouraged our child to learn it this way, occasionally answering her questions or translating the words that she couldn't figure out by herself. She's now 6 and speaks it pretty well, she can easily maintain a conversation and she is very good at identifying the correct phonemes while listening (even in the cases when she may not know the word). Actually, she's better at listening comprehension than what her mother and I could ever hope to achieve ourselves. Differentiating phonemes is a crucial ability that is learnt optimally at an early age and after only a few years old it cannot be learnt that well (I remember reading an article about this limitation in Scientific American more than 20 years ago, I don't have a link for that).

Once upon a time that meant a free diskette ready to format. Still not super useful at the time, yeah.

If LTS' sole point were to keep a stable baseline, then that point would only be for the benefit of some short-sighted developer whose only interest were to keep his to-do list brief. Even a slightly more forward-looking developer would realize his work's point lies somewhere else, particularly when done in a corporate environment such as Canonical's and not as a hobby (but even when done as a hobby for a community project such as Debian). His work should be oriented towards goals somehow related to the costumer priorities, without whom it ceases to matter. Keeping a stable baseline is unrelated to any costumer or user interest.

The costumer or user of LTS wants, well, Support (fixes) for some extended time (Long Term) and avoiding problems (less bugs), perhaps at the cost of getting less new features. The whole point of LTS is self-explanatory.

Keeping a stable baseline is a tactic used to try to provide long-term support by reducing the amount of new bugs at the cost of less new features. But keeping a stable baseline does not attain the key word, the substantive in LTS: Support. Support is provided only by introducing fixes, and that is exactly what has been omitted in the case of the Intel microcode bugs.

> The whole point of an LTS release is that they will keep a stable baseline

I think you're confusing an objective (LTS) with a tactic (keeping a stable baseline). Certainly the whole point of LTS is not to keep a stable baseline, but to provide long-term support. And that is clearly violated when Ubuntu chooses to not provide support when it is known to be needed (e.g., listed in an Intel Spec update) and a solution is available by a vendor (e.g., Linux-specific microcode update being made available by Intel). The whole point of LTS is to avoid the bleeding edge while fixing known bugs. Microcode updates is not bleeding edge, it's just patches for known bugs.

I don't think yours is a serious answer, what I said already refutes your points. Ubuntu has already made me waste a week and I don't want to waste any more, particularly when you can't or won't listen to what I say and look for irrelevant excuses like the availability of UEFI vendor updates. Just FYI Intel provides these updates for very good reasons and RHEL/CentOS/Fedora have been providing processor microcode updates for ages now and with relatively frequent updates (see the microcode_ctl RPM changelog). Bye now.

By ancient I mean that it is 1.7 years old and by now Intel has published 4 later releases (20160607, 20160714, 20161104 and 20170511). I think it's a fair and tame adjective considering this is processor microcode we're talking about and that it made me spend a week of my own time hunting it.

You say Ubuntu has a bug to track the microcode package as an exception, but that doesn't seem to be having a positive effect, does it? Precisely because Ubuntu cannot pick it apart, what is it that they're trying to decide in the bug? Why is Ubuntu second guessing Intel in deciding which microcode update to apply and which to skip? How would Ubuntu know that better than the manufacturer? The Intel specification updates list tons of processor bugs including some very critical ones, so we know the microcode updates do help with some of those. When was the last time that an Intel microcode update brought a new bug or made something worse? I'm not aware of any such instance, and although that may indeed happen sometime it doesn't seem as likely as facing existing known bugs, right?

I think it could be argued that it is up to the user to decide (say, a warning during installation), or that Ubuntu could choose to apply all microcode updates by default and let the user opt out. Ubuntu might impose a certain delay, say a month or two at most, in order to see if a microcode update gets withdrawn or ends up too buggy. But I don't think Ubuntu could reasonably choose to skip all microcode updates for 1.7 years like it did in my case, or to choose which ones to apply and which ones to skip, like it seems to be trying to. Microcode should be treated like other propietary software, but with special dilligence due to its criticality. If nVidia says a particular driver release is very buggy and should be updated, Ubuntu promptly updates it. Why would Ubuntu sit on known critical microcode updates then? If, and it's really a big if, eventually some microcode update brings a new bug and Ubuntu deployed it, it would be Intel's fault and not Ubuntu's.

Indeed, the latest Intel microcode published for Ubuntu 16.04 is the ancient 20151106 [1]. Later Ubuntu releases do have more recent microcode packages [2]. I cannot understand why they left out 16.04 there. So much for LTS, it seems.

This recently came to my attention while debugging some increasingly frequent lockups, which took me a solid week of eliminating all seemingly more likely causes (VirtualBox, nVidia driver, faulty RAM, etc). In the end I found the culprit while digging into the Intel Specification updates: my Core i7-5820K (and most other Haswell-E and Broadwell processors) has a bug when leaving package C-states, and the only workaround is to disable C-states above level 1. Timely updated microcode, which applies this workaround, would have saved me my week.

[1] https://launchpad.net/ubuntu/xenial/+source/intel-microcode [2] https://launchpad.net/ubuntu/+source/intel-microcode/+change...