Is Prefix of String in Table?  a Journey into SIMD String Processing - <AUTHOR> http://trent.me/is-prefix-of-string-in-table/ <comment><AUTHOR> Side note: people have been inquiring how I made the diagrams and whatnot. I'll put a little section like that on the next article. For now though:

The two main diagrams, depicting struct layout and then the 5-pane register walk through, were done in Visio, then saved as SVG, with fonts edited directly in Vim (took a few cycles to figure out which fonts looked best across all devices).

The charts were done in Excel, connected to the CSV data files produced by the benchmark utility, then wired up using a PivotTable. A PivotChart was created, Save As -> PDF, edit PDF in Inkscape, delete surrounding border, crop canvas to fit diagram, Save As -> SVG. Edit SVG fonts in Vim, voila, nice vectorized graph!

Sounds laborious, and it took forever to get the flow down, once I'd settled on a process it was pretty easy to whip up new graphs.

<comment><USER2> I admire your attention to detail and keen sense of aesthetics. Well done.

<comment><AUTHOR> Thanks! Joe Walnes should get credit for the underlying HTML and CSS and site design and whatnot... I lovingly pilfered[1] his websocketd[2] site a while back for PyParallel[3] and liked it so much I decided it to use it for this personal site as well.

[1]: [https://twitter.com/joewalnes/status/567495778349113345](https://twitter.com/joewalnes/status/567495778349113345) [2]: [http://websocketd.com/](http://websocketd.com/) [3]: [http://pyparallel.org/](http://pyparallel.org/)

</comment></comment></comment><comment><USER3> Absolutely excellent!

SIMD-units of the x86-64 CPU are not discussed enough IMO. And every time they are discussed, I'm always blown away by their efficiency in solving some tasks.

\</comment><comment></comment><comment>---

Full disclosure: I don't understand what you've done yet. I've just skimmed the article really quick, but I already have some questions. Hopefully you didn't answer them already elsewhere, lol.

* Any reason to highly-optimize "strings of length 16" instead of "strings of length 32" ?? The vast majority of your code uses "xmm" registers (16-bytes), but it would seem like it'd be straightforward to target ymm registers (32-bytes) instead.

Were there any particular reason why you chose 16-bytes instead of 32-bytes? Like maybe targeting AVX but not AVX2?? (Then again, I see a rare ymm register here and there... sooo... I guess I'm just a bit confused with the design decision)

* SSE4.2 has string-specific instructions. Did you look into any of the SSE4.2 string instructions to see if they'd help in your case? (Ironically, forcing you back down to xmm registers, since its SSE only. So kind of a contradiction with my first question, lol) I fully admit that I don't actually know how to use the SSE4.2 string instructions, so don't look into my question too hard.

\</comment><comment></comment><comment>

I'll have to spend some time studying your code and explanation. Thank you very much for the writeup! It will be helpful for my SIMD-studies. There really isn't enough material out there on AVX / SSE optimizations.

<comment><USER4> On benefit of sticking with 16 bytes is it work on any 64bit machine, and as well you don't run into weird throttling issues that you do with AVX/AVX2/AVX512

So it is a lot easier to make something general purpose, where almost anyone can use it and it will always be faster.

With AVX you sometimes have to take some care.

<comment><USER3> He's using the "v" instructions, which requires AVX, and probably AVX2 (I haven't memorized all the instructions... but they're at least AVX). Even if he sticks with 16-bytes, the use of the "v" instructions basically requires a relatively recent processor.

<comment><AUTHOR> Yeah it's actually a pretty inconsistent mish-mash of ISA usage. I _could_ go straight SSE4.x but I'd lose out on the vp* goodies you get with AVX and AVX2, even if I'm only using XMM registers.

The "length of 16, num elements is 16" parity is nice though and simplifies the logic of the algorithm.

</comment></comment></comment></comment><comment><AUTHOR> Fun tidbits: a) I bombed, like, 6 coding interviews whilst writing this article. Two of them were related to string processing, too, which I thought was funny. (In a depressingly ironic kind of way.) No point, other than I seemingly suck at the "leetcode" coding interview style companies seem to rely upon these days.

And b) there are at least two Easter eggs in this post that no-one seems to have noticed.

Oh, and c) perk of religiously keeping line length to <= 80 characters... the code is surprisingly readable on mobile devices!

<comment><USER5> So you're looking for a job then?

<comment><AUTHOR> Sure am!

</comment></comment></comment><comment><USER6> Here is a way to do it with a perfect hash table (so only one lookup).

Find a 128-bit mask that will be used to select bits of the input string. You want to minimize the number of 1 bits in the mask, since the table size is 2^(number of 1 bits). On the other hand, you need to pick enough 1 bits so that there is only one string per table entry.

AND this mask with the input string. COMPRESS these bits using the mask. The result is the index into the table. Each entry has a string to compare and thermometer coded mask (number of 1 bits equals length of string in bits). AND the input string with the thermometer coded mask and compare it with the string. If they match, you have a hit.

COMPRESS (or generalized extract) means to move selected bits to the right so that they are all next to each other and adjacent to the LSB. There is a clever algorithm for this, see section 7-4 of Hacker's Delight:

[https://doc.lagout.org/security/Hackers%20Delight.pdf](https://doc.lagout.org/security/Hackers%20Delight.pdf)

<comment><AUTHOR> Patches welcome :-)

