Docker Image Insecurity - <AUTHOR> https://titanous.com/posts/docker-insecurity <comment><USER4> I wish the author had not omitted this crucial paragraph in the announcement he quotes:

        Note that this feature is still work in progress:
        for now, if an official image is corrupted or tampered with,
        Docker will issue a warning but will not prevent it from
        running. And non-official images are not verified either.
        This will change in future versions as we harden the code
        and iron out the inevitable usability quirks. Until then,
        please don't rely on this feature for serious security, just yet.

So, we've made it pretty clear from the start that we're _working_ on ways to make image distribution more secure, but are not _claiming_ that it's more secure yet.

<comment><USER5> I wish you'd take things like this seriously when they become public and not spend your time telling the world how everyone is wrong about Docker. The author spent a lot of time disassembling this issue and he doesn't even work for you; rather that interpret that as trying to make Docker better, which it is, you're right back on HN playing the "nobody understands what we say and everybody bullies us" attitude that Rocket really brought out of you. I wish you wouldn't do that.

We can't all get what we wish for, apparently. The difference between your wish and my own is that the less I get mine, the more you alienate the people in this community. It's your prerogative not to care about that, but how you act on HN has really made clear to me that Docker is riding on simply being first, just as MySpace did.

<comment><USER4> We do take security reports very seriously, when they were brought to the project repo: [https://github.com/docker/docker/issues/9719](https://github.com/docker/docker/issues/9719)

If you are looking to gauge our reaction to legitimate criticism and bug reports, you should follow the github repo and mailing lists, not hacker news.

<comment><USER5> I'm not talking about Docker. I'm talking about you. Your first inclination is how people are wrong and only you are right, in every case. I don't understand your need to make everyone who criticizes Docker feel wrong, or like they missed something. Your thread here about Rocket was extremely alarming and directly motivated me to plan for a future without Docker.

Best way forward here would have been "hey, thanks for looking into this, we know it's an issue." All of which you said later after making sure the author knew he missed something, which no normal user is going to look for anyway.

The real bummer is you remind me of the CEO of Linode, whose company will fail for similar reasons. He is equally infallible and ignores criticism.

<comment><USER4> That's an understandable criticism, even though it makes me want to die inside. Let me try and explain my point of view, and why this whole situation is so frustrating to me.

First, my impression is that I _do_ spend most of my days listening to criticism by people smarter than me, revisiting my assumptions, and trying very hard to make people feel appreciated for their effort in the process. Most of that effort is spent on IRC, the Docker repository, and the Docker mailing lists (in decreasing order of time invested). Obviously, I am biased. But I'm willing to bet that if you spent a week or 2 on the IRC channel interacting with me and the other maintainers, you would develop an entirely different picture of how we work and how we treat criticism.

Second: aggressive blog posts by competitors and their coverage in Hacker News. This is something new to me, and I acknowledge that I have been handling it very poorly. I thought I had learned my lesson last time, but as your message points out, it appears I have not. Basically, I handle very badly the combination of 1) feigned indignation and ignorance by people with clear conflicts of interest; 2) a small number of vocal haters waiting for an opportunity to pile on, and 3) lots of intelligent but uninformed bystanders. When someone makes a valid criticism, with the ultimate goal of improving the project, as harsh as it is, I will be the first to embrace it. But here we are talking about something different: a blog post written by commercial competitors, with the intent of making the project look as bad as possible - using valid _known_ criticism when available, but not shying away from recycling old criticism which has since been addressed, or sometimes making up facts altogether - resulting in a more compelling narrative that will "stick" better. These are posts crafted by venture-backed companies competing with Docker, inc. in the same general space (developer and IT tools), with all sorts of conflicts of interests. I now these people personally, they are all part of the Silicon Valley scene, and what they do is very intentional. It has nothing to do with honest criticism or attempts to improve the project - <USER2> are taking place all day long on the repo, and never generate any drama. It's just business as usual, but as an engineer it drives me crazy. What drives me most crazy is how easily people fall for it. But, I acknowledge that it's not an excuse for the sort of knee-jerk reactions I've engaged in. As frustrating as it is, I think the proper reaction would be to 1) stay under the radar, wait for the drama to die down; 2) take a solid look at the criticism, extract the _real_ one from the political bs, and focus on fixing that; 3) take a solid look at how well we communicate what we do. For example, we have made good progress on security compared to 6 months ago, but clearly we have done a poor job at explaining that and showing solid proof points. 4) as outrageously hypocritical and unfair as these posts appear to _me_ , who know the full back story and understand the commercial motivations, remember that the rest of the world is not aware of the commercial back story. And frankly, they don't care. What they'll remember is our response to the criticism.

So - I did my best to express my point of view on all this. My personal lesson is that success is not that fun, and sometimes I regret the days when Docker was not successful. But at the same time there is a sense of responsibility: a great many people use this tool every day, and we are responsible for improving those tools every day. Once these vc-backed competitors (whether it's coreos or flynn) are done writing their blog posts, they aren't going to fix the project. That's our responsibility, and nothing else should matter.

So, for what it's worth, my new year's resolution will be to do a better job at the above - and perhaps take a break from Hacker News altogether, too ;) Feel free to join the IRC channel if you want to discuss this some more. In the open, of course!

<comment><USER5> You make some good points (and I genuinely appreciate the long and well- thought-out reply, honest), but two things stand out to me:

First, a blog post is only aggressive if you let it be. I can set up a blog and sit around shitting on Docker all day long, and in fact, the entire Hollywood ecosystem is built around that crap. There's blog posts about my current and former employers that make my stomach turn. One guy in particular has written essays about how a former employer is anti-Semitic, and they're basically all made up. My root point is just to be above it. If you want Docker to succeed, it's more effective to _prove_ those blog posters wrong than to _tell_ them they're wrong, you dig? Talk is cheap. "You missed this part of the announcement" is just throwing contempt around, fixing the issue is just better in every way.

The second point is I get your contempt for CoreOS and Flynn, but calling them VC-backed and swiping at them didn't help. You're VC-backed too, and you know that, so I'm left confused by your general tone on that. You're also not going to score many friends on Hacker News by contempt for the VC ecosystem, which is how that read (and apologies if I was wrong there). The us-versus-them stuff that I see you do, that included, is a pretty strong signal regarding coming to work for you, so for every asshole that won't shut up like me, imagine all the silent people reading your remarks and quietly coming to conclusions.

All in all, thank you for the reply, and I'm glad you're at least thinking about how to be better on this.

<comment><USER4> On the vc-backed point, i should have been more specific. There is nothing wrong with being vc-backed. However there has been a deliberate attempt at crafting a narrative of "docker is expanding feature scope because it is vc- backed therefore greedy an untrustworthy". That narrative is pushed by competitors who are also vc-backed, making the whole thing quite ridiculous. Yet somehow it sticks. It's very disheartening given the enormous focus on cleanly layering company success on top of project success.

Anyway, you are right. Time to focus on fixing the actual issues and ignoring the rest.

Thanks.

<comment><USER5> No, thank you. You gained a lot of respect back just by listening and taking it to heart.

By the way, I totally get you. I'm the same way. If someone's wrong, damn my position, I want to tell them. It's damaging to a deep layer when people are wrong about your work, especially when you believe in it very strongly. I compared you to caker earlier and he and I went twenty rounds about decisive, honest response to some of the criticism. One thing he's good at, to his credit, is knowing when _not_ to respond (usually). I'm still learning that.

Anyway, happy holidays.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> I keep hearing people ask "why won't they just get the core tech right instead of adding all these tangentially related features?".

If Docker was just an open source project, it could focus on getting the core tech right. But Docker is also a startup, and the startup can't stay differentiated unless they keep adding bells & whistles, all of which stay tightly integrated.

