This is what the Windows Vista/7-era UX guidelines say/said on on the matter:
Consider providing menu item icons for:
- The most commonly used menu items.
- Menu items whose icon is standard and well known.
- Menu items whose icon well illustrates what the command does.
If you use icons, don't feel obligated to provide them for all menu items. Cryptic icons aren't helpful, create visual clutter, and prevent users from focusing on the important menu items.
I think there is something going on, as the BE200 is E keyed rather than A+E keyed like the AX210. It physically won't fit in the slot in my AMD laptop where I previously installed an AX210.
You can reopen closed tabs and windows from the History menu. It will restore the state of forms, so that form state is retained somewhere (presumably memory).
Traditionally (in the UK), it was reserved for large, varied shops like department stores. However, the American usage to mean any shop has certainly been spreading in business-speak for a fair while.
From the OED (the entry has not been updated recently):
> Chiefly N. Amer. and elsewhere outside the U.K. In early use, a shop on a large scale, and dealing in a great variety of articles (see quot. 18082). Now, equivalent to the British use of shop n. 3.
> The use of the word in this sense has not become common in the U.K. except in Comb., as chain store n. at chain n. Compounds 3, department store n. at department n. 5 (see under the first elements), store detective n. at Compounds 1d(a), in which it still refers to a large shop.
The two knowledge base articles linked are also interesting:
Speculative Execution Exploit Performance Impacts - Describing the performance impacts to security patches for CVE-2017-5754 CVE-2017-5753 and CVE-2017-5715
Controlling the Performance Impact of Microcode and Security Patches for CVE-2017-5754 CVE-2017-5715 and CVE-2017-5753 using Red Hat Enterprise Linux Tunables
It comes across as fairly defensive. Presumably the statement was hastily put together, but it's not really the tone you want to strike when you have a lot of worried customers wondering what is going on.
> Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers.
A rather bizarre statement of nothingness, and also an odd thing to say in a statement that just named AMD and ARM.
> Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.
It's interesting to note what it doesn't say – as it would seem to imply that for some workloads the performance impact will be significant.
“Workload dependent” clearly implies (despite the spin they are trying to put on it) that some users will be worse off than others. What isn’t my at all clear (to me) is what they mean by ”will be mitigated over time”. Are they implying that when we buy new professors (from them) there’ll be a hardware fix that won’t require the performance-sapping patch?
Quoting ARM and AMD is really a bit pathetic too, IMHO, especially if it turns out that AMD chips are immune to the flaw.
> What isn’t my at all clear (to me) is what they mean by ”will be mitigated over time”. Are they implying that when we buy new professors (from them) there’ll be a hardware fix that won’t require the performance-sapping patch?
Another possible interpretation: the early patches will create performance issues, but we'll issue subsequent patches that will make the performance issues less noticeable.
Not saying this is the right interpretation, just another possibility.
That's probably a more accurate interpretation, but the wording is maddeningly ambiguous... just the fact that we can sit here and posit such wildly divergent interpretations is testament to how utterly woolly the statement itself is.
> Quoting ARM and AMD is really a bit pathetic too, IMHO, especially if it turns out that AMD chips are immune to the flaw.
The official fix for this in the Linux kernel has a comment that literally says to assume all x86 processors suffer from the same issue and will disable KPTI for all x86 processors, including AMD.
There's an AMD-specific patch that I saw floating around that keeps the setting enabled for AMD processors, but I'm not sure if it made it into the mainline.
The original fix had a comment that literally said, "/* Assume for now that ALL x86 CPUs are insecure */" They've since added a check to exclude AMD processors.
I don't know if it's possible to see who contributed that patch (yet), but I’m cynical enough to half-expect that the “assume all x86 processors are insecure” patch might come from an Intel engineer...
I would not be surprised at all, considering the patch I saw for the AMD processors was literally a one-line if statement around the set cpu insecure flag that added a check for AMD processors.
The 5% to 30% performance hit (dependent on workload) was measured with PCID. The hit may be more on older CPU's that do not support PCID.
So Intel might make out OK on this, since people will have to update their servers, and right now there are many more x86 server hardware choices which use Intel chips. The truly scary thing from Intel's perspective is if people decide to use this as an opportunity to move to AMD, or worse for them, completely outside the x86 ecosystem, to ARM64 or PPC64LE systems. I have heard accusations that Intel has strong-armed motherboard manufacturers so there are't that many choices for those other platforms --- at least so far. But of course, everything can change over time.
Because let's be honest: when I bought my XEON and i5 processors, performance wasn't the issue that made me pick Intel over AMD. PUH-LEASE. This is the worst kind of customer service malarky I have read in a while.
The "average" computer user may not notice the difference, but servers running Intel processors are used by businesses, hospitals, government, the military, cloud providers, and on and on. Often these organisations are thrashing this infrastructure to within an inch of its life.
Until fairly recently I was consulting and, no exaggeration, one of my former clients: if their SQL Server host takes a 15%, never mind a 30%, performance hit, they're screwed.
I personally have just been the prime mover in the procurement of a server costing £25k with a 3 year support contract, pretty carefully specced according to performance. And you're telling me I should be OK with that machine taking a 30% performance hit below what we specced? No way.
EDIT: Sorry, original version of last sentence was a bit out of order - the tone of that release got under my skin a bit.
Sure. Catching mainstream media off guard is different from Intel though. There is no way this caught them by surprise.
If anything it reads like it was very carefully crafted by lawyers to make sure they don't get sued to hell for a defective product. (It's not but lawyers are gonna lawyer)
They may not have realized it would make it to the media; until this week there was not much chatter, and then today Intel's stock is trading lower while every other chipmaker is trading higher. Their PR team may not have been prepared for that situation, and they may be worrying about CTOs giving more serious thought to AMD (or even non-x86 chips) for their data center upgrades.
> A rather bizarre statement of nothingness, and also an odd thing to say in a statement that just named AMD and ARM.
Particularly bizarre considering the use of "believes". If Intel disbelieved that their own products are the best in any particular respect, that might actually warrant a press release on its own.
In any case, the claim that "no user data was collected or shared" is suspect.
Users who enabled the extension and visited NBC Universal's site (and others) were sending extra HTTP header data to the server, data that identified them as a Firefox user, of a specific version, who had a particular extension installed -- that's how the "engagement" worked.
Do you think the server(s) that handled these types of "special" requests were configured to specifically _not_ log the incoming traffic or extra headers?
Do you think that NBC Universal would spend the resources to build an elaborate[1] ARG focused on digital "engagement" with fans, form a relationship with Mozilla to promote the show and ARG to Firefox users, but also specifically _not_ collect data about those users?
I wonder how many people who were under the same impression can admit they were wrong, and of those, how many are able to tone down their outrage to the level warranted by the communication issue.
Outrage is really hard to dial back, even in the face of new information - I know it is for me. I guess that's an interesting corollary for many of the events we see happening in these polarised times.
Consider providing menu item icons for:
- The most commonly used menu items.
- Menu items whose icon is standard and well known.
- Menu items whose icon well illustrates what the command does.
If you use icons, don't feel obligated to provide them for all menu items. Cryptic icons aren't helpful, create visual clutter, and prevent users from focusing on the important menu items.
From: https://learn.microsoft.com/en-us/windows/win32/uxguide/cmd-...
reply