Ask HN: How do we solve the Bitcoin schism? - <AUTHOR>

How do we solve the Bitcoin schism? What solutions are you getting behind? What do you personally propose as the way forward? <comment><USER2> An article with background for those (like me) who don't follow Bitcoin news.

[http://www.ibtimes.co.uk/bitcoin-schism-how-bitcoin- became-v...](http://www.ibtimes.co.uk/bitcoin-schism-how-bitcoin-became- victim-its-own-success-1516507)

"Bitcoin is in crisis; Bitcoin is thriving. More people than ever are using the cryptocurrency but as adoption grows the network that it relies upon is running out of spare capacity. Developers fear that within less than a year, the whole thing could grind to a halt. If nothing is done, bitcoin's own success may end up breaking it."

</comment><comment><AUTHOR> I think a Lightning Network might be a good solution, but it's an untested idea: [http://www.coindesk.com/could-the-bitcoin-lightning- network-...](http://www.coindesk.com/could-the-bitcoin-lightning-network- solve-blockchain-scalability/)</comment>


Leica Adds 3D Laser Scanner with 1km Range to Product Lineup - <AUTHOR> https://all3dp.com/leica-3d-laser-scanner-1km-range/ <comment><USER2> That site immediately asks for your geolocation and opens a popup after a few seconds.

Better link to Leica directly instead: [http://leica- geosystems.com/products/laser-scanners/scanners...](http://leica- geosystems.com/products/laser-scanners/scanners/leica-scanstation-p50)</comment>


3-in-1 Machine for 3D Printing, CNC Carving, Laser Engraving. Is it worth? - <AUTHOR> https://8bitwork.com/2019/08/18/snapmaker-is-launching-snapmaker-2-0-a-modular-3-in-1-3d-printer/ <comment><AUTHOR> I don't know hoe feasible it is to have all 3 in one machine. I would never buy something like that. 3d printing and laser engraving are compatible, but the same cannot be said for CNC carving. The rigidity needed just isn't there, and if it was, it would end up being too slow for a 3d printer. If you want a cnc router, just get one separately. When I bought my CNC router I got a 3d printer tool for it and it was a waste of money. It wasn't very good, and a CNC router is way too slow compared to even the cheapest 3d printers.</comment>


Supporting Linux kernel development in Rust - <AUTHOR> https://lwn.net/SubscriberLink/829858/281103f9c6fd0dc2/ <comment><USER2> I'm concerned about the gradual move from GCC to LLVM. The lack of copyleft protections on LLVM means that it's much more dependent on corporate sponsorship, and means that there's a risk that major improvements to LLVM compilers will only become available as proprietary products.

People underestimate the role of copyleft licenses in preserving long-running FOSS products like GCC, Linux, etc.

<comment><USER3> > I'm concerned about the gradual move from GCC to LLVM. The lack of copyleft > protections on LLVM means that it's much more dependent on corporate > sponsorship, and means that there's a risk that major improvements to LLVM > compilers will only become available as proprietary products.

As someone who works within LLVM professionally, I don't think this is particularly likely -- compilers are _massive_ and complicated beasts, and the "moat" for proprietary improvements is small: they're either niche and therefore not of interest to the majority of programmers, or they're sufficiently general and easiest to maintain by releasing back upstream (where Apple, Google, and Microsoft will pay a small army of compiler engineers to keep them working).

Your concern is the one that kept GCC from stabilizing its various intermediate representations for decades, which is why virtually all program analysis research happens in LLVM these days.

Edit: To elaborate on the above: neither Apple, nor Google, nor Microsoft wants to _individually_ maintain LLVM. Microsoft appears (to this outsider) to be actively looking to replace (parts of) MSVC/cl with the LLVM ecosystem, because they're tired on maintaining their own optimizing compiler.

<comment><USER4> I don't consider the improvements that ARM, Apple, Sony, CodePlay, NVidia, AMD, among others, don't upstream due to IP considerations or revealing of hardware secrets, niche.

<comment><USER5> But if they have IP considerations or trade secrets to protect, they wouldn't contribute them to any other open source project either. This way, they can at least upstream everything, which doesn't fall under these restrictions.

<comment><USER4> They don't upstream everything, while reducing their development costs, that is the point.

Personally I don't care, but I bet many FOSS anti-GPL advocates will eventually care.

<comment><USER6> > _They don 't upstream everything, while reducing their development costs, > that is the point._

_ph_ meant to write _" This way, they can at least upstream everything which doesn't fall under these restrictions."_ (note the deleted comma before "which"), i.e., they can at least upstream _something_ instead of _nothing_.

<comment><USER5> Yes, thanks :)

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> If we get the Rust backend for gcc finalized and merged first, it would be much easier to get Rust code into the kernel:

> [https://github.com/philberty/gccrs/](https://github.com/philberty/gccrs/)

<comment><USER8> That's a front end?

<comment><USER9> Compile C to Rust! Easiest language migration ever.

<comment><USER10> That would eliminate the need for Rust. Just imagine, if your C code can be converted into Rust, would there ever be a case to start a fresh project in Rust? It will permanently become an Intermediate language.

<comment><USER11> Converting C to Rust is not that hard. Converting C to _safe_ Rust is the difficult part.

<comment><USER10> Rust without safety isn't Rust at all!

</comment></comment></comment></comment></comment></comment><comment><USER12> One of the challenges to building an entirely new kernel is the vast amount of hardware support in the form of drivers and the features the existing kernel exports to userland in the form of syscalls.

Would it be possible for a hypothetical new kernel, presumably written in Rust, to run an existing kernel such as Linux in a VM, just to tap into its drivers and emulate its syscalls? As more drivers are ported to the base kernel, the reliance on the donor kernel would shrink over time.

Edit: This was an aside. Of course I realize that the conference was about adding Rust code to the Linux kernel, and not about rewriting any large, important, and functional codebase in language-of-the-day™. Hence my speculative language: "hypothetical" new kernel, "presumably" written in Rust.

<comment><USER13> The point of this LPC session was how to incrementally introduce Rust in the existing Linux kernel, with all its existing drivers and syscalls and similar. A rewrite would indeed be a daunting and problematic proposition.

There are kernels written in Rust, such as Redox, but those are separate projects, and that's not what this conference session or article are talking about.

Standing reminder: the Rust project is not a fan of rabid Rust over-evangelism (e.g. "Rewrite It In Rust", "Rust Evangelism Strike Force"), and sees it as damaging and unhelpful. We discourage that kind of thing wherever we see it. We're much more in favor of a measured, cautious approach.

<comment><USER14> Unless the OP changed his comment, this is an overreaction to a harmless, hypothetical, technical question. I've seen a lot of annoying Rust evangelism, but this ain't it.

BTW, I'm not a Rust dev, and it would appear the OP isn't a Rust developer either. They don't even seem aware of Redox. Seems odd to accuse them of "Rust evangelism".

<comment><USER13> I was not accusing the OP or anyone here of such evangelism; rather, because the OP was talking about writing/rewriting a kernel in Rust, I was stating that _we_ weren't looking to "rewrite it in Rust" or similar. We've seen a lot of people suggesting that the work on putting Rust in Linux was trying to "rewrite the kernel", and it seemed appropriate to provide such a disclaimer.

</comment></comment></comment></comment><comment><USER15> > The ubiquitous kmalloc() function, for instance, is defined as > __always_inline, meaning that it is inlined into all of its callers and no > kmalloc() symbol exists in the kernel symbol table for Rust to link against. > This problem can be easily worked around — one can define a > kmalloc_for_rust() symbol containing an un-inlined version but performing > these workarounds by hand would result in a large amount of manual work and > duplicated code.

That's why there exists crates like [https://docs.rs/cpp/](https://docs.rs/cpp/) which allow to embed C++ (and thus C) directly into the rust source code, simplifying the manual work and reducing the duplicated code.

<comment><USER16> Yup - that got a very brief mention in the article as "Google is working on automated C++ conversions"; there's also [https://github.com/google/autocxx](https://github.com/google/autocxx) which builds on top of it.

C++ is a richer language than C and has more information about ownership (e.g., if you return a std::string you know how ownership works; if you have two arguments that are a char * and a length it's much less clear), but additional annotations in the kernel's C headers to convey this level of information in a machine-parseable way would be awesome.

<comment><USER15> The cpp and cxx crates are two different crates with different goal.

The cpp crate is about convenience, but require the use of unsafe within the rust code.

The cxx crate do extra checks making the rust code safer but needs more boilerplate.

In the case of C however, these type checking are not really possible, as you say.

</comment></comment></comment><comment><USER17> Sounds like they have the same problem Apple's Swift does for calling into C/Obj-C.

Two examples: My understanding is that there's a ton of code and added complexity in Swift itself to support Obj-C interoperation. And while you can call C and Obj-C APIs, as-is, there was/is basically a company-wide effort to write API wrappers (aka. overlays) for existing system APIs.

For the second part, maybe if Rust for Linux kernel programming gets to the level of popularity as, say, TypeScript in the JavaScript community, the Linux community will end up creating the needed API wrappers as an organic, group effort.

<comment><USER18> This is mostly just a random tidbit but one of the fascinating things to me about Swift <-> ObjC interop is that it's not just that Swift was modified for ObjC, but ObjC was modified for Swift as well. In general it works pretty well and I wonder how much of that is because Apple can modify ObjC whenever it wants.

<comment><USER4> .NET <-> C++/COM also went through a similar process.

<comment><USER19> .Net is a much simpler integration, all of the support is in the CLR because COM defines a limited ABI that can be called from any language that can walk a few pointers in a C++ vtable given an interface definition.

One can even completely ignore the RCW/CCW support in .Net entirely and just hack together some struct types that match the vtable layout.

<comment><USER4> Old style COM yes, UWP supports much more, value types, enumerations, generics, partial support for implementation inheritance (in context of XAML).

Also you ignored that .NET was made to fully support C++ via Managed C++, replaced with C++/CLI on version 2.0.

<comment><USER19> The WinRT ABI does implement some new features, yes - but they're all still implementable with nothing more than standard C# code with no special support from WinRT itself (in fact, the WinRT ABI integration is being stripped out of the runtime and cswinrt is the way forward).

C++/CLI ultimately still uses the same features the runtime uses for p/invoke calls, though it uses slightly different IL to transition to native code since it doesn't have to worry about an external ABI within a mixed mode assembly. Sure, there's a whole compiler that supports this weird mixed mode world from a language perspective - but it's really boring at runtime.

<comment><USER4> All of that doesn't change the fact that there is tooling in place, and language features (e.g. dynamic for COM, upcoming C#9 improved native FFI) to ease interoperability between managed and some level of C++.

Something that no UNIX does, and we only find similar ideas in Swift/Objective-C++, IBM language environments, and the old OS/2 SOM (Smalltalk/C++).

While everyone else just writes glue code with C like interfaces, as if the world has hardly changed from UNIX V6.

<comment><USER19> Purists may hate it, but as a toy project I've been working on making a stripped-down version of the WinRT concepts that runs on Linux (well, anything with a c++17 compiler and a dlopen function provided by a linker). The guy behind cppwinrt started work on the Xlang project in a similar vein, but it's currently not being worked on so I figured I'd give it a shot.

I agree that C as the lowest common denominator sucks.

<comment><USER4> Good luck with it.

Project Reunion seems to have rebooted everything, which is most likely the reason for it to have stalled.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> We built a whole BPF tool chain for rust :), although not for kernel development.

[https://github.com/solana-labs/rust](https://github.com/solana-labs/rust)

If this kind of seems interesting please send us a CV.

<comment><USER21> Do you have some kind of official blog for this? I'm interested in BPF and currently learning Rust, would love to learn more about this.

</comment></comment><comment><USER22> Probably a crazy unpopular opinion, but I kind of agree with the Hyperbola (GNU / formerly Linux-libre, in future using a fork of the OpenBSD kernel [https://itsfoss.com/hyperbola-linux-bsd/](https://itsfoss.com/hyperbola- linux-bsd/)) devs that Rust in Linux is not necessarily a good thing, for the reasons they mentioned when they announced they were switching kernels ([https://www.hyperbola.info/news/announcing-hyperbolabsd- road...](https://www.hyperbola.info/news/announcing-hyperbolabsd-roadmap/)) (Edit: and the LLVM dependency).

<comment><USER13> The vast majority of the text in that post is inaccurate and hyperbolic. Linux is not "forcing adoption of HDCP" (it's just something Linux has a driver for), Rust does not require internet access to use (and the trademark comments are not particularly accurate either), the Kernel Self Protection Project is alive and well and making new improvements in every new version of the kernel (see Kees Cook's regular blog posts for details), systemd is not spelled "SystemD", gettext has no dependency on Java (and the link _in that post_ explains that). And in general, decisions about what technologies to use are made by those who show up and do the work to build viable solutions, not by people who snark.

It's a rant by an obscure one-developer distribution that _formerly_ used the Linux kernel. Some people are never happy no matter what you do, and if you make the mistake of treating their rants as useful feedback, you get a list of 30 more demands before they'd consider gracing your little project with the honor of their all-important usage again.

<comment><USER23> I think you were being "inaccurate and hyperbolic".

> Linux is not "forcing adoption of HDCP" (it's just something Linux has a > driver for)

What they actually said in the article:

> Historically, some features began as optional ones until they reached total > functionality. Then they became forced and difficult to patch out. Even if > this does not happen in the case of HDCP, we remain cautious about such > implementations.

<comment><USER13> My comment was entirely based on the second link. Direct quote from that:

> Linux kernel forcing adaption of DRM, including HDCP.

(Which linked to a patch adding driver support for handling HDCP, with absolutely no possibility of it somehow being forced.)

Regarding the quote from that interview: sure, and there's also no guarantee that the Linux kernel won't drop support for every architecture except SPARC, except of course for all the people involved not putting up with it. In what possible universe would Linux developers decide it was a good idea to mandate HDCP? It's completely unfounded and unsupported hyperbole and fearmongering, without even a hint of potential truth.

It's also roughly consistent with what I'd expect from someone who thinks that gettext daring to have support for Java and C# format strings is a horrific problem that should be ripped out by the roots.

<comment><USER22> I don't know about Linux, but Mozilla has mandated many things that I would have hoped it never would have, like XUL depreciation, and especially added many anti-features to their largest product, deciding each was not their hill to die on [https://news.ycombinator.com/item?id=24124954](https://news.ycombinator.com/item?id=24124954). I left Firefox and have never regretted it. The Hyperbola devs did the same, and I will be happy to try their OS and support them fighting on every hill they find, no matter how tiny or unimportant it seems to larger organizations.

<comment><USER13> > like XUL depreciation

There were specific reasons for that: [https://yoric.github.io/post/why-did- mozilla-remove-xul-addo...](https://yoric.github.io/post/why-did-mozilla- remove-xul-addons/)

</comment></comment></comment></comment></comment></comment><comment><USER24> Looks like there is a lot of work involved to have anything done, remind me the issues that the Chrome team said 2 weeks ago.

<comment><USER25> There is no doubt a lot of work here, but C <-> Rust interoperability is a lot cleaner than C++ <-> Rust.

And for what it's worth, for almost all langauges C <-> X interoperability is a lot cleaner than C++ <-> X. Since almost all languages (including rust) "speak C", both in terms of compiler support and and being able to map every important C concept to a concept in their language. The same isn't true with C++.

One thing to worry about with adding any language (including rust) to the kernel, is that the next good looking language will probably interoperate well with C and not interoperate well with Rust. So there is a much higher cost the second time you try to add a language.

<comment><USER13> > One thing to worry about with adding any language (including rust) to the > kernel, is that the next good looking language will probably interoperate > well with C and not interoperate well with Rust. So there is a much higher > cost the second time you try to add a language.

This is something that Rust is acutely aware of. There have been many discussions about the idea of a higher-level "safe ABI", such that languages with notions like counted strings or bounded buffers could interoperate with each other without having to go by way of an unsafe C interface.

<comment><USER26> Is there any work currently happening on this. I think this would be huge for many languages so we can finally graduate past the era of C ABI.

</comment></comment></comment></comment><comment><USER27> I won't get tired of repeating the same comment in every topic that suggests Rust to be a great replacement of C in _existing projects_ , that it isn't.

The safety guarantees that Rust provides are neither unique nor complete, and if we discuss the amount of effort necessary for bringing new interfaces like the one this article mentions ("one can define a kmalloc_for_rust() symbol containing an un-inlined version"), we should compare it to other existing solutions, like ATS [1], that are designed to be seamlessly interoperable with C codebases without giving up on the safety side of the argument.

Just a week ago there was a link in ATS reddit channel that advertised ATS Linux [2][3] initiative, that may be of great interest for the same people who are interested in bringing more memory sefety to Kernel development, without giving up on existing C interfaces and the toolchain[4].

[1] [http://www.ats-lang.org/Documents.html#INT2PROGINATS](http://www.ats- lang.org/Documents.html#INT2PROGINATS)

[2] [https://www.reddit.com/r/ATS/comments/ibyczp/ats_linux/](https://www.reddit.com/r/ATS/comments/ibyczp/ats_linux/)

[3] [http://git.bejocama.org](http://git.bejocama.org)

[4] [http://ats- lang.sourceforge.net/DOCUMENT/INT2PROGINATS/HTML/...](http://ats- lang.sourceforge.net/DOCUMENT/INT2PROGINATS/HTML/c2016.html)

<comment><USER28> >The safety guarantees that Rust provides are neither unique nor complete,

Well no language can ever have "complete" safety guarantees. But I would like to know what other languages offer the same set of guarantees without GC overhead. This would include:

* the usual memory safety * no nulls * no undefined behavior * no data races

Does ATS guarantee those things?

<comment><USER29> Yes, ATS can guarantee all those things and more. In particular, ATS allows you to write "unsafe" code, which you then prove safe with a mechanically verified proof. This is in contrast to unsafe Rust, which depends on programmer discipline, and has no (intra-language) mechanism for verification beyond the basic type system. You could say that Rust is all-or-nothing, while ATS allows gradual verification, as well as proving safe much more complex code than you can in Rust. I'm not going to claim that ATS is overall better than Rust - it's not - but it's a far more powerful language than Rust for safe systems programming. It's just that most people are not willing or able to pay the very high price in ergonomics. I recommend watching this presentation for a good idea of what ATS programming is like: [https://www.youtube.com/watch?v=zt0OQb1DBko](https://www.youtube.com/watch?v=zt0OQb1DBko) In short, it's about as user-friendly as an overheating nuclear reactor.

<comment><USER27> > It's just that most people are not willing or able to pay the very high > price in ergonomics.

Hopefully it will get better in ATS3 - [https://github.com/githwxi/ATS- Xanadu#project-description](https://github.com/githwxi/ATS-Xanadu#project- description)

</comment></comment></comment></comment><comment><USER30> I believe someone will show up and rewrite entire kernel in Rust.

<comment><USER4> Better start fresh with proper OS architectures, [https://www.redox- os.org/](https://www.redox-os.org/)

</comment></comment><comment><USER31> So glad that Rust at 1.38 ditched the Ada model of compiling all dependent modules firstly.

<comment><USER32> Can you please expand further on what you mean by this? Are you saying that rustc is compiling a crate before its dependencies?

<comment><USER33> Compilation in Cargo has been split into metadata pass and code generation pass. Metadata part has interdependencies, but is relatively fast (it's roughly like a C header generation). This allowed more codegen to be done in parallel.

To be honest, it was a modest improvement, because compilation has been decently parallelized already (compiler uses incremental builds, parallel codegen, and ThinLTO even within a single crate)

</comment></comment></comment><comment><USER34> It's not about safety, if that was the real argument we should start with obvious improvements like checked C [https://github.com/microsoft/checkedc](https://github.com/microsoft/checkedc) The C++ lifetime checker or Cyclone

<comment><USER16> Checked C addresses a small number of memory safety problems - it addresses bounds checking / buffer overflows, but not use-after-frees, double frees, data races / insufficient locking, and several other things that fall into the general category of "memory safety," nor more general "safety" things like type confusion.

The kernel is not written in C++ and is unlikely to use C++, for many reasons - Rust is a more natural C-but-better for the kernel than C is.

Cyclone hasn't been maintained for over a decade; it was a research language, and it largely served its purpose as a research language in inspiring production-supported languages like Rust.

</comment></comment><comment><USER35> What kind of performance hit is rewriting part of the kernel in Rust going to entail when it comes to compiling the kernel? How many platforms will cease to be able to compile their own kernels? The article says there will be some, but doesn't give numbers.

More worryingly, the article also says that only some platforms will be "Rusted" in this manner, splitting the codebase into "mainline Rust" and "obscure platform C" as far as these sections are concerned; this seems like it will fracture the development community between people who know Rust and those who don't, and those who can work on mainstream platforms and those who can't. Fewer eyes on this code seems like the wrong way to go.

<comment><USER26> The point is that if you implement a driver for a device that only exists on hardware that supports LLVM then there is no problem.

<comment><USER35> No, the point is that increasing the number of languages in the kernel imposes restrictions.

(The further point is that it's impossible to have this discussion here.)

</comment></comment></comment><comment><USER36> Pretty soon they'll be arguing for inclusion of JavaScript in the Linux kernel</comment>


What's behind Mediterranean diet and lower cardiovascular risk - <AUTHOR> https://medicalxpress.com/news/2018-12-explore-mediterranean-diet-cardiovascular.html <comment><USER2> Researchers at the Monell Chemical Senses Center in Philadelphia and the University of Pennsylvania found that extra-virgin olive oil contains an anti- inflammatory agent that acts similarly to how ibuprofen does. They named the substance oleocanthal:

[https://www.monell.org/news/news_releases/olive_oil_contains...](https://www.monell.org/news/news_releases/olive_oil_contains_natural_anti_inflammatory_agent)

So a lot of people in the Mediterranean consume an anti-inflammatory as part of their daily diet. I believe the thinking is that this is _part_ of the lower cardiovascular risk, but not the only factor by any means.

</comment><comment><USER3> "The team also explored why and how a Mediterranean diet might mitigate risk of heart disease and stroke by examining a panel of 40 biomarkers, representing new and established biological contributors to heart disease. ... The team saw changes in signals of

* inflammation (accounting for 29 percent of the cardiovascular disease risk reduction)

* glucose metabolism and insulin resistance (27.9 percent),

* and body max index (27.3 percent).

The team also found connections to blood pressure, various forms of cholesterol, branch-chain amino acids and other biomarkers, but found that these accounted for less of the association between Mediterranean diet and risk reduction."

The _suggestion_ from the data being that inflammation and insulin resistance might be more important factors than the usual cholesterol panel that people tend to fixate on.

</comment><comment><USER4> I have friends in Athens, whom I visit. I've observed that most of the time they put their virgin olive oil on the food once it is done cooking. When asked about it they claimed that the oil is 'full of healthy things that turn cancerous when burned.'

They rarely use extra-virgin to cook with, either.

<comment><USER5> Extra virgin olive oil is the first press oil. It contains particulates that have a very low smoke point. You should not be cooking with extra virgin olive oil. Pure olive oil is a later hot press extraction and does not have the particulates. It has a much higher smoke point. Im not convinced that US stores are actually selling extra virgin olive oil anyway outside of specialty shops. Olive oil is supposed to be fresh and should taste spicy at first.

<comment><USER6> Your suspicion is substantiated [1]. Olive oil bought from U.S. producers will have had substantially less opportunity for adulteration, as their processes are certified by U.S. authorities (this is a mitigation and not a guarantee).

1\. [https://www.telegraph.co.uk/news/worldnews/europe/italy/1198...](https://www.telegraph.co.uk/news/worldnews/europe/italy/11988947/Italian- companies-investigated-for-passing-off-ordinary-olive-oil-as-extra- virgin.html)

</comment></comment></comment><comment><USER7> I've always wondered if Americans can follow the Mediterranean diet with all the reports of our olive oil being conterfiets.

<comment><USER8> Look for olive oil from California. It's really only olive oil.

<comment><USER9> Yeah cause there's no way they'd fake that

<comment><USER10> Exactly.

Domestic production is regulated and certified by the US government, transported through short supply chains subject to auditing. Tampering with food supplies is very difficult to execute and harshly punished when inevitably detected. Food safety and consumer confidence are a high priority for commercial and public interests... you have never worried about watered down milk, you shouldn't worry about 100% domestic olive oil.

Compared to imported goods... foreign governments are trusted to do their job before goods make their way through long and slow international supply chains. Plenty of time for undetected tampering before goods make it to American distributors. Tracking down diluted olive oil across an ocean is difficult, the other side has plausible deniability, the risk/reward of the crime is much better.

I'm not saying our oil is _better_ \- just trustworthy. You get what the label says.

</comment></comment></comment></comment><comment><USER11> Here's a simple trick to avoid cardiovascular risk: any diet that reduces the amount of meat people consume. Overwhelming majority of Americans eat too much meat (with respect to health), so any diet that has less meat in it will on average improve their health. No surprise: [https://nutritionfacts.org/2018/02/06/how-healthy-is-the- med...](https://nutritionfacts.org/2018/02/06/how-healthy-is-the- mediterranean-diet/)

</comment><comment><USER12> What if it's not diet.

I read somewhere that Silicy has higher life expectancy although it's poor (probably worse healthcare) in comparison to North Italy.

Maybe it's not diet but the family values? Maybe being family focused increases life expectancy despite having not superior diet.

<comment><USER13> You are assuming that poorer means worse diet.

That is simply not true at all in relation to having a healthy diet, and the opposite is perhaps true.

In many places the traditional diet is healthy. Then, when people become richer they eat more, eat more meat, more fat, more sugar, more processed food, etc., and obesity and cardiovascular diseases shoot up.

<comment><USER14> As a poor person who's always been surrounded by poor people, you are wrong.

Poor and less educated people know nothing about nutrition and don't have the money to buy good food.

When you don't have the money you are forced to fill up with cheap calories like bread, rice, pasta, sugar, etc.

<comment><USER15> > _Poor and less educated people know nothing about nutrition and don 't have > the money to buy good food._

In societies with traditional agriculture and village culture, they don't have to "know about nutrition". Their traditional recipes and ways of eating are healthier, and cheaper.

That's not an absolute rule, but that's exactly the case with Mediterranean diet for one.

> _When you don 't have the money you are forced to fill up with cheap > calories like bread, rice, pasta, sugar, etc._

Some of which is fine. The healthier people in Japan eat a lot of rice, and bread is mighty fine too, as are noodles etc.

Sugar and highly refined breads are recent inventions. They poor people in Italy pre-70s would hardly have much sugar in their meals except from natural sources (tomatoes etc, not refined). No fast-food and crappy supermarket tv- diner style food either. People cooked religiously.

Also the poor masses in Italy etc were traditionally not destitute (e.g. developing world-like). Just poor. They could still afford basic meals, and had strong family support.

</comment></comment></comment></comment><comment><USER16> Could another factor be physical activity? The extent of many Americans' physical activity is walking from the car to the entrance of a building; the fad goal of 10,000 steps is fairly trivial to hit if you walk to work or use transit on a regular basis.

Survey from NYC comparing exercise by primary modes of transportation: [https://www1.nyc.gov/assets/doh/downloads/pdf/epi/PAT- survey...](https://www1.nyc.gov/assets/doh/downloads/pdf/epi/PAT-survey- summary.pdf)

</comment><comment><USER17> I always feel apprehensive about 'region X's diet is the healthiest' articles. To me, the strongest example for this is the Japanese diet. Whilst their diet _is_ healthy in many ways, it also raises your risk for stomach cancer by quite a lot.

<comment><USER18> I agree that I think that diet is one significant part of a (probably complex) equation - not a single deciding factor.

But regarding Japanese stomach cancer... if you're saying they get stomach cancer more than others because of their diet, how do they still live so long? Do they also have a secret way of beating the cancer so it doesn't cut their lives short?

<comment><USER17> For one they are aware they (as a population) get stomach cancer more often, so they actively screen for it, in the way most countries in the West screen for colon cancer.

Remember that some types of cancer, if caught early enough, are more akin to a chronic condition than a delayed death sentence. Once treated there are quarterly or bi-annual checkups and any suspicious tissue will be removed preventatively. You still have a much higher chance of stomach cancer popping up again vs. someone who never had it, but with the checkups it'll be nipped in the bud before it grows into something severe.

That might sound offhand but that is how it is for (as far as I'm aware) bladder cancer and most gastrointestinal cancers. Cancer in the lungs, liver or brain usually is much much more dangerous because there's little screening and they're much more resistant to treatment.

</comment></comment></comment><comment><USER19> Mediterranean countries also have some of the worst economies. Could this also be related to diet? (I ask this as a legitimate question, not as an attack on Mediterranean countries)

<comment><USER20> Hardly.

It has more to do with gastronomical culture, I think. In Italy, for example, eating quality food is _important_, it is something people care about and actively look for.

This has a low correlation with social or economical status, is something deeper, something that people learn to do since kids, looking at their parent's behavior, going with them at the market and learning how to choose good ingredients, spending time cooking.

</comment></comment><comment><USER21> Valter Longo's research has a good explanatory framework for this effect. For an introduction, The Longevity Diet (2016) is worth a read.

</comment><comment><USER22> [deleted]

<comment><USER23> I think they don't mean people in Mediterranean, but people following Mediterranean diet - frequently advised for heart health

<comment><USER22> [deleted]

<comment><USER24> This study looked at Americans following the Mediterranean diet.</comment></comment></comment></comment>


How to become your own boss - <AUTHOR> http://www.bbc.co.uk/news/business-19542914

<comment><USER2> TL;DR: remarkably lightweight article, mostly a puff piece about one particular entrepreneur.

General good advice found within: "there are as many opportunities in a down market as in an up market", "setting up a business you essentially have do five years of work in one year", and "don't bet the family home".</comment>


Ray Dalio – Why and How Capitalism Needs to Be Reformed (Part 1) - <AUTHOR> https://www.linkedin.com/pulse/why-how-capitalism-needs-reformed-ray-dalio/ <comment><USER2> Dalio compares capitalists to socialists using the old saw: one has trouble slicing up the pie, the other has trouble growing it. More appropriate today from my experience working as a commodities trader: the financial sector eats the pie that the real economy bakes. I retired comfortably after only 10 years on the Street ... but I'm not proud of what I accomplished. And neither should you be, Mr. Dalio.

<comment><USER3> The financial sector provides the work of analyzing economic need to better allocate capital. It is real work, that adds real value to the economy. The problem with the financial sector is that barriers to entry, created to "protect retail investors" and "mitigate systemic risk", result in the vast majority being excluded from the industry and a small elite capturing the majority of profits.

Any development that threatens to disrupt the regulated financial sector is dealt with harshly by regulatory agencies, as in the case of the token sale market and the SEC's enforcement actions against token sale organizers.

<comment><USER4> > created to "protect retail investors" and "mitigate systemic risk", result > in the vast majority being excluded from the industry and a small elite > capturing the majority of profits.

Most Americans don't make enough to have anything left over to invest in the markets. This isn't a regulatory failing, this is a labor regulation failing.

<comment><USER5> > Most Americans don't make enough to have anything left over to invest in the > markets.

This assertion is not supported by demographic statistics. The _median_ US household has ~$12,000/year in investable cash, after _all_ ordinary expenses. Whether or not they actually invest any of this cash is another matter.

<comment><USER4> 57 percent of Americans can't come up with $500 for an emergency expense. Based on that, I disagree with your assertion regarding investable cash.

</comment></comment></comment></comment></comment><comment><USER6> Problems have solutions, Contradictions don't. Capitalism has Contradictions[1]

[1] [https://thewire.in/economy/david-harvey-marxist-scholar- neo-...](https://thewire.in/economy/david-harvey-marxist-scholar-neo- liberalism)

</comment><comment><USER7> Glen Weyl's RadicalXChange movement is the most sensible alternative to capitalism out there, imo. The Herberger tax/COST and liberal radicalism are great ideas.</comment>


Lineageos: New Mascot and Br0zip - a new era of ROM building - <AUTHOR> http://lineageos.org/Announcing-our-Mascot/ <comment><USER2> The unwritten rule of the painfully obvious corporate April Fool trick is that you try and trick your customers into believing you're about to do something really silly or strange. It's probably not such a good idea to promise things that your organisation would like to be able to do, but can't actually deliver. That only disappoints anyone naïve enough to fall for it and emphasises how far short of these aims lies your reality.

(Hence the general lack of "Cure found for Cancer" headlines amongst the April Fool press releases)</comment>


Ask HN: Have you ever over-engineered something? Why? - <AUTHOR> <comment><USER2> Yes, a lot. I feel that I'm doing it more often now. I'm 5-year exp. now, and the unexpected expectation of ensuring that it should be self-sustainable in the future is making me spend more time in even small thing, which is definitely over-engineering.

Often meeting goes like,

Person 1 - this should do it

P2 - But if we do that, that will also cover that2 in future

P1, P3 - Make sense, let's do it.

P4 - We should also do that3.

All - Lets put up our points on a Doc, and discuss it again tomorrow. We shouldn't build something which we have to revisit in the future, it will be a waste of time otherwise.

All agree, adjourned.

(P1 to Pn are interchangeable)

<comment><USER2> I also feel that spending a lot of time reading Uber/Netflix blogs (or similar stuff) is not what I should do, for an hour, first thing in the morning.

</comment></comment><comment><USER3> All my life. Sigh. Engineers often don't have skin in the game in the way an entrepreneur or a business owner does.

I think when we are shielded from harsh realities of the market. We build something we want and consider cool. Not something that is useful.

<comment><USER4> Yeah, but when you let the bean counters make engineering decisions it is all about cost and nothing about value.

So when you are actually engineering tangible real world items (eg cars and buildings) that have substantial embodied energy "over engineering" can sometimes actually mean making something of long term quality and value that lasts past fashion and trend.

</comment></comment><comment><USER5> yes my boss believed it was a divine creation, and i jumped ship as soon as that started being talked about</comment>


Ask HN: Large client demands our code be given to a trustee - <AUTHOR> We're a small startup, providing a whitelabel SaaS. A large potential client demanded that a copy of our source code would be entrusted to a third party (attorney) to be released to them only in case our company goes belly up.
We have reservations about code not being under our control.
Has anyone experienced something similar? What are the risks? Could they be mitigated? <comment><USER2> This is a perfectly normal request and also perfectly reasonable.

They'll also expect very clear steps on how to install it and get it running.

Consider the scenario from the clients perspective. They are being asked to base a portion of their lively hood on a small company. They just want to make sure they can continue to function if you get bought and shuttered, or go bankrupt.

I'm not sure what reservations you'd have. I mean a trustee's entire value is in their reputation, so if they give away your source code they are done. I'm going to guess your source code isn't what some lawyer wants to end their career on.

Maybe turning the question on its head, what possible reservation would you have with this?

<comment><AUTHOR> Basic reluctance for someone having some 'claim' on our code, that could potentially legally limit us in the future. Perhaps future investors would have reservations?

<comment><USER3> It depends on how this is put together in your contract with this customer. Escrow should be treated as insurance rather than claim - your work is not (or at least should not be) made available to this customer, it's with trusted party.

<comment><AUTHOR> Thanks!

</comment></comment></comment></comment><comment><USER3> Hey, it's good problem to have, especially if you are a small startup :-) That means there is probably enough interest in you for those big guys to build something serious on top of your product. If I was CIO or anything else at exec level I would not continue with you until your code went through proper escrow (not only 3rd party storage but also 3rd party audit) - this is reasonable, especially if you plan to base some high-revenue plans on new product.

You will be fine as long as you have other customers and your survival is not dependant on that particular customer. If you are unsure here then you might be better to ask their intentions and if these are very serious maybe they will buy you off and save the hassle :-)

</comment><comment><USER4> This is pretty standard for dealing with enterprise clients. They literally just want a copy of your code in escrow so they're not left hanging if you go out of business. They usually pay the escrow costs and you ship a CD-ROM or something. In my experience, this just happens once and nobody thinks to ask for updates once it's done.

</comment><comment><USER5> I've seen that being required of very small software houses selling to bluechip corporations. There are professional services like Iron Mountain that specialize in code escrow.

I'm not a fan of it, it's a stupid idea frankly. But it does exist in the wild.</comment>