blumentopf

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>).

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.

I've had an Intel S3500 brick within 4 weeks and a SanDisk Extreme Pro start to show occasional I/O errors after a few months. The latter doesn't just lead to bit rot, but unreadable files. With ZFS I was able to identify those with a quick zpool scrub. Which shows how valuable checksumming is even in the absence of ECC memory. At least according to my anecdotal experience, flash is much more flakey than conventional hard disks, so the assumption that stuff just doesn't happen seems ludicrous.

So they still have a team working on ZFS? Could the anonymous "ilovezfs" involved with OpenZFSonOSX and coming from a California IP address be part of this team?

https://mobile.twitter.com/ uses a much saner and faster UI.

I assume the videos available on iTunes are encoded in an H.264 profile that can be decoded entirely on the GPU, so the CPU would indeed be mostly idling during playback.

There's some progress on the keyboard and trackpad, but it's still a WIP:

http://comments.gmane.org/gmane.linux.acpi.devel/82025

At least a patch to recognize the WildcatPoint PCH is in 4.6:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

I'm awed by your work but this is really an abomination:

"Unfortunately, company policy prohibits me from sharing the actual code." (http://marc.info/?l=linux-ext4&m=145007745502639&w=2)

- Implementation-diverse nameservers

Use multiple implementations, e.g. NSD/BIND for authoritative servers and Unbound/BIND for resolvers, to mitigate against implementation-specific bugs and vulnerabilities.

Hopefully the kernel driver rewrite pays off

It's not a rewrite, amdgpu is a fork of radeon with support added for newer GPUs plus some cleanups and older code stripped off. Which means if you're submitting fixes, you need to submit it to both drivers (at the moment the two patches you'd submit will usually be identical.)

Oracle's ZFS encryption is susceptible to watermarking attacks: http://lists.freebsd.org/pipermail/freebsd-hackers/2013-Sept...

The "more advanced" claim is certainly disputable but OpenZFS has a larger and rapidly growing user base. The ZFSonLinux and OpenZFSonOSX ports in particular are bringing loads of new users to the table, and that means more testing, more contributors, and in the long run more features. (I've also become an occasional ZoL contributor that way.)

Mercedes-Benz was in a similar position in 1997 when the newly introduced A-Class flunked the moose test. After a short period of denial they hired a specialist (Armin Töpfer), halted production for several months and retooled all cars with a different suspension and ESP. The ESP wasn't even necessary but put competitors under pressure to include it in their compact class cars as well. The crisis was eventually overcome and the car sold very well in Europe (1.1 million produced in 7 years). There's a fascinating book (sadly in German only) on this called "Die A-Klasse: Elchtest, Krisenmanagement, Kommunikationsstrategie." (http://www.amazon.com/dp/3472037997)