But seriously though, I played around with compression a bit initially: [https://github.com/tpn/tracer/blob/master/StringTable/String...](https://github.com/tpn/tracer/blob/master/StringTable/StringTable.h#L966). Referenced Hacker's Delight when I was working on it. Granted, this was just for compressing the USHORT lengths into BYTE-sized lengths.

Are you sure your compression suggestion would work for prefix matches? If you can get lower latency than the fastest assembly version, I'm all ears: [http://trent.me/is-prefix-of-string-in- table/#IsPrefixOfStri...](http://trent.me/is-prefix-of-string-in- table/#IsPrefixOfStringInTable_x64_12)

All of the compress/expand routines mentioned in that Hacker's Delight section you're quoting seem to mention upwards of 160+ instructions. My negative match logic fast-path only requires 12 instructions.

<comment><USER7> True. A gperf alike hash table (with special key indices) works only ok with compile-time known strings. But a simple CMP-alike perfect hash table with double indirection would be worthwhile to test against.

I called it Hanov after [http://stevehanov.ca/blog/index.php?id=119](http://stevehanov.ca/blog/index.php?id=119) Problem is there that you have to calc a hash for each string, which is only fast with __builtin_crc/_mm_crc32_u64

<comment><USER8> A hash alone isn't going to help much; he has both a 1-char string in the set and to top it off, most of the other strings begin with (a distinct from the 1-char string one) the same string. There are some tricks (overpopulate the hash table with short string) but hashing is tricky here.

Source: 11 years of string matching work. :-) We built a multiple hash table string matcher in the early days of Hyperscan (it's gone now).

</comment></comment></comment></comment><comment><USER9> I was wondering how long it took to write such content rich article, then I saw this:

> Hours spent on this article to date: 230.56.

<comment><AUTHOR> On the plus side, it only takes, like, 3 hours to read end-to-end.

<comment><USER10> You should simd your reading process and split that in to threads.

<comment><USER11> Inter-thread communication is hard.

</comment></comment></comment></comment><comment><AUTHOR> The article is much longer than I originally anticipated. If you're looking for some good bits, you could probably jump straight to here: [http://trent.me/is-prefix-of-string-in- table/#IsPrefixOfStri...](http://trent.me/is-prefix-of-string-in- table/#IsPrefixOfStringInTable_10)

That discusses the last C implementation before I took a stab at the assembly versions.

The final assembly section was pretty juicy as well: [http://trent.me/is- prefix-of-string-in-table/#IsPrefixOfStri...](http://trent.me/is-prefix-of- string-in-table/#IsPrefixOfStringInTable_x64_3-review).

I was investigating why an earlier assembly version was so slow, then ended up writing a version that unequivocally beat all the C and previous assembly versions across the board (both prefix and negative matching, and worst case false-positive matching (where up to three comparisons needed to be done)).

TL;DR with optimized data structures specifically geared toward SIMD instructions, you can definitely get sizable performance improvements in both C with intrinsics, and then again with raw assembly.

</comment><comment><USER12> > A reference implementation was written in C as a baseline, which simply > looped through an array of strings, comparing each one, byte-by-byte, > looking for a prefix match.

This is a poor choice; the 1970s boyer-moore also is significantly faster for most case as it avoids many pointless searches. And if you have a dedicated search table you can optimize the search even more (e.g. pre-sorting keys and targets, using a more dedicated structure like a trie, etc)

I think these approaches would also be amenable to deliberate acceleration with intrinsics, as you did with your brute force search.

Regardless, interesting work.

<comment><AUTHOR> Well... I mean the first version (IsPrefixOfStringInTable_1) uses the lengths from the string array to improve performance versus the baseline: [http://trent.me/is-prefix-of-string-in- table/#IsPrefixOfStri...](http://trent.me/is-prefix-of-string-in- table/#IsPrefixOfStringInTable_1)

The super-simple baseline referred to in the intro was whipped up as a trivial example of the simplest approach you could take for the problem.

Trie was never in contention as I didn't want to rely on any algorithms that involved pointer chasing. There's this comment at the top of StringTable.h:

        The design is optimized for relatively short strings (less than or equal to
        16 chars), and relatively few of them (less than or equal to 16).  These
        restrictive size constraints facilitate aggressive SIMD optimizations when
        searching for the strings within the table, with the goal to minimize the
        maximum possible latency incurred by the lookup mechanism.  The trade-off
        is usability and flexibility -- two things which can be better served by
        prefix trees if the pointer-chasing behavior of said data structures can
        be tolerated.

[https://github.com/tpn/tracer/blob/v0.1.12/StringTable2/Stri...](https://github.com/tpn/tracer/blob/v0.1.12/StringTable2/StringTable.h#L23)

I'm not sure if Boyer-Moore is well suited to the specific use case I wanted to address. It is geared toward looking for occurrences of a pattern in a stream of text bytes, which isn't really what I'm doing at all. I have an input string of known length. I have up to 16 strings in a table, and I want to quickly check if any of those strings "start with or are equal to" my input string, with special emphasis on negative matching being on the fast path, and preserving the location of the match in the table (so it can be cast to an enum, for example).

So, this article was specifically about the SIMD-oriented STRING_TABLE structure, not necessarily about the history of string processing. Another article potentially comparing this approach to tries, Boyer-Moor or Aho- Corasick would make sense in the context of larger prefix table data sets (and a larger text corpus being searched, e.g. wikipedia dumps).

<comment><USER13> What's the issue with "pointer-chasing"? That it might be inefficient in practice (despite preferable runtime complexity?) due to making poor use of CPU caches?

<comment><USER3> > That it might be inefficient in practice

That's basically it.

Consider that his algorithm completes 16-searches in 20-cycles, or roughly 5 nanoseconds.

A single fetch from main-memory will take 50-nanoseconds, or be ~10x slower than the methodology discussed in this post. Even a fetch from L3 cache is typically 10-nanoseconds, while a fetch from L1 cache is 1ns or ~4-cycles. This SIMD-methodology is incredibly FAST.

The "best-case" scenario of this SIMD code is 6-cycles, which is faster than two L1 fetches. (!!!)

Note: two L1 fetches would likely go into the reorder buffer and be out-of- ordered into an efficient manner. But... ignore that plz since that destroys the point I'm trying to make. Lol. Still, you can see how repeatedly forcing even L1 fetches would slow down the code, and "pointer chasing" is more likely to fill up the Reorder buffers, since you cannot rely upon prefetchers to pre- fetch the data, or other such tricks of the CPU.

Algorithmic complexity means that eventually, the linear / SIMD methodology eventually will be slower with a big-enough dataset. But when looking at small data-sets and optimizing them to the maximum ability (ie: searching 16-strings ASAP), linear / sequential scans are king. Kinda like why insertion sort ends up winning in a lot of small cases over other sorts. CPUs and RAM are incredibly well optimized for sequential data scans.

</comment></comment></comment></comment><comment><USER14> Is this somewhere a Bloom Filter (or similar probabilistic data structures) could be used to improve performance? From a quick survey of cryptographic hash functions something like BLAKE2 would serve your needs at ~4ops/byte. If you had a wide enough bloom filter you can turn your check, in most cases, into a binary &.

Just a thought. The author here obviously already knows what they're doing and has likely thought of this but I'd be interested in hearing why this ASM- optimized approach was chosen instead.

<comment><AUTHOR> The initial length + unique character test allows us to negative match in a way that is effectively identical to a bloom filter.

If the initial negative match test indicates no match, then we can be certain there is not a match. Otherwise, we might have a match, and need to compare the candidate strings in more detail.

I can't imagine how hashing would help in either the fast-path negative match case, or the prefix match case. Hashing is sort of at odds with prefix matching, in my opinion.

<comment><USER14> Could you get good-enough performance with something simpler and more portable?

The optimized assembly is much more complicated and specialized. Porting platforms/architectures is very difficult and you loose out on the compiler's abilities to make assumptions and optimize your code.

String length is a very poor probabilistic filter as you're specifically looking substrings.

Also if you already have a hash of your input string's prefix, and the hash of all of your known strings, in the case where you actually need to check against your "known" strings becomes a fast search of a set of numbers making the fail-through case of your code negligible. If you impose a limit of strings in your "known" pool the compiler can have a field day.

<comment><AUTHOR> > Could you get good-enough performance with something simpler and more > portable?

Hmmm. Did you read the article? Any of the C versions are relatively simple and portable. They basically work the same as the assembly ones and give great performance... I'm not sure what you're trying to get at.

> The optimized assembly is much more complicated and specialized.

Well, it's my article, I wanted to see if I could beat a PGO C compiler with all its optimizations turned on :-)

> Porting platforms/architectures is very difficult and you loose out on the > compiler's abilities to make assumptions and optimize your code.

I know the trade-offs that come with assembly. But if you're okay with them, you can get the best possible performance out of the underlying hardware. That was the goal of this article.

> String length is a very poor probabilistic filter as you're specifically > looking substrings.

I don't understand this comment. String length is a great filter because if any strings in the table are longer than the input search string, then there's no way we can have a prefix match.

> Also if you already have a hash of your input string's prefix, and the hash > of all of your known strings, in the case where you actually need to check > against your "known" strings becomes a fast search of a set of numbers > making the fail-through case of your code negligible. If you impose a limit > of strings in your "known" pool the compiler can have a field day.

I don't know where this fascination with hashes comes from... have you looked at the implementation? Even when it has to do a string match, the timings now are around 13-14 cycles. The nature of the data structure means you're really only ever doing max 2 comparisons... 3 if someone is sending you worst case data (and even so, with 3, you're only clocking ~20 cycles).

Hashing and prefix matching just don't play well nicely together.

</comment></comment></comment></comment><comment><USER8> This is fine work, and well presented. The only flaw (which I've discussed on Twitter with Trent) is the performance analysis against a single string at a time means we can't really analyze the effects of branch prediction on a realistic input (as the branch predictor will converge to 'perfection' almost immediately). I think these effects would be small, but it really does need to be properly analyzed.

</comment><comment><USER15> I always love learning about performance and how this low level stuff works. Is there a book that people recommend for this type of stuff?

<comment><AUTHOR> I bought a bunch of assembly/MASM books from the 90s recently, if that helps. Writing assembly is a skill that atrophies so quickly without constant exercise, so once you spool up to an acceptable level of assembly productivity, you really need to make a conscious effort keep practicing to maintain it.

If I go for a couple of weeks, I'll come back and be like "wait, how do I check if this is a NULL pointer again?".

The Computer Archtecture books are good, you can pick up 2nd hand copies of older versions for cheap. Intel and AMD manuals are good, too.

</comment></comment><comment><USER16> This seems like a complicated way to speed up a linear scan. What's the advantage of this approach over just sorting the strings and doing a binary search, which is log N?

(Not a naive binary search using strcmp, but the trick where you find the lower and upper bounds given index 0, refine it using index 1, etc. until your input is exhausted.)

<comment><USER17> Chasing pointers is cache death. Many theoretically optimal algorithms have been struck down by the God of Memory Latency.

eg, If you measure it, tree performance will often be much improved by storing slightly less than one cache line's worth of data at each node. The CPU can pipeline and predict the shit out of the linear search at each node to the point that all the theoretical O(1) or O(log N) lookups in the world get demolished by a CS101 scan of the array. This makes a relatively good general use cache aware data structure because small collections tend to fit into a single cache line while large data structures have relatively few pointers to chase.

Of course as the OP demonstrates, optimizing for your specific use case can yield even more dramatic improvements.

<comment><AUTHOR> Heh, "predict the shit out of", I like that.

</comment></comment></comment><comment><USER18> Have you done some comparison with a trie implementation (known for good performance on prefix matching, see: [https://en.wikipedia.org/wiki/Trie](https://en.wikipedia.org/wiki/Trie))

<comment><AUTHOR> I love tries for larger data sets, and have used them many times for longest prefix matching problems.

However, they inevitably involve pointer chasing, are quite branchy, and not really amenable to SIMD optimizations. They also do not have any means in place for doing a fast-path negative match, which was important for me.

I think you'd really struggle to get anything based on pointer chasing and binary search to compete with the CPU cycle counts I was seeing toward the end for the assembly versions (e.g. 6 cycles for negative match, 14 for prefix match, 21 for worst-case false-positive negative match).

I comment a little bit about it here: [http://trent.me/is-prefix-of-string-in- table/#other-applicat...](http://trent.me/is-prefix-of-string-in-table/#other- applications)

> The other nice side-effect is that it forces you to pick which table a given > string should go in. I made this decision by looking at which types occurred > most frequently, and simply put those in the first table. Less frequent > types go in subsequent tables.

> I have a hunch there's a lot of mileage in that approach; that is, linear > scanning an array of string tables until a match is found. There will be an > inflection point where some form of a log(n) binary tree search will perform > better overall, but it would be very interesting to see how many strings you > need to potentially match against before that point is hit.

> Unless the likelihood of matching any given string in your set is completely > random, by ordering the strings in your tables by how frequently they occur, > the amortized cost of parsing a chunk of text would be very competitive > using this approach, I would think.

> A fun experiment for next time, perhaps!

</comment></comment><comment><USER19> Curious if GPU is suitable for similar tasks? Any successful GPU based json or http parser.

<comment><AUTHOR> I'm optimizing for ultra low latency here; i.e. what's the absolute fastest I can detect a prefix match against this known string table? The final assembly version is down around the 6-20 cycle range, depending on what you're doing.

The overhead of dispatching a kernel to the GPU (and subsequent memory copy of the search string) would take tens of thousands (if not hundreds of thousands) of CPU cycles, so, it's not really applicable in this single-shot prefix lookup case.

Where it would be interesting: much larger prefix data sets (say, the name of all known cities, states, countries etc) and identifying where they occur in an even larger text corpus (like a wikipedia dump).

In that approach, you'd obviously compare against a multi-threaded CPU implementation... but, it'd be interesting to see the comparison.

</comment></comment><comment><USER7> This is now the 6th duplicate of this article, click on the (trent.me) link to see the other discussions. Excellent article of course.

<comment><AUTHOR> I only submitted one of those about two weeks ago, if that's any consolation :-)</comment></comment>


What Happens When We Decide That Computers Are Just Devices to Access the Cloud? - <AUTHOR> https://cheapskatesguide.org/articles/cloud-computing.html <comment><USER2> Who's "we"?

The cloud can't give me what I need from my computers, so for me, computers will never be just devices to access the cloud.</comment>


Ask HN: Which static site generator you use? - <AUTHOR> <comment><USER3> I can recommend to use Hugo [0] as a static website generator. They have plenty of themes [1] to choose from. You can still adjust it with basic knowledge in HTML/CSS. Afterward you can chose where to host it. You can use Github Pages [2] for free or pay for a service like DigitalOcean [3]. I wrote a technical cheatsheet [4] on how to setup your own website with these ingredients.

\- [0] [https://gohugo.io/](https://gohugo.io/)

\- [1] [http://themes.gohugo.io/](http://themes.gohugo.io/)

\- [2] [https://pages.github.com/](https://pages.github.com/)

\- [3] [https://www.digitalocean.com/](https://www.digitalocean.com/)

\- [4] [http://www.robinwieruch.de/own-website-in-five- days/](http://www.robinwieruch.de/own-website-in-five-days/)

<comment><USER4> Does GitHub support Hugo? As I only know that it has support for jekyll. If they support then I want try with it. I tried with jekyll but i find customization little complex.

<comment><USER5> Same. As far as I know, GitHub only supports Jekyll. If you need to serve Hugo for static site generator, I would recommend to use GitLab Pages [1]. It's free and you can connect your own domain and TLS certificates. Not to mention, your repository visibility.

[1]: [https://pages.gitlab.io/](https://pages.gitlab.io/)

</comment></comment></comment><comment><USER6> It all depends e.g. what's your favorite (scripting) language? what's your favorite template (language)? what's your favorite configuration format / language? and so on. I've put together a stay static showcase - that shows the same website / sample site (w/ posts, pages, datafiles) in 10+ static website builders / generator - <USER2> [https://github.com/staystatic/staystatic](https://github.com/staystatic/staystatic) Cheers.

</comment><comment><USER7> If you want to try something browser-based, not tied to any scripting languages - I'd like to introduce Pragma ([https://pragma.build](https://pragma.build)). Read the intro blog post [0] and request for an invite if that sounds interesting.

[0] [https://www.laktek.com/2016/11/29/introducing- pragma/](https://www.laktek.com/2016/11/29/introducing-pragma/)

</comment><comment><USER8> Used Jekyll ([https://jekyllrb.com/](https://jekyllrb.com/)) for a while. But now Hugo ([https://gohugo.io/](https://gohugo.io/)).

<comment><USER9> What made you shift to hugo?

<comment><USER8> This: [https://www.youtube.com/watch?v=CdiDYZ51a2o](https://www.youtube.com/watch?v=CdiDYZ51a2o) Not that I need that much speed. But could not resist.

</comment></comment></comment><comment><USER10> I use Jekyll for most static sites where I present information (most of them are internal websites for specific projects inside companies) And I use middleman when I want a little bit more custom things to happen.

</comment><comment><USER11> Jekyll and Middleman both on larger scale production sites.

</comment><comment><USER12> Since my favorite scripting languages produced nothing of value in the last decade I started using hugo and don't care patching it. It just works.

</comment><comment><USER13> Hugo : [https://gohugo.io/](https://gohugo.io/)

</comment><comment><USER14> Octopress, because it handles code formatting particularly well.

</comment><comment><USER15> MyOwnStaticBlogGenerator

</comment><comment><USER16> pelican, it supports jupyter notebooks

<comment><USER17> Out of the box or as a plugin? I can't find anything on the pelican website.

</comment></comment><comment><USER18> Middleman</comment>


Ask HN: MSPA could use scaling help - mkr-hn

This webcomic: http://www.mspaintadventures.com/
Is launching a big thing: http://mspandrew.tumblr.com/post/11881428494/the-lowdown-on-10-25
And they don't know what to do to support the very large load and traffic they're expecting without it costing too much. HN seems like the place to ask for solutions. <comment> mkr-hn Clickables:

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

[http://mspandrew.tumblr.com/post/11881428494/the-lowdown- on-...](http://mspandrew.tumblr.com/post/11881428494/the-lowdown-on-10-25)

</comment><comment><AUTHOR> Newgrounds.com was made for this.

<comment> mkr-hn There are some issues with using NG: [http://www.mspaforums.com/showthread.php?42891-Andrew- Hussie...](http://www.mspaforums.com/showthread.php?42891-Andrew-Hussie-made- a-Tumblr%21&p=5661499&viewfull=1#post5661499)</comment></comment>


Apple and the Kindle - <AUTHOR> http://www.aaronsw.com/weblog/kindledetails

<comment><USER2> > Or (and this is incredibly aggravating) when you select a word in the > Kindle, depending on how common a word it is, the option that comes up > highlighted by default is either "full definition" or "start highlight". > Since e-ink's refresh rate is so slow, you typically don't see what's > actually come up until you've pressed the button for the second time. So I > often "double click" on words to highlight them, but some percentage of the > time this kicks me over into the dictionary and I have to hit back twice to > get out.

I'm on my third Kindle. The latest one, sans keyboard, is the first to have this problem. It's so annoying. Literally sometimes I'll be in the middle of a great passage and try to highlight it and then I'm brought to the dictionary page for a word like "the".

Is there anyone on here who is on the Kindle team and knows when a fix for this will come out?

*Also, as a general commentary, I think the Kindle is a revolutionary device. Moreso than the iPad. I think Bezos knows full well what he is doing and would prefer to keep it under the radar how absolutely amazing and big this thing is going to be. It shocks me that Apple hasn't come out with an eInk reader yet. It's an order of magnitude better for reading than an iPad.

<comment><USER3> After reading ebooks on my iPhone and now iPad, I couldn't go back to the kindle. The UI was just so terrible and slow. I use white on black for night time reading, and can still fall asleep.

Incidentally, this is the same reason I could only use Duck Duck Go for one day before going back to Google search. The Google search UI has just spoiled me with its responsiveness.

<comment><USER2> > The UI was just so terrible and slow.

Have you tried the latest one? It's noticeably faster. Worth the $79. (And I'll get the touch screen as soon as it's available).

> I use white on black for night time reading, and can still fall asleep.

I've heard this from multiple people. I should try it.

I read my Kindle on occasion for hours and hours. Not only does it not hurt my eyes, but it's so light. The iPad is quite heavy.

I really wonder if Apple will ever come out with an eInk screen. After reading how upset Jobs got over Android ripping off the iPhone, I kind of think that maybe they never will and that they'll just let Amazon have that market.

<comment><USER4> > I really wonder if Apple will ever come out with an eInk screen. After > reading how upset Jobs got over Android ripping off the iPhone, I kind of > think that maybe they never will and that they'll just let Amazon have that > market.

Are you saying that Apple came with iPod because no one had made an Mp3 player before?

Apple made iPhone because no one made a phone before?

<comment><USER2> I guess I don't see how they could improve the Kindle drastically this late in the game.

The Kindle should be faster, lighter, and the UI should be a bit easier (but the touchscreen version due out at the end of the month could solve that already).

Amazon's already reduced it almost as much as can be. I feel like if Apple came out with an eInk reader it would be tough to be anything but a "me too" product. Perhaps they could do color eInk? I think it would take an advance like that to make it worthwhile.

<comment><USER5> Color eInk isn't being done because it's a technical problem, not a design problem. Everybody knows color eInk would be cool, we don't need Apple to step forward and say "You know what, color eInk would be cool!"

We just need somebody to invent a feasible one, make it and sell it. You'll then see it in Kindles quickly enough.

<comment><USER6> Color eInk isn't being done because nobody is willing to bet the farm on it. Everybody knows color eInk would be cool, and we DO need someone like Apple to step forward and say "You know what, color eInk would be cool! And here's a billion dollars, make it happen!"

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> To me the Kindle has two killer features: the screen (because I can read it like paper for hours) and its weight (can hold it for hours like a paperback book). Those two things made it a 'wow' device. The 3G access made it effortless.

None of those things seem very clever and have been pretty easily duplicated in the Nook. The software itself (and this applies to Kindle and Nook) is rather ugly and it feels slow to react. Both need Apple to come in and make them work.

<comment><USER8> Please leave my Kindle alone. I don't want it to be fancy. I want to read books on it. Cheap, long battery life, and a screen that reads like a book is as clever as I ever want from it. I have no intention of replacing my kindle anytime soon. I don't care if a new version comes out that's 10 times faster... I'm completely content with the one I have.

When I want to use an iPad (for something other than reading books), then I'll just use my iPad.

<comment><USER9> The first question I always get from people who haven't seen a Kindle before is "can you go on the internet with it?" _sigh_

"No- it's just for reading books. Nothing else."

The problem is, I realise that it can go on the internet. It's just so damn slow that it makes everything else look way better. _Not_ offering web browsing would stop feature creep.

<comment><USER10> Although I agree that removing non-primary features would help have a more honest comparison, there is a great advantage to the Kindle having a web browser.

You can download books straight from the internet to your device. You can go to the Project Gutenberg website (<http://www.gutenberg.org/>) browse for a public domain book, and download it straight to your device. You don't need to use an intermediate computer.

</comment></comment></comment></comment><comment><USER11> I'm beginning to develop a theory that this kind of Apple-fandom is somewhere between being an audiophile and a mentally contagious form of OCD.

I've had complete strangers, totally normal people (picture the exact opposite of a stereotypical techie), raving to me in a shop about how great their Kindle is because they saw me play with the demo device. That's a home run in anyone's language.

But Aaron, who seems to have trained himself to appreciate the finer details, has this joyous experience ruined for him in much the same way a wine snob can no longer enjoy an even passable glass of wine.

I guess the missing factor is how much effort is expended on these nicities versus the return on that investment.

If the text below a main icon is cut off, is that a sign of how shoddily the entire thing is put together, or is it simply _not important_ , compared with the many benefits the device gives you?

<comment><USER12> Its just annoying, even insulting, that something that could have been fixed, permanently, for everybody, was let out the door with that stain on it. Unlike wine, software CAN be (nearly) perfect for everybody, every time.

</comment></comment><comment><USER13> There's a theory of interpersonal relationships that says you need 4-5 positive interactions to balance every 1 negative interaction, if a friendship / relationship is to be sustainable. I'd argue that with devices and software, that ratio goes way up - maybe at least 10:1 or 20:1. That's why even a small annoyance can balance a largely positive experience.

</comment><comment><USER14> Aaron! Font size! Bigger!

<comment><USER15> Seriously. I have good eyes but if I have to zoom in at 300% on your page to be able to read it, something is definitely wrong.

<comment><USER16> I've since given up hoping people will stop thinking that tiny, tiny fonts are awesome. Cause I guess nothing makes the article you wrote more awesome than making it impossible for humans to read. Readability, ftw. <http://www.readability.com/>

</comment></comment></comment><comment><USER17> I love my Kindle. One of the best tech buys in recent memory. The thing I want to be able to do is share books with my wife as if they were 'real books'. In other words, one of us at a time gets a lock on it, but there's no time limit.

<comment><USER5> She's your wife. Trade Kindles for the day.

<comment><USER17> It'd get kind of awkward quickly, as I read books at a much faster rate than she does, so I'd always be loaning myself books from my Kindle, while she meanders her way through my books.

All in all, not an ideal solution given what the technology should enable us to do.

</comment></comment></comment><comment><USER18> I really wonder why no ones mentions typography. In terms of great typesetting the Kindle is somewhere in the 60's. Since at least LaTEX (not talking about Adobe and Apple products) ligatures and other niceties found their way into computers. Any by all means - this is a dedicated reading-machine! I still love my Kindle, mainly for jgrahamc's reasons.

</comment><comment><USER19> I used to be quite skeptical of Kindle and a dedicated book reading device until I was gifted a Kindle. My wife got tired of my buying hundreds of books and having it fill up the house and the Kindle TV ad did the trick.

Now that I've used it for a few months, I'm a Kindle convert. I carry it with me all the time - conveniently fits into my coat pocket and weighs so little - and I whip it out whenever I'm a line or at an airport and all those otherwise wasted time.

It has remarkable battery life - I normally get 2-3 weeks between charges - and more if I turn off WiFi. The more I use it, the more I like all the small details which while quirky and not quite upto iPad levels of overall usability adds up to a very convenient book reading experience. I used to lament the space wasted on the physical keyboard but I'm not such a fan of the new touch Kindles.

Now I wish I had all my books on my Kindle.

</comment><comment><USER20> I wish they had the same "attention to detail" on their website. One reason I stopped buying from them was every time I went to the website I was bombarded for offers for Amazon Prime, Credits Cards, Free Shipping and other products.

The problem was that if I clicked on any of those offers the website would eventually work out I was a non-US user and tell me I wasn't eligible. But Amazon already knew that when they showed me the offers in the first place.

Any site that has 30% of their frontpage taunting me with cool stuff I can't buy obvious doesn't want me as a customer.

</comment><comment><USER21> So far I've had a pretty frustrating experience with the Kindle (Kindle 4 no keyboard, no touchscreen) from the get-go. Sure, the box was nice, but as soon as I powered it on it was frustrating.

Since the Kindle was a gift, I had to enter in my Amazon account information before I could do _anything_ else. Total buzzkill. I wanted to flip through a book and see what the screen was like and how it worked, but instead I have to laboriously type in my 35-character password like I'm using an NES controller.

After that, there's no sample books on there- you'd think they could put a public domain book on there for free. Every MP3 player I've ever bought comes with a few sample songs. Ok, fine. Now I have to hook it up to my computer via USB. Put an epub file on there. It doesn't support epub? Ok, fine. Put an RTF file on there. That doesn't work. Ok, fine.

Finally put a .txt file on there of a book I'm halfway through the paper version of. Apparently the Kindle has a weird concept of pages for txt documents, so I have to hit the "Next Page" button 97 times, or guess what "location" I'm at (1456 out of 4452 I guess?) and enter that in.

All of that frustration, in the first 30 minutes, just to get an idea of what it is like to read on it and page through a book. Never had that kind of experience with an Apple product. "Unboxing" experiences with Apple products have become a religious experience for a reason. Amazon is still _far_ short of that.

<comment><USER22> On the other hand, when you get a Kindle in the mail you don't have to connect it to a computer with iTunes on it to get it to work.

I can also load books from my computer onto the Kindle using drag-and-drop without needing iTunes (or any Amazon software) installed.

<comment><USER23> Connecting with iTunes is actually no longer required for iOS devices starting with iOS 5.

You can also add PDFs to iBooks on the device without iTunes -- not sure about epub files though.

<comment><USER22> But iTunes is required to update my ipod to iOS 5 :-)

I've never been able to get large pdf's onto my ipod without itunes. Can't email them because they're too big, and the ipod cannot browse local shared directories.

<comment><USER24> Dropbox?

</comment></comment></comment></comment></comment><comment><USER25> > small details that delight get buried under small details that annoy

Must point that even Apple software/hardware have their own trivial features that prove to be annoying for some users (remember no right-click anyone?).

Amazon has achieved a very usable device with the Kindle in such a short foray into consumer electronics, for which Apple has had around 3 decades of experience to build on. Here's to hoping attention to detail and UX takes giant strides at Amazon improving upon what is already a very good product.

<comment><USER26> Remember no right-click anyone?" I have yet to forget the right click and more importantly middle click...

</comment></comment><comment><USER27> I have to wonder: does Apple spend more time playing with each new piece of technology internally before releasing it?

I can see in the rush to launch that you can certainly hit 100% of your feature list and still not hit the things that count.

When you see something like a ".com" key on the keyboard whenever an internet address is requested, you have to wonder if it wasn't in the original design but eventually someone played with it enough and thought it up.

</comment><comment><USER28> I was a big fan of the original Kindle's wheel navigation. It just felt right, like a Model M keyboard.

</comment><comment><USER29> > _lifetime unlimited worldwide_ data plan

Unfortunately the web-browser that makes this useful (beyond buying books) is still labeled "experimental", years later. Meaning it can be dropped at any time.

</comment><comment><USER30> I didn't know about Kindles being already logged in. That's clever--"out- Apple-ing Apple". I'd worry a bit about package thieves but that's probably mostly irrational.

</comment><comment><USER31> Whatever UI ugliness exists in the Kindle and its apps don't matter much to most Kindle owners. They just want to read. [typo edit]

</comment><comment><USER32> I loved my Kindle(s), but the screens are very fragile. I've already cracked two of them.

If you have a Kindle, you _need_ a case, and should never take it out. iPads seem much more durable (and indeed heavier)

</comment><comment><USER33> "And this is all before I've even got to the disastrous incompatibilities between the Kindle device, the Kindle for Mac app, the Kindle for iOS app, the Kindle Online Reader (read.amazon.com), and the kindle.amazon.com social network — all of which are full of gruesome interface annoyances of their own."

I just bought a Kindle, and besides my first attempt at buying one resulted in returning it to Best Buy because of a damaged screen, I love it. I had been reading Kindle books in my iPad and also loved the app experience. Mostly, the ability to highlight and annotate at will, and have an online repository of that to refer to, were the little details that sold me.

But what are the incompatibilities that he refers to?

However, on the $79 kindle, the details are definitely flubbed. The page turning/return/home screen keys make no logical sense. I apparently ordered one of those "Special Offers" by total accident...I must have pressed a confirm button when I meant to press whatever the hell stands for the "Cancel" button.

At $40 (for an interior design class), that's almost half the Kindle retail price. Not a bad monetization plan, I guess.

<comment><USER34> I'm 100% sure you can cancel whatever you accidentally ordered on Amazon.com.

Just like One-click ordering, the point is to make a purchase easy and let only the people who don't want to go through with it cancel, not to bilk people out of money via misclicks.

<comment><USER33> So this "Special Offer" was a LivingSocial deal. I would agree with you but I looked over the email many times, and my own account page. There is not only no easily visible option to cancel, there is no email contact. I have to call to complain.

Even more befuddling is that every Amazon purchase I have ever made has resulted in a confirmation email minutes after the purchase. This "Special Offer"'s confirmation came to me at 2AM, well after I went to bed. I'm willing to chalk this up to me mistakenly hitting the buttons and ordering the offer while awake and that there's a delay to process it on the LivingSocial end. Either way, it was not reassuring.

<comment><USER35> Amazon seems to delay the confirmations on some of their digital purchases; definitely MP3s and maybe video (IIRC). Believe at least in those cases, it's to make the CC processors happy (batching lots of small single purchases). Apple does the same thing for the iTunes/App store, though it seems to be on the scale of days instead of hours there.

edit: to be clear, by "delay the confirmations" I meant to say "delay the actual purchase"; the purchase(s) doesn't actually get charged until their time threshold hits.

<comment><USER36> Nothing makes CC processors happier than many tiny transactions. Apple and Amazon defer and batch transactions in order to save a fortune on transaction fees, which traditionally involve a fixed cost on the order of tens of cents, plus a much smaller percentage of the total. It's a huge bite of a ~$1 purchase.

<comment><USER35> What I meant to say. Way too long of a debugging session earlier...

</comment></comment></comment></comment></comment></comment><comment><USER26> I cannot highlight/annotate samples. I have a second generation kindle. Is this a new feature of the newer models?

<comment><USER37> Serious question: Why would you want to highlight or annotate a small sample of a book?

<comment><USER38> Maybe you found that section particularly interesting and would like to look back at it later? Maybe you're reading the book for a class and instead of taking notes in the margin, you're taking notes on the Kindle.

I actually find myself highlighting stuff all the time. You can also see areas of the book that other people highlighted, which adds a kinda neat social aspect that isn't usually present in reading.

<comment><USER37> I didn't mean highlighting in general. That I get. I meant highlighting a _sample_ of a book.</comment></comment></comment></comment>


Apple Blocks Spotify in the U.S. - <AUTHOR> http://www.wired.com/epicenter/2010/10/apple-blocks-spotify-in-the-u-s-report/

<comment><USER2> It seems a bit disingenuous to say that Apple is "blocking" it. They may be working against it -- and probably are -- but blocking implies Apple has some magical veto. It might be hard to believe, but this sort of thing is pretty normal in the capitalist wunderland.

</comment><comment><USER3> I don't like the naive tone of this article. First, they describe the prospect of Apple fighting the service as 'sinister.'Second, they say Apple are trying to scare labels by saying Spotify generates little revenue, which must be 'scaremongering' because Apple obviously 'don't care about record label profits.'

There's nothing mysterious going on here... Spotify just doesn't make any significant money for anyone. It's a big free party that could disrupt proper businesses.

I also don't see how Apple are 'almost inevitably' going to launch a Spotify style service. Where's their evidence for that, outside a large data-centre being built - which could be for any number of purposes.

<comment><USER4> Just curious, why do you believe that Spotify doesn't make any money for anyone?

<comment><USER3> They seem suspiciously tight-lipped about how much money they take, then there's been a few articles detailing how the royalties earned by musicians/publishers per play are minuscule. And just listening to the service, the adverts that get played are by charities and government for the most part, there doesn't seem to be any big contracts there. Plus the free service is excellent so I can't imagine there conversion rate to Premium membership is very high. And even if it is, the small amounts they charge, compared to the vast amount of intellectual property they're making available, and the bandwidth needed to provide it, doesn't make it look like a good business for the industry to get involved in.

<comment><USER4> I agree that they are very tight-lipped about actual revenue streams, but I don't think that is their fault. I would guess that it is the record companies that want to keep such numbers secret. One of the guys who started Spotify previously did Tradedoubler, so they know something about on-line ads. While they haven't said much officially, they did comment that ad-sales were going quite well.

Regarding what musicians earn, the most interesting note is probably that the Swedish collection agency (STIM) said about half a year ago or more that Spotify is the number one digital earner for music in Sweden (passing iTunes for example).

As for the bandwidth, see the paper I linked in another comment for some interesting statistics on how much bandwidth is actually needed (tl;dr version, surprisingly little thanks to p2p and caches).

<comment><USER3> Hmm, interesting point about the bandwidth and about Sweden. But I'd like to know if Spotify cannibalized the iTunes sales, cause that's kind of the whole point about it being a free frenzy and not making significant money. Put it this way, they may have taken in more money than iTunes... but how much more music did they give away? (and even counting raw playing time, that doesn't capture the full effect of customers knowing they can access something whenever they want)

<comment><USER4> As far as I remember it (it was something a STIM representative said in an interview, can't find it just now), it was about how the revenues from Spotify had increased significantly.

Also, one should remember that, AFAIK, the initial idea was the free account type and Premium came later. It is all about competing with piracy, making something that is easier and more convenient for the user while still giving a revenue stream to the rightsholders.

<comment><USER3> I kinda thought they were always planning on Premium charges though, they just wanted to build some momentum first. My main problem with it is I can see 'the rights-holders' making a good new revenue stream, but only in the sense of people/companies that own massive publishing catalogs. The _individual_ rights-holders, eg. the songwriters, I fear are being sold up the river.

<comment><USER4> I was in the original beta-trials of Spotify (started second half of 2007), and the info then seemed to indicate that the intended model was ad-financed. A lot of people apparently asked about paying to get rid of the ads.

As for smaller artists, compare it with the situation in commercial radio. A few radio-plays will not get you very much money, but the number of people that listened to your song is actually quite high.

<comment><USER3> Comparing it to radio is where the trouble starts. A potential customer cannot rely upon radio to access your music/product. At best they'll hear a few of the artist's tracks, if they're patient and lucky. Therefore the radio is in no way a substitute for owning the LP, it's more like an advert/complement than a competing service. But Spotify DOES let the potential customer access your product in full, removing the main incentive to buy your LP. Furthermore, you're not only competing with a free version of your _own_ product, your competing with a vast catalog of other music, millions of records that can be accessed effortlessly. "Should I spend £10 on this one album, or should I spend £10 for a month of unlimited access to endless high-quality music?" The economic position this puts individual artists in is _dire_.

Also, another thing about the ads is sometimes they're hardly ads at all, they're just Spotify announcements. I can't believe they'd be wasting spots like that if they were really pulling in serious advertising money.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> don't doubt this story for one second. consumers may love the service, but no way they achieve the 10% conversion rates that the labels have called for.

spotify has talked a big game, but their "imminent" US launch has yet to happen...and i'm not convinced it ever will.

all said, i'd love to see daniel ek (spotify ceo) & steve jobs at the same table...

</comment><comment><USER6> Funny how it so many journalists believe that Apple would need a huge $1 billion data center to do streaming when Spotify obviously doesn't.

<comment><USER7> Apple doing it and Spotify doing it are two completely different things, traffic-wise. Assuming that Apple is basing their streaming solution off of Lala's model (not a given, but why else acquire them?), we're talking about giving _every_ iTunes user streaming access to their entire music library, _including songs that weren't purchased through iTunes_ (which would require a serious amount of cloud storage). Spotify reached one million users sometime last year; there are how many millions of iPhones and iPod Touch's out in the world?

<comment><USER4> Even though the most recent numbers from Spotify indicate something on the order of 10 million users, I agree that Apple still has larger innate audience. However, Spotify uses filesharing to further decrease the load on their own servers, which I don't think Lala used. For some fun details on the Spotify model, see <http://www.csc.kth.se/~gkreitz/spotify-p2p10/></comment></comment></comment>


Show HN: Screen.farm – Send a webpage to any connected browser window - <AUTHOR> https://screen.farm <comment><USER2> Feedback: I'm sorry but I don't understand what's this. I see "mapy" in a big box and, when I go to the provided URL I get to the same page but a different word.

This app (I guess it's an app?) would really benefit from some sort of 1-2-3 tutorial.

I'm still interested though. What's this?

<comment><AUTHOR> Thanks for your feedback. Now I don't really understand why I thought it wouldn't need instructions.

You can use this to push a webpage to any browser window, with minimal setup and interaction. You can make your tablet or phone a non-interactive external display.

Here are some instructions:

1\. Add your device to your "farm" by scanning the QR code or entering the URL on that device

2\. Optionally, edit the auto-generated name of that window (in your case "mapy"), to something like: "tablet"/"phone"/"oldlaptop".

3\. See the bookmarklet link for your device appear on your computer, drag this to your bookmark bar

4\. Visit some website then press the bookmark => the website should now be opened on the respective device. Alternatively, you can use the REST API to send a URL or image to a device

With a simple Ruby script (I will publish that soon), you can watch your Desktop folder on OS X for newly created screenshots, and upload them as they are created, so in effect, you take a screenshot and it instantly appears on your tablet.

</comment></comment><comment><USER3> I figured out the use of this; its a better and quicker alternative to PushBullet. If you connect your phone and laptop then when you open a link on your laptop the same link can open on your phone simultaneously. It's really nice. Yeah, I agree that there must be some 1-2-3 tutorial.

</comment><comment><USER4> What would a use case for this be?

<comment><USER5> Many companies (incl. ours) have displays in lobbies etc. to show dashboards, news, twitter feeds etc.

Usually there is a lot of fuss when something breaks (finding spare keyboard and mouse, connecting it to hidden pc).

If I get this right, this will create a 'remote control' for each such screen, right?

<comment><AUTHOR> It doesn't create a fully functional remote control. All you can do is push content to a connected browser window. If the browser crashes, you'll need a keyboard or another remote access tool.

This tool is just a quick and simple way to make use of your extra screens. You can use a bookmarklet to make a webpage instantly appear on a screen, or with a tool using the REST API, you can make the screenshots you make instantly appear on an external screen.

</comment></comment></comment><comment><USER6> Is this open source?

<comment><AUTHOR> It will be soon, I'll just have to write a readme.

<comment><AUTHOR> Here's the source: [https://github.com/stimulus- software/screen.farm](https://github.com/stimulus-software/screen.farm)</comment></comment></comment>


Why transparent salaries make sense - <AUTHOR> http://blog.granttree.co.uk/post/70579054648/why-transparent-salaries-make-sense <comment><USER3> I used to think transparent salaries were a good idea. Until I was hiring people. Over time, I learned that it's not just transparent salaries in your own company that causes a problem - it's transparent salaries in other people's companies.

I've worked for multiple HR companies who performed studies, all of which showed that salary isn't the highest priority on employee concerns. Yet, in my experience, the number one reason I lose employees (or have left a job) was money.

Also, yes, I have poached employees from competitors by simply finding out how much they were making and offering more. You want to show me how much you are paying your people? It will tell me either that you are not profitable (if you are paying too much) or it will tell me the exact number I need to beat to take your best people.

And rest assured, I WILL take your best people.

Rest assured, I HAVE had my best people taken as well.

Business is not a democracy. Business is a competition. It is a fight for survival. No business is going to be so transparent to reveal enough to help their competitors. Even those 'transparent' companies who post on blogs their entire process? Trust me, they ain't showing you some of the most important stuff. They are marketing to you.

I don't know how this comment will be taken on HN, but I realized some time back that the number of people on HN who are smart is very high, but the number of people who actually run businesses is much, much lower. So I run a company. My comments are based on my experience.

<comment><USER4> If you want to know the salary of someone you want to hire, you can just ask him... In which way is it hard?

<comment><USER5> It is one of those potentially awkward questions - a candidate has no obligation to answer that question, and in some cases, I believe it is even illegal to ask.

<comment><USER6> It's not illegal in the US to ask what a candidate is getting paid, but you also (typically) have no good way to verify their answer.

</comment></comment></comment></comment><comment><USER7> For people who are skeptical this sort of transparency could ever work, consider that in Norway (also Finland and to a lesser extent Sweden) tax returns are completely open to the public:

[http://skattelister.no/](http://skattelister.no/)

So you can quickly look up what somebody's income and net worth are and the public at large are in favor of it.

<comment><USER8> I don't know how is in those countries here in Canada taxes are a combination of several factors, and you can be in the same salary range that somebody else and still be paying a significant different amount.

<comment><USER7> Income, tax, and net worth are all public in Norway, so that issue doesn't exist.

</comment></comment></comment><comment><USER9> I work at a great mid-sized (300+ employees) company that has a transparent, set pay scale, with an even simpler formula than Buffer. Each inter-level promotion is a 10% bump, and a level promotion is 20%, all the way up. I love it.

A positive side effect is that promotions become more of a "are you performing at this level?" question rather than a politicking game, and responsibilities at each level become much more clearly defined. I think that many companies could benefit from adopting similar structures.

</comment><comment><USER10> I am progressive enough to love all the things people are changing up in the business world to make things better. I am also conservative enough to be somewhat dubious that things that sound awesome are _actually_ awesome. Usually (but not always) things are the way they are because other things have been tried and this was the optimum solution found at the time. Many times we forget the initial experiments and start fresh without learning from all the work that went on before. This can both be a good thing and a bad thing.

My point is that as readers we should be careful. We need to distinguish between stories that tell us things we are predisposed to like and things that actually work. Daniel (swombat) has done a great job of sharing some personal experiences. I say let us let the real world decide. If we can all work from the beach in a transparent organization where there are no bosses? Freaking count me in on some of that action. But either it works or it doesn't. A few stories here or there about small companies trying new things is more of a fun read than anything else.

Good luck to all these experiments, though. With so many cool things being tried, I expect to see some great results over the next few years as the marketplace sorts out the efficient business ideas from the popular ones. Really cool times ahead!

</comment><comment><USER11> Transparency sounds good from the employer perspective. You get to control the negotiation procedure (by completely eliminating it) and set salaries how you like. Take it or leave it.

Transparency also sounds good to lots of engineers who don't like negotiation, see it as unfair, and aren't any good at it. No need to bother with all that. Salaries are set. Everything is "Fair", which resonates nicely with an engineer.

But it sounds really bad to an engineer who's genuinely good at what he does and knows how to negotiate a rate that reflects that. Why would a fella leave, say, 100k on the table to go work for a place like Buffer, where even the CEO is only making $150k/year? No thanks, but thanks for saving us the trouble.

The worst thing that could happen is that this sort of thing takes over the industry. That's definitely a possiblity because it's so attractive to those first two groups, and let's face it, there are a lot more managers, introverts and suckers in this industry than guys who are willing to negotiate their worth.

I could see a whole generation of engineers coming up, expecting to be valued on seniority only, and thinking the Industry Average is the correct value for their output.

Not a happy prospect.

<comment><AUTHOR> You wouldn't - and that's fine.

We don't have to hire everybody. If what you care about is salary above all other things, that's absolutely fine. I don't judge you for it. I care about making money too. The kind of people we do want to hire care about making enough money, and making a fair amount in relation to how the company is doing, but they care just as much about working in a great environment which has the features that transparency allows us to have.

In other words, you may be very good at what you do, but based on the above you would be a poor culture fit for a place like GrantTree or Buffer - <USER2> that's absolutely fine, on both sides.

<comment><USER11> Why assume that somebody asking for their market rate wouldn't be a good fit for your company?

Framing salary discussions in the context of how the company is doing is one way that employers try to manipulate naive young engineers. Same with all "8 Pieces of Flair is the minimum, but if you want to wear more, we encourage that" tactics, it tries to compare something relevant to the employee with a second, completely irrelevant thing. It's easy enough to spin those discussions in a way that make it look like we're all pitching together to build something great, but at the end of the day, it's still a negotiating tactic.

Personally, I prefer to separate salary negotiation from the rest of the decision about whether somebody would be a good fit. After all, that's a one- time negotiation that probably won't ever be revisited. A guy's skills, sense of humor, leadership ability and overall fun-to-be-around-ishness are the things that matter every day for the rest of his tenure, and are therefore a lot more important when deciding whether you want him on your team.

<comment><AUTHOR> > _Why assume that somebody asking for their market rate wouldn 't be a good > fit for your company?_

That's twisting my words. What I said is that if salary is their primary concern, then they're not a good fit. Asking for your market rate is just fine, so long as you understand that what we can give you is constrained by what has been decided by the team is a reasonable level of pay for that position.

Someone who, knowing our culture, still insists on being an exception and getting a different salary, is basically saying that they care far more about their own outcome than about the outcome for the company as a whole. Teamwork is one of our core values, so they've just marked themselves out as a bad culture fit.

> _Personally, I prefer to separate salary negotiation from the rest of the > decision about whether somebody would be a good fit._

Arguably, with our system the salary negotiation is entirely separated out - and then reduced to nothing. There is no salary negotiation. The salary is what's on offer in the job ad, and that's that. If you don't like it, don't apply.

</comment></comment></comment></comment><comment><USER12> And tomorrow write somebody the article "I read about transparent salaries yesterday".

Dont miss on Sunday: "Show HN: How i read an article about an article that assumes, that transparent salaries make sense."

Sorry, i cant resist.

<comment><USER8> Don't be sorry, that idea comes to my mind any time I see that pattern too. It is somehow funny, like people hacking the stories and titles to be used as another level of conversation.

Not new nor HN exclusive, but still interesting.

<comment><USER12> Sometimes i am not sure if it is for an another level of conversation, or simple a try to get some traffic from strong visited topics.

</comment></comment></comment><comment><USER13> Transparency makes sense _in the right context_ , but adding this qualification makes the suggestion less controversial, and therefore less noteworthy, since almost anything can make sense in the right context.

One of the contexts in which full transparency is less appropriate is where a business has a legacy of inconsistent approaches to hiring and remuneration, meaning that person A is paid significantly more or less than person B, even though both do the same job at the same level. We might all agree this isn't fair, but at the same time it isn't necessarily something that is easily fixed. A business might simply not be able to afford to fix salary disparity in one hit. Transparency in this context might do more harm than good because it brings the disparity to the fore gives it a focus it would not otherwise have. It reduces the options available to the company that wants to fix this disparity, in particular it reduces the timeframe in which the disparity might be removed.

In fact, this is my recommendation for fixing a problem of salary disparity; institute a policy toward salary adjustment that makes it clear that discrepancies will _over time_ tend to be eliminated. You can be fully open about this policy without disclosing individual salaries, and you can adjust the timeframe to fit your business context. If you're cash-poor you can take longer to fix the problem.

In other words, we should be transparent about the approach to setting and adjusting salaries, but the situation with individual salaries is more complicated.

<comment><AUTHOR> The catch is, transparency forces a certain amount of fairness to come with it. I should probably have mentioned that in the article too.

It's difficult to keep unfair arrangements when all is transparent. You can't just implement transparent salaries, without also making the salary scale fair. And the benefit there is that once salaries are transparent, everyone knows that they're fair, because they can verify it for themselves.

<comment><USER13> Transparency forces fairness assuming you can afford to fix the discrepancies in an acceptable amount of time.

If you can't fix discrepancies in an acceptable amount of time then full transparency forces something unpleasant, and in this context it is potentially unhelpful to everyone.

<comment><AUTHOR> Of course. If you're committed down a path where your company is basically unfair to its employees, then yeah, transparency won't help.

A good example of transparency not helping is our sudden transparency about the activities of the NSA. Obviously that's not helping them. Though arguably it is helping us.

In a case where a company is intrinsically unfair to its employees and can't correct that, transparency would probably hurt the company but help all the employees - by sending a strong message that it's time to get the hell out of this crappy company.

<comment><USER13> It's the other way round - if a company is committed to a path of fairness but has inherited an unfair legacy of salary disparity (this can happen in many ways and is not always because of overt unfairness) then transparency can make it harder for the company to fix the problem.

</comment></comment></comment></comment></comment><comment><USER14> One issue I have with transparent salaries is that employment is an agreement between the employee and the company: it's a two-way street. Yet when you implement transparent salaries, the company is unilaterally deciding to share critical information in that agreement.

I am a huge fan of a company transparently sharing its own information with employees. Revenue, profitability, sales, etc... People like to feel like they know what's going on. But it's another to share an employee's information with other employees. There are many people (and I recognize this is a cultural norm, so it differs around the world) who like to keep their salary private, and it should be their prerogative.

<comment><USER15> Exactly this! Who audits this? It is a corporate "policy" effectively, which the controlling interest can lie in exactly as much as they feel like... transparency for all people not in a place to control the "numbers".

This is an insanely one sided arrangement, that can easily be leverage to keep employees in line. "Don't you see that Jim only took a 2% raise this year, do you really think you deserve more than Jim? He has four kids!"

<comment><AUTHOR> It's far more complex and simple than that in our case. The starting point is that 50% of revenue is allocated to "costs": overheads, base salaries, commissions and the bonus pool.

How people decide to split that up between themselves is up to them, through a process that itself is open and semi-democratic (getting more so with each round of changes).

If anything, I would say that seeing transparency as a weapon of management is really misguided. A manager could always lie and claim that Jim only took a 2% raise this year. With transparency, they can only say that if that is in fact the verifiable truth.

</comment></comment></comment><comment><USER16> "And, strangely enough, people react to that by behaving like adults."

Unless they don't! When access to information is warranted only to people responsible of having access, things stay secure from a wide range of angles (the golden rule of security - "deny everything by default, the access is explicit exception"). People aren't all milk and honey, they also have inner bad parts, and the usual systems we employ have (among other things) the task of keeping those parts in check (at least as much as possible). Like any other free commodity, the (useful) information can be not only used, but also abused. Knowing intimately a system one becomes able to game it. Or you think that doesn't happen or it's unlikely? Just to leave an example - what do you expect will think someone sweating in stress and efforts all day long, working close to coworker better paid with apparently less work/effort involved? That that coworker is better at what he/she does? You'd be lucky! That one will more likely think that the system is unfair. And if these kind of people won't leave right away to find "rightness" somewhere else, they (although not admittedly) will self-attune to give you the minimum for what they get (it's easy to do that given enough info) and maybe focus on emulating good visible marks (also easier when you have sufficient information to learn the system well enough). This is just one scenario from many possible other ones (driven from the human inner bad parts). I'm sorry, but I can not ignore the consequences of this kind of thinking. I lived in such environment, I felt it, and I also saw it going down. Maybe it doesn't ring to you, but this "total transparency" is just a juicy piece of communism.

<comment><AUTHOR> _Just to leave an example - what do you expect will think someone sweating in stress and efforts all day long, working close to coworker better paid with apparently less work /effort involved? That that coworker is better at what he/she does? You'd be lucky! That one will more likely think that the system is unfair._

As I mentioned in another comment (and should have mentioned in the article), this is a natural consequence of transparency: it demands fairness. There is nowhere for unfair compensation schemes to hide with full transparency.

So in your example, the underpaid worker would naturally demand to be paid fairly. And the response to that better be something like "yes, this is how we'll do it" \- otherwise, you're right, they will leave (a good call, if they're working in a company that treats them unfairly). This is definitely a plus for the employees.

From your username you sound Romanian (I was born there, my parents left just after I was born and I grew up in Switzerland). I know from my parents that Romania under communism was a pretty horrible place. But I also know from talking to them that it was a place that was full of fear and mistrust. We're using transparency to increase trust, and it works. Sure, from one angle, if you squint the right way, it looks like some sort of "communist" nonsense to open up all this information, but I can assure you that at least at the scale we're at, the effect is to increase trust and empower people, not to reduce them to fearful subjects of the state.

</comment></comment><comment><USER17> Keep in mind, a lot of jobs have transparent (or at least published) salaries which hasn't seemed to render negotiation tactics ineffective or, for that matter, raised the maturity level of people holding said jobs.

For example, professional athletes and political office holders.

I think a more difficult, and more desirable, target for transparency is not one's salary, but one's contribution to the top and/or bottom lines.

</comment><comment><USER18> I'm not really sure. At least, this would help others poaching from your company, as they know exactly what your employees are getting?

<comment><USER19> This article is talking about internally transparent salaries. The salaries aren't disclosed to outside parties, so the policy doesn't help poachers.

<comment><USER18> Sorry, it seems the Buffer article gave me a Halo here.

</comment></comment></comment><comment><USER20> I'm curious how this internally transparent policy works when hiring new people? Do they tell you what everyone else is making before you negotiate, or only after you've been hired? Either way, that feels potentially awkward.

</comment><comment><USER21> Maybe, but to me, this still looks like an intrusion to people's privacy.

Edit

To those "but if they tell you before". I reply: it still is. Google/Facebook tell you before that they will use your data for advertisement, some still think that's an intrusion of people's privacy anyway. However, Google/Facebook give me something in return, so I play along, but what's in it for me when a company makes my paycheck public? I just don't see the point of it. Also, once you grow over a certain size, I don't believe you can make up salaries with such rigid rules.

<comment><USER22> If the organization makes it clear to potential hires _before_ they are hired that the company has an open salary policy then the potential hire can choose to maintain their privacy and work elsewhere that does not have an open policy. In this case it probably is not an intrusion into employee privacy.

If an organization were to do this after the fact (i.e. when there are already employees on board) then I think you are right.</comment></comment>


The Facebook Ratio - <AUTHOR> http://www.tenpoundhammer.com/2011/11/facebook-ratio.html

<comment><USER2> 2/3 things that you don't think you want to see, but will use heavily anyway</comment>


Why does Google search do this? - <AUTHOR>

Every time I mis-type something, Google offers a suggested correct spelling, by showing a link titled "Showing results for <i>Foobar</i>". I always impulsively click this link.
When I do this, it refreshes the entire page. Why doesn't clicking this link just hide that part of the page? I'm already being shown results for that term - why do the search again and waste 2 more seconds of my time?
E.g. https://www.google.com.au/search?q=exmaple <comment><USER2> When you click the correct spelling, it changes the url to:

[https://www.google.com.au/search?q=example](https://www.google.com.au/search?q=example)

I'd assume they do this so that, if you share or bookmark this url, it's one less step for their servers later?

</comment><comment><USER3> Seems logical to me. You (and millions others) routinely misspell things, but mean to search for clean terms. So google auto-correct search terms first and shows results for clean terms. "Clicking" would mean you actually want to search for "misspelled" variation.

So impulsively clicking on this link would mean that you just need to get your impulses in order.</comment>


Black Swan predicts: Apple buys Facebook? - <AUTHOR> http://www.bizjournals.com/sanjose/blog/2010/12/outrageous-predictions.html

<comment><USER2> Won't happen. Sure, it would be a great acquisition for Apple, but the author doesn't explain why Facebook would even want to get acquired rather than going public. Facebook isn't going to sell for $50 Billion, they have too many hands in the cookie jar at this point to sell for the market value. Let alone that Apple doesn't even have enough cash.

</comment><comment><USER3> There is only one company I would love to see Apple acquire - Nintendo</comment>


Forget Photoshop. Adobe Is a Marketing Company Now - <AUTHOR> https://www.bloomberg.com/news/articles/2019-03-27/forget-photoshop-adobe-is-a-marketing-company-now <comment><USER2> Shame they're no good at it. As someone who's used Experience Cloud (and more accurately, Target), the system is absolutely awful in both usability and general UX design. Constantly struggles to load the original website being edited, likes to overwrite random bits of code if you use their tools for updating text in A/B tests, has multiple buttons marked save which do different things, lacks common options compared to competitors and has probably the worst interface for selecting elements to track clicks on I've ever seen.

<comment><USER3> Adobe hasn't made a product I'd pay money for in almost ten years. I'm still using all things ~CS3, or whatever the last generation of non-subscription apps was, and I really don't feel like I'm missing out on anything.

<comment><USER4> > or whatever the last generation of non-subscription apps was

Fwiw, this was CS6, not CS3.

Assuming you're talking about CS6, I agree and am doing the same thing. I also don't think it's a coincidence that Creative Suite stopped improving at the same time people became forced to keep paying regardless of whether the product improved.

<comment><USER3> Their backwards-compatibility suffered too. What a coincidence.

</comment></comment></comment></comment><comment><USER5> What a shame. They went from a company producing tools that empowered creatives to deliver amazing experiences to making tools that degrade experiences.</comment>


Electronic Arts DeluxePaint early source code - <AUTHOR> http://www.computerhistory.org/_static/atchm/electronic-arts-deluxepaint-early-source-code/ <comment><USER2> Still waiting for the HyperCard source code to be released. I am acquainted with one of the members of the original HyperCard team, but he says his old floppies are no longer readable. :(</comment>


Wikipedia Fails at Life - <AUTHOR> http://artem.posterous.com/wikipedia-fails-at-life

<comment><USER2> I don't get it. What's this? Catch-22 at Wikipedia?

<comment><AUTHOR> Me neither. I was trying to file an issue for false positives and got denied due to a false positive error. No wonder these things never get fixed.</comment></comment>