Rubenerd logo

Rubenerd



Why ZTE was banned in the US, Australia

Sherisse Pham reported for CNN Tech:

The United States has cracked down on one of China’s biggest tech companies, banning it from buying components from American firms. [..] On the same day, ZTE also received a blow from the UK government, which warned telecom companies against using the Chinese firm’s equipment and services.

And Australia followed suit, as Simon Sharwood reported in The Register:

Australia’s largest and dominant telco, Telstra, has stopped selling the ZTE devices it sold under its own brand. [..] Telstra blamed US sanctions recently imposed on ZTE that prevent the Chinese mobe-maker from acquiring parts made by US companies.

If I may indulge in some rhetorial questioning, why? There could have been a few reasons.

Misrepresented software patches

ZTE, along with an unsurprising but worrying array of Android manufacturers, were caught lying about what software patches were installed on their phones. Andy Greenberg reported in Wired on the Security Research Labs team’s discovery:

[..] the lowest-performing companies on the list were the Chinese firms TCL and ZTE, all of whose phones had on average more than four patches that they’d claimed to have installed, but hadn’t.

This didn’t get anywhere near as much coverage as it should have. This cuts right to the heart of how software patches have to be filtered down from Google to all these third parties.

It’s understandable that hardware would be shipped with outdated software, especially in today’s climate where software gets constant updates. If ZTE and these other manufacturers had bundled a slip of paper saying welcome to your new phone, please update to get the best experience, nobody would have minded or cared. Instead, they fudged version numbers, so not only would a large number of people have avoided updating because they don’t see the urgency, security concious people would actively think they don’t need to.

If a third party, okay, a third third party in this case, had got into your phone and tweaked version numbers so you’d stay vulnerable for later exploitation, we’d consider that malware.

Pre‐installed adware

Could it have been banned because some of their devices had been caught hosting after market adware to their unsuspecting users, as the Avast team discovered?

The Avast Threat Labs has found adware pre-installed on several hundred different Android device models and versions, including devices from manufacturers like ZTE, Archos, and myPhone.

Running an OS by a company making most of their money from advertising makes this somewhat moot, but still.

Class

This is another age‐old issue, but especially true in the age of The Notch. But I’ve always been struck by how… familiar ZTE’s designs are. As Alex Heath reported for the Cult of Mac:

While ZTE has tried to make a phone like the iPhone, “the actual build quality and feel in the hand is a completely different story,” notes Android Authority in its review. “The entire body of the Blade S6 is made of plastic, and while plastic doesn’t necessarily have to feel cheap, as we’ve seen from the slew of premium quality mid-range smartphones released recently, unfortunately in this case, it does.”

What bugs me about this isn’t the blatent copying, its that Apple has one fewer competitor in design. Legitimate competition is the best thing for consumers.

Also calling it the S6 has gotta be a swipe against Samsung. Maybe they should call their next phone the Galax S7.

The real reason

What about GPL violations? The fact most Android phones are still running outdated software? The fact alternative stores to Google Play have been released because people don’t trust the offical channel anymore?

Okay, you figured out by now that those concerns weren’t the reasons why. Not to get all Merlin Folders on you, but turns out, it was politics. Back to Sherisse’s article:

The US Commerce Department said that ZTE lied to American officials about punishing employees who violated US sanctions against North Korea and Iran. The Chinese company agreed to pay a $1.2 billion fine last year after a US investigation found it had illegally shipped telecommunications equipment to Iran and North Korea.

Which leads us to the only reasonable, unavoidable conclusion: I miss Palm.


The Walkie-Talkie Sky Garden

Photo of the Sky Garden by Colin on Wikimedia Commons

The English Wikipedia Featured Pictures team have been on a roll, like so many quality condiments. I found myself lost in this photo by Colin, but was lulled into a false sense of security by the serenity.

It shows the Sky Garden atop 20 Fenchurch Street, known to locals in London as the Walkie Talkie. I’d tell you it’s in London, but that would now be superfluous, and a little insulting to your comprehension abilities.

The tower isn’t without criticism, which is to say it’s been criticised. By critical people, and critics. Specifically, according to Wikipedia:

  • it won the Carbuncle Cup in 2015 for the UK’s ugliest building

  • the garden itself was smaller and has less greenery than expected, and you have to book to visit it; and

  • the word literally is thrown around liberally these days, but the angle of the windows concentrated light and literally raised temperatures on certain points at street level past boiling point.

