Sorry Nvidia, innovation in AI will be at the low end, not on giant GPU mainframes.

 Innovation in computing has always been at the low end.

When people were able to get their own personal computers, that's when the revolution sparked.

Nvidia, in a weird reversal of the norms of computing, is pushing AI into "GPU Mainframes" like the Nvidia A100 - super giant, super powerful, super expensive AI/GPU number crunchers.

That's the playfield where Nvidia CEO Jensen Huang wants the AI revolution to play out - in the cloud, in the hands of the high priests of cloud computing at Amazon, Azure and Google, using Nvidia's most ridiculously expensive hardware.

But I have bad news for Jensen - software developers hate that.  Consumers want to do it themselves, they want it to be cheap and they want to be in control.  The industry abandoned the mainframe, and no matter how much Nvidia wants that era back, its finished.

What that means is that the AI revolution is not going to play out in the cloud, where GPUs are expensive and hard to get access to and controlled by the high priests, who decide who is allowed mainframe computing time. 

Nope, the AI revolution will be on retail gaming spec GPUs from AMD and Intel. In fact Nvidia may not be part of this low end AI party, because Nvidia imposes artificial constraints on its drivers so you CAN'T do the AI you want to on their retail gaming GPUs.  

Software developers will develop AI for what they can get their hands on.  They'll smash and squeeze the software till it fits and works on what's available.  They'll find innovative ways to connect multiple gaming GPUs together.

The forces of open source will rally against Nvidia's attempt to make AI into a new mainframe era.

It's happening now.

Andrew Stuart

9 Aug 2023

andrew.stuart@supercoders.com.au

Where are all the exciting digital advertising screen applications?

Whenever I see a digital advertising screen, I want to interact with it.  However I've never seen a single such digital advertising screen.

Put a QR code on the screen, scan it from your phone and take control via your phone.

Imagine passing by that giant screen at the airport, scanning the QR code on it and taking control!

Or that screen built in to the bus stop shelter.

Or those giant screens above the intersections in the city.

Maybe Space Invaders.

Maybe some sort of UI that allows users to interact with the advertisement.

Maybe at an airport, scroll the ad to videos of different international destinations.

Maybe build some sort of multi player game in which multiple random passers by can scan the QR code and join into a game together.

Maybe something else innovative and entertaining.

Give people a reason to look at the screen and want to interact with it.

Instead of just "screen and ad", the least possible imaginative way of utilizing giant screen advertising. 

Where are the cool and exciting interactive digital ad screen applications?

The advertising industry really has no imagination. 

andrew.stuart@supercoders.com.au

7 aug 2023

This is my Mum's 80th birthday present.

20 Dec 2021 andrew.stuart@supercoders.com.au

It's a rotary phone from the 1970's. This is the sort of phone we had in the house when I was a kid. For Mum's birthday, I bought this old phone from a second hand store. I pulled it apart and installed a little computer into the phone. I connected the rotary dial to the computer. I connected the speaker in the handset to the computer. I connected the hangup/pickup switch to the computer. I set up a dedicated phone number with voicemail, which emails every voicemail to me. I then asked all Mum's friends and family to leave a special birthday message for her on that phone number. I converted these messages to MP3 files. I uploaded all the MP3 files to the computer in the phone. I then wrote some code in Python which plays a dial tone when the handset is picked up. The Python code listens to the rotary dialler. When the a number is dialled on the rotary phone, the Python code plays back one of the birthday messages. There were over 60 messages, which I assigned to phone numbers 100 to 160. I then ran a USB power cord out of the back of the phone and into the computer inside.

I wanted to add in some of the dial up services from the 1970's like "dial a story", "dial a horoscope", "dial a poem", also some crazy AI generated stories about our family members, but I ran out of time. I put it in a box and mailed it to Mum. This all took ALOT of time but once I get an idea like this I can't get it out of my head until it's done, and Mum's worth it eh?

Here's how to recruit junior/graduate software developers ..... your team's future superstars!

 

Recruiting junior developers is NOT the same as recruiting senior developers - a different approach is required.

Junior/graduate software developers are NOT senior developers with fewer years experience. And yet, many companies interview and assess juniors/graduates in pretty much the same way as they interview senior developers. You need to change your process for assessing juniors.

Senior developers are often assessed according to what they know, and are typically probed with questions to find to their level of expertise, i.e.

1. What does this do, in that programming language?
2. Explain some deep detail to me about some programming technology.
3. How do you do (some professional software development process, like testing)?

And of course when you interview senior developers, the questions relate to your company technology stack! Such as JavaScript or C# or Java. Makes sense, right?

The thing that mostly matters with senior developers is their depth of technical knowledge.

BUT THIS APPROACH IS WRONG FOR JUNIORS/GRADUATES! Junior developers are not senior developers with less years experience.

