Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Grappling with Go

blog.ntpsec.org

Post reply on HN
Print view View original

101–110 of 118 posts

Re: Grappling with Go

#101

Post by MichaelGG »

codygman wrote: post #90
MichaelGG wrote: post #70

Earlier quoted context omitted.

Safety is hardly a trend is it? GC'ing everything makes safety rather much easier. Go doesn't go beyond Java level safety or really any of many earlier "managed" languages. Does Go offer safety above, say, PHP? Rust not only does all that, it provides data race safety, and does so without a runtime or tracing garbage collector or real performance sacrifices. All while maintaining C linkage for zero cost interop. I ca…

> Go doesn't go beyond Java level safety Go doesn't reach Java level safety because of a lack of generics.

Well it's still memory safe though, right? You'll just get a runtime error, not memory corruption.

Re: Grappling with Go

#102

Post by pjmlp »

oblio wrote: post #78
zzzcpan wrote: post #48

Earlier quoted context omitted.

But if you could learn some things from the history and use that to your advantage, why wouldn't you? Everyone would be doing so. And yet somehow it doesn't work like that, outdated things are in fact outdated and you can only take away very little from them. Things that were designed with trade offs for very expensive slow synchronous machines during the times when programmers were not bound to languages, because ev…

> But if you could learn some things from the history and use that to your advantage, why wouldn't you? Everyone would be doing so. Hah! Reasons for not learning from history: * history is hidden behind NDAs, bad licences and patents * history is hard to access due to its environment (printed on out-of-print books, stored on tapes, HDD and other forms of storage in someone's basement) * history is written in a progra…

True, but many of those hurdles are easy to overcome when one is curious about history of computing, specially since many libraries have been scanning old books and papers.

For example, I have collected the majority of Xerox and DEC research papers that I could get hold of.

Re: Grappling with Go

#103

Post by dcu »

j1f4 wrote: post #89
dcu wrote: post #79

Earlier quoted context omitted.

I'm not seeing any changes in my results. I'm testing in an old laptop, I guess that's why it's so slow. My rustc version is 1.15.0 and go 1.8.

If you are running the program with `cargo run` that takes the same --release flag. Could be the machine difference though.

I'm not. Are you testing with go 1.8 btw?

Re: Grappling with Go

#104

Post by stevekemp »

jerf wrote: post #45
stevekemp wrote: post #27

I continue to be surprised by the sheer amount of writing we see about ntpsec. The project was started over two years ago, and yet progress reports seem very optimistic and self-congratulatory, despite an obvious lack of progress. Sure rewriting "bits" of things, with more features, and adding my python sounds useful. But here we are 500+ days since the project started and there are only minor experiments in moving f…

What progress are you looking for? There seem to be downloads here, posted pretty regularly: ftp://ftp.ntpsec.org/pub/releases/ I don't know if they build and work, but I'd suspect they do, based on the refactorings being discussed. The commits seem to be clicking along. A diffstat of roughly where I think they branched off of ntp vs. master takes a moment to poke through, because the raw stats are "1032 files change…

Downloads have always been available, as this project was started by taking an existing one - then trying to cut down on things that were insecure, bad, outdated, or similar.

In short this project is very like the forked openssl project. Progress has been made, I can see it, but I think taking two years to turn some existing code into something cleaner is .. surprising.

Especially now that the focus seems to be throwing it away, and starting anew in rust / go (though based on recent updates go seems to be the choice).

Re: Grappling with Go

#105

Post by groks »

tptacek wrote: post #57
jerf wrote: post #45

Earlier quoted context omitted.

What progress are you looking for? There seem to be downloads here, posted pretty regularly: ftp://ftp.ntpsec.org/pub/releases/ I don't know if they build and work, but I'd suspect they do, based on the refactorings being discussed. The commits seem to be clicking along. A diffstat of roughly where I think they branched off of ntp vs. master takes a moment to poke through, because the raw stats are "1032 files change…

They started with Mills ntpd, so there have been downloads available since t0. There's a significant amount of code you can lose from a large C project just by getting rid of ifdefs that nobody uses, so the +/- line count isn't a great metric either. The true metric for success for something like ntpsec is the number of meaningful security problems ntpd has been vulnerable to since ntpsec's inception that ntpsec hasn…

> The true metric for success for something like ntpsec is the number of meaningful security problems ntpd has been vulnerable to since ntpsec's inception that ntpsec hasn't been.

They talk about 3 areas where bugs have been removed, including:

  Much of ntpd’s most convoluted code lives in ntp_proto.c, which
  implements the state machine central to the protocol. Of the 29
  vulnerabilities that have received CVEs so far in 2016, a couple
  of multi-KLOC functions in ntp_proto.c are responsible for 15 of
  them — just over half. Of course, "just rip it out" wouldn’t
  suffice in this case: this is core business logic, not junk code.
  So we rewrote those functions from scratch, cutting line count
  considerably and yielding a far more readable result.
https://blog.ntpsec.org/2016/12/13/fantastic-bugs-and-where-...

The other two areas are guaranteed bug-free because they removed the code.

Re: Grappling with Go

#106

Post by tptacek »

groks wrote: post #105
tptacek wrote: post #57

Earlier quoted context omitted.

They started with Mills ntpd, so there have been downloads available since t0. There's a significant amount of code you can lose from a large C project just by getting rid of ifdefs that nobody uses, so the +/- line count isn't a great metric either. The true metric for success for something like ntpsec is the number of meaningful security problems ntpd has been vulnerable to since ntpsec's inception that ntpsec hasn…