I guess it makes a better desktop background!


Micro‐beads

This was written quickly in a brief fit of anger, and may not be up to the usual quality of posts here on Rubenerd. Because if I’m known for anything, its quality writing; see what I did there?

Clara and I got some face wash last night. I was about to slather it all over my mug in the shower, like a gentleman, before I noticed these tiny, bright blue grains of crap in it. I spend a solid five minutes picking it out because I didn’t have another immediate source of face cleaning in my soapy, bleary-eyed morning state.

Yes, this abomination had plastic micro‐beads; those grains of non‐biodegradable plastic.

I’m willing to give the benefit of the doubt to so many companies. When they released the first versions of their product years ago, they weren’t aware of the future consequences of their use or disposal. Mr Carrier didn’t set out to destroy the ozone layer with his air conditioner, for example.

Plastic micro‐beads are comparatively recent. They were proposed and developed with full knowledge that it’d be washed down sinks, and end up in the oceans. And they didn’t care. These are incontrovertible facts; I don’t buy any defence of this decision.

Oil spills garner headlines, but I put these people in the exact same league. Possibly worse, because while oil is used to power things, micro‐beads are an entirely useless marketing gimmick. They saw a potential environmental disaster, and thought they could make a quick buck off it.

Get this out of toiletries, now. Governments, legislate against this shit, because we can’t trust businesses to act in our collective interest here. And to the people who thought this was a good idea; choke on a plastic-filled fish. Bon Appétit, halfwits.



New York’s C Trains

R32 set J train at Marcy Avenue, by R38R40 on Wikimedia Commons

