Log in

Pete Zaitcev's Journal [entries|friends|calendar]
Pete Zaitcev

[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Community Meeting [24 May 2017|03:52pm]
<notmyname> first, the idea of having a regular meeting in addition to this one for people in different timezones
<cschwede_> +2!
<notmyname> specifically, mahatic and pavel/onovy/seznam. but of course we've all seen various chinese contributors too
<notmyname> but the point is that it's a place to bring up stuff that those in the other time zones are working on
<mattoliverau> Cool
<notmyname> I think it's a terrific idea
<tdasilva> i bet the guys working on tape would like that too
<notmyname> my goal is to find a time for it that is so horrible for US timezones that it will be obvious that not everyone needs to be there
<zaitcev> Yeah, if only there was a way to send a message... like a mail... to a list of people. And then it could be stored on a computer somewhere, ready to be read in any timezone recepient is in.
<notmyname> zaitcev: crazytown!
<mattoliverau> zaitcev: now your just talkin crazy
[link] post comment

AWS price reductions [03 May 2017|02:05pm]

Amazon announced another price cut today and anaylists are all about "there's more margin in VMs", "Microsoft Azure finds it tough to compete", and so on.

Being in storage I'm obviously biased, but I think the price cuts in S3 and Glacier are more consequential. All that data is like savings account for Amazon. Any time they need cash, they can just increase prices right back, and what are you going to do? Data is not VMs, you cannot just download it all overnight, you cannot migrate off the service.

Obviously things are not that simple, and they are trying to bind code to AWS in ways that yield similar inertia to the data. As Adrian Cockroft tweeted, "OpenStack not closing the gap". Cut him a slack though, he was at NetFlix, and it was 4 years ago. One way or the other, data's inertia is natural and code's inertia is artificial — it's something engineers can fix.

[link] post comment

SDSC Petabyte scale Swift cluster [22 Apr 2017|09:04pm]

It was almost two years since last Swift numbers, but here are a few numbers from San Diego (whole presentation is available on Github:

> 5+ PB data
> 42 servers and 1000+ disks
> 3, 4, 6 TB SAS drives for objects, SATA SSD drives for Account/Container
> 10 GbE network

The 5 PB size is about quarter scale of the largest known Swift cluster. V.impressive. The 100 PB installation that RAX run consists of 6 federated clusters. Number of objects and request rate are unknown. 1000/42 comes comes to about 25-30 disks per server, but they mention 45-disk JBODs later, with plans to move to 90-disk JBODs. Nodes of large clusters continue getting fatter.

The cluster is in operation since 2011 (started with the Diablo release). They still use Pound for load-balancing.

[link] post comment

Amazon Snowmobile [12 Apr 2017|10:59pm]

I don't know how I missed this, it should've been hyped. But here it is: an Amazon truck trailer, which is basically a giant Snowball, used to overcome the data inertia. Apparently, its capacity is 100 PB (the article is not clear about it, but it mentions that 10 Snowmobiles transfer an EB). The service apparently works one way only: you cannot use a Snomobile to download your data from Amazon.

P.S. Amazon's official page for Snowmobile confirms the 100 PB capacity.

[link] 1 comment|post comment

It was surprising [27 Mar 2017|12:33pm]

So here I was watching ACCA at Crunchyroll, when a commercial comes up... of VMware OpenStack.

I still remember times in 2010 when VMware was going to have their own cloud (possibly called VxCloud), with blackjack and hookers, as they say, or much better that OpenStack anyway. Looks like things have changed.

Also, what's up with this targeting? How did they link my account at Crunchyroll with OpenStack?

{Update: Thanks, Andreas!}

[link] 1 comment|post comment

Standards for ARM computers in 2017 [19 Mar 2017|10:34am]

I wrote this 7 years ago, in 2009:

Until ARM comes up with a full computer instead of just a CPU, it's no contender in Linux server space.

So, how are things nowadays?

The final question had to do with cross-platform drivers. There is an interpreted executable format known as EFI Byte Code (EBC); drivers compiled to that format can run on multiple architectures. [...]

Graf asked whether drivers could, instead, be shipped as a multiple-architecture binary. Progress is being made in this direction, and EFI supports multiple binary formats.


P.S. Jon reminded me about SBSA, and indeed it's a solid advancement. But using EFI drivers is an idea so monstrously dumb that I don't even know what to say.

[link] post comment

PTG, Sheraton, Atlanta [01 Mar 2017|06:51pm]

Serious reports trickle in (one, two), but on the lighter side, how was the venue? It's on the other side of the downtown, you know.

Bum incursions were very mild. Most went to the coffee area at the 1st floor, under the lobby level of Sheraton. One was remarkable though. I saw him practicing an unusual style of fighting on the sidewalk, with deep squats and wild swings - probably one of them prison styles. Very impressive, and also somewhat disturbing since all I have for him is checking with feet as well as I could, then move in for grappling phase, and then it's luck... Once done with his routine, he proceeded right past the coffee into the 2 rooms where some other org was meeting (not OpenStack) and started begging food off the hotel workers setting up tables. I heard him claiming that he was very hungry. Seemed super energetic and powerful a few minutes prior lol. But as much as I know, no laptops were stolen at the PTG (unlike e.g. OLS and UDS). Only goes to show that the main hazard is the venue staff and bums are more of an amusement, unless it's a really rough area.

[link] post comment

Richard Feynman on Gerrit reviews [02 Feb 2017|09:37am]

Here's a somewhat romanticized vision what a code review is:

What am I going to do? I get an idea. Maybe it's a valve. I take my finger and put it down on one of the mysterious little crosses in the middle of one of the blueprints on page three, and I say, ``What happens if this valve gets stuck?'' --figuring they're going to say, ``That's not a valve, sir, that's a window.''

So one looks at the other and says, ``Well, if that valve gets stuck--'' and he goes up and down on the blueprint, up and down, the other guy goes up and down, back and forth, back and forth, and then both look at each other. They turn around to me and they open their mouths like astonished fish and say, ``You're absolutely right, sir.''

Quoted from "Surely You Are Joking, Mr. Feynman!".

[link] 1 comment|post comment

git-codereview [12 Jan 2017|12:55pm]

Not content with a legacy git-review, Google developed another Gerrit front-end, the git-coderevew. They use it for contributions to Go. I have to admit, that was a bit less of a special move than Facebook's git-review that uses the same name but does something entirely different.

P.S. There used to be a post about creating a truly distributed github, which used blockchain in order to vote on globally unique names. Can't find a link though.

[link] post comment

Mirantis and the business of OpenStack [08 Jan 2017|11:07am]

It seems that only in November we heard about massive layoffs at Mirantis, "The #1 Pure Play OpenStack Company" (per <title>). Now they are teaching us thus:

And what about companies like Mirantis adding Kubernetes and other container technologies to their slate? Is that a sign of the OpenStack Apocalypse?

In a word, “no”.

Gee, thanks. I'm sure they know what it's like.

[link] post comment

The idea of ARM has gone mainstream [27 Dec 2016|11:51am]

We still don't have any usable servers on which I could install Fedora and have it supported for more than 3 releases, but gamers already debate the merits of ARM. The idea of SPEC-per-Watt has completely gone mainstream, like Marxism.

<sage> http://www.bitsandchips.it/english/52-english-news/7854-rumor-even-intel-is-studying-a-new-x86-uarch new uarch? it's about time
<sage> they just can't make x86 as power efficient as arm
<JTFish> What is the point
<JTFish> it's not like ARM will replace x86 in real servers any time soon
<sage> what is "real" servers?
<JTFish> anything that does REAL WORLD shit
<sage> what is "real world"?
<JTFish> serving internet content etc
<JTFish> database servers
<JTFish> I dunno
<JTFish> mass encoding of files
<sage> lots of startups and established companies are already betting on ARM for their cloud server offerings
<sage> database and mass encoding, ok
<sage> what else
<JTFish> are you saying
<JTFish> i'm 2 to 1
<JTFish> for x86
<JTFish> also I should just go full retard and say minecraft servers
<sage> the power savings are big, if they can run part of their operation on ARM and make it financially viable, they will do it

QUICK UPDATE: In the linked article:

The next Intel uArch will be very similar to the approach used by AMD with Zen – perfect balance of power consumption/performance/price – but with a huge news: in order to save physical space (Smaller Die) and to improve the power consumption/performance ratio, Intel will throw away some old SIMD and old hardware remainders.

The 100% backward hardware x86 compatibility will not guaranteed anymore, but could be not a handicap (Some SIMD today are useless, and also we can use emulators or cloud systems). Nowadays a lot of software house have to develop code for ARM and for x86, but ARM is lacking useful SIMD. So, frequently, these software are a watered-down compromise.

Intel will be able to develop a thin and fast x86 uArch, and ICC will be able to optimize the code both for ARM and for x86 as well.

This new uArch will be ready in 2019-2020.

Curious. Well, as long as they don't go full Transmeta on us, it may be fine.

[link] post comment

FAA proposes to ban NavWorx [22 Oct 2016|10:26pm]

Seen a curious piece of news today. As a short preamble, an aircraft in the U.S. may receive useful information from a ground station (TIS-B and FIS-B), but it has to transmit a certain ADS-B packet for that to happen. And all ADS-B packets include a field that specifies the system's claim that it operates according to a certain level of precision and integrity. The idea is, roughly, if you detect that e.g. one of your redundant GPS receivers is off-line, you should broadcast that you're downgraded. The protocol field is called SIL. The maximum level you can claim is determined by how crazily redundant and paranoid your design is. We are talking something in the order of $20,000 worth of cost, most of which is amortization of FAA paperwork certifying and you are entitled to claim SIL of 2. I lied about this explanation being short, BTW.

So, apparently, NavWorks shipped cheap ADS-B boxes, which were made with a Raspberry Pie and a cellphone GPS chip (or such). They honestly transmitted a SIL of 0. Who cares, right? Well, FAA decided that TIS should stop to reply to airplanes flying around with a SIL Zero ADS-B boxes, because fuck the citizens, they should pay their $20k. Pilots called the NavWorks and complained that their iPads hooked to ADS600 do not display the weather reliably anymore. NavWorks issued a software update that programmed their boxes to transmit SIL of 2. No other change: the actual transmitted positions remained exactly as before, only the claimed reliability was faked. When FAA got the wind of this happening, they went nuclear on NavWorks users' asses. The proposed emergency directive orders owners to remove the offending equipment from their aircraft. They are grounded until the compliance.

Now the good thing is, the ADS-B mandate comes in 2020. They still have 3 years to find a more compliant (and expensive) supplier, before they are prohibited from a vicinity of a major city. So it's only money.

I don't have a dog in this fight, personally, so I can sympathize with both the bureaucrats who saw cheaters and threw a book at them, and the company that employed a workaround against a meaningless and capricious rule. However, here's a couple of observations.

First, note how FAA maintains a database of individual (not aggregate) protocol compliance for each ADS-B ID. They will even helpfully send you a report about what they know about you (it's intended so you can test the performance your ADS-B equipment). Imagine if the government saved every query that your browser made, and could tell if your Chrome were not compliant with a certain RFC. This detailed tracking of everything is actually very necessary because the protocol has no encryption whatsoever and is trivially spoofed. Nothing stops a bad actor to use your ID in ADS-B. The only recourse is for the government to investigate reported issues and find the culprit. And they need the absolute tracking for it.

Second, about the 2020 mandate. The airspace prohibition amounts to not letting someone into a city if the battery is flat in their EZ-pass transponder. Only in this case, the government sent you a letter saying that your transponder is banned, and you must buy a new one before you can get to work. In theory, your freedom of travel is not limited - you can take a bus. In practice though, not everyone has $20k, and the waiting list for the installer is 6 months.

UPDATE 2016/12/19: NavWorx posted the following explanation on their website (no permalink, idiots):

Our version 4.0.6 made our 12/13 products transmit SIL 3, which the FAA ground stations would recognize as sufficient to resume sending TIS-B traffic to our customers.

Fortunately from product inception our internal GPS met SIL 3 performance. The FAA approved our internal GPS as SIL 3. During the TSO certification process, the FAA accepted our “compliance matrix” – which is the FAA’s primary means of compliance - showing our internal GPS integrity was 1x10-7, which translates to SIL of 3. However, FAA policy at that time was that ADS-B GPS must have its own separate TSO – our internal GPS was certified under TSO-C154c, the same as the UAT OUT/IN transceiver. It’s important to note that the FAA authorized us to certify our internal GPS in this manner, and that they know that our internal GPS is safe – applicants for TSO certification must present a project plan and the FAA reviews and approves this project plan before the FAA ever allows an applicant to proceed with TSO certification of any product. Although they approved our internal GPS to be SIL of 3 (integrity of 1x10-7), based on FAA policy at the time they made us transmit SIL 0, with the explanation that “uncertified GPS must transmit SIL 0”. This really is a misnomer, as our GPS is “certified” (under TSO-C154c), but the FAA refers to it as “uncertified”. The FAA AD states that “uncertified” GPS must transmit SIL of 0.

So, basically, they never bothered to certify their GPS properly and used a fig leaf of TSO-C154c.

The letter then goes on how unfair it is that all the shitty experimentals are allowed to signal SIL 3 if only they use a proper GPS.

UPDATE 2016/12/20: AOPA weighs in a comment on NPRM:

Specifically, AOPA recommends the FAA address the confusion over whether the internal position source meets the applicable performance requirements, the existence of an unsafe condition, and why the proposed AD applies to NavWorx’s experimental UAT model.

The FAA requires a position source to meet the performance requirements in appendix B to AC 20-165B for the position source to be included in the ADS-B Out system and for an aircraft to meet the § 91.227(c) performance requirements (e.g., SIL = 3). The FAA does not require the position source be compliant with a specific TSO. Any person may demonstrate to the FAA that its new (uncertified) position source meets the requirements of appendix B to AC 20-165B, thereby qualifying that position source to be used in an ADS-B Out system. However, integrating a TSO-certified position source into a UAT means that a person will have fewer requirements to satisfy in AC 20-165B appendix B during the STC process for the ADS-B Out system.

Around May 2014, the FAA issued NavWorx an STC for its ADS600-B UAT with part numbers 200-0012 and 200-0013 (Certified UATs). The STC allowed for the installation of those UATs into any type-certificated aircraft identified in the approved model list. The Certified UATs were compliant with TSO-C154c, but had internal, non-compliant GPS receivers. (ADS600-B Installation Manual 240-0008-00-36 (IM -36), at 17, 21, 28.) Specifically, section 2.3 of NavWorx’s March 2015 installation manual states:

“For ADS600-B part numbers 200-0012 and 200-0013, the internal GPS WAAS receiver does not meet 14 CFR 91 FAA-2007-29305 for GPS position source. If the ADS600-B is configured to use the internal GPS as the position source the ADS-B messages transmitted by the unit reports: A Source Integrity Limit (SIL) of 0 indicating that the GPS position source does not meet the 14 CFR 91 FAA-2007-29305 rule.” (IM -36, at 19.)

Hoo, boy. Per the above quote by AOPA, NavWorks previously admitted in writing that their internal GPS is not good enough, but they are trying to walk that back with the talk about "GPS integrity 1x10-7".

In the same comment letter later, Justin T. Barkowski recommends to minimize the economic impact in the rulemaking and not force owners to pull NavWorx boxes out of the aircraft immediately.

UPDATE: The final ban is published on June 6, 2017.

[link] post comment

Russian Joke [01 Sep 2016|10:12pm]

Supposedly from Habrahabr.ru, via bash.org.ru:

Autor's Bio: Andrey Pan'gin [ref — zaitcev]. Programmer in the Odnoklassniki company, specializing in highly loaded back-ends. Knows JVM like the back of his hand, since he developed the HotSpot VM at Sun Microsystems and Oracle for several years. Loves assembly and systems programming.
A comment: Fallen angel.

[link] post comment

Curse you, Jon Masters! Why do you always have to be right! [24 Aug 2016|12:56pm]

My friend and colleague Jon is proud of his disdain for Linux on desktop (or tablet, for that matter), and always goes around telling people how OSX always works on a Mac, because Apple performs integrated testing etc. etc.. The latest episode involved him buying a lemon Dell XPS 13. Pretty much nothing worked right on that pitiful excuse for a computer, and I am sorry to admit, I felt a little smug telling Jon on Facebook how well my ASUS UX303LB worked under Fedora. I've not had a failure to resume even once in the years I had it (yeah, my standards are this low).

Long story short, Fedora 24 came out and I'm given the taste of the same medicine: the video on the ASUS is completely busted. I was able to limp along for now by using the old kernel 4.4.6-301.fc23, but come on, this is clearly a massive regression. Think anyone is there to bisect and find the culprit? Of course not. I have to do it it myself.

So, how did F24 ship? Well... I didn't test beta versions, so I don't have much ground to complain.

UPDATE: While upsream is working on the fix in the next release, I'm using i915.enable_psr=0.

[link] post comment

The sound ID of telemarketers [24 Aug 2016|11:16am]

I noticed one strange thing recently. Every telemarketing call starts with an particular sound that resembles a modulated data block. It's very short, about 250 ms, but very audible. I'm a little curious what it is. Is it possible to capture and decode?

The regular calls are not preceded by this block, so I'm certain that it's something that telemarketers mix in. But to what purpose?

UPDATE: Someone shared this post on Hacker News. I'm happy to report they didn't conclude that I'm making shit up, but the best the hive-mind came up with was that the Caller-ID is getting sent even after the receiver is picked up. I really should record this somehow.

[link] post comment

Fedora, Swift, and xattr>=0.4 [18 Aug 2016|06:23pm]

If one tries to run Swift tests with "PYTHONPATH=$(pwd) ./.unittests" on a stock Fedora, a bunch of them fail with "DistributionNotFound: xattr>=0.4". This is fixed easily with the following patch:

diff -urp pyxattr-0.5.1-p3/setup.py pyxattr-0.5.1/setup.py
--- pyxattr-0.5.1-p3/setup.py	2012-05-15 16:58:20.000000000 -0600
+++ pyxattr-0.5.1/setup.py	2014-05-29 14:21:54.223317477 -0600
@@ -29,3 +29,11 @@ setup(name = "pyxattr",
       test_suite = "test",
       platforms = ["Linux"],
+# Add a dummy egg so "xattr>=0.4" works in requirements.txt for paste-deploy.
+# This primarily helps with running unit tests of Swift et.al., because for
+# packaging we already disable all this.
+      version = version,
+      description = "Alias to pyxattr",
+      ext_modules = [Extension("xattr", [])]
+     )

IIRC I proposed this as a fix, but the maintainer of pyxattr in Fedora was not glad to see it, so I threw together a spec and RPM for pyxattr, kept in my people.redhat.com page.

This was going on for 3 years or more. Rebuilding the patched pyxattr again for Fedora 24, I started wondering idly, why is it that nobody else ran into this problem? I suspect the answer is that I am the only human in the world who tests OpenStack Swift on Fedora. Everyone else uses Ubuntu (or pip).

[link] post comment

Go go go [15 Jun 2016|08:57am]

Can you program in Go without knowing a thing about it? Why, yes. A barrier to entry, where are you?

[link] post comment

You are in a maze of twisted little directories, all alike [07 Jun 2016|03:21pm]

[root@rhev-a24c-01 go]# make get
go get -t ./...
go install: no install location for directory /root/hail/swift-go/go/bench outside GOPATH
For more details see: go help gopath
[root@rhev-a24c-01 go]# pwd
[root@rhev-a24c-01 go]# ls -l /root/go/src/github.com/openstack/swift
lrwxrwxrwx. 1 root root 25 Jun 6 21:50 /root/go/src/github.com/openstack/swift -> ../../../../hail/swift-go
[root@rhev-a24c-01 go]# cd /root/go/src/github.com/openstack/swift/go
[root@rhev-a24c-01 go]# pwd
[root@rhev-a24c-01 go]# make get
go get -t ./...
[root@rhev-a24c-01 go]#
[link] post comment

Encrypt everything? Please reconsider. [29 May 2016|11:16am]

Somehow it became fashionable among site admins to set it up so that accessing over HTTP was immediately redirected to https://. But doing that adds new ways to fail, such as certificate expired:

Notice that Firefox provides no way to ignore the problem and access the website (which was supposed to be accessible over HTTP to begin with). Solution? Use Chrome, which does:

Or, disable NTP and change your PC's clock two days back (be careful with running make while doing so).

This was discussed by CKS previously (of course), and he seems to think that the benefits outweigh the downsides of an occasional fuck-up, like the only website in the world that has the information that I want right now is suddenly unavailable with no recourse.

UPDATE: Chris dicussed the problem some more and brought up other examples, such as outdated KVM appliances that use obsolete ciphers.

One thing I'm wondering about is if a redirect from http:// to https:// makes a lot of sense. If you do not support access by plain HTTP, why not return ECONNREFUSED? I'm sure it's an extremely naiive idea.

[link] 1 comment|post comment

Russian Joke [25 May 2016|01:15pm]

In a quik translation from Bash:

XXX: Still writing that profiler?
YYY: Naah, reading books now
XXX: Like what books?
YYY: TCP Illustrated, Understanding the Linux kernel, Linux kernel development
XXX: And I read "The Never-ending Path Of Hatred".
YYY: That's about Node.js, right?

[link] post comment

[ viewing | most recent entries ]
[ go | earlier ]