As technologists, we live partially in the future. We are always making implicit bets based on our predictions of what the future will bring. To better understand our powers of prediction, it can be helpful to look back into the past, to review our biases and best guesses in retrospect. As we seek to understand this next tech cycle, Bryan Cantrill takes us through a series of predictions made over the past two decades to see what actually came to pass, what was stunningly wrong, and what may still be emerging in the industry in 2022 and beyond. To watch all of the recordings hosted during Scylla Summit 2022 visit our website here: https://www.scylladb.com/summit.

1. Predicting the Present
Bryan Cantrill
CTO
YOUR COMPANY
LOGO HERE

2. As technologists, we live partially in the future: we are always making implicit
bets based on our predictions of what the future will bring
• To better understand our predictions of the future, it can be helpful to
understand the past – and especially our past predictions of the future
• E.g., for nearly a decade starting in 2000, a group of us gathered each new
year to make (and write down!) 1-, 3- and 6-year predictions…
• These were often both surprisingly right on trajectory – and stunningly wrong
on timing
The power of predictions

3. • 6-year, 2000: “Most CPUs have four or more cores”
• 3-year, 2003: “Apple develops new ‘must-have’ gadget: iPhone. Digital
camera/MP3 player/cell phone” (!!)
• 6-year, 2003: “Internet BW grows to the point that TV broadcasters become
largely irrelevant; former TV networks begin internet broadcasts”
• 6-year, 2004: “9/11-scale economic shock caused by single virus”
Aside: Dire predictions

4. • Dire predictions are compelling, viz. The Population Bomb (1968), Silicon Snake
Oil (1995), Time Bomb 2000 (1999)
• Even the wrong ones are often not entirely wrong – they contain important
truths
• But dire predictions often also ignore human adaptability: yes, bad things
happen, but humans are adaptable – technologists especially so!
• Dire predictions should not be summarily dismissed, but nor should they be
unquestioningly accepted – however authoritative they may seem
Some of our predictions from the aughts…

5. • 3-year, 2004: “Friendster killed by friends.google.com”
• 6-year, 2004: “Term ‘long distance’ falls out of telco lexicon”
• 1-year, 2005: “Spam turns corner, less of a problem than year before”
• 1-year, 2006: “Google embarrassed by revelation of unauthorized US
government spying at GMail”
• 6-year, 2006: “Volume CPUs still less than 5 GHz”
• 6-year, 2006: “Wireless 3D video ‘iGlasses’ (w/ear-buds) latest ‘it’ gadget”
Some of our predictions from the aughts…

6. • Looking back on our predictions, they tell us much more about the present
than the future!
• Longer term predictions were more likely to be accurate than shorter term
ones – and much more likely to be interesting!
• We entirely missed important trends like cloud computing and software-as-a-
service!
Reflecting on predictions

7. • More generally, we missed the ramifications of the broadening of trends that
that we already understood to be transformational, e.g.:
○ The Internet
○ Distributed version control
○ Open source
○ Moore’s Law
Missed predictions

8. • Find those current things that clearly represent a better way of doing things,
but are not broadly appreciated or understood
• …which is why many technologists find the future somewhat accidentally: they
find something that they themselves enjoy!
• This is not foolproof or formulaic (some trends never broaden!) and likely to be
wrong on timing – but less likely to be entirely wrong on trajectory
• “The future has arrived – it’s not evenly distributed yet.” – William Gibson
Finding the future

9. • Gibson’s famous quote starting appearing as attributed to him in the early 1990s –
but it is of unknown origin
• Ironically, this idea itself seems to not have been very evenly distributed!
“The problem is that the idea would have preceded its first recorded public utterance by quite
some time, in the way of these things. I would assume I thought it, then eventually said it to
friends, and that by the time I said it in an interview (the most likely scenario) it had become an
idea I took for granted. It wasn’t something generated to give a talk, nor was it in some essay
or article.”
– William Gibson in personal correspondence to Kevin Kelly, 2011
Source: https://quoteinvestigator.com/2012/01/24/future-has-arrived/
Aside: Gibson’s quote

10. • The things that I feel I know that might not be evenly distributed:
○ Compute is becoming ubiquitous
○ Open FPGAs/HDLs are real
○ Open source EDA is becoming real
○ Open source firmware is (finally!) happening
○ Rust is revolutionary for deeply embedded systems
Predicting the present, ca. 2022

11. • Computation becoming ubiquitous, meaning computers in new places (à la
IoT) but also CPUs where we once thought of components
• E.g., open 32-bit CPUs replacing hidden, closed 8-bit microcontrollers
• We are already seeing CPUs on the NIC (SmartNIC), CPUs next to flash (e.g.,
open-channel SSD) and on the spindle (e.g. WD’s SweRV)
• New opportunities for hardware/software co-design: keep hardware simple
and put more sophistication into software and/or soft logic
Ubiquitous compute

12. • FPGA bitstreams have historically been entirely proprietary -- and one is
therefore dependent upon proprietary tools to generate them
• The Lattice iCE40 bitstream format was reverse engineered in 2015 by Claire
Wolf, and can be entirely synthesized with an open toolchain!
• While Xilinx (AMD) and Alterra (Intel) retain proprietary components (e.g., for
timing models), newcomers like QuickLogic are entirely open
• See, e.g., SymbiFlow, Verilog to Routing (VTR), Yosys, OpenFPGA, and the
(new!) Open Source FPGA Foundation
Open FPGAs

13. • Hardware description languages have traditionally been dominated by Verilog
and (later) SystemVerilog
• Compilers have been historically proprietary -- and the languages themselves
are error prone
• In recent years we have seen a wave of new, open HDLs, e.g.: Chisel, nMigen,
Bluespec, SpinalHDL, Mamba (PyMTL 3), HardCaml
• Of these, Bluespec is especially interesting!
Open HDLs

14. • Proprietary software has historically dominated EDA…
• Open source alternatives have existed for years -- but one in particular, KiCad,
has enjoyed sufficiently broad sponsorship to close the gaps with
professional-grade software
• The maturity of KiCad (especially KiCad 6!) coupled with the rise of quick turn
PCB manufacturing/assembly has allowed for astonishing speed:
○ From conception to manufacturer in hours
○ From manufacturer to shipping board in days
Open source EDA

15. • The software that runs closest to the hardware is increasingly open, with
drivers nearly (nearly!) always open
• Increasingly, we are seeing the firmware of unseen parts of the system
become open as well, viz. the Open Source Firmware Conference
• This trend is slower in the 7nm SoCs -- but it’s happening!
• However, even in putatively open architectures, there generally still remains
proprietary software in the form of boot ROMs -- and this proprietary software
remains a problem!
Open source firmware

16. • Rust has proven to be a revolution for systems software: rich type system,
algebraic types, ownership model allow for fast, correct code
• Slightly more surprising has been Rust’s ability to get small -- which coupled
with its lack of a runtime lets it fit everywhere!
• With its safety and expressive power, Rust represents a quantum leap over C --
and without losing performance or sacrificing size
• Viz. Hubris, the de novo Rust operating system we developed at Oxide, now
open source: https://oxide.computer/blog/hubris-and-humility
Embedded Rust

17. • None of these things i new per se – but they are real and tangible and in active
daily use by us at Oxide
• They all point to a future in which hardware and software are actively co-
designed!
• That so much of this is open assures that it will survive
• The trends may take time to broaden, but the trajectory seems likely!
Evenly distributing the future

18. Thank you!
Stay in touch
Bryan Cantrill
@oxidecomputer
bryan@oxidecomputer.com