All of the headline changes go in during a two-week window at the start of the cycle, having been developed previously. Several people write articles during that window about what got merged, so the list is already known when the release actually comes out two months later. (That two-month period is used for testing in more unusual situations and checking for incompatibilities among the set of changes that got merged for the cycle.)

So this article is really reporting that two compact weeks of merge decisions in early October are now officially considered tested and ready, and they wrote the article and people checked it over a while ago now.

The part that's harder to track is ongoing development work, which happens continuously without a set schedule, but it happens in separate trees and only goes into the official tree when it's complete, has been reviewed, and has gone through various testing in systems managed by kernel developers. All of the work described here was done before 6.17 was released, and developed during several releases before that, but it didn't need to affect Linus's tree until he decided it would land in 6.18.

They generally use a primary and standby system, just because it's a lot harder to avoid consistency problems with multiple primaries. This means that you need to direct traffic to the current primary, and redirect it to a standby when necessary, which is fine except that the system you're switching away from and the configuration interface for your DNS provider are both in us-east-1, because everything normally is. That's why they're looking for the ability to make a different region primary specifically during in AWS outage.

There's a typo in the headline. It's supposed to read "Microsoft Forms Superintelligence Team Under AI Chef Suleyman 'To Serve Humanity'".

I use the magsafe on my laptop. I almost always use the laptop in the same place and only charge it there, so it's not getting mixed into my collection and picked back out, and the magsafe is somewhat easier to fumble into place than USB-C. If I was using it long enough somewhere different to need to charge it, I'd grab a USB-C (probably already nearby), rather than collecting the magsafe from where it's set up.

They could include things like special lines at immigration, rather than just visa requirements. Arriving in Amsterdam with an EU passport is much less of a hassle than arriving with a US passport, but they both count the same on this report. Then there's the question of whether you need a permit to stay indefinitely, or just the passport.

The person who made the report is a professional penetration tester. His usual method is to look for anything that could be wrong and then test whether it actually is. What he found is that the AI tools came up with potential issues he hadn't thought of, and they weren't all wrong, so it's a valuable tool to him because he normally runs out of ideas rather than running out of time to test them. He complained about the UI making it hard to go through large lists of reported issues exhaustively, and he only used the suggested fixes to get a better idea of what the issue was supposed to be. So it's clear that the tool's output wouldn't be directly useful to a maintainer, but it does serve a purpose.

I got a third-party cable for my phone that my phone recognizes as being able to charge it faster than the cable that came with the phone could. They should probably warn you that they don't have a cable or charger, in case you're getting a phone because you lost everything and don't have that stuff, but the first-party stuff isn't better these days.

I think it's even more interesting, in that one or two humans have to decide whether to question a call, and they have to identify calls that were wrong, not just ones they want to overturn, and they don't have a great angle to figure out what the algorithm would do. I think it's going to be fun to see batters try to do the ump's job, while standing to the side and considering swinging at the pitch.

I think the real issue is warm parts of China selling to cold parts of India without including the features that aren't needed near the factory. We know lots about battery chemistry, but rural farmers have had more immediately relevant things to know about up to now and don't have a good source of information on this new thing the government is pushing, so they skip things that sound like luxuries and end up with something inappropriate for their purpose.

It used to be the case that scientists had a good theory about what weather there would be in different seasons, and this theory was usually right. They couldn't predict daily weather all that well, but they could predict that you could reasonably grow oranges in Florida without worrying about it being colder than Maine for a week and snowing a month later, and they could tell you that there would be snow in Vancouver and not in Dallas.

Now conditions are outside the boundaries that climate models are based on, and scientists really have no clue any more. And it's not just the scientific climate models that don't apply; common sense and experience are no longer relevant, because we don't have history that tells us what happens in this environment, measured, anecdotal, or otherwise. In all of our past experience, the arctic wind has blown eastwards around the pole. Then one year it blows across the pole into Europe. Two years later, it blows across the pole into North America. Is this going to be a regular occurrence? Nobody knows.

