Assessing Russian Activities and Intentions in Recent US Elections [pdf] - <AUTHOR> https://www.dni.gov/files/documents/ICA_2017_01.pdf <comment><USER2> Dear lord a dozen countries could use this style of "evidence" to support the notion that the BBC(British Broadcasting) is deeply involved in nefarious election influencing. I believe in freedom of speech including Russia's ability to talk and influence. All the evidence not directly related to hacking is just completely inappropriate. This "proof" doesn't help their case against Russia. They should be focusing a narrow remit on the like's of Gucifier and Wikileaks. What a mess.

<comment><USER3> As a kid growing up through the 1978-79 Iranian revolution, I can tell you BBC played a crucial role. We use to gather an listen to Farsi BBC broadcast in short-wave radio. That experience has made me to be distrustful of any major media outlet.

<comment><USER4> I remember it. They used to announce demonstration schedules. And the line from the Foreign Office was "BBC is independent". What a crock of shit. And the New York Times was calling the Ayatollah Khomeini a "saint". (Let that sink in.)

[https://sadbastards.wordpress.com/2013/08/08/khomeini-was- pr...](https://sadbastards.wordpress.com/2013/08/08/khomeini-was-praised-as-a- moderate-by-the-new-york-times/)

RT is clearly a propaganda organ and Russians are old hands at propaganda. That much is clear. But the germinal issue, the elephant in the room, is that corporate media in our nation serves such a thin gruel of "news" that outfits like RT or (earlier) Al-Jazeera gain a foothold and establish "credibility" simply by publishing what our media refuses to cover. Didn't they get the memo that we have thing called the internet these days and other sources are a click away?

The biggest nugget in this report, imo, is that NSA is not so hot about this assessment. Which reminds me, did the former CIA employee cum whistle blower dish out CIA's dirty secrets as well or did he just dump on the NSA?

<comment><USER5> Well then, the issue is to establish good journalistic sources, which publish the important stories, while remaining independent of propaganda motivations, including corporate ones.

How do we do that?

<comment><USER6> Thank you for asking the right questions!

This should be it's own topic. Can you run an "Ask HN"?

My thought would be an information system that is jointly published in by all nation states - like a broadcast Wikipedia. The idea is that out of the chaos in the reporting the facts that every nation agrees on will get through clearly, whereas the opinions, unfounded accusations and the rest will bury themselves in a quagmire of costly effort.

<comment><USER7> Yeah that's gonna run about as effectively as the UN, which is to say barely at all. I do have a scheme I'm developing for this problem but I'm not sure how practical it is.

<comment><USER5> Go ahead and contact me personally. We _need_ to do something about this, and if algorithms can, algorithms must.

<comment><USER4> Train it on this - a great resource: [http://www.gdeltproject.org/](http://www.gdeltproject.org/)

I remain skeptical that merely flagging individual content as 'probable disminformation' will the address issue.

Propaganda is, at its core, a form of _psychological manipulation_. It doesn't necessarily have to involve overt lies. Omission of facts, tone, phrasing and choice of words, etc. are all effective tools.

There are _patterns_ to propaganda. /That/ is their achilles heel.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> The report seems to present lots of conclusions to controversial issues (like the hacking) but it provides zero evidence for these conclusions.

The little that's backed up by evidence in there is Russia's public propaganda efforts, like Russia Today, which aren't really anything new (though certainly interesting).

What's controversial is the hacking and I haven't seen anything that attributes the hacks to Russia beyond reasonable doubt. If the evidence was taken to a US court and put before a judge and jury, I don't believe a prosecutor could get a conviction.

I understand that the US wouldn't want to give up its intelligence sources but I also don't think that the people of the US should let the government make foreign policy decisions based on hidden evidence. That's how Iraq happened.

<comment><USER9> Isn't that how most foreign policy works? The WoMD fiasco was a problem for sure, but the solution to that is to elect officials we can trust. When the White House says the CIA has come to them with evidence that must be acted on, the White House can't turn to the populous and ask if there is enough evidence to act. They need to have the autonomy to act as they see fit.

<comment><USER8> > Isn't that how most foreign policy works?

It's how foreign policy has worked in the past but I think it's demonstrated that it's not how foreign policy should work in the future.

> the solution to that is to elect officials we can trust.

That seems incredibly unlikely to happen. US elections seem to be mostly decided by who has the most political capital and media support rather than trustworthiness or merit.

> When the White House says the CIA has come to them with evidence that must > be acted on, the White House can't turn to the populous and ask if there is > enough evidence to act. They need to have the autonomy to act as they see > fit.

I'd agree that this is the case but I don't think that the agencies themselves can be trusted anymore. The head of the NSA told a blatant lie in front of Congress and worse, got away with it. There's no accountability anymore so I don't think trust is wise.

I think the US as a country can only function when the people trust the government, the government respects the people and the people within the government trust and respect each other. None of these things are currently the case and I suspect things are only going to get worse. What that will cause I have no idea.

</comment></comment></comment><comment><USER10> Unfortunately there isn't any new evidence here.

First, there's no doubt that RT is Russian propaganda. That's not news, and I'm unsure why it's in this kind of report. Paid russian internet trolls is an old accusation too. I think it's probably true but I don't see any concrete evidence in this report.

The real question here centers on the emails: did some Russian intelligence agency leak the DNC emails to wikileaks? The report asserts that this occurred, but again offers no concrete evidence. Instead it focuses on establishing motive.

We do have concrete evidence (published by crowdstrike) that Russian intel hacked the DNC. But we don't have concrete evidence linking the leaked emails to that hack.

I'm trying to remain objective here. I don't think it's unlikely that Russian intelligence was the source of the emails. I just don't see anything new here to conclusively prove that assertion.

Maybe I'm being too picky about what constitutes concrete evidence.

<comment><USER11> This report provides conclusions, not raw data.

If you are being honest with your comment, then you are unwittingly committing several logical fallacies:

\- burden of proof: demanding confidential information that will never be provided ensures you will never receive "proof"

\- moving the goalposts: this report includes several new analyses, but by moving the goalposts it will never be "enough"

\- straw man: the issue is not restricted to DNC emails; at a minimum it includes manipulation of US social media platforms.

<comment><USER10> Respectfully, I don't think I'm committing any of those fallacies.

-The idea that some information is classified and some isn't is silly. There's just information that you're willing to divulge and information you're unwilling to divulge. I see no reason to assume evidence that would implicate Russia must be so sensitive that the government would never divulge it.

-I'm not moving any goalposts. There's only one piece of this puzzle I'm interested in: evidence linking Russia to the leaked emails. I accept that Russia has a broad propaganda network that often attempts to undermine US interests. I don't see that as an extraordinary thing.

-See above. I accept the astonishing amount of propaganda. But the emails are the key piece here, and there's no concrete information in this report.

I don't dismiss the DNI's claims, I just don't see the extraordinary evidence generally required for extraordinary claims.

<comment><USER11> Thanks for your reply - I'm not accusing you of malice.

I would love to see more of their raw data. I research social media and I have specifically investigated 2016 US election memes, so those data are extremely interesting to me. However, the DNI PDF states:

> This report is a declassified version of a highly classified assessment; its > conclusions are identical to those in the highly classified assessment but > this version does not include the full supporting information on key > elements of the influence campaign.

So, irrespective of yours or my assessment of what the raw evidence might be like, DNI already stated that they think it's too sensitive. This probably isn't going to change for 10-20 years (which is a common lifespan for classified information) so you've just got to figure out a way to analyze this situation without the specific evidence used to create this report. It doesn't mean there isn't other evidence out there. Like I said: I research social media and I have my own evidence stack. Some of it is here:

[https://iandennismiller.github.io/election- memes/](https://iandennismiller.github.io/election-memes/)

I am considering the events of the past 2 months as "moving the goalposts" \- and this isn't a personal thing against you or any individual. Originally, we had statements from certain officials, but that wasn't enough. Then we had consensus among intelligence agencies, but again that's not enough. Then we had a statement from the president, but that's not enough. Now we have this report and it's still not enough.

On the straw man, the emails are not the entirety of the DNI argument, so reducing it to that creates the straw man, and dismissing the whole report on the basis of the emails is just how the straw man fallacy works, in practice. I am focused on social media, but you're focused on emails. It's okay to care more about one thing than another, but it is a logical fallacy to dismiss the rest of the report because you're not satisfied with the part you care about.

Lastly, I don't think it's extraordinary at all to claim that Russian intelligence managed hundreds of sock puppet accounts across Reddit, Facebook, Instagram, Imgur, Twitter, and other platforms. In fact, I would be shocked to learn that the opposite was true. In fact, none of the claims in the report are extraordinary; it's all extremely plausible.

My (sortof expert) opinion is that I think the DNI social media conclusions are plausible.

<comment><USER12> > Lastly, I don't think it's extraordinary at all to claim that Russian > intelligence managed hundreds of sock puppet accounts across Reddit, > Facebook, Instagram, Imgur, Twitter, and other platforms. In fact, I would > be shocked to learn that the opposite was true. In fact, none of the claims > in the report are extraordinary; it's all extremely plausible.

Perfectly agreed. The United States and China also have these sock puppets, as do other countries. I think this is one of the reasons why people get into a tiffy whenever I insist on working with the facts and not US propaganda and rumors. Get accused of being a shill for Greece, Turkey, Russia, China, etc all the time.

Social media is swarming with sockpuppets, and now the game has escalated more, with H.R. 5181 passing in NDAA 2017, the Center for Global Engagement will be empowered to experiment with the techniques for social media propaganda developed by DARPA's SMISC program.

Don't know if the clock is moving toward midnight, or if just reddit is going to choke on itself.

<comment><USER11> > experiment with the techniques for social media propaganda developed by > DARPA's SMISC program.

Interesting. I hadn't heard of SMISC - thanks!

</comment></comment></comment></comment></comment></comment><comment><USER13> Gleen Greenwald from the Intercept has published some decent pieces on the lofty "evidence" for Russian hacking, his latest being:

[https://theintercept.com/2017/01/04/washpost-is-richly- rewar...](https://theintercept.com/2017/01/04/washpost-is-richly-rewarded-for- false-news-about-russia-threat-while-public-is-deceived/)

<comment><USER14> Glenn Greenwald has already stated his opinion on this report: [https://twitter.com/ggreenwald/status/817479125707399168](https://twitter.com/ggreenwald/status/817479125707399168)

<comment><USER15> You can always tell those who have little to contribute when they fall back on the "there is no evidence" line. It's a declassified report. The sources and methods that the US intelligence community uses is never going to be made public nor does anyone reasonably expect it to be.

So instead of complaining about evidence. Assume that the Obama administration is not trying to make their last big story before leaving a lie and refute the motives etc.

<comment><USER13> Show me evidence of your claims suddenly isn't a reasonable ask in the face of an accusation? Don't complain about lack-of-evidence, just put your trust blindly in someone. This argument feels quite weak.

</comment></comment></comment></comment><comment><USER16> I think a legitimate public service was served by the release of Podesta and DNC emails. We wouldn't have known about DNC's stacking the decks against Sanders otherwise. I wonder why all the liberal outrage hardly address this point.

<comment> brown9-2 because only one party had their inner communications released

<comment><USER17> I bet Trump supporters are happy nothing bad about Trump was leaked and no foreign news networks ran ant hit pieces on Trump. He probably would have lost if that had happen.

/s

Besides for the illegal action of actually doing the hack, I don't see how this is any different than all the news stories attacking Trump.

</comment></comment></comment><comment><USER18> So the extent of it is, Putin told Russia Today to bias their news in favour of Trump? I don't care for Trump (or US politics, for that matter), but this has gone so far into the realm of pettiness I cannot even believe what I am reading.

<comment><USER19> That's not at all what the report says, of course.

</comment></comment><comment><USER11> > Moscow's influence campaign followed a Russian messaging strategy that > blends covert intelligence operations—such as cyber activity—with overt > efforts by Russian Government agencies, state-funded media, third-party > intermediaries, and paid social media users or "trolls."

I think social media have been undermined for some time, although previously it was aggressive advertisers who were the culprits. "Astroturfing" is an old word by now. During the US election, this was simply taken to another level, and in a way that had a measurable impact on people's beliefs.

<comment><USER20> Also, it's a well known fact Clinton paid "trolls" to change opinions online.

Isn't that "influencing the election" as well? The U.S. needs so many new laws and changes to make its elections more fair (including media regulations during electoral campaigns), I wouldn't even know where to start.

<comment><USER21> Can you cite something to show that it is well known? I do not know this.

<comment><USER22> [https://en.wikipedia.org/wiki/Correct_the_Record](https://en.wikipedia.org/wiki/Correct_the_Record)

[http://www.factcheck.org/2016/01/correct-the- record/](http://www.factcheck.org/2016/01/correct-the-record/)

[http://web.archive.org/web/20160421163946/http://correctreco...](http://web.archive.org/web/20160421163946/http://correctrecord.org/barrier- breakers-2016-a-project-of-correct-the-record/)

[http://www.latimes.com/politics/la-na-clinton-digital- trolli...](http://www.latimes.com/politics/la-na-clinton-digital- trolling-20160506-snap-htmlstory.html)

edit: Insufficiently neutral sources?

<comment><USER21> Thanks! It's still a stretch to say that "Clinton paid trolls" since PACs (hybrid-PACs?) offer a layer of indirection.

<comment><USER23> How is it a stretch? They were clearly and obviously working for Clinton.

<comment><USER21> "working for" as in aligning their cause, but not necessarily "working for" as in being paid by.

There's no indication that Clinton gave them money, is there?

<comment><USER23> You can't be serious.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER24> A lot of this report is about RT - Russia Today - the English language TV channel run by the Russian government.

How is this different than "Voice of America" or the BBC for that matter; those media give a lot of space to political opposition in places like China or Russia.

Sure RT have an opinion and a bias wrt. US politics; but it is not like the people watching would be in any doubt that this channel was sponsered by Russia and had "an Russian perspective" on things.

<comment><USER20> Ironically, the U.S. will now fund a "counter-propaganda" agency to do more of this, too (I imagine with a more domestic focus).

[http://www.counterpunch.org/2016/12/29/obamas-christmas- gift...](http://www.counterpunch.org/2016/12/29/obamas-christmas-gift-to- trump-a-ministry-of-truth/)

[http://www.portman.senate.gov/public/index.cfm/press- release...](http://www.portman.senate.gov/public/index.cfm/press- releases?ID=F973E46B-AA8C-4F3E-91B4-8EC0FC7F2F3E)

<comment><USER21> Well of course. Nobody likes asymmetrical warfare.

</comment></comment></comment><comment><USER25> page 21. It was definitely eye opening to see the quantitative graphs showing how much Russian funded RT media's youtube views stacked up vs the major new media. RT's subscriber base was similar and it's social media footprint was much smaller but it's views were so much higher.

Were they gaming Youtube? Did the major news media decide not to engage and invest in their youtube content? Red Herring?

<comment><USER26> There's quite a few Russian accounts on Youtube with suspicious views counts. Like the guy who cuts things in half with his glowing knife. Lots of Russian spam and click-bait content too. Type in something about Ukraine, Russia or NATO and scroll through all the Russian 'WW3 Illuminati' garbage that comes up.

</comment></comment><comment><USER21> "ProKremlin bloggers had prepared a Twitter campaign, #DemocracyRIP, on election night in anticipation of Secretary Clinton's victory,judging from their social media activity."

<comment><USER27> thats proof right there they didn't think their methods were going to work, so maybe they didn't intend to "hack" the election in the first place ?

<comment><USER28> So if I make backup plans, I don't think there's any chance of my primary plan working? Don't be absurd.

</comment></comment></comment><comment><USER29> After watching HyperNormalization 2016, what the Russians probably sook to accomplish has already been, a large fraction of the population is already doubtful of the system as we have it.

Reminds me of this[0]

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

</comment><comment><USER30> Why was this discussion removed from the front page? Seems like relevant news of interest to a tech audience to me.

<comment><USER11> I hope it will be un-removed. This report is important.

</comment></comment><comment><USER21> I really feel like it's harder to know what to believe and who to trust than I remember it ever being.

Are there any good resources about how to vet truth in whitewash propaganda situations?

<comment><USER31> This.

My go-to is wikipedia, which isn't perfect, but when you want to answer something like "How much foreign cyber-warfare has America participated in?" and get just the raw data you can trust it to not have an agenda.

<comment><USER32> Raw data itself can be biased by the selection of which raw data to present. That is why in court, one swears to tell the _whole_ truth.

<comment><USER31> Well then you are free to edit wikipedia, add new information if you have objective sources.

</comment></comment></comment></comment><comment><USER31> My feelings on this issue are complex. Though I had previously been vocally skeptical about attributing hacking to Russia, I'm a little more middle-of- the-road now.

It's inconsistent for a foreign government expressing opinion on American politics to be called "propaganda" while we allow corporations to spend any amount of money trying to change peoples opinions via super-pacs. The line between propaganda and political dissent is very blurry.

I suppose I'd say Russia didn't do anything "wrong," (after all Americans foreign interventions are much more heavy-handed than anything described here), but I do now think it's likely Russia did want Trump to win and that Russia would potentially use more advanced meddling techniques if it thought it could get away with it.

</comment><comment><USER33> Well.... did they say anything untrue?

Our media stations are propaganda outlets as well. I get my 'news' from many different propaganda sources because I've found that it is very easy to tell when they are outright lying so I can just ignore that, but typically they say something that is close to the truth. The thing is that there is so much truth out there so each propaganda outlet will tell some portion of the truth that fits their narrative the best. If you grab all these different portions of the truth you can begin to piece it all together and have the biggest piece of the truth possible.

<comment><USER23> If you listen to interviews with any politicians or intelligence officials it's pretty obvious that they are dancing around the truth and never answering any questions. This is a partisan hit job.

And I can't tell if the DNC is supposed to be a private or government entity. If you complain that they cheated and screwed over Bernie, people respond with "well it's a private organization, they can do what they want". But now it's a matter of "election rigging" and "national security" that they've supposedly been hacked.

And if the information released was true, who cares if it was a hack? If the information is true, which it appears to be, then it was a service to our country that it was released.

<comment><USER21> This report was commissioned with bipartisan support from congress. So, is it a "bipartisan hit job"?

<comment><USER23> "Partisan" is a more generic term. It's one set of groups going after another.

</comment></comment></comment></comment><comment><USER21> "We assess Moscow will apply lessons learned from its Putin-ordered campaign aimed at the US presidential election to future influence efforts worldwide, including against US allies and their election processes."

<comment><USER5> Well, honestly, it's not _that_ hard to avoid voting for Kremlin-backed candidates. Just avoid voting for authoritarian right-wing nationalists or supposedly far-left "radicals" who spurn international cooperation and cozy up to Russia, and you're set.

</comment></comment><comment><USER34> Looking at the charts in the report it's impressive and worrying at the same time to see that the media influence of RT is in the same league as BBC, despite nobody heard about RT just a few years ago, while BBC has existed for decades.

</comment><comment><USER35> Seems like this was erased from the frontpage? Any idea why?

</comment><comment><USER36> EXECUTIVE SUMMARY: Trump had RT and Fox News. Clinton had MSNBC, CNN, Politico, NY Times, Washington Post, and most other MSM.

</comment><comment><USER6> It would be interesting to hear the take from the other fourteen intelligence agencies. I thought they were going to be in the report?

</comment><comment><USER37> Can anybody say with a straight face that this is not a politically motivated report?

<comment><USER38> No. But this is an Ad Hominem fallacy.

<comment><USER39> When dudes be like "just trust us", and they've lied before, and they have obvious interests in lying again, no it ain't everybody's favorite fallacy.

</comment></comment></comment><comment><USER6> Interesting bits of analysis:

1\. "DHS assesses that the types of systems Russian actors targeted or compromised were not involved in vote tallying."

2\. "When it appeared to Moscow that Secretary Clinton was likely to win the election, the Russian influence campaign began to focus more on undermining her future presidency."

3\. "Russia's goals were to undermine public faith in the US democratic process, denigrate Secretary Clinton, and harm her electability and potential presidency."

4\. "Moscow also saw the election of Presidentelect Trump as a way to achieve an international counterterrorism coalition against the Islamic State in Iraq and the Levant (ISIL). "

5\. "Pro-Kremlin bloggers had prepared a Twitter campaign, #DemocracyRIP, on election night in anticipation of Secretary Clinton's victory, judging from their social media activity."

\-- Full stop -- Do they mean Americans who are "Pro-Kremlin" like many progressives and conservatives that are anti-war? Or do they mean paid/covert bloggers? It seems to me they mean Americans? In which case how is that in the report at all?

6\. "Disclosures through WikiLeaks did not contain any evident forgeries."

7\. "RT and Sputnik—another government-funded outlet producing pro-Kremlin radio and online content in a variety of languages for international audiences—consistently cast president-elect Trump as the target of unfair coverage from traditional US media outlets that they claimed were subservient to a corrupt political establishment. "

\-- I actually believe this to be true. I absolutely hate Trump and think he's a despicable man and unfit for the presidency. However, I thought that the media coverage of him was absolutely brutally skewed and over-the-top clearly politically aligned. Anyway I saw this kind of reporting across international media outlets and friends and family and other news media outlets in the US said the same thing.

8\. "RT America TV, a Kremlin-financed channel operated from within the United States, has substantially expanded its repertoire of programming that highlights criticism of alleged US shortcomings in democracy and civil liberties."

\-- I think these speak to me because American media will not cover civil rights abuses and curtailments in a non-apologetic fashion. It seems typical to me that state-propaganda criticizes their adversaries' civil liberty abuses, as the US does to Russia and China and as Russia and China do to the US.

The whole section on RT seemed to be completely off topic and distractionary. I only got half way through it.

I did not see any assessment that Podesta's emails were hacked by Russia or shared by Russia. I was hoping to see that because people keep grouping it into the DNC hacks.

</comment><comment><USER40> Dear lord, either Hacker News has a surprisingly large Trump-supporting crowd or it's part of the Russian social media campaign.

Keep sowing that uncertainty and doubt on a report that is backed by classified information. Do you want them to reveal the names and locations of all our spies and detail our sigint methods? The end of the report says what "High Confidence" means.

<comment><USER16> So we're to believe the government without any evidence? That's the classic case of argument from authority.

<comment><USER40> "the government" is made up of a shit ton of people. I don't think there's some grand conspiracy involving the intelligence agencies, the Obama administration, and even Republican Senators to make all this up.

<comment><USER22> You're right. There must be WMD in Iraq.

<comment><USER40> You're being intellectually dishonest. You have no way of knowing about correct reports that the intelligence community provides the military on a constant basis.

<comment><USER41> Intellectually dishonest? You're the one who started this comment chain with the false dichotomy that anyone asking for concrete evidence is either a Russian shill or Trump supporter.

</comment></comment></comment></comment></comment></comment><comment><USER12> And spied, infiltrated and disrupted emerging political groups (Tea Party, Occupy, BLM, etc) around the country with Federal Surveillance programs.

<comment><USER42> Creating new accounts to get around HN moderation is not allowed. We've banned this one.

We detached this comment from [https://news.ycombinator.com/item?id=13341032](https://news.ycombinator.com/item?id=13341032) and marked it off-topic.

</comment></comment><comment> FLUX-YOU [deleted]

<comment><USER43> >Russia conducted an "influence campaign" at least from the time that the race was only between Clinton and Trump, yet we only find out about it after the upset?

Other than the time the US government pointed the finger at Russia a month before the election?[1] It came up numerous times in the debates. Newsweek had an article about Russia's motives a few days before the election[2].

This is not something that is brand new, why are you acting like it is?

[1] [https://www.dhs.gov/news/2016/10/07/joint-statement- departme...](https://www.dhs.gov/news/2016/10/07/joint-statement-department- homeland-security-and-office-director-national)

[2] [http://www.newsweek.com/donald-trump-vladimir-putin- russia-h...](http://www.newsweek.com/donald-trump-vladimir-putin-russia- hillary-clinton-united-states-europe-516895)

<comment> FLUX-YOU I guess I hadn't followed as closely as I thought I had.

I'll delete this silly rant.

</comment></comment></comment><comment><USER44> A synonym of 'propaganda' is 'information'.

</comment><comment><USER45> "this document does not include the full supporting information, including specific intelligence on key elements of the influence campaign. "

tl;dr : More of 'trust us folks' because KGB, Soviet Union, Emails , Putin , Youtube page views.

<comment><USER21> Do you doubt that the conclusions are different in the Classified versions of the document?

<comment><USER45> Do you doubt that North Korea was behind sony hacks ? [1]

1\. [https://www.fbi.gov/news/pressrel/press-releases/update- on-s...](https://www.fbi.gov/news/pressrel/press-releases/update-on-sony- investigation) \- the FBI now has enough information to conclude that the North Korean government is responsible for these actions.

<comment><USER46> Are they now believed not to have been? As far as I can tell it's still just as open of a question now as it was then.

<comment><USER45> > it's still just as open of a question now as it was then.

that still makes the 'conclusion' wrong.

</comment></comment></comment></comment></comment><comment><USER16> What percentage of US electorate would change their voting preference by reading Russia Today?</comment>


Bootstrapping a Software Product - <AUTHOR> http://bootstrapping.sifterapp.com <comment><USER2> Great slides! I especially enjoyed the "great decisions"/"bad decisions" part, I catched myself currently doing some of the "bad decisions" - like focusing too much on short term ups and downs.

Can you share the PDF? The link on SpeakerDeck doesn't work.

<comment><AUTHOR> I'll followup with the SpeakerDeck folks. I expect they'll have it working soon. I think they got slammed a bit more than they expected, but they're throwing more resources at it now.

<comment><USER2> The PDF is hosted at Amazon S3, so server resources at SpeakerDeck shouldn't matter. The problem is the wrong permissions on the PDF.

[https://speakerd.s3.amazonaws.com/presentations/4e6a452f4932...](https://speakerd.s3.amazonaws.com/presentations/4e6a452f4932a400010002c0/Refresh2011.pdf)

<comment><AUTHOR> Gotcha. I passed it along. I'm sure they'll get it sorted soon. If you'd really like it now, shoot me an email, and I'll send it along. garrett at nextupdate dot com.

</comment></comment></comment></comment><comment><USER3> Great deck for those of us working toward a switch from a service model to a product model. It's rare that the lifestyle aspects (marriage, home, children) are covered in decks about startups or bootstrapping, but those are such HUGE considerations if you have (or want) a life outside of your work.

I'm not a Sifter user (different needs), but I've gleaned a lot of professional insight from your posts/interviews/presentations in the last few months. Thanks for sharing so openly.

</comment><comment><AUTHOR> Slides obviously miss a lot of context if you didn't attend the presentation, so I'd love to chat with folks or answer questions if anybody has them.

<comment><USER4> Would you mind saying a bit more about why you felt building your own billing system was a bad idea?

We're looking into that at the moment, and have been considering the usual options of DIY, using Recurly/Chargify/similar, going quick and dirty with Paypal/Google, etc. Right now, after a great deal of investigation and contacting many organisations for more details, we are overwhelmingly thinking that a simple, direct system with a payment gateway and merchant account is the way to go. None of the usual recurring billing suspects has even come close to justifying the costs and usually lock-in of integrating their service instead.

However, in the HN goldfish bowl, almost everyone seems to have a different view (though I have noticed a few dissenting voices creeping in recently). Right now, all we've done is a bit of prototyping with the test system for the service we're looking at using and a thorough read of the docs. If we're about to enter a world of pain when we actually want this stuff to work, it would be good to hear any advice about how to minimise the damage and make it through!

Great slides, BTW. Thanks for sharing.

<comment><AUTHOR> The main reason that I don't personally believe it's a good idea is that it's not a core part of Sifter. We use Braintree and process everything via ActiveMerchant, but we've been using Braintree so long that we're actually on their old API.

Obviously, since we built it in house, I don't have any hands on experience with the other options that are out there now, but from what I've seen with other applications, I can't see any reason not to use the other providers.

The downside to not building your own system is that you may lose some control over things like invoice formatting or other parts of the user experience.

The other aspect that's a big consideration is PCI compliance. We don't store any payment information on our servers, but it does pass through our servers which means we have to have the minimum amount of PCI compliance. By offloading it to another provider, you're almost entirely free of any significant PCI compliance.

Now that it's done, it's kind of nice having full control over every detail of how we handle credit cards. However, I wouldn't do it again now that there are so many other options out there.

<comment><USER4> Thanks for the reply. I can understand your reasoning, but I think perhaps our situation is different.

For future reference, you might like to know that there are now regular payment gateway/merchant account combinations where you can use their systems to handle the final part of the transaction so you never even have card numbers on your network, so the PCI DSS issues are moot, at least here in the UK. The lock-in isn't ideal, but as far as I know only Recurly out of the major billing services doesn't effectively lock you in just as badly anyway.

However, we've found that the recurring billing platforms tend to lack precisely the kind of flexibility you mentioned above. We have all kinds of plans to use promotional codes, multiple offerings that users can subscribe to individually or in combination, etc. As far as we can tell, none of the "big name" billing services even gets close to supporting this kind of stuff properly yet.

For the benefit of anyone else following this discussion, I'll also mention that because we're in the UK but most (all?) of those billing services are across the Atlantic, there are serious concerns about legal differences, particularly data protection/privacy rules, and about tax, particularly how VAT is handled. Again, the billing services whose terms and conditions we've checked out had deal-breakers here.

Given that the billing services take a relatively large cut out of the payments, sometimes with terms that don't even guarantee any particular level of service, and that we'd have to implement a whole bunch of things on top of their platform anyway, we concluded that they simply don't offer enough to justify the risks and overheads.

<comment><AUTHOR> Those are definitely all very good points. Everyone's situation is so different, I'm always hesitate to give any advice as a "prescription" and more of "here's what we did and why we did it so you can decide for yourself".

I'm definitely aware of how easily the new services enable you to entirely avoid the PCI issues. Personally, I'd say that their cut is probably well worth it relative to the time and effort that it takes to build it from scratch. However, that's driven in large part because I'd much rather invest time in the product than worry about the billing details. It's not that it's all that difficult, it's just that it's not the core of what makes Sifter unique.

With regards to promotions and stuff, I'm not a big fan of that. I'm a strong believer in keeping things simple and people either like it enough to pay for it or they don't. I feel that promotions might attract people for the wrong reasons. The more complex the pricing is, the more painful it is to deal with, and it can quickly become a distraction from simply crafting a better product.

Of course, plenty of companies have had great success with promotions, but it's not for us. To each their own, right? Either way, I hope the info helps. Best of luck which ever way ends up working out for you.

<comment><USER4> I completely understand your point on wanting to concentrate on the main product and not the billing. That's why we spent such a long time looking into the alternatives, and we would happily outsource that side of things if we could do so with acceptable losses in flexibility.

It's interesting that you don't rate promotions, and I noticed elsewhere in your slides you were fairly negative about ongoing publicity spend. On that we would somewhat agree as well, I think.

The difference is more that we're in something of a niche market, nothing like the stereotype HN fodder that is aiming for the general public as a target audience and low prices. We've done a lot of research into both the global demographics of our market and various potential marketing channels, and it turns out that something as simple (to the customer) as a promotion code can support all kinds of other activities beyond just a generic coupon code promotion, as long as you can implement the right systems for generating and recording those codes behind the scenes.

This is where we felt the simple options offered by the various billing services today just weren't up to the job, and to some extent I'm not sure they ever could be since beyond a certain point I think these policies are always going to be customised to a particular business model.

Anyway, thanks again for sharing the slides. It's useful to know where you were coming from on that particular one because it's the only one where our current approach is clearly different to what you felt had worked for you. Otherwise, your experience is actually quite reassuring, as we had come to many of the same conclusions on your other points and it's nice to know that we aren't completely crazy! :-)

</comment></comment></comment></comment></comment></comment><comment><USER5> I've been aware of Sifter for a while but it's great to get the inside story.

I particularly liked your point about building features that no-one used - I'm sure it was kinda hard to watch all that hard work go to waste.

You might have covered this in your talk, but which features did you add that you could have omitted? Without having that usage data early on, is there any way you could have done this differently?

Your slides are awesome by the way :)

<comment><AUTHOR> I don't think that we've added anything that we should have omitted, but I definitely think we added them before we probably should have.

Keep in mind that it really all depends on your goals, and my goals aren't to create a huge app that generates millions but to build something that's pleasant to use and supports me to the point that I can continue to work on it.

That said, I think that we probably should have invested in improving and polishing our existing features before adding source control and email integration. However, I'm sure those have generated a handful new customers that otherwise probably wouldn't have used Sifter. I think they fall into the categories of things that people _need_ when they're evaluating software but that in reality they really don't end up using.

Really, there's so many variables that it's hard to contribute any level of success or failure to one decision. I'm really pretty happy with everything that we have or haven't done to this point. It's just a bit disappointing to pour effort into a feature and find out that it's only being used 2-3% of the time.

</comment></comment><comment><USER6> What made you get into this market in particular? What are your main channels for new customers? What were the biggest lessons on the business and marketing end?

<comment><AUTHOR> We chose it simply because it was just an area that I'm oddly fascinated by. Our main channel for new customers these days is word-of-mouth referrals.

As far as the biggest lessons, they're all in the slide deck. :)

</comment></comment><comment><USER7> Thank you so much for posting this. I particularly liked the timeline showing what was going on in your life as you built Sifter.

</comment><comment><USER8> When you say "run billing daily", I assume you don't actually charge customers daily. What is it that runs every day?

<comment><USER9> I interpreted it as each subscriber can be billed on any day of the month as opposed to everyone billed on the first for example. This would help the cash flow.

<comment><AUTHOR> Cash flow is definitely a big part of it. With daily billing, we never see any huge fluctuations in our account. In my opinion, a slow and steady stream of income is much better than big pop once a month.

</comment></comment></comment><comment><USER10> awesome slides and presentation Garrett!</comment>


Dark Mode Available for Google Chrome - <AUTHOR> https://www.theverge.com/2019/3/12/18262480/google-chrome-dark-mode-now-available-mac-os-mojave-windows-10 <comment><AUTHOR> Looks like they did not change the color of incognito mode, which now makes it confusing when trying to compare windows. They really should have modified coloring in incognito mode.</comment>


Maverick forerunner of artificial life and animation remains largely unknown - <AUTHOR> http://m.nautil.us/issue/14/mutation/meet-the-father-of-digital-life <comment><USER2> If you're interested in emergence and artificial life, I've been working on creating in JavaScript a lot of the work that has been done by others in the past as well as some original projects:

[http://www.emergentmind.com/](http://www.emergentmind.com/)

The last project (The Evolution of Color) has similarities to the color visualizations described in this post: it uses genetic algorithms to evolve a population of colors towards a fittest color as determined by the closeness of the bits that comprise the colors.

I have a few other projects planned so if you're into this stuff you're welcome to sign up for the mailing list to get notified when they are launched:

[http://www.emergentmind.com/newsletter](http://www.emergentmind.com/newsletter)

I'm always open to ideas for new projects so if you have anything you'd like to see implemented or want to work on something together feel free to shoot me a note.

<comment><USER3> Something like evolving virtual creatures would be a fun (although pretty ambitious) addition [1].

There's a processing 2D virutal creatures model called sticky feet [2] (source available) that perhaps could be ported to js pretty quickly.

[1] [https://www.youtube.com/watch?v=JBgG_VSP7f8](https://www.youtube.com/watch?v=JBgG_VSP7f8)

[2] [http://www.cc.gatech.edu/~turk/stickyfeet/](http://www.cc.gatech.edu/~turk/stickyfeet/)

<comment><USER2> For sure -- that is one of the medium term projects I want to work on. We'll see how it goes in the browser though...

</comment></comment></comment><comment><USER4> Link to Alexander Galloway's Processing implementation [http://cultureandcommunication.org/galloway/Barricelli/](http://cultureandcommunication.org/galloway/Barricelli/)

</comment><comment><USER5> _Barricelli presented a bold challenge to the standard Darwinian model of evolution by competition by demonstrating that organisms evolved by symbiosis and cooperation._

Somehow I thought symbiosis and cooperation was the accepted model, and competition was just a cultural projection. No?

<comment><USER3> While the mainstream view is evolving (ha..), the selectionist (competition- centric) view has been largely dominant in biological thinking (e.g. Richard Dawkins). It is giving way to a more balanced view of how natural evolution produces innovation.

For example, researchers like Gould stress non-competitive forces like the role of historical contingency, and exaptation [0]. Margulis, who was mentioned in the article, had a theory that much complexity in cells was accumulated through symbiosis -- a theory that was radical when first introduced but was later validated [1]. In effect, one cell would engulf another, but instead of eating the other cell, they would co-evolve together; for example, the mitochondria (cellular power plant) is thought to have arisen from such an event (it has its own DNA).

[0] [http://en.wikipedia.org/wiki/Exaptation](http://en.wikipedia.org/wiki/Exaptation)

[1] [http://en.wikipedia.org/wiki/Lynn_Margulis#Endosymbiosis_the...](http://en.wikipedia.org/wiki/Lynn_Margulis#Endosymbiosis_theory)

<comment><USER6> You are probably not seeing this but your point needs refutation.

Dawkins model(not his actually but he presented to general public) was not competition-centric. Main idea was gene centric view of life. Competition, cooperation, symbiosis etc all were explained from the genes point of view. The thing to note is, even when we see apparent 'cooperation' between species, at the genes level there is a competition with other gene pools. So the non- competitive forces look so on the surface, but the only thing genes care about is moving on to the next generations and spreading as much copies as possible even if that happens with symbiosis.

Gould on the other hand, was not happy with this selfish view of life(everyone says he had Marxist ideologies which made him a bit bias). He thought of selection as happening at multiple levels, not just limited at genes but also species and individual. This was the main controversy between him and dawkins.

So, to reply to GPs query, yes that quote is sort of incorrect since everyone agreed that cooperation and symbiosis(Darwin too) are very much part of evolution.

</comment></comment></comment><comment><USER7> Damn, and I thought I knew a little bit about the ALife field. But I have to admit, I had also never heard of Nils Barricelli until now.

This is the kind of content I love HN for. _This_ is good stuff. I'm looking forward to looking up some of Barricelli's work and reading up on it.

Thank you, ayberkt, for submitting this.

Also, from the "scientists a lot of people have not heard of, but probably should have" department, I offer Ilya Prigogine. Probably not as obscure as Barricelli, but I haven't found a lot of people know much about Prigogine.

[http://en.wikipedia.org/wiki/Ilya_Prigogine](http://en.wikipedia.org/wiki/Ilya_Prigogine)

</comment><comment><USER8> Non-mobile link: [http://nautil.us/issue/14/mutation/meet-the-father-of- digita...](http://nautil.us/issue/14/mutation/meet-the-father-of-digital-life)

</comment><comment><USER9> I ran into Nils Barricelli while reading _Turing 's Cathedral_, which is a book I enjoyed throughly.

<comment><USER10> I need to jump back into that. I'm not a big nonfiction guy so I put it down to start something else and never picked it back up. Thanks for reminding me.

</comment></comment><comment><USER11> Sounds charming and brilliant enough to be considered a proto-Wolfram.</comment>


Getting Past C - <AUTHOR> http://blog.ntpsec.org/2017/01/03/getting-past-c.html <comment><USER2> Rust has some very desirable properties to me. Writing Rust programs _from scratch_ is not as scary as I've heard of from the internet either. The documentation is excellent, the compiler diagnostic messages are very helpful and the notorious borrow checker didn't stand in my way that much. And I love Cargo and Cargo.io. I have some projects where Rust is the saner choice than Go or other GC based languages.

That said, there are actually drawbacks of Rust compared with Go, IMHO. When facing a moderately large project __written by others __, the ergonomics for diving into the project is not as smooth as Go. There is no good full-source code indexer like cscope /GNU Global/Guru for symbol navigation across multiple dependent projects. Full text searching with grep/ack does not fill the gap well either since many symbols, with their different scopes/paths, are allowed to have the same identifier without explicitly specifying the full path. That makes troubleshooting/tracing a large, unfamiliar codebase quite daunting compared with Go.

<comment><USER3> RLS will hopefully full that gap.

<comment><USER4> RLS?

<comment><USER5> it stands for Rust Language Server

Github project: [https://github.com/jonathandturner/rls](https://github.com/jonathandturner/rls)

Announcement: [https://internals.rust-lang.org/t/introducing-rust- language-...](https://internals.rust-lang.org/t/introducing-rust-language- server-source-release/4209)

</comment></comment></comment></comment><comment><USER6> Can anybody make a strong case to me as to why are buffer overflows considered an issue in C when it takes like 10 minutes to write and test an array implementation that prevents that from ever happening? I do agree that C has issues (though in my opinion neighter Rust nor Go address almost any of them) i just don't understand why are buffer overflows such a huge problem in C when the same thing is going to come up when trying to work with memory in Rust.

<comment><USER7> Because your 'safe' implementation will certainly have a performance cost, and won't be the default. This is why, despite C++ providing std::array, you'll still find buffer overflows in C++ code. C++'s std::array provides the safe 'at' function but you're opting into a performance penalty and it's not the more familiar [] syntax.

Rust arrays/ vectors are safe-by-default. To use the unchecked, unsafe version requires using the 'unsafe' keyword.

let v = vec![0, 1, 2]; unsafe { let x = v.get_unchecked(5); }

This means you can basically grep audit for vulnerabilities, and the above code should be very rare.

<comment><USER8> In addition, the Rust compiler can also _remove_ the built-in indexing checks if it can prove the code is safe. So, say, iterator loops over an array won't have any index checking.

<comment><USER7> C/ C++ compilers are also capable of doing this, though rust's iterator syntax tends to make it a pretty natural optimization.

<comment><USER9> Neither C nor C++ knows, at the language level, the size of an array, unless that size is fixed. The subscript checking variants of C and C++ have to use "fat pointers" which carry along size information. The overhead for this is large and nobody uses that. Fat pointers used to be a feature you could turn on in gcc, but it's somewhat abandoned now.

<comment><USER10> > Neither C nor C++ knows, at the language level, the size of an array, unless > that size is fixed.

Neither does Rust.

> The subscript checking variants of C and C++ have to use "fat pointers" > which carry along size information.

So do Rust's Slices.

> The overhead for this is large and nobody uses that.

People use std::vector all the time for this purpose in C++. It has about the performance you'd expect, with very little overhead except where you want it in bounds-checking.

I don't think there's actually a performance difference here. Rust's default is safer because it requires dropping to unsafe code to do something dangerous, but the same optimizations are available in both.

<comment><USER3> One thing that I've heard might be a difference, but haven't confirmed yet: Rust's lack of move constructors. So you have a vector, it's full, you push one more. It has to reallocate. How do you copy all of the elements over to the new allocation? In Rust, it's a straight memcpy of T * n bytes. But due to move constructors in C++, IIRC they must be moved one at a time.

Again, I haven't actually dug into this; maybe someone more knowledgeable about this can point me in the right direction here?

<comment><USER11> How would a self-referential object work in Rust in that case? The move or copy constructor could not be a simple memcpy.

The self-reference would point to the old object. See this for an example: [http://ideone.com/sEFtbN](http://ideone.com/sEFtbN)

<comment><USER12> [https://github.com/Kimundi/owning-ref-rs](https://github.com/Kimundi/owning- ref-rs) exists, but basically you just don't do intrusive datastructures on the stack in rust.

(Intrusive datastructures on the heap are doable with some tricks.)

They're not very essential so it works out.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> A 62 KLOC secure NTP server seems like an ideal project for this kind of experiment. I imagine it would be self-contained enough to actually _use_ Rust or Golang instead of just treating them like FFI scripters.

</comment><comment> awinter-py > One such cleanup: we've made a strong start on banishing unions and type > punning from the code. These are not going to translate into any language > with the correctness properties we want.

Really? This sounds like idiomatic rust to me (heavy with enums).

<comment><USER14> C unions have no discriminant. But yeah it's a pity—I'd try to hack up discriminated unions then. Or convert to Rust unions and then enums and remove unsafety.

<comment> awinter-py C union declarations should correspond pretty closely to rust enum declarations.

It's a surprisingly important feature. Every large codebase I've worked on has clunky workarounds for storing heterogeneous types in collections.

Haven't seen a silver bullet; dynamic languages are great at this until you have to scale (either in lines of code, number of types or dataset size) and then they become unmanageable. Static languages force you to type a lot and build in-memory ETL-style transformations but scale better. Using SQL is another solution, but that separates you from the language's type-checker and can be another source of error.

Type safety at the serialization boundary was the promise of CORBA and protobuf but we need better tools. I hope we see more focus on ser/des types in the next generation of industry languages.

<comment><USER3> Close, but not quite: unless the type is NonZero, you need space for the tag.

c-style unions are in nightly behind a flag; they're not stable yet.

<comment><USER12> I think they meant that the use case corresponds closely, not the representation. Generally C unions get used the same place Rust unions would in a rust program (not vice versa though), unless they're being used for type punning, which is pretty rare anyway.

<comment> awinter-py I meant if you have a large program where many types are C unions like:

        struct TaggedUnion {
            enum {T1, T2} type_id;
            union {type1 t1; type2 t2;} u;
        }

If the goal is to translate automatically to a rust enum declaration, that will be (a) possible to do with an automatic tool and (b) will give enhanced safety because it will force the type to be checked everywhere these values are used.

</comment></comment></comment></comment></comment></comment><comment> aaron-lebo Outside of the language war bubble it's really great to see a post like this. Practical concerns, reasonable advantages/disadvantages of each language, a real project dealing with real timelines. Thanks!

<comment><USER15> Was going to say the same. In the past ESR has come across as a patently arrogant gun maniac, but the first part of this post is great for all the reasons you mentioned.

(What irritated me though was the switch to first-person narrative at the end).

</comment></comment><comment><USER16> This is literally the only thing I can think of that "NTPsec" can do that would result in the project having any relevance. I understand why some very specific sites are chained to the ntpd codebase, but the vast, overwhelming majority of the ntpd deployed base not only isn't tied to ntpd, but also doesn't need 99% of what ntpd does. Trying to "secure" that codebase always seemed to me like a very silly windmill to tilt at.

</comment><comment><USER17> I wish more mention of D would happen. It is compatible with C and C++ libraries and features GC without sacrificing the good things of C and C++. I always loved the idea of Rust and Go but they are nowhere near C or C++ where it matters to me. D fits the bill, otherwise I just use Python. I like being able to design software in my own way as opposed to being told how to do it.

<comment><USER18> The truth is the Rust leadership did the hard work of building a community around the language, making high-quality tutorials and introductions to the language all before it stabilized for 1.0. Many developers claim to dislike "marketing", but Rust did its marketing/evangelism and D didn't.

From a purely technical standpoint, Rust's borrow checker is able to catch data races, while D has no such functionality (unless I'm not caught up), which is a huge advantage in today's world of multithreaded applications.

<comment><USER12> Even in single-threaded mode D isn't too safe. Safer than C, but unless you're using the GC it is still unsafe.

</comment></comment></comment><comment><USER19> How much concern would non-standard architecture support matter for ntp? Given how many architectures Linux supports, I would think that C would still be the best choice, until these other languages gain support for those missing architectures.

Or perhaps it's a good opportunity for a language which offers transpilation with ANSI C as the target?

<comment><USER20> In addition to squiguy7's point, I'd add that A: it may not be clear if this is your only contact with ntpsec.org [1], but this is actually a fork of the classic ntp, so they may be more willing to abandon some older architectures to produce a more secure product going forward than the core NTP project would and B: the older versions will still be around even so.

Also, it has been suggested by some experiences that older architectures often end up getting supported past when they really should be stopped out of sheer inertia, though I'm not having luck digging up the articles that prompt me to say this. Are there that many systems out there running ntp that can't run Go and/or Rust, and if there are, are there enough to be worth bending the project around? If the people running those things care, perhaps they should fork the project and maintain it themselves. Which is less harsh than it may sound, because they can still pull from upstream, and they probably just need to tread water rather than stay up with the latest & greatest.

(I should emphasize that the operative question is _are there enough to be worth bending the project around_ , rather than whether there are any. Because there certainly are non-zero numbers of systems running ntpd that can't run Rust or Go. But who's going to pay to maintain them? Especially if classic ntp is still available?)

[1]: [https://www.ntpsec.org/](https://www.ntpsec.org/)

<comment><USER19> Well, it's not just older architectures which are not currently supported, it's architectures used in IOT devices, mainframes, and other non-commodity hardware. Specific to LLVM based languages, if it's not a priority to Apple (or the other big LLVM players), it infrequently gets done.

Specific to IOT devices, I would personally love to see secure _everyting_. NTP, TLS, SSH, etc.

<comment><USER21> There is a lot of community interest in Rust with regards to running on embedded devices, so I wouldn't be so quick to point to IOT devices as a reason for not using Rust. That said, I don't know what the current state of support for these less popular architectures is. The official page for platform support is [https://forge.rust-lang.org/platform- support.html](https://forge.rust-lang.org/platform-support.html).

<comment><USER22> LLVM's biggest weakness right now is micro controller support like PIC/AVR. But its getting better: [http://lists.llvm.org/pipermail/llvm- dev/2016-November/10717...](http://lists.llvm.org/pipermail/llvm- dev/2016-November/107177.html)

That should hit most of the chips most people would care about. I presume rust would gain from the upstream LLVM support?

<comment><USER21> Yeah it should. AIUI Rust uses a fork of LLVM, but they should be regularly pulling in upstream changes (but I don't know how often this happens) as well as submitting their own changes back upstream.

<comment><USER3> We do, in both directions.

<comment><USER18> Is there a technical or political issue preventing Rust from using upstream LLVM? Either way, is there a possible resolution on the horizon?

<comment><USER3> Nope. You can use a stock LLVM if you want. Some tests might fail, since patches might not be in upstream yet.

It's not really something to resolve; it's just the usual situation with a big dependency.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> I would start by getting the code to compile with g++, then begin migrating the dangerous C constructs to safe C++ constructs. IMO, that would be a safe, reasonable thing to do.

<comment><USER24> How would you prevent other developers to write C style code?

<comment><USER25> Project leadership, coding standards, _automated analysis and code reviews_.

But realistically speaking it might be easier to change tools for a significant number of teams, because the software development community is in general poor at leadership and process. A rewrite seems more approachable for the average (not necessarily average skills-wise) dev compared to a change in attitude, self-reflection and incremental improvement at a department or company level.

Then the rust compiler will pummel everyone into submission. This can be a succesful strategy. :)

<comment><USER24> Which I seldom see in enterprise projects, specially in companies whose business is unrelated to software development and IT is nothing else than a cost center.

Anything that is optional gets pushed aside.

</comment></comment></comment></comment><comment><USER26> After reading this post the idea of a C-to-C translator that injects bound checking, etc. comes to mind. Such translator could be used by OS distributions to provide safety in the least intrusive way and possibly completely automatically for many C codebases they have in their repositories. Translating into Go or Rust, on the other hand, cannot scale beyond some individual projects, that decide to undertake such efforts. Mainstream C compilers could implement safety features too, but realistically it cannot happen, as it's not something most people care about. So, C-to-C translator might be a best bet with the most impact.

<comment><USER27> CompSci keeps making them, even open-sourcing some, but little uptake or improvements from the FOSS crowd. Here's two of the top ones:

[http://sva.cs.illinois.edu/](http://sva.cs.illinois.edu/)

[https://github.com/jtcriswell/safecode- llvm37](https://github.com/jtcriswell/safecode-llvm37)

[https://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/](https://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/)

<comment><USER28> As we've discussed, one issue is the big performance cost of these solutions. Anyone interested in working on an automatic C to SaferCPlusPlus[1] translator? It should address the performance issue[2]. And should be much more straightforward than these C to Rust/Go translators.

[1] shameless plug: [https://github.com/duneroadrunner/SaferCPlusPlus](https://github.com/duneroadrunner/SaferCPlusPlus)

[2] [https://github.com/duneroadrunner/SaferCPlusPlus- BenchmarksG...](https://github.com/duneroadrunner/SaferCPlusPlus- BenchmarksGame)

<comment><USER27> I thought you have an interesting solution to improving safety of C++ code. So, your techniques work with C code done in the old and new C styles w/ no work? Just fire and forget translation of C code written in arbitrary styles to to be completely memory-safe?

<comment><USER28> Yeah, the idea is that C/C++ has a finite set of "dangerous" elements. SaferCPlusPlus attempts to provide safe compatible substitutes for those elements. In C, basically the only dangerous elements are pointers and arrays (if you consider them separate things), right? SaferCPlusPlus provides safe compatible replacements for pointers (and new/malloc and delete/free). There is a "general" safe pointer type that can be used as a direct substitute for native pointers in most situations, but can sometimes have a noticeable performance cost, depending on usage. Faster safe pointers are also provided, but cannot be used in all situations.

Replacing all the pointers and arrays in your C code with the safer substitutes will eliminate the possibility of invalid memory access, in your code. Of course this doesn't prevent them from occurring in any unsafe libraries you use, including the standard library.

Also, there are certain behaviors in C that may not translate well to SaferCPlusPlus. Like exotic pointer arithmetic. Or, for example, you could imagine some C code that compares two pointers that point to items that have already been deallocated to see if they were previously pointing to the same item. Is that valid in C? Anyway, that kind of thing is not supported by the safe pointers.

There is not yet an automatic translator from C to SaferCPlusPlus, but the translation for most code is straightforward and direct. No new paradigms or "Rust borrow checker" type restrictions. You can check out the benchmark code I linked to in my comment to see examples of C++ code before and after conversion to SaferCPlusPlus. A little code reorganization sometimes helps to achieve optimal performance. But isn't that always the case? :) And of course, SaferCPlusPlus requires a modern C++ compiler and has dependencies on the standard library.

</comment></comment></comment></comment></comment><comment><USER29> It's not yet ready for primetime, but Scala Native ([http://scala- native.readthedocs.io/en/latest/](http://scala- native.readthedocs.io/en/latest/)) might just make a splash in the systems space. I don't think it has anything like ownership yet, but I wouldn't be surprised if it eventually develops that capability. I think you can get it to run without GC, too, but using C Stdlib memory management. Although, that largely defeats the memory-safety.

Just throwing it out there as something to keep an eye on!

</comment><comment><USER30> Looking at the current new and coming languages I would take a hard look at NIM. It may be is not there yet but it looks highly appealing, is as fast as the often mentioned Rust and compiles significantly faster. [http://nim- lang.org/](http://nim-lang.org/)

<comment><USER31> Nim compile times are faster and often the execution time is faster, too. Also it's very expressive, almost like Python.

</comment></comment><comment><USER32> I didn't understand why rust and go are natural alternatives to C. Wouldn't C++ be a more natural option? (Despite the fact that both go and rust are developed by third party companies)

<comment><USER33> "out of C into a language with no buffer overruns, and in general much stronger security and correctness guarantees."

Doesn't sound like C++.

<comment><USER32> I still don't get it. Can't it be done in c++ via appropriate data structures? I mean, it's not like Go is magic, at the end I suppose Go would be doing just that. As far as I know the main reason people opt for Go over C++ are the compiling times...

<comment><USER3> You can write safe C++, if you're careful, and everyone you work with is careful, all the time. Judicious use of features can make your code more safe, but they can never make it actually safe.

Rust and Go, in various different ways (and to various degrees), make it actually safe.

</comment></comment></comment></comment><comment><USER34> My experience is that using C for main(argc,argv)-style programs is rarely a problem. Trouble comes when using long running single-address space containers for service-like abstractions with pthreads etc.; in that kind of environment, malloc() and co. don't cut it because even _if_ you get memory allocation right, unless using pooled memory allocators, memory fragmentation is becoming a serious (ie. unsurmountable) problem.

It's been said over and over since at least the Java times that creating OS processes for individual service invocations is bad for performance, but I've never seen proof for this statement in the form of a benchmark.

Even the OpenBSD developers (who know a thing or two wrt. security of memory allocation schemes) diss process-per-service-invocation architectures in their httpd implementation (eg. calling their CGI bridge "slowcgi" and favouring fcgi over it).

Isn't that inconsequential? I mean if there's a performance problem with CGI- like process-per-service invocations, why not target these problems at the OS level (or via pooling of network connections or whatever the bottleneck is)?

</comment><comment><USER35> Rust is surely fine, and an improvement over C, but its main advantage is that all the rust code is written now, when everyone takes more care about security.

It doesn't have to deal with 40 years of bad legacy code written by sloppy developers.

You can obtain similar quality in a C modern code-base, using tools like static and dynamic analyzers. In fact, today the hardest issues came from multi-threading. I won't even dare to write multi-threading apps without helgrind/TSAN.

And Rust doesn't help in this regard. From: [https://doc.rust- lang.org/nomicon/races.html](https://doc.rust-lang.org/nomicon/races.html) 'So it's perfectly "fine" for a Safe Rust program to get deadlocked or do something incredibly stupid with incorrect synchronization.'

<comment><USER36> I find it rather daring to use raw POSIX threads or similar, hoping that automated debugging tools operating at this abstraction level, such as Helgrind or TSAN, will pinpoint your bugs. The problem is that the state space of a thread-based program synchronizing with mutexes is too large to explore at a reasonable time. More about this: [http://yosefk.com/blog/checkedthreads- bug-free-shared-memory...](http://yosefk.com/blog/checkedthreads-bug-free- shared-memory-parallelism.html) and [http://yosefk.com/blog/making-data-races- manifest-themselves...](http://yosefk.com/blog/making-data-races-manifest- themselves.html)

Which higher-level abstraction to use is a question and depends on the problem at hand; for throughput computing in C, Cilk is perhaps the best today (I guess you could call my own project checkedthreads a bit of a Cilk knock-off.) AFAIK, Rust developers are more interested in higher-level abstractions than Go developers (Go's built-in goroutines being on par with threads in terms of ability of automated debugging tools to flag bugs; perhaps there's work in Go on higher-level abstractions but the vibe I felt, perhaps mistakenly, is that these are non-problems, which I disagree with: [http://yosefk.com/blog/parallelism-and-concurrency-need- diff...](http://yosefk.com/blog/parallelism-and-concurrency-need-different- tools.html))

</comment></comment><comment><USER37> I like go, I'd love to write libraries in it but as far as I can tell you can't really create a C compatible shared library from it. That it still the common denominator if you want to call into it from other languages. I'd love to write Python programs with performance critical stuff in Go

<comment><USER38>
        as far as I can tell you can't really create a C
        compatible shared library from [Go].

Sure you can! (as of Go 1.5, iirc)

Change your build command to use the c-shared build mode:

        go build -buildmode=c-shared

Then, to change the linkage of the functions you want to export, use the magical comment "//export" directive:

        //export MyFunction
        func MyFunction(arg1, arg2 int, arg3 string) int64 {
            ...

<comment><USER3> This still doesn't get over the inherent overhead in calling between the two languages though, right?

(And you're bringing that whole runtime with you. Which might be okay! As always, it depends.)

</comment></comment></comment><comment><USER39> why does it take 62KLOC of C to distribute time? thats more code than the whole plan9 kernel.

<comment><USER39> doom was 52KLOC of C.

<comment><USER40> Less than that even:

      all            37641 (100.00%) in 135 files
      c              37311 (99.12%) in 66 files
      asm              232 (0.62%) in 1 files
      makefile          98 (0.26%) in 2 files

</comment></comment></comment><comment><USER41> I do not contest on the opinion that Rust is a good language, but it slightly hurts me when people club C and C++ together. One can easily write correct by construction code using modern C++. Use of meta-programs allows you to create typesafe constructs. It provides you with zero cost abstractions to specify ownership of resources and ..... <I can go on> One has to just strive to not use the C baggage that comes with it.

<comment><USER12> C++ is much better, but still not safe. Null still exists. Moves are runtime moves, so you can still attempt to access the value at compile time. Iterator invalidation is still an issue.

Of course, C++ might be "safe enough" for your use cases.

<comment><USER41> > Moves are runtime moves, so you can still attempt to access the value at > compile time.

What do you mean by that ? Are you saying the standard decided to make it non- destructive moves ? Then yes, it is a possible scenario for error but also a performance advantage in some cases.

<comment><USER12> > What do you mean by that ? Are you saying the standard decided to make it > non-destructive moves ?

You can still access a value after it has been moved out. use-after-move is allowed by the compiler. It places (stdlib) types in an unspecified but valid state (I've seen C++ code reusing these types and assuming that the state after move is something in particular -- it's not).

Most optimizations you can do by reusing a moved value could be done automatically by the compiler (by using the same stack space since it statically knows that it's been moved out).

Linear types are a pretty well known pattern and could have been used as a part of the design of moves. This would have the additional benefit of removing explicit move constructors from 99% of all types out there. This has not been done (and can't be now).

Edit: The pretty rare optimization potential of runtime moves is pretty much negated by the fact that common things like reallocing a vector can't be made into a memcpy for most types, just because they have nontrivial move ctors which wouldn't exist in the compile-time move scenario.

<comment><USER42> Use-after-move is allowed because of existence of value categories, if you use a return value from a function its creation is usually elided or it is moved, but you can't access that temporary without directly referencing it. When you move an existing object (by specifically saying std::move), what should happen with it? Destroying the object is not a solution because its variable might be still accessible in existing scope (something like dangling a reference in the middle of a scope), which imply use-after-move should be prohibited be language and all variables should have a "not-a-value" state and throw exceptions on use.

<comment><USER12> > When you move an existing object (by specifically saying std::move), what > should happen with it?

You don't destroy it, you treat it as an actual "move", where the compiler will not consider the original variable as accessible after this point, and _not allow accesses after the move_. The memory it took up is free for reuse, and no destruction code is run on the side of the code doing the moving (in the case of a conditional move this gets a tiny bit more complex, but not too much). "It's variable will be still accessible in local scope" is exactly what I'm getting at; you can enforce at compile time that this isn't the case by simply disallowing access.

You shouldn't have local references active, just like how you shouldn't have local references to the contents of a vector when you push to it. You can already invalidate local references to a part of a struct when something gets moved in modern C++. Being wary of invalidating local references is an established concept in C++; this doesn't exacerbate that problem.

It's even better if you track scopes in references which gets rid of the dangling reference problem entirely but at this point you've reinvented Rust :p

To be clear, I'm talking of a completely different model that could have been used in place of the rvalue reference and move model. Making C++ have linear types _now_ would be tough, but it could have been done before. There are different tradeoffs there, but I suspect it would have been safer.

> all variables should have a "not-a-value" state and throw exceptions on use.

You can make this a compile time error. Like I said, linear typing is a pretty well established pattern.

</comment></comment></comment></comment></comment></comment><comment><USER43> > Under Linux, some SECCOMP initialization and capability dances having to do > with dropping root and closing off privilege-escalation attacks as soon as > possible after startup.

I was under the impression that these specific things were actually quite hard to do in Go. I believe that both setuid/setgid and seccomp_load change the current OS thread (only), and since Go multiplexes across multiple threads and gives programmers very little control over which ones are used for what goroutines, I'm not sure how you would, for example, apply a seccomp context across all threads in a Go program. setuid/setgid are currently unsupported for this reason, with the best method being "start a subprocess and pass it file descriptors" ([https://github.com/golang/go/issues/1435](https://github.com/golang/go/issues/1435)).

I'd be interested to hear if others have found ways to actually do this reliably for all OS threads underlying a running Go process.

<comment><USER44> I did this once, by writing a small C program which sets up the seccomp context before exec'ing the Go binary. Unfortunately Go's runtime makes a huge number of system calls in the background, and the whitelist kept growing.

Switched to Rust and there was only had one hidden system call left, getrandom used to initialize the hashmap

</comment></comment><comment><USER45> I didn't see Ada or ATS mentioned upon a quick read here. I don't program in either beyond exploratory play, but they seem to fit the need here no?

</comment><comment><USER46> what's wrong with OpenNTPD exactly?

<comment><USER47> There's a summary of some of its limitations here: [https://en.wikipedia.org/wiki/OpenNTPD#Criticism](https://en.wikipedia.org/wiki/OpenNTPD#Criticism)

One of them (lack of leap second support) is fresh on our minds since we just had a leap second. Some thoughts from the OpenNTPD folks are at [http://undeadly.org/cgi?action=article&sid=20150628132834](http://undeadly.org/cgi?action=article&sid=20150628132834)

Chrony is another alternate NTP implementation, here's their comparison vs ntpd and openntpd. [https://chrony.tuxfamily.org/comparison.html](https://chrony.tuxfamily.org/comparison.html)

<comment><USER46> It sounds like the leap-second thing isn't that big of an issue though...

<comment><USER47> The leap second thing is a big issue for a server. OpenNTPD serves the wrong time on the day of the leap second. They don't propagate the leap second flag properly either. It's not correct and doesn't belong in a public server pool IMHO. This issue isn't just theoretical: it was responsible for a lot of the bad time being served by the NTP Pool last week.

You're right that the article I linked argues the leap second isn't a big problem to client machines. I guess I sort of believe it, if you don't care if your client is a second off from true time once every couple of years.

</comment></comment></comment></comment><comment><USER48> Why do they have to use a low level language ? Why not use NodeJS ? One argument would be time management, but even with C you can not be sure that no interrupts happens in between ...

</comment><comment><USER49> Honestly, why not do it once and for all in a strongly typed pure functional language, validate it, and then tweak the GC parameters to get the performance? Use the safest and most powerful language that you can, if you can.

<comment><USER15> Some people don't believe in tweaking GC's. I've heard horror stories from people who tried it on the JVM.

(And I have made terrible experiences with JVM's GC, but never tried tuning).

Some people don't believe that extremist functional languages are needed (depending on the domain).

Validation. Oh, well.

I think you propose Haskell, and it might disqualify for an NTP daemon, for example in terms of debuggability (stack traces?).

<comment><USER50> A more relevant point that would disqualify Haskell is the fact that its runtime (or rather, the GHC's runtime) is nowhere near predictable enough for the realtime guarantees that time synchronisation software would require.

A Haskell DSL that outputs some safer low-level code would be a more likely choice (for example [http://hackage.haskell.org/package/atom](http://hackage.haskell.org/package/atom)), but Rust is both more popular and has more commercial support.

<comment><USER15> When opting for a DSL that compiles to low-level the "Haskell" part is less important.

I've heard the idea of DSLs over and over again, but who actually does that? I know of course of sed, awk, regex, etc but what part of NTPsec is narrow enough in scope and large enough in volume to justify creating a DSL? (just asking -- I'm not familiar with NTPsec).

<comment><USER27> Companies that like consistently getting results. Example:

[http://ivorylang.org/ivory-introduction.html](http://ivorylang.org/ivory- introduction.html)

</comment></comment></comment></comment></comment><comment><USER51> Rather than looking for a new language, why not ban programs from writing to executable memory?

<comment><USER52> I'm not an expert in this field, but it's my understanding that this is often the case for C programs executing nowadays. The AMD64 architecture even has the NX bit. There are some other ways that this can be enabled too.

But surprisingly, this doesn't solve all code execution security problems from buffer overflows. Sometimes exploiters can find non-executable memory to change that allows them to change the program behavior to do what they want, such as changing the command string that gets passed to a normal execve call later in the program.

But even if you solve the security issues, buffer overflows are still a huge headache. A one byte buffer overflow can cause your program to crash an hour later, with almost no hope of figuring out why it happened. A developer can easily spend weeks tracking down a single buffer overflow crash.

<comment><USER53> > Sometimes exploiters can find non-executable memory to change that allows > them to change the program behavior to do what they want, such as changing > the command string that gets passed to a normal execve call later in the > program.

Changing function pointers or the return value on the stack are the normal things to do. In particular if you corrupt the stack you can simply return into system() with whatever arguments you want.

</comment></comment></comment><comment><USER54> Why does 90% of this _huge_ comments section revolve around Rust? Haven't we had enough of the same already? Yes, we know it provides memory safety guarantees. Yes we know you hate everything written in C with great passion. This has been made apparent and banged on our heads for the past several dog- years. Did anyone bother to look at the sheer amount of refactoring the author & team did? Did anyone realize how difficult this is and what they might learn from this tarrasquesque ordeal they went through? Oh no, apparently it is C and logic mandates that Rust supercedes it so why.the.hell.bother.

<comment><USER21> The huge discussion about Rust is because that's literally what this post is about. It's titled "Getting Past C" and most of the post is about considering Go or Rust as the future language for the project. And, not surprisingly, a lot of people think Rust is a great choice for this (and I agree).

<comment><USER54> The title is Rust-bait so let's all chant rust! Rust! RUST! Oh but there are only three tentative mentions of Rust in it and this entire comment section is corroded. Just compare the two pages in a browser with ctrl-f rust

<comment><USER55> I'm not sure where you're under the impression that the number of times something is _explicitly_ mentioned corresponds directly to the number if times it's being discussed, which is what is implied by your suggestions to search for occurrences of the name. The whole article is about future plans for NTPsec, and the work going into making it so it can be converted to a new language later. The article is about the relative merits of different languages for this task, and Rust is one of the languages. Of course Rust is going to be talked about in the comments. The only odd thing here is that Go isn't talked about more in the comments, not that Rust is talked about a lot.

<comment><USER54> For me, this is the gist of the article:

>> But NTPsec is a lot smaller and cleaner now at 62KLOC of C (that's just 27% of the original size). It's been brought up to pretty tight C99/ANSI standards conformance, and the few remaining platform dependencies are either already well isolated or can easily be made so.

Then they have a section about future plans and a short comparison of two possible languages. I'm surprised that you're surprised Go is virtually non- existent in this thread.

Hackernews comment sections are strictly for endlessly typing about Rust's memory safety features to seemingly no end. You will find this behavior under any article that mentions C or C++.

At this point I don't care about downvotes because the whole finding-valuable- comments-to-learn-from experience I've had in the past is getting harder and harder to attain to. So instead of bitching about that, I will just go upvote someone who is downvoted.

<comment><USER21> Maybe you should learn from the fact that so many people are talking about Rust.

<comment><USER54> I did. See above comments.

</comment></comment></comment></comment></comment></comment></comment><comment><USER56> >Under Linux, some SECCOMP initialization and capability dances having to do with dropping root and closing off privilege-escalation attacks as soon as possible after startup.

Thanks, Eric. Now, FFS, learn how the Cathedral model WORKS, get OpenBSD, learn pledge(2) and stop spreading old FUD against C.

</comment><comment><USER57> > One of the medium-term possibilities we're seriously considering for NTPsec > is moving the entire codebase out of C into a language with no buffer > overruns

For a small one time fee of 1000 USD I can copy paste you 50-100 lines of C that provides an implementation of an array without buffer oveflows. Cheaper than switching to rust or you know, learning C properly.

<comment><USER58> Can you pass this buffer to e.g. read() and it will still guarantee no buffer overflow even if the programmer mis-calculate the size argument to read() ?

<comment><USER59> I'll bet he can give you an array_read() function that does what you ask. I know I could.

<comment><USER57> The fact that it doesn't occur to people to build safe abstractions in C to deal with things like buffer overflows still shocks me. C is fairly low level by todays standards. You 100% have to build abstractions using the standard library and then use those abstractions, rather than just using standard library functions everywhere.

This isn't an argument against safer languages, or higher level languages, or languages with built in bounds checking or anything else. This is more an argument against programming in a "close to the metal" language like C so thoughtlessly that buffer overflows are actually a serious issue.

Maybe you just need a pedantic mind. When first learning C, as soon as I figured out that writing "char buffer[BUFFER_LEN];" could cause your program to crash, I immediately set out to write a safe dynamic array implementation I could push chars onto it and I didn't have to worry. And I am by no means an expert C programmer.

<comment><USER60> Is this abstraction zero-cost? What's the overhead?

Can you give me a similar set of primitives to manipulate memory in a temporally safe manner as well? What is the cost of that abstraction? How does it compare to a runtime's GC?

<comment><USER57> I never made the argument that you shouldn't use a safe GC'd language. I merely made the argument (now flagged for whatever reason) that buffer overflows are an easily solvable issue in C, and if you are having issues with them you really need up your game and learn to create abstractions.

As for the _cost_ of the abstraction of bound checked arrays of arbitrary length, I can't imagine it being any slower than rust. I could be wrong. If you'd care to provide an example program in whatever language you are advocating, I can give you an implementation in C using a bounds checked array ADT, and we can compare notes.

<comment><USER8> Obviously, if you have to check an index length you're going to be doing a branch. However, because the index checks are intrinsic to the Rust compiler, it can _remove_ them when it proves the code is safe. So, for instance, an iteration loop over an array won't have any index checks in the generated machine code.

<comment><USER61> There's two problems with this statement:

\- index checks aren't intrinsic for all cases where it is done, e.g. [https://github.com/rust- lang/rust/blob/8f62c2920077eb5cb8132...](https://github.com/rust- lang/rust/blob/8f62c2920077eb5cb81323142fc5dbe6ae8813c0/src/libcore/slice.rs#L610-L618)

\- being intrinsic is absolutely not required for the checks to be removed. Bounds checks are just a normal branch with a fairly straight-forward condition, and the always-true nature of those conditions is inferred in the same way for both the built-in indexing and non-built-in indexing. This is true in languages other than Rust.

An iterator is designed to just not do any indexing at all (neither using the built-in [] operator or one of the functions that implements manual bounds checks), because it instead just manually (unsafely) walks a pointer along the array.

<comment><USER8> > An iterator is designed to just not do any indexing at all (neither using > the built-in [] operator or one of the functions that implements manual > bounds checks), because it instead just manually (unsafely) walks a pointer > along the array.

It obviously still has to bound-check that it's not about to walk right out of the array. If you want to call this something other than a "bound-check", I think that's being overly pedantic.

<comment><USER61> Yes, it checks that it's reached the end of the array as part of the loop, in the same place that `for (int i = 0; i < n; i++)` checks whether it's reached the end of the loop. I think this is different to the indexing bounds checks we've been discussing since the whole process is more controlled (compare and increment a pointer), rather than taking an arbitrary integer.

But yes, strictly speaking you're right, an iterator does do check when it's reached the end of the array, it just doesn't do any indexing nor does it use the indexing checks built into the compiler (which is what you implied the iterators benefit from).</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


I don't code. Here's my project: Notepeep.com - <AUTHOR>

Site Link: http://www.notepeep.com
Site Description: A place where you can anonymously write about, rate, and comment on people, places, and things.
Hello everyone,
I don't really code. I have an extremely limited understanding of PHP and I get the basics of HTML/CSS. But, I've come up with Notepeep.com entirely on my own given my resources. I tried out a few popular CMS installations and eventually found that I could push WordPress and its plugins in a way that allowed my site operate like I wanted it to.
I know it's certainly not optimized/perfect. I'm sharing it now as I just want to show technical founders and those of us here not technical what a non-technical person can come up with given the amount of resources available to us.
Thanks for your time. I really appreciate your comments/feedback! <comment><USER2> Nice work mathewsi. This is exactly what I would want to see out of a "business" guy with an idea. Do what you can, evangelize your idea.

Definitely one of the better ways to inspire a developer. And, as a developer, we're also better able to understand what the site COULD be than the average person you're showing it to. Bravo, keep at it!

</comment><comment><AUTHOR> Clickable Link: <http://www.notepeep.com></comment>