Threads for bjorn

  1. 6

    That with the lambdas makes for a very powerful new set of features in Java 8. It’s almost a new language.

    1. 2

      That giant 150 line switch statement must have massive mccabe score. Also not sure this class is really a type in the concept of OO. Why does a BitCoin know how to write out plain text HTM? Also the queries in a loop rankle me, but whatever. I’ve written my share of questionable code, so not really judging, just noting. ;\

      1. 1

        I totally agree with the sentiment about writing questionable code, all great engineers have done it.

        But with 700,000 BTC on the line I’m going to lean towards trying to make the code as ‘unquestionable’ as possible. That probably would’ve been a good idea. It would probably be cool to see what kind of approach Mt.Gox took towards testing.

        I’m still an intermediate engineer, I should probably also leave the judging to the masters.

        1. 1

          Mt. Gox was a $400M company that pushed most changes live without a testing environment.

          Using God classes and plenty of mutable state makes it near impossible to unit test.

      1. 2

        The biggest obstacle left is video. Look at Twitch for example, it uses a flash app for streaming video. Amazon and Netflix use Flash and Silverlight (a flash alternative) for video because of DRM issues. WebRTC doesn’t help Twitch because it requires the other end to also share their audio and or video. What’s left on the HTML5 side are TCP websockets and the audio element which is not great for HD streaming on the scale that Twitch does. DRM in HTML5 is a contentious issue. On mobile, these things aren’t issues because you can use a native app to get around holes in HTML5. So until these two problems are solved for the web, Flash will remain.

        1. 1

          Just a minor nitpick… I don’t think Twitch relies on Flash for streaming. I can bring up live streams from the website (as in: running in Chrome, not the Twitch app) on my N5 (no flash there) without issue.

          1. 1

            How would twitch be delivering HD video to an HTML5 page? That has to be either low quality video over TCP websockets or it’s some other kind of thing.

            1. 1

              They use HLS? I mean, that’s how most video streaming is done these days.

              1. 1

                Ah, looks like that isn’t in desktop chrome yet but it is on mobile devices. http://www.jwplayer.com/html5/hls/

                Doesn’t look like it will ever come to Chrome:

                https://code.google.com/p/chromium/issues/detail?id=54198

                1. 1

                  That’s a shame, but not surprising. HLS is ugly, but the alternatives are much uglier.

        1. 2

          Question, is a self-signed cert better than no cert? Seems like no, since anyone would be able to add whatever cert they wanted if they MITM yeah?

          1. 2

            A self-signed cert is good in that it allows any HTTPS connection at all. Savvy users can get the cert though a secure side channel and pin it to get server authentication without going through a CA. Downsides are that for any users not savvy enough to acquire and pin the certificate (which is for most of us all users), it’s fake security since there’s no server authentication, and web browsers spit out scary horrible warnings on self-signed certs since the most likely use case is a MitM attack.

            1. 3

              I think the self signed cert -> mitm attack logic is itself a consequence of the fact that self signed certs have been made useless by the browsers. I.e., it is what it is.

              I use self signed certs in a few places, but not on my website because if I use a self cert people will whine I’m an idiot who doesn’t know anything about security. Instead I use no cert and that’s somehow better. (I have strong feelings about the CA cabal and will not endorse them by using a “properly” signed cert.)

              There is currently a debate raging about the value of opportunistic encryption and passive vs active adversaries. Personally I think passive sniffers are more likely to be found in a Starbucks than active mitm attacks. Monitoring traffic is easier than injecting it, at every level from free wifi to undersea cables. Cert pinning will hopefully make mitm a very risky proposition.

              The question is if false sense of security becomes false security. I don’t know. I lean towards opportunistic encryption is strictly better than no encryption, but I can understand the argument that it’s not.

              1. 2

                That’s why I’ve found that, in practice, they’re essentially worthless for any “production” site. The other trick is that secure side channel; many times, that secure side channel doesn’t exist; it’s a chicken-and-egg problem.

                1. 2

                  The secure side channel doesn’t strictly need to be such. Really, all you need is a channel that’s secure now. Ok, fair enough, you have no way of knowing that, but if you download the cert in the clear…

                  The attacker has to mitm that connection and they must mitm every future connection for all time, or you will detect the cert mismatch. And they need to only mitm your connections, and not anybody who does happen to acquire the cert via other means.

                  Now look at mitm attacks in practice (pre-pinning). They use a compromised CA to inject a trusted cert that works today, but then they can stop at any time. The whole chain of trust thing makes the attack invisible.

              2. 1

                Nearly always, it’s not, and it’s because of that MITM.

              1. 3

                I think this article is more about rolling your own algorithms, but some people say you shouldn’t even try to implement proven algorithms on your own. The Go people rolled their own crypto. A lot of the Go stuff in the go-lang packages is in go. Like gpg, TLS, etc:

                http://golang.org/src/pkg/crypto/tls/tls.go

                http://golang.org/src/pkg/crypto/cipher/cbc.go

                https://code.google.com/p/go/source/browse/openpgp/write.go?repo=crypto#29

                etc

                Seems to be OK. Does anyone think that stuff is insecure? Rust devs have said they wouldn’t implement any crypto code, they would use proven C

                1. 4

                  The Erlang team implemented their own SSL in the last few releases. Obviously the number of bugs in the erlang-bugs mailing list related to SSL went up. That isn’t to say that it’s different than any other new feature in terms of finding bugs. The problem I see with a lot of encryption is that it can take years to find a mistake. Which might be ok, assuming nobody figured it out significantly earlier than the good guys. But still, I’m always very skeptical of homerolled encryption. Go might be the best off since it’s so popular it probably has the yes of some respectful people on it. But meh, I dunno….

                  Is anyone doing anything to replace OpenSSL in C? The OpenSSL code, AFAIK, works out of brute force, not out of being done well. A new core layer would probably be appreciated, but it’s a ton of work.

                  1. 3

                    The primary author on Go’s crypto/* packages is Adam Langley, who is a world-class cryptographic engineer.

                    1. 1

                      Even the Go people don’t roll their own algorithms. There’s a significant level of risk in implementing standard cryptographic primitives, but you can test them extensively against other implementations, be careful about timing attacks, study the literature, and manage that risk. It’s something to worry about, but it’s not a sign you should run away screaming.

                      Rolling your own algorithms, though, leaves you deep in uncharted territory, and is something you probably should not do without hiring a large group of experienced, well established cryptographers to try to break your system. Even then, you should be considering running away screaming.

                    1. 7

                      While the body of the article is correct, the title of the article will be misused as an argument against using KDFs by people who haven’t read the article, since the KDF will salt and hash your passwords.

                      1. 2

                        I agree the blog title is misleading, but how do you use a title of an article in an argument? I think the danger is that someone will see the title, not read the article and stop salting and hashing passwords I think that’s unlikely though, because what would they do instead? Store a password in plain text because they saw a blog title?

                        1. 2

                          I’m imagining this conversation:

                          Les: Hey, we’ve been storing our passwords in plain text in our database. That’s bad. We should use bcrypt instead, because I’ve heard it’s more secure.
                          Chris (defensively): Well, what we have now works. What does bcrypt do?
                          Les: It salts and hashes the passwords so that even if an attacker steals a copy of the password database it’s okay, somehow. I don’t really understand.
                          Kit: But everyone knows that if you’re salting and hashing your passwords, you’re doing it wrong.
                          Les: You are? I thought that was the best practice.
                          Chris (vaguely remembering): No, it’s a bad practice. How’s that feature you were going to deliver today coming along?

                          Maybe this sounds implausible to you, but I’ve worked at jobs where I’ve been told, “Curiosity on the job just gets you into trouble,” “Assert statements are a bad practice because it’s bad when your code makes assumptions,” and “Don’t tell client SMEs that we should delete their unused code.” (Instead, we modified the unused and non-working code in parallel with our other changes.)

                          1. 1

                            These people shouldn’t be writing any kind of software ever.

                            1. 1

                              You were one of these people when you first started programming. Maybe for three months, or six months, or a year. If it wasn’t longer, you were lucky. I was stuck at that level of incompetence for fifteen years.

                            2. 1

                              Tell them bcrypt salts and slow hashes the password.

                        1. 1

                          This should have also been tagged as news. There is very little detail about networking specifics in the blog post.

                          1. 2

                            Except the “news” tag is no longer available. https://lobste.rs/s/yf80h7/remove_the_news_tag/comments/1wdbht

                            1. 1

                              Hrm, then maybe it shouldn’t have been posted. How could I have filtered this out?

                              1. 2

                                7 other people disagree with you.

                                1. 3

                                  I don’t have an opinion on whether this article belongs on lobste.rs, but I agree with bjorn that the “networking” tag is a stretch.

                                  The guideline on the submission page is:

                                  If no tags apply to your content, it probably doesn’t belong here.

                                  If this story belongs here then maybe we’re missing a tag? Or maybe the description of the “networking” tag needs to be clear that it includes things like this?

                                  1. 3

                                    If we still had a news tag I’d have tagged it with that as well, but an article discussing peering agreements, bandwidth, and CDNs is still “networking” to me. Perhaps it’s just my experience working at an ISP.

                                    1. 4

                                      Clearly what’s needed are “off topic” and “low quality” tags, so you can preemptively tag your submission and have users filter it.

                                      1. 1

                                        I think an offtopic tag is a good idea, as OT discussion will inevitably occur. Having a single bucket for it keeps everyone on the same page.

                                        Stack Overflow rules are a good example of how not to do this. They kept shuffling OT content around: first to Programmers, then Meta, then they opened the floodgates with the StackExchange network. Then they made “chat”, which nobody liked. Despite the rules, OT content kept appearing.

                                      2. 1

                                        Fair enough - maybe the description could be changed to “Networking & networks”? Then it’s a bit clearer what it includes, and it’s obvious that it excludes the business sense of the word.

                                  2. 1

                                    Yeah so whoever marked my comment as “troll” obviously doesn’t understand the meaning of the world “troll”.

                              1. 2

                                A neat social trick might be to include an option for “I don’t like this” and to only show that downvote to the user, but not actually use it to calculate the score. Even though we’ll know this, we’ll probably still choose it because it solves a psychological need to mark something as bad, even though it won’t tell anyone else. I actually have found the “low quality” option useful, because some links have been pretty low quality.

                                1. 5

                                  btc’s suggestion of having a two-axes, one for quality, one for agreement, is a better solution in my opinion. It would show you both what people think of the quality of what you’ve submitted (like is it well or poorly written, does it actually have some content or is it all fluff) along with their opinions on it (just a do people like/agree with this, or not?).

                                  1. 2

                                    I missed that idea. I like it a lot.

                                1. 2

                                  Error handling in go is really noisy and verbose. err checking everywhere. It’s similar to Java and checking for nulls all the time. I really don’t like this style. I don’t know why go and Java have constant error checking where as in my JavaScript or Python it’s never much of an issue.

                                  1. 12

                                    Feels natural, but I come from a C background.

                                    1. 13

                                      I come from a try catch background in java and python and I welcome the error handling. I’ve been ignoring errors for far too long. It’s time for me to step up and be a responsible developer.

                                      1. 1

                                        I would argue that a language where exceptions are thrown is a much safer environment to work with than one where exceptions don’t exist: The thing is. Yes. We all should be responsible developers, and yet we all make mistakes.

                                        Yes. An uncaught exception will cause your program to terminate, but that’s not a bad thing. An unhandled exception is a spot where you screwed up and more often than not, your program is now in an inconsistent state and code that runs in the future and depends on the operation that just failed might also fail in inconsistent ways.

                                        When your program terminates, then you know for sure that no further damage will be done.

                                        I like that safety net. I much rather crash than destroy even more stuff as a consequence of missing checking for a possible error condition.

                                        Exceptions also help a lot in keeping different components of a bigger application separate as you don’t have to manually propagate errors back up the stack. And when you have a good semantic hierarchy of exception classes, you can handle a whole lot of error conditions in one fell swoop.

                                        In the web application I’m working for, I can throw a semantically named NotFoundException, no matter where in the framework it happens and I can be sure that this will eventually be turned into a 404 error for the client. No matter how deep down the stack I am: My method there and then failed to find something? Throw a NotFoundException and it will be dealt with.

                                        Especially in the cases where I really can’t do anything but show an error page, I don’t have to add error checking all the way up the stack from where I am. Error handling is constrained to two places: Where the error happens and way up there in the request handler where it’s turned into a nice error page (and a HTTP error). All the pieces in between don’t need to care and thus read much nicer.

                                        I think that’s very convenient and I really fail to see how this can be bad design.

                                        1. 1

                                          It’s actually pretty difficult to accidentally ignore an error condition in Go. The compiler throws out a lot of complaints. You can suppress the errors, but you have to pretty explicit about it.

                                          But yeah, exceptions actually would be pretty nice (as long as you are forced to explicitly catch or throw them, as in Java). I think Go uses error codes instead because it encourages you to handle errors at the source instead of waiting for it to propagate out. In my code, I usually just do something like

                                           err := functionThatCouldError()
                                           if err != nil {
                                               panic(err);
                                           }
                                          

                                          This has basically the same effect as an exception in Java or Python. The program exits immediately with a nice stack trace. Although I guess this does require me to type 3 extra lines.

                                    2. 7

                                      Because Go doesn’t have JavaScript’s ability to attempt to coerce things into whatever-the-hell-JavaScript-feels-like-doing-right-now, or either of their dynamic type system where things can be added to other things whenever you feel like it.

                                      Python and JavaScript both have exceptions, and using try/catch when you’re running something that could do less than wonderful things is a good idea. Consider a case where you’re getting input from across the network, and you want to make sure something’s actually an integer. In Python you can’t just run type(variable) is int, because it came to you as a string or bytes. You need to cast it, but casting can cause a ValueError.

                                      Having exceptions bubble up and kill your program is typically a bad idea. You’d want to handle that, and the way to do it, in both JavaScript and Python is using a try/catch block.

                                      Go’s use of err everywhere is used instead of try/catch blocks. It makes you deal with errors when they happen, instead of letting them bubble up and be handled later. I think that’s nice. It’s much more explicit than a block at the end of your code that says “some sort of error could happen, and if it does, lets try something”.

                                      1. 4

                                        Yea, I definitely like the error handling better than I thought I would when I first started learning Go.

                                      2. 4

                                        Are you saying that handling any possible (or probable) error is a bad thing?

                                        Also, last I checked Java’s error trapping was exception-based.

                                        1. 4

                                          Because of Java’s “checked exception handling”, which I think we can probably agree at this point was a failed experiment, you end up having to explicitly wrap exceptions at the point where you call an API that generates them. At the extreme, you have things like this (testData is a string, and this is in a test case):

                                              InputStream in;
                                              try {
                                                  in = new ByteArrayInputStream(testData.getBytes("UTF-8"));
                                              } catch (UnsupportedEncodingException e) {
                                                  throw new RuntimeException(e);
                                              }
                                          
                                              for (String line : new LineIterator(in)) {
                                                  p.dispatchLine(line);
                                              }
                                          

                                          If it weren’t for the checked exceptions, in wouldn’t even need to be a variable; it could be inside the for-each thing. bjorn could have been saying, and correctly in my experience, that Golang’s multiple-value returns for errors result in you having to write similarly sequential code.

                                          However, I don’t think this is as bad in Golang as it is in Java, because the big problem with it in Java is that any new exception that can appear in some library you’re using must ripple upward through exception specifications, unless you wrap it like I did above. So a small change in one place can result in the need to make many functionally meaningless changes in many other places.

                                          What I think bjorn is actually saying, though, is that it’s like how in poorly written Java you have to check for null all over the place, because lots of things that are supposedly a value of some type are instead null, especially failure return values. I think this is probably true of poorly written Golang, too.

                                          1. 4

                                            I’ve always wondered why Java’s checked exceptions get such a bad name and this is a great example, thanks.

                                            I never understood it because I spend a lot of time programming Haskell where the convention is heavily in favor of various kinds of “checked exceptions” in that it’s very often impossible to use values which were created in failing contexts without either bubbling failures upward or handling them.

                                            The difference is that Haskell has Functor/Applicative/Monad interfaces which allow you to compose failing contexts and the values within in much more sensible and syntactically light manners. Oftentimes it’s not terrifically difficult to “check” all of your exceptions upon calling an API since you just want to glom them all together and float that new failing context upward—and that’s just (<*>).

                                            I don’t think Haskell’s notion of errors is completely successful. At the very least there’s a lack of strong cultural conventions which causes a proliferation of error types. Successful error handling thus becomes a small mire of mapping between various kinds of error types (Maybe, Either e for various e’s). The exception system provides slightly more strength of convention, but it’s broadly frowned upon since you now have to suspect every line of code for failures again.

                                            Anyway, that’s my two cents and a bit of an epiphany thanks to your code snippet here. I’d encourage anyone interested in learning more about Haskell’s error types to look at the errors package [0] which has a large number of “mapping” and “code pattern” combinators for error handling.

                                            [0] http://hackage.haskell.org/package/errors

                                            1. 1

                                              I’m glad it’s a helpful example! But I think it’s kind of an extreme case. Most of the time the code needed to cope with Java exceptions isn’t this bad. (For example, most exceptions you have to handle can actually arise, unlike this case.)

                                              I haven’t tried Haskell, but it sounds quite a bit more pleasant. Thank you for the reference!

                                          2. 1

                                            Yeah, this is the answer. The alternative is to just error out whenever an exception happens (which is more or less what Python does). That might be OK for a simple script. It’d be pretty disastrous if you are writing a long-running server.

                                            1. 3

                                              In Python your server’s top-level loop can catch and log arbitrary exceptions, so that’s not really a huge problem with Python. The deeper problem, I think, is that exceptions can’t convert failure into success; they just let you determine what kind of failure you want to have. But in a language with exceptions, nearly every line of code can fail. It’s just implicit. (In a language with operator overloading and run-time polymorphism, like Python, essentially every line can fail.)

                                              Writing code that handles, and especially prevents, every possible error requires a different mentality. You can do it in Python, to some extent (though running out of memory is pretty hard to guard against) but the fact that all those possible errors are invisible in the source code doesn’t help at all. If instead you have to write extra code for each thing that can fail, then you know what those things are, and you also have an incentive to minimize them — to make parts of your code that simply can’t fail.

                                          3. 4

                                            Sorry to bring up a meta discussion, but why are people downvoting bjorn’s comment?

                                            Error codes vs exceptions is an ongoing debate and everyone has their own reasons for liking one over the other.

                                            Go’s error handling is verbose.

                                            0 points.

                                            I’m used to error codes from C.

                                            11 points.

                                            Why are people downvoting an opinion they don’t agree with?

                                            1. 3

                                              Because that’s not all of bjorn’s comment. bjorn’s comment mentions that Python and JavaScript don’t have as verbose error handling, but that’s mostly because there isn’t compile time checking to make sure you don’t do anything that could cause an exception without dealing with it somehow.

                                              You should still deal with the exceptions in Python and JavaScript, but because there’s no note in the code itself that says “this might cause some problems” you aren’t typically away that those could be problems until they become problems.


                                              That said, I didn’t downvote bjorn’s comment, I just think bjorn’s opinion isn’t well formed, or is ignoring why Java and Go deal with errors the way they do.

                                            2. 2

                                              I have been using go for a while now, and I actually don’t mind the error checking. I am used to explicit-ness in other things from my Python days, so maybe that is why it doesn’t bother me, but I actually enjoy being able to handle the error where it happens

                                              1. 2

                                                I spend 40+ hours a week in Python land, and I generally enjoy it very much. While I don’t mind Python-style exceptions when I’m responsible for most or all of the code I’m working on or maintaining, often it’s hard to predict what your various dependencies are going to throw at you. With Go, error handling is so explicit that you are more or less forced to know what’s going on, which I like.

                                                Go/C-style error handling is a lot more verbose, but it’s refreshing being 100% aware of the error cases and what is going to potentially be sent your way. With Python, you don’t know unless the documentation, unit tests, and the organization of the source code is good.

                                              1. 2

                                                Interesting feature I didn’t know about, but I’d probably look at etcd or zookeeper for distributed locking. I actually haven’t seen an architecture that included multiple instances of rabbitmq, every time it’s just one queue, a single point of failure.

                                                1. 3

                                                  IMO, RabbitMQ clustering does not handle network partitions well. It possibly requires a human to decide which RabbitMQ is golden.

                                                  1. 2

                                                    RabbitMQ supports “autoheal” mode for clustering: https://www.rabbitmq.com/partitions.html

                                                    1. 4

                                                      And the semantics of “autoheal” are absolutely terrifying.

                                                      1. 2

                                                        You are always welcome to suggest improvements for RabbitMQ. Here’s our mailing list: https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

                                                        1. 3

                                                          I think the overall semantics of RabbitMQ clustering make providing a reasonable alternative extremely difficult. Instead I prefer to simply not make use of clustering and use Rabbit has a transport.

                                                  2. 2

                                                    Have you been following the news?

                                                    See the New York Times architecture for example, completely distributed around many RabbitMQ Instances:

                                                    http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2014-January/032920.html

                                                    Instagram uses a lot of RabbitMQ, many more companies do. There are many use cases cited on the Pivotal blog, but I don’t want to get “commercial” in this forum.

                                                    1. 1

                                                      It’s worth pointing out that “having a single point of failure” has nothing to do with RabbitMQ or any other software tech for that matter, it’s about how whoever setup that architecture decided to go about each software component.

                                                    1. 2

                                                      Stuff like this makes me really unhappy:

                                                      1.1 + 1.01

                                                      2.1100000000000003

                                                      Especially when I want some kind of versatile way to display that information according to units. Money, uptime, etc.

                                                      1. 6

                                                        Always work in cents, seconds, etc. Units small enough to not need further division.

                                                        1. 3

                                                          Isn’t the issue that all numbers in javascript are floats? As soon as you use division, you may have a problem even if you’re trying to keep everything in ints.

                                                          1. 3

                                                            If you divide integers without thinking, you won’t get good results either. 3 / 2 == 1.

                                                            Real world quantities are rarely infinitely divisible. You always have to think about the remainder and where it goes, regardless of the representation your computer uses to perform the calculation.

                                                            Trivial example: 3 roommates split the $1000 rent. If they each pay $333.33, they’ll come up a penny short. Whatever process the roommates use to decide who pays the extra penny, you have to add that code to your rent splitting computer program. It’s not going to happen by magic.

                                                            The problem is not floating point, per se; it’s omitting the large part of the process that deals with edge cases when translating the real world into a program.

                                                            1. 1

                                                              The problem is not floating point, per se

                                                              That’s not my point. The grandparent post said:

                                                              Always work in cents, seconds

                                                              In js, if you pretend to try to use int’s you get:

                                                              <script>
                                                              
                                                              var cents = 100;
                                                              
                                                              var splitBetweenThreePeople = 3;
                                                              
                                                              var split = cents/splitBetweenThreePeople;
                                                              
                                                              alert( split); // 33.333333336
                                                              
                                                              </script>
                                                              

                                                              So working in “cents, seconds, etc” fails. It just fails differently than you expect if you’re expecting JS to be using integer math.

                                                              1. 1

                                                                Buggy code is going to be buggy. A better exercise is to try writing correct code. The correct version of the above isn’t too difficult. Then compare that to writing the same code but using an amount of 1.00 dollars.

                                                                Working in cents doesn’t automatically make the code correct, but at least it allows you to write correct code.

                                                                1. 1

                                                                  So, what’s the correct version of the above? I don’t know JS very well; I’m curious.

                                                                  1. 2

                                                                    Calculate the split and remainder, then distribute the remainder afterwards.

                                                                    cents = 100
                                                                    splits = 3
                                                                    share = Math.floor(cents / splits)
                                                                    remainder = cents % splits
                                                                    for (i = 0; i < splits; i++)
                                                                        people[i] = share
                                                                    while (remainder--)
                                                                        people[remainder]++
                                                                    

                                                                    This will give you people = [ 34, 33, 33 ].

                                                                    Trying to do this with dollars is impossible because you can’t store either 0.33 or 0.34 in a float. The best split that can be accurately represented would be 0.25, 0.25, and 0.50. (You could come close by allowing fractional pennies. 0.3125, 0.3125, 0.375 add up to exactly 1.00, but you still have the problem that nobody has fractional pennies and rounding after the fact is extremely error prone.)

                                                        2. 4

                                                          when you need a perfectly accurate representation, with a known level of precision (like money, or uptime), fixed point numbers (or at least some take on the concept, a la twips) would be your best bet.