[ my public key: https://keybase.io/rozzie; my proof: https://keybase.io/rozzie/sigs/Hsc0xK81xcGd6GBwDzJWMFUPWqqICZoa5sYvEJ6CA8A ]
- I began recruiting for what became Azure in Jan 2006. I was chief software architect / cto at the company. Amitabh Srivastava and the legendary Dave Cutler were the leads, with Dave focused on the hypervisor. (I'd met Dave in the 80's when he was at DEC and I was at DG.)
The project was in my team (CSA labs) but was cross-funded behind the scenes by Kevin Johnson, the president of Server & Tools. KJ & I did this because there was passive-aggressive resistance to a 'cloud first' design/architecture philosophy from within his org, where there was a deeply-rooted belief that enterprise servers and ops management tools would adequately scale-up.
KJ bought in and was all-in, as was the 'tools' part of his org (Soma & ScottGu). SteveB initially didn't quite know what to make of my desire and myriad efforts to fundamentally transform the company from packaged products toward services, and he had to cope with some of the wake I was leaving. It wasn't all smooth. But he believed in me and helped me to recruit internally, which was essential.
My explicit cross-funding agreement with KJ, my peer, was that when I decided it was the 'right time', I'd hand off my Azure org and it would be re-merged into S&T in more-or-less a 'reverse merger', with cloud leadership taking over server.
I launched Azure at PDC 2008 with what today we'd call lambda's (functions-as-a-service based on .net) & blobs & cloud database as the core services. Why no linux or windows VMs? They were absolutely part of day 1 plans, but a major political ploy from within KJ's team ('this will kill the server business') resulted in an active decision (mine) to defer until post-launch. It wasn't a technology issue, nor was it an OSS issue; the team believed in OSS & Linux. But shipping was top priority, and we shipped.
When I ultimately left the company in 2011, it was time to do the reverse merger that KJ and I had planned. A proven, super-talented manager from Bing that everyone loved, Satya, was chosen to lead the org as it was moved into S&T upon my departure. James Hamilton, the architect of Azure's relational DB, left for AWS. Ultimately, under Satya, ScottGU & co ended up re-plumbing much of the original code with a by-then-ready Windows hypervisor, VMs & Linux, and all that you see today. By then the org finally was aligned and 'believed', and SteveB was genuinely 'all in'.
Getting products from 0 to 1 is sometimes a challenging process involving incredible people and stamina from believers at every level. In this case I'd say it was worth the effort.
- Tangentially-related, it remains surprising that many U.S.-based developers I've spoken with fail to realize that they need to obtain an Export Control Classification (ECCN) from the US Dept of Commerce's Bureau of Industry and Security (BIS) before publishing their apps in the app store or otherwise making them available on the net. And then devs need to submit annual updates for their products.
Most will get a mass market exemption under 5D992, but a surprising number of modern applications making 'interesting' uses of crypto will need export licenses.
https://www.bis.doc.gov/index.php/encryption-and-export-admi...
- Thx for clearing the rights and for releasing, Scott. And of course thanks to Microsoft and IBM.
It would be fun at some point down the road to get some of the older code building and running again - particularly '84/'85-vintage Windows & Notes builds. Quite a lot of work, though, not just because of hardware but also likely because of toolchain gaps.
- At Software Arts I wrote or worked on the IL interpreter for the TRS 80 Model III, the DEC Rainbow, the Vector Graphic, the beginnings of the Apple Lisa port, as well as the IBM PC port. To put you into the state of mind at the time,
- in the pre-PC era, the microcomputer ecosystem was extremely fragmented in terms of architectures, CPUs, and OS's. 6502, z80, 68K, z8000, 8088. DOS, CPM, CPM/86, etc. Our publisher (Personal Software) wanted as much breadth of coverage, as you might imagine
- one strong positive benefit of porting from 6502 assembly to IL and using an interpreter was that it enabled the core code to remain the same while leaving the complex work of paging and/or memory mapping to the interpreter, enabling access to 'extended memory' without touching or needing to re-test the core VisiCalc code. Same goes for display architectures, printer support, file system I/O, etc.
- another strong benefit was the fact that, as the author alludes to, the company was trying to transition to being more than a one hit wonder by creating a symbolic equation solver app - TK!Solver - that shared the interpreter.
Of course, the unavoidable result is that the interpreter - without modern affordances such as JIT compilation - was far less snappy than native code. We optimized the hell out of it and it wasn't unusable, but it did feel laggy.
Fast forward to when I left SoftArts and went across the street to work for my friend Jon Sachs who had just co-founded Lotus with Mitch Kapor. Mitch & Jon bet 100% that the PC would reset the ecosystem, and that the diversity of microcomputers would vanish.
Jon single-handedly wrote 1-2-3 in hand-tuned assembly language. Yes, 1-2-3 was all about creating a killer app out of 1.spreadsheet+2.graphics+3.database. That was all Mitch. But, equally, a killer aspect of 1-2-3 was SPEED. It was mind-blowing. And this was all Jon. Jon's philosophy was that there is no 'killer feature' that was more important than speed.
When things are moving fast and the industry is taking shape, you make the best decisions you can given hunches about the opportunities you spot, and the lay of the technical and market landscape at that moment. You need to make many key technical and business decisions in almost an instant, and in many ways that determines your fate.
Even in retrospect, I think the IL port was the right decision by Dan & Bob given the microcomputing ecosystem at the time. But obviously Mitch & Jon also made the right decision for their own time - just a matter of months later. All of them changed the world.
- https://safecast.org/devices/ https://safecast.org/history-of-safecast/ https://safecast.org/about/
It’s quite a wonderful set of globally-distributed volunteers brought together by varying passions - from hardware hacking to citizen science.
Whether from fixed or mobile sensors, whether from radiation or air quality sensors, all data is CC0-licensed at birth and is freely available for download.
- Beyond being 60-bits, programming the 6400/6500/6600/6700 was interesting and memorable in other ways.
- Ones' complement (rather than two's complement) binary representation of integers, and thus the need to cope with "-0" in your code. Modern programmers are surprised that there was a day when "-1" had a different binary representation than today.
- The CPU/CPUs were not actually 'in charge' of the machine. There were ten 12-bit processors called PPU's (peripheral processing units) which did all I/O, and which had the unique capability of doing an "Exchange Jump" instruction to do a CPU task switch. In a sense, the CPUs were 'compute peripherals' to the PPUs.
- The architecture was fascinating in terms of memory hierarchy. The "centeral memory" used by the CPUs was augmented by a much larger "extended memory" (ECS - Extended Core Storage) with block transfer primitives. One could implement high-scale systems (such as the one I worked on - PLATO) that smoothly staged data between CM, ECS, and disk.
In those days, there was a necessarily-direct relationship between the machine language (the bit encoding of instructions for operations & registers) and the assembly language (COMPASS). As a developer it was incredibly enjoyable because, in Ellen Ullman's words, you felt very 'close to the machine'.
- "Now, no one bats an eye if you ship the most secure crypto you want."
The most surprising thing to me is that, in speaking in the past several years with younger entrepreneurs, they're not even aware of the obligation to file for an export license for any/all software containing crypto (such as that submitted to the App Store).
I've not yet seen a case in which a mass market exemption isn't quickly granted, but devs still need to file - and re-file annually.
- I use my HP-16C several times every week while debugging Notecard firmware. Yes, math is integrated into IAR EWARM and there's always Hex Calc on my iPhone. But there is something comforting about grabbing this same little artifact that has been on my desk since the days when I was debugging Lotus Notes using symdeb.
- Not unrelated, this is quite an amazing device - even before you consider its $9.95 price at Sparkfun.
https://usefulsensors.com/person-sensor/ https://usefulsensors.com/about/
- Tangentially related: if you're fascinated about how all of this vintage equipment used to work, and if you find yourself near downtown Seattle on a sunday with an hour or two to spare, I strongly encourage a visit to: https://www.telcomhistory.org/connections-museum-seattle/
It's an incredibly rare opportunity to see geek geezer volunteers keep this central office telephone switching equipment up and running, and they'll proudly show you how it all works. A combination of aging techs and students constantly maintain equipment ranging from crossbar switches to an ESS.
It's a labor of love, and you'll want to leave something in the tip jar just to say thanks.
- LTE feels as though it is going to be an exception to that rule. This is the dawn of eMTC lifecycle
- YMMV but our experience with Cat-M has been very good with regard to speed and general coverage. (Probably because it was just a tower software for LTE eNodes.) 300Kbps+ seems to be the norm.
- 30mm x 35mm, plugging into a standard M.2 Key E socket
- All of USB, I2C, low power UART (9600 fixed), and high speed USART.
They all equivalently are JSON request/response ports. I2c uses a simple serial-over-I2C protocol.
Most customers use the I2C or low power UART interfaces because the device only uses ~8uA when listening on those ports. (Our internal MCU can listen on those ports while in STOP2 mode.)
- Just so there's no confusion, you linked to the "NOTE-WBEX" which is europe-only. If you're interested in countries covered, it's best to look at "NOTE-NBGL": https://dev.blues.io/hardware/notecard-datasheet/note-nbgl-5...
- Truth in advertising: As stated in another response above, if you want to do a real computation you need to factor-in "session setup" overhead. If you config for TCP/IP (unencrypted) your session overhead is about 1kb. If you config for TLS, your session overhead is just under 4KB. Once the session starts, data transfer is super efficient - probably about 250-500 bytes for a half dozen or dozen notes of typical size. Session duration is typically 1-2 seconds.
The other secret of most IoT platforms is that their negotiated rates round sessions to 1KB boundaries. That's insane for IoT. For ours there is no rounding, and the 'practical' rounding is the 40-byte TCP/IP header.
- I was using Whispernet as an example of a great user experience; that's all.
There are no tricks and our prepaid/embedded pricing is real, and we will never sell anything for a loss. We're selling commercial IoT and our business must be sustainable. (Free tier of Notehub is an acquisition cost and that cost is extremely low.)
- Happy to comment. We've been working on this for several years now and we're super proud of what we see people building and deploying.
The question is a bit general, so let me just give you some related facts.
- Because more than half our customers use this in a battery-powered way (such as a tracker), the normal operating mode (json-configured) is "normally quiescent" (~8uA draw) with the modem powered off completely. You program the sync period and can also kick off syncs manually, for example if you sense an urgent condition.
- In this "periodic mode", syncs are usually take about 15 seconds to register, 1 or 2 seconds to sync, and then hanguup. If you configure for TLS it sends about 4KB for the TLS session setup, and if you don't care about on-wire encryption you can use straight TCP at about 1KB. A half dozen reasonably-sized JSON notes compresses to about 250-500 bytes on the wire.
- Many customers don't use it battery-powered - such as embedding it inside an air handler or generator, etc. When in this mode, you can configure (JSON) it to be connected in a "continuous" mode. Not much downside - just a 1 packet (40 byte TCP header + 1 byte) for a ping every 20m for robustness.
When in continuous mode you get "instant sync" upstream, and get a bonus feature: If you use an HTTPS (JSON) API to send an inbound message to the device, it syncs instantly to the device.
- Our packets are so tiny that nobody ever thinks about actual modem bandwidth. However, you'll notice it when you're using it for firmware update. (We support DFU of modem, of our firmware, and of your own host MCU's firmware.)
We have 2 primary SKUs for the product: our "Narrowband" SKUs based on BG95 which support three RATS: LTE Cat-M1 (~375Kbps), LTE Cat-NB1 (~64Kbps), and GSM (~100Kbps).
For $10 more you can buy our "Wideband" SKUs based on EG91 which supports LTE Cat-1 4G/LTE, 3G, and GSM. These go up to 10Mbps.
Hope you find this interesting.
Recently, my head spun around a bit when I saw an experiment done by my team at blues, and I realized it was time for me to dig a bit deeper. https://www.tjvantoll.com/2025/03/17/vibecoding/
And so, over the past few weeks I've done an interesting CEO vibe-coding experiment of my own, trying to test the limits and to see how close I could come to building something that could be regarded as 'ship quality'.
Did I succeed? You be the judge.
I didn't write a single line of code in this repo, but, as HN would expect, my instructions were voluminous and needed to be quite detailed. An interesting experience, nonetheless.