https://ssd.borecraft.com/SSD_Buying_Guide.pdf

For 11th gen:

https://web.archive.org/web/20230716062901/https://old.reddit.com/r/framework/comments/11dtm78/guide_for_setting_up_egpu_with_framework_11th_gen/

As a side note about BIOS

Framework’s official stance on Coreboot:

“As this keeps popping up even after multiple responses, let this be the “official” response so we can put this to bed, at least for now.

It is not that Framework “does not care” about Coreboot, it is that we have a very long list of priorities for a very small team (we are less than 50 globally and have existed for less than 3 years) and while being able to support Coreboot would be fantastic, it is just not a priority for Framework right now given the sheer number of initiatives that we have to launch now and in the immediate future. We pivot from one NPI (New Product Introduction) to the next, back to back, and have since our first product launch. Our firmware/BIOS team is small and is supplemented by an outside 3rd Party partner. The consistent, “well, just hire more people then” is unfortunate as those in the know understand that’s not how it works, especially for a small, private company trying to exist in a very mature market segment. While tech in general is shrinking, layoffs are in the news constantly, and global economies are getting hit hard, we’re still here, releasing new products, and working hard to support everything we’ve already launched.

If and when we decide to add Coreboot to the docket of active projects, we’ll let the Community know, but if you want Framework to continue to exist, and you believe in our mission, we’ll have to continue to ask for your patience. If not having Coreboot is a blocker for you, personally, to join the Framework Family, we do hope that we can earn your business in the future.”

https://community.frame.work/t/responded-coreboot-on-the-framework-laptop/791/239

the 7640u and 7840u are both rated for a default TDP of 28w, although it is configurable as low as 15w by the laptop manufacturer.

That reference seems to be using the default for the 7840u, whereas they’re using the configurable minimum for the 7640u, which is misleading.

The 7840u and 7640u are actually the exact same chip, just the 7640u has 2 CPU cores and 4 GPU cores disabled.

Ryzen is pretty good at putting cores to sleep when they aren’t needed, so when at idle or running a load that can’t take advantage of those cores the 7840u should behave pretty much the same as a 7640u and have similar power consumption.

Then when under heavy loads both CPUs will likely hit whatever the maximum power the cooler can handle is, however having more cores each running at lower power (ex. 7840u) generally performs better than fewer cores each running at higher power (ex. 7640u).

So under heavy loads the 7840u should actually have better performance with similar power consumption, however the better performance allows it to complete the task quicker and get back to low power idle sooner, overall improving battery life.

So theoretically the 7840u should overall have similar to slightly better battery life than the 7640u assuming all software is implemented properly (I was an early adopter of Ryzen 3000 desktop CPUs and it took several driver/BIOS updates before it would reliably put unneeded cores to sleep and significantly reduce idle/low load power consumption).

++

credit: u/RiftBladeMC on Reddit and @RiftBlade@lemmy.world on Lemmy.

original link: https://old.reddit.com/r/framework/comments/13dz5nb/comment/jjnv1nq/?utm_source=share&utm_medium=web2x&context=3

With the workloads you listed the only place that you may have a noticeable difference is in gaming. But if the games you play are not very intensive then you will only see a negligible improvement

For that use case, the Ryzen 5 seems perfectly suitable. It’s what I pre-ordered myself, with a similar expected workload.

This is data on a previous generation Ryzen 5: https://pc-builds.com/fps-calculator/result/1fB1dg/4T/dragon-age-inquisition/ This might be helpful too: https://www.youtube.com/watch?v=ykRYYl6xSpo

++

credit: u/runed_golem on Reddit

original link: https://old.reddit.com/r/framework/comments/13dz5nb/comment/jjnow91/?utm_source=share&utm_medium=web2x&context=3

thanks

The Windows system partition contains everything that you see when you open your C: drive in Windows Explorer: Windows system files, documents, user accounts, etc.

When you encrypt the system partition, all those files get encrypted with whichever algorithm you choose.

Anyone who gets a hold of your computer will be completely unable to access anything on the C: drive because it’s all been encrypted.

HOWEVER, they would be able to access it if your computer gets stolen while it’s powered on or in sleep mode (if it’s a laptop)

So if you’re really paranoid, you should always shut down your system when you’re in a situation where it could possibly get stolen.

No. That’s the whole point. If you only have one disk (or volume), both the operating system and your documents are on it. Therefore, encrypting it means no one can use your computer unless he has the Vera Crypt password.

The “store now, decrypt later” is an issue with public key cryptography- which is most internet traffic. Symmetric encryption isn’t really messed up by quantum computing even in theory- your 256 bit thing might become effectively a 128 bit thing, but that’s still incredibly impossible to worry about (there’s some general purpose algorithm that requires a quantum computer that would generally halve the key size I think).

What is likely threatened by quantum computing are public key algorithms that work on the idea of one way being easy, and another way being hard. Like factoring- multiplication of huge numbers is fast, factoring them is not. Shor’s algorithm is the famous one to be able to do this fast enough given a good quantum computer. But a lot of these allegedly one-way functions would be varying degrees of screwed up in the so-called ‘post-quantum world’.

In a normal SSL connection, you use public key cryptography to exchange a symmetric key, then you use that. So if you were to record an entire SSL connection and then in the future be given a big quantum computer, you could in theory work it all out- first by undoing the public key initial piece, and then by reading the symmetric key directly, at which point you would be able to decrypt the remainder normally.

From my understanding, standard notes wouldn’t actually be subject to this, as it never transmits your actual key- you encrypt it with your real key locally, and then it gets sent as TLS stuff. So while the public key could be discovered, and the private key for the TLS session, the actual payload data would be encrypted with a key derived from your password that is never transmitted.

Now, if it does actually transmit that key at some point, then all bets are off. But it couldn’t really be secure if it transmitted your key anyway right? So it probably doesn’t do that.