See also "Why there is no Rails Inc" ([http://david.heinemeierhansson.com/posts/6-why-theres-no- rai...](http://david.heinemeierhansson.com/posts/6-why-theres-no-rails-inc))

<comment><USER7> Let's be real here. If Docker was 'just' an open source project, it would move at 50% of the pace and security issues like this would still not be solved. It's crazy to assume that if it were an open source project it would somehow get the core right faster or not expand on its ambitions.

If it were just an open source project, it could focus on nothing, because Solomon would be working on something else that would actually pay his bills.

It's just a young project with a huge interaction surface, they're trying to please a lot of people in a very small amount of time. No reason to panic, just wait for it to get finished.

Also, Docker is an extracted product just like Rails is, and it's not really a framework so I don't think DHH's argument really applies here.

<comment><USER8> > Let's be real here. If Docker was 'just' an open source project, it would > move at 50% of the pace and security issues like this would still not be > solved.

That's wild speculation, and the elephant in the room (Linux), while a different beast, is a pretty strong counterexample for how being 'just' open source oesn't doom you to being slow or insecure.

> It's crazy to assume that if it were an open source project it would somehow > get the core right faster or not expand on its ambitions.

I don't think it's crazy at all. A (say, community funded) purely open source project has no distractions and has nothing to do _but_ to get the core right. It also has no incentive or reason to expand its ambitions.

<comment><USER9> You took _Linux_ as an example? It took Linux 10 years (1992-2002 - <USER3> 2.4) to get to a stage where it's considered widely production-ready in the enterprise. And the phenomenal development rate of the 2.4+ series is thanks to corporate sponsors hiring talented developers to work on the kernel full time.

I can give you a couple of counter-counter-examples.

GIMP has been around for almost 20 years by now, but its development rate is abysmally slow, still faraway from what most people expect from a Photoshop replacement. Its progress since ~2008 hasn't been that big.

GNOME has been around for almost that long too, but it's constantly suffering from lack of man power.

The Sidekiq background worker system for Ruby is open source, but development went much faster ever since the author started monetizing on it by selling commercial licenses.

Nginx is also open source. They have much more development power now that they are a business and have a source of income. Before, it was just Igor working on it whenever he had time when he's off work.

</comment></comment></comment></comment><comment><USER10> I don't understand why the image distribution is so tightly tied into the main docker codebase. This is why rocket is a thing, because docker is the systemd of the container world. Please stop trying to do everything.

<comment><USER11> There are a lot of problems to solve, and docker by itself only gets you part of the way. Orchestrating docker containers is the interesting problem, not so much Docker in itself (for me anyway). The handwringing that docker should do less (as a company), because each company should only solve a small problem is just stupid.

If the argument is that the tools should be small and composable, then I agree 100%. Maybe image distribution should be a separate tool from the tool used to run a container. That is actually a pretty good point.

<comment><USER12> I think the "handwringing that docker should do less" has a lot to do with the fact that just getting Docker containers right is a huge effort in itself, and they have a long way to go even there. It's not a _solved_ problem by a longshot.

<comment><USER11> I agree, there are problems all around. I was responsible for getting docker adopted on a fairly small (but a number of moving parts) software project. It has been somewhat painful.

</comment></comment></comment></comment><comment><USER13> Hello, I'm the lead security engineer at Docker, Inc.

There is nothing particularly new in Jonathan's post and I thank him for facilitating a conversation. Image security is of the upmost importance to us. For these reasons, we've concentrated efforts here in both auditing and engineering effort. Engineers here at Docker, our auditors, and community contributors alike have been evaluating this code to many of the same conclusions.

Last month, we released Docker 1.3.2 which included limited privilege separation and extending this paradigm has been discussed. I have explicitly called out the need for containerization of the 'xz' process, and to run it in an unprivileged context. I thank Jonathan for reminding us of the need for this work and validating much of what is already in progress.

As the recently published CVEs describe, we are expending resources in discovering and fixing security issues in Docker. Yet, I agree the v1 registry has a flawed design and we're aware of it. In September, I requested to become a maintainer of the tarsum code and have also made proposals and pushed PRs toward improving the v1 registry integration. This is not to replace the v2 effort, but to offer improved security for the design we have today.

We have a draft for a v2 registry and image format. This and the supporting libtrust library are in the process of being audited by a 3rd-party. This is something we had previously promised the community and are making good on. What code exists today is a technical preview.

Unlike the v1 registry and image format, the libtrust and v2 image format code has been designed for a decentralized model. However, as the libtrust and v2 image work, and subsequently, registry protocols are still in draft and security review, it is difficult for us to recommend that users yet attempt deploying these. This is why the developers of that code have not published clear instructions for its use, nor made such recommendations. As this work comes out of review and a specification is finalized, we should expect to see a much better experience and more secure image transport, along with stronger support for on-premises and 3rd-party registries.

<comment><USER14> Lead marketing engineer

<comment><USER15> It's unfortunate ewindisch's post has elicited such a response. He clearly spent time trying to communicate clearly the situation at Docker and some of the security issues surrounding it. I could be wrong but it doesn't seem that you've spent a commensurate amount of time and through in your reply.

It's certainly your right to be snarky and negative. Perhaps that's how you've learned to address others whom you're offended by. But instead of insulting ewindisch by using 'marketing' as an epithet, can I encourage you to address the content of the post instead?

Clearly, by using the term 'marketing' you mean to imply that the content of ewindisch's post lacks the kind of content you deem relevant to sufficiently addressing this issue. Why don't you challenge ewindisch on this? That would be more constructive than saying that he's NOT the lead security engineer.

<comment><USER16> Perhaps it has something to do with smaller companies and the need for engineers to talk to customers. But the engineers I work with would never say silly things like "facilitating a conversation." OTOH, the marketing department will go to great lengths to add phrases like that to anything they send outside the company.

<comment><USER17> I've seen more authentic replies on here get lambasted for being unprofessional. That bit of phrasing did make me twitch, but I can see how he might've thought he needed to put on his 'corporate communications' voice before posting here.

</comment></comment></comment></comment></comment><comment><USER18> I would really prefer when Docker, Inc would spend their time and effort in securing their core product rather than extending it all the time by adding more and more features like Machine, Swarm, etc.

<comment><USER19> According to Red Hat, the current best way to secure your Docker usage is to `127.0.0.1 index.docker.io` and use an alternate transport.

The core "translate flags into running container options" works fine IMO, it's the centralized transport causing the issue. Which isn't the end of the world, as distributing tarballs is not exactly a demanding task.

As an example / plug, I helped write a (prototype) tool that lets you import a docker image from the registry, then transport / version it separately: [https://github.com/polydawn/hroot](https://github.com/polydawn/hroot)

Thus, integrating via `docker load` + `docker export` is possible & reasonable.

Linked from the article: [https://securityblog.redhat.com/2014/12/18/before- you-initia...](https://securityblog.redhat.com/2014/12/18/before-you-initiate- a-docker-pull)

</comment></comment><comment><USER12> The inevitable CVE's coming from this report will definitely get their attention. Hopefully the adults in the room will help make sure that the Docker team addresses what up until now has been a really lax approach towards security.

Who is the architect in charge of this, and do they have any security chops? If not, it's just a matter of $$$ to get a 3rd-party security review before every major release. I've done it before, and it's really not a big deal.

</comment><comment><USER20> It confuses me why they wouldn't just verify the images since they have the signature in the manifest. Is this because they don't want to wait for a complete image before the start streaming through the pipeline? Is this actually a significant time saver?

<comment><USER21> The entire model looks to me like it never had even the most superficial security analysis done. It's like a smorgasbord of insecure decisions:

* the false sense of security from putting signatures in the manifests then ignoring them

* loading signing certs via the network with no provision for pinning

* happily loading untrusted/unsigned images by default (npm, rubygems, installtools, etc. also do this but why repeat their awful design mistake?)

* running basically everything as root (because why deal with all those messy permissions?)

My sysadmin Spidey-sense has been tingling at the rate of change in the Docker ecosystem since it went from "interesting POC" to "we think it's production ready" in a shockingly short period of time. Things like this sadly confirm that initial pessimistic view.

<comment><USER22> Not at all related to docker, but this sort of thing is what makes me happy about communities like Rust. They are taking an incredibly long time to get to 1.0, but they've been progressing methodically and consistently and are trying to get something good out the door instead of bowing to any pressure to release early. Of course, Mozilla is a different beast compared to Docker, Inc., there is less of a profit motive more so than a need to create a revenue stream to stay maintainable and keep creating good new tech.

Things like this are really putting everything that is happening with Rocket and the drama around it in perspective.

</comment></comment></comment><comment><USER23> Particularly interesting given that some of these problems were pointed out to Docker folks ~4 months ago in the development of the feature. [https://github.com/docker/docker/issues/8093#issuecomment-57...](https://github.com/docker/docker/issues/8093#issuecomment-57138688)

<comment><USER22> Read through that thread, funny thing is 19 days ago someone is pointing out how the docs are misleading after he is informed that docker doesn't verify signatures [1]. @shykes makes the claim on one of the comments here that nobody has every brought up that particular issue before, and while he wasn't the one who responded to this guy someone from the docker core team did.

Clearly nobody changed anything in the docs to clarify. Like most things security related people don't care until there is a major exploit or somebody with enough clout complains enough, or more likely than not both.

[1]: [https://github.com/docker/docker/issues/8093#issuecomment-65...](https://github.com/docker/docker/issues/8093#issuecomment-65612835)

<comment><USER24> Not disputing that the "verified" message is misleading, but the comment you referred to was about "not yet being able to create a signed image".

I don't think there's anything yet in the docs with regard to signed image, apart for the release notes[1] mentioning it being a "sneak peak" of a coming feature, that is under development

[1]: [https://docs.docker.com/v1.3/release-notes/#new- features](https://docs.docker.com/v1.3/release-notes/#new-features)

</comment></comment></comment><comment><USER25> Early on, I asked that images be signed similar to Debian packages, but was met with skepticism and resistance. To me, none of the Docker core devs had a handle on security implications of allowing anyone and everyone to share random bits without being able to prove end-to-end integrity and nonrepudiation.

I hope this has changed, Docker is a great app. But if not, Perhaps someone would like to teach them a security lesson? It seems the only way most people actually learn, sadly. :(

</comment><comment><USER26> Reminds me of debian and ubuntu's requirement that apt-get is run under root. There is simple ways to get apt-get to run on non-root, but it require giving permission to non-root account to modify important package signature files. But, they're not as bad as docker. It's becoming norm for these US/Silicon companies to give very bad integrity on data.

<comment><USER21> The difference here is that apt-get and its ilk need to modify critical system state basically every time they run, and that state isn't controlled by a persistent daemon. I actually consider this a great tradeoff: yes I have to use sudo to run that one command, but I don't have a long-lived process sitting around pulling data down off the Internet and doing stuff with it while humming along as uid 0.

It's also literally one line of code in most UNIX-based languages (syscall.Setuid(<uid that isn't root>) in Go, FWIW) to drop root privileges before doing something unsafe. Even if the main Docker daemon absolutely has to run as root most of the time, it can and should fork and drop that access for anything dealing with moving data between unstrusted (e.g. the Internet, user input, etc.) and trusted (verified, read-only local state) security domains.

<comment><USER27> As a quick word of caution (which doesn't invalidate anything you've said), Go has a long-standing bug[0] whereby syscall.Setuid doesn't always apply to all threads (on Linux at least) so extra care does have to be taken.

[0] [https://github.com/golang/go/issues/1435](https://github.com/golang/go/issues/1435)

<comment><USER28> It's not a bug, strictly speaking; it's just a feature that's really easy to misunderstand. The `syscall` package in Go tends to be logic-less wrappers around the raw syscalls, and that's what happens here.

Linux actually maintains the uid/euid/suid/gid/egid/sgid/etc. fields per OS thread (which are actually processes, just with a bit of shared memory). The raw syscalls only change the fields on a single task.

Glibc is where the logic happens to propagate that setting to all threads, by setting up signal handlers and immediately triggering a signal, IIRC.

You can get the useful behaviour by using cgo and importing setresuid from unistd.h.

What go should probably do here is:

1) Add os.Set{res,re,}{u,g}id, which implements the logic from glibc.

2) Remove syscall.Set{res,re,}{u,g}id. Anyone that wants that behaviour can use syscall.Syscall6 and syscall.SYS_SETUID or whatever. At least, they could add some really loud godoc to those methods.

The main problem with that is that `os` tries to have a cross-platform API, and (for example) BSD has no saved user or group IDs and therefore no setres{u,g}id. I suspect Windows and Plan9 are even weirder.

<comment><USER29> > It's not a bug, strictly speaking; it's just a feature that's really easy to > misunderstand.

It is a bug on Linux -- strictly speaking. Did you see how it is patched? They removed setuid from linux: [https://codereview.appspot.com/106170043](https://codereview.appspot.com/106170043)

> "That these functions should made to fail rather than succeed in their > broken state."

</comment></comment></comment></comment></comment><comment><USER30> As a non-security aware(not a security specialist) developer, this was one of the most instructional and concise little gem about security flaws i've read. You can learn very useful tricks just by reading this. Thank you</comment>


Ask HN: Received three password reset emails - <AUTHOR>

I received three password reset emails from Hacker News today that I did not initiate. The emails say just to ignore it but should I report it to anyone? <comment><USER2> Was it an email about someone attempting to change your password or was it an email requesting you TO change your password?

If it was the latter scenario, feel free to reach out and talk to the phishing scammer. Recently I had a great conversation with the guy sending out BTC-e phishing mail. We talked about where he bought his email list, how many people he has on it, and how he's just trying to get enough money to buy a safe house for his family. He sounded like a pretty decent guy aside from the fact that he's stolen about 20,000 litecoins so far.

<comment><AUTHOR> It was from Hacker News. Someone was attempting to reset my password. I got three of these emails 2 minutes apart each. I wondered if it had to do with the recent heartbleed bug.

</comment></comment><comment><USER3> it sounds likely to be someone trying to reset the password for username "mattm". possibly malicious, though given its its "very common first name + first letter" format, it strikes as very possibly a confused user thinking it was theirs.</comment>


Prison Switcharoo - <AUTHOR> http://www.cartalk.com/content/prison-switcharoo-0?question <comment><USER2> If you enjoy non-trivial puzzles such as this, I strongly recommend Peter Winkler's book _Mathematical Puzzles: A Connoisseur's Collection_. It contains two variants of this problem. The easier of the two, _The One-Bulb Room_, has essentially the same solution as this one.

On the other hand, the harder one is really considerably harder! Here it is, _The Two-Bulb Room_:

"Each of n prisoners will be sent alone into a room, infinitely often, but in some arbitrary order determined by their jailer. There are two lights in the room, each with its own binary switch. There will be no means of communication other than these switches, whose initial states are not known. The prisoners again have a chance to confer in advance.

Again, we want to ensure that some prisoner will eventually be able to deduce that everyone has visited the room. What, you did it before with only _one_ switch? Ah, but this time, every prisoner must follow the same set of rules."

<comment><USER3> Is this two-bulb room problem not identical to the OP's Prison Switcharoo problem?

<comment><USER2> There are two differences. The first is a minor difference in the way it's formulated: in the OP's version, the prisoner is obliged to flick one switch or the other when he's sent into the room, whereas in this version he has the option of doing nothing.

The second difference is the one that makes this problem genuinely difficult, though: "Ah, but this time, every prisoner must follow the same set of rules." In other words, the agreed strategy has to be the SAME for every prisoner.

<comment><USER4> Depending on whether the prisoners are able to determine the passage of time, this can either take relatively little time or a lot of time.

Easy: If the warden grabs a prisoner once a night, then the prisoners set up a system according to the passage of days.

Each prisoner starts with four "tokens." This means that in a prison population of 23 prisoners, there are 92 tokens in total for the prisoners.

We'll call the switches A and B. Starting off, A signifies 1 token. When you turn the switch on, you are putting a token into the switch. When you turn it off, you are taking one. B signifies 2 tokens.

When a prisoner visits the office, he looks to see if he can grab some tokens. If neither are on, then he puts in some tokens of his own. He will try to put as many tokens as possible in. So, for example, if he has 4 tokens, he will put in two.

Of course, if he has insufficient tokens, he does nothing.

After a predetermined period of time, the switches double in "worth." Switch A is now worth 2 tokens, and Switch B is worth 4. This will double again to 8 and 4, then 16 and 8, and so on, until they reach 64 and 32. If someone is able to accumulate 92 tokens, then it's apparent that everyone has visited the room at least once. Otherwise, it then starts over at 1 and 2.

We need four tokens for every prisoner because of a few possible extra tokens. If A and B are both on, then there are three extra tokens in the system. If you have fewer than four tokens per prisoner, it becomes possible to accumulate the required number without having everyone be in the room. You also can't have fewer tokens, because it would require that a prisoner collect tokens that might not actually be there.

Hard: If no one can figure out the passage of time, then they have to stay at 1 and 2. This will take much longer for someone to eventually accumulate all of the tokens, especially since all of them are trying to accumulate.

Edit: Here's a horribly written Python program that shows this process in action: [http://codepad.org/iY121Ui3](http://codepad.org/iY121Ui3)

</comment></comment></comment></comment><comment><USER5> What a fun puzzle! The "ah-ha" moment is realizing that the brains of the prisoners can be be used to store the state, and not just the panel of switches. My initial reaction was to think about the storage capacity of the switch panel, and immediately hit a wall because clearly you can't store 26 bits in 2 switches. So you have to go hunting for another place to maintain state - and of course in the head of one of the prisoners is a great place!

</comment><comment><USER6> There is a very interesting paper which solves the problem when there are 100 prisoners, and there is only one lightswitch and one light bulb. It's like an exercise in communication over the lowest bandwidth channel imaginable. Some of the schemes get fairly complicated, and there are some difficult probability analyses on time-to-escape.

[http://www.segerman.org/prisoners.pdf](http://www.segerman.org/prisoners.pdf)

</comment><comment><USER7> The answer: [http://www.cartalk.com/content/prison- switcharoo-0?answer](http://www.cartalk.com/content/prison- switcharoo-0?answer)

<comment><USER8> It should be 43 instead of 44, right?

<comment><USER9> The answer explains this. The number should be ( _p_ \- 1) x 2 where _p_ is the number of prisoners. (23-1) = 22 * 2 = 44

<comment><USER10> But would it not be sufficient to count p?

If switch A starts out in the ON position it would equal one 'fake' prisoner. If the counter just counts one extra (which equals p - 1 (himself) + 1 (fake prisoner) = p) it should be enough, no?

<comment><USER11> The issue is that the counter doesn't _know_ the state of the first switch at the start. If it's on at the start, then sure your solution will work. But if it's off at the start and they all agree to only flip on the switch once, then the counter will sit around forever waiting for p flips, when only p - 1 will ever happen. They need a solution that will work no matter what state the switch is in at the start.

</comment></comment></comment></comment></comment><comment><USER12> This was a fun problem. On the other hand, I felt cheated when Vidit Drolia of Yammer gave this problem and expected it to be common knowledge enough to be solved in 3 minutes. Don't think it's quite that much of a valid interview problem.

<comment><USER13> Puzzles during the interview -- show others how smart you are by giving clever puzzles. Watch them struggle, make them feel bad for not figuring it out under pressure. Also accept lots of people who can google puzzle answers, or just are really good at solving puzzles. Which, works great if they are running a plumbing company and have to figure out good shapes for your manhole covers, a prison, or are just evil and like to shrink people and throw them into blenders.

</comment></comment><comment><USER14> Here's the best solution I've heard for this:

The prisoners meet together and designate a leader. The leader will maintain a tally. They also designate one of the switches to not matter. The prisoners then use the following strategy:

When a prisoner is lead to the room, if the designated switch is off and it is the prisoner's first time flipping the relevant switch, it is turned on. Else, flip the irrelevant switch. If the prisoner is the designated leader, and the relevant switch is on, he adds a count to his tally and turns the relevant switch off. Otherwise he just flips the irrelevant switch. This way, once the leader has seen the light be on a sufficient number of times he can definitively say that they have all been in the room.

<comment><USER15> > once the leader has seen the light be on a sufficient number of times he can > definitively say that they have all been in the room.

Ah, but what's a sufficient number of times? The unknown initial state is what tripped me for a bit. :)

<comment><USER16> n-1, where n is the number of prisoners. -1 to account for the leader.

<comment><USER17> It's actually 2(n-1), because the designated switch can start in either state.

</comment></comment></comment></comment><comment><AUTHOR> I love puzzles like the ones that Click and Clack showcase on Car Talk (NPR). The Sunday Puzzle ([http://www.npr.org/series/4473090/sunday- puzzle](http://www.npr.org/series/4473090/sunday-puzzle)) by Will Shortz is also another source of challenging word puzzles. Games Magazine and Martin Gardner's columns in Scientific American are/were also fantastic reads for games and puzzles.

What other sources of word/math/logic puzzles are out there?

<comment><USER18> Presh Talwalkar posts weekly logic puzzles[1]. His blog is a good source of interesting applications of economics and game theory to the real world.

[1] [http://mindyourdecisions.com/blog/](http://mindyourdecisions.com/blog/)

</comment></comment><comment><USER19> Although the supplied answer guarantees that no prisoner will die from alligators, it does not guarantee their freedom.

The answer includes a major (and I believe flawed) assumption, which is that the visits will be uniformly distributed. However, the puzzle states that "I may choose the same guy three times in a row".

The Counter could visit the switch room 44 times without flipping the switch if such visits were the first 44 chosen. After everyone visits (which would be 1,012 visits since "given enough time, everyone will eventually visit the switch room as many times as everyone else"), the Counter will be no closer to knowing the truth.

Of course, it is true that the greater the number of visits the greater the probability that the Counter's final visit will fall after everyone has visited, but there is no guarantee.

Regardless of how many visits you assume for each prisoner, there will always remain a probability that the Counter's visits will be clustered early in the visitations. In such a scenario, the Counter's role becomes useless and all prisoners will die in prison.

</comment><comment><USER20> The solution assumes no prisoners die before they flip A twice. No fault tolerance : p

<comment><USER3> You could solve this by creating an order of succession for the designated counter in your original meeting.

If no announcement is made when someone dies, however, you've got a problem.

</comment></comment><comment><USER21> In the version where one prisoner is taken in per day, the solution can be drastically simplified if it is agreed that the prisoner who is taken into the first day is the counter.

That case only requires flipping switch a off 22 times after the first day.

Obviously, removing that single bit of information makes the solution much harder to find, but adding then later removing it makes discovering the solution a more iterative thing. Which is desirable if, for example, you're giving these puzzles to your kids.

<comment><USER22> You cannot know if you are the first to go into the switch room. Prisoners are taken to the room at arbitrary times.

<comment><USER23> I think you missed the part where he said "In the version where one prisoner is taken in per day", in which case it _is_ possible to know if you are the first to go into the switch room.

<comment><USER22> Right...

</comment></comment></comment></comment><comment><USER24> Is it me or does this solution rely on the belief in a certain order to the random picking of prisoners? If the counter switches to an off state 44 times, that doesn't tell him that all 22 other prisoners gave toured through the room. A guard (random algorithm) could have just selected the same two prisoners -- the counter and another guy -- 22 times. Am I missing something?

<comment><USER25> You are missing the cooperation of the other prisoners, they have agreed to only give information to the counter once no matter how many times they are sent into the room by the guard.

</comment></comment><comment><USER26> This is mostly an instance of a class of problem discussed in more depth here: [http://www.ocf.berkeley.edu/~wwu/cgi- bin/yabb/YaBB.cgi?board...](http://www.ocf.berkeley.edu/~wwu/cgi- bin/yabb/YaBB.cgi?board=riddles_hard;action=display;num=1177584051)

I say mostly because the bit where one switch must be toggled and there are 2 switches makes it a bit different from 23C2. I don't think the difference is useful, though; the set of solutions is probably the same as the solution set for 23C2.

</comment><comment><USER27> Since there's a password article on the front page too...

This problem is very clever, and there is a very clever way to solve this, assuming everyone plays nice. However, that solution assumes perfect collusion. These are prisoners we're talking about, so at least in some cases, we have to assume there may be bad actors involved. I mean this is a cute problem assuming the following:

1\. All the prisoners have perfect memory (for this problem)

2\. All the prisoners actually want to live.

3\. The warden is telling the truth

4\. The guards are all honest.

These are all the type of assumption that gets websites hacked. So what is the attack surface here?

* One of the prisoners decides this is a fun way to suicide

* One of the prisoners is in gang A, and one is in gang B. They value gang honor above their own life, and need to take out the other.

* A guard has decided that this is a great way to off some "scum"

* A prisoner forgets the algorithm, or hits the wrong switch, or other form of human error.

* As if_by_whisky points out: someone dies before the full run.

* The warden just wants to mess with people before feeding them to alligators, and just states "wrong" whenever someone declares all have visited.

* A prisoner can't handle the stakes, and cracks and makes the declaration early.

* The leader messes up the count.

There are probably a lot more.

Further, the warden is making assumptions that we can't be sure are true. Prisons are notorious for being bad at doing the actual security thing. Are there ways for prisoners to collude and do extra error checking on their end? Can a guard be bribed to help share state? Is there a way to get other prisoners involved in message passing, even if they manage to prevent direct collusion between the selected 23?

I don't know a way around all of these. In fact I'm pretty sure there a some combinations where everyone is just fucked. But, what can be done to add robustness to this problem? It seems pretty silly for prisoners (likely malicious actors as a generalization) will follow the rules and stay within the constraints the warden sets out.

I ask, because I've solved plenty of things in a nice elegant way, that were trivially broken by not assuming everything will play nicely in the environment. Similarly I've broken plenty of "awesome solutions" by asking questions about assumptions. The difference between the algorithmic solution and the real world is sometimes surprisingly large. Just some food for thought :)

<comment><USER28> The warden lying is in the same category as the universe exploding (I.e., the universe might explode next week, should I still get a coffee?).

It's fine if you think games are stupid, maybe try to get to the point a little quicker though.

<comment><USER27> I don't think games are stupid. I just like them to be a bit in depth. Why would I spend time looking at a more interesting version of the game, how to cheat it, and how to add twists otherwise?

Also, if you want to take a game theory approach, you're wrong about the warden. If the warden is just playing a sadistic mind game, and wants to fuck with the players before feeding them to the alligators, the correct "solution" to the game for the players (should they catch on to the warden), is to never declare, thus extending the game infinitely, or barring that maximally, before the warden bores of the game and offs them.

</comment></comment></comment><comment><USER29> I had fun solving this today and wrote a dinky ruby program [1] to test my solution. Is there a better way to do this?

[1] [http://pastebin.com/n0vHSdzm](http://pastebin.com/n0vHSdzm)

</comment><comment><USER30> The solution could take years, even decades to solve - all depending on how often the warden brings in a prisoner. I'd rather wait out my prison term, hope to be released early for good behavior.

</comment><comment><USER31> Can't they all meet in the switch room?

<comment><USER32> Every now and then you find someone who thinks differently from everyone else. In this case, you.

<comment><USER31> I might also be thinking wrong. But as far as I know, the puzzle doesn't explicitly prohibit this.

<comment><USER33> Yes it does. It tells you that a randomly selected prisoner will be taken to the switch room and allowed to turn one of the switches on or off...and will then be led back to his cell.

There's no option for the prisoners to go to the switch room at the outset; they've just arrived at the prison and don't know where it is. So it would not be possible to meet up there, they have to wait for the prison guards to take them there individually.

<comment><USER31> It says they can meet before doing to their cells.

</comment></comment></comment></comment></comment><comment><USER34> Can the prisoners tell if the switch is in the on or off position?

<comment><USER26> Yes. The solution assumes that they can agree beforehand about what to call the states of at least 1 switch. I don't think there is a way to come to that agreement beginning the process.</comment></comment>


Investigating the Performance Overhead of C++ Exceptions - <AUTHOR> https://pspdfkit.com/blog/2020/performance-overhead-of-exceptions-in-cpp/ <comment><USER2> (quoting desc) _sigh_ (end quote)

Exceptions _make your code faster_ in the non-exceptional case.

See all those if-branches for error checks that don't exist in your code? That branch-free code is going to run faster than your branchy code. And the code's shorter, because it doesn't have the checks and handling intermixed, which makes it fit better into cache.

This isn't rocket science, I'm amazed that this isn't obvious.

<comment><USER3> Branchy code where the branches are statically known to be _very_ unlikely ought to be practically as fast as the branch-free equivalent. You're probably forgoing a few optimization opportunities since you do have to build a proper exception record (and perhaps a stack trace) if the code errors out but other than that, it just doesn't matter that much.

<comment><USER4> Static branch prediction isn't found on any major architectures, right?

You can optimize the code generation around that knowledge but not passing it directly to the CPU

<comment><USER5> It is absolutely done, it's just implicit rather than explicit. The simplest heuristic is to predict backwards branches as taken (loops) and forward branches as not taken, and it works quite well (though I think it might be more sophisticated than that).

<comment><USER6> Of course the error-code checking branches will most usually be forward branches, thus not predicted correctly the first time through, or after spilling.

</comment></comment></comment></comment></comment><comment><USER7> I can't say I'm a fan of these sorts of articles. "Which strategy is most performant?!" is rarely the appropriate measure for an error handling strategy, it's more nuanced than that. Concerns like what makes a recoverable error vs an unrecoverable one are more important. Ensuring correctness is more important. The usability of an API is more important. Readability and maintainability are more important. Knowing what errors mean in terms of your domain model is more important.

Use what fits for your situation, don't take the "when all I have's a hammer..." attitude to anything. Sometimes return codes make sense (eg in hot- loop code). Sometimes exceptions make sense (in constructors, for example. And no, two-step initialisation is not a good alternative.). Sometimes neither make sense and you actually should just terminate the whole program (out-of- memory). Sometimes contracts make more sense (precondition checks, validating function arguments).

Anyway, regardless of your strategy if you can provide some method of querying if a thing _can_ succeed to your API, do so; it's always better to handle errors by just making sure you don't cause them!

<comment><USER8> I would add that a error-handling strategy should never be a concern wrt performance because obviously the purpose of this sort of code is to serve as guard rails and ideally never be called at all ever.

If your error-handling code is triggered so often that you feel it might be causing a performance hit, you have far more serious problems than the performance overhead of how you handle errors.

<comment><USER9> My web server gets about 1000 to 1 hits of hacking attempts to valid requests (malformed headers, etc.) so I hope nginx and fcgi handle errors efficiently, because I pay for those cycles.

<comment><USER8> You're not describing exceptional events. You're describing pretty much the happy path of any reverse proxy. In fact, in some applications these sort of events outnumber HTTP Status 200-worthy requests.

<comment><USER9> That's a strange idea of what "happy path" means. An invalid request is, by definition, an error or exception.

<comment><USER8> That assertion is obviously wrong. Think about it: you have a web server listening to the world. Do you really expect all requests to be neatly pointing to sanitized URLs? Of course not. Why on Earth should you assume that handling invalid requests is not one of the primary use cases?

<comment><USER9> You and flqn are trying to convince me that expected errors are not errors [https://en.wikipedia.org/wiki/Happy_path](https://en.wikipedia.org/wiki/Happy_path)

When I want a parameter is an integer, I don't check all the ways in which it's NOT an integer; the happy path is when it _is_ an int and the program can continue, and anything else is an _Error_. If it overflows, that's an error too.

i.e., happy means it's basically the longest path (aside from diagnosing the error).

The question is: should the subroutine set an error number or throw an exception? Knowing the cost for each might help me decide for various situations.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> It should be well-known that actually throwing an exception in C++ is extremely costly. I think it is also fairly widespread knowledge that even allowing the compiler to support exceptions has runtime costs. Exceptions do not conform to C++'s "zero-overhead" principle. That's why numerous large organizations from NASA to the Dept. of Defense to Google decree that C++ exceptions must not be used.

<comment><USER11> I believe the exception ban at Google these days is justified more on the grounds that integrating with existing code would be problematic, rather than on performance grounds. I seem to remember reading something to that effect.

<comment><USER12> Their coding guidelines on the topic lay out the pros/cons and ultimate reasoning pretty well: [https://google.github.io/styleguide/cppguide.html#Exceptions](https://google.github.io/styleguide/cppguide.html#Exceptions)

</comment></comment></comment><comment><USER13> _sigh_ If your application is slow, odds are it's not because you used exceptions.

If you're throwing enough exceptions for this to matter it'll show up on a profiler, and then you can change that specific chunk of code to avoid treating that particular case as 'exceptional'.

<comment><USER14> Tim Sweeney, creator of Unreal Engine, Epic Megagames, etc, recently had a code base where exceptions were causing problems even when not actively being thrown:

[https://twitter.com/TimSweeneyEpic/status/122307740466037145...](https://twitter.com/TimSweeneyEpic/status/1223077404660371456?s=20)

Quoting him in a follow up tweet:

>They weren't throwing and a disassembly showed no visible artifacts of exceptions. But turning off the possibility of throwing exceptions gained 15% and just made the assembly code tighter with no clear pattern to the improvements.

<comment><USER15> How does he know that the performance improvement wasn't just a side effect of altering the alignment of his code? Here's a guy getting a 48% performance improvement just by randomizing the alignment of his functions: [https://youtu.be/Ho3bCIJcMcc?t=351](https://youtu.be/Ho3bCIJcMcc?t=351) or slides if you prefer [https://github.com/dendibakh/dendibakh.github.io/blob/master...](https://github.com/dendibakh/dendibakh.github.io/blob/master/_posts/presentations/PerfAnalysisOnModernCPU.pdf)

<comment><USER14> I am very familiar with this effect. We could of course use effects like this to cast doubt on any benchmark someone has ever run, unless they specifically mention that they tested for this, and 100 other bench marking gotchas. We can, if we like, assert that all things are unknowable, while at the same time asserting that the thing we want to be true is for sure true.

However, it appears to be a rather commonplace occurrence that having exceptions on, even if you aren't using them, can cause performance problems, it isn't just a one of in Tim's case. Also Tim has quite a bit of experience working on bleeding edge C and C++ performance code so there is a good chance he did account for this. You can ask him.

<comment><USER16> How common is it, actually? And on what platforms/architectures? It was a common problem back in the day when most code was compiled for x86, since exceptions weren't designed to be zero-cost in that ABI.

For what it's worth, the article itself has this bit:

"Thanks to the zero-cost exception model used in most C++ implementations (see section 5.4 of TR18015), the code in a try block runs without any overhead."

<comment><USER15> It has been at least a 10% effect in the last two things I profiled, which were a simple software rasteriser and a distributed key value store. The other significant benchmarking gotchas I see are: 1) the CPU being in a sleep mode when the test starts and takes a while to get running at full speed, and 2) other stuff running on the machine causing interference. But these two are easy to work around compared to the alignment-sensitivity problem.

</comment></comment></comment></comment></comment></comment><comment><USER17> Exceptions are not meant to be fast. In fact, exceptions are meant to be exceptional. Hence the name.

Exceptions are meant to be fast if and only if you do not throw any. And even this is only truly true on Unix.

The original implementation of exceptions on Windows put extra unrolling info on the stack and then cleaned it up at the end of the function, adding a runtime cost even when no exceptions were thrown.

The Unix way of exception handling does not put anything extra on the stack, so exceptions are free if you don't throw any. The compiler puts some metadata into your binary and generates cleanup code. If an exception is thrown, the run-time (libstdc++ for gcc on Linux) will grab the return address from the stack and then do a binary search through the metadata to find the right unwinding code generated by the compiler. This is obviously a comparatively enormous overhead. In particular because the metadata are separated from the code, so the OS never has to read it from disk unless you actually throw an exception.

The reason for that is that you are not supposed to use exceptions for signaling. They are for error handling. Exceptions are for occasions like "you asked for memory but there was none left" or "you asked for the 15th element in this vector but it only has 10". They are not meant for non-exceptional errors like "you asked for data from the network but there is no data yet" or "you wanted me to check if the file exists and it does not".

The thinking behind all this is that the error handling path is not time critical. If it happens, something exceptional has happened, and the OS will probably have to swap in the error handling code from disk to begin with, which is horrendously slow. In fact, this is not just a possibility. The feature was designed specifically so that the linker would move the exception handling code to a different page and the OS would only read that page from disk if an exception actually occurs. This is not an accident. It is deliberate planning and took engineering effort to achieve.

Running a benchmark of throw vs return is an attempt to answer the wrong question.

Important side note: operator[] on a vector does not do range checking. at() does. That's why you should always use at() instead of operator[].

<comment><USER18> You seem to be arguing that, because exception tables end up on separate pages, we should consider exceptions as being as expensive as disk accesses. (Apologies if I've just built a straw man, that's how I read it.) I don't buy that. If you use exceptions more than totally exceptionally, according to your definition, then those pages will be loaded to memory and kept there – while the optimisation sounds very clever and sensible, I have a hard time imagining that exception metadata is huge in comparison with the rest of the program code.

Once that data is in memory, you're back to the numbers in the article, where throwing an exception can take barely more than a microsecond. That's huge compared to a function call, but is fast compared to a lot of things that an overly cautious programmers wouldn't dare follow up with an exception. To steal your own example, checking whether a file exists certainly falls into this category – that's likely to take _milliseconds_.

(Even your other example – no data available to read (I'm imagining a select / poll situation) – would probably be fine with exceptions, though I agree it's not the right tool for that situation. Just making a call to the OS is likely to cost a comparible amount to throwing an exception, even though you're describing a non blocking call. And by definition this won't end to being called in a critical inner loop - if data becomes available then the exception will do being thrown.)

<comment><USER19> He makes the point that exceptions should be truly exceptional conditions for your program that would prevent it from running, generally due to system malfunction. Some people use it for basic business logic and it was never meant for that. It is meant to help you gracefully abort things when everything is about to go to hell.

<comment><USER18> > He makes the point that exceptions should be truly exceptional conditions

The comment did say that, but the only explanation of _why_ exceptions should only be used that way seemed to be performance based. If that is not the issue, then what is? Saying "that's what they're for" without any other detail is a circular argument.

<comment><USER17> I feel slightly misrepresented.

I explained how exceptions are implemented, and the actionable intelligence you can derive from that understanding (if perf matters to your code and/or scenario, then use exceptions only for hard errors, not for generic signaling).

If perf does not matter in your scenario, than obviously the guidance does not apply to you. To me that does not mean it's a waste of time to explain how exceptions work and what that means to performance critical code.

</comment></comment></comment></comment></comment><comment><USER20> Converting an exception into a return. Which loses the "have to deal with it; cannot ignore it" property that made the exception valuable.

"The key takeaway here is that an exception cannot be ignored or forgotten; if we have an exception, it must be dealt with."

If converted to simple "C style" status returns -- it is only 5 times slower (11.5ns vs 57.5ns) -- and can be ignored and forgotten.

In the associated slide deck, boolean valid() must be used before value. In this case, this is just as unsafe as C return codes. A C++ exception is always considered an lvalue, meaning that union is initialized, but I am not sure what reading the other side results in (I don't think that this is allowed).

My take on this? Please use an exception if you mean an exception (for C++). If it is too slow (which I consider unlikely), please deal with it some other way (I would suggest a status return).

<comment><USER21> > Converting an exception into a return. Which loses the "have to deal with > it; cannot ignore it" property that made the exception valuable.

[[nodiscard]] -Werror

</comment></comment><comment><USER22> If exceptions aren't used, the error case has to be handled somehow. The usual approach is to return two results, and callers have to check the error flag somehow. If exceptions are very rarely thrown, then even with their very high overhead the total cost could well be lower than the cost of returning a separate error result and having callers check that result, perhaps by pattern matching.

</comment><comment><USER23> Exceptions are expensive and I hope no body uses it in the hot path (80%). The compiler has to inject a lot of code to unwind the stack that affects the cache. It is however not expensive for common operations (20%).

There are couple of threads in dforum that discusses this and to have throw attribute [1] and eventually making nothrow as default [2].

[1] [https://firstname.lastname@example.com...](https://email@example.com)

[2] [https://email@example.com](https://firstname.lastname@example.com)

<comment><USER24> Why do you link to forum entries from dlang on a c++ exception topic? Is the implementation identical or at least somewhat similar?

<comment><USER4> D is evolved from a C++ compiler, and can - in principle, it's a question of priorities I believe, catch C++ exceptions

</comment></comment></comment><comment><USER25> I made a website where you can measure these things in both time and instructions. It's not perfect because it's a VM, but at least you can see for yourself the horror show that is the first exception thrown. And also the bloat that exceptions add. I still use exceptions simply because they are part of the language, although sparingly. But I have a gut feeling that the implementation of C++ exceptions in the current compilers, and the ABI, is just subpar. It has to be, because nothing that isn't a context switch should be measured in hundreds of thousands of instructions.

See: [https://droplet.fwsnet.net](https://droplet.fwsnet.net)

Just experiment with adding and removing exceptions, and compare it. It's shocking.

Hello world using printf:

      Instruction count: 14988
      Binary size: 345 KB

Hello world try->throw->catch (and printf):

      Instruction count: 286926
      Binary size: 397 KB

Hello world using std::cout:

      Instruction count: 63502
      Binary size: 888 KB

<comment><USER6> You are just measuring initialization time. The global "C" locale used by printf is statically initialized. With constexpr that could be done in a C++ library if anybody cared. Runtime spent initializing might matter for startup in an embedded system, but they tend not to use cout much.

You could submit a PR constexpr-ing std::cout initialization.

</comment></comment><comment><USER26> I would love to see the results for increasingly values of randomRange. This is just benchmarking the case when you throw exceptions 50% of the time.

</comment><comment><USER27> If you want to see Herb Sutter's take on exceptions (and RTTI), I can really recommend this talk where he explores his Result-esque (like in Rust) solution that he wrote a paper about and proposes for standardisation: [https://youtu.be/ARYP83yNAWk](https://youtu.be/ARYP83yNAWk)

</comment><comment><USER28> Performance overhead, I'm not that worried about - if you're throwing exceptions routinely in the critical path, there's likely a lot else wrong with your code. The crappy part about C++ exceptions is that they also introduce a substantial binary size overhead.

</comment><comment><USER6> Spot the Howler: " _it's always best to catch an exception as close to the throw point as possible_ ".

No. It's fastest to do that, but if you cared about fast, you wouldn't be throwing at all.

Exceptions, by definition, are _off of the critical path_. If there's a generalization to be made, it's that it's always best to catch them _as far from the event as possible_ , because then you will have few catch clauses. If you have more than a few, you are Doing It Wrong.

It shows a fundamental misunderstanding to worry about how fast throwing an exception is. You legitimately worry about how fast it is not to throw them, and that is generally quite fast indeed.

</comment><comment><USER29> It's popular because it gives to people what they want to hear. There has been lots of research that gave different results and people just love to ignore.

</comment><comment><USER30> The overhead also depends on how the compiler implements them

Some compilers use setjump/longjump (sjlj), and then it needs to save all registers somewhere on every try{}. Probably also in every function that calls a destructor. That is very slow, even if no exception is thrown at runtime

</comment><comment><USER31> I was disappointed they didn't do a test case with std::error_code.

EDIT: Is there something wrong with std::error_code? I don't care about my points, but I'm worried I might have missed something I should know.

<comment><USER32> I personally have a hard time understanding std::error_code. Specifically I can't figure out when std::generic_category vs std::system_category should be used, and I worry that confusion between the 2 of them will lead to confusing and inconsistent APIs where it's hard to predict what error_code will be returned in what situation.

<comment><USER33> std::system_category and std::generic_category are generally the same on non- Windows platforms. std::system_category on Windows is any Windows error (HRESULT, GetLastError, etc) and std::generic_category always represents errno.

So for cross-platform APIs that exist on both you'll generally use std::generic_category as the API is usually defined to modify errno in the case of an error. For Windows-only APIs use std::system_category.

</comment></comment></comment><comment><USER34> Any idea of the cost of the final approach they used for the "success" case? E.g. if the rand errored 1/100, would the cost of returning that union object outweigh the exception?

</comment><comment><USER32> Instead of using Expected you could also use std::optional or std::variant. Expected might have a slightly clearer API for this use case though.

</comment><comment><USER35> 1\. Exceptions are necessary for correctness. This alone solves the question of whether they should be used. Error codes just don't cut it because they only handle _expected_ errors (which is never enough in the real world).

2\. Arguing about C++ exception performance is pretty pointless anyway since C++ performance is its (only) strong side. Until Java/C# matches C++ in e.g. cutting edge 3D engines, this question won't even become interesting.

<comment><USER36> I disagree with both points, in fact with every statement you made. Correctness can be achieved without use of exceptions (whether this is easier or harder to do is up for debate). Next, in some cases correctness may be sacrificed for performance reasons (e.g. solving a traveling salesman problem). I find it easier to properly handle unexpected error codes than unexpected exceptions. C++ has other strong sides beside performance. Java/C# often throw exceptions in very non-exceptional cases (e.g. .Net's File.Delete method).

<comment><USER35> Nope, there's no practical way to cover all possible cases. There is always a possibility of a totally exceptional situation arising (we're only human). And then your beautiful ole error-cods returnin' function either takes down your whole application (which might result in someone dying while on life support in a hospital) or plods on with a successfull error code (leaving your program in an incorrect state). All because you didn't have a catch-all-exceptions clause.

This is why I find C++'s "nothrow" a joke, by the way. It's not within human power to guarantee that any piece of code never throws exceptions. A gamma ray might flip a bit. You never know. The only practical way to reliability is the Erlang way: be prepared for errors arising anywhere anytime, not rely on fallible notions of what can and cannot cause errors.

<comment><USER36> There is a difference between preventing a program crash and handling errors. Please don't use catch-all-exceptions clause for either, especially not in hospital machines.

The difference between writing if (status != SUCCESS) and catch (Exception) is that the former will allow the program to actually crash when it should (see panic in Rust). You should not be able to recover from OutOfMemory or GammaRayFlippedABit errors (use ECC memory to prevent that). You should restart the process (or the entire machine) because you can't hope the developer was wise enough to destroy and recreate appropriate amount of state.

The additional problem with exceptions in Java and C# is that many times you don't care about failure of some operations, but the language practically forces you to write catch-all statement to prevent a program crash, so you end up accidentally catching unrecoverable errors.

</comment></comment></comment></comment><comment><USER37> If you wanted this today, why would you implement the Expected template instead of using Boost Outcome?

<comment><USER38> For the blogpost it makes more sense showing an example implementation IMHO.

And in some places, it's easier just writing it out than deal with the process to add a dependency.

</comment></comment><comment><USER39> TL;DR: We rediscovered monads.

<comment><USER40> Well yes. And that's why there's a group that has in the committee that has been trying to steer await towards a proper do-notation.</comment></comment>


Google Home Strategy Aims to Use Chromecast to Beat Amazon Echo - <AUTHOR> http://variety.com/2016/digital/news/google-home-amazon-echo-chromecast-1201874125/ <comment><USER2> Wow. Google hasn't even released their product yet in this line, and they're already working on blocking the competition. They're not even waiting to see if they can be successful through fair competition.</comment>


"...so that there are no obvious deficiencies" - Hoare on ALGOL 68 - <AUTHOR> http://vestein.arb-phys.uni-dortmund.de/~wb/hoare.txt

<comment><USER2> The real horror is how much thicker the C++ standard is than any of the thick documents mentioned in the speech. If people like Knuth, Hoare, etc. were working towards a dream where programming has the rigor of physics, the modern situation is more akin to alchemy.

</comment><comment><USER3> I like the other half of the statement "obviously no deficiencies".</comment>


Released mobile framework ChocolateChip-UI for iOS, Android and Windows Phone - <AUTHOR> http://techcrunch.com/2013/08/29/sourcebits-launches-an-overhauled-chocolate-chip-ui-a-cross-platform-mobile-framework-with-ios-7-ui-support/

<comment><AUTHOR> Hi all! I'm the developer behind ChUI and I'm here to answer any questions.

</comment><comment><USER2> It's super fast and fun to work with. Loving it

</comment><comment><USER3> Oh awesome implementation!</comment>


Are build tools making the web too complicated for beginners? - <AUTHOR> https://www.youtube.com/watch?v=3i9WFgMuKHs

<comment><USER2> Yes and No.</comment>


Kevin Rose declares Reddit the winner - <AUTHOR> http://twitter.com/kevinrose/status/36916428607062016 <comment><USER2> Yes.. and with this, Kevin Rose's descent into douchebaggery is complete. Welcome to the dark side.

</comment><comment><USER3> Reddit has about 6 months before the digg spammers, and digtards turn reddit into a bruh-wasteland.

This is not good news at all. Is anyone building a digg/reddt alternative?

<comment><USER4> > Is anyone building a digg/reddt alternative?

You're soaking in it.</comment></comment>


'We feel really terrible,' says chief executive whose app roiled the Iowa caucus - <AUTHOR> https://www.latimes.com/business/story/2020-02-04/we-feel-really-terrible-says-chief-executive-whose-app-roiled-the-iowa-caucus <comment><USER2> Seriously curious, there were only 1,765 precincts.

Couldn't they just create a Google Forms link share it to the field people sending the results back? It would be only 1765 lines in a Google Sheets doc, and would be practically free. (Not to mention more secure than a custom implementation by semi-incapable development contractors like in this case.)

<comment><USER3> They legitimately wanted more security than that, with two-factor and other similar systems to prevent hostile actors inserting bad data.

<comment><USER4> Google probably does 2 factor better than $smallapp. I'd probably take more than 1 form per report though (I think that falls under "similar systems" stuff you mentioned).

<comment><USER5> Although a little kludgey, it does cross of the boxes:

\- Only allow one entry per GSuite ID in Google Forms

\- Enforce yubikey 2FA on GSuite.

\- Issue each captain a Pixel 1 with Google MDM for remote wiping and app deployment.

\- Turn off all other apps (Docs, Fi, Photos, etc...) in GSuite.

<comment><USER6> Wouldn't all of this be more elegant using Graphql?

<comment><USER7> Are you serious or making a joke? Not saying it can't be serious. But it might be a joke. I can't tell anymore.

<comment><USER8> If that's not a joke I'm quitting this industry and becoming a carpenter

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Just saw this article from ProPublica [1] that basically implies they sent all the data over http instead of https.

So much for "improved security"

[1] [https://www.propublica.org/article/the-iowa-caucuses-app- had...](https://www.propublica.org/article/the-iowa-caucuses-app-had-another- problem-it-could-have-been-hacked)

</comment><comment><USER10> CEO claims the "The app was sound and good" but there was a "transmission bug" in the code...

Other way to say it, if you don't count the mistakes - then the app is excellent.

<comment><USER11> "Other than that, how was the play, Mrs. Lincoln?"

</comment></comment><comment><USER12> I remember hearing on NPR how annoyed people were with the DNC's lack of transparency on this app, and their reasoning was "we don't want to let the Russian hackers know how we're doing this".

The more this saga continues the more the democrat gang seems like a troop of out of touch hippie professors recruiting freshman to do their "technology" work.

<comment><USER13> Or, few rungs up the ladder, it's a convenient way to get in Sanders' way while claiming incompetence!

</comment></comment><comment><USER14> From the article here - [https://www.bostonherald.com/2020/02/04/companies- behind-iow...](https://www.bostonherald.com/2020/02/04/companies-behind-iowa- caucuses-app-failure-had-ties-to-hillary-clinton-pete-buttigieg-campaigns/)

Shadow Inc. — the tech company behind the app — launched in 2019 with backing from political nonprofit ACRONYM, according to a statement from the nonprofit.

ACRONYM founder and CEO Tara McGowan, a Newport, R.I., native, said on Twitter that Shadow is "an independent company ACRONYM invested in.

McGowan, who lists herself as a former journalist, married then-Hillary Clinton campaign staffer and current Buttigeig strategist Michael Halle in 2015, according to a Providence Journal marriage announcement and Halle's Twitter account.

Not at all suspicious !

<comment><USER15> It's not really. That's how most software projects happen. "We need XYZ app/site/solution? Hm...I worked with these guys back in 2016 and they did good work. I'll make an introduction...."

<comment><USER16> But that first step, "we need xyz"... they didn't.

<comment><USER17> Also "they did good work" can't possibly be true, since Clinton 2016 was a bad campaign, with bad data, that lost.

<comment><USER18> Your logic is there can be no individual person who did good work on the campaign, if the overall campaign was bad?

<comment><USER17> We're talking about the person who _led_ the software and data efforts for Clinton in 2016. Clinton's data was bad and misleading and stale, which contributed to the candidate taking victory tours a week before losing four states the campaign thought they would easily win. Yes, I think every high- ranking official of that campaign should be unemployable in the same field.

<comment><USER18> Gotcha, fair enough

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> I really don't see a lot of accountability in any of his statements. It just seems like "well this thing went wrong, somehow, and its nobodies fault and hey nothing was lost". I find that to be absolutely abhorrant. Think about if you're one of their junior developers - you'd probably be blaming yourself for whatever bug that happened to get in. That the CEO wouldn't take any responsibility is a complete lack of leadership.

To those devs, jr or otherwise - every step that was supposed to protect against a failure in the app seems to have failed here, and you should not feel bad. Mistakes happen and should be expected, but the damage that they are allowed to wreck is the blame of poor management, not you.

<comment><USER2> Every single executive in this little software company used to work at Clinton's 2016 campaign [1] so they have political connections.

Not to mention, political parties aren't transparently run in many cases like we've seen in 2016 Democratic National Committee email leak. Most likely, these people are feeding off of their political connections and harvesting donation money from not just the party, but also the candidates [2].

This is also why I'm no longer donating to a political party directly, or a candidate who would in turn would do the same. It seems like the only independent candidate running under democratic party is keeping his campaign money in-house.

[1] [https://www.crn.com/slide-shows/applications-os/who-is- shado...](https://www.crn.com/slide-shows/applications-os/who-is-shadow-inc- the-company-behind-the-iowa-caucus-voting-app-/2)

[2] [https://twitter.com/BustinTrudeau/status/1224697566182498306](https://twitter.com/BustinTrudeau/status/1224697566182498306)

<comment><USER20> These developers also developed Buttigieg's campaign software and Buttigieg donated to help develop the caucus app.

<comment><USER21> No COI to see here, folks.

Why isn't the DNC harder on crap like this?

<comment><USER22> >Why isn't the DNC harder on crap like this?

Well, for starters, because the DNC doesn't run the Iowa caucus.

<comment> munk-a The DNC doesn't directly run the caucus, but the DNC (or maybe, more precisely, the democratic party) chooses to accept the results of the Iowa caucus and subsidizes (or entirely funds) the running of the caucus.

Additionally, the Iowa dem caucus (and primaries) aren't a governmental thing, the political parties aren't government organizations - they're private organizations that are just _all about the government and politics_ as such the Iowa caucus is really weirdly in a grey zone where there is even less necessary oversight than the administration of the general election in Iowa will have - but sort of more oversight since the DNC could just reject the results outright... Buuuut things like the voting rights act have forced some regulations into primary operation - it's all quite confusing...

The TL;DR though is that the DNC doesn't technically run the Iowa caucus but is more than capable of making the Iowa dem caucus committee feel a whole lot of pain and hold them accountable.

</comment></comment></comment></comment></comment></comment><comment> munk-a > Niemira also confirmed Acronym's role as majority investor in Shadow but > declined to name the company's other investors. He also declined to name the > members of Shadow's board of directors.

Hey guys, you done messed up - no more lack of disclosure. Your company will probably be dissolved due to this hilariously well publicized failure.

> The company's mission is to help advance Democratic causes and candidates, > and its employees were excited to have an important role in Iowa's historic > presidential caucus.

That sounds noble and all, but also pretty silly - how was your solution ever going to help "advance Democratic causes and candidates" purely by serving as a drop-box for everyone to upload voter tallies to. The employees at your company can feel excited to be working to support the DNC - but it's really a stretch to claim that your vote tallying solution was advancing Democratic causes. It's like claiming, as a car manufacturer, that you're excited to help advance the cause of addressing back problems because some of the people who might buy your car end up driving to staples and buying a new office chair.

</comment><comment><USER23> i love a smug, passive-aggressive apology. just OWN up to it, acknowledge the implications of the issue you caused and provide an actual apology. unreal.

"I'm really disappointed that some of our technology created an issue that made the caucus difficult," said Gerard Niemira, chief executive of political technology company Shadow Inc., in his first interview after the caucus. "We feel really terrible about that."

<comment><USER24> > just OWN up to it

That's how you end up getting sued.

<comment><USER25> Its not like they can avoid being sued by not doing this. It just changes the cost point to be sued successfully, and actually denying impact and consequence probably increases their burden. Owning up, being sued but showing contrition has an upside.

</comment></comment></comment><comment><USER26> > The problem was caused by a bug in the code that transmits results data into > the state party's data warehouse.

The amount of data we're talking about here would fit comfortably in an Excel spreadsheet. Why on Earth was there a data warehouse involved at all?

<comment><USER6> From what I read on various articles linked in this thread and others, the votes were being checked against the warehouse (who knows where the warehouse is getting data, if that's the one true source, why even have this app). It failed to check against it properly (they were getting back an error). I guess election night was the first time they tested this validation phase , as they were not able to account for it and the app simply failed.

</comment></comment><comment><USER27> A typical non-apology. Making it sound like there were just minor subtle errors that they could never have foreseen and were caught off-guard by.

They were deploying an app to a very inexperienced user group, via developer certificate enterprise sandbox because they couldn't get the app done in time for App Store review and approval. They didn't do the requisite amount of live user testing and were sending out instructions up to 3pm on the day of voting.

They had a chance to evaluate whether they should take on this job and do it right or not. They could've advised and warned the IDP that they were going to get in trouble.

But they thought they could handle it based on their past inconsequential apps. And they wanted the business and publicity of doing this job. They were wrong, and now playing it off like it was some minor mistake.

It wasn't. Just a typical story of overly confident people getting in over their heads, and now passing it off as no big deal when in fact it is a big deal. Maybe if such behavior was fined or penalized there would be a lesson learned...

</comment><comment><USER28> First line in their job application:

"Shadow is a technology company dedicated to building power within the progressive movement."

Can some things remain non political these days? What a weird sentiment.

Are we moving to a future where I need to check the political leanings of software providers before they can agree to do business with me? I'm looking for a professional to do a job, you can keep your politics at home...

<comment><USER29> They aren't progressive. So caring about the statement is pointless. North Korea's official name doesn't mean shit.

</comment></comment><comment><USER30> With all the furor around election tampering, why aren't there regulations around vote counting hardware/software?

Is the CMM still a thing?

[https://en.wikipedia.org/wiki/Capability_Maturity_Model](https://en.wikipedia.org/wiki/Capability_Maturity_Model)

"The CMM was originally intended as a tool to evaluate the ability of government contractors to perform a contracted software project."

For something as important as _elections_ , developers (organizations) should be required to adhere to CMM 5 and use a very tight waterfall + TDD practices. Further, the product and testing requirements should be public. Not this shadow development crap.

<comment><USER31> the dnc and associated state organizations are not government organizations and there are no rules or regulations on whatever processes they use to select a candidate for the presidential election. they can literally do whatever the hell they want.

for that matter there is no (federal level) law or regulation requiring a public vote for the president at all. the constitution establishes the electoral college but the methods by which electors are chosen and vote are left to the state themselves.

</comment></comment><comment><USER32> Basically someone didn't do the load testing before prod release.

<comment><USER33> That's what I thought originally, but there really shouldn't have been much load (ignoring the load of downloading the app to begin with). There were fewer than 2000 precincts, and each precinct had to upload around 100 bytes of data. That shouldn't have been hard.

One news story I read quoted an error message about a "missing protocol." I believe that the "coding error" was really a configuration error: somebody forgot to include [https://](https://) in the web service URL. The app recorded the data, but couldn't upload it.

Load testing would have found this, but so would a single integration test/smoke test.

<comment><USER6> My thinking is they simply didn't do any dry runs with possible simulated data (bad data, malformed data, partial data), they didn't consider all the ways things can go wrong in real time. This is less about load testing but more about exception handling/fallbacks.

<comment><USER33> I definitely agree with you there.

</comment></comment></comment></comment><comment><USER34> > the app was sound and good, the problem was a transmission code ...

This guy doesn't know what he's talking about is he? Is this same person who wondered why he could copy the google frontend and it would look literally the same? What use is a browser with faulty internet 'transmission code'

<comment><USER6> Yeah, like what does that mean? Their post requests had bad data from the frontend? How were they validating what they were sending?

</comment></comment><comment><USER35> Most comments here seem to be about "what Shadow should have done", making it obvious, given the distribution of HN users, that Shadow really should have used a different systems approach. But I'd like to focus on a different aspect: they used the systems approach that they did (given budget and deadline), and the outcome was poor. Is it difficult, using their approach, to accomplish what they accomplished? Seems like a single function call is the likely culprit. What exactly caused this... A race condition, database sharding? What's the cause of this issue, at a technical level?

</comment><comment><USER36> Election software made by Shadow, inc. No joke

</comment><comment><USER37> Does anyone have the source code or packages for the apps? I think the HN community could have a field day with this!

<comment><USER38> Not open source ==> not auditable

<comment><USER37> Here's the React Native JS Code: [https://raw.githubusercontent.com/jfbguy/iowa-caucus-app- dec...](https://raw.githubusercontent.com/jfbguy/iowa-caucus-app- decompiled/master/resources/assets/index.android.bundle)

We still need the index.android.bundle.map to faithfully deminify and audit.

<comment><USER37> Shadow team, if you're in the shadows, please come into the light and post this file for us!

</comment></comment></comment></comment><comment><USER39> What a den of incompetence, thanks DNC. Trying to rig Iowa and failed so badly is laughable.

</comment><comment><USER40> But not terrible enough to issue a refund for the taxpayers.

</comment><comment><USER36> Made by shadow, inc. No joke

</comment><comment><USER17> This guy is quoted in Vice magazine throwing shade on Vertica, a database written by a Turing Award recipient and used in many demanding roles. Then he hired some Starbucks prep cooks (literally, check LinkedIn) with no education and no industry experience and created a disaster. These events should replace whatever is currently in the literature as an example of the consequences of the Dunning-Kruger effect.

<comment><USER41> I really don't think its okay to be criticizing the job history of people. Everyone did something before they were a developer. You used to shit yourself daily, but we don't bring it up during code review. So i don't see how a previous position that lead towards being a developer is grounds for derogatory commentary.

<comment><USER42> It's Ok to have new / inexperienced devs on the team. In fact it's good for the industry to bring them in.

The problems come about when there are _nothing but_ inexperienced devs on the team.

</comment></comment></comment><comment><USER43> If someone with mod powers sees this (or OP), the title has a typo in it. It's intended to be "says CEO whose app roiled Iowa", not "rolled Iowa."

<comment><USER44> To "roll" is to mug or to rob someone. Seems fitting?

<comment><USER45> Agreed, I thought it was an intentional backhanded comment to the CEO.

<comment><AUTHOR> A funny typo and one I wouldn't mind leaving too much, but I fixed it. :)</comment></comment></comment></comment>


Show HN: I've made Bootstrap builder for developers to speed up their workflow - <AUTHOR> https://www.gridbox.io <comment><USER2> Yearly toggle, in pricing, looks like it isn't sitting right.</comment>


MIT Cold Fusion IAP 2014 - <AUTHOR> https://www.youtube.com/user/ColdFusionNow

<comment><USER2> First slide made me chuckle:

Warning:

Working in this field at this time can destroy your career.

Being interested may be damaging to your personal and professional life.</comment>


Ask HN: Which media do you use to disconnect while staying informed (slow news)? - <AUTHOR> Hi there,
I am getting really really tired of checking my news apps or emails every few hours. It is pointless.
I want to find a way to disconnect while staying informed of the most important news. I heard about the slow news movement but cannot really find something that fits my needs.
Do you know any media that help you stay informed in a more sustainable way? My ideal would be a short (readable in 1 hour or so) weekly newspaper (physical if possible) that would present facts and (various) opinions about the 3 to 5 most important news of the week. If it is not focused on 1 country it is even better. Does this even exist?
Thanks a ton in advance! <comment><USER2> I can recommend The Economist (if you are willing/able to pay). Top-notch succinct writing, an audio version and a wide selection of articles. I always thought that it focuses too much on politics (which does not interest me that much), but every issue has still plenty of articles that I find compelling.

Another benefit of paying for what you read: you feel obligated to use that source instead of mindlessly browse online

<comment><USER3> Came here to post this. I swapped my daily news reading habit for an Economist subscription (paper only) and have not looked back. The first 1-2 pages will typically summarise the week's news well enough for me not to feel like I've missed out on anything, and the quality of writing and variety of interesting topics is excellent. I also agree with your second point about feeling obligated to read it!

Edit: for some humorous and UK-specific news/investigative journalism/cynicism I can also highly recommend a subscription to the fortnightly Private Eye. It works out at like £1 per copy and is always a fun read.

</comment></comment><comment><USER4> A weekly physical newspaper is simply a [https://en.wikipedia.org/wiki/News_magazine#Notable_print_ne...](https://en.wikipedia.org/wiki/News_magazine#Notable_print_news_magazines) and broadly available from newsagents and often supermarkets, or am I missing something?

</comment><comment><USER5> [https://www.slow-journalism.com/blog](https://www.slow-journalism.com/blog) may be a little too slow for you

</comment><comment><USER6> I doubt if there is any physical newspaper doing it. I would suggest shortlisting 2-3 monthly magazines based on your interest and I believe that will do the job.</comment>


More New Mozilla Technologies - <AUTHOR> https://davidwalsh.name/mozilla-projects <comment><USER2> I love pdf.js. A lot of people complained about it when it was being developed, but it is such a simple pdf drop-in for node.js app-developers, web developers and everybody else on a javascript enabled platform.

I just wish they included it on Firefox for Android!

</comment><comment><USER3> The thing is Mozilla is all about Chrome technology, Chrome parity and Chrome design.

Everything they care about is Google and Chrome. I miss the times where Mozilla was able to think on their own and was no follower and admirer of a dangerous and utterly greedy and disgusting tracking company called Google!

As long as they are following that path which leads more and more away from users with knowledge to users who use Chrome, Mozilla's downfall will continue.

It should be more than clear now, that Mozilla's big hope that users of Google Chrome will fill the void which is ripped open by advanced, power, geek users leaving, is not becoming a reality.

Mozilla can invent whatever they want, but as long as they do not remove the core issue - their new found ideology that only being like the competition will lead forwards - things will go more downhill.

I wonder if Mozilla can be saved.

</comment><comment><USER4> I have been using FF for many years, recently it locked up my ubuntu 12.04 and 16.04 a few times really badly(used all memory and swap space before OOM kicks in, rendered the machine totally unusable for 10~30 minutes, I always ended up cold-boot it). Two weeks ago I decided to switch to Chrome, so far so good.

While I love FF and hope it gets stronger, its market share is sadly dropping sharply, I recently read it's about 10% of the market share? That's a red flag considering Mozilla does not have the deep pocket to compete with Chrome and the awakening IE, and Safari.

The future does not look rosy for FF I am afraid.

</comment><comment><USER5> So, I might have a use for Tofino in the future, so I figured I would google it to see how hard it would be for me to find in the future.

"mozilla javascript browser project" and variations don't seem to find anything. Most come up with [https://developer.mozilla.org/en- US/docs/Mozilla/Projects](https://developer.mozilla.org/en- US/docs/Mozilla/Projects), which doesn't list it for some reason.

Even searching for "mozilla technologies" doesn't find it (except for articles about new technologies in general, including this article), and it's not on [https://developer.mozilla.org/en- US/docs/Mozilla/Tech](https://developer.mozilla.org/en-US/docs/Mozilla/Tech).

If I search for "mozilla tofino" I'm not finding any links to mozilla.org. Even restricting the search to mozilla's site only comes up with themes, addons and mailing list entries.

Any clue on why this project is so hard to identify with Mozilla?

<comment><USER6> It's probably just because it's new. Here's their blog: [https://medium.com/project-tofino](https://medium.com/project-tofino)

I'd also recommend looking at browser.html and Servo: [https://github.com/browserhtml/browserhtml](https://github.com/browserhtml/browserhtml)

</comment></comment><comment><USER7> A browser built with Node.js? And people think rewriting Firefox in Rust would be a waste of development resources.

<comment><USER8> It's node.js + electron; they're not rewriting the HTML renderer (which is Chromium-based).

It's intended as a prototyping platform, where they can quickly build UI experiments using only HTML + JS (and React).

<comment><USER9> Électron ? So it's a Chrome based Mozilla project ?

<comment><USER10> More less, but it's only for prototyping.

As far as I understand they wanted to focus on UX and use whatever works for everything elese.

<comment><USER9> Thanks the ux part wasn't very clear in the article</comment></comment></comment></comment></comment>


Show HN: Pushcut API – Smart Notifications for DIY Makers - <AUTHOR> https://www.pushcut.io/webapi.html <comment><AUTHOR> To the makers, hackers, and DIY enthusiasts like me: I just released the brand new __Pushcut API __!

My intention is to offer everything that is needed to integrate Pushcut to any DIY automation system you might have.

Check out the [documentation here]([https://www.pushcut.io/webapi.html](https://www.pushcut.io/webapi.html)). <\- You can even play around with the API through the web UI, which is pretty cool I think ; )

The primary use is of course to send smart notifications with dynamic content and automation actions to your iOS devices.

However, I think the coolest part is the possibility to register you own (local network) webhooks as "online actions" in Pushcut.

This way you can trigger anything in your local automation system - <USER2> from the notification action - on your local network.

My hope is that over time there will be more and more "plug-and-play" integrations for all various DIY solutions out there (openHAB, Hass io, Node- RED, webCoRE, ...)

Let me know if you are interested in collaborating on an integration, or if you want to request additions to the API.

Also, which automation system would you like to see a Pushcut integration for?</comment>