So how to assess juniors/graduate developers?

When you hire a junior developer, DO LOOK mostly looking for *personal traits*. Hire juniors for the person, the attitude, the energy, the enthusiasm, the motivation, the evidence that they have already built something. Then, when they have come up to speed - you’ll have all those personal characteristics, plus they will have learned your technology environment. You'll have a superstar.

When you hire a junior developer, DO NOT look for how well they know your company technology stack - it does not matter!

Here’s what to look for:

The “whole person”.

When you read their resume and talk to them, what do you see? Do they seem to be someone energetic, enthusiastic, smart, motivated? How much do they want this job you have on offer? This person - the whole person - is who you will be working with for years to come - look at the big picture of who they are as a person.

Can they communicate well? 

Can they discuss *their own* software projects in depth, can they explain the technical details *not in answer to your technical questions*, but instead ask them to explain in depth their favorite software projects that they have already built.

This is a critically important point ...... the context of your assessment should be what the candidate has done already, NOT your technology stack. It's about THEM, not about YOU. If you assess them based on how well they know your company technology stack you'll miss out on lots of great people.

Do they work hard to learn, is there evidence?

Is this someone who works hard to learn, is this someone who *chooses* to write code? Can you see that in their resume? Ask them the straight question “tell me about how much you choose to code and when and what you write”.

Have they *done anything*?

What have they *done* already? Have they built projects? Did they manage to get anything complete? Building a software project to completion is a huge challenge and take much effort and learning. Make sure you give credit for getting something built. You should be impressed if a junior managed to get something built. And if they built something end to end and brought it to market somehow then be doubly impressed..... don't just ignore this, it indicates ability to plan and show they have the drive to think through and follow through lots of small details.

Assessing specific technology knowledge.

I’ll honestly say that I think it’s close to irrelevant what specific programming syntax they know and what technical questions they can answer during an interview. Syntax and programming can be learned - as software developers we have spent our entire careers learning. It’s just not important if a junior knows some specific thing about JavaScript or C++. On the other hand, it is necessary to do some assessment of what they know technically. Do this by asking them to explain what they already know, NOT by probing them to see if they know what you think they should know.

You'll find something odd when you probe the specific technical skills/programming knowledge of juniors - they'll surprise you with how well they know certain specific technical facts, then they'll shake your faith when they seem to completely misunderstand other things. Don't mark them down for that misunderstanding .... it's because they lack experience, that's all.

The key to assessing junior developers, more than anything else - can they engage in a deep back and forth technical discussion?

The foundation of all team based software development is discussion. You NEED your team members to be able to carry out deep back and forth technical discussion. I'll emphasise again the topic should be things that they already know, the topic should NOT be the technologies of your company technology stack. Ask about what is their favourite software they have written - the software they are most proud of writing, ask more about it, ask more about it again, get curious about their software, what problems did they hit, what went well, what did not go well, what did they learn, what would they do differently if they built it again, why did they choose those technologies, what was their role in the project? Ask what technologies they find interesting, what has caught their attention? What would they like to learn? Why do they like that technology etc etc etc. Try to get into a deep, interesting, back and forth discussion about technology..... that's only going to happen if it is about stuff they have built or are interested in.

Finally.

The single thing to remember ….. junior developers are NOT senior developers with fewer years experience. If you assess them the same way then you’ll miss out on really great future team members.

And of course I am both technical recruiter and developer. Contact me if you want me to help you find great people andrew.stuart@supercoders.com.au

You should pay your first developer TWICE the market rate.

 You've founded your company.

You've got the investor cash.

Now you need to start building that application that's going to make you a bajillionaire.

But first you need to hire developers to do the building.

I'm going to put it out there: you should get a senior developer / senior software engineer, and you should pay them TWICE the market.

So if market rate in your city is $120K, then place ads on the job boards and everywhere you can, stating up front in the job title $240K.

"$240K!!! Senior JavaScript ReactJS/nodejs developer wanted."

And then make it clear in the first sentences of the job ad:

We are a startup company with the funding to build the first version of our software.  We'll be building it in <insert technology choices here>.  We are looking for the best of the best senior software engineers and we will pay TWICE the market rate to get that person.  Later employees will be paid well, but this offer we will make only to our first engineer(s) because it's so important.

I've seen many startup companies go about their first hires in a very normal way..... or even worse, they hire junior developers (which I should caveat is a fine strategy is you don't have money).

It's a different story if the company is founded by software developers - this advice is for the non-technical founder.

Of course just because you are paying double market rate doesn't necessarily get you an amazing person - but it gives you a very good shot at shaking that person out of the market.

What I could not undiscover about Unikernels.

