Java 7 changed the structure of String - <AUTHOR> http://www.javaspecialists.eu/archive/Issue230.html <comment><USER2> Based on all of the coding "best practices" books/blogs I've read, it is unwise to develop something which heavily depends on the internal implementation of the String class (or any library class). Many other commenters here are bemoaning the impacts the specific implementation of String will have on their existing applications. However, we should be designing based on the interface/contract presented, not specific implementation details of interfaces/libraries. Any optimization based on specific implementation details is "at your own risk."

If changes to the implementation of String could cause issues for you, you really should be using a custom solution anyway. A quick and dirty option would be to write a wrapper class which uses all of your preferred String hacks in a central location, and using that in place of String throughout your code. When String's implementation changes, you can update your hacks all in one place.

Here is some relevant advice from The Pragmatic Programmer: [https://pragprog.com/the-pragmatic- programmer/extracts/coinc...](https://pragprog.com/the-pragmatic- programmer/extracts/coincidence)

<comment><USER3> Algorithmic complexity should be considered part of an API, because it is not mere "internal implementation". It has observable effects from the outside. When a function in an API goes from O(1) to O(n), that should be considered a breaking change.

For the record, C++'s standard library has algorithmic complexity as a part of the API. See the analogous std::basic_string::substr: [http://en.cppreference.com/w/cpp/string/basic_string/substr](http://en.cppreference.com/w/cpp/string/basic_string/substr)

I've been bitten by std::list::size in pre C++11 code, as it was allowed to be O(n). But they were clear about it, the fault was mine. Now, it is guaranteed to be O(1): [http://en.cppreference.com/w/cpp/container/list/size](http://en.cppreference.com/w/cpp/container/list/size)

I think it's likely that the change to String.substring was actually a good one. But I also agree with others that it was rolled out poorly, and should probably not have been in a fixpack release, as from how I see it, they changed the API.

<comment><USER4> substring() was always defined in the 6 and 7 JavaDoc as:

"Returns a new string that is a substring of this string..."

Both implementations satisfy the API description so the API didn't change, the implementation did.

Optimizing your code based on the internals of a supposedly opaque data structure is a bad practice and if you get burned you only have yourself to blame.

<comment><USER5> In reality, performance often matters. Then there's no way to avoid needing to understand what the implementation does. The java6 implementation was a big, somewhat well-known gotcha. Read in mb of data in a String, substring a couple kb out, and tada! you're still holding all those mb.

You inescapably either:

1 - substring introduces a new string, creating lots of garbage since it's an incredibly common operation,

or

2 - substring saves garbage in many cases by having substring return sub- chunks of the full char array, but you will be unable to gc the full string as long as _any_ substring remains reachable

<comment><USER2> or 3 - stop trusting the internal String implementation to be as efficient as possible, write a wrapper you can update with the best method for the current version, never look back :-)

<comment><USER5> why not reimplement the entire standard library so you understand and control all the performance characteristics? This can be just like writing C in the 90s: start by writing a hashmap, a string, an arraylist or equivalent, etc. Because your code is sensitive to every common data structure you use.

<comment><USER2> Because, most of the time, performance doesn't matter enough to justify it. Custom solutions are only necessary if you know performance is critical to your application's purpose, and that you need to squeeze as much out as possible. If that isn't the case, then you don't need to worry about the implementation details, because, in general, any performance changes won't matter.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Here is an explanation of the change to `substring()`[0] and why it was done. The change was done in Java 7u6.

In short, the previous way of keeping the same underlying character array and just updating the {offset, count} indexes has a drawback in that if the original string is large, it is prevented from being GC'd if one keeps a reference to even a single substring generated from it.

So, it's a trade-off between the original and new behaviour; the original way more or less caps the memory usage at the size of the original string, but at the expense of not being able to GC it if even a single substring exists, while the new way increases memory usage for each substring generated but does not prevent any of the strings from being GC'd.

This is why the article's code example yields such a huge difference in memory usage in Java 6 vs Java 7; it is effectively a sort of "anti-pattern" when used against the new `substring()` method. (i.e. iterating through a large string and generating lots of sub-strings)

The article I linked to, which came out in late 2012, basically had the same advice:

 _" If you are writing parsers and such, you can not rely any more on the implicit caching provided by String. You will need to implement a similar mechanism based on buffering and a custom implementation of CharSequence_"

