How old is your PC? My 10 years old laptop has a TPM built into the CPU (Intel PTT), which Windows 11 is perfectly happy about once I figured out how to enable it in the boot options.
+1 to being really really sceptical of anyone claiming to have a 10 year old system that supports it. Skylake is literally well known for not supporting TPM 2.0 and the i7-6700K is still considered reasonably high end by todays standards (tech hasn't moved fast in the past decade and the 14nm Skylakes aren't that far off the 14nm+++++ high end variants Intel sells today).
The first draft of TPM 2.0 was 2015. The finalized version was Nov 2019. Intel 8th gen and above do have the option to upgrade to TPM 2.0 via a firmware update but as you point out those CPUs are not 10 years old.
That's one of the problems with this TPM 2.0 requirement. Tech has not moved fast in the past decade and the requirement is asking people to throw away 10 year old systems that can still easily beat today's midrange lineup.
I think what OP may be experiencing is that Windows 11 does install on older TPM 1.x hardware. It just nags to upgrade the hardware to TPM 2.0.
(I'm not seeing any "nags" anywhere, I don't know where that would be?)
Edit: I just noticed that that page is the same that was linked from the article. Yet it still contains the block that the article claims has been removed. Did they put it back in again?
Edit 2: Or I do have TPM 2.0? It seems to think that I do:
So yes, this is TPM 2.0. And TPM 2.0 was released in a non-draft version at the time my CPU was made. And the "1.16" is the revision number of the TPM 2.0 specification that it supports.
I went and checked now, and your timeline seems way off. According to https://trustedcomputinggroup.org/resource/tpm-library-speci... the first draft of TPM 2.0 was in 2013 not 2015, and the first "non-draft" version was in 2014 not 2019. It does make sense, revision 1.16 of TPM 2.0 does predate my CPU.
The PC Health check app says it's not supported, but the installer doesn't complain. I don't know if it would have allowed me to update automatically, but it works when using the ISO.
A bit of an aside I have been wondering about is what people called her in her own time. Her name was Augusta Ada King, and she was the Countess of Lovelace. Was it common back then to shorten the title into a last name, or is it only something we have been doing in more recent time?
For the title holder, in this case the Earl of Lovelace, they are often referred to ("styled") simply by the place name. So after William King-Noel was created Earl.of Lovelace he was styled "Lovelace". She would have been styled "Lady Lovelace" in society, and "Countess of Lovelace" in formal contexts
I think the limit for discernible features when using an optical microscope is somewhere around 200nm. This would put the limit somewhere around the 250nm node size, which was used around 1993-1998.
That is Google's choice. They weren't allowed to give Google Maps as the only option. Rather than implementing a way for the user to choose which site to use for maps they decided they would rather remove the feature altogether.
Yes, though O’Brien is Ó Briain in Irish, according to Wikipedia. I think the apostrophe in Irish names was added by English speakers, perhaps by analogy with "o'clock", perhaps to avoid writing something that would look like an initial.
There are also English names of Norman origin that contain an apostrophe, though the only example I can think of immediately is the fictional d'Urberville.
I have an 'æ' in my middle name (formally secondary first name because history reasons). Usually I just don't use it, but it's always funny when a payment form instructs me to write my full name exactly as written on my credit card, and then goes on to tell me my name is invalid.
I got curious if I can get data to answer that, and it seems so.
Based on xlsx from [0], we got the following ??d? localities in Poland:
1 x Bądy, 1 x Brda, 5 x Buda, 120 x Budy, 4 x Dudy, 1 x Dydy, 1 x Gady, 1 x Judy, 1 x Kady, 1 x Kadź, 1 x Łada, 1 x Lady, 4 x Lądy, 2 x Łady, 1 x Lęda, 1 x Lody, 4 x Łódź, 1 x Nida, 1 x Reda, 1 x Redy, 1 x Redz, 74 x Ruda, 8 x Rudy, 12 x Sady, 2 x Zady, 2 x Żydy
Certainly quite a lot to search for a lost package.
Interesting! However, assuming that ASCII characters are always rendered correctly and never as "?", it seems like the only solution for "??d?" would be one of the four Łódźs?
There were no "big" rivers, ever. More like springs. We have lots of subterranean water, so out of the 18 rivers we have in the city, 16 have their sources here [0]. They were used to power mills in the 19-20th century during the industrialization. Many of the rivers that used to go through the city center flow underground.
I live close to the river Olechówka [1], which flows into a regulated reservoir that used to feed a mill - so the area is called Młynek, "Little Mill" :)
As you may be aware, the name field for credit card transactions is rarely verified (perhaps limited to North America, not sure).
Often I’ll create a virtual credit card number and use a fake name, and virtually never have had a transaction declined. Even if they are more aggressively asking for a street address, giving just the house number often works.
This isn’t a deep cover but gives a little bit of a anonymity for marketing.
The thing is though that payment networks do in fact do instant verification and it is interesting what gets verified and when. At gas stations it is very common to ask for a zip code (again US), and this is verified immediately to allow the transaction to proceed. I’ve found that when a street address is asked for there is some verification and often a match on the house number is sufficient. Zip codes are verified almost always, names pretty much never.
This likely has something to do with complexities behind “authorized users”.
Funny thing about house numbers: they have their own validation problems. For a while I lived in a building whose house number was of the form 123½ and that was an ongoing source of problems. If it just truncated the ½ that was basically fine (the house at 123 didn't have apartment numbers and the postal workers would deliver it correctly) but validating in online forms (twenty-ish years ago) was a challenge. If they ran any validation at all they'd reject the ½, but it was a crapshoot whether which of "123-1/2" or "123 1/2" would work, or sometimes neither one. The USPS's official recommendation at the time was to enter it as "123 1 2 N Streetname" which usually validated but looked so odd it was my last choice (and some validators rejected the "three numbers" format too).
Around here, there used to be addresses like "0100 SW Whatever Ave" that were distinct from "100 SW Whatever Ave". And we've still got various places that have, for example, "NW 21st Avenue" and "NW 21st Place" as a simple workaround for a not-entirely-regular street grid optimized for foot navigation.
Are we sure they don't actually validate against a more generic postal code field? Then again some countries have letters in their postcodes (the UK comes to mind), so that might be a problem anyways.
Canada has letters in postal codes.
That’s the issue the GP is referring to, since US gas stations invariably just have a simple 5 numeric digit input for “zip” code.
There is so many ways to write your address I always assume it it’s just the house number as well. In fact I vaguely remember that being a specific field when interacting with some old payment gateway.
Still much better when it fails at the first step. I once got myself in a bit of a struggle with Windows 10 by using "ł" as part of Windows username. Amusingly/irritatingly large number of applications, even some of Microsoft's own ones, could not cope with that.
"Write your name the way it's spelled in your government issued id" is my favorite. I have three ids issued by two governments and no two match letter by letter.
My wife had two given names and no surname. (In fact, before eighth class, she only had one given name.) Lacking a surname is very common in some parts of India. Also some parts of India put surname first, and some last, and the specific meaning and customs vary quite a bit too. Indian passports actually separate given names and family names entirely (meaning you can’t reconstruct the name as it would customarily be written). Her passport has the family name line blank. Indigo writes: “Name should be as per government ID”, and has “First And Middle Name” and “Last Name” fields. Both required, of course. I discovered that if you put “-” in the Last Name field, the booking process falls over several steps later in a “something went wrong, try again later” way; only by inspecting an API response in the dev tools did I determine it was objecting to having “-” in the name. Ugh. Well, I have a traditional western First Middle Last name, and from putting it in things, sometimes it gets written First Middle Last and sometimes Last First Middle, and I’ve received some communications addressed to First, some to Last, and some to Middle (never had that happen before!). It’s a disaster.
Plenty of government things have been digitalised in recent years too, and split name fields tend to have been coded to make both mandatory. It’s… disappointing, given the radical diversity of name construction across India.
That only works if you’re concatenating the first and last name fields. Some people have no last name and thus would fail this validation if the system had fields for first and last name.
Honestly I wish we could just abolish first and last name fields and replace them with a single free text name field since there's so many edge cases where first and last is an oversimplification that leads to errors. Unfortunately we have to interact with external systems that themselves insist on first and last name fields, and pushing it to the user to decide which is part of what name is wrong less often than string.split, so we're forced to become part of the problem.
I did this in the product where I work. We operate globally so having separate first and last name fields was making less sense. So I merged them into a singular full name field.
The first and only people to complain about that change were our product marketing team, because now they couldn’t “personalize” emails like `Hi <firstname>,`. I had the hardest time convincing them that while the concept of first and last names are common in the west, it is not a universal concept.
So as a compromise, we added a “Preferred Name” field where users can enter their first name or whatever name they prefer to be called. Still better than separate first and last name fields.
Just split the full name on the space char and take the last value as the last name. Oh wait, some people have multiple last names.
Split on the space and take everything after the first space as the last name. Oh wait, some people have multiple first names.
Merging names is a one-way door, you can't break them apart programmatically. Knowing this, I put a lot of thought into whether it was worth it to merge them.
People can have many names (depending on usage and of "when", think about marriage) and even if each of those human names can handle multiple parts the "text" field is what you should use to represent the name in UIs.
I encourage people to go check the examples the standards gives, especially the Japanese and Scandinavian ones.
It’s not just external systems. In many (most?) places, when sorting by name, you use the family names first, then the given names. So you can’t correctly sort by name unless you split the fields. Having a single field, in this case, is “an oversimplification that leads to errors”.
I’m not sure what you’re trying to get at. The field containing the family name is the one labelled “family name”. You don’t have two fields both labelled “name”; there’s no ambiguity.
Whether it's healthy or not, programmers tend to love snark, and that snark has kept this list circulating and hopefully educating for a long time to this very day
[0]: Presumably "Chinese (Traditional)" in the selector, but it shows that it is translating from "Chinese (Simplified)" until you click the drop down at which point it shows "Chinese (Traditional)" as selected in the selector box: https://i.imgur.com/kjZ1WQk.png
Great, now you can start putting your customizations in that directory instead of the OS-managed /etc/ssh/sshd_config blob. That's why the `.d/` convention exists.
I had to look up the info because I wasn't sure really, so I appreciate the direct question. It means 'directory' or 'conf.d pattern'. So you have your config file, and the config directory that contains "parts" of the config to be merged with the main one to provide customizations/overrides.
reply