Let's say one day you are casually browsing the logs of your giant Kubernetes cluster. You spot this log message: "npm update check failed". Hmm. Fortunately you have an egress firewall enabled, blocking all outbound traffic other than to your well-known API's, so you know why it failed. You now worry that maybe some of your projects are able to auto-update because it was difficult or impossible to fence them off.

Why would you want a container updating within itself? You rebuild them once a week in your CI, and deploy those tested, scanned updates. Here you are live-importing the risk we talked about in the ESLint debacle, meaning that someone in the universe might have a password they use on more than one site, it gets compromised, and an attacker pushes new code to their repo. And then boom, you'd install it without knowing.

As a backup for your 'egress firewall' you have also made all the rootfs read-only in your containers, mitigating the possibility of new installs like this. But, most containers have to have some writeable volume somewhere (even if only for the environment-variable-to-/etc/foo.conf-dance on startup).

Here the solution is a magic, 'lightly documented' environment variable NO_UPDATE_NOTIFIER. But...

The code behind this (for nodejs) is here. You can see it would spawn out to the shell. It doesn't do this check for a while (a day?) after you startup, so you might be lulled into a false sense of security. And it would be hard to construct a generic test to check for this behaviour. So yeah, the best seat-belts are the egress firewall, strict as strict can be, and a read-only rootfs.

Earlier I wrote about cryptokitties. The concept is you design a virtual 'tamagotchi-like' cat and then try to sell it to suckers customers via Eth. Looking back in on them it seems that they are somehow anti-inflationary. The selling (well asking!) price of a cryptocat has gone up by about the same amount (expressed in fiat currency) has gone down. In other words, you would have done better to convert $ to Eth to CryptoCat than to HODL.

Now, looking at our reference-crypto-kitty (swampgreen) we find that there has been some devaluation. I mean now that is a used, older cat, so that is to be expected. But the 'fresh' ones are now asking about the same (~$14), which is about 10x the Eth.

Colour me... underwhelmed.

Recently I bought the TS80. I was sad to find that it does not do USB-C PD, only the proprietary Qualcomm QuickCharge 3.0. I was even sadder to find that, although the OLED and software will work @ 5V, it will cowardly refuse to light the engine and make heat. I was even sadder to find out that the 'Qualcomm Quick Charge 3.0' powerbank I bought, well, the iron didn't like it. It did work plugged into the QC3.0 charger, but sometimes you want to be portable!

But, given that the iron runs firmware, it must be hackable, right?

If you hold the button down as you plug it in, it goes into DFU mode so that is promising.

More promising, there is an open issue 'Add TS80 support' on the TS100 repo on github.

Even more promising, well, it builds, and, installs, and, runs!

And, great success, this sw has a mode (by default) which allows it to start the heater in 5V. This in turn tricks the powerbank into staying alive long enough to recognise the QC3.0 signalling, and in turn, deliver  MOAR VOLTS!. Turns out it will deliver 11V @ 2A, so ~22W.

Now, you might wonder why I have that 'Rogers' USB flash plugged in. Well, the power bank goes to sleep when there is no load. So as soon as the iron hits temperature (about 20seconds), the power bank switches off. Boo. So I needed a dummy load, and, well, no one is ever going to use this 20MB flash for anything, it may as well make a bit of heat and trick this power bank.

So it seems that the software was able to work around the bug, hack successful!

As for the average consumer, well, we would all be forgiven for thinking that something w/ the only writing on it being 'Qualcomm 3.0 Quick Charge' would do QC3.0 properly. Its a bit unfair to think that a consumer would build new firmware for a widget from an unreleased branch in github of an open-source repo of their soldering iron.

Its a brave new world of continuous and agile!

So I decided to run a bit of a test for range. You see, the e-bike has a simple '5-bar' battery meter, not really letting you know how much farther you could go before you are doing all the work. Unlike a car, the downside of running out of juice is not as terrible, you just have to handle all the hills yourself. Also, unlike a car, the amount of work the battery/motor puts in is not 100%, and is variable. But, despite all that, I still want to know how often I have to charge / do I have the range to go there and back without having to charge or do all the work.

The setting I have available 'Pedal Assist' is a level from 0...9. When its on '0' the electronics are all sleeping. As you step this up from 1...9, as you pedal, the motor puts in some work to match. In practise I've found that higher than level 1 is just not needed unless you are in a real hurry and a bit lazy. So all my riding is on '1'.

So for the test. My round-trip commute is 6k, so 30k/week. I started the week off with a 20k ride in ~14degree weather, followed by the weekly commute and associated errands, followed by a ~20k ride in ~6degree weather. This lead to 73.5km according to the trip odometer. I started this out 'full' (5 bars) and ended it on 2-bars (so ~40% if I believe the meter). This implies that I could go probably ~100km before running fairly low on battery.

The battery is 48V @ 16AH, or ~800WH. Now lets compare. Our car (Chevy Bolt) is 60kWH, and has a maximum range of about 500km in perfect conditions. So I have 1.3% the capacity, and 1/5 the range (its a much much lighter vehicle and of course no AC/heat/... so its not a fair test). In other words, the car is 6.4% the efficiency of the bike if we look at it from solely a 'moving 1 person from A to B' standpoint.

Lets compare against another electric. If we look at a Tesla model X P100D, this vehicle has 100kWH for 465km range, or about 3.6% the efficiency (again on the sole metric of moving 1 person from A to B).

So despite my 'fat' tires having lots of rolling resistance, it seems an e-bike is pretty efficient (mainly due to power/weight ratio) compared to a car.

Dr Nouriel Roubini testified today before the US Senate Committee on Banking. My favourite quote? Probably:

“Actually calling this useless vaporware garbage a “s**tcoin” is a grave insult to manure that is a most useful, precious and productive good as a fertilizer in agriculture.”

He suggests that "blockchain is the most over-hyped technology ever, no better than a spreadsheet". Nice. Hope none of you are hodling alt-coins.

He mentions one of the things that has bothered me, the transaction rate. Visa can do 25K transactions / second but the 'new tech' of blockchain can do 7? How can we run a global economy on 7 transactions/second?

He doesn't even both going into how much 'clean' coal is burned by blockchain. I also like how he says "Even the flintstones new better, they used clam shells rather than utility-coins for barter". Hanna-Barbera called the crypto-bubble? Who knew!

Now, one of the things that I'm a bit sad about... blockchain has its uses. I wouldn't treat it as money or anything like that, but it can provide a safe, secure means of journalling information over time. It doesn't need the complex 'mining' ecosystem of people burning their houses down with sketchily wired nvidia cards. I'm a big fan of e.g. a ring-signature-based blockchain for sharing reputation-based data. But, as an investment class, an asset class, as currency, or whatever you call 'numbers that were created in basements'? No thanks.

Now the other guy testifying says, if we make more bitcoins jeeps will be safer. Um. Maybe.

So, which side do you weigh in on: blockchain is an insult to fertilizer? or blockchain will make my toaster safer? Why does it have to be just one? Lets pick both!

 Loading ...