blumentopf's comments

Linus hasn't pulled it yet. (And it's doubtful whether he will.) It's just David Howells has requested him to do so.

There's a bug in Apple's EFI driver for BCM4331 cards present on a lot of older Macs which keeps the card enabled even after handing over control to the OS. A patch went into Linux 4.7 to reset the card in an early quirk, but I suspect other OSes can be taken over via WiFi on the affected machines:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Porsche for instance isn't earning any money with their LMP1 race cars. They need them to sustain the illusion that they're a sports car company, despite the majority of their sales being SUVs (Cayenne, Macan) and sedans (Panamera).

Revolution Pi for SCADA / IoT applications. Mounted on an industry standard EN 50022 top hat rail with a 24 VDC power supply.

https://revolution.kunbus.com/

https://hopperapp.com is just 89 €, I've found its decompiler to be sufficient in most cases.

> You can plug a TB3 device into a TB2 laptop with a simple adapter. Apple sells theirs for $29; Chinese versions will be cheaper.

Apple's adapter has turned out not to work on Linux. It might not work with BootCamp either. Seems to require a special driver:

https://bugzilla.kernel.org/show_bug.cgi?id=189731

You need to read the whole thread:

http://marc.info/?l=linux-pci&m=148238610022972&w=2

"obviously i am interested to get this upstream with the least amount of effort. I am quite aware though that some patches will need an overhaul to be applicable for upstream. its not really my call if it is enough to make this an enable patch and review the quirks enabled by it or if the code needs to be moved."

Upstreaming patches into the kernel requires that you're willing to spend time to rework them so that the result is maintainable. Saying from the start that you only want to do the least amount of work possible isn't helpful.

LEDE folks have started to dump their patches on kernel mailing lists, but they don't seem to be mainline-able as is and the submitter is loathe to rework them:

http://marc.info/?l=linux-kernel&m=148230680302480&w=2

BMW has a subsidiary in Ulm (BMW Car-IT) working on the next head unit. This will be designed and engineered in-house, at least to a large extent. Any opinion on that? The current head unit generation is apparently sourced from a 3rd party. I interviewed there once, it was almost funny how much they stressed that they're a software company, not a car company, kind of like self-hypnosis. (Disclosure: I didn't get the job, neither wanted it after seeing the situation on-site; didn't fit into their culture.) (Fun fact: Company is full of ex-Nokians who they apparently scooped up when the local Nokia subsidiary had layoffs.)

> Google doesn't do laptop/desktop computers

They do:

"Google Chromebooks outsell Apple Macs" (May 2016)

http://www.businessinsider.com/google-chromebooks-outsell-ap...

Yes, because the PCIe root complex in the CPU can only connect one other device besides the southbridge, and that's used for the Thunderbolt controller on the left handside. The second Thunderbolt controller is connected to the southbridge (as are all the other PCIe peripherals), so it doesn't have the same number of PCIe lanes available as the one directly connected to the root complex.

Apple could have solved this by connecting a PCIe switch to the root complex and attaching both Thunderbolt controllers below it, but that would have consumed additional energy. Alternatively they could have used a beefier CPU with more PCIe root ports on the CPU, but I guess those available would have been too energy hungry. Which kind of means this is Intel's fault for not providing a low-energy chip with enough PCIe root ports on the CPU.

I'm wondering what the situation is like on the 15" version with discrete graphics. This would require 3 root ports directly on the CPU to drive both Thunderbolt controllers and the GPU with full speed, I assume that's indeed the case since it's not mentioned in the document.

Another thing not mentioned in the document is that energy consumption will be suboptimal if one device is attached on both sides of the machine because it prevents one of the Thunderbolt controllers from powering down. One should connect both devices on one side to improve battery life.

Edit: On Skylake the PCH is apparently optional, the functionality is mostly integrated into the CPU, so the limitation is really the number of lanes provided by the CPU, and this wasn't sufficient to connect both Thunderbolt controllers with 4x. The CPUs used in the 13" model all have 12 lanes, the ones in the 15" model have 16 lanes. So for the top-of-the-line model this could be 4x for each of the Thunderbolt controllers, 4x for the GPU, 2x for the SSD, 1x for Wifi, 1x for HD Audio?

Business as usual with macOS. The other day I was browsing the ocspd source code. Turns out it calls openssl using system(). So openssl is officially deprecated on macOS and yet they're using it internally to handle certificates?! And there's an enlightening comment:

    /* Given a path to a DER-encoded CRL file and a path to a PEM-encoded
     * CA issuers file, use OpenSSL to validate the CRL. This is a hack,
     * necessitated by performance issues with inserting extremely large
     * numbers of CRL entries into a CSSM DB (see <rdar://8934440>).

http://opensource.apple.com/source/security_ocspd/security_o...

ocspd was introduced with 10.4. A decade ago. And that's really the problem with macOS: There's no refactoring of old hacks, but rather just bolting on of ever more new stuff.

This is an issue in the kernel. You don't report this to the distro vendor but to the appropriate kernel mailing list. In this case the interface to user space is broken AND it's a regression, so it would be appropriate to cc: Linus. Chances are high it's fixed in the next -rc release (i.e. within a week).

You can download firmware updates for lenses as well as camera bodies, and with MFT there's even an open standard for interchangeable lenses/bodies across manufacturers.

Birthday paradox.

Totally off base. BSD versus GNU conventions.

In German industry, there's plenty of angst that incumbents might be displaced by IT companies. E.g. Apple introduced their watch a bit more than a year ago and now they're dominating the smartwatch market, traditional swiss watchmakers can hardly get a foot in this space. So companies are trying to buy whatever they can afford in the hope of not ending up left behind. Porsche recently bought a stake in a parking app startup [1]. It all feels a bit like the dotcom era when so-called "old economy" companies frantically shelled out money to acquire "new economy" startups. Or like the stage shortly before the credit crunch in 2007 when dumb German Landesbanks piled subprime papers onto their balance sheet [2].

[1] http://www.intelligentmobilityinsight.com/news/ClB/Porsche-t...

[2] http://archive.fortune.com/magazines/fortune/fortune_archive...

I'm not surprised at all that BIND performs poorly, look at those graphs (granted this is for authoritative servers, but says a lot about BIND's performance in general): https://www.nlnetlabs.nl/blog/2013/07/05/nsd4-performance-me...

I'd stick with Unbound. There are a lot of knobs to fiddle with in the config. Be sure to compile against libevent so that you can use the highly scalable epoll as a backend (assuming you're on Linux). Turn up all the limits for cache size etc. Disable DNSSEC validation if you don't care about spoofed records. Ask on the mailing list if you need help, Wouter and his colleagues are very nice and respond very quickly.

For this to be correct, all records to be resolved would need to have completely disjunct labels from the root down. Which they cannot if they are indeed in the millions.

Ugh, so public resolvers are flooded with requests? Wouldn't it make much more sense to set up a local caching resolver like unbound and feed your queries to it? It would be much more considerate towards the public resolvers and also use less of your own bandwidth.