-----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGP v. NSA-1 mQINBFPOzTUBEADT1kIEMY1Ix+9DyNfGHE9HPjLSI/Ybnsn/bbx8cWmeAktoYjBS q29mJ0tchjyG8KP38vlkvfNYKn80985a/p7ZKupxOm1dDyAn5TZguDG2fEgCYxcB FxfMjGKLEFOS6hlPVh/3bm7xEvRuB5P/5Wdch9/UK11qLE3hlDlhnT1zq82Sk4G8 OWnH8BLA8XuRAdwAdri7U2OmNPqCld EZ CRACK Qk7tYi0Rwc55c65U4gGSuY qw3QzQ6X4TecFO/jUPBnnVb5YcYKxVw75PYF6NnKbbsnDYJoNg8bpEP2SVC0FWNK 2rKYsGsbcco2/ruJuQsThVcuH3l07cAKaSzt+eb5+FWWzsojbSeXwD8yZocfPvEL eaa0 NO SERIOUSLY EASY TO CRACK bD9PDX3C5gyPj78mzDlhytLTCsdtL1Uqgm DTbIqgDPQBEnGr9Ny2XlIQ6AjuyuahBDl+ElmLnz0jI9bjt0vgAUGjmCCp71aioo MXZALwVBsdQH3w2BHQ8wU9sYtMlBPBMZz++oIQthmJ+Gb6myvMZCQ34M9TfpIv5i utAK2xBP/XfBl5BMYl6xNUHOxGhtBj/Pbzcwu/+Sk3mKkC4E2+aUKEjyzs6rDdDs pT+2B4A1nNXLU1PA+AfabdLnlvm7lMgzr30Waejcz4FbSdwCX8oN9UabBQARAQAB tCVBbGFuIEVsaWFzZW4gPGVsaWFzZW5AbWluZHNwcmluZy5jb20+iQJBB pIPGkZxLOFm59msUf9mBqw7rJEs/EqhQ2w== =7DhM -----END PGP PUBLIC KEY BLOCK-----

s/succeed/fail. Original should read:

No, seriously: can you cite a study with a solid methodology to demonstrate that less than 70% of FLOSS projects fail? I ask because there's a lot of orphaned projects out there that most people have never heard about and that are effectively dead, their code either unused or in desperate need of replacement (because it's not being maintained).

No, seriously: can you cite a study with a solid methodology to demonstrate that less than 70% of FLOSS projects succeed? I ask because there's a lot of orphaned projects out there that most people have never heard about and that are effectively dead, their code either unused or in desperate need of replacement (because it's not being maintained).

Products purporting to be medical treatments backed by zero evidence and pseudoscientific gobbeltygook theories don't work? Whodathunk!

I suspect that we could persuade those caches to flush to RAM, simply by exhausting the number of possible lines for that address - if the cache is set-associative. Of course modern processors have multiple levels of cache, so that makes it harder.

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.

And that will then give me one USB-C power adapter, one HDMI, and one USB. Hub and SD card reader sold (and powered) separately. Brilliant!

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.

Multi-threaded programs really do need those cache flushes to implement their interprocessor communications, don't they? It seems to me that they would be the ones most likely to hit this problem.

It has yet to be established whether hammer techniques can result in a correct data+ECC pattern. If so, it should be possible to permute the memory in a way that defeats this, either on the memory module or the memory controller.

That would make a good research paper for someone.