Linux

14780 readers

308 users here now

A community for everything relating to the GNU/Linux operating system (except the memes!)

Also, check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 3 years ago

MODERATORS

Ategon@programming.dev

anzo@programming.dev

dwraf_of_ignorance@programming.dev

Best laptop hardware? (programming.dev)

submitted 1 day ago by Moussx@programming.dev to c/linux@programming.dev

18 comments fedilink hide all child comments

Hello! For work (where I'm compiling a big Rust monorepo in a loop), I'm on a Thinkpad T14 Gen 4 and it's getting a bit annoying.

My only constraint is that I'd like a 13-14 inch device

The AI memory situation is probably to blame, but after sending a LLM fetch specs and GeekBench results, it seems that for sustained multicore performance, the only thing that comes close (within 10% but still lower) of a M5 MacBook Pro (currently ~3200 EUR), is the HP Elite G1a (ARM linux is OK), but its list price is much higher (up to 4900 EUR for 64G memory and 1TB disk) for arguably worse speakers and battery on top.

So right now it's hard to justify not getting a MacBook and that makes me sad...

Is there a laptop you're using right now that comes close enough to a MBP in long compilation jobs, but runs Linux and doesn't somehow cost more ?

you are viewing a single comment's thread
view the rest of the comments

[–] racketlauncher831@lemmy.ml 2 points 1 day ago (1 children)

What was really the problem? If you compile it the first time, the second time it only compiles the files you've changed. No matter how big your monorepo is, as long as it compiles overnight, there shouldn't be any impact to the speed of work.

[–] Moussx@programming.dev 1 points 1 day ago (1 children)

So there's this fun thing in rust where if you don't have exactly the same feature set for all components of the workspace when you go to a subfolder for a component you can invalidate cached artifacts and trigger a lot of jobs. Same thing when you check out a branch then compile. And as I have a fair volume of crates in the workspace, changing mtime on the files for a checkout means I still have 5~10 minutes each time I want to run tests locally (a fresh run takes ~30 minutes to ~45}

[–] ExperimentalGuy@programming.dev 1 points 22 hours ago

I've never worked with a rust codebase that big. I've never had to deal with issues like that but damn, 10 minutes to run a test is crazy.