floatboth

https://wayfire.org — you're welcome :)

For fun parts you can get an NXP LX2160A board from SolidRun (or the earlier Marvell Armada8k one).

The performance wouldn't be competitive (Cortex-A72 is really old by now) but it's nice to have a proper arm64 desktop.

> I wonder if a Q32-17 workstation could be put together for cheaper than whatever the cheapest Apple M1 pro device is

Nah. You can't just get a chip & mainboard retail since there is basically no market for that.

About the only option for an Altra workstation is a prebuilt for "as low as $7661" :(

https://store.avantek.co.uk/ampere-altra-64bit-arm-workstati...

The P650 core is compared to Cortex-A77 (while Neoverse-N1 is an offshoot of A76), but N1 is from 2019. P650 is still in the "dev kit somewhere in 2022" stage, while the new Neoverse-N2 is in the "AWS is letting EC2 customers test drive it already" stage: https://aws.amazon.com/blogs/aws/join-the-preview-amazon-ec2...

> They prefer to keep inner workings secret

https://github.com/tianocore/edk2-platforms/tree/master/Sili... https://github.com/tianocore/edk2-platforms/tree/master/Sili... https://github.com/tianocore/edk2-platforms/tree/master/Sili... https://github.com/tianocore/edk2-platforms/tree/master/Sili...

dtb is for embedded devices. Server/workstation class hardware uses ACPI.

And security people hate them because side-channels.

The big shortage seems to be in microcontrollers and power ICs, not the kind of stuff you'd want to fab on TSMC.

Putting an STM32 onto N7 would be nuts.

Highly doubt that this will reduce the amount of mining in the world. Eth miners will mostly just switch to a different shitcoin. As long as BTC is dominant, mining will keep wasting gigatons of power. And how exactly would anyone dethrone BTC? The first mover advantage is everything, and nothing else has it.

The demand from gaming & workstation & datacenter is absolutely huge, revenue would not fall without buttcoiners because the GPUs would still fly off the shelves.

In fact buttminers create a new risk for the vendors: whenever buttcoins seriously crash, the market will suddenly be flooded with used GPUs.

After git itself – patch-based systems like pijul. But it won't be easy to overcome the inertia. Git is just that popular.

Isn't the vast majority of electricity in France coming from French nuclear power plants?

Windows handles not holding onto the inode is a major, MAJOR pain in the ass.

I hate the fucking "file is busy, try again?" dialog so fucking much.

Major versions of Gtk are, for all intents and purposes, different toolkits entirely. They are always parallel-installable, they don't conflict with each other.

The de-facto standard for dependency discovery is pkg-config. CMake being its own little world with its own finding system is annoying and part of the reason why the ecosystem has not migrated from autocrap to CMake en masse. Thankfully Meson came along, which does everything correctly.

What is the missing 1 point?

> overcomplicated

What exactly is complicated, using hexadecimal in addresses? The IP packet format itself is as simple as ever, and management things are done in a more elegant way (ND runs over ICMP rather than ARP being sort of there on the side not-in-IP-at-all).

> not backwards compatible

Massive service providers like T-Mobile US who use NAT64 as the only way to connect to v4 hosts anymore would disagree.

> doesn't actually solve the NAT problems for home users because of how ISPs work in the real world

My ISP delegates me a /56. How else do ISPs work in the "real world"? I've heard of some giving out smaller networks but never something egregiously small.

But the higher the framerate, the less time you have for exposure on each frame.

But that CPU shouldn't really do anything other than shoveling raw sensor data to flash as fast as possible. All the processing can happen on your workstation (or an iPad or whatever).

Is on-chip flash really that much more vulnerable to glitching than on-chip RAM, the CPU registers, etc.?

Yes, with a cable that connects to SBU pins: https://chromium.googlesource.com/chromiumos/third_party/hdc...

(if you have unlocked CCD and didn't lock yourself out of it — you could e.g. forget the password)

you can do whatever you want using flashrom with the SPI flash chips for both AP and EC.

> this design doc

Hmm, there's no timestamp for the page itself but the picture attachments are dated 2009.

> Cr50 RW storage can be recovered from the RO loader by using a physical USB-UART cable

That sentence sounds weird, not sure why it wouldn't be recoverable via the SBU cable — the RO firmware is just an earlier build of the same firmware that does offer the GSC/Cr50 UART among its consoles via SBU.

I'm not going to check though :D

> how the RO firmware is authenticated

According to OSFC presentation https://2018.osfc.io/uploads/talk/paper/7/gsc_copy.pdf

"RO public key in ROM, RW public key in RO" so they thought of that, the root of the root of everything is truly immutable silicon.

> e.g. glitching the Boot ROM

There are likely measures against this, since this is a "secure chip" designed in modern days by Google rather than some shitty vendor. But either way, attaching probes for voltage-glitching the root of trust is far beyond the capabilities of the proverbial "evil maid" :) And the glitching question should apply to Apple and whoever else as well.

> any end user with no specialized knowledge can follow a few simple documented steps with another machine and a USB cable and an app in the App Store (or idevicerestore) to fully, securely, and confidently restore all the writable firmware

What Google does for the "normal people" AP flash recovery: only the RW CBFS partition is writable from the AP, and for recovery it boots from an RO partition: https://doc.coreboot.org/security/vboot/index.html#recovery-... (there's a theme to everything the CrOS team does haha… surprise, the EC also uses the RO+RW mechanism)

Yes, this doesn't protect against the "I'm a normal regular user with no debug access and someone desoldered my SPI flash, tampered with it and soldered it back" but… come on :) Especially considering hard-to-open laptop cases and WSON-8 flash chips, that's just a ridiculous scenario to care about.

Defender still introduces performance issues, sometimes it's better to disable Defender too and have no scanning crap whatsoever.

GPUs are often the easiest to recover actually – boot with another GPU, keeping the screwed-up one plugged in – it will still be flashable, just run atiflash or whatever.

Also, high end "gamer" hardware often includes "dual BIOS" (on both mainboards and graphics cards) and/or "BIOS flashback" (special button makes a microcontroller flash an image from a USB stick inserted into a marked port, even without a CPU present).

The screw hasn't been a thing for years, you prove ownership by sitting there for like 15 minutes pressing the power button when told :D

But it's a lot more than just "go ahead".

For stock users: enabling dev mode wipes storage and reinstalls CrOS, so trying to "attack" via dev mode a) won't give the attacker any data and b) will be extremely noticeable because the data is gone (and there will also be dev warning screens all the time unless they then make fully custom FW and CrOS that aren't secure but look exactly like stock)

