Contributors Leaving Pytest - <AUTHOR> https://twitter.com/brettsky/status/1248690641539760128 <comment><USER2> I feel very uncomfortable whenever I read a code-of-conduct, including the PyTest one:

[https://github.com/pytest- dev/pytest/blob/master/CODE_OF_CON...](https://github.com/pytest- dev/pytest/blob/master/CODE_OF_CONDUCT.md)

I don't think there's anything wrong at all with the spirit of such documents, but they seem to normalize a world where bad behavior is regulated by well- intentioned ad hoc legalese.

In the good old days, one would receive on the spot practical training on how to behave by ones parents, friends, older siblings, teachers etc. I suspect my revulsion at reading codes of conducts is part of me being in denial that there are so many more people in the world now, on the internet, who were raised by the social / etiquette equivalent of animals.

<comment><USER3> The problem with "on the spot practical training" is that not everyone gets the same training across cultures or economic groups. This gives some groups a permanent embedded advantage over others, which is the opposite of meritocracy. Ad hoc enforcement only makes this worse. The ad hoc legalese in a code of conduct _can_ bring more consistency to both rules and enforcement, though regrettably many implementations fall short.

<comment><USER2> You make a good point — I suppose conduct codes are the HR department for mailing lists. I've always thought of collaborative open source communities as groups of friends or at least like minded hobbyists with a common thread of likeability, but I suppose they are a lot more like workplaces.

</comment></comment></comment><comment><USER4> So some person is doing some thing and it drove multiple people out.

This desperately needs a summary for anyone not embedded in the pytest community.

</comment><comment><USER5> I don't understand why the problematic individual is not named. I guess most people in the pytest community know who it is, but other communities need to be warned too, in case s/he moves on to some other project.

<comment><USER6> They are. Not directly, but through heavy hints in _that_ thread. I really hope they have evidence to back this up, because from my POV they all but identified the guy after being unhappy with the action of the CoC comittee.

Maybe they don't care now they've left, but on the other hand maybe they hope the guy is kicked out at which point they can return; but is that really reasonable after essentially circumventing the CoC process?

</comment></comment><comment><USER7> Genuinely puzzling considering the mailing lists are quite civil and actually a generally pleasant seeming place - except for the top posters - may they burn! jkjk :D

Anyway, according to Github recent history, the top recent committers are:

* [https://github.com/nicoddemus](https://github.com/nicoddemus) (leaving)

* [https://github.com/blueyed](https://github.com/blueyed)

* [https://github.com/RonnyPfannschmidt](https://github.com/RonnyPfannschmidt) (leaving)

* [https://github.com/asottile](https://github.com/asottile) (leaving)

* [https://github.com/bluetech](https://github.com/bluetech) (elevated last month to core)

* [https://github.com/thisch](https://github.com/thisch) (last in mid 2019)

Honestly, I didn't realize pytest was such a German product. Fascinating.

</comment><comment><USER8> three contributors have left: [https://mail.python.org/pipermail/pytest- dev/2020-April/0049...](https://mail.python.org/pipermail/pytest- dev/2020-April/004941.html)

this is sad but echoes something i have seen far too many times. i wish them the best luck. especially at times like these; they need to prioritize mental health over dealing with individuals online.

sometimes it's not even about trolling but about having a bigger voice than others online...

</comment><comment><USER9> Other threads: [https://news.ycombinator.com/item?id=22838951](https://news.ycombinator.com/item?id=22838951) and [https://news.ycombinator.com/item?id=22837373](https://news.ycombinator.com/item?id=22837373)

</comment><comment><USER10> What's going on? I can't find anything concrete

edit: Seems to have something to do with the CoC?

<comment><USER5> No, the only issue with the CoC is that it seems unable to resolve the situation. They have a CoC board but apparently it won't act in this case.

<comment><USER10> I was judging from [1]: "I am contemplating to follow the #pytest exodus, I previously left the CoC team because of the issue at hand"

[1] [https://twitter.com/ossronny/status/1248674298807627778](https://twitter.com/ossronny/status/1248674298807627778)

<comment><USER5> Yes - the CoC seems powerless to stop the problem. That guy recognised that earlier and dropped out of the CoC board; eventually he followed others who dropped out of the project.

From what I can determine, this is not one of those "omg the newfangled CoC is driving people away" situations, but rather "we have an asshole in our midst and, despite all the big words about CoC, nothing actually gets done about it, so I'm out".

</comment></comment></comment></comment><comment><USER11> It would be funny if of the three that has left A has an issue with B who in turn has an issue with C who has an issue with A. But it's not funny.</comment>


How did software get so reliable without proof? - <AUTHOR> https://surfingcomplexity.blog/2020/03/02/how-did-software-get-so-reliable-without-proof/ <comment><USER2> How does software get reliable at all, ever? In my experience there are two ways:

1\. You write reliable software from the start. It feels a lot like writing a mathematical proof, or at least sketching one. After a few dumb bugs are fixed the code continues to work without issue, year after year, and nobody ever looks at it again. (This isn't as hard as it sounds! It's not the right approach for everything, but it should be more widely used than it is.)

2\. You write normal software, i.e. unreliable crap, but you look at the ways that it goes wrong and fix them. This requires that you put some work into detecting that things have gone wrong. A lot of software companies will trace all crashes, and aggregate stack traces and logs from them. In this kind of environment, you can improve software reliability by sticking a paranoid number of assertions in your code and obsessively checking to see what triggered them. After a while all the common problems will have been removed, and the remaining bugs will be less prevalent than hardware failures -- and then you can declare victory.

<comment><USER3> In my experience the majority of enterprise service applications and smaller few-purpose systems are build following 1.

We've have an ASP Web Forms food ordering system that's basically four forms and a simple CRUD admin system page that's been running flawless for half a decade. It's only needed upgrades to its .NET system as we moved up the TLS version ladder, and it has thousands of daily users. There are no tests, no real monitoring outside of "is it still up?" and no complaints.

Eventually we'll have to clean up the database, eventually. But chances are someone will have build something new by then.

<comment><USER4> I doubt that would be 1 and not developed using 2 followed by a "don't touch" policy, tbh

<comment><USER5> We have one project under a don't touch policy. Sure it is probably the most stable project because no features are getting added but it is also becoming a maintenance nightmare the longer we accumulate interest on our technical debt. There is a version 2 planned that will add a lot more features and I'm sure we will spend the first weeks on upgrading the libraries it is using because they are a major version or two behind.

</comment></comment></comment></comment><comment><USER6> > _How did software get so reliable without proof?_

Simple, software started shipping with more bugs in backlogs :-P

— More seriously, software today is endemically crappy, and often poorly designed. I dunno why Hoare thought it was any better. The only saving grace is that (modern) software largely stays away from _serious_ stuff. Eg: The airline industry is reluctant to upgrade software from decades ago, but happy to incrementally upgrade other pieces of the system on shorter cycles. Then of course, we have systems like the Boeing 737Max MCAS where the software did what it was supposed to (taken literally) but the software system was poorly designed.

EDIT: Just remembered this fantastic talk by Joe Armstrong [https://youtu.be/lKXe3HUG2l4](https://youtu.be/lKXe3HUG2l4)

The smooth running of _every_ abstract system depends crucially on the (human) operator handling the point of contact with reality, in practice, often bending reality to make it tractable for the system. Any bureaucracy would grind to a halt if it wasn't intelligent humans carrying out the processes! Software is no different.

Just like it's hard to take a technology from "zero to one", it is hard to take the amount of necessary human oversight from one to zero. For this reason, I would much rather think of software as amplifying the capabilities of that human, rather than automating away other humans. In practice, these systems will end up needing a highly skilled and trustworthy human operator to shepherd them — might as well design the system to make it maximally easy for those operators to understand/debug/tweak.

<comment><USER7> > software today is endemically crappy, and often poorly designed

So is every other engineering product that hasn't gone through years (decades) of evolutionary refinement.

<comment><USER8> I doubt software engineering is engineering discipline. At least not the way we are doing it now. We are not engineers, we are craftsmen. It is a miracle that the software that drives the world more or less works. So far there hasn't been any major catastrophe due to software but it will happen. Software sucks.

<comment><USER9> Over time, I think I am coming to agree with you.

I went to an engineering school. People who designed bridges had a wide, but constrained parameter space, and well-accepted design patterns.

I started out in semiconductor (MCU) systems and sometimes circuit design, and we had a broader (but not yuuuge!) parameter space, but it was growing as transistors got cheaper. Less well-accepted design patterns, because what you do with 50K transistors and 500K transistors and 5M transistors and 50M transistors - to use effectively - you need different patterns - and that changed so _fast_!

I did software-ish things with my h/w teams, and they would mock me because "software is easy". "You can do anything". And to do a rev, you didn't need to burn a $50K and 6 weeks (or whatever it is now) at the fab for each turn.

The problem with software is that it is SO unconstrained. You truly CAN do anything - except engineer in an unconstrained environment. I guess this realization (and Python blowing up on me in run-time environments) have taught me that: Constraints suck. But they are good. Software could use more of them, because they force discipline at dev time, at compile time, which reduces blow-ups at run-time.

<comment><USER7> > I went to an engineering school.

My father attended MIT in the 1940s. He said that the engineers at MIT designed the new chemistry building, with all the latest features to support laboratories. Only when the building was completed and scientists were moving in did anyone realize that there were no toilets.

<comment><USER10> Rumor has it that the U. of Waterloo was designed without including the weight of ... books. So the building is sinking.

<comment><USER11> This rumor also exists for the Robarts Library at UofT, and in both cases, I am quite certain, it is just that - a rumor.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> I've worked on software for some time and have seen a wide range of interesting failure modes. All of the interesting failures (some of which have had large monetary or visible outage impact) involved systems that broke in ways that aren't well-addressed by proof systems. Instead, they've been about things like statistical binning of parts, rare errors that escaped through middling checksums, and complex distributed systems. In most of these cases, there is some physical component, such as corrupted packets which pass CRC checksum, or a chip that occasionally miscomputes the hash of a string. Not sure how proof systems handle this, but in practice, those have been some of the most impactful errors, and they are typically dealt with using heavy but not comprehensive software testing.

<comment><USER13> In my experience the interesting failures are a tiny fraction of the failures; your mind just glosses over the vast sea of boring failures. The most impactful software flaws have not been subtle logic misalignments, they've been utterly basic errors like Cloudbleed or the Arianne 5 overflow. Maybe proof systems can only address 99% of software failures; my guess is that with experience we'll find ways to cover the rarer cases as well, but even if we don't, they're still worth using.

<comment><USER14> Well, maybe. Additional costs with these approaches are often ignored. I wouldn't want to give up proof systems as a tool, but too many treat them as a zero cost panacea. A proof system or type checker is not an excuse to not give a f __k about your craft, but I 've seen it that way more frequently than I'd like to admit.

Personally and honestly, outside of already well understood or defined systems, I'd say that people should invest their time in understanding their _business_ domain, before they dig deep into proofs and related techniques.

<comment><USER13> > Well, maybe. Additional costs with these approaches are often ignored. I > wouldn't want to give up proof systems as a tool, but too many treat them as > a zero cost panacea. A proof system or type checker is not an excuse to not > give a fk about your craft, but I've seen it that way more frequently than > I'd like to admit.

The acceptable defect rate to the business is presumably fixed, so if a proof system or type system reduces you defect rate below that then that _should_ be an "excuse" to write fewer tests and move faster, as icky as it feels to do that. I find the maintenance burden of tests is often underestimated; types in particular may not be free, but they get you more bang for your buck than any alternative, in my experience.

> Personally and honestly, outside of already well understood or defined > systems, I'd say that people should invest their time in understanding their > business domain, before they dig deep into proofs and related techniques.

Isn't it the same thing though? Encoding your business domain into the system you're using is the hardest part of using any formal system, but it's also an excellent way of forcing you to really understand the domain.

<comment><USER14> In my experience, people either truely care about the business domain, and are willing to be uncomfortable to delve into it, or not. Types and proofs seem to be orthogonal.

Some domains are worth it, some are not. Sometimes it fits well, sometimes it doesn't.

Just don't be the one sinking into the muck saying, "...but the math worked". The math will be far more reliable than your understanding of the domain.

</comment></comment></comment></comment></comment><comment><USER15> Isn't it evolution and Darwinian selection?

Bad pieces tend to die out, good pieces get replicated, "breed", mutated and incorporated[1]. Biological systems are not fault-tolerant. They are resilient _on the average_ , under typical conditions.

[1] Among species, we get vertical transfer of genes (parent(s) to offsprings), horizontal (e.g. plasmids between bacteria). Getting as a piece of DNA as a submodule (this element-of relationship) is rare... but happens (e.g the mitochondrium). In software, it is one of the most common relationships.

<comment><USER16> Not quite? Life is resilient under the worst case. If it weren't, the first time the worst case came around (drought year/early freeze/whatever) that form would become extinct.

Sure there's a distribution (gene pool) and some is merely resistant under normal conditions. That kind prospers, but keeps the 'worst case' genes handy. A few members of the population are the 'prepper' members, and if this year is the worst case then the species survives.

Anyway something like that.

<comment><USER15> Drought is still a "typical" condition. (I.e. one from its environment, from the last hundreds of thousands of years or so.) Selection pressure worked on that. Yes, it may be a condition that makes 10%, 50% or 90% percent of the population to die - and it is not a problem, in the grand scheme of things.

Not normal conditions are things that were never tested, or never tested to that extend. E.g. an invasive species from a different continent, a chemical compound, different pH of water, etc. Consequently, many species die out completely - as there is not enough time for the selection of better-fitted genes for this setting.

Also: compare with machine learning, and giving a sample out of the training dataset distribution (all photos are shot in good light, give one in the dark). Usually, the answer is meaningless.

</comment></comment></comment><comment><USER17> How did proof itself get so reliable? The process of convincing yourself that a proof is correct isn't so different from the process of convincing yourself that a program is correct.

<comment><USER18> Yes, it is. This can be shown with theory: proving a program is correct is NP- hard, but verifying the proof is in P-space. It is way easier to show a proof is correct than to generate the proof in the first place.

<comment><USER17> True, at least for formal proofs. I was thinking more of traditional mathematical proofs, which are often as hard to formalize as programs are to prove correct. In both cases, convincing yourself that the proof or program is correct involves reading it and seeing whether each of its parts follows from or fits into the other parts to make a coherent whole.

Of course, there are ways to fool the reader, but I think people learn to avoid writing in ways that are likely to mask errors (e.g., not reusing the same symbol to mean completely different things, both in proofs and in programs).

</comment></comment></comment><comment><USER19> Every piece of software defines an input space of all possible inputs for that software. This space is staggeringly, exponentially enormous. However, the space of inputs that are actually given to the software are generally an exponentially small subset of the possible inputs. Making this often very stereotypical and "friendly" space of inputs do mostly sensible things is at least polynomially, if not exponentially, simpler than making the software be entirely correct.

It is both true that software is a streaming pile of bugs, where the vast, vast majority of responses to possible inputs is somehow wrong, yet the vast, vast majority of inputs actually processed by the software are mostly correct (not entirely, but mostly) because they are in the generally polynomial subsets of the exponentially complicated space that the developers made correct... ish.

<comment><USER20> To expand on this, floating point works for 95% of programs. It is the 5% that needs exact accuracy/precision offered by arbitrary precision libraries. Most programs hardly exhaust the entire range of your typical floating point usage range. For example in a GUI you won't be able to easily tell the difference between 100% and 99.9999999% by eyeballing.

</comment></comment><comment><USER21> Except that we continue to slowly automate away human intervention (must be done reasonably; it must still be _possible_ , it is just less current in practice). Just look at the state of the art in field X at date T, then 10 or 20 years after.

We are getting better at some software, and why would we not? Not all SW, but some, and even probably a lot of. Likewise for VLSI (which in some aspects is quite similar to SW); there are some quirks, but it basically works despite the modern designs being of unprecedented complexity. With a reliability way higher that tons of high ends mechanical devices. Same story for off the shelf standard operating systems even for absolutely not critical software: given the application are somehow tolerant to crashes (the user just restart), it is remarkable that we get so few.

I'm a firm believer that there is no SW crisis. There are people or companies refusing to apply best practices here and there, or even not knowing they exist, but that is another story.

</comment><comment><USER22> As a software person, I found Richard Feynman's paper "Personal Observations on Reliability of Shuttle" quite interesting.

[https://www.history.nasa.gov/rogersrep/v2appf.htm](https://www.history.nasa.gov/rogersrep/v2appf.htm)

The part about software reliability stuck in my head, because he quickly came to the conclusion it was fine.

Now shuttle software is probably the most special type of software on the planet, but it made me think how reliable software is... compared to hardware (and possibly people).

<comment><USER23> Physical things tend to not yield to abstractions as much. While people talk about how difficult software debugging is when the illusion of a high level abstraction is broken, still it's more of an exception.

</comment></comment><comment><USER24> > The ultimate and very necessary defence of a real time system against > arbitrary hardware error or operator error is the organisation of a rapid > procedure for restarting the entire system.

"Just putting out the plug and stick it back in" is one common way nowadays of how to get out of an unforeseen state. It has quite some history and goes at least back to the "let it crash" philosophy of Erlang. Of course this still does not work for all kind of domains, especially when one is closer to the metal. But still, we may have found a sufficiency compromise between formal verified software (and thus, higher costs) and some kind of fault-tolerant software (increased productivity).

<comment><USER25> Or, in another word, "disposability". We have a lot of systems that aren't repairable, don't get debugged, don't have things fixed mid-flight.

And...it works, with respect to most existing challenges. Restarting and replacing is easy to scale up and produces clear interface boundaries.

One way in which it doesn't work, and which we still fail, is security. Security doesn't appear in most systems as a legible crash or a data loss or corruption, but as an intangible loss of trust, loss of identity, of privacy, of service quality. We don't know who ultimately uses the data we create, and the business response generally is, "why should you care?" The premise of so many of them, ever since we became highly connected, is to find profitable ways of ignoring and taking risks with security and to foster platforms that unilaterally determine one's identity and privileges, ensuring them a position as ultimate gatekeepers.

</comment></comment><comment><USER26> Simply an absurd amount of hard work. Millions upon millions of person-hours spent banging foreheads against C++ and the like. Billions of gray hairs. But that's progress for you.

</comment><comment><USER27> The most trivial software system you can think of nowadays is already so large in scope and/or complex that you can't prove it _doesn't_ work either, because there's no complete specification on how it's supposed to work - if it existed, it would be the bug-free software itself, because all software is specification.

In the end all that matters is whether the system is useful, in an economical sense (value delivered > defects over time).

So I would argue software did _not_ get reliable, our bar for defects remained low, but the relative value delivered increased a lot because software has amazing leverage.

<comment><USER28> Moreover, when you get an existence proof of a bug, it's usually easy to change such a system to seem ok.

As Hoare also said, "There are two methods in software design. One is to make the program so simple, there are obviously no errors. The other is to make it so complicated, there are no obvious errors."

</comment></comment><comment><USER29> So I guess the answer is: because of the feedback loops that exist around the software systems.

<comment><USER30> Exactly. Software systems are reliable because they have economic value. We're incentivized to make them work, regardless of how much technical debt and duct tape lies under the hood.

</comment></comment><comment><USER31> > _How did software get so reliable without proof?_

Two words: survivorship bias!

The software field exploded in the past half a century, producing a huge volume of activity producing a huge amount of cruft. A lot of the unreliable stuff gets shaken out; so what we see is a biased sample consisting of the successes that remain. Software that is halfway successful gets to be maintained, and over many years or decades, the reliability improves.

</comment><comment><USER32> Human operators surely play a part sometimes, but there are systems which eliminate or minimize that and are still surprisingly reliable. I think people have learned to build resilience into their systems, which expect and anticipate failures. These systems still fail and when they do it's often in very complex and surprising ways, but those failures are rare.

<comment><USER33> Interesting. I wonder if there is a point beyond which multiplying these abstractions doesn't really do anything to boost either performance or reliability i.e. will someone come up with a way to wrap and package kubernetes clusters into yet another russian doll abstraction?

<comment><USER32> I actually wasn't thinking in terms of abstractions although those can help too. Simple things like always validating your inputs, adding sanity checks and safety limits to your code, building in isolation, can go a long way towards catching a lot of errors and/or limiting the blast radius of failures.

</comment></comment></comment><comment><USER34> Most of the software I have written for work has no near on no functional / unit tests. It is industrial process monitoring software that runs 247 on remote machines thousands of miles away. Simple fact is it has to work, no if's but's, even when there are faults in its environment.

This does not mean to say that the software has not been tested.

Testing is subjective to a softwares use. You could have 10000 tests and still have a series of bugs.

Testing for my work comes as two categories, "Tested by design" and "Environmental Testing". "Tested by design" involves developing your software by which the designing and writing the software inherits the tests as you go. When I go about designing a feature, I expand on a chosen solution of that feature and then methodically branch out on the uses of that feature, build a map of dependancies, scenarios, outcomes, consequences etc for that feature. These become the basis of how I write the code for that feature because I have inherantly put in mitigations for everything I have considered before hand. There is no point in testing something excessively if you can and/or have garanteed by code that it will perform exactly as designed. That may seam a contraversial thing to say.

With "Environmental Testing" we simulate the environment which the software is put into with real external factors. This is particular for the software I write. This is not always the best for another software project.

I've written my works software from scratch 3 years ago and it has had various incremental additions and changes. Yes there have been bugs. I will admit that entirely. However the key thing with work's software is that is has rarely crashed or rarely faulted while containing those bugs. Most faults that have been found have been configuration errors/issues.

I would be interested in how others approach testing strategies for the software they have written.

</comment><comment><USER35> Having worked in some places that aren't software companies it is pretty incredible how something a developer who is no longer in the company set in the last decade is still kicking ass with no monitoring or documentation.

It's truly remarkable! All those databases that software depend on and go without people even realizing they exist until someone literally decomissions a datacenter only then to figure out lots of apps require that particular machine to be running... they're day in and day out working with 0 maintenance for years... impressive.

Postgres, mysql and mongodb are examples of databases I've seen like that! As well as inhouse apps that depend on those databases... at most they have a cron job for backing up and keeping at most the last X backups.

</comment><comment><USER36> I don't think software is all that reliable. Almost every piece of major software that I use has one or more bugs and periodically locks up or crashes. We as users have been conditioned to accept this with the situation getting worse rather than better over the years.

The main reason software _seems_ more reliable than in the past is because in a SaaS environment the crash doesn't happen on your computer anymore. But the effect is the same unless extreme care was taken on the server side to ensure that no data was lost. In most cases we perform the equivalent of a reboot or retry: we reload the page.

</comment><comment><USER37> This article misses the elephant in the room: how to define "reliability". Most software perceived to be reliable (eg, MS Paint, bash) have numerous bugs, it's just that no one comes across them. Software that is perceived to be "reliable enough" (eg, MS Word, Chrome), have bugs that pop up regularly.

Here are some vague uptime reliability measures and what you need to get there:

\- 70% reliability: you can often just free-code it and pray.

\- 95% reliability: you better have a bunch of tests.

\- 99.5%: you need automated testing, coverage tools, documentation, team coordination tools, and and solid merge/deployment process.

\- 99.99%: all-of-the-above plus tests that aggressively attack and analyze production systems (eg, Netflix Chaos Monkey), coverage tests that do branch coverage and not just line coverage, simulating network failures, and/or test on a variety of hardware and user-configurations.

\- 100%: The only way to be absolutely certain, is to convert each line of code into a mathematical operator and solve for a formal proof of correctness.

The 100% reliability standard is not just theoretical. The U.S. government issues software standards for safety critical devices (military, aviation, healthcare), and some of them do indeed require mathematical proof of correctness (EAL6+ being a key standard). They generally do not require 100% bug-free code, but just that some particular features are 100% bug free (e.g., the OS/scheduler will never deadlock).

<comment><USER38> > and some of them do indeed require mathematical proof of correctness > > (EAL6+ being a key standard)

Nitpick: EAL6 is still semi-formal, EAL7 is formally verified design and tested. EAL7 is very rare, on the CC certified products page [1] there are only 2 EAL7 certified products: a hardware diode, and a virtual machine OS.

[1] [https://www.commoncriteriaportal.org/products/](https://www.commoncriteriaportal.org/products/)

<comment><USER37> > Nitpick: EAL6 is still semi-formal, EAL7 is formally verified design and > tested. EAL7 is very rare, on the CC certified products page [1] there are > only 2 EAL7 certified products: a hardware diode, and a virtual machine OS.

You are definitely correct. Also, disclosure... I worked on that EAL7 Virtual OS. When I left it was only EAL6+, likely leading to my bias towards it.

</comment></comment></comment><comment><USER39> 1\. Proof costs. Like, a _lot_. If you don't _need_ the reliability, why would you pay for it?

2\. How much reliability is needed? Not 100% (usually). If my OS crashes, I'm unhappy. If the OS on my company's production server crashes, that's a lot worse. But our production server is actually a redundant cluster, so if one machine crashes, people are unhappy, but nothing horrible happens. (In point 1, I talked about the cost of proven-to-be-perfect software. Needing to have a redundant cluster is part of the cost of _not_ having perfect software, which also must be considered. But because the hardware isn't 100% reliable either, we needed a redundant cluster anyway...)

3\. Formal methods are often playing catch-up. Now we have to worry about timing side-channel attacks through the cache. There may now be formal methods to prove that such things are not possible in a piece of software; I'm pretty sure there were not such formal methods five years ago. We keep finding new areas that can fail. (One advocate of formal methods replied to me some weeks ago that formal methods proved that the software would never do anything that it wasn't specified to do. I doubt that claim with respect to something like side-channel attacks. Even if it's true, though, I suspect that often the _specification_ didn't include "no side channel attacks" until certain recent events brought it to more popular attention.)

Proofs are therefore suffering from a double whammy: Not only are they painfully difficult and expensive, but they're incomplete. When something comes up that wasn't covered by the proof of correctness, you now need to fix it. _And then you have to re-run all the proofs all over again, because your fix may have invalidated them._

4\. All proofs have to start somewhere, usually with a formal specification. If the specification is wrong (looking at you, MCAS), all the formal proofs in the world won't save you. (Well... a _system-_ level formal proof might. But that's even harder and more expensive. And even that fails if the _system_ spec is flawed.)

TL;DR: Real proofs are too expensive for the benefit they provide, in almost all cases. The cost-benefit just isn't there. Hope lies in making them easier and more automated to use (better type systems, for example).

</comment><comment><USER40> Maybe it has something to do with most software not only being not right but not being wrong either (I'm paraphrasing Wolfgang Paul).

We do put a lot of effort into writing correct programs for some definition of correct. But a lot of our specifications don't include things that aren't obviously wrong like, "not leaking secrets," wrong.

I share the enthusiasm of SPJ who said, "it's amazing that it works at all let alone so well." It's easy to forget that that little white box you type a few words into is more impressive in scope and complexity than the tallest buildings humans have built. And yet it is so largely invisible!

I think the more important question is how much longer have we got left before regulators and insurers demand we assume more liability for things when they do go wrong.

<comment><USER41> I actually think that the FOSS movement and licensing is really progressive in this space. This thing comes with NO Warranty etc is really great because you own the risk of the systems you build. If only that got surfaced more to the users so they realized that a T&C page isn't really protection for anything.

Rather than force devs to use formal methods, I'd really like it if software got to the point where regulators and insurers demand that we treat personal information like radioactive waste and try and handle the least amount possible.

<comment><USER40> > Rather than force devs to use formal methods

I don't think professional liability would _require_ all developers to use formal methods any more than it would require all practicing software developers to become licensed engineers.

It may require companies to hire a licensed engineer to sign off on projects and it could require those engineers to be insured so they may want to use formal methods on a risky project to keep their rates down.

The end result, I think, is the same: pressure to do better by the standards of the state of the art and not skimp on privacy and security.

</comment></comment></comment><comment><USER42> If you compare K&R C and C++17, everything that has been added is some form or another of 'proofs'.

So I take issue with the 'without proof' part; even if they're not proofs that adhere to strict mathematical forms, they're still there.

</comment><comment><USER43> In 2020, software is reliable?

</comment><comment><USER44> most software today is a mess. only when you include the user in the loop with his version-3-new-final backups and willingness/need to retry in the event of error you get something that's workable.

we've effectively shifted partial blame on the users, the famous "operator error" class of bugs, made sure to help then save often and substituted reliability with resilience

but it doesn't mean software is reliable. the whole system as a whole and including users corrective actions is somewhat resilient enough for productive work

</comment><comment><USER45> I think the answer to the question posed may just be "it's like natural selection".

A lot of software is horrifically bad. But not all flaws are created equal. A software that runs an online shop, but crashes 50% of the time during checkout will probably not create a successful company and thus won't survive long.

However a software that has comparably many flaws and fails in all kinds of rare corner cases, but still gets the job done in most average cases, may just survive, even though it's equally bad.

</comment><comment><USER46> How did people get the impression software was so reliable?

</comment><comment><USER47> What strikes me in both the original article and the post is the failure to recognise that a strong form of selective pressure is being applied upon software, and that adaptive processes (of which evolution is but a single example) tend to optimise for the criterion that is being selected for even in absence of an overarching design ('proof'). I recommend reading _Darwin Among the Machines_ for comparison to hardware.

</comment><comment><USER48> By fixing everything that goes wrong noticeably and by having no idea that many features are currently actually not working as they are supposed to?

To actually create reliable software currently the best bet is to have automated tests for as many things as possible and exploratory manual testing around any feature that changes.

</comment><comment><USER49> By focusing on the critical path through the call tree. It's shocking how many fatal errors static analysis finds in my typical C/C++/C# code but the call graph that those errors are on simply never gets exercised. The mathematical proof would include all those unused paths.

</comment><comment><USER50> Probably money? If there is money to be made somebody is going to find a solution that mostly works

</comment><comment><USER51> When it comes to writing reliable software the best paper I have read is "Design By Contract". That one paper combined with proper usage of exceptions will go a long way in preventing bugs. Of course there is also a need for more rigor in requirements.

</comment><comment><USER52> Fascinating how perception has changed since then; I think most people today would have the opposite sentiment: "How did software get so _unreliable_?"

My guess is: software creation and distribution became exponentially more accessible around that time (1996) with the advent of the web. Not only were many less-qualified individuals creating software (which isn't intrinsically a bad thing!), many more people were _consuming_ software (making consumer software a much more lucrative market), and technology changes allowed companies to "move [much] fast[er] and break [more] things".

Businesses were always optimizing for profits, and the dot com boom simply changed the equation to where reliability was no longer profitable in the majority of the field.

</comment><comment><USER53> Richard Feynman said it best:

1\. Write down the problem

2\. Think real hard

3\. Write down the solution

[http://wiki.c2.com/?FeynmanAlgorithm](http://wiki.c2.com/?FeynmanAlgorithm)

</comment><comment><USER54> Short explainer video covering Hoare's original paper:

[https://youtu.be/eY8AyCZ5uUg](https://youtu.be/eY8AyCZ5uUg)

</comment><comment><USER55> > How did software get so reliable

Talk about begging the question!

<comment><USER2> How many HTTP request does nginx usually serve before crashing? How long can a Linux kernel stay up before panicking? Some complex software _is_ startlingly reliable.

</comment></comment><comment><USER56> Fixed a ton of bugs. And it's not that reliable, and super reliable software in airplanes is proved.

</comment><comment><USER57> By begging the question!

</comment><comment><USER58> > How did software get so reliable without proof?

Because most software is just moving data from one place to another, combined with some very simple business logic.

</comment><comment><USER59> It didn't.

</comment><comment><USER60> The proof is in the pudding.

</comment><comment><USER61> See Betteridge's law of headlines.

</comment><comment><USER62> The main reason I've found for programs being 'correct' is that the range of actual inputs for programs is severely limited.

Most programs see inputs that are similar enough to previous inputs that the latent bugs are never triggered, or at worst triggered one at a time.

Running programs far outside their expected parameters on the other hand has nearly always lead to disaster.

<comment><USER58> Would you say that a typical web-browser (a complicated piece of software) always sees the same kind of input?

<comment><USER62> Pretty much.

Throwing [0] to chrome and firefox has made made them hang for 5 minutes so far. Generating the HTML took under a second and 13MB, large, but not larger than the fatter webpages out there.

In terms of input browsers don't see but should be able to parse you can't get much simpler than this.

[0] In Guile2.x:

        (define print
          (lambda (x)
            (display x)
            (newline)))

        (define div-hell
          (lambda (n)
            (cond
              ((eq? n 0) (print "TEXT"))
              (else
                (print "<div>")
                (div-hell (- n 1))
                (print "</div>")))))

        (print "<html><header><title>DIV HELL</title></header><body>")
        (div-hell 1000000)
        (print "</body></html>")

</comment></comment></comment><comment><USER63> >The problem with the question "How did software get so reliable without proof?" is that it's asking the wrong question. It's not that software got so reliable without proof: it's that systems that include software got so reliable without proof.

No. This person isn't sounding smart enough. The real question isn't how systems that include software got reliable without proof but instead the reverse: how did software that includes _systems_ get so reliable without proof? That's how you should conclude an article with some hand wavy technical jargon.

</comment><comment><USER64> The same way bridges, aeroplanes and medicine happened. What makes software so special?

</comment><comment><USER65> Brilliant analysis.</comment>


Of Card-Counting, Startups, and the Real Story of the MIT Blackjack Team - <AUTHOR> http://www.xconomy.com/2008/03/27/of-card-counting-startups-and-the-real-story-of-the-mit-blackjack-team/ <comment><USER2> Sometimes I feel crazy. There was an unclosed paren a little over halfway through the first page and it bothered me for the rest of the page. At that point, I suppose, I must have just given up and emitted a syntax error. I think it might be time for me to get back to Lisp.

Interesting read, anyways. Maybe I'll get the book and/or check out the movie.

</comment><comment><USER3> >One very small stakes investor in the early days, says Chang, was open source software pioneer Richard Stallman, who had worked at MIT's Artificial Intelligence Lab before resigning in 1984 to develop a free Unix-like operating system known as GNU.

Sweet.

<comment><USER4> Good job, rms.</comment></comment>


Why we are switching from Ruby/Sinatra to Node.js - <AUTHOR> http://groups.google.com/group/urug/browse_thread/thread/519f1f0d570d88e0?pli=1 <comment><USER2> Oh my. I like node, but that's a bunch of weird arguments. Most of them contain a kernel of truth, but jumping from that to node comes as some kind of non sequitur.

1) Version hell: No up-to-date packages on Linux distributions? As compared to the packages they have for a fictional stable node version?

2) Rails 3: I thought you were talking about sinatra? Where did Rails come into this?

3) Again with the versions. It would be nice to give a good reason why for him the push to 1.9 would be so important.

4) Speed: Yes, the V8 engine is quite fast. This won't matter for most of your work, though. Most of the heavy lifting for Node's event system is done by libev (written in C), the same that's underneath Eventmachine. Compared to I/O, it will hardly matter. And if it will, then moving to a compiled or JVM language will probably still be better.

5) Mobile: What's wrong with JRuby? It's closer to Dalvik than anything else. And again, what's the connection to node? You're not much better of there, never mind that it uses the same engine as in the (Froyo) browser.

6) Familiar frameworks: Not that familiar, as event-driven code has to be a bit different. But yeah, you've got a sinatra clone...

7) Javascript: Finally a good point. A single implementation language is usally quite nice, and not everyone wants to go the Seaside/Parenscript route.

Don't get me wrong, it might as well be a good decision, but these arguments are a bit immature, especially all the blabbing about Ruby 1.9, which isn't exactly the complete and utter miraculous revolutionary step.

<comment><USER3> Since when was EventMachine written in terms of libev? EventMachine, last time I looked (which is recently --- we write a _lot_ of EM code here), has its own idiosyncratic event library.

<comment><USER2> Don't know with what I mixed that up (POE, probably. I know, libev is only an option there). Not that libev is a rather huge software, it's basically a wrapper around whatever the host OS provides (select, epoll, kqueue). From looking at it, eventmachines's C extension does the same. So my main point stands: A big part of the performance characteristics of node come from a lower-level C functionality. I guess that having an infrastructure that's mostly asynchronous comes second. Pure V8 speed won't matter that much for most tasks. If someone has counter-examples, I'd be pleased to hear them. As often with concurrency, better memory efficiency would probably win out.

</comment></comment></comment><comment><USER4> A lot of the same comparisons could be made between Ruby/Rails and Java/Spring/Faces/Struts/Hibernate/etc when the Ruby/Rails combo first came out. That is to say, when a technology is in its early stages, fragmentation hasn't had a chance to set in. I think Node.js stands a pretty good choice of avoiding fragmentation for the near future, but that is only because it is a pretty raw implementation. Node.js is apples where Ruby on Rails is oranges.

Another thing the author would be wise to note that Node.js may not be ready for prime time just yet. The author has been attributed as saying such as recently as May of this year:

<http://www.yuiblog.com/blog/2010/05/20/video-dahl/>

The API needs to stabilize a bit before I'd roll a large amount of code on top of it. If there's anything I've learned from Ruby on Rails, it's that you have to be prepared to tear in to a plug-in or module if the maintainer decides they're not going to maintain it with future versions of the technology that it plugs in to.

Overall, this rant jumps all over the place. We go from Sinatra, to Rails, to mobile. How is the switch from Sinatra to Node.js relevant to Ruby in a native mobile environment and also Rails? It's all just a little bit confusing.

I'm responsible for the app hosting environments at our company, so I understand the author's frustration with Ruby versions and the impending release of Rails 3. About 6 months ago, we started on a brand new web app and decided that we were going to look toward the future. We built it on top of Rails 3 (first beta) and Ruby 1.8.7. I literally had to compile various builds of Ruby 1.8.7 until I found one that would work with the first Rails 3 beta. We had to hold that configuration through Rails beta1 because we couldn't find a config that worked with Ruby, Rails, and all the plug-ins we are using. It has been _painful_. But now that Rails is closing in on a 3.0 release, and Ruby is closing in on 1.9.2, things seem to be coming together. Plug-in authors see a light at the end of the tunnel and are running toward it.

I also strongly disagree with the authors sentiment with regard to RVM. If there is a strong point to Ruby on Rails development, it is that every layer of the stack has received a lot of attention. RVM is an elegant solution, and it works well with bundler, which is integral to the Rails 3 release. Having pushed forward through several releases on top of Rails 3, RVM, and Capistrano, I can say with confidence that Rails app deployment has arrived. Mixing/managing Gem versions for production and staging environments in one OS environment is ready to rock. The one caveat being that there is no good solution for running more than one version of Ruby. The Passenger team is working on a solution to that, but I'm not sure we'll ever implement it. Running mixed Gems is one thing, running mixed interpreters in another. My preference is to keep some level of consistency at that layer.

I've not addressed all the author's points, because he's right about some things. Specifically speed and the "ooooooh shiny" mentality of most Rails developers. My lead developer is the best programmer I've ever worked with. I wouldn't trade him for anyone, but I do find it a constant battle to force a strict vetting process of new technologies. We went through no less than three authorization plug-ins during the early stages of app development on our most recent project, and the last revision consumed a not insignificant amount of time to strip from the project. I still feel like the trade-offs are worth it. At least for our project.

</comment><comment><USER5> Perhaps I'm missing something. Who is this that is announcing they're switching? Is there a specific reason that HN as a whole cares?

<comment><AUTHOR> I have no idea on who it is and I don't think it matters, but rather it was some interesting points and thought it was fitting to see where others on HN thought about it.

<comment><USER5> OK, I was just spending far too much time looking to figure out who it was, and just had to ask.

</comment></comment></comment><comment><USER6> I never was big on Ruby since writing JSON services with servlets and doing my UI in pure HTML / CSS / JavaScript gave me the same agile velocity. But I have to say writing JSON services with Node has become a more and more attractive proposition. It is so light weight and fast that I have been looking for the right project to get my feet wet on it.</comment>


Ask HN: What questions couldn't you answer when browing my new website? - <AUTHOR> http://www.shirlaws.com.au

<comment><USER2> I think you're coming at this from the wrong approach (though I could be wrong). I don't go to a website to 'browse', or to get questions answered, and particularly, 'what questions couldn't get answered'.

I think what you are looking for is what does the website do for the business. Does the website attract clients, explain what the company does, and why shirlaws is the best choice?

So, to start 'love business'. What is that? You love business? we should love business? what does loving a business get a person? How is it beneficial? Same thing with the taglines on your slider. They are like a bunch of taglines, but they are somewhat out of context, and what's with all the children? If you are a business site, why would you fill your site with childish playful images? Do you specialize in business that cater to children? if so, then it might make sense, but I'm not getting that context form what you have. 'Increase turnover'? Shouldn't that be 'decrease turnover'? or I guess it depends on what 'turnover' is referring to. You want to limit staff turnover, not increase it. 'Impove their bottom line'. Who are they? I want to improve my bottom line. Of course, if you spend a bit more time on the site, you see the 'coaching' stuff, but that isn't what first strikes the visitor, and you'll likely loose a lot of people before they even see that stuff.

Focus on the coaching first. Shirlaws is a coaching company which ..., we help your business...,

<comment><AUTHOR> Really useful observations, and I'm most grateful.

The colours and kids are part of our branding ourselves away from the stereotypical, 'hard, commercial' business consultant, and while that works really well for people who are introduced to us it's obviously not as clear to people who might stumble across us online.

Turnover must be too jargony. I might change to revenue.

And I think you nailed it with 'explain what the company does'. Easy to forget sometimes that the rest of the world doesn't care about your baby! Many thanks.

<comment><USER2> I wouldn't say people don't care about your baby, but they care more about what your baby can do for them. That's the way I try to look at it.

</comment></comment></comment><comment><AUTHOR> Inspired by this post from earlier in the week about FAQs - <http://news.ycombinator.com/item?id=1146552>

1\. Visit our site 2\. Provide us with 2-4 questions you had and could not answer while browsing our site

This is my website in the sense that I produced a lot of the planning and content. I figure any questions the HN community has about business, Shirlaws, or business coaching would be relevant, so if they're not answered I need to improve the site.</comment>


Ask HN: How does a company insure against data breaches? - <AUTHOR>

<comment><AUTHOR> Do large SaaS firms tend to carry the same kind of cyber-liability coverage?</comment>


U.S. coronavirus testing threatened by shortage of critical lab materials - <AUTHOR> https://www.politico.com/news/2020/03/10/coronavirus-testing-lab-materials-shortage-125212 <comment><USER2> Whereas other countries aren't having the same problem, so I presume this is another self-own due to the gov desire to create their own test in the US, rather than the _clearly available in huge numbers_ tests available in other countries.</comment>


American English Dialects - <AUTHOR> https://aschmann.net/AmEng/ <comment><USER2> I love these old looking very personal type of sites. It feels like in the age of SEO optimization these sites often get lost in the search engine results. I have always found these sites to have a surprisingly high amount of quality content that is hard to find anywhere else.</comment>


Show HN: WhoQuest – find anyone for anything - <AUTHOR> http://whoquest.com

<comment><AUTHOR> Hey Gang,

We're building a product that helps turn anyone's search for people into a giant search party. We do this by having people post questions that start with "who" and letting others come and endorse the best people.

As endorsements are collected, we build a list of the best people to connect with.

So far...people have used WhoQuest to find employees, freelancers, collaborators, mentors, and experts. We actually used it to find actors for an explainer video, and freelance bloggers.

Feel free ask us anything or play around with the site.</comment>


Cubby Is Like Dropbox... If Dropbox Also Had Free, Unlimited Syncing - <AUTHOR> http://lifehacker.com/5907654/cubby-is-like-dropbox-if-dropbox-also-had-free-unlimited-syncing-and-weve-got-invites?utm_campaign=socialflow_lifehacker_facebook&utm_source=lifehacker_facebook&utm_medium=socialflow <comment><USER2> And only Windows and MacOSX support, unlike dropbox's: Windows, MacOSX, Linux, iOS, Android and Blackberry.

The reason Dropbox will continue to prevail over these offerings is its ubiquity. iCloud? Mac only? Ha! Useless to me. This? No Linux or Android support? Still useless to me. Not worth another second thinking about.

Not to deride Cubby too hard, I'm sure it's another neat thing, but I get tired of people thinking any of these things have a shot at dethroning Dropbox. They put a lot of work into being as cross platform as they are (I presume (since no one else has matched it)) and they deserve their top spot.

<comment><USER3> Anything that doesn't require you to submit to centralized storage under third party control (euphemistically known as "the cloud") has a shot at dethroning Dropbox.

Especially outside the US, where people, governments and businesses are becoming increasingly weary of having their data stored where US government agencies can get access with little to no legal process.

When companies start using "not stored in the US" as a selling point for their services you have a serious problem.

<comment><USER2> fair enough to some extent. However since I can't run the software at home, at work, or on my phone, it's still not even on my radar so my point retains some of its validity :)

<comment><USER4> If you aren't adverse to rolling your own solution, do what I do - a really cheap UK hosted VPS + rsync.

I can get at it from my phone or desktop and it costs next to nothing.

</comment></comment></comment></comment><comment><USER5> Things have come full circle. This sounds a lot like Foldershare.com -- they offered virtually unlimited syncing of folders between machines, but with no cloud backup. They were acquired by MS in 2005. I used Foldershare before I signed up for Dropbox, and in parallel with dropbox, for a while. :)

<comment><USER6> I was thinking the same thing. Then, if you recall, when they were acquired the "5GB of cloud storage" feature was exactly what Microsoft added and called it "Live Sync." Then they merged it with Mesh, killed Mesh, and called the merge "Live Sync." Then they killed all of it and started pushing SkyDrive.

And now SkyDrive is news. And this solution, which is the same as the old solution Microsoft had, is also news. Somehow.

</comment></comment><comment><USER7> I wonder how this differs from AeroFS (YC S10).

...I also wonder what the heck Yuri and co. have been up to for the past few months. Things have been awful quiet over there.

<comment><USER8> Yeah, you are of course (and unfortunately) right - we've been eerily quiet as of late.

The short of it is: We've been quietly working on a major overhaul of many internal components (improvements to the networking stack, syncing stack, and the way sharing is done). Unfortunately some of the changes are so fundamental that we're not able to do our usual continuous deployment and push the changes incrementally. Instead, we'll be having a major release sometime in the (near? :) future which should provide dramatic improvements. We've been using the new client internally for a few weeks now and so far we love it. I hope you do too (I know, I know, once it's out!)

I usually try and engage actively with the community, but for the past few months I've also been very busy recruiting and building out our team (<http://www.aerofs.com/careers.pdf> \-- we are still hiring!), so my own communication with the external world has been limited. We're working on addressing this as well :)

<comment><USER9> Loved the idea of aeroFS but it was too slow & buggy to use compare to a solution like Dropbox in my case. But I'll make sure to try the new version when it comes out!

</comment></comment></comment><comment><USER10> Serious question: can it do unlimited syncing between your computers if they are rarely on at the same time? If I sync between my laptop, open sometimes during the day, and my desktop, turned on only at night?

That would really be a killer app, if a master list of files was stored on Cubby's servers, and it would transfer only things that had changed to the servers, waiting to be sent to the other computer whenever it was turned on...

<comment><USER11> Isn't this basically DropBox (2GB + referral free spacce), and the 5GB you get for free on this new Cubby service? With both you pay more for the space you use as it syncs across devices as they are on...

I guess you're asking for this functionality as part of the free service, moving things through server-side as they sync?

<comment><USER10> Exactly, using the server-side not as a permanent mirror, but just using that 5GB or whatever as a "holding space" only for files that are currently out-of- sync. Once they sync, delete from server...

</comment></comment></comment><comment><USER12> dropbox, you've been really good to me, but the competition has really got you in the crosshairs.... (and i'm a linux user, which doesn't even work with this [yet?...or google drive], but the competition really has become pretty serious lately).

<comment><USER13> The more competitors Dropbox gets, the more fragmented the whole thing becomes, which in that sense helps Dropbox. I look at Cubby and think "not another cloud storage", there's no point for me even if it's "better" because I'd have to convince everyone I work with to use it. I'm already sharing various folders with other people on Dropbox, the switching cost is large and only GDrive looks like a true contender as something that many people will end up using or at least will bother to install if I need to share something with them.

<comment><USER14> I completely agree. The more competitors, the more fragmentation, the better for Dropbox.

Something primitive in me starts to kick in when this occurs. I start to question the trustworthiness, validity, and longevity of "other services", which in turn only bolsters who I know best, or even just first. Everything else becomes the proverbial Brand X.

</comment></comment></comment><comment><USER15> Slightly off topic: Why does Sugarsync get such little love? It lets me sync/backup arbitrary folders rather than dumping everything into one, so I don't have to remember to put stuff into the One True Folder (which Dropbox, GDrive, Skydrive etc all do), or run things live from there. But I hardly ever hear about it on hacker news. Just wondering if there are known issues with their approach.

Edit: I see now Cubby does the same thing. Like.

<comment><USER16> I tried it and liked it, but the lack of an automatically public folder with URLs I can type from memory was a deal-breaker.

</comment></comment><comment><USER17> I'm guessing they probably just p2p the files between the computers (with setup help from cubby's servers).. pretty neat way to offer a free feature

</comment><comment><USER18> Too bad it does not have a Linux client.

</comment><comment><USER19> Excellent. Been looking for a Dropbox-easy way to move large amounts directly between machines (here's hoping it doesn't require passing all of it thru a central server) without having to park it in a size-limited cloud. There was a nifty USB gidget that was close, but required $99 hardware and did route everything (albeit encrypted) thru a host.

New iMac coming soon! great time to test Cubby.

</comment><comment><USER20> I really like Cubby and I think it has a lot of potential. I've been using it for about 3 weeks now. The only problems I have seen is that it notifies you every time something is updated. This includes temp files. This gets rather annoying. I also wish I could start paying for a bigger plan now :P

<comment><USER21> Do you know how the non-cloud aka computer-to-computer syncing done? Particularly, is the data cached in some intermediate server? I love the idea and would use it if the answer to the above question is No!

<comment><USER20> Cubby's p2p information can be found in their FAQ

</comment></comment></comment><comment><USER22> I tried SugarSync and Syncplicity before settling on Dropbox. I don't trust either of them with my files, but I've been a happily paying customer of Dropbox's for 4 years now.

I care way more about not losing my work than I do about $10/month. Cubby may have an uphill battle ahead of it.

</comment><comment><USER23> "Free, unlimited" gets my spidey-sense tingling.

<comment><USER19> Based on little I'm thinking "it's Skype, but for data" where the service is driven by free point-to-point file transfer, but related buffering/storage or other "hey that's great but I'd pay for..." services tacked on (like Skype's X-to-phone paid services - dirt cheap, but cumulative).

</comment></comment><comment><USER24> i don't use windows live mesh, but my roommate does and from what he's told me it sounds exactly like this. does this do anything other than windows love mesh does?

<comment><USER25> Windows Mesh had a bad habit of locking files unnecessarily when I was working with them, which got in my way and I had to get rid of it. Mesh sounded better on paper.

</comment></comment><comment><USER26> Yet another Amazon based file thingy. I'll pass.

</comment><comment><USER27> It's X, like Y, but with Z!</comment>


Two Russian Spies Charged in Massive Yahoo Hack - <AUTHOR> https://www.wsj.com/articles/four-men-charged-in-connection-with-yahoo-breach-1489592862 <comment><USER2> To try and be a good citizen alongside the requisite paywall gripe, here is a link to a comparable article without paywall.

[http://www.nbcnews.com/tech/tech-news/russian-spies- charged-...](http://www.nbcnews.com/tech/tech-news/russian-spies-charged- massive-yahoo-email-hack-n733716)

</comment><comment><USER3> 3 hours earlier, also on the front page right now: [https://news.ycombinator.com/item?id=13876208](https://news.ycombinator.com/item?id=13876208)</comment>


Picwing is Offering 2 Months Free in Honor of Mother's Day - <AUTHOR> http://ycombinator.posterous.com/picwing-is-offering-2-months-free-in-honor-of <comment><USER2> Great, now I have no excuse not to take those pictures of me and my fiancé that my mom has been asking me for...

</comment><comment><USER3> Is there anything stopping you from claiming random people you know to be your 'mom'?

<comment><USER4> No, but they don't care. They're just using Mother's Day as an excuse to do some drug-dealer marketing--giving a little bit away for free to try to make you a consistent customer.

<comment><USER5> I'm pretty sure drug dealers were not the first people to implement (or even popularize) this sort of marketing. It might have been school bake sales.

</comment></comment></comment><comment><USER6> And just as a friendly reminder to HN, don't forget to call your mom today!

</comment><comment><USER7> Looking forward to sending photos to my grandmother with this app.

<comment><USER8> My grandmother just turned 99. She's sharp as a whip, but doesn't use a computer, so she misses out on all of the family photos that the rest of us see on facebook or by email. Picwing solves this problem. My grandma loves it.</comment></comment>


JS Wars - <AUTHOR> http://29a.ch/jswars/

<comment><AUTHOR> Nice write-up from Ajaxian here [http://ajaxian.com/archives/fun-friday- mullets-and-space-bat...](http://ajaxian.com/archives/fun-friday-mullets-and- space-battles)

</comment><comment><USER2> Holding down space didn't fire continuously, but instead scrolled me down the page.

Back button didn't work; had to click on a bookmark to leave.

Then it prompted me for a score, preventing me from leaving until I either hit escape or typed something in.

</comment><comment><USER3> Sorry, but if a 7 year old kid wrote this in Flash I might be impressed. JavaScript has light-years to go before it's a viable platform for anything involving animation and graphics, for even the most cursory uses.

<comment><USER4>
      >light-years to go before it's a viable platform
      >for anything involving animation and graphics

once all browsers support the canvas element (as does firefox3) its just a matter of time until some standard 2D animation libraries popup that will enable game development.

flash is ecmascript + proprietary set of libraries and a great IDE. but javascript has the advantage of coming out-of-the-box with the browser.

(and in the distant future there is Canvas 3D, which really is opengl exposed to JS :) <https://wiki.mozilla.org/Canvas:3D> )

<comment><USER3> > javascript has the advantage of coming out-of-the-box with the browser

Well sure, but you get a different js with every browser, and always will!

<comment><USER4> it's always a different superset. not too bad, and you always have that with different interpreters / compilers.

</comment></comment></comment></comment><comment><USER5> With Chrome, it only started when I used enter. Nice demo of what one can do with JavaScript and modern browsers. As other people mentioned, flash still wins, but I view this as very impressive.

The code needs quite a bit of polish, but as the author mentioned this was a quick hack.

</comment><comment><USER6> Great demo, It even loads on my Android, I just can't start it without a keyboard. Wonder how well it would run.

</comment><comment><USER7> Hey, it's using my favicon!</comment>


Bonsai-c: C to asm.js compilation for humans - <AUTHOR> https://github.com/gasman/bonsai-c

<comment><USER2> I like this a lot. It's similar to lljs [1] in allowing small amounts of asm.js to be generated, using a familiar syntax (C). That's an important use case and indeed Emscripten doesn't really support it.

Two comments on this bit:

> Wait, what's wrong with Emscripten? [..] It's perfect if you've got a great > big POSIX C + SDL codebase that you want to run in its own self-contained > environment in a browser, but it's not very helpful for writing idiomatic > Javascript code that just needs to drop into optimised asm.js occasionally > for some heavy lifting.

First, I think this correctly describes some important use cases. But more generally, I think the main use cases I see in this space are

1\. Complete C or C++ programs, like a 3D game engine. Emscripten mainly focuses on this.

2\. A C or C++ library that people want to use from JS, like Box2D or Bullet. Emscripten focuses on this quite a bit as well. You can disable filesystem support and other unnecessary features for such pure computational code, and then for a library the size of Box2D or Bullet, Emscripten's runtime isn't a significant code size issue. And it provides tools to make C++ objects look like JS objects, so using such libraries is convenient (see ammo.js and box2d.js for examples).

3\. Small amounts of C that are to be "embedded" in JS. lljs and Bonsai-c focus on this.

A second comment: The third use case here is easy to get wrong. There is often a cost to calling from JS to asm.js and back. Writing a little asm.js function that adds two numbers and calling that in a loop will generally not be efficient, both because such functions are often optimized to asm.js-like speed anyhow, and because of the JS<->asm.js overhead. To make it worth it, the asm.js needs to do a more serious amount of work. Just mentioning this because it seems like a common pitfall.

[1] [http://lljs.org/](http://lljs.org/)

</comment><comment><USER3> As someone who has worked extensively with emscripten, and asm.js, something like this is great and needed.

Very promising, however it could easily become a crappy version of emscripten by adding e.g. C++ support or full C standard library support.

</comment><comment><USER4> > It's perfect if you've got a great big POSIX C + SDL codebase that you want > to run in its own self-contained environment in a browser, but it's not very > helpful for writing idiomatic Javascript code that just needs to drop into > optimised asm.js occasionally for some heavy lifting.

That's not really true -- it's pretty easy to call into an Emscripten module from javascript. You have to do some data marshalling, but that's true of any dynamic language -> c binding.

</comment><comment><USER5> Really great, like it. I'd also love to see the examples get more complex as the engine gets more capable. I mean the engine is pretty cool already: [https://github.com/gasman/bonsai-c/blob/master/examples/add....](https://github.com/gasman/bonsai-c/blob/master/examples/add.c) \- but it doesn't give any impression about what it currently is capable of. (e.g. in the README it tells about the lack of string support, et al.)

Will follow the progress of this project!</comment>


Economic mystery: Why is the American midwest more equal than rest of the US? - <AUTHOR> http://qz.com/594766/help-explain-an-economic-mystery-why-is-the-american-midwest-more-equal-than-the-rest-of-the-country/ <comment><USER2> I find it odd to not talk about the effects of minimum wage compared to cost of living in the area. I am from Indiana. It is common for people to take paycuts when they move to the area - the basis being that in most of the places, the cost of living is quite a bit lower (metro areas, especially chicago, aside). Many places have headquarters in mid-sized hub towns of 40-60k people. Sometimes people are quite happy because it lets them live pretty comfortably at the top without costing as much money. Moving to a coast for a payraise and then moving back can grant an overall lifestyle and payraise.

Yet minimum wage is the same in the midwest as it is other places, sometimes lower. Most of the available jobs are in the minimum - $13/hr zone. Had it not been for federal regulation, I speculate it would have stayed around the $5/hour zone. When minimum wage rises in Indiana, only those legally affected tend to get a raise. We get told that it theoretically isn't supposed to work that way. It really has lessened the gap between workers and management because they don't tend to get any raises, unless they are lucky enough to get a cost of living or performance raise each year.

</comment><comment><USER3> As a non-American I am less than qualified to provide an answer, but one possible hypothesis is Race and ethnicity. The midwest has according to Wikipedia with 79% the highest Non-Hispanic White ratio of any region.[1] As Blacks have the highest rate of poverty 27%, followed by Hispanics 25% compared to 10% for non-Hispanic Whites. [2] Income equality might be explained by having less poor people.

A follow up hypothesis would be that racial homogeneity might lead to less ghettoisation resulting in less competition for the lowest paying jobs. One might feel less compelled to pay only the lowest possible wage if one can relate to the other person, by race, neighbourhood, etc.

Now, as to why Blacks and Hispanics have higher poverty rates; one explanation may be that the American social system relies very heavily on both parents present (and working) for a child to grow up in an advantageous situation. This is something I have observed to a much lesser extend in more socialist societies in Europa. And famously in all but 11 states, most black children do not live with both parents. In every state, 7 in 10 white children do. [3]

[1] [https://en.wikipedia.org/wiki/Race_and_ethnicity_in_the_Unit...](https://en.wikipedia.org/wiki/Race_and_ethnicity_in_the_United_States)

[2] [http://www.csgmidwest.org/policyresearch/1012incometrends.as...](http://www.csgmidwest.org/policyresearch/1012incometrends.aspx)

[3] [http://www.washingtontimes.com/news/2012/dec/25/fathers- disa...](http://www.washingtontimes.com/news/2012/dec/25/fathers-disappear- from-households-across-america/?page=all)

<comment><USER4> In the case of Black poverty in the US there are probably better places to look first than the issue of single parent households.

The main reason for the high poverty rates among the black population is pretty well understood. Firstly, the legacy of slavery and legally mandated segregation that amounts to 300 years of outright state sanctioned oppression. Secondly, historical and ongoing discrimination in employment and educational opportunities, discrimination over housing, discrimination over the availability of credit with good terms, and institutional discrimination in the criminal justice system and beyond.

After that you might then say something about how single parent households are typically less stable than two parent households, and the rate of single parent households is higher than the norm among black households. By this point though you might need to re-think the direction of causation.

The kind of analysis you put forward can easily start looking like its saying that poverty among black people is a moral failing of black people, rather than a moral failing of society. The latter is where most, but of course not all (black people are individuals with moral agency as well of course!), of the blame lies.

Example: The crack cocaine epidemic hit black communities quite hard, and although there are individual moral failing that lead to addiction and further societal breakdown (single parent households, highschool dropout rates etc...), the vulnerability of black populations due to historic systematic oppression played a large role in making those individual moral failings much more likely.

<comment><USER5> > In the case of Black poverty in the US there are probably better places to > look first than the issue of single parent households.

With all due respect, you have a lot to say on an empirical claim (does race matter much more than parental status with respect to poverty?) without any data to back it up.

One could argue that broken families today is part of the legacy of slavery from 150 years ago, or disagree with the sources already cited, but I don't see you making those arguments. Or citing factual sources otherwise.

> The kind of analysis you put forward can easily start looking like its > saying that poverty among black people is a moral failing of black people, > rather than a moral failing of society.

Yes, prejudice is a danger. Do we ignore the analysis because of the risk of bigotry? Or is there a way to phrase the issue that lets us presume good faith, have an honest discussion, and perhaps correct subtle bigotry if it becomes clear?

<comment><USER6> Casting doubt here is pointless and detracts from the discussion. If the bar for discussion on hacker news is the same as for a peer reviewed paper no one will ever be able to say anything of use here.

<comment><USER5> > If the bar for discussion on hacker news is the same as for a peer reviewed > paper no one will ever be able to say anything of use here.

Agreed, but when someone posts some sources, replying with speculation isn't very useful, in my opinion.

<comment><USER4> In my opinion pedantry isn't helpful for stimulating conversation. You admitted ignorance of the causes of US poverty and of US history ('As a non- American I am less than qualified to provide an answer'), suggested a very simple single parent household theory with evidence of a correlation with poverty. I merely placed your theory and evidence within a historical and ongoing context of oppression (slavery and state sponsored oppression didn't end 150 year ago).

Pretty sure that Jim Crow and Slavery aren't speculation, but are common historical facts that don't require citation, much like saying World War 2 or the Annexation of Crimea happened doesn't require citation.

The point wasn't that single parent households aren't a cause of poverty (it certainly doesn't help), but that it is far too simplistic, that it is probably more symptomatic than causal, and with a US political lens can be seen as a case of dog whistle politics (not accusing you personally of engaging in such politics, which I should have made more clear).

<comment><USER5> > You admitted ignorance of the causes of US poverty and of US history

You're confusing me with another commenter.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> The all consuming quest to be the richest guy on the block is less important than on the coasts.

Religion plays a part? I've been to a few Midwestern states, namely Missouri, and Ohio. There's a morality they have that's missing here.

When I was there, I never felt like I was being lied to, or taken advantage of. Here, on the west coast, I'm leary of most people daily--regardless of socio-economic class. I'm not claiming the Midwest is some utopia, but it's less about the almighty Buck.

I've met a few women in my days. The only two I ever considered marrying just happened to be from the Midwest. I would have done anything for Gena at one point in time; she shot me down pretty quick. I still think about her.

</comment><comment><USER8> Less diversity, less natural wealth (agriculturally speaking), less industry, and it's land locked, meaning less ease of access to global markets via oceanic transport.

Both the east and west cost have provided great agricultural wealth due to climate favoriability and nutrient rich soils, are home to many traditionally poorer immigrant cultures and have a greater means for increasing their by using the ocean for trade and transport.

</comment><comment><USER9> Is it possible there are no rich people in midwest? How many billionaires live there?

<comment><USER10> Like I mentioned below, Johnson Couty, Kansas is one of the richest im the country:

[https://en.m.wikipedia.org/wiki/Johnson_County,_Kansas](https://en.m.wikipedia.org/wiki/Johnson_County,_Kansas)

<comment><USER11> 19th richest is not particularly rich, especially when the median household income is only $73,733. Power law distributions are really critical here.

EDIT: In fact I'd argue that this supports point that the Midwest is very equal - one of the wealthiest counties is really not that rich.

</comment></comment></comment><comment><USER12> Having grown up in the Rust Belt, I think the answer is that there's a talent drain. Smart, ambitious kids with prospects tend to leave -- it's not something that just affects CEO's and the 1%, it's something that affects the lower-upper and upper-middle classes as well.

</comment><comment><USER13> So it's more equal because they are all poorer together. It's really not that hard. Hard to be unequal if you're pretty much without wealthy people.

<comment><USER14> > Hard to be unequal if you're pretty much without wealthy people.

Clearly you haven't visited places like India, where in many cases the low economic status and illiteracy of the poorest are used to make the wealthy even wealthier.</comment></comment>


The Ethereum-blockchain size has exceeded 1TB, and yes, it's an issue - <AUTHOR> https://hackernoon.com/the-ethereum-blockchain-size-has-exceeded-1tb-and-yes-its-an-issue-2b650b5f4f62 <comment><USER2> Again this?

No the blockchain size hasn't reached 1TB yet and doesn't seem that close at ~51GB at the moment. [http://didtheethereumblockchainreach1tbyet.5chdn.co/](http://didtheethereumblockchainreach1tbyet.5chdn.co/)

I'm happy to discuss in detail if there's interest, but essentially the misconception is that all previous states need to be kept. Ethereum uses the blockchain as a state machine where each block is a state transition and the current view of state (world state) is kept as a piece of data connected with an account.

<comment><USER3> All previous states do need to be kept if you aim to audit the chain, which a lot of use cases will hope to do.

Just the chain itself already being at 51gb is also a problem since it's so new and has relatively non-existent volume.

Ethereum is pulling 24,000 transactions per hour on average.

Compare that to say Visa which is doing 6,000,000 per hour.

<comment><USER4> If Etherum generates 51GB every three years at 24,000 TPH then Visa isn't going to produce significantly less than 13TB every 3 years at 6 million TPH. Lots of transactions require lots of storage. Visa doesn't pull any magic tricks, it just stores more data. If storing more data isn't viable for blockchains then they will have a hard time against centralized databases.

</comment></comment></comment><comment><USER5> It's hard to take seriously any article that defends LN...

</comment><comment><USER6> Thank you, for finally putting this out. I was very confused as to why am I the only one having these strong feelings against how the tech works.

I think the guys over at bigchaindb present quite an interesting solution to the problem Blockchain is trying to solve, without giving up scalability and speed.

[https://youtu.be/1NHHmHVCWy0](https://youtu.be/1NHHmHVCWy0)

</comment><comment><USER7> This is why I laughed at Bitcoin Cash's proposed "We'll make our blocks as big as demand is", because long term that doesn't scale if every dedicated host needs the full ledger.</comment>


How Google's Self-Driving Car Works - <AUTHOR> http://spectrum.ieee.org/automaton/robotics/artificial-intelligence/how-google-self-driving-car-works

<comment><USER2> They talk about tapping your smartphone to get an unmanned car to show up, but... Isn't that what a taxi is? Other than saving the cost of a driver, how does this really improve things?

<comment><USER3> Removing the cost of the driver will have an tremendous effect. It will bring down the cost of a taxi ride near to the cost of driving with your own car (plus the way the car had to drive to get to you). I have big hopes, that this technology will close the 'last mile' problem of public transportation.

<comment><USER4> Absolutely ... imagine ZipCar, but you don't have to go to where the car is -- it can come to you!

<comment><USER5> And idling zipcars could park themselves in optimal locations around town, too!

</comment></comment></comment></comment><comment><USER6> In the UK there was a nice slot about it in Channel 4's Brave New World last night</comment>


The Los Angeles Hacker News Meetup is this Saturday - <AUTHOR> http://groups.google.com/group/los-angeles-hners-hacker-news This is our first meetup! Come and join in on the initial discussion for what we hope to be a monthly fixture. <comment><USER2> Family responsibilities will keep me from making a weekend meetup, but anyone interested in hn would likely enjoy <http://promenade.thursdaylunch.com/> in Santa Monica. That happens every week, and I'm usually there.

</comment><comment><AUTHOR> If you missed it in the group, the location's changed! It's now at CoLoft: [http://groups.google.com/group/los-angeles-hners-hacker- news...](http://groups.google.com/group/los-angeles-hners-hacker- news/browse_thread/thread/534a618b44feb782)

</comment><comment><USER3> FWIW I'd highly recommend considering doing it at the Coloft space in Santa Monica.

<comment><USER4> Wil, thanks for recommending the Coloft. We'd be happy to provide the space! <http://coloft.com>

<comment><AUTHOR> Hmmm, I'm not so sure changing the meetup location on such short notice is the best idea, I'd hate to have people showing up to the wrong spot.

That'd be great for the next one though!

<comment><USER4> Wasn't sure if you had picked a space yet. We'd be happy to host the next one here at Coloft.

<comment><AUTHOR> sounds good!

</comment></comment></comment></comment></comment><comment><USER5> I am really interested in going, but it just so happens I'm out of town for the next 3 weeks :( I'd love to hear about how things went, and for this to be a monthly occurrence. I look forward to the next one! :)

</comment><comment><USER6> Awesome! I've been waiting for one of these since I got to LA.

</comment><comment><AUTHOR> This will be our first meetup, so join in on the initial discussion for what we hope to be a monthly fixture!

</comment><comment><USER7> Is the meeting likely to be in other parts of Los Angeles, or will it remain a Santa Monica Meetup?

<comment><AUTHOR> We'll likely be having our next one in SM, since CoLoft so generously donated space to us, but I don't see any reason we wouldn't be able to move around a bit! Out of curiosity, what part of LA are you in?

<comment><USER7> Pasadena, near JPL/Caltech. The downside to being out here is that there aren't any public hacker spaces (that I know of).

<comment><USER8> I'm in the same area - I'm sure between Caltech, JPL, and places like Idealab there should be some more of us around. I'll organize a local meetup if we can get a few more people - if you're from the area and interested, reply here or send me an email (in my profile).

<comment><USER9> I'm also from Pasadena. I would definitely be there.

</comment></comment></comment></comment></comment><comment><USER10> I'd totally go, but the ICFP contest is this weekend. Well, maybe they'll have a boring problem.

</comment><comment><USER11> Sounds great! Incidentally, there's a chalk festival in Pasadena that weekend too.

</comment><comment><USER12> Still shooting for 3pm?

<comment><AUTHOR> Yep still shooting for 3.

<comment><USER12> Damn, was hoping it was a bit later - won't be able to make it this time. Looking forward to the next one. Thanks for putting this on!

</comment></comment></comment><comment><USER13> I'll be there, and I'm looking forward to it!</comment>