tag:blogger.com,1999:blog-14206071831175566702024-03-13T11:40:11.987-07:00A blog about various stuff.Unknownnoreply@blogger.comBlogger10125tag:blogger.com,1999:blog-1420607183117556670.post-74142298327604623072023-08-08T23:48:00.003-07:002023-08-08T23:52:38.246-07:00Sorry Nvidia, innovation in AI will be at the low end, not on giant GPU mainframes.<p> Innovation in computing has always been at the low end.</p><p></p><p>When people were able to get their own personal computers, that's when the revolution sparked.</p><p>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.</p><p>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.<br /></p><p>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.<br /></p><p>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. <br /></p><p>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. </p><p>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. <br /></p><p>The forces of open source will rally against Nvidia's attempt to make AI into a new mainframe era. <br /></p><p>It's happening now.<br /></p><p>Andrew Stuart</p><p>9 Aug 2023</p><p>andrew.stuart@supercoders.com.au</p><p><br /></p>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-1420607183117556670.post-16128732783160238142023-08-06T14:48:00.006-07:002023-08-06T15:15:33.391-07:00Where are all the exciting digital advertising screen applications?<p><span class="commtext c00"><b>Whenever I see a digital advertising screen, I want to interact with it. However I've never seen a single such digital advertising screen.<br /></b></span></p>Put a QR code on the screen, scan it from your phone and take control via your phone.<p><span class="commtext c00">Imagine passing by that giant screen at the airport, scanning the QR code on it and taking control!</span> <br /></p><p>Or that screen built in to the bus stop shelter.</p><p>Or those giant screens above the intersections in the city. <br /></p><p>Maybe Space Invaders.</p><p>Maybe some sort of UI that allows users to interact with the advertisement.</p><p>Maybe at an airport, scroll the ad to videos of different international destinations.</p><p>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.</p><p>Maybe something else innovative and entertaining.</p><p><b><i>Give people a reason to look at the screen and want to interact with it.</i></b></p><p>Instead of just "screen and ad", the least possible imaginative way of utilizing giant screen advertising. </p><p>Where are the cool and exciting interactive digital ad screen applications? <br /></p><p>The advertising industry really has no imagination. </p><p>andrew.stuart@supercoders.com.au</p><p>7 aug 2023<br /></p><p></p>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-1420607183117556670.post-45789552782166438592021-12-19T16:26:00.005-08:002021-12-19T16:35:11.666-08:00This is my Mum's 80th birthday present.<p><br /></p><span color="rgba(0, 0, 0, 0.9)" face="-apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif" style="background-color: white; caret-color: rgba(0, 0, 0, 0.9); font-size: 14px; text-size-adjust: auto; white-space: pre-wrap;"><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEigdAEi1rI5hUO8CqG0dAy0jYgBX4DePCa-DVSDhtXAQE1O4KeBJdPr0v7M887XEnaigkk-D9xio9j3KDQ26dz-UZNOdcwoL8lscWKNXsEIlkHFr4z260XNVOx-hlVF6Kcwa05WWJxxzHFt-A0tODbZc7boo8LT8AafuNFZJahhdQmdoTl1KX96rrtR=s800" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="623" data-original-width="800" height="326" src="https://blogger.googleusercontent.com/img/a/AVvXsEigdAEi1rI5hUO8CqG0dAy0jYgBX4DePCa-DVSDhtXAQE1O4KeBJdPr0v7M887XEnaigkk-D9xio9j3KDQ26dz-UZNOdcwoL8lscWKNXsEIlkHFr4z260XNVOx-hlVF6Kcwa05WWJxxzHFt-A0tODbZc7boo8LT8AafuNFZJahhdQmdoTl1KX96rrtR=w419-h326" width="419" /></a></div><br /><span color="rgba(0, 0, 0, 0.9)" face="-apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif" style="background-color: white; caret-color: rgba(0, 0, 0, 0.9); font-size: 14px; text-size-adjust: auto; white-space: pre-wrap;"><br /></span></div>
</span><span color="rgba(0, 0, 0, 0.9)" face="-apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif" style="background-color: white; caret-color: rgba(0, 0, 0, 0.9); text-size-adjust: auto; white-space: pre-wrap;"><span style="font-size: medium;">20 Dec 2021 andrew.stuart@supercoders.com.au</span></span><div><span color="rgba(0, 0, 0, 0.9)" face="-apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif" style="background-color: white; caret-color: rgba(0, 0, 0, 0.9); text-size-adjust: auto; white-space: pre-wrap;"><span style="font-size: medium;"><br /></span></span><div><span color="rgba(0, 0, 0, 0.9)" face="-apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif" style="background-color: white; caret-color: rgba(0, 0, 0, 0.9); text-size-adjust: auto; white-space: pre-wrap;"><span style="font-size: medium;">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.
<br /></span></span></div><div><span color="rgba(0, 0, 0, 0.9)" face="-apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif" style="background-color: white; caret-color: rgba(0, 0, 0, 0.9); text-size-adjust: auto; white-space: pre-wrap;"><span style="font-size: medium;">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?
<br /></span></span></div></div>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-1420607183117556670.post-84414270244087530892020-12-13T13:55:00.004-08:002020-12-13T14:00:17.885-08:00Here's how to recruit junior/graduate software developers ..... your team's future superstars!<p><span style="font-size: large;"> </span></p><p><span style="font-size: large;"><b>Recruiting junior developers is NOT the same as recruiting senior developers - a different approach is required.</b></span></p><p><span style="font-size: large;">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 <i><u>change your process for assessing juniors</u></i>.</span></p><p><span style="font-size: large;">Senior developers are often assessed <b>according to what they know,</b> and are typically probed with questions to find to their level of expertise, i.e.</span></p><ol><li><span style="font-size: large;">What does <b>this</b> do, in <b>that</b> programming language?</span></li><li><span style="font-size: large;">Explain <b>some deep detail to me</b> about <b>some programming technology</b>.</span></li><li><span style="font-size: large;">How do you do (some professional software development process, like testing)?</span></li></ol><p><span style="font-size: large;">And of course when you interview senior developers, the <b>questions relate to your company technology stack</b>! Such as JavaScript or C# or Java. Makes sense, right?</span></p><p><span style="font-size: large;">The thing that mostly matters with senior developers is their depth of technical knowledge.</span></p><p><span style="font-size: large;">BUT THIS APPROACH IS WRONG FOR JUNIORS/GRADUATES! <i><u>Junior developers are not senior developers with less years experience</u>.</i></span></p><h3><span style="font-size: large;"><b>So how to assess juniors/graduate developers?</b></span></h3><p><span style="font-size: large;">When you hire a junior developer,<b> DO LOOK mostly looking for *personal traits*</b>. 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.</span></p><p><span style="font-size: large;">When you hire a junior developer, <b>DO NOT look for how well they know your company technology stack - it does not matter!</b></span></p><p><span style="font-size: large;">Here’s what to look for:</span></p><h2><span style="font-size: large;"><b>The “whole person”.</b></span></h2><p><span style="font-size: large;">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? <i>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</i>.</span></p><h2><span style="font-size: large;"><b>Can they communicate well? </b></span></h2><p><span style="font-size: large;">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.</span></p><p><span style="font-size: large;">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.</span></p><h2><span style="font-size: large;"><b>Do they work hard to learn, is there evidence?</b></span></h2><p><span style="font-size: large;">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”.</span></p><h2><span style="font-size: large;"><b>Have they *done anything*?</b></span></h2><p><span style="font-size: large;">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.</span></p><h2><span style="font-size: large;"><b>Assessing specific technology knowledge. </b></span></h2><p><span style="font-size: large;">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++. <b>On the other hand, it is necessary to do some assessment of what they know technically</b>. Do this by <b>asking them to explain what they already know</b>, <i><u>NOT by probing them to see if they know what you think they should know</u></i>.</span></p><p><span style="font-size: large;">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.</span></p><h2><span style="font-size: large;"><b>The key to assessing junior developers, more than anything else - can they engage in a deep back and forth technical discussion?</b></span></h2><p><span style="font-size: large;">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 <b>things that they already know, the topic should NOT be the technologies of your company technology stack</b>. 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.</span></p><p><span style="font-size: large;"><b>Finally.</b></span></p><p><span style="font-size: large;">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.</span></p><p><span style="font-size: large;">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</span></p>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-1420607183117556670.post-30983817762252392262020-10-20T16:58:00.004-07:002020-10-20T17:01:53.138-07:00You should pay your first developer TWICE the market rate.<p><span style="font-size: medium;"> You've founded your company.</span></p><p><span style="font-size: medium;">You've got the investor cash.</span></p><p><span style="font-size: medium;">Now you need to start building that application that's going to make you a bajillionaire.</span></p><p><span style="font-size: medium;"><b>But first you need to hire developers to do the building.</b></span></p><p><span style="font-size: medium;">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.</span></p><p><span style="font-size: medium;">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.</span></p><p><span style="font-size: medium;"><b>"$240K!!! Senior JavaScript ReactJS/nodejs developer wanted."</b><br /></span></p><p><span style="font-size: medium;">And then make it clear in the first sentences of the job ad:</span></p><p><span style="font-size: medium;"><b><i>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></b></span></p><p><span style="font-size: medium;">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).</span></p><p><span style="font-size: medium;">It's a different story if the company is founded by software developers - this advice is for the non-technical founder. </span></p><p><span style="font-size: medium;">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.</span></p><p><br /></p><p><br /></p>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-1420607183117556670.post-68071969389491746222018-08-29T20:50:00.001-07:002018-08-31T04:45:29.211-07:00What I could not undiscover about Unikernels.<span style="font-size: large;">Unikernels </span><span style="font-size: large;">http://unikernel.org/ </span><span style="font-size: large;">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".</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">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.</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">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.</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">The minimal nature of Unikernels is immensely appealing.... tiny operating systems occupying only a handful of megabytes, more secure than traditional operating systems.</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">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.</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">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.</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">I invested years building <a href="http://www.bootrino.com/">http://www.bootrino.com</a> - 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.</span><br />
<span style="font-size: large;"><br /></span>
<b><span style="font-size: large;">Why didn't Unikernels catch on?</span></b><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">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.</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">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.</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;"><b>The flaws with the Unikernel concepts.</b></span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">While I was building bootrino I discovered some things about Unikernels that were hard to undiscover.</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">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 <a href="https://www.yoctoproject.org/">Yocto Linux</a> 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.</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">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.</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">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.</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">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.</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">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.</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">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. </span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">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. </span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">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. <b>What's the real difference between embedded Linux systems and Unikernels? Not much.</b> 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.</span><br />
<span style="font-size: large;"><br /></span><span style="font-size: large;">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. </span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">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.</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;"></span><br />
<span style="font-size: large;">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</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">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.......</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">Andrew Stuart</span><br />
<span style="font-size: large;">andrew.stuart@supercoders.com.au</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;"><br /></span>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-1420607183117556670.post-37433018965621830862015-05-25T16:26:00.003-07:002015-05-25T16:29:43.368-07:00Why do G-rated movies need to frighten the heck out of children?<span style="font-family: Arial, Helvetica, sans-serif;">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?</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">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.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">Many of these scenes are very, very scary. EVERY Pixar G-rated movie includes scenes that are terrifying to children.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">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". </span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">It's almost like Hollywood feels that movies just won't sell unless it can scare children to the bottom of their little souls.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">https://www.youtube.com/watch?v=hHs_KhePqEM</span>
<span style="font-family: Arial, Helvetica, sans-serif;">https://www.youtube.com/watch?v=3MIX33DO16c</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-1420607183117556670.post-91027114053724914322015-05-20T15:22:00.000-07:002015-05-20T15:34:05.012-07:00For Linux, your core skill is navigating broken stuff, which is everything.<span style="font-family: Arial, Helvetica, sans-serif;">In the Linux world, as others before have said, "everything is broken".</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">If you are a developer or sysadmin doing anything of any significance then your ability to reach your goal is defined by how quickly and easily you can recognise and find workarounds for broken stuff.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">Actually, not everything is broken, but so much <b>is</b> broken that it feel like everything. It's the broken stuff that will take your time. The stuff that isn't broken will be easy and will happen quickly.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">So the faster you can jump through Linux's never ending minefield, hot coals, machine gun nests and shards of glass, the faster you can get productive work done.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">Wanna be productive? Get good at seeing and sidestepping and fixing broken stuff.</span>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-1420607183117556670.post-71736853391607203782015-05-10T18:09:00.003-07:002015-08-05T06:20:02.338-07:00An incredibly brief introduction to JavaScript in 2015 for experienced developers.<span style="font-family: Arial, Helvetica, sans-serif; font-size: large;">Over the years I've done bits and pieces of web and JavaScript development. For one of my current projects however I need to get some serious stuff done, so I knew I had to come up to speed on the state of the art in browser development. I chose to target react.js as it seems to me to promise the simplest mental model which is what I need because I am time poor.</span><br />
<span style="font-size: large;"><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">And things have changed ALOT in JavaScript development since the old days. It took lots of searching and reading to make sense of the current landscape so I will now save you days of effort and summarise what you need to know:</span></span><br />
<span style="font-size: large;"><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">1: Programming a web browser directly with JavaScript is dead. In the same way that few people now programs CPUs directly with assembly language. When you are writing JavaScript it now gets compiled (actually transpiled) to JavaScript. Forget writing code directly for execution in a browser, those days are gone, move on.</span></span><br />
<span style="font-size: large;"><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">2: There are a number of JavaScript variant languages for you to choose to program in. The mainstream choice is now ECMAScript2015, also known as ES6. </span></span><span style="font-family: Arial, Helvetica, sans-serif; font-size: large;">ECMAScript2015 /</span><span style="font-family: Arial, Helvetica, sans-serif; font-size: large;">ES6 turns JavaScript programming into something sane, for lots of reasons but primarily because it implements a module/import system. </span><br />
<span style="font-size: large;"><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">3: Your development workflow involves writing ES6 code then shoving it through a series of very useful tools that carry out transformations of your code. The main transformation is the transpiling (converting your ES6 code to plain old JavaScript e.g tools like 'babel'). Other transformations include minifying (compressing/reducing the size of the output, e.g. 'uglify'), uglifying or mangling (making your code to make it harder for others to make sense of - 'uglify' does this too), bundling (combining multiple JavaScript files into a single file to reduce load times e.g. tools like browserify), translation (if you are using reactjs then you can write JSX which is like including XML style HTML in your JavaScript, this also needs to be translated as part of the transpile process). There's probably plenty of others but these are the main ones I have encountered.</span></span><br />
<span style="font-size: large;"><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">4: Your development workflow will use some sort of tool to tie together all the transpiling and transformation tools. If you know what "make" is then you understand the concept. If not, well it's just a utility of some form that has a few different configurations of the tools mentioned above, each configuration useful for pushing your code through the various utilities until a final JavaScript file pops out of the end. "gulp" is the tool that people seem to be using alot at the moment for this purpose. </span></span><br />
<span style="font-size: large;"><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">5: You will need to learn how to drive the Google Chrome debugger or spend a very long time in debugging hell. Go to YouTube, search for "JavaScript Debugging Chrome" and spend a few hours watching. Time well spent. The key thing you need to know is that JavaScript "source maps" will allow you to debug your code in the browser even after shoving it through the various transformation tools.</span></span><br />
<span style="font-size: large;"><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">6: You will want to make use of various JavaScript libraries. This is done through the npm package management system. Invest some time in learning the basics of this. The key thing you need to know is that you say "npm install <packagename>" which installs packages under a "node_modules" directory in your current directory, which is where you compile from. In your code you will use "import" and "require" to load in the packages. </span></span><br />
<span style="font-size: large;"><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">Hopefully that lightning introductions has helped you find your feet.</span></span><br />
<span style="font-size: large;"><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">I'm learning all this. Have I got it wrong, please let me know.</span></span><br />
<span style="font-family: Arial, Helvetica, sans-serif; font-size: large;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-1420607183117556670.post-13037626561089764252014-12-05T17:02:00.001-08:002014-12-05T17:02:40.491-08:00If the product you are developing is not viral, maybe it belongs in a marketplace.If your product has no viral mechanism, then maybe it belongs in a marketplace. So before you start developing, know which marketplace your product is suited to. Don't get to the end of the development process (as I do) and then wonder how to get it in front of buyers. Understand marketplaces in advance.Unknownnoreply@blogger.com