For custom users: you can lock the debug interface with your password! Plus do your own vboot if you're concerned about.. ehh.. flashing over SPI directly bypassing the debugger (not easy on some devices) or somehow some vulnerability allowing internal flashing from the CPU.

So Chromebooks do have decent measures against physical access and allow for full CPU & EC firmware customization.

The screw meme just doesn't die… Modern Chromebooks use a debug USB-C cable for flashing and serial console access, and a "sit around for like 15 minutes pressing power button when told" process to prove ownership to unlock dev mode.

Come on, that's not a real problem ;)

As someone who had a Clojure phase about 9 years ago: the actual problem with modern Lisps is that they don't really offer a big set of unique good features. The basic functional map-filter-reduce "meat grinder" is everywhere (and has been almost everywhere for a long time, Java not having lambdas for ages is what clouded everyone's vision into thinking that's not the case). The other "Lisp feature" is macro metaprogramming based on homoiconicity (Code Is Data™) and we have it in some non-Lisps too now (hello Elixir) and… is it really the best way to do metaprogramming? Ehh. Well, many compiled&typed languages actually do similar-ish things: using syn in Rust proc macros / haskell-src-exts in Template Haskell you can work with code "as data". And that isn't as nice to work with as D's `static foreach/if` + reflection/introspecion thingies like allMembers/getMember.

Hiding what's going on (e.g. details related to real hardware like machine integers) is arguably pretty good for teaching a complete beginner about what this "code" thing even is.

Though I guess the classic workaround for that is to carefully construct the course such that these details are revealed gradually, without being overwhelming.

> claiming that literally everything is OOP

Well, "is" is quite the load-bearing word in those claims. I think it is kinda true in the sense that lots of things can be represented as OOP. A great example is how Scala represents ML-style ADTs as sealed class hierarchies.

Interpreter state ("what's been `use`d") completely changing the meaning of that expression sounds like the worst possible way to do it.

Oh I didn't mean "random" as in "could change". In fact "random" was about the unspecified .so blob, not the http archive.

> pkg-config in my experience is less reproducible

But this is what I mean, you only want full reproducibility in a "corporate" environment. In a FOSS desktop environment you often specifically want to use whatever the system has.