Poster just means that Wayland support is perfect, I think. In any case, GNOME 3 has gotten better. I tweak it, and yes I wish that wasn't needed for pleasant use, but once tweaks are added GNOME works reasonably well.

I think a key part is simple: good story quality. Key steps:

1. Eliminate duplicates. The submission system should quickly warn of potentially duplicate URLs or subject words.
2. Quick review. Find a way to have a quick review of the story summary before posting. You don't want to slow down the flow too much, but it'd be good to have someone check for missing "not"s, URLs that don't work, and so on. I would assume you already have a spelling and grammar checker, but it's not clear it's always working. That sort of basic for a few sentences really shouldn't take that long.
3. Try to find good topics. That one in some sense is the hardest.

The discussions are sometimes interesting - and sometimes not. But I think if the stories start higher-quality, the follow-up discussion is more likely to be better.

In the longer term, the system for entering text is... quirky. Has someone considered using Markdown? Yeah, Markdown processors vary, but lots of people know Markdown (e.g., via GitHub), and specs like CommonMark and libraries like Red Carpet make it fairly painless.

Good luck!

I think "Planetary Defense Office" is a cool name. Someone should invite William Shatner.

The point of the article How are students learning programming in a post-Basic world? isn't that we should all use Basic. The point is that there's a need for a single 'starter' language so that people who have no experience can get started using something. That language should come with practically all computers, should be portable enough so that you can write programs that port to many computers, should be immediately accessible so beginners can quickly learn some basics, and should be useful enough so that beginners can create useful programs.

There are a number of reasonable contenders, including Python, Ruby, and Java. A version of Ruby comes with MacOS, but none of these 'just comes' with the computer regardless of what OS you run - so in most cases, before you even get started, you have to explain how to download and install something. Not ideal. Java is what a lot of people use professionally, but it does take more time to get started when you know nothing. Python has many advantages for simplicity, but you need to install it in many cases.

Perhaps the dark horse here is Javascript ES6. Javascript is available almost everywhere, and people can get started quickly. As a first language Javascript's unusual approach to OO programming (with prototyping) has probably held it back, but ES6 adds standard class notation, and that might make it much easier to use as a starter language.

I looked at the list, and it's really no big deal. Firefox will just add support for some aliases for standard names, so that existing websites that use "-webkit" prefixes will "just work" today. That's good for users, and it doesn't mean the 'death of standards' or anything like that. It's reasonable to ask people to use the standard names going *forward*. However, it takes a long time for older sites to update, and they rarely update completely correctly. This decision means that Firefox users will have a good experience looking at other sites.

Italy believes Apple was supposed to pay €880m in tax between 2008 and 2013, and Apple only had to pay €318m instead. If this report is accurate, Apple's tax evasion appears to have been handsomely rewarded. Perhaps Italy's estimate of taxes owed turned out to be wrong. Maybe. However, I suspect the tax authorities simply decided it was easier for them personally to just settle. The problem is that this creates a terrible precedent... and also robs their citizens of the services those taxes were supposed to fund. I'm no fan of big taxes, but each country gets to decide what taxes and services are appropriate. Other companies have now been told that it would be foolish to pay their taxes. If countries want to prevent tax evasion, they need to actually acquire all the back taxes owed, along with stiff penalties to discourage recurrence.

There is a moon that orbits the Earth that English speakers normally just call "the Moon" (note the capital letter for a proper noun). That doesn't mean there aren't other moons (obviously). If we need to give it a name, I'd suggest the Latin name (Luna), but most people don't use that terminology. Similarly, we are in "the Solar System", but I don't see a problem calling other systems "solar systems"; they just aren't THE solar system.

Good. 8 more years of time working correctly. The fundamental issue is that the Earth just doesn't care what our atomic clocks measure. If programmers want an exact time system without leap seconds, use TAI, that's what it's for. Most people in the world don't care if it's hard to code leap seconds. Instead, most people go outside occasionally, and they expect that 'noon' means approximately 'sun at highest point'. We can switch to some system other than leap seconds, but if we expect 'noon' to have its conventional meaning, then we need to agree on a system that does that.

This makes the most sense of all the proposals I've seen. How can we help encourage the FCC to consider this? Is there an email address at the FCC for taking comments (e.g., to encourage it)? I'd like to send a "me too" so that the FCC knows to consider this proposal carefully.

If you're worried about compromised CPUs being used to compile executables that are used by others, then reproduceable builds are a great countermeasure. Just use reproduceable builds on many different CPUs, and compare them to ensure they are the same (for a given version of source and tools). The more variations, the less likely that there is a subversion. If what you're compiling is itself a compiler, then use diverse double-compiling (DDC) on many CPUs.

If you're worried that an INDIVIDUAL may end up with a compromised CPU, then yes, it's much harder to counter attack. On some systems, you can isolate the system (no network traffic, etc.). That said, an adversary has to send packets to subvert a specific system, then every time they do the subversion they risk being detected, so it's far less likely to be used for bulk surveillance... it would more likely be one well-resourced organization (e.g., a government) working against another well-resourced organization.

If scholar just means "one who studies", then obviously anyone who studies a religious text for a long time BECAUSE they're a believer is by definition a scholar. I don't think that's what you mean.

If we change "scholar" to "scientist", it's quite clear that scientist is not synonymous with atheist. Pew research found that "just over half of scientists (51%) believe in some form of deity or higher power; specifically, 33% of scientists say they believe in God, while 18% believe in a universal spirit or higher power". Besides, many would say that science requires repeatable experiments, and many truths simply aren't repeatable (e.g., history).

Most scholars don't think that the Talpiot Tomb has anything to do with Jesus. For exampel, Géza Vermes says the arguments for the Talpiot tomb are not "just unconvincing but insignificant" (see the Wikipedia page). Also, Christian theology does not depend on whether or not the shroud of Turin is real.

I'm not muslim, but even the summary notes a perfectly reasonable explanation - the parchment could be an old one. And frankly, I'm skeptical that the carbon dating is that precise; carbon dating depends on a lot of assumptions that can easily be false in specific circumstances. (Yes, radioactivity decreases at a fixed rate... but you have to make BIG assumptions about its starting value.) So while this article makes for a good headline, the current actual evidence is rather worthless.

I've been googling around and can't find any evidence that it's blocked or mitigated. I know it *was* vulnerable, and can find no evidence to the contrary, so I have to presume it's still vulnerable. Blech.

What about the disastrous SwiftKey vulnerability? It makes Samsung Android systems vulnerable too. Samsung said they'd fix it back in June, but we still have no patch.

When buying an Android phone: Measure how many days it takes from the vulnerability report (at least publicly) until it's patched in phones already used by customers. Focus on phones more than 2 years old, since your phone will be that age someday. Then: Don't buy from unresponsive makers. I suspect that if a few buying guides included those numbers, some manufacturers and service providers would start paying attention.

"How would an experienced developer get these problems in the first place?"

A lot of projects do not follow widely-accepted best practices... even if they are experienced... and that is a problem!

A remarkable number of OSS projects fail to have a public source control system (#2). That includes many established projects that everyone depends on. Actually, a number of OSS projects - and projects that people THINK are OSS but are not (because they have no license) - fail many of these points. It's not that Red Hat's internal processes are immature; Tom was trying to bring in software from someone else (Google in this case) and was fed up by the poor practices from people who should know better.

Yes, #7 refers to a best practice (let people pick their install directory) that's been around for at least 20 years and probably much longer, but it's still widely NOT followed.

Anyway, that's Tom's point; there are a lot of widely-accepted best practices that are NOT followed, and that needs to change.