The extent to which climate change has a falsifiable hypothesis, it is rejecting the null hypothesis. That is, you can ask: is the environment now following the patterns we have previously observed? We find that we are observing patterns that we had not observed previously, including some that we would have noticed had they occurred in a substantial time period. On the other side, we've previously been able to demonstrate enough of an understanding of climate to know how to build houses and what crops to plant where. But the evidence that you should build houses in Florida to keep heat out and houses in Maine to keep heat in is getting less certain. The issue is not that scientists know that something bad is going to happen, it's that nobody has any clue if something bad is going to happen, even after taking into account that some bad things never happened before, because the situation is just different in some measurable ways.

Personally, my guess is that the planet has major negative feedback, or it wouldn't have stayed in a reasonably narrow range of climates long enough for life to get this far. More greenhouse gasses in the atmosphere will trigger more cooling by some other mechanism, which might be okay or might be all of the continents turning into highly-reflective deserts instead of light-absorbent arable land. We really can't make an accurate prediction.

There's got to be a significant correlation between having the seasonal flu vaccine recommended for you, and being exposed to swine flu. Surely we should expect that people who choose to get seasonal flu shots do so in part because they're more likely than average to come down with the flu if they don't get a vaccine. Being at high risk for exposure to the flu is a clear mediating factor in leading to both getting every available flu shot and coming down with any strain that goes around that there isn't a vaccine for.

To put it another way, we vaccinate some people go keep them from spreading the flu. If there's a link between getting the vaccine and getting the flu if you don't get the vaccine, then we're vaccinating the right people, and we should go on vaccinating them. (But it's worth making sure people know that they can't act like they're immune to the flu this year.)

Of course, the study could have found an actual danger to the vaccine, but we can't tell until the peer review is complete; peer review is where people will come to some sort of consensus on what the risk is that this value should be compared to.

That's why there's a legal system to which the two parties present their evidence before a judgement is rendered. If this guy can actually present the evidence he says (here) he has, he should win in court. If he's lying here, he should still go to court, and lose big. (Or, more likely, they should go to court-backed mediation, where they can show their evidence to a mediator who can make a decision if it's obvious and make it stick if they both accept it.)

He makes a good point about the weird Ubuntu version scheme: a new user is likely to think that you could update from version 8.04 to 8.10 as a ordinary incremental change. But an expert would know that 8.04 and 8.10 are actually dates ('08.April and '08.October), and everybody actually calls them Hardy and Intrepid whenever they're saying anything that might be useful information. For that matter, the recent code names actually tend to give accurate suggestions about the sort of release it will be, with the LTS one suggesting robustness and the others suggesting ambition of various sorts. (Are you sure you want to move from something Hardy to something Intrepid? On the one hand, you get new stuff; on the other hand, it won't live as long)

$ host www.whitehouse.gov
www.whitehouse.gov is an alias for www.whitehouse.gov.edgekey.net.
www.whitehouse.gov.edgekey.net is an alias for e2561.b.akamaiedge.net.

Reducing their bandwidth and server load is just not a big deal. (See Akamai and note that the whole site takes the path that the "image" request takes in that diagram.)

You can probably simplify the git workflow a lot.

You don't need to update at all until you're done with your branch. If there were any benefit to updating regularly, you could get exactly the same effect at the end by rebasing a dozen times against progressively newer commits in the upstream history. The exception, of course, is if someone has done something you want to use, but you can just update to the point you require. SVN doesn't have a command for "updating all the way is too hard, update only a little bit at a time", which gets people in the habit of updating all the time.

If this is your whole workflow, you shouldn't have any of your own changes on the master branch (except, of course, when you send out your work branch and then get it back in the next pull), so you shouldn't need to fix anything there; in fact, the "pull" should just say "fast-forward" and give you exactly what is in the main repository. In fact, you can skip having a master branch at all, and just rebase against "origin/master" (which is the state of the main repository the last time you looked).

You should use "git commit" all the time. Until you push, you can revise commits after you make them. As soon as you've done any work you wouldn't want to redo, commit it. Then use "git commit --amend" when you do more. Eventually, do another amend to write a real message, inspect the change with "git show", then fetch, rebase, make sure you still like it, and then push.

I generally work with two branches, one which contains just whatever I've written as I write it, with tons of commits with the message "more stuff" or "fixes", and the other formed by getting a diff between origin and the junk branch and applying only those parts that are actually all one logical change and all good, and committing it with a good message. I repeat this until my good branch contains everything worthwhile, and then I dump the branch that's only got unneeded debugging statements, whitespace changes, and so forth.