0\. [http://www.javaadvent.com/2012/12/changes-to- stringsubstring...](http://www.javaadvent.com/2012/12/changes-to- stringsubstring-in-java-7.html)

<comment><USER7> The thing I mind is that there is now no way to get the old behavior. String is a final class, so you cannot override it and add a field, even. You can roll your own - if there is no code you do not control that takes a string. (And if you don't mind having to write your own string class!)

And it being done in a "bugfix" release? That's unacceptable.

<comment><USER8> Given the pain that would be associated with rolling your own, why not make the case that a new method be added to the String interface that provides the old behavior? Legacy applications still need to change, but it would be a relatively straight-forward mechanical replacment.

<comment><USER9> That requires storing an extra two fields per String (int length, offset;), which is costly. Users who need constant-time substrings can simply implement their own class `Subsequence extends CharSequence` with a constructor taking a CharSequence and two ints. Users who need to pass a substring to a foreign function which only accepts String do need to copy, but that's not a major enough use-case to justify upping the memory usage of most applications.

</comment></comment></comment></comment><comment><USER10> I recently started to write an article describing how java.lang.String was one of the classes that the Java creators got mostly right in Java 1.0. This contrasts to other Java 1.0 classes such as java.util.Date, which, as the usage of Java spread, and some good practices emerged, revealed itself to be poorly implemented.

I wanted to show in my article how one of String's strengths is that String efficiently shares memory with substrings. But then when I looked into Java 8's String source code, I was surprised to find that this was not the case. It seemed I had been working with false assumptions for years.

Now, thanks to Heinz's article (OP), I discover that this was a change in the String class.

Long ago, a man who had been programming for 30 years told me about his theory of the half-life of programming knowledge being roughly 18 months. Today, Java has made me believe his theory a little bit more.

<comment><USER11> > Today, Java has made me believe his theory a little bit more.

I think Java is sort of an exceptional case here in that the language stays relatively stable and evolves very little over time. Also they tend to not change internal details of the standard library without reason, so even lots of things programmers _shouldn 't_ rely on, such as behaviour of substring() will stay unchanged for quite long.

Now JavaScript on the other hand probably has programmign language and framework knowledge half life of considerably less than 18 months ...

<comment><USER12> JS now is moving fast but for the longest time it was stuck in stasis with various incompatible implementations floating around. And almost any knowledge on it was probably invalid in one of those implementations.

</comment></comment></comment><comment><USER13> The article is an example of using an anecdote ("During our course, the customer remarked that they had a real issue with this new Java 7 and 8 approach to substrings") and a skewed microbenchmark to extrapolate to general advice.

The substring change was done to address common real scenarios, as the author of the change described here: [http://www.reddit.com/r/programming/comments/1qw73v/til_orac...](http://www.reddit.com/r/programming/comments/1qw73v/til_oracle_changed_the_internal_string/cdhb77f)

<comment><USER14> It does address common real scenarios. However, it also causes issues for other common real scenarios. For instance, say you have a CSV parser where you generally only look at a few columns. Under the old system, it wasn't crazy to implement this by, for each field, checking if any unescaping is necessary, and if not (generally the common case) doing a substring. This produces some garbage, of course, but manageable amounts. This approach abruptly gets _far_ slower under Java 7.

I can see why they made the change, but it absolutely did cause problems for real-world use-cases.

<comment><USER13> The way the change was distributed (in a bugfix release) and (mis)communicated was completely wrong, I definitely agree with that. As for the parsing example, yes, that's one way to implement this but definitely not the only right one -- if you care only about a couple of fields from a massive string, it depends on your application domain whether you can tolerate the additional memory bloat. What I like about the current behaviour is that the method is less surprising and more GC friendly

<comment><USER14> Oh, there are definitely other approaches to the problem I mentioned (and in fact approaches which are better than the naive split even under Java 6). Changing it out from under people should have been done a lot more carefully, though.

</comment></comment></comment></comment><comment><USER15> I would not have objected to releasing this change in Java 1.7. But releasing it in a BUG FIX RELEASE causes me to lose confidence in the maintainers of the JVM. One of the reasons that large companies like mine build in Java is because of Sun's long history of extremely careful attention to backward compatibility. Oracle is no Sun.

<comment><USER16> 100% right. Sun were psychotically obsessed with maintaining a completely stable and reliable and predictable platform for both the JVM & Solaris. This went out the window with Oracle for the sake of "innovation". The number of major incidents caused by cavalier changes in 1.6 & 1.7 is ridiculous. Youd be hard pushed to even find anything worse than a documentation formatting bug in 1.5.

<comment><USER10> I've been programming in Java since Java 1.1.8 and I hazily recall several regression problems under Sun's stewardship. My gut feeling is that the rate of regressions in Java updates has remained steady.

If the rate has increased significantly under Oracle's stewardship, this is something I'd like to write about in my Java newsletter.

Do you have some statistics to demonstrate that regressions have become substantially worse since Oracle took over Java? I'd happily acknowledge you as a source!

<comment><USER17> The only real one was System.getenv() which was stubbed out to a no-op in Java 1.3 and then brought back in 1.4.

</comment></comment></comment></comment><comment><USER18> Can't understand why people in this thread seem so ticked about this.

The author's observation is interesting and useful to know, but this is an edge case that is easily fixable and actually kind of the fault of user code, not the implementation or the spec.

Its not so simple to just say "I can't believe they changed the performance of xyz"... the author's article is about just one usage pattern, and there is no evidence presented to show it is very common compared to others. Developers needing specific behavior for this pattern could easily have used java.nio.CharBuffer which makes allocation/copying/access to the underlying array/etc explicit, and just happens to implement CharSequence. No reimplementation of String necessary.

In general, Java is not C or C++, and has never been billed as a platform where you could rely on the internal representation of anything unless it is specified as such. Even the same bytecode running on the same platform on the same machine can run differently if the hotspot compiler says Make It So. That of course assumes you are even using Oracle's JVM or OpenJDK... there are in fact other implementations of both the JVM and the standard library that are free to implement things however they want.

Even within the Oracle/OpenJDK sphere - there are 4 different garbage collectors which all could affect this pattern differently. There is even a new String dedup feature that would have an impact on the internal behavior of Strings:

[https://blog.codecentric.de/en/2014/08/string- deduplication-...](https://blog.codecentric.de/en/2014/08/string- deduplication-new-feature-java-8-update-20-2/)

tl;dr - don't assume and pick the right tool for the job

</comment><comment><USER19> And there is a good chance it will change again to have compact String in OpenJDK 9, see [http://openjdk.java.net/jeps/254](http://openjdk.java.net/jeps/254)

<comment><USER10> I'm dubious as to whether this change will occur. It's been tried before, and given up due to complexity.

I think it is an excellent idea, but in practice too awkward to implement seamlessly.

<comment><USER20> Python 3.3 did it: [https://www.python.org/dev/peps/pep-0393/](https://www.python.org/dev/peps/pep-0393/)

</comment></comment></comment><comment><USER21> The author of the change participated in a Reddit thread discussing it when the update came out. Thought he made a pretty good case for it.

[https://reddit.com/r/programming/comments/1qw73v/til_oracle_...](https://reddit.com/r/programming/comments/1qw73v/til_oracle_changed_the_internal_string/cdhb77f)

<comment><USER22> I don't know, this

[https://www.reddit.com/r/programming/comments/1qw73v/til_ora...](https://www.reddit.com/r/programming/comments/1qw73v/til_oracle_changed_the_internal_string/cdhupx4)

seems to bring up persuasive arguments on the other side.

<comment><USER23> His suggestion is pretty ludicrous though.

You can't just deprecate substring() which is a function that is used in what 90% of the millions of Java applications around the world. All because life is difficult for a tiny few edge cases (and for which workarounds exist i.e. checking Java version numbers). Sure it wasn't great that it was done during a bug fix but we need to be mindful that Java releases do span multiple years.

</comment></comment></comment><comment><USER24> Stop being so dismissive of this being a problem. I've had lots of problems with runaway allocation rates in parsers due to this issue. They could at least have introduced an alternative method which returns a view into the original String IMO. Not everyone is silly enough to not read the doc and get confused when memory blows up.

<comment><USER25> > and get confused when memory blows up

this is fairly easy to spot with a profiler though

<comment><USER24> Yes that is what I mean. Is it really more common that people do substring and expect the rest to be thrown away than the other way around? I would like to argue that this is an optimization aimed at sloppy code while it's penalizing well-written code.

<comment><USER2> I would say: definitely yes. I definitely think it is more common for a programmer to expect that if they make a substring, and never reference the original string again, only the substring would remain in memory after GC. It is more intuitive. Without prior knowledge of the implementation, why would you expect a reference to a substring to hold the entire original string in memory? I don't think it is necessarily sloppy code to interpret the method this way when you do not know the underlying implementation.

The description in the Java 7 API for substring is "Returns a new string that is a substring of this string." That does not suggest any sharing with the parent string; it says "new string".

<comment><USER24> OK I agree that it's more logical from a GC point of view. But why would you end up with a gigantic string? Are you not doing something wrong then?

Anyway, I have moderately sized strings and am trying to analyze parts of them. And I don't want to make copies for the sake of analysis. This has to be quite common as well.

</comment></comment></comment></comment></comment><comment><USER26> This reminds me: Generic Persistent RRB vectors should be part of every standard library. There's a great master's thesis out there waiting to be written about a similar data structure for variable length encodings of elements (such as UTF-8 strings).

<comment><USER27> Interesting, another Phil Bagwell paper [http://infoscience.epfl.ch/record/169879/files/RMTrees.pdf](http://infoscience.epfl.ch/record/169879/files/RMTrees.pdf)

</comment></comment><comment><USER28> String on its own is inefficient class. There is extra pointer, int field... ASCII strings are not downgraded from char[] to byte[]... You get big performance bonus just by replacing String with raw byte[].

I wrote Map<String,String> which does this transparently, and it consumes about 5x less memory compared to HashMap<String,String>.

<comment><USER29> It's not that simple. See [1] and [2]

[1] [https://bugs.openjdk.java.net/browse/JDK-8054307](https://bugs.openjdk.java.net/browse/JDK-8054307) [2] [http://shipilev.net/blog/2015/black-magic-method- dispatch/](http://shipilev.net/blog/2015/black-magic-method-dispatch/)

<comment><USER30> It's been a little while since I read the method dispatch post...can you explain what you're driving at?

</comment></comment></comment><comment><USER31> > _Java 7 quietly changed the structure of String. Instead of an offset and a > count, the String now only contained a char[]. This had some harmful effects > for those expecting substring() would always share the underlying char[]._

In theory they could have implemented both. Substring optimization for small but not larger strings.

<comment><USER32> That would been terrible and unexpected. The behaviour would differ based upon the length of the input String.

<comment> david-given It shouldn't. The behaviour is specified by the external interface, and if the internal implementation is changing the behaviour, then the implementation is broken.

For example, back when I was at a JVM company, we had two string implementations, one for ASCII strings and one for UCS-2 strings; the JVM uses a lot of ASCII strings, and frequently you could figure this out at code load time. Having an implementation based on an array of bytes saved quite a lot of space, and was completely transparent.

</comment></comment></comment><comment><USER33> OTOH, Java 8u20 added string deduplication in the GC: [https://blog.codecentric.de/en/2014/08/string- deduplication-...](https://blog.codecentric.de/en/2014/08/string- deduplication-new-feature-java-8-update-20-2/)

</comment><comment><USER34> Can someone explain to me why using a cached value for hashCode in an immutable string is a bad thing?

<comment><USER35> I don't think he refers to the caching being a bad thing, but that it probably does not affect performance that much, since most Strings are likely to be small (and the number of times hashcode is called is also likely to be small).

There's also a catch : if the hashcode of the string is 0, the hashcode will be recalculated every time (since the code assumes it has not been cached yet).

<comment><USER36> >There's also a catch : if the hashcode of the string is 0, the hashcode will be recalculated every time (since the code assumes it has not been cached yet).

At least that part should be easy to fix by defining a hash function that returns numbers != 0 - even the article says they did it for JVM7 but it's gone in JVM8 - with no explanation ?

<comment><USER37> The hash32 implementation in Java 7 was not intended to fix the case where the actual hash value was zero, nor did it have an impact on that case as the hash32 value was stored in a separate field.

It was made to decrease the number of hash value collisions in large data structures (hash maps and such). Its replacement is described here: [http://openjdk.java.net/jeps/180](http://openjdk.java.net/jeps/180) . Given that most Strings never end up in a large collection, allocating an extra 4 bytes for every one of them was a waste.

This post has been edited once for factual correctness.

<comment><USER38> It's hard to imagine a situation where the hash function would be so slow as to justify adding 4 bytes to every string.

<comment><USER39> If your strings are large, then calculating the hash will take time AND the extra 4 bytes for hash storage will be minimal extra overhead.

You can easily find good & bad cases for all of these string implementations. They all have tradeoffs.

</comment></comment></comment></comment></comment></comment><comment><USER40> Why does he say SubbableString example is not threadsafe? The private fields are only written during object creation.

<comment><USER41> Because he takes a reference to a char[] in the constructor without copying it. char[]s are mutable so this means that the internal state of his String can be mutated by something else without any synchronisation guarantees.

<comment><USER40> But that's nothing to do with thread saftey - even with a single thread if the char[] changes then stuff blows up right?

<comment><USER42> Correct, and Java's String(char[]) makes a copy of the array for that reason. This article's benchmark gets a boost by avoiding that.

</comment></comment></comment></comment><comment><USER43> Obligatory: [https://xkcd.com/1172/](https://xkcd.com/1172/)</comment>


Facebook: tools are top priority - <AUTHOR> http://www.facebook.com/note.php?note_id=171746501831

<comment><USER2> Required me to log in. Would it be considered good or bad practice to copy it here for HNers without Facebook accounts?

<comment><USER3> Here's a copy on the original author's personal site that doesn't require a login: [http://algeri-wong.com/yishan/engineering-management- tools-a...](http://algeri-wong.com/yishan/engineering-management-tools-are- top-priority.html)

The whole series is worth a read: <http://algeri-wong.com/yishan/engineering- management.html>

<comment><USER2> Ahh, an even better alternative.

</comment></comment></comment><comment><USER4> Great article, especially for engineering managers. There's always a temptation to do something manually since it's quicker now, but in the long term all that time adds up fast.

</comment><comment><USER5> Here's an example of one of Facebook's MySQL tools: [http://www.theregister.co.uk/2010/09/21/facebook_online_sche...](http://www.theregister.co.uk/2010/09/21/facebook_online_schema_change_for_mysql/)</comment>


Nonpharmaceutical Interventions by US Cities During 1918-1919 Influenza Pandemic - <AUTHOR> https://jamanetwork.com/journals/jama/fullarticle/208354 <comment><AUTHOR> Key grafs: objectives and conclusions.

Objectives: To examine the implementation of nonpharmaceutical interventions for epidemic mitigation in 43 cities in the continental United States from September 8, 1918, through February 22, 1919, and to determine whether city- to-city variation in mortality was associated with the timing, duration, and combination of nonpharmaceutical interventions; altered population susceptibility associated with prior pandemic waves; age and sex distribution; and population size and density.

Conclusions These findings demonstrate a strong association between early, sustained, and layered application of nonpharmaceutical interventions and mitigating the consequences of the 1918-1919 influenza pandemic in the United States. In planning for future severe influenza pandemics, nonpharmaceutical interventions should be considered for inclusion as companion measures to developing effective vaccines and medications for prophylaxis and treatment.

These findings contrast with the conventional wisdom that the 1918 pandemic rapidly spread through each community killing everyone in its path. Although these urban communities had neither effective vaccines nor antivirals, cities that were able to organize and execute a suite of classic public health interventions before the pandemic swept fully through the city appeared to have an associated mitigated epidemic experience. Our study suggests that nonpharmaceutical interventions can play a critical role in mitigating the consequences of future severe influenza pandemics (category 4 and 5) and should be considered for inclusion in contemporary planning efforts as companion measures to developing effective vaccines and medications for prophylaxis and treatment. The history of US epidemics also cautions that the public's acceptance of these health measures is enhanced when guided by ethical and humane principles</comment>


Grandpa's Beer - <AUTHOR> https://popula.com/2019/04/11/grandpas-beer/ <comment><USER2> It's a treasure to find someone who can have an elder act rudely toward them and reflect, "I also felt like, hey, this is a great moment, sad and interesting and funny. This is what old people do. You will do this one day, and you will not know you are doing it." It's easier when, like the writer, you are not around that person all the time, but it's an excellent viewpoint that allows people to enjoy older people who are losing perspective, but still have much to offer.

<comment><USER3> Thanks for calling out the deeper aspect of the article rather than the superficial beer-related aspect.

> You will do this one day, and you will not know you are doing it.

That is a profound statement.

I see older people behave in certain ways and think I will never be like that. Then I realize that I will be, and that when I am like that I will not know it. And therefore maybe I already am like that.

<comment> rkuykendall-com > I see older people behave in certain ways and think I will never be like > that. Then I realize that I will be, and that when I am like that I will not > know it. And therefore maybe I already am like that.

The problem is that this isn't always true, and it's hard to know when, since there's another thing that causes all old people to do something: They all lived at the same time.

There are certain ways that older people relate to food that is based not around being old, but having lived through the great depression. The same with the baby boomers, etc. We can already see that people who grew up around 9/11 and the recession will be different in certain aspects.

Even hobbies, may have much less to do with being old, and more to do with carrying over hobbies from an earlier age.

Think of it like 'old people names'. Those aren't old people names, they're 'teenager names' 65 years later.

</comment></comment></comment><comment><USER4> I'm English. A lot of beer here was traditionally served at cellar temperature even though today, most beer is served cold. I've been known to complain about the temperature of beer too.

This well-written tale should be a salutary lesson to me about getting too fixed in my opinions :)

<comment><USER5> > today, most beer is served cold

It depends what you're drinking & where you're drinking it. Almost all the beer I order is served at room temperature.

<comment><USER6> 'Room temperature' is a funny thing - people say you should drink most red wines at 'room temperature' but apparently people's ideas of room temperatures has changed and increased by more than a couple of degrees over the last century. A small and hot dinner party kitchen certainly isn't what is intended by 'room temperature.'

Many sommeliers really recommending serving 'room temperature' red wines closer to cellar temperature or have fridges that just reduce temperature by a couple of degrees from the dining room in order to get what they want.

</comment></comment></comment><comment><USER7> In the US a bar served me Mort Subite at the same temperature as they served lager. In a plastic cup. I think that really kills the brand over a longer time.

<comment><USER8> A travesty, for sure, but unlikely to tarnish that brewery's reputation given the nationality of the perpetrators.

Another serious problem with ordering such beers on tap in the U.S. is that the beer in the line is often flat and stale, having sat for perhaps days due to its unpopularity here. Compounding this, I've found our bartenders are sometimes unfamiliar with the beers, and may add insult to injury by denying there's any problem.

If you're drinking in anything other than a true specialty bar in North America, from my experience it's best to stick to bottled beer from one of our excellent local alternatives, such as Ommegang or Unibroue.

</comment></comment><comment><USER9> Don't understand how people can drink beer at room temperature.

I've been to the CAMRA beer festival in Paisley a few times with some friends and we usually go to a pub afterwards as tradition.

That cold pint of Tennents is heavenly after dealing with all the lukewarm ale.

<comment><USER10> Heavier bodied and more complex beers do better with warmer temperatures. Eg a lager is best drunk cold, a stout (or lambic) should be a bit warmer.

Whether that should go all the way to room temperature depends on how warm your room is. (And how you like your beer.)

Eg [https://belgium.beertourism.com/belgian-beers/duchesse-de- bo...](https://belgium.beertourism.com/belgian-beers/duchesse-de-bourgogne) suggests you drink the Duchesse de Bourgogne at 8-12C. If you start at 8C and let it warm up as you sip, you'll notice the taste change over time and the flavours and aromas develop.

If you sip your lager slowly, you are just going to have an insipid drink. Especially if you started with something as bland as Heineken.

<comment><USER11> That's really interesting about Duchesse! I'd noticed that qualitatively (when we have some, it goes in the fridge). It definitely opens up over the 45 minutes while we watch a TV show

<comment><USER10> My Duchesse never lasts that long: I like it too much. But I start drinking it only when it's warmer.

I even managed to get it on tap on a few occasions.

<comment><USER11> That's how I discovered it! A local place included it in a "different beer" flight they were doing. I went back two weeks later and they were out, so I had to figure out where to find it bottled around here.

<comment><USER10> It's relatively easy to get in London and cheap.

But was impossible to get in Singapore for years. I now found a supplier that has a few.

Of all places, Japan had good availability. But they seem to have a thing for Belgian beers.

</comment></comment></comment></comment></comment></comment><comment><USER12> I like a good cool beer or stout, but get disgusted at cold beer. It's not enjoyable, so it gives me time to talk with friends as the beer warms to a proper temp.

<comment><USER13> I like my Lagers & Pilsners cool but Americans (generally!) really do sometimes take the cooling to extreme measures (such as keeping even the glasses refrigerated). In Central Europe a least even the cool-served beers aren't served at quite the near freezing temperatures you'd sometimes get in the US.</comment></comment>


Ask HN: How does your company manage passwords? - <AUTHOR> Shared doc?
1Password for Teams?
etc... <comment><USER2> Lastpass, quite happy about it. Best feature is that you can have externals having access to websites via a browser plugin without knowing the actual usernames and password. You can later revoke access easily.

<comment><AUTHOR> Yes. Although the weakness of it, is that if one get's compromised, they pretty much get access to everything. Single point of failure.

</comment></comment><comment><USER3> Really shittily. >.<

We use Passpack -- terrible UX, some debatable security-vs-practicality tradeoffs, no password manager integration, no decent export, but does have a good amount of control and functionality.

<comment><AUTHOR> >>> Really shittily. >.<

I feel you there. Yeah, that's why I'm asking this question to figure out best practices, and maybe new tools and structure.

Thanks.</comment></comment>


Ten Fallacies About Web Privacy - <AUTHOR> http://online.wsj.com/article/SB10001424052748704147804575455192488549362.html?mod=WSJ_Opinion_LEADTop

<comment><USER2> Many of the replies strangely don't seem to debunk the myths. For example, the reply to #5, people's worry that "someone will know things about them that they may want to keep secret", is that "most information is used anonymously", and "to the extent that things are 'known' about consumers, they are known by computers". That isn't a rebuttal at all, though: the fact that "most" information is used anonymously, and much information "known" is only known by computers and used as part of aggregate analytics or ad-targeting algorithms, doesn't address the core worry, that "someone will know things about them that they may want to keep secret". I mean, this is basic logic: you can't debunk a worry that _someone is doing X_ by arguing that _some people aren't doing X_.

For example, there are no assurances that Facebook isn't giving personally identifiable information about specific users to government agencies without warrants (they refuse to say either way). ChoicePoint's explicit purpose is to collect and sell such information ([http://www.washingtonpost.com/wp- dyn/articles/A22269-2005Jan...](http://www.washingtonpost.com/wp- dyn/articles/A22269-2005Jan19.html)). Even at a small scale, I've personally looked at information on systems I sysadmin that I suspect users would "want to keep secret", and I could have legally shared that information; it was purely my discretion and ethical sense that I shouldn't be publishing the results of sysadmin snooping that kept me from doing so. So it seems at least _exceedingly likely_ that companies are attempting to collect and connect information about people that those people would like to keep private, are not all (contrary to this op-ed) anonymizing the data or only allowing algorithms to use it, and at least some are probably sharing and/or selling it.

#7 also seems extremely dubious as a prediction. If indeed someone were given a printout of information collected on them by such firms, I think many people would be unpleasantly surprised. The reason they aren't irate is not the unfounded assertion that "there is no harm from the way it is used", but because they have never seen such a printout, have no way to get one, and have no idea how it's being used or shared/sold.

Much of the rest is simply pure opinion: "so-and-so says X is bad, but in fact I like it". I mean, I can see an argument that privacy regulations will cause more harm than good, but this doesn't really seem like that argument.</comment>


Jaron Lanier: Post-Symbolic Communication - <AUTHOR> http://www.edge.org/q2007/q07_12.html#lanier

<comment><AUTHOR> His flexible homunculus idea was reinforced for me by reading at the same time about a guy who kept 6 avatars going at once in an MMPORG.</comment>


Stadia advertised on Chrome new tab page - <AUTHOR> https://twitter.com/tomwarren/status/1163923268757274626 <comment><AUTHOR> I think they're really overstepping it here, making the browser itself an ad delivery vector.</comment>


A Chinese Internet firm finds a better way to make money - <AUTHOR> http://www.economist.com/news/business/21586557-chinese-internet-firm-finds-better-way-make-money-tencents-worth

<comment><USER2> I wonder if a similar model can be explored for other highly populated countries like India where internet users are expanding rapidly.</comment>


Google Fi gets iPhone eSIM support - <AUTHOR> https://arstechnica.com/gadgets/2020/04/google-fi-gets-iphone-esim-support/ <comment><USER2> There still don't seem to be any plan changes. At this point, Fi is pretty expensive compared to competitors. Fi only makes sense if you are an incredibly light data user, you are one of the few people who both live in one of the specific areas in which network switching helps and have one of the handful of phones that can take advantage of it (the iPhone is not on that list), or you are a frequent international traveler. No one falls into that last category at the moment, but this eSIM support would potentially make that a slightly more favorable option for a future iPhone user who travels, but I doubt it attracts many new customers.

<comment><USER3> I don't think network switching works on iPhone.

Edit: oh, and you've added that above.

<comment><USER2> Sorry, I edited that in immediately after posting since I wasn't initially clear that the iPhone is not among the handful of phones that support network switching.

</comment></comment></comment><comment><USER4> It is worth noting that even with this upgrade, Google FI is still just a T-Mobile MVNO (mobile virtual network operator) on the iPhone. The Verizon, Spring and US Cellular networks are not supported on the iPhone.

<comment><USER5> The huge difference for me between Google Fi and other T-Mobile MVNOs (like Ting) is that international data isn't throttled. Even less throttled than most of T-Mobile's offerings.

[https://community.t-mobile.com/thread/149011](https://community.t-mobile.com/thread/149011)

</comment></comment><comment><USER6> For the people complaining about Fi being more expensive for the same features: Google Fi is also the only US carrier that protects your line from porting and SIM swaps with actual two-factor authentication. I'm willing to pay for security.

</comment><comment><USER3> I wonder when they'll bring visual voicemail or Wi-Fi calling.

<comment><USER7> I wonder when they'll let me port my number back to google voice.

<comment><USER8> I wonder when I'll stop receiving iPhone group chat messages days after they're sent</comment></comment></comment>


DuckDuckGo Lite - <AUTHOR> https://duckduckgo.com/lite/ <comment><USER3>
        Original Landing Page: 1.08MB (41KB transfer) / 1.50s / 11 requests
        Original Search: 1.90MB (55KB transfer) / 1.8s / 29 requests

        Lite Landing Page: 11KB (7.01KB transfer) / 335ms / 3 requests
        Lite Search: 35KB (6.85KB transfer) / 538ms / 4 requests

<comment><USER4> 2MB for the default .. even Google's seems to be about 1.5~2MB just from looking at my debug console.

I wonder how this compares to search engine landing pages back around 2000 or 2005; back when 1MB could take you a few minutes on dialup.

DDG Lite might be just the right size for 90s era sites.

<comment><USER5> > _2MB for the default .. even Google 's seems to be about 1.5~2MB just from > looking at my debug console._

Try Google in text browser, for example _Links2_ [0]

        $ links2 https://google.com

[0] [http://links.twibright.com](http://links.twibright.com)

</comment></comment></comment><comment><USER6> I don't know if this is the right place to talk about this but what I've always really wanted out of Duck Duck Go is "category" filters or maybe even anonymous user profiles. A problem that I have is that most of my queries make sense within a certain domain.

Example: I wanted to know about Chicken Scheme. During my exploratory phase, I'd sometimes search for "Chicken Lisp" and would get results for "chicken lips" with a very small font suggestion for refining my queries further.

Perhaps, if I was able to select a category (software engineering) it would automatically skew my search results for that preferred domain. Maybe a !cat macro? Google doesn't really have this problem either - and I'm guessing here - because it is either better at guessing intention or because it _knows_ that I'm a software engineer because of my previous searches and then it automatically customizes my search results within a boundary of correctness - i.e, if OhSoHumble searches for chicken thighs then that person probably wants recipes rather than info on a Scheme implementation.

I guess account profiles would somewhat help with this as well - where you can opt into skewing your own results on the regular.

Regardless, I think there is a good middle ground to take between "collect as much data on this individual as possible to customize their results" and "put programming related search results at the top if the individual asks for it".

<comment><USER7> I thought the same thing too. Just being able to add some tags to my cookie session saying:

"Developer, Ruby, Ruby on Rails"

DDG is not very workable with 'ruby gem' searches without more context. Or at least when I last used it. I was using ddg full time, but found myself back on google.

<comment><USER6> Especially with how poorly named some projects/libraries are.

</comment></comment></comment><comment><USER8> Maybe I am a bit weird but the first thing I do with my hello world search results is open the page source. I was surprised by the amount of wasted new lines, it is more empty space than content. More surprisingly I found quite a few lines containing nothing more than spaces. There were quite a few instances of nbsp being repeated. This is one place where seeing a lot of tabbed in spaces is clean but also quite wasteful.

There are 9694 spaces in the page, 15464 new lines and ~272 non breaking spaces on a file that is only 178037 bytes. Just under 15% of the file probably doesn't need to be there. It hopefully is a fairly easy win to remove a lot of the wasted bytes in the file.

<comment><USER9> The effect in terms of bytes sent over the network would be negligible due to compression.

<comment><USER8> You are quite correct, if I correct the original file the gzipped equivalent of the file ends up just 4% larger, so the gap between the two narrows quite a bit. Still a bit of fat to trim but by no means the same level of waste the raw file contains.

</comment></comment></comment><comment><USER10> Why does it give different results than when you search on duckduckgo VS duckduckgo/lite ?

Search for "video hub app" \-- the regular version finds the website videohubapp.com while the lite version does not :(

<comment><USER11> I can reproduce this as well. The results differ by quite a bit:

[https://duckduckgo.com/?q=video+hub+app](https://duckduckgo.com/?q=video+hub+app)

[https://duckduckgo.com/lite/?q=video+hub+app](https://duckduckgo.com/lite/?q=video+hub+app)

<comment><USER12> At least judging by the cookies passed "d: 1" \- "Safe Search: Strict" is enabled by default on the lite version. Enabling it on the regular version does make the results similar.

</comment></comment></comment><comment><USER13> This works exceptionally well in the lynx terminal-based browser.

[https://lynx.invisible-island.net](https://lynx.invisible-island.net)

<comment><USER14> I use regular ddg in w3m on occasion, didn't realize until just now they were actually redirecting to ddg lite. I wish other sites with massive sidebars/headers would do the same

</comment></comment><comment><USER15> [https://duckduckgo.com/litedark/](https://duckduckgo.com/litedark/) needed

<comment><USER3> Even better: [https://developer.mozilla.org/en- US/docs/Web/CSS/@media/pref...](https://developer.mozilla.org/en- US/docs/Web/CSS/@media/prefers-color-scheme)

</comment></comment><comment><USER16> At least this one doesn't have that annoying popup whenever you open it - <USER2> to switch back to google because of it.

<comment><USER17> Use start.duckduckgo.com to bypass that popup and all the other things. [https://start.duckduckgo.com/lite/](https://start.duckduckgo.com/lite/) also works, just adjusted my mobile bookmark to use this.

If you go into your settings, there's the ability to have your configuration as URL parameters, so that you can bookmark a specific way of using it without needing a cookie or session ID. From [https://start.duckduckgo.com/settings](https://start.duckduckgo.com/settings) open the "Show Bookmark URL on the right and it has the string to use in your bookmark to bypass all the random things and always visit the site in your preferred design/setup.

</comment></comment><comment><USER18> Reviewing the frontend code, a couple of things stand out.

1) The HTML/CSS code isn't minified.

2) The PNG images can be compressed further (lossless) for extra savings.

3) CSS classes/ids could be further shortened in post-processing.

<comment><USER19> Does HTML ever need minifying? Serving using compression would handle it wouldn't it?

<comment><USER20> html minifer mostly just remove the whitespaces. Compression (gzip or brotli) preserves the source, i.e. decompressed file is exactly the same as the original's; whereas minifier alters the source.

<comment><USER19> Well that's what I mean. Minifying css/js makes sense as it usually includes a concatenation stage.

Minifying HTML just makes your page source slightly harder to look at. Whitespace would be squashed into almost nothing with in-transit compression.

Probably something nobody ever needs to think of, but as a web dev it's an argument I've had more than once!

</comment></comment></comment></comment><comment><USER21> If you're a decrepit old man like me (I'm in my 30s now), you will remember that this is the way Google used to be in the 90s.

Altavista, the alternative, was a bloated, slow mess.

</comment><comment><USER22> Most useless comment on HN ever, I know, but... THANKS.

After having observed and been part of the infancy of the web in the 90s I can only be very grateful for this.

It's the age, I know.

</comment><comment><USER23> Does anyone know if there's a good way to make this lite version the default search in Firefox instead of the normal Duck Duck Go website?

<comment><USER24> I see three dots left to the star in the URL bar, it expands and lets me add it.

IIRC Firefox mobile requires you to long press the search field.

</comment></comment><comment><USER25> The old results page didn't let ctrl+backspace work on search bar. Cynical me frowns at going out of your way to break that. Also results should be 80 characters wide to read on a big screen.

[https://www.goshdarnwebsite.com/](https://www.goshdarnwebsite.com/)

</comment><comment><USER26> Poor formating on mobile. Search results do not fit screen width. Annoying, but should be easy to fix.

</comment><comment><USER27> Also, add &kd=-1 to the search URL to get direct links.

For example:

[https://duckduckgo.com/lite?q="robert%20anton%20wilson"&kd=-...](https://duckduckgo.com/lite?q="robert%20anton%20wilson"&kd=-1)

<comment><USER28> I seem to get direct links on this anyway. What are other people seeing?

<comment><USER27> You're right. I guess DDG must have made that the default at some point.

</comment></comment></comment><comment><USER29> I keep getting "forbidden" when entering any search. Anyone else having this issue?

<comment><USER20> I get the error when I search using right-click menu or through an embedded search box. Regular search works fine.

The ones not working have Origin request header.

</comment></comment><comment><USER30> Any chance for a dark version?

</comment><comment><USER31> You know what would make this even better?

A simpler URL, something like ddglite.com or ducklt.com

<comment><USER32> duck.com already redirects to duckduckgo.com

<comment><USER33> duck.com/lite does not work though

<comment><USER34> ddg.gg/lite works here

</comment></comment></comment></comment><comment><USER35> holy cow. that page was loaded and rendered _before_ mobile safari's open-tab- animation finished. going to ddg.co takes _much_ longer.

</comment><comment><USER36> The pagination does not seems to be work properly

</comment><comment> m-p-3 Perfect startpage for my Kobo eReader

</comment><comment><USER37> While they're on it can't they make http version of it? Some browsers don't support modern https, you know.

<comment><USER38> Why? That ship has sailed long ago. HTTPS is a requirement for browsing the web in 2020, just as HTTP was in 2000.

Most of the browsers that can't do modern HTTPS run on operating systems that shouldn't be on the public internet because of security concerns in any case, so that leaves perhaps a few really fringe browsers. Come to think of it, I can't even name one of them — even text-based browsers like Lynx work with DuckDuckGo (you end up on this Lite version).

<comment><USER37> Embedded systems can use internet securely without HTTPS.

<comment><USER38> Good point, but embedded systems don't generally act as an agent for a user to browse the internet. Their endpoints tend to be known API's. You wouldn't use DuckDuckGo from an embedded device like that until you reach the level of a full-fledged modern OS with an up-to-date browser (e.g., Linux running on a Raspberry Pi). It would be meaningless too, because even if you could use a search engine without HTTPS, almost all of its linked results will require it.

The internet can be used without HTTPS, but you can't expect to browse common websites without it.

</comment></comment></comment></comment><comment><USER39> Hell yeah.

</comment><comment><USER40> Well this page has not much content, but the first thing I notice is that the search box and the button are not aligned correctly...</comment>


Ask HN: Cheapest way to do 2,000 concurrent rtmp video streams? - <AUTHOR>

Looking to change our infrastructure. Looking to set up a rtmp server(s) that can stream 2,000 rtmp streams(500kB/s each). Anyone have any experience with red5/flash media server. What sort of performance can I expect. Any way to cache the video files in RAM using this software out of the box. Should I just go with a CDN if my peak bandwidth will be 10x off peak? Any hosting providers/co-locaters that have low bandwidth costs(10TB of traffic) and a nice(at least 1GB/s) connection.<p>Thanks! <comment><USER2> I hope I will be facing the same problem soon with UsabilityTest.com :) ! I just started by using Wowzy , have been playing with Red5 2 years ago which was complicated to get it running - now I guess when they are reaching RC it should be good. As for hosting - I only know good UK hosting providers.

</comment><comment><USER3> you might want to give these guys a call:

<http://www.influxis.com/>

they do FMS hosting</comment>


USB is forbidden to Evangelical Christians because symbol is the mark of Satan - <AUTHOR> http://www.guardian.co.uk/science/the-lay-scientist/2010/nov/15/3

<comment><USER2> People much less crazy/religious than these refuse blood transfusions that would save their lives. What a world we live in!

<comment><USER3> Its obvious that this particular guy is retarded. No problem. In any case I wonder what they would say about the Ukraine?

[http://en.wikipedia.org/wiki/File:Lesser_Coat_of_Arms_of_Ukr...](http://en.wikipedia.org/wiki/File:Lesser_Coat_of_Arms_of_Ukraine.svg)</comment></comment>


Build Better User Interfaces with Patternry - <AUTHOR> http://www.onfocus.in/startup/view/build-better-user-interfaces-with-patternry-09-01-11

<comment><USER2> As a general complaint, i feel like most of these "web/graphic design pattern libraries" miss the point of christopher alexander's original 'pattern language' idea, which specify cataloging as only one part of actually developing a larger, expressive, design language.

Still, the problem with these as actual 'design patterns' is that they're often wedded to specific implementations rather than the tasks they're trying to solve. I.e. "Endless Scrolling" (to pick an example) is not a pattern, it's a solution to a larger problem (e.g. user retention, communicating large datasets, immersive experience, &c).

The point being that if you're talking about design patterns in terms of the implementation (web forms, 404 page) you're restricting your pattern language to specific solutions rather than understanding what problems you are actually trying to solve (i.e. I WANT TO GIVE YOU MONEY, WHERE DID THIS GO?, respectively).

Although these sites often address these problems, they do so as a second level consideration rather than the primary atom of their pattern language, which diminishes their power. This is generally part of the problem with how design patterns are discussed and understood, which is a bummer, because it promotes the perception that they are 'reference catalogs' rather than 'languages for addressing problems.'

 _edit: fixed ambiguous language in last sentence_

</comment><comment><USER3> Seems strikingly similar to PatternTap, which I've enjoyed using from time to time: <http://patterntap.com/></comment>


Information Architecture Task Failures Remain Costly - <AUTHOR> http://www.useit.com/alertbox/ia-failures.html

<comment><AUTHOR> What log analysis tools do you use to see where people get stuck on your site?</comment>


Can the iPhone 6 Plus fit in your pocket? - <AUTHOR>

It fits just fine in my jeans, but your mileage (especially with skinny jeans) may vary. And while it the iPhone 6 Plus fits, it's not exactly a comfortable fit. It makes me fully aware that I'm walking around with a giant device in my pants (ahem), and the huge rectangular bulge it makes isn't exactly attractive. The iPhone 6, it should be noted, feels perfect in my pocket.<p>Is this a deal breaker for you? <comment><USER2> If Apple brings back normal, non-skinny pants back to the market this way, I will be so happy.</comment>


'Corporations Are People' Is Built on a 19th-Century Lie - <AUTHOR> https://www.theatlantic.com/business/archive/2018/03/corporations-people-adam-winkler/554852/?single_page=true <comment><USER2> The Atlantic should be ashamed of this headline.

Winkler's essay in the Saturday WSJ on this same topic says this: "Corporate personhood is a foundational principle of business law. In 1757, Blackstone in his influential 'Commentaries on the Law of England' wrote that corporations were 'artificial persons.' Open any corporate law casebook and one of the first lessons will be that corporations are legal persons." [0]

So, "Corporations are People" isn't a new idea, is much older than the 19th Century, and Winkler himself says otherwise.

[0][https://www.wsj.com/articles/what-rights-should- corporations...](https://www.wsj.com/articles/what-rights-should-corporations- have-1519919444)

<comment><USER3> Legal corporate personhood is _exactly_ the original differentiating factor of the corporate form vs. other business structures (which basically consisted of sole proprietorships and general partnerships at the time, most other forms are newer inventions than the corporation.)

That said, _Constitutional_ corporate personhood is a distinct thing; it is quite possible for legal corporate personhood to be observed without the protections granted to "the people" or "persons" in the Constitution being extended to private corporations (they generally are not extended to juridical/artificial persons which are _not_ private corporations, such as public bodies, despite those bodies also being legal persons.)

The contentious issue about "corporate personhood" is about Constitutional, rather than juridical, corporate personhood. So while you (and the WSJ article you cite) are correct about legal corporate personhood, that's also a bit of a non-sequitur and equivocation in the discussion at hand. (Though it would help if articles like the Atlantic one would expressly identify Constitutional personhood as the issue and contrast it with juridical personhood, so as to clarify the problem domain and forestall this kind of distraction.)

</comment></comment><comment><USER4> > Somewhat unintuitively, American corporations today enjoy many of the same > rights as American citizens. Both, for instance, are entitled to the freedom > of speech and the freedom of religion.

I keep hearing that but what does it even mean?

Corporations don't have religious beliefs, people do. Can the corporation be Muslim and have 100% Mormon employees?

The only controversial bit I could locate in a different source was the corporate political spending: [https://en.wikipedia.org/wiki/Corporate_personhood](https://en.wikipedia.org/wiki/Corporate_personhood) \- but there is a bajillion plus loopholes to do that without the need to resort to legal fiction.

<comment><USER5> Yeah companies can internally praise certain religions over others. They can't discriminate but they do anyways.

<comment><USER4> It's not the companies, it's their owners. The simple test is, if the company management changes to someone of a different faith, will they praise the same religious belief? The answer is clearly no, as no one in their right mind puts religion in the articles of incorporation, probably not even in Pakistan or Saudi Arabia.</comment></comment></comment>


Stock Market Meltdowns - Why they will happen again and again and again - <AUTHOR> http://blogmaverick.wordpress.com/2008/09/15/stock-market-meltdowns-why-they-will-happen-again-and-again-and-again/

<comment><USER2> <http://news.ycombinator.com/item?id=305191></comment>


Twitter Premium Accounts - How a Joke Became a Hoax - <AUTHOR> http://www.twittown.com/twitter/twitter-premium-accounts-how-joke-became-hoax <comment><USER2> _Truth is, BBSpot didn't try to "trick" anyone. That entire site is devoted to fake and satirical news. There was no "hoax," only a joke that someone didn't bother trying to understand before spreading his outrage around the Twittersphere in little 140-character long spurts._

Hear hear. Twitter was full of mostly interesting, cutting edge, net culture-y folks until early last year, but this story shows just how the community has changed. It beggars belief that anyone would believe the original story if they'd taken time to read it rather than just retweet what someone else had said (similar to stuff getting voted up on Reddit/Digg without people reading?). It reeked of satire.

<comment><USER3> _Hear hear. Twitter was full of mostly interesting, cutting edge, net culture-y folks until early last year, but this story shows just how the community has changed._

Which ironically is also touted as it's biggest asset and value: It has no monetizing plans, it has no real business, but it has a huge bunch of gits using it, and that makes it valuable.

New-capitalism is a rather interesting phenomenon.</comment></comment>


ThunderSVM: A Fast SVM Library on GPUs and CPUs - <AUTHOR> https://github.com/zeyiwen/thundersvm <comment><USER2> Potentially stupid question: What is an SVM? The linked page uses the acronym almost 30 times but doesn't define it.

<comment><USER3> Support Vector Machine. A Machine Learning technique that's used typically for classification and regression, but also has been adapted to novelty detection, stuctured prediction, ranking etc. I wrote up a beginner's tutorial some time back, if you are interested [1].

[1] [https://blog.statsbot.co/support-vector-machines- tutorial-c1...](https://blog.statsbot.co/support-vector-machines- tutorial-c1618e635e93)

<comment><USER4> Great read, thanks!

</comment></comment></comment><comment><USER5> >"Outside of neural networks, GPUs don't play a large role in machine learning today, and much larger gains in speed can often be achieved by a careful choice of algorithms." [1]

Scikit learn espouses a non-GPU approach. Perhaps the performance gains by using GPUs aren't that significant. Has anyone tried SVMs (or for that matter other non-DL classifiers) + GPUs?

[1] [http://scikit-learn.org/stable/faq.html](http://scikit- learn.org/stable/faq.html)

<comment><USER6> Anyone has more insight into why? if I try to grid search hyperparameters for a random forest takes ages in a single machine with scikit-learn. I only ever see GPUs in neural networks. Is there some acceleration for non-NN machine learning algos?

<comment> T-A Generally speaking, what GPUs excel at is applying exactly the same operation to many parallel data streams. Neural networks are like that.

Random forests are the opposite: branching on conditional tests is very expensive. It's been several years since I last wrote raw CUDA and OpenCL, but if memory serves, back then the docs essentially said that every if...else amounted to running both branches on all the data and then deciding what to keep, effectively halving performance. So a decision tree just a few levels deep would slow you down by an order of magnitude.

</comment></comment></comment><comment><USER7> Prerequisites

         - Supported Operating Systems: Linux, Windows and MacOS
         - CUDA 7.5 or above | cmake 2.8 or above | gcc 4.8 or above

s/GPU/nVIDIA/

Is it just me or does anyone else get annoyed when a library claiming to run on GPUs uses proprietary CUDA, making it nvidia-only?

It would seem strange to claim that a library "runs on CPUs" but only supports Intel CPUs.

<comment><USER8> It does run on GPUs, just only some of them.

> It would seem strange to claim that a library "runs on CPUs" but only > supports Intel CPUs.

Most things would "run on CPUs" but often not run on ARM CPUs.

The key distinction is that it runs on some GPUs rather than (just) some CPUs, so it seems reasonable that they say that.

<comment><USER7> Most things that "run on CPUs" run on CPUs by many vendors. In the cases where software does not run on ARM processors it's almost always due to an architectural difference with x86, not an artificial proprietary limitation.

If an open-source library chose to rely on a proprietary C compiler with special language features (e.g. the Borland C compiler) that targeted only Intel x86 CPUs, I would argue we would not generally claim this software "runs on CPUs". The software "runs on Intel x86 CPUs" seems more appropriate.

Similarly, especially in the machine learning field, it seems to be more and more common that "GPU" really means "CUDA-required GPU". In a world where AMD and Intel GPUs are also common (perhaps more common?), to me it makes sense to be up-front about this.

I'm not criticizing the authors' choice to use CUDA here. I'm just saying it would be nice if we stop pretending CUDA is synonymous with GPU programming, especially in cases where OpenCL would be a very appropriate choice (e.g. open-source software).

<comment><USER8> The important point is it runs on any GPUs. If you think then saying it runs on GPUs is wrong the counter sounds more unusual, that it doesn't run on GPUs.

They could have been more precise but there's nothing wrong or particularly misleading about what they said, and what they said conveyed the most important aspect.

> would argue we would not generally claim this software "runs on CPUs"

"This software does not run on CPUs" sounds wrong for this scenario.</comment></comment></comment></comment>


The Ruby Game - <AUTHOR> http://www.therubygame.com/

<comment><USER2> Python:

import string

def foo():

        s = string.ascii_uppercase

        return "-".join([''.join(x) for x in zip(*[list(s[z::5]) for z in range(5)])])

20.41 usec, btw. Also how the heck, did it took 7 seconds for a script to do this? ( See slowest solution )</comment>


Zero Factorial - <AUTHOR> https://www.youtube.com/watch?v=Mfk_L4Nx2Z <comment><USER2> Youtube says: "This video does not exist."</comment>


Is It Ever Worth It To Set Yourself On Fire? - <AUTHOR> http://www.jamesaltucher.com/2011/08/was-it-worth-it/

<comment><USER2> Seriously?

"There's been plenty of times one could take the easy way out. Dying like this is easy. Within 45 seconds he passed out from the pain of burning. Within two or three minutes he was dead from asphyxiation or his organs burning and the skin peeling away from his bones. Big deal."

I'm sorry, but after reading that paragraph I lost all interest in the article, and respect for the author, regardless of the "point" he was trying to make.</comment>


Ask HN: What method you've used to eliminate bad remote tech hires? - <AUTHOR> <comment><USER2> I'm not sure that it's particularly more difficult to eliminate bad remote hires than it is to eliminate bad in-office hires. Hiring in general is hard, and some number of poor employees always make it through. Some people come well-credentialed and interview well but then don't perform well, by a variety of metrics. Maybe their work is technically great but they're lazy, or reckless, or argumentative, or any number of other problems. I don't think any of this differs much from on-site workers vs remote workers.

In the end, the problems are the same regardless of where they might work. You've still got to filter and vet the people you're going to interview. It's not uncommon to remotely interview people even for on-site jobs; in fact there's almost always a phone screen and one or more phone/video interviews before people are brought on-site, if they're brought on-site before the hire at all.

Remote work has specific challenges to be sure; you need people who can communicate well. They need to operate with less information. It's hard to have effective meetings; you can't replace the value of a few people standing around a whiteboard, despite the excruciatingly-slow advances in technology for sharing this kind of data.

They also need to be motivated self-starters, because for all you know they're simply watching TV and taking bonghits all day. You'll need to make sure you're effectively evaluating their productivity. I don't mean to say that remote people are more inclined to slack off, or that it's hard to slack off at the office, but there's no getting around the psychological aspects of this, especially if your team is primarily on-site and only some of them are remote. I've seen the resentment that can build up, where people are far more critical of the remote workers; if you don't see someone working as hard as you, it's easy to assume they're not.

The single best way to eliminate bad remote hires is to find people with a proven track record of remote work. Try to ask specific questions about remote work challenges and solutions to help gauge whether or not they can handle it.

</comment><comment><USER3> In my experience, there is no such thing as "bad remote tech hire". Either it is a "bad hire" or you need to set the right training and expectations.

A bad hire will perform bad whether in person or remote. I do understand the premise of your question though. The issue with remote hires is not that they are bad, but they are probably not well equipped (training, expectations, process, tools) to do their job remotely. Also, unless someone is senior enough with some remote experience, I am personally hesitant hiring remote because it adds to the complexity.

So you don't eliminate bad remote hires. You eliminate the reasons why they are performing bad being remote if they are good otherwise. If they are bad anyway, then being remote probably makes it worse but not sure what you can do about the "remote" part only in such case.

</comment><comment><USER4> Revoke the VPN key _duck_ :)</comment>


Podcast Addict update has been rejected again from the Play Store - <AUTHOR> https://twitter.com/PodcastAddict/status/1296090447291355136 <comment><USER2> Rejection with no feedback for a long standing app that excels in its category is a real shame.

</comment><comment><USER3> I loved podcast addict when I used an android phone. This is an utter and absolute shame.</comment>


A Great Old Timey Game Programming Hack (2013) - <AUTHOR> http://blog.moertel.com/posts/2013-12-14-great-old-timey-game-programming-hack.html <comment><USER2> If you like that, you should read Bob Pape's free book about the making of R-Type on the Spectrum. I think it was one of the most technically accomplished games on the Spectrum, which is no small feat - there were lots of other talented programmers trying their hardest to achieve the impossible on that platform.

The amazing part of the story is how poorly the industry treated Bob and yet an excellent game still made it to the shops.

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

<comment><USER3> Oh wow, R-Type was one of my favourites on the Spectrum, had no idea about the book! Thanks.

<comment><USER4> You might appreciate [https://www.reddit.com/r/TheMakingOfGames/](https://www.reddit.com/r/TheMakingOfGames/)

</comment></comment></comment><comment><USER5> I've read this story before (likely on one of the two occasions linked) but I enjoyed reading it again.

I don't know how accessibly it is to the young guns today but one thing this story manages to elicit very well is the general zeitgeist I experienced myself during those days. Mind you, I was never as advanced a programmer as the author and his friend were. But the description of "facing a problem caused by the restricted architecture of the machine your working on, the puzzle-like search for a work-around, and simply just having the _spare time_ to dedicate to a project" are memories I know very well too.

Unfortunately, this feeling really _is_ a memory. Coding has changed so much since the days of the 6502 or 6509, it's a completely different ball game. That's why I wrote above, I don't know if those who haven't been there can relate to the story very much, other than it reading like a peculiarity. But it sure is a nice -- and even suspenseful! -- read for an old-timer like me.

<comment><USER6> I think that the young generation might still relate to this story. Hacks have changed, but they still exist.

The difference is that now, instead of looking for a particular CPU instruction, you'll look at hidden instructions in you JIT bytecode or ways to trick your sandbox (browser?) to let you use the GPU.

<comment><USER5> But that's kind of my point: naturally, there are still "hacks" around, I didn't mean to imply otherwise. But as much as the nature of coding has changed, so has the nature of the hacks. I still wonder how easy it is for someone who grew up with IDEs, frameworks/libraries, and StackOverflow to relate to an old-time story like the one above. Sure, you can relate to the general feeling of "something is in the way of me reaching my goal, is there a clever way around it?" but to me, a lot of the "magic" inherent in the older hacks is different from today's. Can that old-time magic still be felt by a kid of today when reading a story like this one?

</comment></comment></comment><comment><USER7> Discussed at the time: [https://news.ycombinator.com/item?id=6913467](https://news.ycombinator.com/item?id=6913467).

And in 2015: [https://news.ycombinator.com/item?id=10491768](https://news.ycombinator.com/item?id=10491768).

<comment><USER8> This story wasn't prevented by the dupe-filter (presumably), but was your post automated?

<comment><USER9> I dunno if OP was complaining necessarily - there are a lot of cool stories to be read in the old threads too!

<comment><USER8> Not a complaint by me, parent to my comment is [the main?] mod, dang. I just was curious whether they'd implemented a side app to post links to past threads.

I'm always a bit surprised this site is not technically advanced on the front end.

</comment></comment></comment></comment><comment><USER10> As a developer who has spent most of my time developing web applications, I get this feeling whenever I work with micro controllers. Memory usage and binary size are ever-present during the development process. Compiler optimization flags become really important. You're accessing registers and peripherals directly and you sometimes run into weird bugs and limitations with on-chip drivers that require a clever or unorthodox workaround to be found.

It's a nice deviation from high-level programming.

</comment><comment><USER11> The commodore 128 allowed the same trick of moving the machine stack and zero page. But the 6510 processor didn't have useful multiple-push or multiple-pull instructions so the possible speedup wasn't as much. Also in practice people writing games for the commodore targetted the C64 as it was a much larger market and the 128 was backwards conpatible so nobody bothered witb 128-only tricks like that.

</comment><comment><USER12> This is one of the reasons I love working with fantasy emulators like PICO-8. They impose deliberate technical limitations that force you to find creative solutions like this.

</comment><comment><USER13> I really enjoy how this piece captures the sheer joy of programming.

</comment><comment><USER14> Just noticed a comment by Terry Davis about TempleOS after the article; RIP.

<comment><USER15> Ah damn, I didn't realize he died. A fascinating mind.

</comment></comment><comment><USER16> WE'RE NOT WORTHY

I love this hack. Genius.</comment>