> The true metric for success for something like ntpsec is the number of meaningful security problems ntpd has been vulnerable to since ntpsec's inception that ntpsec hasn't been. They talk about 3 areas where bugs have been removed, including: Much of ntpd’s most convoluted code lives in ntp_proto.c, which implements the state machine central to the protocol. Of the 29 vulnerabilities that have received CVEs so far…

From this paragraph you might get the impression that ntpsec had dodged 29 CVEs in 2016. But that's not the impression I have: I think it has been vulnerable to many of the bugs reported in ntpd.

Further: not all CVEs are equivalent, so in addition to wanting to know how many vulnerabilities ntpsec was also vulnerable to, you also want to know what the distribution both of severity and of exposure in the default configuration those bugs had.

Ultimately: I feel about ntpsec the way I would have felt if, in 1997, someone had proposed SendmailSec. The answer to the Sendmail security problem wasn't a "hardened" Sendmail (though the Sendmail team sure tried); it was Postfix and qmail.

Re: Grappling with Go

#107

Post by tptacek »

brians wrote: post #87
tptacek wrote: post #83

Earlier quoted context omitted.

ntpsec isn't a project to revamp or cryptographically improve the NTP protocol; it's an attempt to do for ntpd what BoringSSL and LibreSSL are doing for OpenSSL.

Sort of. The NTS people appear to be ntpsec people: https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp... , and talk about how clearing out the crud (including unused modes) provides enough headroom for the work of adding security.

What you really mean to say there is that Franke is heavily involved both in ntpsec and in modernizing NTP protocol security. :) But the two projects are unrelated. I'm also interested in (and more optimistic about) things like AGL's roughtime:

https://roughtime.googlesource.com/roughtime

... but I acknowledge being somewhat mystified by how much complexity is in NTP given the very minimal needs virtually everyone I've ever worked with had for time synchronization. We all need it, but we don't need it to be ntpd-grade featureful. So this is probably a blind spot for me, and maybe roughtime is less promising than NTS.

Re: Grappling with Go

#108

Post by pjmlp »

xiaoma wrote: post #96
pjmlp wrote: post #13

Earlier quoted context omitted.

I know them. My point is that commercial failures of specific OSes have more to do with politics and economic games than capabilities of programming languages. As the OP was kind of insinuating just because many are too young to remember the OSes written in those languages, they should be ignored. Yet, so far none of the OSes being written in Rust or possibly Go, have achieved the same amount of users those old forgo…

> "As the OP was kind of insinuating just because many are too young to remember the OSes written in those languages, they should be ignored." No, I wasn't. It was an honest question. The only OSes I've used or had any experience with are Dos/Windows, MacOS, iOS, various Unix/Linuxes and the reaally old Commodores/Macs that just ran Basic. I was hoping maybe something I'd heard of wasn't based on C/C++.

Faire enough, so prepare for an history lesson. :)

Mesa/Cedar was created at Xerox PARC, as an extension of the Xerox Star 8010 system, which was programmed in Mesa, the language that inspired Niklaus Wirth to create Modula-2.

http://www.digibarn.com/collections/systems/xerox-8010/

https://www.youtube.com/watch?v=Cn4vC80Pv6Q

https://www.youtube.com/watch?v=ODZBL80JPqw Mesa evolved to Mesa/Cedar, which allowed for automatic memory management via reference counting and a tracing collector for the cycles.

https://archive.org/details/bitsavers_xeroxparcteCedarProgra...

The environment had a REPL and debugger inspired by the Smalltalk and Lisp systems at Xerox.

Think of Swift Playgrounds, kind of.

This system inspired Niklaus Wirth to create Oberon, which you can read about in his book, about how the OS was built.

http://www.ethoberon.ethz.ch/books.html

In 2013, Niklaus Wirth revised the language and updated the book for a FPGA based computer.

http://people.inf.ethz.ch/wirth/ProjectOberon/index.html

There were several generations of the Oberon OS, the last one before it stop being relevant, the Bluebottle OS coded in Active Oberon variant.

http://www.progtools.org/article.php?name=oberon&section=com...

It had a strange mix of UI, using a mix of text and mouse input. Basically all applications were dynamic modules and the procedures/functions with a special signature could be used from the UI.

So you could select text or objects from applications, and invoke such operations on the selection.

The Oberon System 3 and Oberon V4 with their Gadgets framework were the best experience, before AOS was designed.

Most relevant OS in Modula-3 was SPIN OS,

http://www-spin.cs.washington.edu/external/overview.html

There were a few others, this is just a small sample.

Re: Grappling with Go

#109

Post by j1f4 »

dcu wrote: post #103
j1f4 wrote: post #89

Earlier quoted context omitted.

If you are running the program with `cargo run` that takes the same --release flag. Could be the machine difference though.

I'm not. Are you testing with go 1.8 btw?

Go 1.7.4 and rust 1.14. Interesting discrepancy in the relative speeds of the tools we are seeing.

Re: Grappling with Go

#110

Post by sanjayts »

bborud wrote: post #98

I've changed my main language for doing work only a handful of times and it usually takes a few years of doing side-projects in a new language before I switch. For instance it took about 7-8 years before I switched to Java (and then only after establishing a programming style that doesn't rely on frameworks at all). The language wasn't hard to learn, but it took a while for the JVM and the standard library to get to…

Sorry if you saw this coming but do you really not miss generics and exceptions? I like Go given that it's a lean language and the compiles down to a self contained binary which doesn't consume gobs of CPU or memory and is pretty quick to start-up and run. Perfect language for writing command line tools and one-off network clients.

But I dread the feeling of writing repetitive error handling code and copy-pasta to get a simple generic functionality to work across data types. Maybe I should just consider it a better C and move on...

Post reply on HN