Hi AC,

This is sort of self-contradictory, so I don't really need to respond to it directly. I just want to point one thing out. I can't afford to work for any company as less than a C-level employee. It would be a salary cut from my current business.

Not to mention that I'd not like it.

An AC talking about balls. Pathetic.

Right. I didn't even bother responding to the taunts.

Coward really means coward. I am sorry for the folks who are afraid that their employer will take a dislike of what they post, but for them we have handles.

I can't say I'm happy about what's happened to Debian. Having Ubuntu as a commercial derivative really has been the kiss of death for it, not that there were not other problems. It strikes me that the kernel team has done better for its lack of a constitution and elections, and Linus' ability to tell someone to screw off. I even got to tell him to screw off when he was dumping on 'Tridge over Bitkeeper. Somehow, that stuff works.

IMO, don't create a happy inclusive project team full of respect for each other. Hand-pick the geniuses and let them fight. You get better code in the end.

This actually has something to do with why so many people hate Systemd. It turns out that Systemd is professional-quality work done by competent salaried engineers. Our problem with it is that we're used to beautiful code made by geniuses. Going all of the way back to DMR.

It really does look like Jomo did post this article, and it refers to another article of his.

What isn't to like about Ubuntu is that it's a commercial project with a significant unpaid staff. Once in a while I make a point of telling the unpaid staff that there really are better ways that they could be helping Free Software.

It's just that I object folks who would be good community contributors being lured into being unpaid employees instead.

Say how do feel about idiots working for corporations contractually enmeshed with the US military-industrial-surveillance complex. Why no spittle-laced hate for them?

The GNU Radio project was funded in part by a United States intelligence agency. They paid good money and the result is under GPL. What's not to like?

Keep all of the idiots that want to work for a millionare for nothing. Fire the others.

Anyone with sense has by now joined a non-profit project.

The EU rule requires that you either provide a Micro USB port or an adaptor. A USB-C port and a USB-C to Micro USB adaptor would fit that, though there is an effort underway to allow just USB-C. The design requirements of USB-C included making chargers and adaptors very cheap (there's an interesting story of how the two resistors that it uses to select the voltage were chosen).

That's an explicit requirement for USB-C. For Micro USB, I've seen several devices where the port is damaged, but never seen one cable with a damaged connector.

If your monitor / TV uses the HDCP DRM crap than it adds a few frames latency and so you need the audio to be delayed in the monitor by the same amount, even if it's going to external speakers. This was the main reason for pushing audio into the HDMI spec, though there are some other processing steps (e.g. upscaling using inter-frame information) that can also introduce latency and make being able to delay the audio by a fixed, display-controlled, amount useful.

If you're buying an Apple screen, then it will have the USB hub in the display and will provide power. If USB-C connectors become mainstream, then I'd hope that other manufacturers will too.

No, they require a dongle and Apple will sell you one for $80. Just as existing Apple laptops require a dongle to talk to VGA projectors and Apple will sell you one for $20, meanwhile third party vendors will sell you one for $5. Apple always charges an insane amount for dongles.

You might want to look up what an IOMMU is and for how many generations of x86 processors they've been a standard feature.

Nope, no cache flush for compare and exchange. Modern CPUs use a modified version of the MESI protocol, where each cache line has a state associated with it (modified, exclusive, shared, invalid in MESI, a few more in modern variants). When you do a compare and exchange, you move your copy of the cache line into exclusive state and everyone else's into invalid. Before this, you must have the line in the shared state (where multiple caches can have read-only copies). When another core wants access to the memory, it will request the line in shared state. If another cache has it in its exclusive state, then the exclusive line will be downgraded to shared and a copy of its contents sent to the requesting site.

If atomic operations had to go via main memory then they would be significantly slower than they are and would be a huge bottleneck for multicore systems.

They don't flush, no. They will add memory fences, which will generate cache coherency bus traffic, but won't trigger a write back to main memory (modern CPUs can snoop the cache of other cores, so the data will be sent cache to cache).

The main reasons for flushing the cache are:

• If you have some non-volatile DRAM and want to ensure consistency.
• If you're doing DMA on anything other than the latest Intel chips, so that the DMA controller will see the data that you've flushed from the cache.
• If you're writing a JIT compiler or some other form of self-modifying code (including a run-time linker) and need to ensure that i-cache and d-cache are consistent (I think x86 does this automatically, but I could be wrong).
• If you're writing a crypto algorithm and want to make side-channel attacks via the cache difficult.

Compare-and-exchange and mfence would be doing cache flush all of the way to RAM and global cache line invalidation, wouldn't they? So, they can potentially be used to hammer too.