Unikernels http://unikernel.org/ have been around for a while but remain a relatively unknown technology. The core idea of a Unikernel is that it is a specialised operating system that throws away pretty much everything except network and disk drivers and application code, making for a tiny custom operating system that is usually single purpose, and typically claim to be more secure and efficient than traditional operating systems because they have disposed of all the unneeded code and in doing so, also reduced the Unikernels "attack surface".

Let's be clear about one thing - my view of Unikernels is oriented only toward my personal use case for them - that's the context of this post... and there are use cases for Unikernels that do not match my use cases.... I'm just saying so this isn't seen as a criticism of Unikernels, it's just the telling of my journey on that path.

I discovered Unikernels several years ago and took a particular interest in the Rump Kernel http://rumpkernel.org/ which is essentially NetBSD stripped down to little more than the network drivers, the disk drivers and your application code.

The minimal nature of Unikernels is immensely appealing.... tiny operating systems occupying only a handful of megabytes, more secure than traditional operating systems.

I thought I'd arrived early at a technology that was going to explode with popularity because Unikernels made so much damn sense...... security is a big deal and Unikernels were exceptionally secure because it's just an application, there's really nothing you can log in to on a Unikernel.  Contrast this with Linux where most machines are ready and waiting for users to log in, and hackers, once they get access can cause untold damage.

Being first to a new technology that explodes with growth is potentially a big opportunity, so I bet big on Unikernels.  There was work to be done with Unikernels because they were very complex to build and configure, and when I got on board they were not running at all on the cloud platforms.

I invested years building http://www.bootrino.com - software to make it easy to load and run Unikernels on all the major cloud platforms.  That was the gap I saw - making the complex Unikernel technology easy to run in the cloud.  I got my software built and it was fun and I learned a huge amount along the way, but Unikernels didn't explode with popularity, and although the project is still up and running, effectively it is abandoned because it meets no driving market need.

Why didn't Unikernels catch on?

Mainly because of Docker and serverless computing.  Serverless computing is a good enough solution for improving security, and Docker's lightweight virtualisation were two technologies that filled the market space that I thought Unikernels were going to occupy.  I'd had some experience with Docker and found it to be complex and unwieldy and it seemed likely people would gravitate to the better Unikernel technology once they discovered it.  When serverless hit the scene it was clear this wasn't going away any time soon, and it was also clear that serverless had taken some of the heat out of the application security issue - want a more secure application? Just run it as serverless.  You can't log in to a Unikernel, but you can't log in to a serverless function either. In the time it took me to build bootrino, Docker took over the world.

Unikernels had also been attacked as being "undebuggable" and "unfit for production".  I thought these claims were of no real value and put forward by people who had invested alot in backing the competing container technology.  Nevertheless the criticism seemed to get alot of traction with detractors of the Unikernel concept but it was never a criticism I cared much about - being "undebuggable" was never something that I encountered as a problem.

The flaws with the Unikernel concepts.

While I was building bootrino I discovered some things about Unikernels that were hard to undiscover.

One thing I learned was that sure - Unikernels are extremely minimal, and have no user login system, making them extremely secure, BUT Linux can be built that way too.  Embedded Linux systems such as Yocto Linux https://www.yoctoproject.org allow you to build tiny operating systems that consist only of a kernel plus the application code, occupying only a handful of megabytes.  Hey- that looks alot like a Unikernel!  Purists might object and say they are worlds apart because a Unikernel has a flat address space or some other distinction but I don't care about that stuff.... from a practical perspective - for the factors that I cared about - a stripped back Yocto Linux system is largely the same as a Unikernel.

The next thing I discovered that was hard to ignore was the symmetric multiprocessing story - Unikernels don't have such a story.  They are inherently single core.  That's a big problem in todays multicore world, and whilst there are ways around it by running many parallel single core Unikernels, it became clear to me that in fact the Linux kernel is a really good thing - and lot's of good stuff like handling SMP.  And as a result of my research I discovered also that the Linux kernel can be only a handful of megabytes anyway.  Taking full advantage of multi processors is not something that should be the responsibility of an application - it's a specialised and very tricky thing to get right, and its probably best done by some other bit of software - what should we call that?  Let's call it a kernel.  So what's with the Unikernels obsession with getting rid of the kernel?  There's not alot to be gained from having no kernel, and there is alot to be lost.  Hmmm.

Along the way I discovered you could do all sorts of tricky stuff like building Linux operating systems to run purely from RAM - such as Alpine Linux and TinyCore Linux do.  Again started to become even more blurry to me what the compelling advantage was of a Unikernel over a Run-From-RAM Linux operating system.

And finally the thing that I just couldn't ignore was that Linux let you configure it into very small and secure configurations with full SMP support AND you could run ANY existing Linux languages or applications on those tiny systems.  Unikernels generally seemed to need special builds and toolchains and configuration systems and recompilations to get them to run applications.  This was a huge advantage for Linux in a tiny configuration versus Unikernels.

