Hacker News new | ask | show | jobs
by newswasboring 2272 days ago
Just an aside, but it always felt weird to me that we call is bare-metal while the actual code runs on mostly semiconductors.

I am very glad that in my bachelor program our microcontrollers class actually made us hand enter hex codes in a kit. It got tedious after a while (maybe it should have been for only a few weeks not the whole semester), but it gave me a weird sense of being one with the machine. And it has as awesome ice breaker when talking with older programmers. For some of them I am the only one of my age that they have met who has ever done this. Another thing is it helped me sort of see the flow of it and encouraged optimization.

(I don't want to give too much credit to my college, they did it not as some great pedagogical trick but to save money and laziness)

7 comments

Bare metal comes from mainframe days. The largest systems like IBM 360-67 and others were called "Big Iron" - see https://www.ibm.com/ibm/history/ibm100/us/en/icons/system360... for NASA's moonshot-era Big Iron. You could run programs on OS/360 or you could, if daring, run code directly on the machine, on the "Bare Metal". It's quite common to run 1-card programs on the Computer History Museum's IBM 1401 --- which was not really considered 'Big Iron' at the time, although today we call it a 'Mainframe' https://computerhistory.org/exhibits/ibm1401/
Interesting. But why were they called big iron? It doesn't seem to be in IBMs marketing material (at least I couldn't find it) and the wikipedia reference points to a 2005 vulture article where they call it the big iron[1]

[1] https://www.theregister.co.uk/2005/07/20/ibm_mainframe_refre...

I think it might come from auto body shop terminology. We would remove layers of paint or rust and get down to the "bare metal" for prep work. That "down to the bare metal" phrase was very commonly used.

That is to say "no layers" or "right on the substrate".

Just a guess though.

