1,746 karma · joined March 25, 2017
commit 2f438e20ab591641760e97458d5d1569942eced5
Author: Stefan Liebler <___.ibm.com>
Date: Thu Jul 31 20:04:54 2014 +0200
S/390: Revert the jmp_buf/ucontext_t ABI change.So maybe look into T14s Gen2 AMD (which may be pretty similar to X13 Gen2 since they share the HW maintenance manual). But YMMV of course, and I have no experience of M1.
I also have 64GB on my work T480 (non-s) despite "max" being 32GB.
The Lenovo-reported max RAM specs often do not take into account newer larger memory modules released after the laptop (or at least I believe this is the reason for the discrepancy).
Requiring multiple completely separate apps for different payment methods is insane - the reasonable way is to have the same app support both and show the non-Apple method only for Dutch customers.
Similarly, in most of continental Europe phase-to-phase is 400V but most outlets are 230V. E.g. in my apartment only the stove has a 400V three-phase (4-wire) connection.
I was originally looking to buy one of the X13 Gen 2 Intel models that have it soldered, I must've thought it applied to AMD as well.
I guess I'll try out Intel AX210 then, to see which one actually works better for me.
> - Came with MediaTek 7961 WiFi, which while supported by mainline Linux, the performance is trash (~30MBit on 802.11ac).
It works perfectly for me on Fedora 35 (kernel 5.15), with consistent speeds around 800-900Mbps. The AP is an ASUS RT-AX86U.
Also somewhat surprisingly, while Intel AX200/201 is faster as it supports 160MHz (I had it before), the MT7961 has been more stable for me, both speed-wise and bug-wise, so far anyway. But YMMV.
> Luckily it's only M.2 so you can replace it with something like the AX201
I believe X13 Gen 2 has soldered WiFi, not M.2.
Though with a quick glance at current local computer retailer catalogs I found only HP 290 G3, which is not a laptop (https://www8.hp.com/h20195/v2/GetPDF.aspx/c06636833.pdf). Found plenty of discontinued laptops (e.g. HP ProBook 430 G6: https://support.hp.com/lv-en/document/c06179691), though, so maybe it is just not as common anymore. I vaguely remember seeing FreeDOS laptops much more often 5-10 years ago.
Most of those trigger a specific Android permission popup at runtime to grant access when actually needed/used. The app doesn't them just by the user installing it.
That's not true. Commingled inventory is stored in separate bins so that the original source of the unit can always be determined.
This is explicitly said on the Amazon seller help pages for commingling ( https://sellercentral.amazon.com/help/hub/reference/20014148... , https://sellercentral-europe.amazon.com/help/hub/reference/G... )
There is also this Financial Times article from 2019: https://archive.md/kfABj - quote from Amazon spokesman:
> The system is purposefully designed so that similar products are not placed next to or near each other, and Amazon can also track the original seller of each unit.
I guess the confusion came from the name "commingled inventory" - Amazon seems to have recognized this recently and is now referencing this feature as "virtual tracking" instead (quote from the above help pages):
> Commingling is a term that was sometimes used to refer to virtual tracking. However, virtual tracking is a more accurate term, because we trace the source of eligible products throughout the fulfillment process. Identical items from different suppliers are not stored together.
But that seems weird to me - just show the more relevant languages first, then, so they don't need too many button presses.
(and you can of course unlist yourself)
I'm somewhat interested, did it go down differently in e.g. U.S., i.e. are directory services gone, too?
But nowadays you can configure additional visible languages yourself on the language settings page (checkboxes under "Programmes & Films Languages") without changing the UI language: https://www.netflix.com/LanguagePreferences
Moving all that header code around between files will conflict with all other code merges that touch those same lines.
However, glibc documentation (https://www.gnu.org/software/libc/manual/html_node/Feature-T...) says:
> If _TIME_BITS is undefined, the bit size of time_t is architecture dependent. Currently it defaults to 64 bits on most architectures. Although it defaults to 32 bits on some traditional architectures (i686, ARM), this is planned to change and applications should not rely on this.
So it sounds like glibc plans to change the default, just like musl has done.
You can still run Linux programs linked against decades-old versions of glibc on current systems as they have kept ABI compatibility with the use of symbol versioning, without changing their SONAME ("libc.so.6").
Sure, that does not extend to being able running programs linked against new glibc symbols on old systems, but if you consider that ABI-breaking then the Linux kernel would also be ABI-breaking as you cannot run binaries relying on new kernel syscalls (etc) on older Linux kernels.
> Currently it defaults to 64 bits on most architectures. Although it defaults to 32 bits on some traditional architectures (i686, ARM), this is planned to change and applications should not rely on this.
Note that due to the fixed-price nature of the original supply contract, the total cost of the plant was "only" €5.7B ($6.4B) to the owner/operator (TVO).
The $10B-$11B is the estimated cost to the plant supplier (Areva NP/Framatome), i.e. they made a huge loss.
Finnish source of numbers: https://www.kauppalehti.fi/uutiset/olkiluoto-3-alkaa-tuottaa... (paywall)
But Amazon wants a statement with a billing address and the card number.
That's one reason I only use my credit card on Amazon - it has such a statement available in case I ever need one, while most of my other cards do not.
I know there are claims that EU is on the verge of banning E2E, but they seem to be, AFAICS, exaggerated or unfounded.
They didn't say that banks cannot charge for SCT Instant.
They said that banks can't charge more for international than they do for domestic.
Yes, the accounts in my bank (in Finland) default to SEPA Direct Debit off.
For recurring utility payments etc. we instead use Finvoice e-invoicing (https://www.finanssiala.fi/en/topics/finvoice-standard/). The customer enables e-invoices on a per-issuer basis directly from their bank web interface, with an option for auto-pay and payment limits. The payments are processed as regular SEPA payments. The e-invoice goes directly to customer's bank, replacing paper/e-mail invoices.
For paying one-time online purchases the user is redirected to their bank to authorize a one-time SEPA transfer (other non-SEPA payment methods like cards and MobilePay are common, too).
But I very much doubt actual such legislation will get enacted. There is not even an actual proposal yet, only articles like this saying one is coming soon.
We do know CSAM screening legislation is coming as the current voluntary rules have a 3-year time limit - but it is, in my opinion, very unlikely there will be mandatory screening, despite some people reportedly pushing for it.
There is no such proposal as of yet.
In my opinion, the last regulation applied in July 2021 was sound (final text: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A...), allowing a 3-year extension to the existing practice of voluntary screening until a proper legislation can be finalized.
Some would have wanted to completely disallow voluntary screening (which would have been the case had the regulation not been adopted, due to privacy law changes in Dec 2020), too, and I can understand that position. But that is seemingly not shared by European Parliament who voted to allow voluntary screening to continue (they did shorten the time period to 3 years from the original 5, though, by an amendment).
In my opinion it is not a fiasco at all. It simply allows the current pre-Dec-2020 practice of voluntary screening to continue for a limited period of 3 years (so they have time to get a proper permanent legislation in place). Privacy rules changed in Dec-2020 that made voluntary screening effectively illegal, hence the stopgap.