Slashdot Mirror
More Power To The Firmware
An anonymous reader writes "In More Power To The Firmware Amit Singh talks about technical details of EFI, the next-gen BIOS replacement standard Intel, Microsoft and others are pushing. This is a very informative piece where he talks of issues with legacy BIOS, how it affects those who develop in the firmware environment and how EFI plans to solve these problems. EFI usage examples are included, including a programming example. He contrasts EFI with Open Firmware as well. IMO the second half of the article is even more interesting, where sample FORTH code is provided for displaying a window/mouse pointer GUI inside the Apple/Mac firmware! And of course, there's code for a new 'Towers of Hanoi' animation using the Mac firmware (remember Hanoimania?). Aspiring Mac Firmware Hackers could also check out the suggested projects ;-)"
...but can you imagine any sort of Windows-dependent BIOS? Is this in our future? Is it even possible? Or, worse yet, a Windows-based BIOS of some type where the OS actually IS the BIOS?
Don't be a looter...and yes, I know that it's spelled with an "A" instead of an "E".
I'm not in favor of increasing the complexity of the bios. They can barely get them stable after a few updates now, how will it be when they are doing alot more? Yeah I know that Sun Sparc's have a complicated bios, but they did it right. I don't trust Microsoft and Intel to do it right.
thisnukes4u.net
We don't need DRM built into the BIOS, and that's exactly what would happen if Microsoft had a say in it.
I agree that we don't need more complexity. Let the OS handle the hardware as much as possible.
- It's not the Macs I hate. It's Digg users. -
We don't need no stinkin' software, firmware will do it for us.
Insert witty saying or aphorism here.
i had an amd 486dx4/100 motherboard back in the mid 90s that had a full gui windowing system to configure the bios that relied on the mouse (tabs were used, too). i think it was 640x480 or something very similar.
Apple has been doing this since the beginning, since they control all hardware (or has to be approved by them). Having MS or Intel do it on a box that will have an immeasurable amount of peripherals by different manufacturers is only looking for problems. It may be possible but I fear it will be at the expense of creativity and thinking differently will not be an option.
Stay tuned for new sig...
great. so step down the drm one level. When do we get the BIOS's bios then? And then when do we get the work-around for that? And so on and so forth..i'll not be buying from Intel or Microsoft anytime soon, if ever again.
Here's a link to an older KT entry; "Status And Discussion Of EFI (Extensible Firmware Interface) Support"
Explains some history, rationale and technical details.
Belief is the currency of delusion.
However I'm sure by the time I actully press submit it will have done just that, but then again that is basicly the theme of every other thread on /.
heh reminds me of a pocket pc where the Windows OS is in the ROM
The war with islam is a war on the beast
The war on terror is a war for peace
Glad to see there is attention being paid to the firmware end of things both commercially and as open source - that's one area your average geek is a little leary of toying with, due to Inoperative Hardware potential.
What I always worry about is the non-techical end of these things. BIOS level control on what software a computer can run is a much harder obstruction to overcome than things like driver issues. I wonder if they won't use the "Next Generation" mantra to say this is the perfect time to pass legislation that requires DRM control be built into all computational devices. OpenBIOS wouldn't be of much use if DRM laws require a closed system.
Also, if firmware gets too smart, you might get things like a DVD drive refusing to play a movie unless your operating system can guarantee it that you computer doesn't have the ability to copy content illegally.
When you can program games in BIOS level systems, I start to get a little wary. Keep my BIOS to the minimum please - configuration options needed to handle my hardware (things like boot order, low level configuration options the OS shouldn't know about, etc.) should be all the capability needed. A BIOS should be simple, efficient, and stick precisely to its job. I've got an OS for the rest. If the new system is good for that type of work, excellent. But if the hardware starts getting too smart for its own good, then I might wind up hauling out those two Sun Ultra 1s I bought - they should run more or less forever and I'll live with slower speeds in order to stick with a consumer friendly machine.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
This would definitely help Intel and its 'Not'tanium. Then AMD would have to make something similar or pay to use the same design. I am more interested in the System Abstraction layer. Would this simplify direct access to sys devices?
While I think that the current x86 BIOS methods are outdated, I do not support a leap to total OS integration, yet.
I think that if a community effort were mounted through a system of standards, a satisfactory next-gen BIOS could be acheived.
Of course, this raises the question of who comprises the community, businesses or enthusiasts?
"Here's a spoiler: You're will die alone."-Triumph the Insult Comic Dog
Let me add something that I find remarkable: I have not seen a single reference to Open Firmware in any EFI specification, presentation, whitepaper, or related document. Perhaps I did not look hard enough. This is not a criticism though. Some might argue that EFI's pathbreaking-ness is valid in the context of PCs, so it is appropriate not to mention prior similar ideas.
I'm not quite sure what that last part means - how can you say it's not appropriate to mention when the technology is so similar? Just because it hasn't been used on PC's before is no reason not to learn from what has been used before.
I would have liked to see more of a comparison of exactly whe EFI gives you over Open Firmware of today - I gathered it was the custom pre-boot programs and network connectivity, but I would have liked to see more examples of new things that make use of these features that you can't do in Open Firmware.
It's funny to have a whole article about EFI then show all the cool things you can do with an advanaced BIOS by giving Open Firmware demos. Sort of like watching a Longhorn demo of transparency in UI while working on a Mac.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Golly, the amount of time Amit seems to spend messing around with the very low levels of Open Firmware seems insane! Imagine figuring out how to get a mouse to work solely to get his 'Tower of Hanoi' program to work nicer! :-)
Still, more power to him.
Your Windows PC is my other computer.
640K ought to be enough for any BIOS :)
--Aaron Greenberg
I just skimmed through the article looking for information about the Palladium-like DRM stuff that was supposed to be embedded down to the hardware level within the next few years. I couldn't find anything. Not being a hardware/firmware person, a lot of the stuff in the article is over my head, but I expected something about DRM to shine through, if not to be the overriding theme.
DRM has already been mentioned in a few comments in this thread (perhaps by people who didn't RTFA). But where is it???
As long as the direction appears to be open standards, "blurring" the line between core hardware and the OS at this basic level isn't that dangerous a concept.
Mod me troll, if you must, I can't help it.
You can do a lot of stuff in Open Firmware by changing environment variables. A good project would be to create a graphical configuration utility that lets you do just that in addition to browsing the device tree.
The perfect sig is a lot like silence, only louder
So I glaned over the article, and while it mainly focused on EFI being done for IA-64, it also hinted that EFI was available for x86. Does anyone know of any reasonable priced motherboards that use this as opposed to an older BIOS? I'm looking for the hinted at x86 support, as I don't feel like buying an Itanium. Also, while we are on the subject, is this an Intel only thing or does AMD have a say in the matter?
-- Fighting mediocrity one bad post at a time.
It does hardware abstraction, draws windows, bytecode interpreters, etc.
I've been using EFI (on Itanium) for quite some time, and have had zero issues with it. I really like the fact there are DCHP modules that allow networking to be started without the OS running. They have ftp servers, disk drivers and you can boot your machine from a remote image using bootp services. If your OS is dead on your disk, you can restart to efi and download a previous image on to your harddisk (or remote boot/install). Heck, you can run your code without even booting the OS. Imagine dedicated distributed.net clients that run straight from EFI without the overhead of an OS.
While I understand people have concerns that Microsoft is using this as a DRM delivery mechanism, there is nothing that is stopping Microsoft from working with Phoniex to add DRM to today's bios's. EFI (and non-legacy bios environments like openBios) make it easier for non-windows OSes to run on new Hardware. This isn't in microsoft's best interests. Microsoft wants a bios that only runs signed code (like their XBOX), so that you have to ask them nicely for a key to your equipment.
The author mentions that EFI is somehow better than Open Firmware, but I fail to see how. It all sounds like Intel decided to go their own way again (just like their Itanium had to be different and incompatible with any (RISC or CISC) CPU out there).
Why, for sanity's sake, can these companies never adopt a perfectly good standard, but do they always have to give everyone headaches by rolling their own? If Open Firmware has some deficiencies, surely they can be fixed with some incremental improvements?
The Intel Architecture is evolving...from the primitive, kludgy, underperforming, el cheapo to the overhyped, overheating, overexpensive and incompatible. Even IBM (Connector Conspiracy) and Apple (Think Different) are more open and standards-oriented these days.
Please correct me if I got my facts wrong.
I found the assertion that 64bit PC's don't use the BIOS rather amusing. Evidently bits of Intel still haven't managed to bring themselves to admit the existance of Athlon64 just yet.
I hope this doesn't mean that PCs will be sold like Xboxes. I don't want to have to intall a mod chip on my laptop to run linux. I like the idea of the BIOS having more function and power, but I want it to do more than just prevent code from being executed. This should definately be an open standard otherwise Microsoft or Intel will have too much control. It's one thing to boot into windows and have that muck up your computer, but it's different when microsoft code is running on a linux box.
Since microsoft doesn't seem to like to innovate anymore, I wonder why they are pushing for this. Linux has shown that you don't need security at the hardware level to prevent viruses from taking down your computer.
So far I don't see many benefits the user will notice and enjoy. I'm not trying to spread DRM FUD because this article doesn't talk about it, I'm just asking why Microsoft cares so much to push this.
You mean after ten years of proven success in both SUN AND APPLE SYSTEMS Intel finally gets PCI religon?
That is right folsk intle is finally enacting the last part of the PCI psec.. should we jump and cheer for it after ten years of foot dragging?
Don't Tread on OpenSource
There are various system emulators that need ROM images to boot the virtual system. I have been wondering about open source projects to provide these images, unencumbered by copyright restrictions, trade secrets, what have you.
I am into operating system development, and I would like to play around with architectures that I don't have real hardware of. It can't be too hard to write a firmware implementation if the code for the emulator is already available.
If you are aware of any such projects that are not mentioned here, please post. Ones that I know of are OpenBIOS, FreeBIOS, and LinuxBIOS, which are also mentioned in the article, with links.
Please correct me if I got my facts wrong.
It would be fun to see someone port one of those Apple ][ emulators to this thing, so you can actually boot a Mac into an Applesoft programming mode, just like in the old Apple ]['s. If it can handle a simple GUI like in the article, or if it could handle an implementation of System 1, I'm sure an Apple ][ emulation would be no problem.
From what I gather in the article, any of these Forth programs have to be loaded off of the hard drive in order to be executed. I didn't really understand if they could be stored in non-volatile memory, and if the computer could be configured to run them when it is turned on. I don't know how much space there is for non-volatile memory, but it would be interesting to be able to write a really basic OS that runs off of it without having to read from the hard drive at all.
I suppose it's possible since you can update the firmware, but does Apple keep information about how to program the firmware proprietary, or is it open for people to tinker with?
"In More Power To The Firmware Agent Smith talks about..."
Its anti-flamebait. There are far too many people on /. that think that way. I call them "Stupid".
PS. Now this post, on the other hand, will also probley be modded down. Thats a good thing. I think That getting modded down every now and then is a good thing. If everyone agrees with what you are saying, then you must not be saying anything important.
PS PS I think its clear to me that slashdot's moderation system is a failure. The signal to noise ratio is far too low. The insightful comments aren't, the average poster has the maturity level of a 13 year old, ect, gripe, ect. I don't know how much longer I'll be here.
Well.. maybe. Or Maybe not. But Definitely not sort of.
Kinda' like what Apple has been doing for 20 years... You run their software on their hardware, and that's it. No software will readily run on their hardware, and their software won't run on other hardware. Not so scary.
It wouldn't be very Basic if it had DRM on it.
Why not make plug and play operating systems on rom chips?
What's happening here with EFI is that the BIOS has now grown to become an OS. If all you want BIOS to do is init the hardware and then jump to an OS then that's all the BIOS should be, just some init code to set up memory, chipset registers and cache so that it can jump to an OS for all the rest. But if you want the BIOS to do a whole lot more than just call it an OS and use an OS with lots of support with drivers already written.
And for this BIOS that's really acting and grown to be an OS, I choose Linux!
More at : http://www.linuxbios.org/
Quidquid latine dictum sit altum viditur
The one thing people always forget is that, in truth, Microsoft/Adobe/Autodesk need people to have pirated versions of their software. Have you ever noticed how quickly major pieces of software are cracked after release? My guess is that they unofficially provide people with information to make this possible.
If everyone absolutely and without an option had to pay for their version of Office/Autocad/Photoshop, free software would become ten times more popular in no time at all. Right now, software companies can keep their prices artificially high for the businesses that have to pay for it, and keep the "installed user base" artifically high without having to provide tech support.
It's sort of the same thing with laws in the States. If every law was enforced every time, then people would be pissed and they would go away. Instead, laws that aren't enforced 100% of the time can be used against people the government doesn't like.
If DRM ever hits 100% of the market, prices will go down because people will refuse to pay.
How long before we start seeing poorly written pre-boot applications causing vulnerabilities?
For instance, with efi's networking capabilities, I can imagine hackers letting efi grab that 1 dhcp address that the user has allocated, and reporting it back to them. While the user spends time on tech support trying to figure out why ipconfig doesn't show anything, the hacker is rooting around their disk through efi.
That may be far-fetched; but from the concepts offered in the article, it sounds feasible.
Would any firmware-saavy slashdotter give us a hint as to how likely that scenario is?
Hot Damn! It's the Soggy Bottom Boys!
CALL -151
I want to delete my account but Slashdot doesn't allow it.
While the OS may have been in ROM, Like the Atari ST's, that doesnt make it the actual BIOS.
By its very definition, the BIOS is a much lower level block of code. the true hardware abstraction layer, that the OS rides on top of..
Sure its also in a ROM of some sort, perhaps even the same chips.. but that still doesnt really make a ROM based OS a 'BIOS'..
---- Booth was a patriot ----
Back in the day, when I was a co-op student employee, I spent some time testing Linux drivers on Itanium systems. EFI was about as intuitive as a worm eaten apple (no docs, just a "hey, you're good at figuring things out, test this"). Plus, it kept forgetting changes to its configuration. Eventually, I became familiar with its obtuse ways, but it never exactly brought a smile to my face when I saw the EFI prompt.
That said, the PC BIOS should have been put out of its misery years ago. I'm just not sure EFI's really going to make developer's & users/admin's live that much easier.
Let us not forget that IBM published the assembly language source code listing for the original PC BIOS in full beginning in 1980.
This "openness" allowed and enabled the first generation of PC developers to see and understand what was going on at the firmware level - literally an open book and manna from heaven for the times.
This was not quite the precursor of today's open source movement though since IBM never granted permission to copy or use the code, but 1 billion PC compatibles later it is easy to see that IBM's approach unlocked at least one aspect of the value of openness.
Dan Bricklin comments thoughtfully about the PC BIOS in his blog. Search for "purple".
Controlling access to copyrighted media is not the DRM BIOS's direct role; its role is to ensure that the operating system that boots can be trusted to do so.
Right now, a secure trusted music player may ensure that the copyrighted media it plays never ends up in the wrong hands (i.e., the user's); however, there's nothing (in theory) stopping the no-good thieving user from replacing the audio device driver with one which makes a copy of the unencrypted sample stream elsewhere. If the OS requires drivers to be signed, then the OS can be hacked; they can boot from a hacked kernel which doesn't enforce this requirement.
This is where the DRM BIOS comes in; under it, all bootup code would have to be digitally signed. Any code that's signed would, in theory, continue the chain and not load any other code which is untrusted in a privileged capacity. Only once the black iron sandbox is built does any potentially untrustworthy code get loaded, where it can't do anything untoward.
Incidentally, this may be compatible with the GPL. Linux could still be distributed with source code you could look at; just that if you compiled your own kernel, it wouldn't boot on your machine (at least not on the bare metal).
You hit it more or less in your second sentence. LinuxBIOS is not an OS in a BIOS. It's a minimal BIOS that can bootstrap a system and load a Linux kernel stored in the firmware. This is good because, as you pointed out, there are already tons of drivers and stuff for Linux, and Linux can handle things like initializing hard disks and NICs. It can then load the OS.
LinuxBIOS fits more in the description you gave in your second sentence.
How long do you really think it would take to reverse engineer a BIOS?
If Microsoft were to be successful in implementing deals with the BIOS makers to require their "trusted" BIOS, the whole system would be dependent on some sort authentication call. It seems to me it would be trivial to discover those calls, and hard-code the "trusted" response into the open BIOS. If it's a true hash calculation on the revised BIOS, that makes it trickier, but finding the right "extra bits" to come up with the same hash would be an interesting distributed computing problem.
It's axiomatic that any software designed to limit freedom of information will be circumvented sooner rather than later. This one just seems particularly easy.
The cure for cancer is coming: Reovirus
Until you can do email from within it.
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
The full operating system is not in ROM. Basic system drivers and windowing code is, as well as the kernel, but it's not the whole shebang. The AmigaDOS ROMs lie somewhere in between OS and BIOS.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The page does a nice job furfilling it's stated purpose, but suffers from a lack of segregation that might be confusing. The author cited example for EFI in Part I. He could have put those links into a separate section in part II. This is a minor formatting problem and I'm happy that the resource has been created.
"Part I: The Firmware Scene." gives you what it promises. If you look through the headings you will see, Legacy Pains, EFI, Open Firmware and Others. Wow, that's a lot to cover.
"Part II: GUI Widgets In Open Firmware", also gives you what it says it does, though it looks like it does not follow because it only talks about Open Firmware. Amit could have made it into examples and put his EFI link in as the EFI example and talked about it a little.
Overall, Amit has created a nice resource. He gives objective descriptions without much opinion. I would not have bothered to mention closed source and I can only imagine how much trouble it is to keep informed about things that the developing companies want to hide details of.
Friends don't help friends install M$ junk.
It worships Apple by showing the power of the OpenFirmware system in Macs. RTFA b4 tr0|ling, U L@/\/\3R.
Wont this new standard die in a few years once we get those instant-on PCs using integrated silicon and nanotechnology?
~ there are 10 types of people in this world, those that can read binary and those that can't
Backslashes? DOS-style dir listings? UGH, I thought the idea was to remove obsolescence.
Also, this is even worse than ACPI from a needless complexity standpoint.
And, do note that BIOSes are a PC only thing. The Amiga "BIOS" was actually some code on a small (64k IIRC) ROM chip that did hardware self-tests and loaded Exec from the 256k ROM chips (which also had intuition.library and some other libraries and device drivers). Then, the bootblock was loaded and Exec ran the system startup scripts.
dd if=/dev/zero of=`df / | awk '/^\/dev/ {print $1}' | sed 's/s[0-9][a-z]//'` count=1 bs=512 && shutdown -r now
I didn't think it was bad at all, I thought it was a great reference - it's just that he teased me by showing me different aspects of two different worlds that look very similar, without giving me much common ground to tie the two together!
Basically, I'm just hoping for a part three that concludes the whole thing with a comparison.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
As you know, EFI is really old technology.
The Intel incarnation of EFI is a trophy for outsourcing proponents. Instead of implementing BIOSes, they develop standards for BIOSes. Would Intel be drafting standards if the work done by IIRC was still done in Santa Clara? Probably never.
We should start thinking of standards as commodities rather than intellectual property. The standard will be the product just as noodle salad is to a restaurant.
Distribution channels who want to sell a board can then buy firmware from a single implementor, say a contractor in India, without the need to have their own specialized programming team. They will sell the board under the name of its standard.
Then after a few years the standard will become obsolete. Just like a gadget, the standard will be phased out for the next evolution. Instead of single implementors making their own leaps, we'll have groups of distribution channels making leaps, each selling slight variations of the same product, the standard.
Perhaps the classic concept of a BIOS is a PC thing, but other machines have an equivalent, such as SUN and apple...
Some have more features, such as a tty console, but they are the same concept..
Really any well designed machine would have the hardware abstracted away from the OS.. Unless you start talking embedded devices, where space is at a premium..
---- Booth was a patriot ----
That is soooo lame. If I have a recovery tape, which is common practice under HP-UX, I can't recover from it, unless I use a very uncomfortable 2-step procedure (booting from CD and then proceeding from tape). HP-UX is one of Itanium's "native" OSes, but EFI is somewhat of a step back in some parts compared to HP's Boot Console Handler.
I get a certain kind of comfort when I pull in to the gas station and see a really old car using the same gas pump as me. In the auto industry there have been many changes in the past hundred years but a 1913 Model T can still buy and use the same gas as my car can.
BIOS is a sort of standard that assures compatibility. When we drift away from that standard, we start losing a very core basic value - the kind of thing that stops us from "filling up at the pump" so to speak.
I want my BIOS. Other things can change but I want my BIOS because I feel better knowing that some things stay the same.
The Amiga is kind-of unique. The OS _is_ the BIOS, as well as everything else.
Turn the Amiga on, the 680x0 reset vector runs. Through board logic, the Kickstart ROM is mapped to 0x00000000 as well as its usual location, and the lowest points of the ROM point out the jump address for the reset vector. The 68000 goes there, it's the INIT code of exec.library. Exec performs a self test on the board logic, the memory and the custom chips. It then searches for expansion cards (creates expansion.library), attached disk drives (trackdisk.device) and HDs (scsi.device (regardless of whether you have an IDE or SCSI hardware interface)), PCMCIA card disks (carddisk.device), etc.
The graphics.library writes direct to Amiga hardware. The audio.device, in ROM, writes direct to Amiga hardware. potgo.resource, cia[a|b].resource, misc.resource, disk.resource, etc, are all arbitration mechanisms for custom chip registers. Sure, dos.library can load filesystems from disk once it's initialised by a HD or disk standard bootblock, but the basic 6 Amiga filesystems are in ROM. intuition.library and its high level BOOPSI stuff like loadable gadgets, images, datatypes are built on top of layers.library, which is built on top of hardware-hitting graphics.library.
So there is tight integration between the hardware and the OS. There's no low-level code offering a hardware independent API to AmigaOS... that's AmigaOS itself. You can't put another OS there without adding in half of what AmigaOS did, in order to maintain the Amiga hardware. There's a lot of stuff that came after the Amiga designs (such as MMUs), and there's no official OS interface to it. They're not initialised by the OS. Random application programs fought over them with no OS supervision.
... this reminds me of a quote by Descartes:
d ardHere but a well defined x86 "OS image loading capability interface" or something can handle that. EFI bytecode only makes sense when you have a large number of architectures using EFI in the first place. Considering the snobbishness and NIH syndrome rampant everywhere I somehow doubt that's going to happen.
"Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away."
A BIOS where there's nothing left to take away hauls the OS into memory, maybe sets up pmode and jumps into it. Granted there might be some issues with stuff like ATA/SATA/SCSI/USB/Firewire/Ethernet/InsertNewStan
I vote they put GW Basic back into the BIOS ROM.
Or maybe useful utilities like Sun and other workstation vendors have.
Or maybe more than 15 FUCKING IRQS! Like Macs have.
Is it me, or is everyone else just better all around? The only thing going for PC's is the junk is so cheap.
Southeastern Virginia REPRESENT!
>>EFI defines GUID Partition Table (GPT), a new partitioning scheme that must be supported by EFI firmware. GPT uses globally unique identifiers to tag partitions. It is used by the 64-bit version of Windows, and offers several advantages over the legacy MBR-based partitioning scheme:
Why does the partitions have to have a GUID? Is this to be able to identify a computer uniquely to trace hackers, etc?
Most of these old bios's actually loaded their setup program off a hidden 10-20mb partition on the hard drive, not running off some rom on the motherboard.
I have played with EFI on some Itanium2 computers. It is a cool technology, because it allows you to conduct the way your computer is booting, adding your own scripts, you can even use python for that. But there are some disturbing points: these scripts are supposed to reside on your hard drive in a FAT16 formated partition, and the native EFI scripting language looks like windows style "autoexec.bat" scripting... So may be funny, but it would be far more better, and less intrusive for hard drive, to have linux bios instead.
A forth interpreter + compiler + editor can live in less than 20k of memory. This provides a lot of extra flexibility in how one does things like: handle BIOS extentions (juust write em in forth and they can run on any CPU architecture - not just x86), write service tools, disk drive low-level formatters,....
Forth is more compact than machine code. This might not seem relevant in multi-megabyte machines, but it does make it a lot easy/cheaper to add small code snippets to hardware devices.
You can modify the behaviour of the Forth compiler itself, on the fly. This makes it very handy for expressing various structures that are often difficult to express in "static" languages like C and asm.
It gives older programmers an excuse to break out the flared pants again!
Engineering is the art of compromise.
Great comment!
Mod the parent down pls, it's a sad day in /. when a person gets an 'insightful' rating for griping about the aesthetics of a firmware shell.