I spent alot of time getting tiny operating systems to boot on the major cloud computing platforms. One of the times that most influenced my thinking about Unikernels was when I was trying to get MirageOS https://mirage.io - one of the leading Unikernel implementations - working on Amazon, Google and Digital Ocean. MirageOS is interesting in that you can compile the same MirageOS program into either a Unikernel, or into a Linux binary. I got to the point that I had the same MirageOS compiled application running on Amazon, Google and Digital Ocean under Linux, and I also had it running as a Unikernel successfully on Google Compute Engine - it did not work as a Unikernel on Amazon and Digital Ocean.  This was a key moment.  I sat there thinking OK - the very same MirageOS code works well on all three cloud platforms, and works fine Google as a Unikernel, but not the other two.  And I thought "Unikernel or Linux - it's exactly the same practical outcome".  The Linux version was running with nothing more than the MirageOS application binary, a Linux kernel of a handful of megabytes plus a few extra libraries - incredibly minimal.  That moment was a turning point, and it became very hard to see Unikernels as having substantial benefit over Linux at that point. In fact Linux had made it easier and more practical to implement MirageOS due to its better driver support. The only perceptible difference was the MirageOS/Linux implementation was 10 - 15 megabytes larger, which I didn't care about. I wondered then if all this Unikernel effort, and all the associated configuration, programming and loss of SMP, was about trying to save the space taken by 15 megabytes of Linux kernel? Cause the fact is, you can run your system as nothing more than a Linux kernel, plus your application and library code and absolutely nothing more, if you can be bothered configuring it that way.

No doubt unikernel purists will point out that there is a big difference between the definition of a unikernel versus a minimally configured Linux system such as Yocto Linux or Alpine or TinyCore.  Or perhaps they might point out that Unikernels can be only a handful of kilobytes and can boot in milliseconds.  I respect those things but my personal interests never needed those things. I was interested in practical outcomes for my personal use cases and less interested in purist definitions.  

I had come to see that it was possible to build very very small Linux systems, compatible with all Linux software, with all the security advantages of Unikernels, but with the benefit of symmetric multiprocessing and all the Linux driver support and community support.  

In practical terms I'd discovered, and could not undiscover, that for my personal interests and my personal use cases - anything that Unikernels can do, Linux can do better.  What's the real difference between embedded Linux systems and Unikernels?  Not much.  And besides, none of it really mattered anyway because the market wasn't beating a door down for this technology in the way it was flooding toward Docker and serverless. To put it a little brutally but factually - (almost) no one cares about Unikernels because there's no compelling market need.  Technologies that the market really needs get ripped out of your hands and used - to butcher the words of Marc Andressen. Unikernels do not have product/market fit.

And speaking of zero product/market fit - I'm proud of http://www.bootrino.com - the system I built for booting Run-From-RAM operating systems in the cloud, and I have immense respect for the incredible intellect and capability of every person in the Unikernel community - all infinitely smarter and better programmers than me - I was after all just a user of the technology, not one of the heroic individuals building the Unikernel technology - but in the end I just couldn't undiscover that Linux makes a better Unikernel-like OS than Unikernels do. 

The core point of this blog post being that Unikernels have a place in the world, but maybe not for running general purpose applications. Unikernels shine where millisecond boot times count and where you want to squeeze out every single possible instruction and run everything in ring 0.


If you are wanting to run general purpose applications with Unikernel-like minimalism and in Unikernel-like isolation then perhaps consider something like Yocto Linux or Alpine Linux running from RAM or TinyCore Linux in Run-From-RAM mode, and configure out the user login system

I had bet on the horse that wasn't the winner, I'd invested years of work into it, which I don't regret and had alot of fun with.  Off to start the next thing.......

Andrew Stuart
andrew.stuart@supercoders.com.au

Why do G-rated movies need to frighten the heck out of children?

My little boy has recently become old enough to enjoy going to the movies. What could be better than taking your kids to the movies on a Saturday afternoon?

But I've found that many, if not most, supposedly G-rated movies almost always contain frankly absolutely terrifying scenes that are often quite extended.  My boy jumps off his seat and hides and doesn't watch.

Many of these scenes are very, very scary. EVERY Pixar G-rated movie includes scenes that are terrifying to children.

But why? Why does Hollywood feel that every movie, even for tiny children, has to include deeply frightening scenes? I don't understand. It seems like the accepted wisdom is that "to frighten is to entertain".  

It's almost like Hollywood feels that movies just won't sell unless it can scare children to the bottom of their little souls.

https://www.youtube.com/watch?v=hHs_KhePqEM https://www.youtube.com/watch?v=3MIX33DO16c