Hear that, Intel? I will put money where my mouth is. I am not sure I can afford any of these RISC-V chips and they are still alpha quality beyond the Talos, but those of my ilk will do their damndest to make you pay for tone deaf reaction.

You are still buying Intel, so not sure how they will care...

So IF they had a Power0 chip it wouldn't be Intel. Though I have zero idea how System76 would put Power9 into a workstation laptop but they do put a desktop cpu into their Serval lineup. https://system76.com/laptops/serval

My system was delivered with a BIOS issue that made it only boot perhaps 1 out of 30 cycles. Delivered on a Thursday night, after spending a lot of time troubleshooting, I had to wait until their support got in on Monday to get anything done. Then I had to mail it in and wait a long time to get it returned with a reflashed BIOS (I'd be lying if I said I remember exactly how long, just remember it feeling way too long).

I explained that I had bought the laptop specifically for on-site work with a client and that I needed a functioning fix or replacement ASAP. They told me they couldn't make anything happen any faster, and even told me that they had no way for me to pay out of my own pocket for faster return shipping, though IMO they should've offered to do this themselves.

I did eventually get back a mostly-working system which I still use around the house, though it's had a habit of hard-locking when the GPU is under stress the whole time I've had it. But my experience with Sys76 customer support is the biggest factor in deciding not to buy from them again.

Do bear in mind this was several years ago and that it is reported from memory. It is entirely possible they've gotten their act together and/or that I'm misremembering some details, but this was my experience as I recall it.

so much honesty is such a pleasure to read !

Good tools cost more, and are worth it.

Your product just went to the top of my shopping list.

I won't, if it means having to run Ubuntu (and derivatives) or Pop. I'd like to run the distro of my choosing, thanks, but no thanks. It will be possible to disable ME on other laptops/desktops as well.

> You must run Ubuntu 16.04 LTS, Ubuntu 17.04, Ubuntu 17.10, Pop!_OS 17.10, or an Ubuntu derivative and have the System76 driver installed to receive the latest firmware and disabled ME on laptops

Maybe it will run fine on Fedora, but if it bricks your laptop, they don't want to get blamed.

I don't see why you can't attempt to do it manually yourself, without the aid of their driver and firmware update tool. Except that you might forfeit any warranties/support.

System76, can you clarify?

Sadly it's standard to only see official support for Ubuntu or RHEL in the Linux world. Not that I don't understand, it's all very fragmented, and that creates a lot of work as to support multiple distros. People are working on remedies, though.

*I don't have a System76 laptop

EDIT: Crap, pre-order.

https://www.raptorcs.com/content/TL2WK2/intro.html

I have been skimming too light on the market details for that bad boy. Only proves the point that the high-cost might be the price of helping proprietary hardware feel the sting of changing cultural tides.

@jackpot51 system76 folks -

Are your systems currently using opensource boot bios? If not, any plan to do so in near future?

We may be experimenting with coreboot more in the near future

I used to work on embedded systems where I have full control of uboot. With that, I can easily reserve the section of memory in boot uboot and Linux kernel when the keys logging info (such as FTRACE of ISR, sched switches etc) from kernel are kept.

When a kernel panic happens, the system will go thru the warmboot sequence and detected there are logging info in that section of DDR and dump it out before continue to boot.

This "postmortem debugging features" make debugging certain category of very difficult bugs (kernel driver panic) much easier.

With typical close source x86 bios in Linux laptop, it is very hard to enable this kind of debugging.

I've written this elsewhere, but I'll repeat: it seems a shame that folks like System76, Purism, aspiring Kickstarter campaigns et al aren't leveraging the supply chain already in place for Chromebooks. In the case of Purism, for example, x86-64 Chromebooks comparable to Purism's low end models can be had from Dell for 3/4 the asking price of the former. Considering that the driver situation is necessarily a solved problem for Chromebooks, and they're already using coreboot, it seems silly to start a parallel effort to deal in hardware the way System76 and Purism are doing, rather than just approaching Dell about a white label deal to supply you with hardware components that are already known to work.

The business model of system76 was what I was personally looking for and I've been very happy with my latest laptop from them. For me personally, the luster would have been lost coming from Dell.

Alienware was bought by Dell not that they outsourced their hardware.

A white-label, more configurable, plain ubuntu version of the pixelbook sounds like a dream.

Dell makes Chromebooks. These Chromebooks run coreboot. Ergo, Dell makes laptops that run coreboot.

There's nothing in my comment about building off the back of Dell's existing program to sell Ubuntu machines to customers—a program whose success story is reported to be bizarrely hit-or-miss with respect to driver issues, even.

Dell's Chromebooks are a success. They're shipped in large quantities. They have no driver issues. They run coreboot. So my advice is simple: if you're a company trying to sell to folks who want a "Linux laptop", then stop sourcing components/machines from otherwise clueless Wintel vendors and trying to shoehorn a traditional distro onto that. Start with the BOM used in Chromebooks. Approach Dell and say you'd like to place a large order—because that's the business they're in, by the way. Now build your company's products on that platform instead.

Substitute "Dell" there with any other competent vendor that has demonstrated their hardware plays well with the FOSS stack powering ChromeOS .

> Partnering with Google for the chromebook supplychain seems like the better theory/plan.

No, that's an ignorant theory. Google is not known for hardware, and certainly not as a supplier for commodity hardware. Even ignoring all that, the response you should expect from Google in regards to playing along should not be enthusiastic agreement.

There is a demand for this, and almost no one is doing this. The only other company that has done it so far is Lenovo, and if you know anything about privacy and hidden adware and history of spyware - you will not buy any Lenovo product.

ECC memory would require a Xeon, but it would be possible to underclock it to bring it to a mobile heat emission profile.

If I balls to the wall it I can kill the battery in 90 minutes (though they are swappable) but I average ~6 hours under actual work conditions (VMs and Intelligent).

It spends the vast majority of time sat at a few percent utilisation but the processing power is there for those few second operations you run infrequently (build from scratch, indexing a large project etc).

I love it frankly, not turned desktop on at home more than once or twice since July.

- Release ME source code

- Remove ME from consumer products

- Have a provable method of disabling the ME entirely

Intel can just give the source, but you can't trust Intel to just give you the same compiler they used, because the compiler might insert a backdoor. You'd need the compiler source, audit it for backdoors, then compile that with a trustworthy compiler. Then use the resulting compiler to compile the ME source.

(Compiler compiler compiler)

Of course that only helps if you trust the toolchain.

(Reflections on Trusting Trust)

Thanks, I really enjoyed reading it!

It is possible (though somewhat time-intensive) to audit binaries, too. If there is real demand for this, it should be possible to crowdscale the auditing problem over a large group of OSS enthusiasts.

I am wondering. Have you considered using the [Linux Vendor Firmware Service](https://fwupd.org/) ?

Source: Am the LVFS and fwupd maintainer.

Still, I have been changing our firmware updater to better suit LVFS and fwupd for when you finally decide to reconnect in a more positive way.

Not trying to tone police you, but you run a project that necessitates bringing vendors to the table. Odd to publicly bash one that's trying to work with you.

It's possible that at some point (depending on if it gets open sourced) I'll be grabbing some of your work and trying to wrangle it to work on my desktop. Is this an area where I seriously risk bricking my CPU, or are there safeguards that cause these kinds of instructions to either work or safely fail?

If you have BootGuard, you will brick your machine, unless you have the manufacturer signing key. We have the signing key for our laptops, so we are able to sign updates for the four systems with BootGuard: galp2, galp3, lemu7, and lemu8.

As far as I'm aware, there's no particular state involved for you to brick the CPU, but you can easily write a firmware which will prevent boot, or fail some time after boot (In the case of removing critical ME blobs). You could brick your board temporarily, but you're going to be using an external flasher (with a convenient little SOIC clip :- ) anyway, so fixing it is a matter of writing back the old/working image.

This is, of course, assuming you are able to write anything that works to the flash, which you might not be able to thanks to BootGuard.

I'm aware that you're working on a distro-agnostic tool. In the interim period, however, if someone with a System76 laptop wants to use Fedora while still disabling ME, can they simply load stock Ubuntu/pop_OS long enough to install the driver and disable ME and then wipe the drive and reload their OS of choice?

Would it also be possible to support consumer-controlled signing keys, placing control of the system in whose hands they belong?

Signing keys are fused into the CPU for boot guard when the CPU is attached to the motherboard during production, for soldered CPUs like the U and H class. Having a customer signing key would seriously complicate BIOS updates, as only one key can be utilized, meaning our firmware updates would not work.

It would also make returns much more difficult, as all CPUs with customer keys would have to be replaced.

Right now, boot guard is only used on the Galago and Lemur.

Yes, I expect as a general solution for your customers it might be overkill, but as this is basically the cutting edge of public domain research on these topics it would nice to know what's possible for customers who would take the risks.

Understood, I have more reading to do in to how the EFI shim/flasher works.

Awesome, I finally get to see the punchline. ;)

(It's never going to happen, I know. But a fellow can dream!)

The other thing I can't give up from my Lenovo is having two batteries in the machine (it has a 4 cell 32WH and 6 cell 72WH)

Side note: PopOS wasn't ready for release. I had lots of problems getting the initial account created and on corporate wifi (PEAP).

For example, there may be two drugs that can treat my illness; taking both might not be better than taking one or the other.

I've been considering system76 for awhile. I see Dell also offers Linux laptops now and has for awhile. Any reason why I should pick system76?

Would be a good place to start, as far as not supporting dell goes. Linux is also a first class citizen w/ system76 - Dell has the factory linux xps13 e.g. but I've heard from a handful of friends who use one at work that its obvious Linux was just kinda slapped onto the laptop at the end of manufacturing or whatever. Support is also probably much better with System76.

For my particular case, the Dell has superior hardware (also, it's about a year newer), but its Ubuntu install has strange problems, and I get crash notification popups somewhat often (including immediately upon logging in for the very first time). The Kudu's install has been rock solid.

System76 has far superior support.

is Redox partially sponsored by System76 via allotting time for you to work on it?

For example, the graphics library orbclient was used in the firmware updater, and the UEFI library from the firmware updater may be used for a Redox UEFI bootloader.

It feels NIH and is exactly why I'll be buying Dell and never System76. I can one-click flash my Dell forward without configuring or installing anything.

For that matter why is there a "HiDPI Service" running? Why is the driver a set of udev rules that could've been upstreamed?