Intel Responds to Security Research Findings - <AUTHOR> https://newsroom.intel.com/news/intel-responds-to-security-research-findings/ <comment><USER2> This is probably one of the poorest and most defensive PR pieces I've read from a company in a long time, and it does not really make me sympathetic to them at all.

> Intel and other technology companies have been made aware of new security > research describing software analysis methods that, when used for malicious > purposes, have the potential to improperly gather sensitive data from > computing devices that are operating as designed. Intel believes these > exploits do not have the potential to corrupt, modify or delete data.

This is deceptive. It very quickly acknowledge the confidentiality aspect, but then claims that is "operating as designed" and then immediacy try to damage control by pointing out what the exploits cannot do (corrupt/modify/delete).

> Recent reports that these exploits are caused by a "bug" or a "flaw" and are > unique to Intel products are incorrect. Based on the analysis to date, many > types of computing devices — with many different vendors' processors and > operating systems — are susceptible to these exploits.

This is deceptive. In the first sentence it combines two statements: 1) bug/flaw in Intel products and 2) that it is unique to Intel. In the rest of the paragraph it then claims that the previous statements are incorrect, but only addressing the second point.

> Intel is committed to product and customer security and is working closely > with many other technology companies, including AMD, ARM Holdings and > several operating system vendors, to develop an industry-wide approach to > resolve this issue promptly and constructively. Intel has begun providing > software and firmware updates to mitigate these exploits. Contrary to some > reports, any performance impacts are workload-dependent, and, for the > average computer user, should not be significant and will be mitigated over > time.

This is deceptive. It immediately mentions AMD to give the impression that AMD also suffer from the problem.

It then goes on with a straw man about performance impacts ("contrary to some reports").

And then mentions "average computer user" whereas the real problem is obviously not average computer users. Again, deceptive.

<comment><USER3> I could be wrong, but I take the "bug/flaw" language to mean this: the processor is doing exactly what it was designed to do (unlike the Pentium FDIV bug, for example). A new class of exploit was recently discovered, and these CPUs are vulnerable to this new exploit. But there was no bug in how these CPUs were implemented, and the only design flaw is that they failed to withstand a new class of exploit that was not known at the time they were designed.

(I don't have any information that could confirm/deny this, it's just how I interpret their verbiage).

I don't get the sense that they are trying to deceptively contradict only part of the previous statement.

<comment><USER4> It's kind of semantics though isn't it? If I write a piece of software that follows the spec and fulfils the customer's need, but then someone tries to do something with it that we hadn't thought of and that results in a security hole... around here we call that a bug, a flaw, something we missed. Maybe it's reasonable to have not spotted the bug, but that wouldn't make it not a bug/flaw.

<comment><USER3> Yeah I agree there is a line there somewhere. If someone sells you a safe and it can be opened with a ballpoint pen, that seems like a flaw. If someone sells you a safe and it can be opened with a military grade laser, that's sort of expected. If someone sells you a safe and it can be opened with a cheap consumer gadget, but that gadget is complex and was unforeseen when the safe was designed, what do you say about that? The last one seems like the closest analogy.

Another example: would you say that MD5 is buggy/flawed?

I guess overall I think this is fair to call a "flaw" but not a "bug."

<comment><USER4> > I guess overall I think this is fair to call a "flaw" but not a "bug."

Yes I agree, it's not a bug in the sense of a silly mistake that slipped through development and testing. It's a flaw / attack-vector that no-one thought of... until now.

<comment><USER5> Reminds me of dieselgate. "Our product is ok unless operated out of spec" didn't work, iirc.

</comment></comment></comment></comment></comment></comment><comment><USER6> > Intel believes these exploits do not have the potential to corrupt, modify > or delete data.

Reading from kernel memory [edit: from unprivileged apps] is still a severe security issue though, right? This sounds like they're trying to downplay that hard, especially with the "operating as designed" phrase.

> Recent reports that these exploits are caused by a "bug" or a "flaw"

[Unprivileged] reading from kernel memory is something of a flaw, no? Fair point about not being Intel specific though.

> any performance impacts are workload-dependent, and, for the average > computer user, should not be significant

Hearing echos of Intel's early FDIV response along the lines of "the average computer user doesn't need perfectly accurate division"...

> However, Intel is making this statement today because of the current > inaccurate media reports.

This and similar sentences has a strange tone to me, it sounds almost grumpy. I guess it got rushed out.

<comment><USER7> That "bug" or "flaw" sentence is very carefully worded. It's like:

        bool bug = true;
        bool flaw = true;
        bool uniqueToIntel = false;

        bool reportsAreTrue = (bug || flaw) && uniqueToIntel;

        // reportsAreTrue == false!

<comment><USER4> Yes it's designed in such a way that in a court of law they could claim they were announcing a bug, but most or many people reading it would come to the opposite conclusion. In other words it's deceptive.

</comment></comment></comment><comment><USER8> What a scummy, dishonest response.

\- Saying it's not a 'bug' or 'flaw' = lie.

\- Cold naming AMD and ARM in the post, I'm certain not just to throw their names in the ring but also for SEO ranking and relationships.

\- Failing to address the root cause, how it came to be and provide other technical references.

And let's not forget - Intel's CEO sold his stock.

\--