Clara and I loved riding the New York City Subway in 2016. It was perfect for tourists, save for the grime. But it seems since it’s only got worse for commuters since we left, with problems culminating in a declared state of emergency. Damn :(.

Marc Santora wrote this article a year ago for the New York Times for the oldest trains in the system, with some amazing photos:

…the C train cars, once the pride of the subway, are now, according to New York subway officials, the oldest in continuous daily operation in the world.

Keeping the 53-year-old trains [Ruben: built 1964–65] running is not just an aesthetic problem. The cars, also known as the R32, break down far more often than any other train in the system, averaging just 33,527 miles between failures. The average subway car can travel 400,000 miles before breaking down. And the newest cars in the fleet average more than 750,000 miles.

Sydney still has many of its S-class trains in service, that we all dub tin cans. They have similar stainless steel construction and panel fluting, though they were built a decade later in the 1970s.

In defence of the C trains, from the Wikipedia page:

According to railfan James Greller, they often cited for their superior durability and craftsmanship, along with the structural reinforcement done to their bodies during the GOH period; four other B Division models built after them have been mostly or completely retired.

Given the build quality of Sydney’s Warratah trains, and the door problems on the Tangaras, I wouldn’t be surprised—only half tongue in cheek—if the S-class trains in Sydney outlasted them as well.

The only other metro I’ve travelled on daily for years is Singapore’s MRT, but their oldest rolling stock was built in 1987, and refurbished in the 2000s.

Photo above is of an R32 set J train at Marcy Avenue, by R38R40 on Wikimedia Commons.


My FreeBSD desktop from ten years ago

Here’s a blast from the past: a screenshot of my FreeBSD desktop from almost a decade ago to the day!

The aforementioned FreeBSD desktop

It was a DIY Intel Core 2 Duo E8400 tower in a slender white case with a Coffee Bean and Tea Leaf sticker, hence the hostname “Espresso”. The depicted character is C.C., everyone’s favourite pizza fan. It shows 29 degrees at 5am, that’s even warm for Singapore at that time.

I was going through a lot of desktop environments back then; 2008 was my KDE and GNOME experimentation days before going back to Xfce that the Cobind Desktop first introduced me to. The cool kids were still using tiled window managers or OpenBox.

To expand on the nostalgia, my primary portable machine was still my first-gen Intel MacBook Pro at the time. I had to be careful to get universal binaries for it; PowerPC stuff worked decently, but not needing Rosetta was a bonus.

Peppperidge Farm and Lelouch remember.


Concat VMDKs with VMware Fusion

VMware Fusion—and as far as I can remember, VMware Workstation—default to splitting disk images into multiple files. There are benefits to doing this, but it might not be what you want depending on your use case.

If you’ve been given a bundle with multiple VMDKs:

$ ls *vmdk
==> disk.vmdk
==> disk-s001.vmdk
==> disk-s002.vmdk
==> disk-s003.vmdk
[..]
==> disk-s00[n].vmdk

You can merge them graphically, like a Boss:

  1. Open the .vmx file in Fusion to import the VM
  2. Go to Virtual MachineSettings
  3. Click the first Hard Disk under Removable Devices
  4. Click ▸ Advanced Options
  5. De-select Split into multiple files

It will sit there chewing away for a few minutes while it concatenates, depending on the size and number of files. And you’ll be left with:

$ ls *vmdk
==> disk.vmdk

Now you can run it through a converter, such as to RAW to boot it on Xen, or something else. Boom!


From the not‐this‐again department

The Catholic Church… you know how this ends. Nancy Notzon filed this for ABC News Australia:

The most senior Catholic to be charged with concealing child sexual abuse — Adelaide’s Archbishop Philip Wilson — has been found guilty by a New South Wales court.

I post this in the sincere hope one day we’ll be surprised by news like this, because it’ll be uncommon again.


A cut-open 737-200

I loved this photo by Eric Freidebach!

US Airways 737-200 N213US fuselage section on display at the Museum of Flight.

The 737 is my second-favourite airframe, after the Lockheed L-1011 TriStar. I likely won’t ever get to fly in a 707, but the 737 shares its distinctive cockpit windows and fuselage cross-section. Note also the simple, rounded rectangle cabin windows; I reckon these are much nicer than the slightly-bulbous ones of most contemporary jets.

What struck me about this photo though was how slender those wings were! And to think all its fuel had to fit in that space. Wild.

The photo is preserved on Wikipedia Commons, because Google bought Panoramio and subsequently shut it down. Of course.


Using rsyncd instead of rsync over SSH

The easiest way to use rsync is with the default SSH transport option. It’s easy, secure, and reasonably fast. Machines will bottleneck elsewhere before your CPUs will encrypting/decrypting the ssh streams, from my experience. And you get all the SSH niceties, like pre-shared keys and host config files.

But this weekend I needed to transfer to an older machine without AES-NI. And in this case, it was most definitely pegging the CPU long before the network link was saturated, as htop showed:

1 [||||||||||||||||||||||||||99.7%]

There are two ways around this with rsync:

  • keep SSH, but enable a faster cipher like arcfour; or
  • use an unencrypted rsync stream with rsyncd, like rsync used to do.

I thought I’d try the latter, like a gentleman.

rsyncd

rsync used to ship with a client-server system using rsyncd as its default operating mode. If you install it on FreeBSD thanks to rodrigo@, the rsyncd rc script still exists:

# pkg install rsync
# ls -F /usr/local/etc/rc.d/
# ==> rsyncd*

The manpage is your friend, but this Everything Linux guide from 1999 is still the nicest I’ve found online to get started.

It goes without saying you’d only want to run it on a trusted network. No really, if you do these on a production site over the internet or another shared network, you’d better hope the data isn’t confidential!

A quick and dirty test

I transferred a 1GiB test file generated with urandom three times, and averaged the transfer times. These were the rough results:

Transfer method Reported speed
rsync with default SSH 28.11MB/s
rsync with arcfour SSH 32.61MB/s
rsyncd 48.77MB/s

And the CPU on the target box went from full utilisation, to hovering around 30%. I was surprised at this drop, given rsync would still be computing hashes to verify file transfers. This would seem to confirm my suspicion the CPU was bottlenecking on the SSH side.

There are plenty more optimisations available, but this wasn’t a bad effort for 10 minutes of work!

Troubleshooting

I followed the rsyncd.conf manpage for configuring rsyncd on the FreeBSD server, but I kept getting stream closure errors. I like open streams, they let me transfer data.

So I enabled logs in rsyncd.conf, like a gentleman:

log file = /var/log/rsyncd.log

Then restarted the daemon, and tried the transfer again. From the logs:

2018/05/06 12:08:37 [23834] ERROR: module is read only

If you read the documentation—what a concept—read only is the default. Whoops!