We call the code that users can actually interact with (even code that's deployed to a web server on the other side of the world) "production" because that's what factories called it when they started producing something. It doesn't make much sense when you think about it either, but I also can't think of anything better to call it.
You're totally right. I think the intermediate step was that software houses producing software prior to online distribution becoming mainstream would refer to software as being 'in production' when it was sent to the factory for CD replication and distribution. Literally being 'in production' at the factory. I believe the term has persisted from this.
> That is to say "no layers" or "right on the substrate".

Ok, I feel very pedantic saying this, but the substrate is the thing that is mostly semi conductors :P.

This "silicon is not a metal" pedantry is a whole new layer of tedium. But if you want to take it that way: the data is mostly carried in the metal layers of aluminium, and the substrate is .. a substrate that's not doing very much.
If you really want to be pedantic then the data is processed and stored in flip flops and stored as charge in semi conductor dielectrics.

But don't take this so seriously, I work in semiconductor manufacturing and even I don't take it that seriously.

I've always thought:

All possible abstraction removed = bare metal

On x86/64 only the CPU vendors go down to that level. Well them and security researchers.
Would you exclude compiler/assembler developers ? Are they not using the bare chip capabilities? Is assembly an abstraction ?
On micro-coded CPUs Assembly is indeed an abstraction, because that is not what the CPU is running, hence why many mainframe manuals refer to Assembly as bytecode.

On x86/x64, the chips have long migrated to an internal RISC like architecture, with an Assembly => micro-op translation step on the decoding unit.

> Is assembly an abstraction ?

Yes, assembly is an (mostly fairly thin, on non-microcoded hardware) abstraction over machine code.

Assembly is an abstraction, as the others have mentioned, but many compiler people are aware of this as it affects performance.
My first actual programming class was on an Intel 8085 kit, and I have to say that hand-assembling on pre-printed carbon sheets was pretty cool. It has served me well in my career to have started at that level.
It would serve everyone well to start at that level. I write enterprise CRUD webapps, and learning these things helped me tremendously.

Unfortunately we now have a culture that views this type of knowledge acquisition as "gatekeeping"

Most universities and technical schools of enough quality do have Assembly programming classes, even if it is a kind of light introduction to the subject.
How so? Why would that be gatekeeping?
Not OP but I can venture a suggestion. There are a lot of people who believe that programming computers is fundamentally simple, and that programmers really only need to know about 10% or so of the things that programmers are traditionally taught. These are the people who will insist that things like algorithms and data structures are meaningless for most programming tasks: as long as you remember all of the Javascript keywords, you've got as much education as you need. So if you or I come along and say "you'll be a better programmer in any language if you understand assembler", somebody else will invariably accuse you of perpetuating an elitist system that prioritizes meaningless theory over actual practice (i.e. "gatekeeping").
My former business partner is in the boat you describe. He learns the bare minimum needed to do the task at hand and seems pleased with that. He still has the joy of discovery, but it's more about what he can do with the tech than any appreciation of the formalism. He's happily working as an indie game coder, and while he doesn't exactly have FU money, he's for the most part cleared the first milestone of making rent for the past few years.

I'm in the opposite boat. I've learned so much about the theory of computing that I almost can't program anymore because most of what we do today feels like a waste of time to me. It's all convention and application now, with so many barriers to entry that I feel like 95% of what I do on any given day is setup. The dreams I had for how computing might evolve and lead us to the endgame of AGI feel more distant to me now than ever before. It will likely happen through the biggest players, using whatever proprietary tech they come up with, and leave garage hackers in the dust. I don't have a good feeling about whatever artificial agents arise from that.

So there is a lot of survivor bias in programming today. I feel like Obi-Wan Kenobi, beat down by the industry, marooned on some distant planet. Meanwhile the youth subscribe to empire quickly, because all they see is glorious rewards. Seeing haggard old graybeards like me fall from such early potential makes them rightfully skeptical of the gatekeeping you describe, the adherence to the old religion of computer science.

Or I'm just full of it. I don't even know anymore. I wish I was part of something bigger again.

Its a strange field that doesn't have clear boundaries and constantly changes.

I keep getting back in my thoughts to an old carpenter who was making a truly wonderful kitchen in a strange corner of an old building. Non of the walls, ceiling or floor around it were straight and it had tons of weird niches. I ask him how he could attack such a problem with such confidence. I would have to spend days pulling my hairs just making a drawing. He said, carpentry is roughly 300 methods of which you only need 120 to 140 to do any job. The rest is just tricks that you don't really need but they are impressive to those who know the problem.

I keep thinking of that in programing context for some reason. Nowadays you just order a plug and play kitchen that fits exactly, a novice can ikea it into place, everything works and it looks fantastic. Programming will get there one day. Until it does it will just look really weird to the old carpenter. So you grind the wood down to Particle board, you glue plastic on it that looks like wood then it gets moist and you replace the entire kitchen? .....!

Yup. I feels you.

A few years into my dev career, I adapted to make maintainable stuff. Because I learned that in 6 months I'd have to fix my own bugs.

Now it seems most code is throwaway, one-off, write only.

I haven't been able to "let it go". I still obsess over making my code correct. No one else seems to care. They get rewarded for fixing their own bugs ("velocity!") which I mostly avoid. So my KPIs look terrible by comparison.

Things get better. Or, they did for me when I retired earlier this year :-)
I think it's largely people talking past each other. One group claims that deeper understanding is useful and the other group says "no way, you don't need deeper understanding to get into (e.g., web) dev!". Being useful doesn't mean "necessary for an entry level position in the highest-level subdomains of computing".
> necessary for an entry level position

I still can't figure out how programming computers (the most complex task a human can undertake) managed to become singled out as the only profession in the history of humanity that is simultaneously assumed by so many to be something you need only a cursory understanding of to be proficient at.

It's entirely in the phrasing. "It would be beneficial to learn how the machine actually works" versus "you're not a real programmer unless ..."

Bootcamps demonstrate that not knowing assembly is not a barrier to earning a decent software engineer salary.

Maybe that is so, because teaching people assembly allows them to pull magic tricks on companies. An example I can think is Apple banning all dynamic code generation and execution on ios apps.
Search on twitter for "computer science" and "gatekeeping" and ask all those people, I dunno. I gave up trying to reason with unreasonable people a long time ago.
We also pogrammed the 8085 machine very recently(2015). It was a very weird feeling realising all the myriad of abstactions come down to basic load/store/arithmetic/logical instructions. Had fun implementing squaring a number whose result wouldn't fit in a register.

EDIT: It was 8085 kit, not 8086.

Astrophysicists consider any element heavier than Hydrogen or Helium a metal. :)

https://en.wikipedia.org/wiki/Metallicity

Hasn't always been semiconductors... or electronics at all, for that matter. That just happens to be the current majority physical implementation, where metal is a little scarcer than it used to be.
Individual transistors are made of doped silicon, but I think that integrated circuits still contain plenty of metal - the gates are connected by 'wires', after all.