tpearson-raptor

Nothing formal, but if the service itself does go down (i.e. your VPS drops and can't be restarted due to a service problem, or connectivity fails, etc.) refunds / service credits would be issued. We really haven't encountered this enough to have a formal policy as of yet -- the redundancies we use are quite good.

Timothy Pearson from Raptor here...so if storage becomes a main concern it definitely becomes less expensive to lease a dedicated box vs. a VPS from Integricloud, and that's by design to some extent. The Integricloud architecture is centered more on making sure that your data stays private than competing directly with Amazon etc. that simply don't have the ability to make any assurances beyond general platitudes in that area (for starters, they don't control the firmware on their own machines), and the design (and pricing) reflect this different approach to cloud services.

The dedicated boxes are also unlimited data transfer, and you can put in some fairly large storage arrays inexpensively. We have a bunch of projects that are using dedicated boxes for development work, for example we sponsor Adelie Linux with one, and so far they've been very happy with the service.

Anyone wanting control of a powerful modern computer is part of the target market. We just haven't been able to drive the price down further at this time -- doing hardware design around fully open source firmware is hard and a lot of the typical shortcuts to lower costs (including the always-concerning "post-sale monetization" concepts) simply aren't something we find acceptable on any level.

Basically, it doesn't do anyone any good for us to lower cost by giving up the full owner control experience that is centric to our product lines. :)

Keep an eye out for an EU distributor of ours -- probably sometime late this month / early next if all goes well...

I wouldn't be surprised -- it's a gaping hole for anticheat software if not addressed. In fact, long term the anticheat is going to have to require a completely locked-down (console-like) experience from boot firmware (ME/PSP attested) through OS and userspace, or it will not be effective.

Which is one reason why I don't rent games on Steam, and why I bought a PS4 instead. If I'm going to have to game on a completely locked down system, I vastly prefer to do it on a system that doesn't touch any of my personal data and for which I can still buy permanent, resalable (and yes, even lendable) games on physical media.

PC gaming hasn't interested me since Steam on Windows with mandatory anticheat became the primary way to play games.

> Provide a path to a $1300 laptop that is POWER based (and not crippled "slow 1 core SMT1" stuff from IBM's dead-bin) and you might entice System76 and Purism.

I just gave them a path to a desktop that is POWER based, with very low up front costs (basically take their existing Thelio chassis, swap mainboards from x86 to POWER, do some software builds of Pop!_OS, and do a trial launch). I think that's a far more reasonable initial trial than going for a full laptop. It's also relatively consumer friendly, especially in today's cloud era where the proprietary apps people are using might just well be behind a web browser in the first place.

If they were a laptop-only company I'd agree with your assessment (I'm not happy with the GPU situation at all, that's the primary blocker for a libre laptop), but they're a laptop and desktop company. That means there's more ways they can test market owner controlled systems than a full up laptop design with massive design + tooling costs for an uncertain return.

I wouldn't be here if I didn't see a bunch of headlines yesterday that made it sound like these new laptops have proper open firmware.

They don't. That's why I'm here, to provide the missing other half of the story.

The general answer is yes and yes. That's why OMI / OpenCAPI are being released as standards, with RTL / HDL. I think at this point there would be more appetite for a next gen interface like DDR5 vs. DDR4 to be released, but I'm just speaking personally from general knowledge here.

Microwatt is the first fully open POWER core:

https://github.com/antonblanchard/microwatt

It's also structured very well, quite clean for learning purposes etc. The current goal so far as I know is to perfect this core, and fork for a more complex / powerful variant. Maybe by the time that's done, the open FPGA tooling will have caught up enough to be able to run a usefully fast (~200MHz) POWER soft core, all in FPGA logic...

I'd strongly prefer a ppc64 core over a RISC-V core for one simple reason: we have a wide deployed base of very powerful ppc64 machines, and not having to keep cross compilers and related environments around is a massive streamlining step that we don't even know the full effects of yet (it hasn't been legal until now to have the SoC under development running the same architecture as the high end workstations and servers used to develop [for] it). The demo of using mainline GCC on a POWER box to build a binary for the Microwatt (that would also run on the host with KVM, if desired, for fast trace and debug) was most impressive.

OK, I think I may have been misunderstood...

What they are doing in that space is valuable. However, with just a bit more tweaking, they could offer something a whole lot more valuable in parallel, and leave this whole semi-open x86 issue behind. If they were to offer even a couple of actually open source firmware systems, and indicate somewhere in the marketing that the x86 boxes are only partly open source, that would not only eliminate the entire controversy here but also allow them to take the next logical step in open software. If their core mission has basically been to make open source easy to consume, that's a worthy goal; why not go a bit further and make open source on open hardware with fully open firmware just as easy to consume?

Clearly there's demand, from the comments in this thread alone!

You might be ascribing quite a bit more leverage to System76 than they actually have here. No one is going to get Intel or AMD to allow open PSP/ME firmware -- AIUI even Google, with the truckloads of chips they buy, isn't able to influence that decision at either x86 vendor. Plus, System76 isn't the ODM -- that's Clevo from what I understand, so their influence on the two x86 CPU vendor(s) will be so far removed as to be quite insignificant IME.

Now, offering something else (ARM, RISC-V, POWER, anything but x86) as a truly open source alternative, then seeing if there was any reaction, might start to apply some small degree of leverage. Definitely there would be more potential opportunities to meaningfully discuss design goals with silicon vendors other than Intel and AMD. Who knows, maybe this could still happen...it'd be pretty easy / cheap to get some POWER desktop offerings lined up based on existing mainboards, and Clevo might be persuaded to do an ARM laptop design based on one of the Chromebook SoCs... ;)

With our baseline blob-free systems, we picked parts that were firmware-free, had open firmware, or could have open firmware written in the future. This is why we don't have onboard 100Gbe, Thunderbolt, or other interfaces that would require relinquishing control of the system to an external vendor. However, the resulting products are quite functional as both PCs and servers, with no real complaints or concerns over the I/O given the multiple PCIe Gen 4 slots available. My understanding is that very few ODMs do this, as they don't want to make that tradeoff, but this is how you apply leverage to silicon vendors long term. And you know what? It's working (outside the GPU sphere at least) -- Raptor isn't the only one pushing hard on these topics from the OpenPOWER side, and so far we've been able to get the silicon we need for our current product lines.

Actually, yes! We're closely monitoring the development progress of the open toolchains for various FPGAs; with POWER ISA now being open for implementation by anyone anywhere, I could easily see a future where extremely sensitive work is seamlessly moved from a large closed ASIC like the current IBM POWER chips to a completely software compatible, but significantly slower, soft SoC running in an FPGA. Or even an ASIC, if methods are eventually developed to verify the ASICs match the input design files at scale (i.e. non-destructive testing).

This seamless transition is one of the key benefits of an open ISA in my mind; development and testing of algorithms can be handled on the closed but top of the line (i.e. extremely powerful) ASIC, then when sensitive data is being handled that same binary can literally be run without changes on the soft core or other slower, but open, system. You could even compile on the slower ultra-trusted system, and test the binary on the larger ASIC -- lots of interesting possibilities here!

Yep, I figured as much. We'd love to do a laptop, we're literally just stalled on the GPU. This is where a consortium of ODMs and OEMs could possibly effect change, the combined buying power is probably enough to get custom GPU silicon sans-DRM and locking created. Only question is, does enough willpower exist from the other ostensibly open vendors at this time to actually work toward that goal with us? ;)

That may be. However, I was using Linux on bog-standard computers before System76 was even founded -- preinstalling Linux on a computer isn't exactly revolutionary, and it's in a completely different league from the work that has been required to bring up entire new CPUs (!) to compete with the increasingly locked x86 systems.

No idea where you're getting a kilowatt from. My desktop uses maybe 120W or so, with a lot of that going to the AMD GPU.

If we're going to trade barbs over ecological damage, what happens to all those Intel and AMD systems that would have been useable if they had just had updates to the locked/signed firmware, but are instead floating around in landfills because the vendor decided they wanted to enforce their control and not issue security updates?

I still don't understand why you would even care about the firmware if you're running Windows. To me, that would be like building a fortified, ultra-secure rear doorway into a run down barn with a gaping hole where the front doors used to be.

If these efforts were even potentially likely to result in open x86 systems someday, I wouldn't be as opposed to them as I am now. But when you have both x86 silicon vendors on record as being contractually and legally unable, let alone unwilling, to allow owner control, all I see is a massive waste of effort with a known incomplete (i.e. partly closed) endgame. Worse, that effort is detracting from other efforts that are providing fully open computing right now, today.

My recommendation has always been to use the commodity x86 world's greatest advantage if you have to use Windows: cost. Get the absolute cheapest possible Windows system you can find that still has enough power to support your clients, plan on replacing it every so often as Windows churns along, and actually invest in a secure, open computer for everything else.

x86 is a closed ISA with closed, locked, signed firmware. All appearances are that it will stay that way permanently, with just enough late-stage open firmware allowed to create sufficient marketing confusion in less technical circles. Why not select and embrace one of the open ISAs for non-Windows computing? Who knows, you might be helping make secure / non-hostile computing happen on a large scale just a little bit faster! :)

Watch out for the LX2160A -- if you intend to use certain items, like any of the onboard high speed networking, you have to load blobs. This was one reason we decided (after careful consideration, which included bringing a box up and working with the firmware for a while in parallel with the POWER efforts) not to use LSI or ARM CPUs in our systems.

Your requirements probably aren't too far off of one of our Blackbird systems -- I suspect it's just the form factor (micro-ATX) that's the problem. You might even be able to do the pull plug for minutes trick with a suitably sized lithium battery tucked inside the slimline chassis. ;)

Which, it should be noted, is impossible due to Intel's hardware-enforced signature checks.

Even if a key were to be stolen from Intel it would then be illegal to use in all Western nations. The ME is off limits to everyone other than Intel and its partners, enforced by both the hardware signatures and some of the most heavily enforced (in terms of consequences) legislation on the face of the planet.

Of course that won't stop malware authors, who couldn't care less about replacing the ME firmware to make it secure, but do care very much about the fact that they can hack into the stock, signed Intel ME firmware, then install their malware in a nearly impossible to detect position.

It was that strongly worded because I've been fighting the "neutralized" rumor ever since it was started (presumably to try to save x86 market share among security conscious people, given its origin). I'm tired of doing so, and it's unfortunately showing, which means I'll probably have to stop talking about it. That's a loss for everyone, especially those who might unknowingly trust their lives to a hostile machine in certain repressive regimes and pay the ultimate price as a result.

This "neutralized" or "disabled" ME rumor is extremely persistent over literally years, probably due to feeding on what people want to hear versus what the reality of the situation is. Every time it's propagated not only does the person that believes it not get what they think they got, but it harms anyone trying to push for truly open computing vs. half-open computing.

The Cambridge English Dictionary states the following primary definition for the word "neutralize":

"1. to stop something from having an effect"

If you were to actually do that to the ME on a modern Intel system (or the PSP on a modern AMD system), here's what you would see:

<blank screen>

This is because the system will not come out of reset until at least the BUP (and for newer systems more ME modules as well) have started. Those modules are signed, proprietary binaries for which source code will never be released per Intel's statements.

So, we have an apparent conflict. How can the ME be "neutralized", according to the standard English definition, while your machine still starts (thereby proving the ME has had at least some required effect prior to coreboot launching)?

That depends heavily on where you're transmitting (i.e what frequency and bandwidth you use) along with the power you're transmitting at.

First, as a ham radio operator, no, you can't just go and start blasting away from an SDR even in the ham bands. You have to follow strict rules, including a non-commercial content rule and you must not use encryption. The ham bands are for people to experiment with new radio technologies and more importantly communicate with one another using those technologies on a hobbyist level -- encryption and commercial use does not help those goals.

That being said, there are chunks of radio spectrum that are effectively "public domain" where you can transmit within certain ERP (effective radiated power) limits without the ham band restrictions on content, protocol, etc. Traditional WiFi lives in one -- the block set aside for microwave cooking devices, and therefore with a near-unusable noise floor for anything but short range communication like household WiFi.

I hadn't, thanks for the link! It's an interesting possibility for a terminal device, though I'd prefer something open ISA -- if that was either POWER or RISC-V vs. ARM, I'd probably pick one up...

OK, that makes sense. And yes, it causes problems for coreboot -- AIUI there are no modern AMD systems supported, because AMD has not allowed use of the AGESA blob in that way.

To the downvoters: I'm guessing you wanted to run Windows 10 "safely" somehow, or sandbox your games. There's almost no other reason to be this stuck on x86; at the end of the day it's just a consumer architecture that some well known privacy disrespecting software requires to run. It's not even that great of an architecture from a technical perspective, it just happens to have the financial weight of the prosumer market behind it right now.

Here's reality:

This laptop won't stop Windows exfiltrating your data. These x86 systems are leaky, they require sizeable amounts of low level binary firmware to even boot, and proper isolation is near impossible. Try sticking a PCIe diagnostic system on an open PCIe slot and sending commands to the WiFi or Ethernet card -- most likely it'll respond [1]. Then consider the firmware in the various controllers attached to the PCIe bus, including your GPU.

It's probably a violation of your game's anticheat system to try to sandbox it. It's definitely a violation of the NVIDIA driver EULA to run it in a virtual machine, unless you pay the enterprise driver license fees and use a server grade adapter. The kind of adapter you won't usually find in a laptop, by the way.

This is a topic that I find very frustrating. We all know you want to do the above. It can't be done without license violations all over the place, or head-in-sand make-believe "security", on modern x86 hardware. No wishing, hoping, etc. will make this change.

[1] Yes, this is known to happen on specific x86 systems that I have personally tried (in that case, it was a malfunctioning GPU writing to the disk controller!). Invalid cross-device access was also tried on a POWER box, where the invalid accesses were blocked and logged as intended.

The ancient AGESA open sourced well over a decade ago, then closed down a few years later right about when the PSP started to appear on AMD platforms?

Or do you mean the modern AGESA binary that has zero support whatsoever in coreboot right now?

IANAL, but this is what I've been told:

Both. Copyright applies to some aspects, patents to others, and then you also get into trademark rights. With the US having embraced effectively permanent copyright, ISAs will not be freely able to be implemented unless their owner expressly allows it (my understanding is that the Oracle vs. Google case solidified this thinking).

Fundamentally, that means you get to pick from RISC-V, POWER, or SPARC when selecting a well known ISA for your new device, or start signing licensing agreements (which always come with restrictions and oftentimes significant royalties).

Honest question: why do you consider System76 to be building new roads by using locked hardware and offering partial open source firmware for it? Wouldn't the new roads kudos be more appropriately given to all of the folks that made real open hardware happen (RISC-V, OpenPOWER, etc.) years before this partly-open-source system announcement went out?

In my mind the RISC-V folks especially were real trailblazers in this space -- they took massive risks when no one, and I mean no one, was doing open source CPUs beyond soft cores. IBM focused more on open firmware, then eventually opened their ISA, but x86 vendors have had no such forward vision in their history -- the x86 vendors have followed in this space, not led, for well over a decade, and indeed both sides of the x86 duopoly (Intel and AMD) are both separately on record as having stated their goal is to take control away from the machine owner in whatever manner they need to in order to fulfill their DRM contracts.

Even with this laptop announcement, if I'm honest, more following is being demonstrated -- the coreboot user community had open source firmware ARM laptops (Chromebooks) available quite a long time ago, why weren't those hailed as building new roads when they appeared? Does anyone really think we would have reached a point where an x86 vendor would be trying to advertise even partly open source firmware without the pioneering efforts of the competing, truly open architectures?

Here's POWER's training code for DDR4:

https://git.raptorcs.com/git/talos-hostboot/tree/src/import/...

pgeorgi has a valid point in that if you go for the cheapest off the shelf building block type DDR4 solution for your silicon design (won't name names here, but it's a widely known vendor in the silicon block space), those controllers come with mandated binary-only firmware. IBM (and apparently Marvell?) both didn't use that cheap off the shelf solution and also decided to release their training code. Kudos to both companies for bucking the trend here!

I was being snarky in this particular post. Normally I don't do that, but I kinda got tired of saying the same thing over and over and tried something new. Didn't mean to offend, only challenge.

I run Debian Buster.

My best recommendation might be a bit odd, but here goes...

Can you put a POWER "base station" of sorts in your dorm / apartment and use a low power secure terminal, like a corebooted C201, to access it over an encrypted link?

I've done something like this when I had to travel last -- was able to maintain a stable link back to one of my POWER machines so the lack of local computing power on the laptop didn't matter. Really hate that Chromebook touchpad though. ;)

I've actually given up on using laptops for now. I still have an old x201 and t400 but they don't get out much due to the Intel silicon vulnerabilities.

Nothing I do with secure data hard-requires that level of portability, and for insecure (tracked, DRMed, closed + signed firmware) mobile use a Lineage smartphone is good enough for what I do. A laptop with closed / signed firmware simply doesn't gain me anything worth having over the phone.

My personal desktop is a Blackbird. The couple of old x86 apps I can't easily ditch (because they are open source but need MVC APIs and I'm too lazy to write the shim layer) I just forward X over SSH to an old corebooted Opteron box.