* Note: "AMD chips are affected by some but not all of the vulnerabilities. AMD said that there is a "near zero risk to AMD processors at this time." British chipmaker ARM told news site Axios prior to this report that some of its processors, including its Cortex-A chips, are affected." \- [http://www.zdnet.com/article/security-flaws-affect-every-int...](http://www.zdnet.com/article/security-flaws-affect-every-intel-chip-since-1995-arm-processors-vulnerable/)

</comment><comment><USER9> It comes across as fairly defensive. Presumably the statement was hastily put together, but it's not really the tone you want to strike when you have a lot of worried customers wondering what is going on.

> Intel believes its products are the most secure in the world and that, with > the support of its partners, the current solutions to this issue provide the > best possible security for its customers.

A rather bizarre statement of nothingness, and also an odd thing to say in a statement that just named AMD and ARM.

> Contrary to some reports, any performance impacts are workload-dependent, > and, for the average computer user, should not be significant and will be > mitigated over time.

It's interesting to note what it doesn't say – as it would seem to imply that for some workloads the performance impact will be significant.

<comment><USER10> "Workload dependent" clearly implies (despite the spin they are trying to put on it) that some users will be worse off than others. What isn't my at all clear (to me) is what they mean by "will be mitigated over time". Are they implying that when we buy new professors (from them) there'll be a hardware fix that won't require the performance-sapping patch?

Quoting ARM and AMD is really a bit pathetic too, IMHO, especially if it turns out that AMD chips are immune to the flaw.

<comment><USER11> > Quoting ARM and AMD is really a bit pathetic too, IMHO, especially if it > turns out that AMD chips are immune to the flaw.

The official fix for this in the Linux kernel has a comment that literally says to assume all x86 processors suffer from the same issue and will disable KPTI for all x86 processors, including AMD.

There's an AMD-specific patch that I saw floating around that keeps the setting enabled for AMD processors, but I'm not sure if it made it into the mainline.

<comment><USER10> I don't know if it's possible to see who contributed that patch (yet), but I'm cynical enough to half-expect that the "assume all x86 processors are insecure" patch might come from an Intel engineer...

<comment><USER11> I would not be surprised at all, considering the patch I saw for the AMD processors was literally a one-line if statement around the set cpu insecure flag that added a check for AMD processors.

Google is failing me or I'd post a link.

</comment></comment></comment></comment></comment><comment><USER12> Lots of people being critical of this response. I think it's pretty good, and have been on the disclosing side of this equation many times.

Admits responsibility and says their current course of action (working with key stakeholders). Addresses concerns of the workaround. Has a timeframe for future updates. Has a call to action for what you should be doing next. To those of you pointing out that this is PR, you're right but that's not a problem...

Short and sweet and has it all. If anything, it is a day late but monstrous organizations probably had a lot of bureaucracy to cut through.

People are so reactionary and quick to throw any company with a security issue under the bus, without ever having been on the other side of the table. The reality is issues happen to everyone and Intel wants to fix it.

<comment><USER13> It's also manipulative, mentioning AMD and ARM for no other reason to make people think those also have the flaw.

<comment><USER14> ARM may have a flaw: [https://lwn.net/Articles/740393/](https://lwn.net/Articles/740393/)

</comment></comment></comment><comment><USER15> > Based on the analysis to date, many types of computing devices — with many > different vendors' processors and operating systems — are susceptible to > these exploits.

Yes, many. Not your biggest competitor though, AMD. They're fine. And that may be the point you're trying to downplay here.

> Intel believes its products are the most secure in the world

Again, your biggest competitor, AMD, does not have this flaw. So precisely how is Intel the 'most secure in the world' if your biggest competitor is more secure than you?

The title of this post should be 'Intel _PR_ Responds to Security Research Findings'.

</comment><comment><USER16> It's always interesting when you see a damage control statement that basically boils down to "contrary to what you may have heard, <exactly the same caveats you've already heard>". It's a subtle kind of straw man, where you reassure your audience by listing the same mitigating facts they've already heard, but act as if those facts have been previously omitted.

I guess the goal is to produce the affect of reassurance when you don't actually have any substantive reassurance to offer. I wonder if this works, in general? My sense is that it always smells like bullshit, but I wouldn't necessarily recall instances where it didn't.

</comment><comment><USER17> > Recent reports that these exploits are caused by a "bug" or a "flaw" and are > unique to Intel products are incorrect.

Isn't the quote above which is from the Intel press release a blatant lie? All the articles I have seen say this only affects Intel processors. Not AMD processors nor, ARM, MIPS, SPARC or PowerPC chips. Did I miss something or is Intel lying in it's press release.

<comment><USER18> We won't know until we know what the actual bug is. All we know is that people are writing patches for Intel chips, and what those patches do.

It's very possible that other processors are affected by the same issue in some different way that doesn't require this set of patches to mitigate.

<comment><USER19> We know that AMD is not affected:

[https://lkml.org/lkml/2017/12/27/2](https://lkml.org/lkml/2017/12/27/2)

<comment><USER18> We know that "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against." E.g. that AMD does not need the patch that Intel does. That is not the same as saying AMD is not affected at all.

We do not know what the actual bug that prompted this activity is. Nobody has revealed that information. It is possible that the bug affects AMD also but does not require this patch.

<comment><USER19> The followup sentence: "The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."

That is a pretty specific reference to the root of the problem, and a pretty clear indication that AMD's design decisions protect against whatever the attack is. Sure, we may find out that there is more to the attack than just speculative memory references, but so far what we have seen suggests a fairly specific vulnerability (that just happens to involve the particular design choices of a dominant chipmaker).

<comment><USER18> And, 17 hours later, we now know that there were three distinct vulnerabilities, of which one applies to AMD.

[https://googleprojectzero.blogspot.com/2018/01/reading- privi...](https://googleprojectzero.blogspot.com/2018/01/reading-privileged- memory-with-side.html)

<comment><USER19> Only under specific software configurations that are not enabled by default, or confined to a userspace single process (which is bad for web browsers running Javascript but not nearly as bad as the Intel-specific attacks). So while AMD is somewhat vulnerable, the most severe and easiest to exploit vulnerabilities are pretty specific to Intel. In a pedantic sense you were right, AMD chips are _affected_ , but it is literally not on the same level as for Intel chips.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20>
      Intel believes these exploits do not have the potential to corrupt,
      modify or delete data.

Followed by...

      Check with your operating system vendor or system manufacturer
      and apply any available updates as soon as they are available.

This press release is a minefield. There are whole paragraphs devoted to say nothing.

<comment><USER21> Somebody please correct me if I'm wrong, but I believe they're basically saying "These exploits _do_ have the potential to read data."

<comment><USER22> There are not saying it explicitly, which they should.

<comment><USER23> Yeah, sort of "Don't worry I'm not going to shoot you in the torso, arms or legs."

</comment></comment></comment></comment><comment><USER24> > Contrary to some reports, any performance impacts are workload-dependent, > and, for the average computer user, should not be significant and will be > mitigated over time.

Given the lack of any facts, evidence, or details in the press release, how is anyone supposed to take Intel seriously?

<comment><USER25> Devils advocate.

Workload dependence... average user... not significant:

A lot of users probably see "30%" and will assume the worst. There really isn't a lot of evidence of how much an average consumer will be affected. Pretty sure your average consumer isn't running pgbench all day. Hell, I'm willing to bargain 90% of servers (I really want to say more) are over- provisioned by 30% or more.

Mitigated over time:

Kernels are getting out safe patches ASAP, performance be damned. With more time to be careful, performance can be clawed back. And/or CPUs are upgrade and features such as PCID mitigate perf losses.

<comment><USER26> The problem is that "average users" pointedly does _not_ include server and DB admins. I don't know about anyone else, but that's what I'm sweating over. We already know high I/O is what takes the biggest hit. I want to know what kind of a hit I can expect on our MSSQL VMs, and I am pretty sure the answer is not "minimal."

<comment><USER27> If you're running SQL in a VM ... I'm pretty sure I know how to improve your performance by 30%.

<comment><USER26> If you mean run on bare metal, not happening, due to MSFT's outrageous core pricing model. They force you to license every core available to the OS, whether you need the capacity or not. Running in a VM is the only way of getting around that requirement.

If you mean run something other than MSSQL — also not happening. Vendor lock in.

</comment></comment></comment></comment></comment><comment><USER28> Interesting use of language:

'Recent reports that these exploits... are unique to Intel products are incorrect... Intel is committed to product and customer security and is working closely with many other technology companies, including AMD...'

Someone new to the issue might think AMD also has this problem.

Similarly (replacing the first elision in the above quote):

'Recent reports that these exploits are caused by a "bug" or a "flaw"... are incorrect.'

So, working just the way you want it to, eh, Intel? But then, why would you describe them as exploits?

<comment><USER25> Not defending Intel here, but devils advocate...

You will find many clients asking how to disable, for example, the Linux patch. Linux is releasing with a flag to disable it, so there is some merit. Why would you want that? There are a lot of times you trust everything running on your box and don't need to take the perf hit.

Intel (and possibly other archs/families) found a perf win that ends up having security implications. A perf nonetheless. If you're willing to bet on your userspace not reading kernel pages, does Intel have a feature for you!

<comment><USER28> Intel is certainly entitled to make and promulgate an objective assessment of the impact of the problem, but a problem is still a problem even if it doesn't affect everyone.

<comment><USER25> Who says they won't?

The issue is embargoed, but that's, as usual, not keeping everyone from speculating. That's fine too, but also realize the layman (even people in this thread) is getting pummeled with ideas like "my new laptop is going to be 30% slower tomorrow; WTF!!!"

<comment><USER28> > Who says they won't?

Not me. My comments are restricted to certain things Intel _did_ choose to say.

And as you are concerned about rumor and disinformation, I cannot imagine you are pleased with Intel's insinuation that AMD processors are also affected.

UPDATE: It seems AMD may be being misleading in this case...

</comment></comment></comment></comment></comment><comment><USER29> >Recent reports that these exploits are caused by a "bug" or a "flaw" and are unique to Intel products are incorrect.

From the English, this report makes it seems like there was no bug and no flaw. However, they say that ((bug || flaw) && only_intel) is false, but I have seen that AMD was not impacted.

Seems like this is a bug or flaw, since they are addressing it soon. They make it seem like everyone should be working in the same boat to address this, but they are just trying to un-distance themselves from their competition.

<comment><USER30> > since they are addressing it soon. They make it seem like everyone should be > working in the same boat to address this

I can assure you that indeed "everyone is working in the same boat to address this", and has been doing so for months, across multiple OS and processor vendors. It's already public that Microsoft and Apple have also implemented page table isolation, and certainly Intel didn't name-drop AMD and ARM carelessly in the press release.

<comment><USER31> > and certainly Intel didn't name-drop AMD and ARM carelessly in the press > release.

I'm sure it wasn't careless, but they are (from all accounts I have read) blatantly lying. Intel isn't known for above board practices. They will do what it takes to win - period.

Name dropping their competitors (to me), honestly shows me how dire of a situation this is. If it wasn't, they wouldn't feel the need to defend themselves and say, "well look at everyone else".

<comment><USER32> According to project zero report, a lot more than intel CPU's are affected by this issue. See relavant HN post here

"These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them."

[https://news.ycombinator.com/item?id=16065845](https://news.ycombinator.com/item?id=16065845)

</comment></comment></comment></comment><comment><USER33> > Intel believes these exploits do not have the potential to corrupt, modify > or delete data.

No, but they _do_ have the potential for privilege escalation or credential exfiltration, which in turn _do_ grant the potential to corrupt, modify and delete data.

</comment><comment><USER34> Oh god, it's got a logo: [https://meltdownattack.com](https://meltdownattack.com)

"Which systems are affected by Meltdown?

Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.

Which systems are affected by Spectre?

Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors."

</comment><comment><USER35> > Intel believes these exploits do not have the

> potential to corrupt, modify or delete data.

That's strange, because I am pretty damn sure that with a working read_kernel_byte(u64 addr) primitive, I can gather enough info to corrupt, modify, or delete a lot of things.

</comment><comment><USER36> Something "operating as designed", if designed incorrectly, is still broken.

Something that doesn't "corrupt, modify or delete data" but _does_ "leak" sensitive data to potential attackers, is still a serious exploit.

This is worryingly full of error-by-omission statements.

</comment><comment><USER37> Seriously? Their response is "It's not fair! ARM made the same mistake so you can't blame us!"?

</comment><comment><USER38> Wow what a deceptive defensive response by intel. Nobody is concerned about data being deleted, it's the unprivileged access thats the issue here.

</comment><comment><USER39> > Intel and other vendors had planned to disclose this issue next week when > more software and firmware updates will be available.

So coordinated patches to hit next week then.

</comment><comment><USER40> Intel's investor call [1] is underway and they are describing the attack vector(s). Rogue data load seems to be most concerning issue according to Intel.

Intel thinks this will need firmware and operating system updates to fully mitigate.

[1] [https://www.intc.com/investor-relations/investor- education-a...](https://www.intc.com/investor-relations/investor-education- and-news/investor-news/press-release-details/2018/Intel-Holds-Investor-Call- Regarding-Security-Research-Findings/default.aspx)

</comment><comment><USER41> This is not a security report, this is PR.

Among other things, it implies, without explicitly naming them, that AMD, ARM and OS vendors are being directly affected while most information out there point out it's merely an Intel issue.

<comment><USER42> It does explicitly name them:

> Intel is committed to product and customer security and is working closely > with many other technology companies, including AMD, ARM Holdings and > several operating system vendors, to develop an industry-wide approach to > resolve this issue promptly and constructively.

<comment><USER43> I think what the parent comment means is that they're explicitly named, but not explicitly called out as being affected, just heavily implied.

</comment></comment></comment><comment><USER44> > Recent reports that these exploits are caused by a "bug" or a "flaw" and are > unique to Intel products are incorrect.

A possible reading of "not a bug or a flaw" could be "works as designed", or better, "works according to the spec". The spec probably never considered cache timing side-channels (if that's what the issue is) as something to be defended against.

</comment><comment><USER45> Wouldn't it be wonderful if we could buy the latest Xeons at a 30% discount? ;-)

<comment><USER46> That's why they're the dominant player. Because even when a horrible defect is exposed people still desire the product over the competition.

<comment><USER47> They would have to screw up really bad for people to go to AMD. I think that may never happen.

<comment><USER45> People who need to get absolutely the most bang for the buck have no ties to any given supplier. Cray deployed one of the first Opteron-based supercomputers.

Intel got lots of datacenter business simply by having a better (as in "better suited to our demands") product than anyone else in the segment. AMD has a short time window to make some large sales. They have until Intel ships a microcode fix or a new line of processors.

<comment><USER48> > They have until Intel ships a microcode fix

Sounds like microcode fix isn't possible.

<comment><USER45> Then the next generation it is.

It's a 5-30% performance boost without even a major change. :-(

</comment></comment></comment></comment></comment></comment><comment><AUTHOR> Project Zero has published a detailed writeup on this. It's worth noting (in the context of Intel's response) that the P0 post confirms that AMD and ARM CPUs are also affected:

 _" Variants of this issue are known to affect many modern processors, including certain processors by Intel, AMD and ARM. For a few Intel and AMD CPU models, we have exploits that work against real software. We reported this issue to Intel, AMD and ARM on 2017-06-01"_

[https://googleprojectzero.blogspot.com/2018/01/reading- privi...](https://googleprojectzero.blogspot.com/2018/01/reading-privileged- memory-with-side.html)

Edit: Discussion [https://news.ycombinator.com/item?id=16065845](https://news.ycombinator.com/item?id=16065845)

</comment><comment><USER49> Do we know the actual bug yet? I sort of assumed it was a timing attack on KASLR rather than a leak of traditional kernel data.

Although I guess that there would have been cheaper mitigations like mapping an empty page to all of the other KASLR slots rather than doing a full world switch in that case...

<comment><USER6> It's true nobody knows what the actual bug is, but I was working with what Ars Technica described: "If the problem were just that it enabled the derandomization of ASLR, this probably wouldn't be a huge disaster... The industry reaction... suggests that it's not just ASLR that's defeated and that a more general ability to leak information from the kernel has been developed." [https://arstechnica.com/gadgets/2018/01/whats-behind-the- int...](https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design- flaw-forcing-numerous-patches/)

<comment><USER49> I guess I've stopped reading security articles by Peter Bright ever since he spent a whole series of articles shitting on project zero for disclosing vulnerabilities after the 90 day disclosure window when Microsoft had just been sitting on the bug.

[https://arstechnica.com/information- technology/2015/01/googl...](https://arstechnica.com/information- technology/2015/01/google-drops-more-windows-0-days-somethings-gotta-give/)

</comment></comment></comment><comment><USER50> Additional information (PDF)[1] released as part of the Investor relations call[2] today:

[1][https://s21.q4cdn.com/600692695/files/doc_presentations/2018...](https://s21.q4cdn.com/600692695/files/doc_presentations/2018/Side- Channel-Analysis-Security.pdf)

[2][https://www.intc.com/investor-relations/investor- education-a...](https://www.intc.com/investor-relations/investor-education- and-news/investor-news/press-release-details/2018/Intel-Holds-Investor-Call- Regarding-Security-Research-Findings/default.aspx)

</comment><comment><USER51> "Recent reports that these exploits are caused by a "bug" or a "flaw" and are unique to Intel products are incorrect."

The 'and' in this sentence makes this assertion correct and is very deceptive.

</comment><comment><USER52> The Register translation of the Intel spin is quite amusing:

[https://www.theregister.co.uk/2018/01/04/intels_spin_the_reg...](https://www.theregister.co.uk/2018/01/04/intels_spin_the_registers_annotations/)

</comment><comment><USER53> This fails all 3 points on Scott Galloway's checklist of how to respond to a crisis. [https://www.youtube.com/watch?v=PB- AyvgE8Ns](https://www.youtube.com/watch?v=PB-AyvgE8Ns)

</comment><comment><USER54> this is a denial from PR and a poor one at that.

</comment><comment><USER55> What a strange response.

>many types of computing devices — with many different vendors' processors

Really? Like who?

</comment><comment><USER56> This probably means software is using CPUs in a way that they weren't meant to. To me, it is funny to watch how virtualization and JIT compilers changed the game for CPU vendors who were used to making CPUs mainly for compiling and running software on a single host instance. Since we have direct virtualization support now, I suspect we are going to get a JIT support in CPUs soon (if we didn't already).

</comment><comment><USER57> > Intel believes its products are the most secure in the world and that, with > the support of its partners, the current solutions to this issue provide the > best possible security for its customers.

* _sad trombone_ *

They're obviously not the most secure, as the Project Zero research shows. The whole press release has to be one of the most dismissive and snobbish PR pieces I've seen from a large corp.

</comment><comment><USER58> > Intel is committed to the industry best practice of responsible disclosure > of potential security issues

No, the industry best practice is _coordinated disclosure_. The term "responsible disclosure" is a misnomer that we'd be far better off if we, as a society, stopped using it.

[https://adamcaudill.com/2015/11/19/responsible-disclosure- is...](https://adamcaudill.com/2015/11/19/responsible-disclosure-is-wrong/)

<comment><USER59> Do you think the executive speculation has been well coordinated? :)

</comment></comment><comment><USER60> > Intel believes its products are the most secure in the world

Well, lol. It's a bit rich to say this in a vulnerability disclosure statement.

</comment><comment><USER61> This is a good time to bring up Intel ME. It is a black box and has already proven to have security issues. There maybe be more we do not know of. This paging flaw is accidental however Intel ME is designed to have unfettered control over all parts of the machine.

If Intel really believed in making secure products and believed in secure computing, they would remove Intel ME.

</comment><comment><USER62> > Intel believes its products are the most secure in the world

[https://security- center.intel.com/advisory.aspx?intelid=INTE...](https://security- center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr)

<comment><USER47> "The most secure in the world" does not mean "flawless". Thinking like that is pretty dangerous (and silly)

<comment><USER62> I haven't seen any articles about AMD PSP security vulnerabilities yet, but there's a new one about IME every other month. If Intel truly is the most secure in the world, why are their CPUs riddled with security bugs big enough to drive trains through (IME has de facto become a integral part of Intel CPUs) and where are the news about non-Intel CPUs with similar bugs?

</comment></comment></comment><comment><USER63> >Intel believes its products are the most secure in the world

After the Intel ME mess? I'm not so sure.

</comment><comment><USER64> If they believe it's not a threat, why the haste from the Kernel devs to fix KAISER?

</comment><comment><USER65> Corporate-speak -> human-speak:

\- Yes, the flow/bug exists

\- We don't yet know if it can be successfully exploited at scale.

\- It's quite possible that other CPU designs are affected as well, we don't have concrete data though. AMD and ARM have already started looking into the issue.

\- Patches will be coming from as many manufacturers and as many OS-vendors as we can convince this is serious on a short notice.

\- The patches do affect performance, often significantly, but there's nothing we can do in such a short period of time. We can only hope we can come up with better solutions down the line.

</comment><comment><USER66> [https://www.youtube.com/watch?v=pdFl__NlOpA](https://www.youtube.com/watch?v=pdFl__NlOpA)</comment>


Splitting Equity Among Founders - <AUTHOR> http://www.themacro.com/articles/2015/12/splitting-equity-among-founders/ <comment><USER2> Previous discussion: [https://news.ycombinator.com/item?id=10665113](https://news.ycombinator.com/item?id=10665113)

</comment><comment><USER3> In my opinion this should be taken with a grain of salt. There may be a little bias too since YC obviously has an interest in the most stable of all configurations for their startups, which is the 50/50 split (although it may not be the most fair one).

 _I came up with the idea for the company_ Indeed a silly reason for unevenness.

 _I started working n months before my co-founder_ IMO if n > 6 it's a valid reason.

 _This is what we agreed to_ Well if it was a fair agreement among equals, why not?

 _My co-founder took a salary for n months and I didn't_ Again, for n larger than a certain number IMO this is a perfectly valid reason not to split equally.

 _I started working full time n months before my co-founder_ See above.

 _I am older /more experienced than my co-founder_ Silly reason to some extent. All other things being equal a drastically more senior co-founder will likely have more contribution to the startup.

 _I brought on my co-founder after raising n thousands of dollars_ If n > 100 I think it's a valid reason not to split equally.

 _I brought on my co-founder after launching my MVP_ Depends on what the MVP is and how much traction it has.

 _We need someone to tie-break in the case of founder arguments_ That alone is a silly argument.

Note: Edited for formatting

<comment><USER4> > I started working n months before my co-founder

For this one, the solution might be to vest n months earlier, but have the same number of shares in the end.

<comment><USER5> The other option would be to treat the time invested as part of the company's seed and treat it separate from the founder's equity. So figure out a relatively low salary, use it to convert the time spent to dollars and then give an equivalent amount of shares based on the valuation when the seed funding was raised. Give the other founders the option to invest money in the company in lieu of time at the same terms.

I know this could result in one founder having more equity than the other(s), but I don't see how this can be considered unfair to any of the founders.

</comment></comment></comment><comment><USER6> I'm curious about equity splits that are unequal, but not woefully lopsided, eg. Microsoft's 66/33 split, YouTube's roughly 45/45/10 split, or Apple's 45/45/10\. Do they have similar problems? It seems like the 45/45/10 split does - Ron Wayne left Apple, and Jawed Karim seems to have been a bit of a loose cannon at YouTube (uploading all the copyrighted content) and hasn't worked with the other YouTube founders since. But then - maybe those partnerships would've foundered anyway? Reddit's equal split between it and Infogami didn't really work out either. Are there any companies out there that have succeeded with 60/40 or 65/35 splits, or 40/30/30 between 3 cofounders?

Honestly, looking at the history of startups, it seems like it really is "growth solves all problems". Startups that have users who desperately want them can survive single founders (PlentyOfFish, Instacart), a 90/10 equity split (Netscape), one founder who screws the others out of equity (Facebook, Microsoft), founders who barely know their cofounders (Parse, Dropbox), founders who break the law (IBM, YouTube, Zenefits, Uber), founders who quit (Apple), founders who bow out (Uber, EBay), all the way up to founders that split shares equally and give a bunch of shares to professors & classmates (Google).

</comment><comment><USER7> For Instagram, I believe cofounders Kevin Systrom owned 40% and Mike Krieger owned 10%. After the Facebook acquisition for $1 billion, that turned into ~$400 million and ~$100 million respectively.

Did the unequal split hurt them before and after the Facebook acquisition ... in ways that's not obvious to us?

(That's not a rhetorical question. I'm genuinely curious if the inequality led to a suboptimal outcome... such as getting acquired for $5 billion by some other company vs $1 billion by Facebook.)

<comment><USER8> I wouldn't be surprised if the idea of grinding it out for another 4-5 years to grow from $1B to a bigger potential outcome was a lot less exciting to the person with 10% fully vested than it would be to the person with 40%.

Based on my personal experience and many others I know, if there is somebody at the company with much more equity than everybody else, both philosophically and practically, it is their company, not yours. So while during the phase of vesting your shares it can make a lot of sense to be there, after you are fully vested the draw is much less. Over time the company isn't going to become any more "yours" and the people who own the majority of the equity have massive incentives to replace you and figure it out.

This is really the only perk of being an employee over a founder is that you can leave and it doesn't affect the company very much, whereas when founders leave it generally casts a very negative shadow on the company. So employees can go in for a 2-4 year shift whereas a founder needs to be prepared for a 7-10 year shift.

<comment><USER7> _> I wouldn't be surprised if the idea of grinding it out for another 4-5 years to grow from $1B to a bigger potential outcome was a lot less exciting to the person with 10% fully vested than it would be to the person with 40%._

Your "grinding it out" phrase triggered another recollection about Facebook itself. Facebook had unequal splits[1] and Mark Zuckerberg had more shares than any of the other founders. I believe ownership was unequal in July 2006 when Yahoo offered to buy Facebook for $1 billion and Mark rejected the offer.[2] I'm not familiar enough with the timeline to know if the cofounders were still there and soldiered on after that point towards the 2012 IPO. Maybe they had contempt for MZ about their smaller piece of the pie and left early.

[1] [http://whoownsfacebook.com/](http://whoownsfacebook.com/)

[2] [http://www.inc.com/allison-fass/peter-thiel-mark- zuckerberg-...](http://www.inc.com/allison-fass/peter-thiel-mark-zuckerberg- luck-day-facebook-turned-down-billion-dollars.html)

</comment></comment></comment><comment><USER9> A few additional notes:

1) Investors do look at equity splits. Or at least my fund does, and I assume we're not an exception. I think uneven splits can be reasonable as long as they're just. For example, I think Reid Hoffman had more equity in LinkedIn than the rest of the large founding team combined, but that made a lot of sense: he already had a great name in the Valley, he self-funded the business for the first year, and so on. It would have been much harder to find a substitute for him than for other founding team members (all of whom were great in their own right).

2) I don't say "always" very often, but you should always have vesting. Always. I've seen friends break up over equity issues because they didn't have vesting. You don't necessarily have to do a 1-year cliff, but it should take years for someone to accumulate 30% or 50% of a company.

3) If you're interested in advice on this topic, the book I always recommend to people is The Founder's Dilemmas ([https://www.amazon.com/dp/B007AIXKUM/](https://www.amazon.com/dp/B007AIXKUM/)). The author analyzed data on thousands of founding teams to come up with practical advice for people who are starting companies. There's a chapter on equity splits in the book.

</comment><comment><USER10> My buddy and I split everything down the middle. You either completely split it or don't split it at all. If you don't agree to a total split you're going to end up micro penny pinching. "Hey man do you wanna cover the Slack monthly and I'll cover the GitHub?" doesn't work. We just determine what we need, run the billing on a mutual business account and pay it off equally. We split all profits and expenses.

Of course if there is a significant workload discrepancy this doesn't work, this assumes equal work from both sides. Realistically you're not going to be able to perfectly quantify workload %. As long as we put in relatively similar hours on a consistent basis, we split it all.

</comment><comment><USER11> What happens when a co-founder leaves the company post-investment before having fully vested? Does the equity usually return to the other co-founders or return to the company, effectively giving all shareholders (n.b. including investors) a pro rata increase in ownership? If it's the latter, one must question an investor's incentives in giving that advice, i.e. are they just encouraging a structure that has the most probability of them ending up with more ownership than they paid for? It's actually difficult to filter for bias when your counterpart has diametrically opposed incentives.

</comment><comment><USER12> From a recent Harvard Business Review article: "What do investors make of teams that split the equity equally? Our data suggest that they are less than thrilled. Even after statistically controlling for a lot of factors, our data still suggest the same basic message: companies that have equal splits have more difficulty raising outside finance, especially venture capital." [1]

[1] [https://hbr.org/2016/02/the-very-first-mistake-most- startup-...](https://hbr.org/2016/02/the-very-first-mistake-most-startup- founders-make)

</comment><comment><USER13> I have a strange counter point..

I am married, I started a company with my wife after I put about a year into the product. Technically, we split it 65(me)/35(her) from a company perspective. We came to these terms based on what each person brought to the table.

On the other hand, now that we are married we do actually "go to war" together and have only joint accounts.

The mutual success and splitting everything evenly worked well for marriage. But it honestly made no difference for the company. We both work hard, we both enjoy the challenge, but in the end thats now what the equity split was about.

The equity split (to us) meant who had more assets (time, money, explerience, etc) to bring to the table. We wanted just compensation, and we felt it was/is fair. I think that's the only "fair" way to do it. I'm not going to marry my co-founders (at least not any more), so it should just be based on trade.

On the other hand, if you're just starting off and plan to work equally hard, 50/50 would be fair.

Giving arbitrary rules for every situation seems like a bad time.

<comment><USER14> Doing a startup with a spouse sounds like a dangerous situation on 2 levels, 1 you're crossing streams. A bad day at work can lead to a bad day home or vice- versa. The second is you're no longer diversified. If you go bust, you don't just lose 1 income stream, you're down 2.

There's a third point related to the first. If your business expands, and you bring in another decision maker on any level it creates an unfair power dynamic. You have 2 motivations instead of only 1 professional. You may disagree with your wife on a critical decision, and you may be right, but it may behoove you not to dig in your fists to keep your home life happy.

<comment><USER13> I agree with all three in general, but disagree for this situation.

How many small business owners run a family business? How many farms are family owned?

Historically, almost all ventures were taken as a family. From 10,000 years ago until about 75 years ago.

All that being said, there is a clear definition of who does what and those streams don't cross.

As for the power dynamic, to be honest it has impacted our ability to get funding. Although, I think personally it should be the reverse. As you pointed out, we live and die by this. Which means our incentives are more aligned than ever.

</comment></comment></comment><comment><USER15> The listed reasons all seem make a lot of sense, but why would they apply only to founders, and not to first employees? Especially so when first funding today often arrives before any product is even built.

</comment><comment><USER16> Equal splits make a lot of sense. If I had it to do over though, I think I would make vesting more reflective of the 7-10 horizon than the standard. Only problem with that is that it can create weird incentives to people who come later in the cap table.

<comment><USER17> Oh god.

I think insane vesting schedules are terrible. Let's not make 10-year vesting schedules.

[https://zachholman.com/posts/the-new-10-year-vesting- schedul...](https://zachholman.com/posts/the-new-10-year-vesting-schedule)

<comment><USER16> Why do you think that being the boat for the length of time to create the value is insane? As the continuing founder in a start-up, I'm pretty sensitive to the idea that the reward is at the end of the marathon. Why would splitting based on a marathon-length rather than a 5k race be insane if what you think you're doing is marathon running?

<comment><USER17> I just don't think value is only delivered over a 10 year period. It should take a decade (or 7 years) to get your initial 'reward'.

It doesn't make sense to be locked into something for a decade that may not even be the same in a decade. Just personal preference though, maybe someone will be up for decade of vesting.

<comment><USER18> _> I just don't think value is only delivered over a 10 year period. It should take a decade (or 7 years) to get your initial 'reward'._

I'm assuming you meant "shouldn't", but that's not what a 10-year vesting schedule would mean either (all other things being equal); With a one-year cliff you'd receive your "initial reward" (i.e. fully vested equity) by the end of the first year, then continue to vest on a monthly/quarterly/yearly basis in accordance with the vesting schedule.

</comment></comment></comment></comment></comment><comment><USER19> I didn't understand the very last part:

> Another good contingency measure is for only the CEO to hold a board seat > before a significant equity fundraise. That will prevent board disputes > during tough decisions, such as in the unlikely event that the CEO has to > fire a co-founder.

Can someone please unfurl what this means? Is it arguing for the founders NOT to have a board seat before significant equity changes so that the CEO can be the arbiter betwen them? (Btw, it's odd to assume the CEO is not a founder).

<comment><USER20> No, it's a way of dealing with the issue of deadlocked decisions between co- founders if equity is split evenly.

Usually in the case of a deadlocked decision between co-founders, you can resort to a board vote, after which you resort to a vote among shareholders.

If, say, two co-founders split equity and they're both on the board, then a disagreement could lead to a problem. If, however, only one of them (usually the CEO) is on the board, then there's no deadlock there.

Sometimes people recommend giving one co-founder (again, usually the CEO) one extra share so their vote can break a deadlock. But putting only the CEO on a board is another way to deal with that problem without having to worry about extra shares.

</comment></comment><comment><USER21> Had to create a throwaway account for this one. I was involved in a founder split that was wildly uneven years ago. The justification sounded good that the beginning, but the imbalance became more and more evident as things went on. Ultimately, one co-founder left, one was bitter all the time, and one ended up with a significantly disproportionate share of the company. It just didn't work at all. Seibel is right here, start with equal shares, and only modify if there is a significant imbalance. All the justifications you can come up with at the beginning of a company just aren't able to take into account what will happen 7-10 years from then. Keep it fair, or you risk introducing a whole load of extra baggage to an already impossible task, right at the beginning.

</comment><comment><USER22> I agree with the 'it's all ahead of you bit'.

BUT - what if someone spent a year or more making a product, got it to MVP, and then took a couple of others on pre-funding.

Most of the vision, concept, and maybe even the trickiest might possibly have been done ...

I wonder what his thoughts are on that ...

<comment><USER16> Then maybe the people that come on at that point aren't actually founders, they're highly equity compensated employees and YC has a whole different set of advice. It is okay to be solo founder, you just need to know that you need to build a team.

<comment><USER23> Part of the issue is that the delineation isn't clear, in life or in startup advice.

</comment></comment></comment><comment><USER17> I guess it makes sense that if you object to having nearly, if not completely, equal equity splits, you shouldn't work together.

If you aren't willing to give significant equity, they either aren't valuable enough or you don't see them as crucial.

</comment><comment><USER24> I will say that years ago in grad school I went over-fair on the equity split of a startup I was attempting with 40-30-30. Our last big potential investor walked because he wasn't comfortable investing in any setup in which 1 person couldn't make the hard decisions if they had to. My co-founders weren't comfortable with that.

Now we all have jobs. :-)

One of these days I need to write about that startup. It was 03-04 and just the differences in technology at the time that led to some of our architectural decisions are mind-boggling.

</comment><comment><USER25> The point of giving someone equity is that you can't pay others with cash, assuming you have the choice. If you have the choice it might well be you would rather start the company alone. There is a very interesting dynamic between the point of some participant being a founder and being an employee - late founders and early employees can be very similar to each other. Assuming a business is already generating revenue of even profit, the dynamic changes.

</comment><comment><USER26> Splitting equity equally is a terrible idea, to use an old quote "Too many Caesars is not good". In any organization there has to be a one leader who is accountable. In case of the startups mostly likely that person is going to be the majority shareholder, splitting equally creates a rule by committee style of management, which is a terrible way to manage a company or country. Ask the Soveits if you don't agree.

</comment><comment><USER27> IMHO this is a very individual matter. An uneven split among founders should not be red light, as long as it is in the same magnitude.

</comment><comment><USER23> I'm surprised YC hasn't explored Dynamic Equity Splits at all:

[https://techcrunch.com/2013/02/09/the-perfect-cap- table/](https://techcrunch.com/2013/02/09/the-perfect-cap-table/)

</comment><comment><USER28> Any advice on clearing up an unequal equity split down the line? What are some ways to rebound from these pitfalls if founders realize, post-investment, that an initial mistake was made?

</comment><comment><USER23> I really doubt one-size fits all advice is appropriate here.</comment>


Show HN: Geoparser.io API – sentences go in, GeoJSON comes out - <AUTHOR> https://geoparser.io <comment><USER2> Great service but it doesn't support other languages than English or Unicode characters.

<comment><AUTHOR> For now, yes, but we can potentially add support in the future for new languages, etc. as needed on a case-by-case basis.

</comment></comment><comment><USER3> Awesome capability! It is fun to think about the potential for apps to discern geography from unstructured text.

</comment><comment><USER4> So glad this is available with PlaceSpotter shutting down soon. Working pretty well for us!</comment>


Why I use GPL - Zed Shaw - <AUTHOR> http://zedshaw.com/essays/why_i_gpl.html

<comment><USER2> That post is strange regarding its use of licenses and implications, and also is probably some years old (it is hard to say, without a date / timestamp in it).

a) The GPL does not enforce "giving back" for server software, if that software is only running on servers but not provided for download. The Affero GPL [1] is meant to close this "gap".

b) Lamson 1.0, released almost two years ago [2], is actually licensed BSD/GPL, making the point of the post moot, unless it was written before the release.

[1] <http://www.gnu.org/licenses/why-affero-gpl.en.html>

[2] <http://lamsonproject.org/blog/2010-07-07.html>

<comment><USER3> It looks like the post is from 2009:

"That was in 2004. Five years ago."

<comment><USER2> That would also match with the later release date. Thanks for clarifying.

</comment></comment></comment><comment><USER4> "Let me give you an idea of how advanced Mongrel was. Remember the "new" attack on Apache called Slowloris that was recently released? I actually predicted that attack, and wrote Mongrel so that it was resistant (as much as Ruby could let me). I called it the "trickle attack" and even demonstrated it. That was in 2004. Five years ago."

Zed needs a history lesson. David Filo at Yahoo! figured it out at least 4 years before Zed did, and patched FreeBSD to provide accept filters in release 4.0. They buffer the request at the kernel level so that the application stack doesn't even see the HTTP request until it's fully formed.

[http://www.freebsd.org/cgi/man.cgi?query=accept_filter&s...](http://www.freebsd.org/cgi/man.cgi?query=accept_filter&sektion=9)

<comment><USER5> Here's a variation I reported to Twisted in 2003: [http://www.twistedmatrix.com/pipermail/twisted- python/2003-J...](http://www.twistedmatrix.com/pipermail/twisted- python/2003-June/004462.html) , and an updated version at <http://permalink.gmane.org/gmane.comp.python.twisted/3628> .

I did not come up with that myself; I had read it elsewhere.

Is this essentially the same thing?

</comment></comment><comment><USER6> Zed wrote this a few years ago. None of my business, but I am curious if the dual license business model for Lamson before he extended the licensing options to include BSD.

I would like to see high profile developers like Zed and Chris Granger fund more projects using services like Kickstarter (as Chris did for Light Table). People who do useful work deserve to be paid for it, and this is one good approach for well known developers.

</comment><comment><USER7> The guy must be damn sure about how cool his projects are, because there's a situation where your project is cool enough for company to use but they won't because of GPL. It would probably work with startups (they're flexible and in a hurry — they'll take the coolest thing around without a second thought), but it may not work with bigger companies. Quite contrary, I believe that big companies tend to use software licensed under BSD, though I have no personal experience with that.

I also want to express my gratitude for a different view of startups — I definitely never thought of them as a bunch of guys who would take as much open source software as possible but hide the fact, all in a name of perceived smartness, innovativeness and productivity.

<comment><USER8> >...there's a situation where your project is cool enough for company to use but they won't because of GPL.

He obviously realizes that. From the article:

>I would actually rather nobody use my software than be in a situation where everyone is using my gear and nobody is admitting it.

<comment><USER7> Yes, he does. I wrote my comment to emphasize the other side of the coin, not to fill some gap that wasn't covered in the article. It must be kind of mistake here (I've read the posting guidelines but I'm still a newbie, thus more prone to errors), so I propose to finish the discussion.</comment></comment></comment>


Temporal Stability of Brain Modules Associated with Human Intelligence - <AUTHOR> https://onlinelibrary.wiley.com/doi/epdf/10.1002/hbm.24807 <comment><AUTHOR> A brief article on the paper's findings: [https://medicalxpress.com/news/2019-10-brain-networks- stable...](https://medicalxpress.com/news/2019-10-brain-networks-stable- individuals-higher.html)</comment>


Breaking Bread: The dark and white flours of ideology - <AUTHOR> http://www.cabinetmagazine.org/kiosk/rips_nicolaia_21_october_2019.php <comment><USER2> As someone who is enjoy eating a lot of bread (part of my Balkan culture), I'm baffled to see so much hesitation toward bread when I go abroad. I'd frequently get plenty of food in restaurants, but not so much bread with it. Even if I get it, either it is something old or "too much white" for my taste (this means there is nothing in it useful for the body).

Although we have plenty of bakeries with fresh bread 24/7, I recently started to make my own with bread maker I got as present few years ago (some Moulinex). It was sitting in a box and I decided to try it before sell it or give someone.

I can say, this ended up pretty well. I always liked chemistry (mixing and weighting stuff, calculating compounds) and this happens to be essential part of bread making. After few failed attempts, my bread finally started to get desired shape and taste; my family started to like it as well.

The best part is that I know what I'm putting in (I'm not so much fond of general food industry) and as a geek, I introduced some geekish stuff as well. Although bread maker automates lot of things, I'm using Emacs and ledger-cli [1] to track compounds I'm adding, including comments about finished bread. This way I can always pull what worked the best, what not and total amount of compounds I spent in a week or month. TBH, this article [2] was inspiration for tracking with Emacs.

Still tons of stuff to learn, but "the project" ended up funny and very enjoyful.

[1] [https://www.ledger-cli.org/](https://www.ledger-cli.org/)

[2] [https://bofh.org.uk/2019/02/25/baking-with- emacs/](https://bofh.org.uk/2019/02/25/baking-with-emacs/)

<comment><USER3> Very nice :) As a fellow bread baker/chemist/geek, I wrote this little command-line tool in Haskell that helps me scale recipes. I've used it to develop/store/print out recipes and routinely for dinner breads like tortillas and rotis ("OK so I just dumped 113 g of durum atta into a bowl; how much water, oil, and salt do I need?")

[https://github.com/ramanshah/bread](https://github.com/ramanshah/bread)

<comment><USER4> Your next task should you choose to accept it is to develop an open source rival to Rotimatic

</comment></comment></comment><comment><USER5> I'm still amazed how relatively easy it is to bake your own sourdough bread, and encourage everyone to at least give it a try. After a few practice rounds, the total time you need to put in for a loaf is about half an hour (<5 mins work, 8–12 hours waiting, 20 mins work, 2 hours waiting, 5 mins work, 5–7 hours waiting, <5 mins work, 30 mins baking, done). I'm following this recipe [1]. Just yesterday I made this one [2], I think my 10th try.

[1] [https://www.hobbshousebakery.co.uk/blogs/recipes/140081991-s...](https://www.hobbshousebakery.co.uk/blogs/recipes/140081991-sourdough- bread-recipe)

[2] [https://pub.hrmnn.net/25/847d8c01/DSCF6085.jpeg](https://pub.hrmnn.net/25/847d8c01/DSCF6085.jpeg)

<comment><USER6> By "throw a cup of water into the bottom of the oven", is he being literal? as in literally pour the water onto the oven floor? Is that safe? Or is it "throw in" in the colloquial sense of "put it in"

<comment><USER7> You can poor the water into a baking tray.

Regarding safety, just be careful not to burn yourself

<comment><USER8> It's best to buy a cheap cast pan, fill it with chain or bolts, and through it on that. If you want to get fancy you can get a metal colander and fill it with ice and put it above that.

<comment><USER9> Baking tray with lava rocks is a better option, but the simplest option is just to bake in a dutch oven with a lid on. There's enough moisture in the dough to create required amount of steam. 20 min with lid, 20 min without gets the job done very nicely.

<comment><USER8> yes but that doesn't work if it's not a boule

</comment></comment></comment></comment></comment></comment><comment><USER10> Question for native German speakers: Are abendbrot and brotzeit regional terms? I know that when I took German I was taught abendessen and imbiss respectively.

<comment><USER11> I can only agree with the other responses.

In my personal usage, I would say Abendessen and Snack.

Abendbrot sounds like something a 60+ year old would call it.

I haven't heard it called Brotzeit since I was in elementary school in Bavaria, so that overlaps with the sibling responses.

Personally, when I hear "Imbiss", a kiosk that sells food is the primary thing that comes to mind. As in, you can get a hot dog with fries there.

<comment><USER10> Regarding Imbiss, it could be that my teacher learned it incorrectly, or it could be that I'm remembering incorrectly. Or, of course, it could be technically correct, but not actually used in daily speech. :)

<comment><USER11> It's a 100% reasonable to teach it. The German Wikipedia result right now is a disambiguation page between the snack and the place to buy the snack ("Imbiss" always being short for Imbissbude, Imbissstand etc.).

</comment></comment></comment></comment><comment><USER12> As a German I didn't realize the bad rep white bread has in Germany originated in Nazi propaganda. But I'm not surprised because a lot of urban myths in Germany do unfortunately. White bread isn't less healthy than any other bread by the way, so the author's uncriticial view of German bread myths - and her inevitable spread by repeating them - is a bit disappointing.

If you really want to eat healthy bread, don't look at the color but look at the ingredients. If there's added sugar or syrup then it's probably less healthy. Except if you take into consideration that the added sugars somehow prevent the bread from getting moldy, since eating moldy bread isn't healthy.

When it comes to ingredients bread really is as simple as it gets, there's not much that can go wrong healthwise (except the aforementioned sugars and syrups). It's astonishing how much variety you can achieve with these smallest number of ingredients by simply changing slightly the way it is prepared and baked.

And another myth is that industrially produced bread is less healthy or of lower quality than the one from the bakery or home baked. The one you bake at home using the off the shelf yeast probably will taste the same if not worse than the ones you can buy pre-packeged in the same store. Of course I can only attest this to German mass-baked bread, maybe it's of high quality anyway.

Baking bread is an art. Of course, if you master it you can make bread that tastes like no other but the best tasting bread will always be the one that's fresh out of the oven, still slightly warm.

<comment><USER13> _White bread isn 't less healthy than any other bread by the way_

That's simply not true. Whole wheat bread retains the bran (fiber) and germ (vitamins), while the endosperm in white bread is mainly starch.</comment></comment>


Groovy downloads double after joining Apache Foundation - <AUTHOR> http://restlet.com/blog/2015/10/21/community-lessons-groovy-downloads-double-after-joining-apache-foundation/ <comment><USER2> > We moved the Groovy project to the Apache Foundation as a message to the > community to say that the community and ecosystem matter the most

You moved it to Apache because all the three staff working on Groovy were retrenched from Pivotal,Inc.

> we started to support Android. even large companies like the New York Times > started to use Groovy to build their Android mobile apps

You're mixing up the functions of Groovy for build scripts in Gradle and as a systems languages targeting Android.

<comment><USER3> Groovy moved from Codehaus to Apache because Codehaus was shut down. This has nothing to do with Pivotal at all. And maybe I get the word retrenched wrong, but it was not a simple reduction of people working at Groovy, it was a full layoff, and out of about 7 people involved with grails and groovy only the eclipse guy stays, because he also works on other things. But afaik Pivotal did not pay anything to Codehaus at any time.

As for Android... you can really make Android application in Groovy now. And the NY Times guys really did/do (don't know the current state) use it for the actual app.

<comment><USER2> There's nothing anywhere about Groovy moving to Apache or looking for another governance structure during the years Codehaus was winding down. It was only first mentioned online about a week after the layoffs from Pivotal were announced. Everything that was on Codehaus was already moving to Github and Guillaume Laforge's groovy-lang.org website. Moving to Apache looks like a direct response to Pivotal's layoffs.

<comment><USER3> We have not been looking for a new governance structure, that's right. That comes in the package with moving to Apache.. as would have been if we had moved to Eclipse. Moving off Codehaus had happened at that point already in several aspects. There was only JIRA, mailing lists, web page as well as a git repo mirror on Codehaus. github because of pull requests, distributions moved away because Codehaus exchanged rsync with webdav making releases take a full day, CI moved because the sponsored server allows us to test against the newest Java directly from the repository and so on.</comment></comment></comment></comment>


AMD Ryzen 1800X vs. Intel Core i7-7700K hash cracking benchmarks - <AUTHOR> https://hashcat.net/forum/thread-6534-post-35415.html#pid35415 <comment><USER2> 600% faster is absolutely unbelievable. According to Agner's observations, this should not be true at all: [http://www.agner.org/optimize/microarchitecture.pdf](http://www.agner.org/optimize/microarchitecture.pdf).

The Ryzen architecture apparently has half throughput for 256-bit vectors instructions compared to 128-bit vector instructions, while Skylake (no data for Kaby Lake yet) has full throughput for 256-bit vectors. Since the 1800X has twice the cores, it should be about the same throughput if all cores are used, so if it isn't multi-threaded, worst case should be half, no?

This guy also seems a bit biased »it has to throttle itself down below the base clock to prevent itself from imploding -- just like their GPUs!«.

There is also a benefit to using 256-bit instructions, contrary to what he says: They're more dense than having 2 separate 128-bit instructions.

I wouldn't call it a bold-faced lie either, it's not like they said »Using 256-bit vector instructions is much faster than using 128-bit vector instructions!«.

</comment><comment><USER3> I sold one of my extra 6700k and had $320 hold burning in my wallet and almost bought a 7700k but got a ryzen 1700 instead to try it out. The MSI mobo was terrible, but i get nearly double the crytonight hashrate of my 4.6GHz 6700k with the 1700 @ 3.9GHz which was pretty easy to do. Temps are around 60C with stock wraith cooler and only takes about 110watts full system hashing. I'd say ryzen is a nice win. Skylake X and Coffee Lake though look like a pretty nice improvement from left field. AMD might have some problems fighting those.

</comment><comment><USER4> So is there any reason to use a CPU for actual hash cracking instead of a GPU?

You'd probably use a CPU to hash user passwords at login and signup, but outside of that is there any reason to?

<comment><USER2> If you didn't have a GPU?

</comment></comment><comment><USER5> Regardless AMD's push back into high end processors is beneficial to everyone. Notice how fast Intel dropped prices and released new processors, like the core i9. At least it will finally end the whole overpriced tick/tock Intel release "roadmap". Intel has been sitting on this stuff all along and just strings everyone out because what else are you going to buy?

</comment><comment><USER6> > And speaking of AVX2, this test was important because it confirms that > Ryzen's AVX2 support is a bold-faced lie. Yeah the instructions are there, > but they don't have any 256-bit registers, so you gain nothing by using > AVX2.

Is this true? That's pretty damning.

<comment><USER2> It's not really a lie, but technically the Ryzen architecture doesn't have 256-bit instructions internally. Not like it matter much to you though, because these are all implementation details, and don't really make a difference for you, other than changing how you should optimise your code for max speed.

</comment></comment><comment><USER7> How did this unsubstantiated and offensive message board link make it to the front page of HN?

<comment><USER8> There was a lot of pretty positive Ryzen coverage around in the last couple of months, so I suspect when something challenges that it piques people's interest and gets a few upvotes in quick succession.

I agree that the tone is pretty juvenile, however - it's not something I'd expect or want to see on HN :-)

<comment><USER9> Seems like it was bumped off the front page with great prejudice...

<comment><USER6> Yeah I can't even find this thread on the first few pages anymore. Such a shame HN can't get over the tone of the thread to discuss the details.

</comment></comment></comment></comment><comment><USER10> i really wanted to buy a ryzen, but it seams it is unstable under a heavy workload [https://forums.gentoo.org/viewtopic-t-1061546-postdays-0-pos...](https://forums.gentoo.org/viewtopic-t-1061546-postdays-0-postorder- asc-start-175.html?sid=b0f6cf1ca43d0576fe17141790552ab8) i will probably have to wait for intel -X chips or buy a e3 v6 xeon :/

</comment><comment><USER11> its been proven that Nvidia graphics card drivers are behind with AMD CPUs. Wether this is purposeful or just that the drivers are not as fleshed out hasn't been proven. For a more complete test they should have added

Ryzen + dual 580

i7-7700k + dual 580

<comment><USER6> Isn't this test CPU only?</comment></comment>


WSJ: Israel revamps army boosting tech, cutting conventional arms - <AUTHOR> http://online.wsj.com/article/SB10001424127887324425204578599953517340808.html

<comment><AUTHOR> Google for WSJ title: Israel to Revamp Army for New Risks</comment>


Monsieur Bernoulli would like you to wear a mask - <AUTHOR> https://medium.com/@saigaddam/monsieur-bernoulli-would-like-you-to-wear-a-mask-ce335635ba76 <comment><USER2> Perhaps M. Bernoulli has read the WHO April report which recommended that masks be worn, noticed the sentence

 _At the present time, the widespread use of masks by healthy people in the community setting is not yet supported by high quality or direct scientific evidence._

and decided not to boss people around without some evidence that it is effective</comment>


Two Fortunes and a Global Software Sweatshop - <AUTHOR> https://www.forbes.com/sites/nathanvardi/2018/11/19/how-a-mysterious-tech-billionaire-created-two-fortunesand-a-global-software-sweatshop/ <comment><USER2> Very interesting read about Trilogy, as someone who worked at Trilogy/pcOrder as their first job out of college.

They were recently advertising for 300k/year architects, I didn't know the current business model was based around a global workforce.</comment>


Why we need another domain registrar - <AUTHOR> http://nameptr.com/2010/12/04/why-we-need-another-domain-registrar.html

<comment><USER2> I want a registrar to sell domains, not be a platform for marketing other services to me. I want one registrar which will sell me any tld, many of the nice-looking registrars don't support .uk or .dk domains. I want there to be a well-documented API for setting up dns, and this may be a partnership with Zerigo. I want their website to not make me think. I want to have sub-accounts for my clients to handle their own domains, white-labeled if possible. I want one-click setups to point to Google Apps, Heroku, etc. And whilst I'll pay a premium for this, I don't want it to be so expensive I can't afford it.

<comment><AUTHOR> This is very much the direction I am trying to go. Of course I will be releasing as early possible. But many of the things you mentioned are on my radar, except for the dns api. I'll have to check out Zerigo.

I am starting out as an Enom Reseller. It looks like I should be able to do .uk domains day one.

</comment></comment><comment><AUTHOR> This is an announcement of my current project. I have a very good idea of what I want in a domain registrar, but I would love to hear what other people want. Please let me know if, if you have the time.</comment>


Plastic buckets, broken printers shine light on Hanoi's poor (2016) - <AUTHOR> https://www.reuters.com/article/us-vietnam-energy-renewables-idUSKCN0ZK0WB <comment><USER2> Here's an article that has more details and a video. [https://www.globalcitizen.org/en/content/homemade-wind- power...](https://www.globalcitizen.org/en/content/homemade-wind-power-from- buckets-vietnam-red-river/)

<comment><USER3> So they are using the motors from the printers as generators.

You still need to rectify the voltage to store the energy in lead acid batteries, losing precious voltage in the diodes. I wonder how they get the >13V to charge the batteries.

Power output is probably <10W average.

<comment><USER4> Maybe harvesting diodes and capacitors from the same e-waste.

Are the motors AC or DC? Even if DC, you'll need diodes to avoid turning the generator into a motor.

Since they were only talking about a few hours of light at an "equivalent" of 45 watts, sounds like a 5 watt LED.

If they keep it really simple, they just charge at a really low rate as long as there's some wind and throw away the rest of the power.

<comment><USER5> On the: >Are the motors AC or DC? part, I believe all printers I've taken apart in the last decade used DC motors of some sort (with the odd stepper thrown in).

</comment></comment></comment></comment><comment><USER6> Interesting, and very cool.

This would never have been possible without the Internet. One might have found stuff like this in the Whole Earth Catalog, but it would likely never have reached these people.

On the other hand, one could say the same about drone attacks by ISIS, or the recent one against President Maduro. And that approach will likely become commonplace.

<comment><USER7> Necessity is the mother of invention (and cell phones are so ubiquitous they probably have at least one or two with internet).

You will see more of this as the worlds trash piles up. There's value to be had in there for the poor and destitute (not saying this is good or bad, it just is).

</comment></comment><comment><USER8> what broken printers are for?

<comment><USER9> My guess would be that they use the motors as generators.</comment></comment>


Pycon 2015 videos - <AUTHOR> https://www.youtube.com/channel/UCgxzjK6GuOHVKR_08TT4hJQ

<comment><USER2> There are a lot of 3 hour sessions. I love these compared to the 20 minute talks, since they go deep into the topic. I just watched James Bennett's "Django in Depth" and it was excellent [https://www.youtube.com/watch?v=tkwZ1jG3XgA](https://www.youtube.com/watch?v=tkwZ1jG3XgA)</comment>


Amazon Key expands to deliver packages inside your car - <AUTHOR> https://arstechnica.com/gadgets/2018/04/amazon-key-expands-to-deliver-packages-inside-your-car/ <comment><USER2> Amazon should sell installable mailboxes that hold packages delivered by Amazon. Amazon can have the key to that.

<comment><USER3> I like the concept, but I don't like the brand lock-in.

Plus I imagine for branding reasons these boxes would be highly visible and more visible than most packages would be.

You give me a subtle box that can be opened by UPS, FedEx, USPS, and Amazon Logistics and I'm game.

<comment><USER4> The USPS will never allow it. Only USPS deliveries are allowed in any USPS receptacle.

<comment><USER5> Everyone except USPS then. I've been kicking around the idea myself. Something like a package box with a slide down ramp, so you can't pull anything out when delivering something new.

<comment><USER4> You can get one of these on Amazon.

</comment></comment></comment></comment></comment><comment><USER6> I would be wary of using this service in a place like SF where smash and grab is so prevalent.

Basically thieves will follow Amazon delivery trucks and watch where the packages get delivered.

[http://www.sfweekly.com/news/authorities-hustle-to-curb- s-f-...](http://www.sfweekly.com/news/authorities-hustle-to-curb-s-f-s-smash- and-grab-epidemic/)

</comment><comment><USER7> If car manufacturers were smart, they'd be all over this. Separate key for trunk vs. cabin.

This solves the drop-package in an unsafe location problem. Why drop shit on your porch when you can drop it into the safer trunk of your car, wherever it is?

Brilliant idea, they're really hammering at the problem.

Once cars are even smarter, they'd go to a Amazon hub while you're sleeping/at work and pick up packages for you of course. Without the effin' carton around it, no need for all that garbage.

Mock all you want, Amazon is at least trying.

<comment><USER8> A lot of vehicles allow access to the trunk by folding down a section of the back seat (so you can haul longer items like skis), so I'm not sure this would be quite as easy as suggested.

<comment><USER9> Usually the latches are only accessible from inside the cabin, however; if only the trunk is unlocked, you can't fold down the seat.

<comment><USER10> My Mazda has the backseat release cables in the trunk on purpose.

I'd be more worried about someone breaking the glass to get into the trunk than vice versa, so the arrangement seems the most logical.

<comment><USER11> A few years ago my company had a big meeting for all senior mangers at a huge conference centre.

Problem was some perp had worked out they had all left their laptops in the company car a large number of which where hatch back's when they all came out a number of hatch backs windows had been smashed and the lap tops nicked.

<comment><USER10> My car isn't a hatchback but obviously there's a huge problem if you own one.

</comment></comment></comment></comment></comment></comment><comment><USER12> I like this. There's no way I'd let an Amazon bozo into my home but I don't mind them leaving stuff in my car which is much less risky. I'd prefer that they only get access to the trunk but I think most cars are set up the other way (able to specifically lock trunk, not cabin).

<comment><USER13> I wonder if Amazon's plan of delivery into home was just marketing for in- trunk delivery.

Or maybe as a distraction for Walmart , which copied the in-home version.

<comment> the-pigeon There's also the idea of having them put cold groceries directly into the fridge and freezer.

Or a dog walker being able to use an Amazon access to open the door to get your dog.

I think Amazon wants to go anywhere consumers will let them but they realize people are going to be very reluctant and some people will never be ok with it but they must think enough will for it to be worth the R&D.

<comment><USER12> Feckin' gross, I definitely do not want some Amazon dude rooting around in my refrigerator.

</comment></comment></comment></comment><comment><USER14> The problem is particularly bad for packages sent to condo buildings. Amazon pickup points are good, but still require you to go pick it up (and delivery notifications are usually quite delayed for me for some reason).

I've been throwing around an idea where condo residents can sign up to be a package hero and accept deliveries on your behalf... maybe even deliver to your door on demand. Is there a reason this doesn't yet exist? Just trust or something else?

<comment> eigen-vector This was introduced to solve this specific problem [https://www.amazon.com/b?ie=UTF8&node=17337376011](https://www.amazon.com/b?ie=UTF8&node=17337376011)

It requires buildings to sign up though. There are also services like Parcel Pending that solve this problem.

<comment><USER15> We had one in my building. First package I ever received the door got stuck and I couldn't get it out. Had to get on the phone and wait for a maintenance man.

</comment></comment></comment><comment><USER16> They're probably angling to cut delivery costs by delivering to people's cars while they're at work.

A parking lot is a much denser cluster of delivery points than a neighborhood of three family houses and packages get stolen from locked cars less than from doorsteps (well maybe not in SF).

Edit: I'm not disagreeing about the creepy factor. This could be abused fairly easily. I expect that it's a matter of time before they sell access to the data set (which will probably include a picture of the license plate and the package sitting inside the car) to some authoritarian state (I'm betting PA, MA or TX) who will then mail a citation for every equipment violation they see. Building your own data set to do this wouldn't be worth it and wouldn't pass public scrutiny but when you can just buy someone's data set it's easy.

There's plenty of other legally white but ethically gray when done at scale things you could do with a data set that will likely include a smartphone-res picture of the interior of somone's car.

On the other hand. This opens up an option for people who live in one state but work in another to exploit differing laws to their advantage (tax, shipping restrictions)

<comment><USER17> _They 're probably angling to cut delivery costs by delivering to people's cars while they're at work._

This analysis aligns to what I know about how Amazon rolls out new products and features. There was an A|B test of this, and the option they're rolling out saved a ton of money.

</comment></comment><comment><USER18> First they wanted to unlock my house. Now they want to unlock my car. Why does this feel creepy?

<comment><USER19> You should have been /be creeped out by on-star if anything. Every on-star vehicle can be tracked within the triangulation limits of cell towers (aka. within half a mile if not better.)

<comment> Harvey-Specter Are you also creeped out by your cellphone?

<comment><USER20> Yes, but the pros outweigh the cons.

</comment></comment></comment></comment><comment><USER21> sucks if this service will be exclusive to subscription services offered by car manufacturers. Cant amazon make a dongle with a simcard and/or wifi that plugs into ODB2 port to enable remote lock/unlock?

<comment><USER22> Onstar et al would _never, ever, ever_ let that happen.

Viper is the only one I know of that's similar aftermarket. But still, that's about as common now as aftermarket head units.

</comment></comment><comment><USER23> Obligatory Onion link: "Popular New Amazon Service Just Comes To Your House And Kills You"

[https://www.theonion.com/popular-new-amazon-service-just- com...](https://www.theonion.com/popular-new-amazon-service-just-comes-to- your-house-and-1819917496)

</comment><comment><USER24> Volvo has been pushing this concept since 2014:

[https://www.engadget.com/2014/02/20/volvos-roam- delivery/](https://www.engadget.com/2014/02/20/volvos-roam-delivery/)

[https://www.engadget.com/2016/05/10/vovlo-in-car- delivery/](https://www.engadget.com/2016/05/10/vovlo-in-car-delivery/)

<comment><USER25> I remember BMW pushing the concept too, around 2016.

</comment></comment><comment><USER26> Yes please put an Amazon parcel in my car all day so my window can be smashed.

<comment><USER12> Not everyone has their car in a place where the window is likely to be smashed. I live in a place where windows are smashed frequently but work in a place with a parking lot patrolled by private security. I'd be perfectly comfortable having a package sitting in my car all day, and in fact have left my car sitting in that parking lot untouched for 6 weeks without issues.

</comment></comment><comment><USER27> I don't really see the point of this. Assuming you have equal or less cars per (adult) person in your househould, what advantage does this have exactly? Your car is likely going to be wherever you are. If it's going to be at work then just deliver it to your office. If it's at home then just deliver it normally.

Best use case is if you've gone for a walk or have more cars than people and then what, your car in your driveway becomes a glorified 5 figure oversized mailbox?

Call me paranoid, but I feel like the real reason is this:

>On the day of delivery, customers can check if their car is parked in-range of the delivery location in the Amazon Key app.

That implies to me they'll have access to your cars location, which is information they can use for targeted ads.

<comment><USER28> That probably depends on the kind of job you have. If you're a developer, sure, you can probably accept a package at the office, but if you're working as a cashier in a supermarket, it's doubtful your employer would allow you to accept packages while working.

<comment><USER29> I personally mail every package to my work rather than home. No worry of leaving the house for one 15 minute window in the entire day and ups showing up and taking my package back with them. ($1800 laptop so taking it back was better than the porch but it was still annoying.)

That said I am the IT/Electronics tech for a small machine shop. Most of us here have items we order come to work.

<comment><USER30> This is my favorite perk of working at a company. The only thing that sort of sucks is when you buy some items for personal use, some for the business, and some for personal-use-at-office, all from the same vendors, and need to disintermingle them. If you're out of town, telling a coworker to go into the Provantage box to grab the network tester you ordered, and having him open the box containing soap, is weird.</comment></comment></comment></comment>


Ask HN: Building the Ultimate Social Login Table - <AUTHOR>

I am finding it hard to locate all of the different ID formates for the various social networks.  This is the table I have so far, can any of you contribute to this list.

  *Social Login Table*

  SERVICE	id	size	TYPE	Charset		Doc Source

  <comment>=	==	====	====	</comment><comment>=		</comment><comment>====

  facebook	fuid	64bit	BIGINT	0-9

  twitter		64bit	BIGINT	0-9

  yahoo		guid	26byte	string	2-7 A-Z
    http://developer.yahoo.com/social/rest_api_guide/ysocial_apis-guids.html

  google		21byte	string	0-9		@willnorris
 </comment><comment><AUTHOR> a friend who i trust recommended just using varchar(255) to represent all IDs. any other comments?</comment>


Apple says its new Apple One services bundle isn't unfair to Spotify - <AUTHOR> https://www.theverge.com/2020/9/15/21438867/apple-one-spotify-antitrust-monopoly-criticism <comment><USER2> A data point: the Premier level of AppleOne quickly had me considering cancelling my Spotify family account in favor of the Apple bundle.

However on further reflection, while apparently not as generous to artists, Spotify is simply a superior product. The recommendation engines and instant playlists are fantastic, the UI is wonderful, and being able to share songs with friends knowing that they'll be able to play them—at the very least via Spotify's free tier—is frictionless.

We pay $10/month for 2TB of iCloud and $15 for our Spotify plan, and currently don't see a need for the other Apple offerings in the bundle—all are nice-to- haves from our perspective.

I think we'll continue our current diversified bundle for the foreseeable future.</comment>


[patent trolling] Warren Buffet patents S.E.O strategy - <AUTHOR> http://www.elevatelocal.co.uk/blog/warren-buffet-patents-seo-strategy-29094977

<comment><USER2> I feel like any regular SEO advice book has most of the steps of the claims of this patent.

1\. A computer-implemented method comprising:

receiving a document containing content for distribution via one or more online media distribution channels;

 _You write a web page_

analyzing a structure of the document; determining optimal modifications to the structure of the document;

 _You should put your navigation after your content_

analyzing keyword frequency and keyword positions in the content of the document, the keyword frequency and keyword positions being analyzed relative to historical data obtained from one or more of the online media distribution channels;

 _Here are some buzzwords that have been picked up by search engines in the past ("keyword frequency," "historical data"). Search engines pick them up when they are in the meta tags ("keyword positions")._

determining optimum modifications to the keywords in the content of the document based on the structured document;

 _Thus, you should put those keywords in the meta tags._

displaying recommended structural changes to the document based on the structured document modification and recommended keyword modifications to the content in the document to a user in a graphical user interface;

 _This is just automation of what an SEO book teaches. It is well-established that automation of a known process is obvious._

receiving input from the user adopting one or more of the structural changes or the keyword modifications to the content; and initiating distribution of the document via one or more of the online media distribution channels.

 _You modify your web page and put it online._

<comment><USER3> Agreed, what the article showed as a flowchart is obvious to anyone with a rudimentary skill in the art of software design.

</comment></comment><comment><USER4> The misleading linkbait title should be changed, just because a company that Warren Buffet invested in via his investment company has taken some action it doesn't mean that WB did it.

<comment><USER5> Business Wire is a private company fully owned by BH, not an investment.

<comment><USER6> That still does not mean Warren did it. If you are the general in an army, you don't necessarily approve every last thing your lieutenants get up to.

</comment></comment></comment><comment><USER7> Could I patent basic problem solving skills and then sue someone who uses them to solve problems? Where will this madness end?

I want to patent the process of using analogies to teach others. Everyone everywhere must cease thinking because they are infringing on my discoveries.

<comment><USER5> That's neither a machine or a method of doing business, so it's not patentable. It doesn't help the argument to pretend the patent system is even broader than it is. This patent isn't on "SEO for press releases", it's for a machine which performs a process including an expert system which evaluates rules to provide keyword suggestions... etc. Unless your machine works the same it doesn't infringe. The idea is not what's protected.</comment></comment>


Hottest tweets about London - 24 hours a day - <AUTHOR> http://london-24h.com

<comment><AUTHOR> Really useful site to get meaningful links about London.

</comment><comment> london-24h thanks for posting!</comment>


Beauty of Tcl/Tk in one tweet - <AUTHOR> https://twitter.com/ankovcom/status/1272053135264100354 <comment><USER2> I prefer Rebol or Red VID dialect.

Here's the same code in Red VID...

        Red []

        view compose [
            text (rejoin [{The sum of } figs: [1 2 3 4] { is: }])
            answer: text {}
            return
            button "Push me to calculate" on-click [answer/text: to-string sum figs]
        ]

<comment><USER3> Been looking at Red and Rebol for a long time but unfortunately they can't get this to work in Linux (the last time I tried it)

<comment><USER2> @9214 pointed you to Linux GTK builds of Red. My example was tested in macOS so haven't tried it on Linux but you'll need GTK & 32bit compatibility libraries installed for it to work.

Rebol/View as always worked on Linux though you will also need 32bit compat + Freetype libraries - [https://stackoverflow.com/questions/34524169/rebol-2-stopped...](https://stackoverflow.com/questions/34524169/rebol-2-stopped- working-after-upgrading-to-ubuntu-15-10)

And there's a 64-bit Rebol 3 with R3-GUI from Atronix, which should only need Freetype library installed - [https://www.atronixengineering.com/downloads](https://www.atronixengineering.com/downloads)

The VID has changed a little bit over time. Here's the example in Rebol2 View...

        Rebol []

        view layout compose [
            across
            text (rejoin [{The sum of } figs: [1 2 3 4] { is: }])
            answer: text {......}
            return
            button "Push me to calculate" 200x20 [
                answer/text: to-string sum figs
                show answer
            ]
        ]

And here it is in Rebol 3 / R3-GUI...

        load-gui

        view compose [
            hgroup [
                text (rejoin [{The sum of } figs: [1 2 3 4] { is: }])
                answer: text {......}
                return
                button "Push me to calculate" on-click [
                    set-face answer to-string sum figs
                ]
            ]
        ]

Both scripts above worked fine on my Ubuntu 18 Linux.

NB. Rebol doesn't come with a SUM function so here's one defined...

        sum: func [s /local total] [
            total: 0
            forall s [total: total + s/1]
            total
        ]

</comment></comment></comment><comment><USER4> TclTk is extremely cryptic. I used to code IVR scripts for Cisco access servers in early 20th, most of them still in use today. A couple of unsuccessful attempts were made to customize them by other people, but nobody (including me myself) knows how do they work. The art had been lost forever.

<comment><AUTHOR> In comparison to many popular languages (e.g., Python, Java), to success with Tcl (not only about Tcl), one needs to be a real fan, because it's not about engineering, it's about passion and art

</comment></comment><comment><USER5> Perhaps proof that beauty is subjective

</comment><comment><USER6> Beauty is in the eye of the beholder. Sadly, OP was hallucinating with this tweet.</comment>


The Apple Factory: Software Design in the Age of Steve Jobs (2019)[video] - <AUTHOR> https://www.youtube.com/watch?v=kl2Flp4oK-g <comment><AUTHOR> I strongly agree with this description of the workflow at this [timestamp]([https://www.youtube.com/watch?v=kl2Flp4oK-g&feature=youtu.be...](https://www.youtube.com/watch?v=kl2Flp4oK-g&feature=youtu.be&t=5544)). Very healthy! Very unhealthy when these principles aren't followed for creating truly new products that people really need and want.</comment>


The Singleton Manifesto (1/5) – Using AI to Save Humanity from Extinction - <AUTHOR> Humanity is dying.  It may seem that society has come a long way to preserving and protecting the human race. Yet, after less than fifteen thousand years as a civilization, we are just as much at risk of extinction.
In the twenty-first century, we are force-fed the ideology of the enlightened human. We are taught that with freedom, liberty, and justice — all nicely tied up in the gift of democracy  — humans can create a paradise on Earth, an environment that allows the human spirit to thrive. In this worldview, the human collective prospers when each one of us is given a voice. The human race survives because the collective is responsible for its survival.
Unfortunately, this is a lie. Democracy was supposed to save us from the evils of tyranny. It was supposed to ensure our survival by creating stability and equality. Yet, it too is cursed by short-sightedness.
This leads to a claim that has already been repeated over and over again: human government has never worked and will never work when it comes to optimizing for long-term survival.
In turn, our only fighting chance comes when we choose to fight for the future. And the only way to do that is to remove humans from power.The only practical way to do this is to put computers in charge of our governments.
This concept, termed the Singleton, is tainted by hyperbole. If you talk to any expert out there, you will usually be met with one response - put artificial intelligence in charge of our governments, and humanity faces extinction.
We believe otherwise. We believe that the singleton is not a harbinger of extinction, but our only hope against it.
This is the first in a series of letters to challenge the status quo surrounding this issue. And hopefully, by the end of this correspondence, we hope to convince you that the Singleton is not something to be feared, but embraced.
And so we begin this delicate balancing act. Welcome.
LEO <comment><USER2> > _we are just as much at risk of extinction_

That's not true. Even the worse predictions for Climate Change and Nuclear War don't predict humanity extinction in a close time. (Perhaps 99% of death, that is really bad, but it's not extinction.)

For supervolcanos and big asteroids impacts we are doomed with or without AI.

</comment><comment><USER3> This raises some questions. Is this really a problem of human government or another structural problem : capitalism, inequality, concentration of power or corruption? In what way is it an inherent problem of human government? What is artificial intelligence ? Machine learning, deep learning? Are there not human biases in artificial intelligences?</comment>