Pete Zaitcev

A little while ago I been to a talk by Michael Verhulst of Terminal Labs. He made a career of descending into Devops disaster zones and righting things up, and shared some observations. One of his aphorisms was:

Nobody Is Google — Not Even Google

If I understood him right, he meant to say that scalability costs money and businesses flounder on buying more scalability than they need. Or, people think they are Google, but they are not. Even inside Google, only a small fraction of services operate at Google scale (aka planetary scale).

Apparently this sort of thing happens quite often.

I selected Lulzbot Mini as my 3D printer in large part because of the strong connection between the true open source and the company. It came with some baggage: not the cheapest, stuck in the world of 3mm filament, Cura generates mediocre support. But I could tolerate all that.

However, some things happened.

One, the maker of the printer, Alef Objects collapsed and sold itself to FAME 3D.

Two, Fedora shipped a completely, utterly busted Cura twice: both Fedora 30 and Fedora 31 came out with the package that just cannot be used.

I am getting a tiny bit concerned for the support for my Lulzbot going forward. Since printers expend things like cleaning strips, availability of parts is a big problem. And I cannot live with software being unusable. Last time it happened, Spot fixed the bug pretty quickly, in a matter of days. So, only a tiny bit concerned.

But that bit is enough to consider alternatives. Again, FLOSS-friendly is paramount. The rest is not that important, but I need it to work.

I was at this topic since NetWinder was a thing, but yet again I started looking at having an ARM box in the house. Arnd provided me with the following tips, when I asked about CuBox:

2GB of RAM [in the best CuBox] is not great, but doesn't stop you from building kerrnels. In this case, the CPU is going to be the real bottleneck.

Of course it's not SBSA, since this is an embedded 32 bit SoC. Almost no 64 bit machines are SBSA either (most big server chips claim compliance but are lacking somewhat), but generally nobody actually cares.

HoneyComb LX2K is probably what you want if you can spare the change and wait for the last missing bug fixes.

The RK3399 chip is probably a good compromise between performance and cost, there are various boards with 4GB of RAM and an m.2 slot for storage, around $100.

Why does have to be like this? All I wanted was to make usbmon work on ARM.

The assertion that nobody cares about SBSA is rather interesting. Obviously, nobody in the embedded area does. They just fork Linux, clone a bootloader, flash it and ship, and then your refrigerator sends spam and your TV is used to attack your printer, while they move on the next IoT product. But I do care. I want to download Fedora and run it, like I can on x86. Is that too much to ask?

The HoneyComb LX2K is made by the same company as CuBox, but the naked board costs $750.

Greg threw a blog post that contains a number of interesting animations of his terminal sessions. Fascinating!

I do not use mutt because I often need to copy-paste, and I hate dealing with line breaks that the terminal inevitably hoists upon me. So, many years ago I migrated to Sylpheed, and from there to Claws (because of the support of anti-aliased fonts).

Greg's approach differs in that it avoids the copy-paste problem by manipulating the bodies of messages programmatically. So, the patches travel between messages, files, and git without being printed to a terminal.

Linode made their Object Storage product generally available. They dropped the Swift API that they offered in the beta, and only rolled with S3.

They are careful not to mention what implementation underpins it, but I suspect it's Ceph RGW. They already provide Ceph block storage as public service. Although, I don't know for sure.

An acquaintance of mine was laid off from Samsung. He was a rank-and-file ASIC designer and worked on FPU unit for Samsung's new CPU. Another acquaintance, a project manager in the silicon field, relayed that supposedly ARM developed a new CPUs that are so great, that all competitors gave up and folded their CPU development, resulting in the layoffs. The online sources have details.

In the same time they gave up on in-house cores, Samsung announced Exynos 990, a standalone version of the 980, based on the successors of the Cortex family, developed by ARM, of course.

As someone said on Glassdoor, "great place to work until you're laid off".

As some of you might have noticed, Facebook started adding a tracking token to all URLs as a query string "?fbclid=XXXXXXXXX". I don't know how it works, exactly. Perhaps it rattles to FB when people re-inject these links into FB after they cycle through other social media. Either way, today I found a website that innocently fails to work when shared on FB: Whomp. If one tries to share a comic strip, such as "It's Training Men", FB appends its token, and makes the URL invalid.

A job at LinkedIn in my area includes the following instruction statement:

Don't apply if you can't really write code and don't have a github profile. This is a job for an expert level coder.

I remember the simpler times when LWN authors fretted about the SourceForge monopoly capturing all FLOSS projects.

P.S. For the record, I do have a profile at Github. It is required in order to contribute to RDO, because it is the only way to login in their Gerrit and submit patches for review. Ironically, Fedora offers a single sign-on with FAS and RDO is a Red Hat sponsored project, but nope — it's easier to force contributors into Github.

Found an odd job posting at the website of Rancher:

What you will be doing

• Design and implement a block storage solution for Docker containers
• Working on development of various aspects of the storage stack: consistency, reliability, replication and performance
• Using Go for product development

Okay. Since they talk about consistency and replication together, this thing probably provides actual service, in addition to the necessary orchestration. Kind of the ill-fated Sheepdog. They may under-estimate the amount of work necesary, sure. Look no further than Ceph RBD. Remember how much work it took for a genius like Sage? But a certain arrogance is essential in a start-up, and Rancher only employs 150 people.

Also, nobody is dumb enough to write orchestration in Go, right? So this probably is not just a layer on top of Ceph or whatever.

Well, it's still possible that it's merely an in-house equivalent of OpenStack Cinder, and they want it in Go because they are a Go house and if you have a hammer everything looks like a nail.

Either way, here's the main question: what does block storage have to do with Docker?

Docker, as far as I know, is a container runtime. And containers do not consume block storage. They plug into a Linux kernel that presents POSIX to them, only namespaced. Granted, certain applications consume block storage through Linux, that is why we have O_DIRECT. But to roll out a whole service like this just for those rare appliations... I don't think so.

Why would anyone want block storage for (Docker) containers? Isn't it absurd? What am I missing and what is Rancher up to?

UPDATE:

The key to remember here is that while running containers aren't using block storage, Docker containers are distributed as disk images, and they get a their own root filesystem by default. Therefore, any time anyone adds a Docker container, they have to allocate a block device and dump the application image into it. So, yes, it is some kind of Docker Cinder they are trying to build.

See Red Hat docs about managing Docker block storage in Atomic Host (h/t penguin42).

Anyone who ever worked with object storage knows that PUT creates, GET reads, POST updates, and DELETE deletes. Naturally, right? POST is such a strange verb with oddball encodings that it's perfect to update, while GET and PUT are matching twins like read(2) and write(2). Imagine my surprise, then, when I found that the official definition of RESTful makes POST create objects and PUT update them. There is even a FAQ, which uses sophistry and appeals to the authority of RFCs in order to justify this.

So, in the world of RESTful solipcism, you would upload an object foo into a bucket buk by issuing "POST /buk?obj=foo" [1], while "PUT /buk/foo" applies to pre-existing resources. Although, they had to admit that RFC-2616 assumes that PUT creates.

All this goes to show, too much dogma is not good for you.

[1] It's worse, actually. They want you to do "POST /buk", and receive a resource ID, generated by the server, and use that ID to refer to the resource.