No More Long Waits on Companies Support Line -  Nevahold.com - <AUTHOR> http://ratemystartup.com/no-more-long-waits-on-companies-support-line-nevahold-com/ <comment><USER2> Yet another site with a page blanking "pop-up" demanding participation long before you have any opportunity to evaluate what is on offer.

My tolerance of this is zero. I do not read the page - potential audience size -1.

<comment><USER3> Given the pandemic of these things over the last few years, I thought I was the only remaining person _this_ annoyed by these silly boxes.

I go to a page to read the content, not to be harassed by pop-overs. I see one, I leave.

<comment><USER4> Fortunately (or unfortunately) the reason these pop-overs are still used is because they still work.

Users are much more likely to perform an action (ex. subscribe to a mailing list) when it is presented to them in a pop-over. (At least that is what my experiences have been)

If you hate them or not, they do work and until the numbers prove otherwise site owners will continue to use them. The decision purely comes down to the best way to increase key metrics.

In full disclosure - I am the founder of <http://RateMyStartup.com> \- The site lists new starts (and uses pop-overs). I would recommend checking out Nevahold.com directly to give it a chance. It really is a cool concept for a startup.

</comment></comment></comment><comment><USER5> This is interesting, will be following closely on how things pan out

</comment><comment><USER6> I really can't wait to filter whatever anti-ad spam Nevahold is going to start spewing allover the internet.

</comment><comment><USER7> I hate the name.</comment>


Ask HN: How to start an LLC on H1B - <AUTHOR>

I am a good programmer with a well paying programming job at a hot technology company on the west coast. Hailing from a 3rd world country with a master's degree from US, I work here on a H1B visa.
In near future, I want to start my own company. Currently, I want to write some mobile apps and sell them online. However, my employer is not very friendly with such policies and having side projects officially may hurt my chances of getting promoted at work.
To fix this I came with the following solution:
Start a LLC in US under a cousin's name(a homemaker and US citizen) and sell apps under that LLC's name. I will run the company under her name. Once I decide to go full time on the startup, I am planning to have an arrangement so that I can buy back the company for a nominal amount.
Is this a good approach? Also is this legal? Are there better approaches?
TIA.
PS: I hope people will understand the reason for posting this under a throwaway account. <comment><USER2> You really should be consulting with a good lawyer who specialises in this line. You will get a clear idea on what is legal and what is not. You also want to make sure the IRS is happy with whatever arrangements you come up with.

</comment><comment><USER3> Below are my ideas. Not a legal advice.

 _Is this a good approach?_

Depends.

 _Also is this legal?_

Probably not. To totally legally work for the LLC you need to apply for and get another H1B. Of course, it is not illegal if you get another H1B. Consult a lawyer and preferably set up an Inc, not an LLC.

 _Are there better approaches?_

I know this is far out and you may not want to do it, but if you are really determined to work on your own apps, you can always work from another country and still sell apps.</comment>


"Intel should be ashamed of itself" -- OLPC's Negroponte - <AUTHOR> http://news.bbc.co.uk/1/hi/technology/6675833.stm <comment><AUTHOR> Intel's Classmate has inferior technology with much higher cost, e.g. the screen, and the poor battery life, last time I looked. <http://www.gettysfamily.org/wordpress/?p=34></comment>


Fixing Habits That Leach Productivity - <AUTHOR> https://therevisionist.org/reviews/fixing-habits-that-leach-productivity/ <comment><USER2> Good stuff. One thing I find helps my productivity is to take time to exercise (run or lift weight on alternating days) in the middle of my workday. It's a nice break and tends to spark creativity.

<comment><AUTHOR> Absolutely! Exercise increases blood flow to the brain, and promotes neurogenesis too! Meaning that your brain can learn much more easily in the long run. I wrote a bit on neurogenesis here:

[https://therevisionist.org/bio-hacking/cognitive- function/#H...](https://therevisionist.org/bio-hacking/cognitive- function/#How_Neurogenesis_relates_to_Learning)</comment></comment>


Ask HN: Why don't Google or Apple make complete password Managers? - <AUTHOR> By complete password managers I mean ones that work across all their devices and are synced ~<i>in the cloud</i>~. It seems like they would get a big chance to lock more people into their platforms. <comment><USER2> I might be missing something, but I think Apple's iCloud KeyChain [1] does exactly what you're describing (for Apple devices only ofc).

[1] [https://support.apple.com/en-us/HT204085](https://support.apple.com/en- us/HT204085)

</comment><comment><USER3> OMG this whole situation infuriates me.

I've complained about this to Google's security folks, and basically the answer I got there was that they don't believe in password managers as a solution and would rather have FIDO/U2F become a thing.

Another part, I think, is that building a password manager is hard. I tried to build my own and quickly found that the problem of finding out which fields are username/password fields was not always easy. Some websites don't even mark password fields with type="password", so you end up with JavaScript ML systems and massive site-specific lists for guessing which fields are username/password fields, and it's a pretty big task to make it really work.

Also, if you've ever recommended a password manager to someone not very technical, pretty soon they forget their master password, and now can't access their passwords, and its' your fault.

Having said all that, Chrome's password manager has been getting better, and they do have an app auto-logic on Android, so maybe those will combine. But I don't think it's a good lock-in strategy for Google, because they don't have a holistic ecosystem - most people are not using Chromebooks - so there isn't really any lock in play for them. Same thing goes for Microsoft, and to some extent Apple, since Safari isn't overwhelmingly popular on OSX.

IMO what is really needed is a standard for this, rather than lock in, so that these companies can co-operate on this and stop trying to make this a marketing bullet point.

<comment><USER4> > I've complained about this to Google's security folks, and basically the > answer I got there was that they don't believe in password managers as a > solution and would rather have FIDO/U2F become a thing.

They have a point. We've had the technology for improving authentication for literally decades - that's effectively what a SIM does. We've had these secure modules in our smartphones forever. The technology is dirt cheap, ubiquitous, and with the advent of these wireless transports the user interface problem is solved. The infuriating thing for me is we still don't use it.

Google has succeeded in forcing the planet to move to https, so I guess they imagine they can do the same thing for authentication. If they succeed they will kill phishing. I wish them luck.

If it were possible to have a NFC WebAuthn implanted in the back of my hand and I could invisibly control the userHandle it handed out by invisibly twitching a muscle or something, I'd be falling over myself to get the surgery done.

</comment></comment><comment><USER5> This is exactly what iCloud Keychain does, _except_ (unless it's changed recently?) you can sync it peer to peer too, you don't have to store the contents in iCloud.

The only part it's "missing" is a 2FA TOTP generator, but apps like [https://cooperrs.de/otpauth.html](https://cooperrs.de/otpauth.html) work quite well in that regard so it's not a major pain point.

Safari + (iCloud) Keychain is IMO evidence that good password management can work client side - these "alternative" solutions like login links via email etc are basically catering to the shit experience of other browsers/platforms.

</comment><comment><USER6> Google would probabbly just prefer you sign in to all your services just using their account.

Thus you wouldn't need a password manager if everything was Google Identity Platform....

That aside chrome has a password manager. I'm not saying it is the perfect solution, but it is there.

<comment><USER7> You cannot sign in to your bank using your Google account.

<comment><USER6> Google probabbly wishes you would...

Other than a handful of cases that they're not focused on I'm thinking they're still focused on their identity platform.

</comment></comment></comment><comment><USER8> On macOS: Safari app -> Preferences (Cmd-,) -> Passwords

Alternatively: /Applications/Utilities/Keychain Access.app

On iOS: Settings app -> Passwords and accounts -> Touch ID/Face ID

</comment><comment><USER9> probably because then they would be liable for when someone hacks your shit and then uses it to login to your bank and steal all your stuff

<comment><USER10> > probably because then they would be liable for when someone hacks your shit > and then uses it to login to your bank and steal all your stuff

Which law specifically would make Apple liable if your iCloud keychain was hacked and the credentials used?</comment></comment>


What do you think of the html title of this site? - <AUTHOR> http://www.getader.com <comment><USER2>
        <title>Ader | Influencer Marketing for Twitch</title>

Am I supposed to see something unusual here?

<comment><AUTHOR> mine keeps changing via JS to "You have (1) message" like it's flashing over and over

</comment></comment><comment><AUTHOR> never seen that before, creative!</comment>


Mysterious shackled skeletons found in ancient Greek mass grave - <AUTHOR> http://www.cbc.ca/news/technology/shackled-skeletons-ancient-greece-1.3703346 <comment><USER2> >> a large ancient cemetery unearthed during the construction of a national opera house and library between downtown Athens and the port of Piraeus.

Typical. In most of Greece one cannot dig to plant a turnip without striking some relic of the ancient times.

It's not a joke. A friend's father who is a civil engineer has told me how the law requires anyone who digs for a house's foundations to report any archeological discovery to the authorities. Then all building work must cease until the archeologists come in, do what the do best, and finally give the OK.

Unfortunately this may take a very, very long time (20 years in one case known to my friend's father). This is because of the impossible bureaucracy in Greece, but also because there is very little money to carry out the necessary work.

As a result it is ...common that when something like this happens the person who has the house built will pay the builders something extra to cover up the finds and keep hush-hush about it.

I don't even want to think what treasures may be hidden under condos and summer houses.

<comment><USER3> Yep, this is true. It's also one of the reasons why the subway in Athens was delayed, as they kept finding ancient artifacts. Thessaloniki has one of the main roads of the city half-closed because they found an ancient street running below it when they tried to dig for the subway.

You can see it under the road, open and everything. I'll try to find a photo.

It sounds terrible that people would mess with artifacts like that (moving them out of their property), but what can you do when your perfectly good plot of land just turned into a decades-long liability because there's some ancient stuff under it? It's not like archeology is the best funded of fields, either, so archeologists don't have the resources to be quick about taking the artifacts.

<comment><USER4> A common thing in Europe in general. My home city, Kraków, Poland, had its market square renovation put on halt for almost a year when the initial works uncovered things of interest to archeologists.

<comment> semi-extrinsic This. I would go so far as to say anywhere outside the US and Australia (where the cities have only existed for less than 3-400 years). But European countries probably have stricter norms and laws for preserving old artifacts than Asian and African countries (Maslow's pyramid etc. etc.).

<comment><USER5> As it happens, the construction of Sydney's shiny new light rail was almost halted because they found a bunch of Aboriginal artefacts under the route: [http://www.smh.com.au/nsw/call-to-halt-sydney-light-rail- aft...](http://www.smh.com.au/nsw/call-to-halt-sydney-light-rail-after- massive-indigenous-artefact-find-20160329-gnsxr4.html)

</comment></comment></comment></comment></comment><comment><USER6> " _" Perhaps with the DNA tests that we will do on these skeletons we may confirm or not this hypothesis that these deceased, these young people could be ... part of a coup ... an attempt by a noble to take power by force," said Chryssoulaki._"

I would _really_ like to know the details of how _DNA_ tests could determine that.

<comment><USER7> If they were all siblings (or related parents and progeny), it could be eliminating a family.

</comment></comment><comment><USER7> Makes me wonder if it will ever be a fashion statement to have a titanium plate attached to some easily accessible bone which has a detailed history of your life to that point on it. Figuring you'll get buried, time will pass, and at some point someone will dig you up again and perhaps would have the technology to read such data.

<comment><USER8> >>... and perhaps would have the technology to read such data.

Eyeballs? Do it in a couple different languages and your hip might be the next Rosetta stone.

There was a 70s movie, and I assume a novel, about a spy with amnesia who had a swiss account number engraved onto such a plate. But I cannot seem to google it atm.

<comment><USER9> >>There was a 70s movie... Are you talking about the Bourne Identity TV movie from the 80s? He washed up on shore and there was microfilm with the swiss account number in his leg or something

<comment><USER8> No, it was an older movie. I think it started at a swiss hospital, the number being visible via x-ray.

Bourne takes from so many spy stories that i doubt it possible to mention one without seeing it somehow mirrored in Bourne.

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

For below (as I've hit the 3posts/hour limit) maybe I was thinking of bourne, but only if he had a plate with the number on a bone. The thing I remember was that the number only became apparent at the hospital during an x-ray, after the accident that caused the amnesia.

<comment><USER10> The book is from 1980 ([https://en.wikipedia.org/wiki/The_Bourne_Identity_(novel)](https://en.wikipedia.org/wiki/The_Bourne_Identity_\(novel\))), and there was a film in 1988: [https://en.wikipedia.org/wiki/The_Bourne_Identity_(1988_film...](https://en.wikipedia.org/wiki/The_Bourne_Identity_\(1988_film\))

Are you sure it wasn't that one?

</comment></comment><comment><USER8> OP skips the most important detail: the shackles. We today do not appreciate the effort needed to manufacture metal goods. Prisoners would never be buried with such valuable objects. That fact alone tells me that this wasn't an execution. This was human sacrifice. That's why the archaeologists are so shy.

<comment><USER11> Why would sacrifices be any more likely than executees to be buried with shackles still on?

<comment><USER12> Because sacrifices have intrinsic value (spiritual value). The shackles can be explained as part of the ritual.

Prisoners are just worthless people that you want to get rid of. Not only would the shackles get removed before burial; so would their shoes etc. They would be stripped and dumped.

<comment><USER13> Executions also have symbolic value and all sorts of people have been buried with metal who were not human sacrifices.

> Prisoners are just worthless people that you want to get rid of.

That's not always true. Sometimes prisoners are important people you want to set an example of. These aren't the first ancient skeletons with iron shackles archeologists have found and the other ones (China, Rome, etc.) certainly aren't all human sacrifices.

</comment></comment></comment></comment><comment><USER14> Around that time Athens conquered many rival states. Aegina was similar to Athens in wealth and number of ships, when it was conquered. Its temple is greater (arguably) than Parthenon.

It was also common to take hostages (relatives from royal family and nobles) from conquered states. Those were executed if conquered state rebelled.

</comment><comment><USER15> Ancient Greece is full of interesting stories that rival Byzantine machinations.

For example, Megacles, who was _archon eponymous_ during the attempt coup, lead the reprisals that killed Cylon's supporters, after promising them safe passage from the temple to stand trial. For this action, Megacles and the Alcmaeonids (his noble family) were exiled from Athens for some time. (Later on they returned to Athenian politics)

Perhaps the most interesting character from the Alcmaeonids was a fellow named Alcibiades, who lived during the Peloponnesian War, which was mainly between Athens and Sparta. (This is after the Persian wars, the events fancifully depicted in the movie _300_ ) Coming from a rich family, he had an aristocratic upbringing, counting Socrates among his teachers; Pericles also helped raise him after his father was killed in battle.

Perhaps the best way to describe him is as a blend of JFK's womanzing, Bill Clinton's charm and Donald Trump's flamboyance. (He supposedly had a lisp, but curiously, this made him even more charming, but his "lisp" turned "R" into "L"[0])

He became popular in Athens but obviously made some powerful enemies along the way, and was forced to flee/defect to their rival city, Sparta, after being accused of desecrating religious statues of Hermes in the city. (Could you imagine if a prominent politician was accused of vandalizing churches or destroying flags hung from people's houses after a night of drinking? Such was the supposed outrage in Athens after this act.)

After some time in Sparta, he was accused of having an affair with the Spartan King's wife and fled again, this time to Persia.

He eventually made it back to Athens, after some negotiations where he promised that he could bring Persian support to Athens in their continuing war against Sparta and her allies. (This support didn't materialize) Nevertheless, he was given a military command and did manage to secure some victories for Athens, but after one particular defeat, his enemies in Athens took this opportunity to get him removed from command. After that, he went into self- imposed exile, and not too long afterward, was assassinated, probably by Sparta.

Some other interesting words with roots in Ancient Greek politics:

\- Anarchy: Athens was ruled by several _Archons_ , who were leaders each with specific duties. So the word "anarchy" means something like "an absence of leadership".

\- Ostracism: Once a year, Athenians would be given the chance to exile someone. If they decided on this, they took a vote, by writing the name of the person they wanted to exile. The names were written on discarded pieces of broken pottery known as _ostraka_ or _ostrakon_ in the singular. After successful vote, the person was exiled for 10 years; attempting to return before this carried the death penalty. Interestingly, after the 10 years there seems to have been no residual sanction against the individual, and furthermore their property was returned to them.

0\. [http://penelope.uchicago.edu/Thayer/E/Roman/Texts/Plutarch/L...](http://penelope.uchicago.edu/Thayer/E/Roman/Texts/Plutarch/Lives/Alcibiades*.html)

</comment><comment><USER16> Maybe Plato's Cave was more than a thought experiment...</comment>


What Can Android Learn From Symbian's Security Model? - <AUTHOR> http://shkspr.mobi/blog/2013/04/what-can-android-learn-from-symbians-security-model/ <comment><USER2> I've not used android too extensively, but this was a very surprising "feature" I noticed in their OS. Extremely overblown permission settings made me uninstall several apps from my friends phone. :)</comment>


Ask HN: who has the highest lifetime earnings at age 40, Doctor Lawyer Engineer? - <AUTHOR> <comment><USER2> Having acquaintances and friends among all three, and being one of the three myself, it varies a lot, based on any number of factors (what type of each, government/private, exactly how long you've been working, country, specialisation, salary structure, etc).

Best guess based on anecdata, however, suggests doctor, even factoring in length of studies, community service/internship, etc - they really start ramping up quickly once you're all qualified, and especially if you keep on advancing your career.

</comment><comment><USER3> "Let's go and eat grandma." Commas save lives.

<comment><USER2> True, but good comprehension requires half a word ;-)

</comment></comment><comment><USER4> Investment Banker</comment>


Google could compete head-on with Verizon, AT&T  - <AUTHOR> http://money.cnn.com/2010/12/30/technology/google_wireless_carrier/index.htm <comment><USER2> This article is idiotic. Android and Google Voice won't work without a telco provider like Verizon and AT&T. The article says nothing about Google building cell towers, so I don't understand the premise.</comment>


From STUPID to SOLID Code! - <AUTHOR> http://williamdurand.fr/2013/07/30/from-stupid-to-solid-code/ <comment><USER2> A lot of people love to try and make a case for Singletons. I have yet to see anyone make a really, truly good case for a pure software singleton. They just make it an absolute nightmare to be well informed -- as a developer -- about state in complex/concurrent/distributed systems.

The only time I ever use them is when my hands are tied by some sort of hardware restriction; a JNI wrapper around some native lib that talks to proprietary hardware like a motor controller where instantiation of more than one comms object would blow out a fuse or something. And even then, I'd make the argument that the people who designed the hardware and its corresponding C API should have just made a safer interface instead of saying "Don't call `new` more than once, or else!". Seems lazy and less-than-appropriately fault tolerant.

<comment><USER3> I know what you are saying, and agree. But consider: I have state that I truly need to be global - something I read from an INI file, the command line, or internally calculated, it doesn't much matter. Is not the alternative to a singleton having that state replicated all over the place? And then you introduce model/view/ signals, have to deal perhaps with race conditions, and so on. Then, just try to grep for the existence of that state in your code.

Like anything, it's a tradeoff. Let's say I have an app with 10 OpenGL windows, and I want to simultaneously control the lighting model for all at once. A singleton gives me an easy way to do that, but then the windows have to poll in some manner (which is perhaps not an issue, since they are in a render loop anyway). But I am brittle - introduce the requirement that each window handles light differently and the singleton is toast. OTOH, introducing a signal/slot or model/view architecture may be overkill for what I am doing. This might be a small corner of the code, and I just want clarity for the few times I go in to read it. I find it extraordinarily hard to understand messaging code - where did this message come from, what was the state of that object that caused it to fire the message, and so on. I think complexity goes up at least by 1 order of magnitude when you have to maintain state and time in your mind to understand a program.

Perhaps not the best example; so consider command line arguments. It's read only, set once, but perhaps needed to be accessed by many different parts of my code. A singleton or 5 seems pretty darn clean to me. Again, not without it's tradeoffs, but the alternatives, to me, seem worse. You can pass, pass, pass, the data through methods and constructors until it gets to the code that needs the info - in which case you have infected a lot of code with rather superfluous (to them) knowledge about command line settings. That's brittle, and you end up touching a lot of code when you add something to the command line. You can do a signal/slot or model/view, which can be quite powerful, but you may be forced into a specific design by your sw stack (they have a model/view architecture which you are using for GUI or something). So your code is brittle by being coded to a specific API, and again, it rather obscures where this data comes from. Plus, this forces the command line reading code to know all about your specific API, how to format the signal, when to send it (command line reading is often done well before the whole stack is started up and going, so you can't send a signal yet). That's very brittle as well. Can you take that code, put it in a test harness, and trivially write tests for it? Probably not.

Maybe I am missing some obvious technique. But a _few_ things in an app are in fact global. Trying to obscure that fact, to my mind, just makes the sw more brittle and a lot harder to understand and debug. Which is not in any way an argument for making non-global things global for convenience.

<comment><USER4> > But a few things in an app are in fact global.

Sure, but for the most part, there is no reason for the components of the app to _depend_ on those things being global (and a significant cost in brittleness for them to do so), so, in general, they should be passed to the objects that need them, even if they are globally consistent throughout the app.

Obviously, there are optimization reasons why you might need to avoid doing this in particular cases, but in general doing so up-front is going to be a premature optimization.

<comment><USER5> "...there is no reason for the components of the app to depend on those things being global..."

BINGO! This is the anti-pattern part. Not that the data is globally required, but that your units are mutually dependable. This is why Interfaces and Dependency Injection are so popular now, because they facilitate the ability to make easily testable, singular units that allow for mocks / stubs etc.

To illustrate, what happens if your global requirement happens to also be external? Would you want to have to test your component with a live version of your global and external resource? No, you would want the ability to test (either as a single unit, or even the whole app), without requiring the database, messaging, web service, etc, to be up.

</comment></comment></comment></comment><comment><USER6> I have been questioning the "programming languages are for humans, use full names" principle recently. Why do we have a tendency, as humans, to create abbreviations so often then? Mathematicians get upset if an operation uses more then a single character or symbol to express it, and are willing to have massive amounts of overloading to achieve it.

<comment><USER4> > Mathematicians get upset if an operation uses more then a single character > or symbol to express it, and are willing to have massive amounts of > overloading to achieve it.

Because context-switching and then processing concise symbols in that context is more efficient for most people's brains that processing prose.

<comment><USER6> So why would it be any different in programming?

</comment></comment></comment><comment><USER7> Anthony Ferrara did a similar presentation a while back: [http://blog.ircmaxell.com/2012/05/dont-be-stupid-grasp- solid...](http://blog.ircmaxell.com/2012/05/dont-be-stupid-grasp-solid- slides.html)

<comment><AUTHOR> Yes, I linked his presentation in the introduction :)

</comment></comment><comment><USER8> _Always_ avoid singletons? Here's my situation: in various parts of my code I need to get the current time. Normally I would call System.currentTimeMillis() but in my test cases I need to ensure the time is a particular value. So I have a Clock singleton class which allows me to get the current time but also to 'stop the clock'.

Is it really better for me to pass the Clock instance all over the place, rather than have a singleton instance that can be referenced anywhere?

<comment><USER9> If you really want to modify global state while running a test, then you might as well use a dependency injection container and get similar behaviour, entirely generalized.

You can then have two much simpler clock classes, one for real time and one for fake time.

Personally, I prefer just passing around the clock, though - it makes dependencies between classes crystal clear.

<comment><USER10> You get the added benefit of not relying on global state. Which you have to do anyway if you want to parallelize your test suite execution.

</comment></comment></comment><comment><USER9> I've always felt that the SOLID rules are very difficult to comprehend, yet pretty basic to apply. A junior dev that I recently coached, who had grown up on modern OO languages (Python, C#, etc), understood all these rules in his underbelly but would never be able to explain them.

I believe that we should be able to come up with a set of (slightly different) rules that are simpler to explain and yield the same good designs.

<comment><AUTHOR> I think that it is a matter of vocabulary, no? Reading the LSP definition in Liskov's paper is quite hard to understand, but with simpler words, it is more understandable.

</comment></comment><comment> luiz-pv9 About the square/rectangle example, what would be the solution? The Square subclass should not verify equality with width and height or it should not even exist? Or something else?

\-- edit Wikipedia: If Square and Rectangle had only getter methods (i.e., they were immutable objects), then no violation of LSP could occur.

<comment><USER4> > If Square and Rectangle had only getter methods (i.e., they were immutable > objects), then no violation of LSP could occur.

Yeah, this is the fundamental problem; _mutable_ objects tend to result in LSP violations when class heirarchies follow common sense is-a relationships, but mutating operations are not limited to those (if any exist) that preserve identity.

A corollary to this is that the use of default constructors very often accompanies LSP violations, as it usually implies _all_ of the object's state is subject to mutating operations.

</comment></comment><comment><USER11> I tend to perceive tight coupling as a virtue rather than as a symptom of stupidity. On the other hand, indescriptive naming is a real, and severe, problem in my code.

Also, both these acronyms seem to lean toward the object-oriented paradigm. I'd like to see something more universal.

</comment><comment><USER12> 'Dependency Inversion' _increases_ coupling. More and more I'm inclined to consider 'Dependency Inversion' an Anti-Pattern.

<comment><USER4> > 'Dependency Inversion' _increases_ coupling.

This is an interesting claim. Could you explain further _how_ this is the case (or provide references which explain it?)

</comment></comment><comment><USER13> Someone needs to fix the font on that website. Ultra thin font on white background and not rendering properly – highly, unreadable!

<comment><AUTHOR> Oh I am really sorry. Could you give me more details (OS, browser) so that I can fix the font?

<comment><USER13> chrome on os x

[http://cl.ly/image/2H4115120p0t](http://cl.ly/image/2H4115120p0t)</comment></comment></comment>


Zero Knowledge Proofs: An illustrated primer - <AUTHOR> http://blog.cryptographyengineering.com/2014/11/zero-knowledge-proofs-illustrated-primer.html <comment><USER2> One of the things that I've been frustrated by existing ZKP primers while educating new Bitcoin engineers on the tools in this space is that they don't form any intuition as to how the you can prove something other than some very narrow (usually seemingly toy-like) problem.

Even if the problem is NP-complete, the transformation from something you'd actually like to to be able to prove to graph colouring or SAT or cycles, is not obvious.

So, I described a novel ZKP for boolean circuits as a teaching tool:

[https://people.xiph.org/~greg/simple_verifyable_execution.tx...](https://people.xiph.org/~greg/simple_verifyable_execution.txt)

It's explicitly not very efficient (since I eschewed all tools from asymmetric cryptography which could have been used to make it efficient), and it may well be not very secure (it's not peer reviewed), but the people I've shown it to have found it to be pretty useful in terms of expanding their perspective and giving them some intuitive confidence that a zero-knowledge proof of the output of an arbitrary program on secret inputs is possible.

Some people here may find it interesting for the same reasons.

</comment><comment><USER3> Can someone help clarify a point about the zero-knowledge part for me?

As far as I can tell calculation is performed (which I would argue is equivalent to knowledge being created) in the process of first checking the value and then rewinding the program to a previous state. Consider the following program (pseudocode):

        start: int value = rand(10) //take a random number between one and 10
        if (value == 2) {return "success"} //here we are checking if our "answer" is correct
        else {goto: start} //rewinding time and trying again

I would argue that this program calculates the number two, and is functionally equivalent to checking a value and is identical to the scheme outlined in this article. Isn't a calculation a creation of information?

If the program was changed so that the if block had (value == 2 `times` 2) I would argue that the program had calculated 2 times 2 (albeit in a stupid way) and thus information had been created.

Can someone point out the flaws in my reasoning? (Obviously there are some, I'm just being too obtuse to see them at the moment)

(EDITS: code syntax and unable to use asterisk as times in the comment so put `times` in instead, hope it's clear

EDIT #2: just realised I said "information is created" which is obviously incorrect as information is conserved. I still think calculation is being performed. I would argue it is the same as performing a random search on the search space. so the information is provided when we check the value

EDIT #3: expanding upon the previous point, assuming we control the time (which we model as the scientist going back in time in the given example) surely in the Verifiers timeline it seems that there is no computation occuring, but in the scientists timeline (assuming the scientist must go back in time and set pick a new set of random colorings) computation is occuring and thus we break our tenet. )

<comment><USER4> > and is identical to the scheme outlined in this article

Would you care to elaborate?

In your example, the Verifier (line 2) already has a solution to the problem (the number 2). Therefore the Solver (line 1) can't possibly give more information about the _solution_.

In the article's example (graph colouring), the Verifier doesn't know the solution to the problem and just verifies a small part of the solution provided by the Solver (2 vertex each time). The Solver doesn't leak any information about its solution at each iteration since the colours are randomised each time.

> I still think calculation is being performed

Yes, but this is the whole point of ZKPs. It's called Zero Knowledge, not Zero Computation.

> I would argue it is the same as performing a random search on the search > space

I agree but the fatal flaw in your reasoning is that the Verifier already knows the solution and therefore doesn't learn "new" information. The Solver is just wasting CPU cycles.

Disclaimer: I just read the article and have no prior knowledge of ZKPs. This is just my basic understanding.

</comment></comment><comment><USER5> In his example Google could colour each vertex a completely different colour. That way when you revealed any random two it would always look like that had done it correctly. I suppose to get round this you have Google tell you which three colours they are using in advance.

<comment><USER6> This is a good time to point out that the solution to GOOG rainbow color cheating isn't to reveal 4 instead of 2 and make sure only 3 colors are seen, because then GOOG wouldn't have to get paid because you'd end up with a long enough list of known pairs to not need their services, because each trial run would leak exactly one pair (assuming a trial didn't indicate GOOG cheating, obviously). This is also why GOOG has to shuffle between each and every sample.

Its interesting to think about acceptable losses in zero knowledge... If the GOOG had the computing power to solve a problem 1000x bigger than you can solve, they can leak down to only maybe 10x and it'll still economically make sense for you to play fair and pay them.

Another fun mental exercise is to analyze the info leakage rate and truth belief rate of allowing GOOG to falsify 1%, 1/3, 1/2 of all colors.

<comment><USER7> Actually, it's not necessary to build a list of known pairs that you eventually link into a solution; if a challenge reveals at least three vertices you can identify each vertex unambiguously one by one. (That's because there are only three colors, so as long as you include the same two vertices v1, v2 in every challenge, you can classify every vertex into [color of v1], [color of v2], or [color 3] as soon as you see it.) A list of pairs only becomes necessary when there are more than three colors allowed.

</comment></comment></comment><comment><USER8> Related, from two months ago

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

</comment><comment><USER9> In the example, the vertices colors for a graph edge are requested, but how can one trust that those colors aren't being generated on-the-fly? Effectively, how can I trust that the "warehouse" isn't cheating me?

<comment><USER10> The OP glosses over this a bit, but it's mentioned in the footnotes: the "hats" represent a commitment scheme, which is a way for the prover commit to a specific color assignment, before revealing what that assignment actually is.

When the verifying party chooses the two vertices he wants to see, the prover can reveal only those two, and the verifier actually has two things to check:

1) the colors revealed are actually two different colors (otherwise the purported solution obviously isn't correct)

2) the colors revealed are consistent with the prover's overall commitment. (in other words, that the prover didn't change his answer "on-the-fly")

</comment></comment><comment><USER11> > In the next post I'll talk about some of those ...[snip]... I'll also talk > about why I dislike SRP so much.

I'm going to guess this is going to be:

* Rocky development process (~6 versions, removing attack vectors with each release). This however isn't exclusive to SRP: EKE flavours have also suffered from problems[0]

* Outdated constructs (e.g. the RFC for TLS-SRP still recommends using salted SHA1 for password hashing, so realistically still relies upon strong database security. Fortunately, this is under client control regardless of what the document actually says)

* Lack of a formal security proof (although it's generalised and dealt with in quite a few papers alongside other protocols).

* Perhaps the lack of an EC formation, although I believe you can build one with a few modifications. (Yongge Wang drafted one in 2001[5] that looks to me, as an amateur, to be sound. The critical modification is no more crazy than the freaky ECDSA construct we rely upon today, afaict, simply because more elegant Schnorr constructs were covered by patents)

I'm not sure why Matt considers the protocol to be complex[1] or crazy[2]. It seems to be a pretty straightforward DH protocol, with a couple of interesting parameters: a commitment by each party to the password verifier, each closing off a different attack (one where a client could otherwise auth knowing just the verifier but not the password, and the other to prevent an impersonating server from gleaning enough to do an offline dictionary attack) There are a lot of subtleties in all off the PAKEy protocols I've read about, not just SRP, one good example can be had here[3], which talks about the intricacies of picking commitment constructs.

Atm I agree with Bram Cohens sentiment on this one[4]. If not SRP, then _something_. I'm looking forward to Matts thoughts in the follow-up. Perhaps he has a more modern starting point in mind[6]

I'd like to see the prevalence of full-on PGP-esque signing and HSMs in every device, but we can't continue to do nothing with passwords. The two uses of password authentication that everyday people rely on the most: password authentication on the web, and WPA2-PSK, are both _terrible_ compared to the PAKEs we already have. Worse, the lack of better things is spawning absolute garbage like third-party login.

I like SRP. While I'm not as familiar with more current IETF RFCs, like Dragonfly[7] and Pwd[8], I believe from cursory looks that they fail to fall in to the "augmented" PAKE category, which means if a server is compromised the infiltrator can use the knowledge they've gained from the database immediately, and without any further work.

[0] [http://www.jablon.org/jab97.pdf](http://www.jablon.org/jab97.pdf)

[1] [https://twitter.com/matthew_d_green/status/28874317682562252...](https://twitter.com/matthew_d_green/status/288743176825622529)

[2] [https://twitter.com/matthew_d_green/status/28874165135724544...](https://twitter.com/matthew_d_green/status/288741651357245440)

[3] [http://coitweb.uncc.edu/~yonwang/papers/TCSsrp5.pdf](http://coitweb.uncc.edu/~yonwang/papers/TCSsrp5.pdf)

[4] [https://twitter.com/bramcohen/status/330423520062476288](https://twitter.com/bramcohen/status/330423520062476288)

[5] [http://grouper.ieee.org/groups/1363/passwdPK/submissions/p13...](http://grouper.ieee.org/groups/1363/passwdPK/submissions/p1363ecsrp.pdf)

[6] [https://twitter.com/matthew_d_green/status/34483169358632140...](https://twitter.com/matthew_d_green/status/344831693586321409)

[7] [https://datatracker.ietf.org/doc/draft-irtf-cfrg- dragonfly/?...](https://datatracker.ietf.org/doc/draft-irtf-cfrg- dragonfly/?include_text=1)

[8] [https://tools.ietf.org/html/draft-harkins-tls- pwd-03](https://tools.ietf.org/html/draft-harkins-tls-pwd-03)

<comment><USER2> > using salted SHA1 for password hashing

Anything else would be better there.

But right now there is a huge multiplicity of trendy password strengthening functions (see also: [https://password-hashing.net/](https://password- hashing.net/)). I'd worry that doing something better than sha1 might still not be great because of a lack of clarity of choices there.

E.g. Some of the most popular (e.g. scrypt) are potentially ill-advised for some fairly overt reasons, like data-dependent timing that potentially leaks information about your password (in what should other wise be a ZKP thats potentially pretty bad!), or potentially problematic in subtle ways. (E.g. is memory hardness really desirable? the cost analysis ignore operating costs. But for compute bound silicon on 28nm built in quantity, power costs more than die area after only a couple months of operation. Requiring lots of upfront costs in gate area means that attackers can amortize their costs over many attacks. Meanwhile, most of the user's computer is siting idle and not contributing to expanding the amount of work an attacker must do.

> * Perhaps the lack of an EC formation,

Yea, well ... SRP sends a fair amount of data and isn't terribly fast for reasonably secure parameters. If someone is unconvinced about the value of this crypto-security-whatever having them send kilobytes of data over the regular password they were going to send may be the straw the breaks the camels back.

Also, if your cryptographic stack is otherwise all ECC having to have a separate bignum implementation for SRP wouldn't be very welcome. But OTOH, the latest in trend curve design uses curves with non-prime order, and at least some of the PAKE schemes I've seen lose their ZK property when there is a cofactor. Bleh.

<comment><USER11> > Anything else would be better there.

Yeah, I can't fathom how that spec got drafted with SHA1. I guess as network guys they just didn't care too much about verifier storage, which is insane, because it's clearly the weakest point of any password based scheme where boxes are, in all practicality, going to be off-the-shelf hardware sat on the open Internet. I think the other proposals like Dragonfly and TLS-PWD repeat this mistake also except, not being "augmented", they're even worse.

> right now there is a huge multiplicity of trendy password strengthening > functions

How's that going? Is there anything amongst the PHC candidates looking like it'll 'win'? It's gone very silent.

> Some of the most popular (e.g. scrypt) are potentially ill-advised for some > fairly overt reasons, like data-dependent timing that potentially leaks > information about your password

Afaict this probably isn't _too_ much of a problem for a client-server PAKE? The password is only hashed on the client/users, probably somewhat noisy and unique, machine. You're already talking about pretty sophisticated and targeted attack that's hard to pull off on a repeated basis. I know that's not a "sound" crypto argument, but you can't easily make a user enter their password 10,000 times for example. The server will probably need to apply a regular hash the password _verifier_ for commitment purposes, but it's typically mixed in with session nonces, and already hardened, so couldn't be any worse than a db dump from SQL injection even if successful. I personally don't see a hole that doesn't exist with current server-side hashing practices. Thoughts?

> some of the PAKE schemes I've seen lose their ZK property when there is a > cofactor

Hmm, interesting. Any information on this?

<comment><USER2> > Yeah, I can't fathom how that spec got drafted with SHA1.

I'm not sure, PBKDF2 existed then... though computationally expensive KDFs for passwords have become more popular over time. And grinding the server for SRP isn't totally cheap.

> How's that going? Is there anything amongst the PHC candidates looking like > it'll 'win'? It's gone very silent.

Been pretty silent from what I've seen but the schedule gave a fair amount of time for review... though I'm not sure how much review various proposals are getting, since this is a domain with basically infinite shed-painting potential (as my own comments here go!), makes it almost feel pointless to review.

> Afaict this probably isn't too much of a problem for a client-server PAKE?

I'm not sure. It would be an unfortunate result if you sought out to make it more secure, and maybe its less secure. (E.g. server database never leaks, but lots of opportunities for timing attacks show up)

> The password is only hashed on the client/users, probably somewhat noisy and > unique, machine. You're already talking about pretty sophisticated and > targeted attack that's hard to pull off on a repeated basis. I know that's > not a "sound" crypto argument, but you can't easily make a user enter their > password 10,000 times for example.

10,000 probably isn't needed though, since extracting a few bits may let you reasonably grind out the rest against the server only; if you make pessimal (read: reasonable) assumptions about how much entropy users actually have in their passwords.

Consider an attack where the attacker code is running in the background (say in another browser tab/nacl) performing cache timing while the user logs it. It's a sophisticated attack, but it could potentially extract quite a few bits. It may be a somewhat complex attack, but a simple conventional hash PKKDF2 would be invulnerable to it.

Yea, I don't see any concern on the server. Server's commitment shouldn't be using an intentionally expensive hash, and normal cryptographic hashes in wide use are constant time.

> Hmm, interesting. Any information on this?

Will look when awake. But the result was something like checking which subgroup a point was in leaking log2(cofactor) bits about the secret. The normal way of avoiding this by multiplying all your values by the cofactor isn't readily available when you're doing some ugly trick of constructing points with no known discrete log from a hash.

<comment><USER11> > the result was something like checking which subgroup a point was in leaking > log2(cofactor) bits about the secret. The normal way of avoiding this by > multiplying all your values by the cofactor isn't readily available when > you're doing some ugly trick of constructing points with no known discrete > log from a hash.

Ah, a partition attack. Could you fix this with more ugly by just iterating the hashing/munging process until your commitment was in a predetermined subgroup? I'm not at all familiar with EC subgroup theory, but the EC-SRP scheme proposed already does some deterministic munging to select the y-coordinate. Of course, even if you can do this, you're open to another timing side-channel.

<comment><USER12> I don't see what the problem is, exactly. If you have a secure hash function taking some string into a point of elliptic curve E, multiplying said point by the cofactor is also a secure hash function into the relevant subgroup of E. See §6.1 of [1].

[1] [https://eprint.iacr.org/2009/340](https://eprint.iacr.org/2009/340)

<comment><USER11> Neat. It's also pointed out in Icarts paper[0] that the naive 'try and increment' algorithm, which I believe is utilised in Yongge Wangs draft EC-SRP proposal I linked up above, is vulnerable to timing attacks. Oops

Interestingly, both Dragonfly and TLS-SRP describe a 'Hunting and Pecking' algorithm to paper over this problem. Perhaps Icarts solution would be more elegant

[0] [https://www.iacr.org/archive/crypto2009/56770300/56770300.pd...](https://www.iacr.org/archive/crypto2009/56770300/56770300.pdf)

<comment><USER12> Hunting-and-pecking is essentially the same algorithm as try-and-increment, where instead of incrementing an x-coordinate on failure one picks another x (pseudo-)randomly. Therefore both are susceptible to the same kind of timing attacks. Dragonfly went to some pains to try to make the process side-channel- free, but it looks ugly as sin, and it's still unclear whether it is actually secure (cf [1]).

[1] [https://www.ietf.org/mail- archive/web/cfrg/current/msg03537....](https://www.ietf.org/mail- archive/web/cfrg/current/msg03537.html)

<comment><USER11> Thanks for that. The tone of Dan Harkins reply is fun. There's clearly a lot of ego in crypto ;) Not sure I see the point in balanced PAKE myself. If you turn weak passwords in to preshared keys then why not just use strong preshared keys to begin with and trust in the bits? Worrying about parameter binding to the verifier seems irrelevant to EC as well.

<comment><USER12> I'm probably not the best person to argue in favor of one flavor or another of PAKE, but balanced schemes give you forward security whereas a naive preshared-key scheme does not.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> I don't quite follow this description:

> Ultimately what we get is the following theorem. If there exists any > Verifier computer program that successfully extracts information by > interactively running this protocol with some Prover, then we can simply use > the rewinding trick on that program to commit to a random solution, then > 'trick' the Verifier by rewinding its execution whenever we can't answer its > challenge correctly. The same logic holds as we gave above: if such a > Verifier succeeds in extracting information after running the real protocol, > then it should be able to extract the same amount of information from the > simulated, rewinding-based protocol. But since there's no information going > into the simulated protocol, there's no information to extract. Thus the > information the Verifier can extract must always be zero.

This seems to identify a way of showing that some protocol is zero-knowledge. But, as I read the paragraph, the requirements aren't strict enough.

Imagine a closely-related protocol, where I get to challenge two edges at once and the four (or three, I guess) incident vertices are revealed. Obviously, I can successfully extract the full 3-coloring through repeated runs of this protocol (revealing four vertices when there are only three legal colors means I can identify which vertices are the same color as which other vertices; given a bounded number of challenges, I can get them all). Also obviously, you can use a time machine to pass any particular challenge in this protocol almost as easily as you can use one to pass the less leaky one-edge challenges.

But I don't see what's making the difference, or how the "theorem" helps me distinguish the protocols. The OP identifies three properties that a zero- knowledge protocol must have: 1, if the prover has a solution, I become confident that it's real; 2, if the prover doesn't have a solution, I become confident that they don't; and 3, zero-knowledgeness.

So, if I'm an honest verifier with no memory (except for previous challenge pass/fail results), the two-edge challenge protocol has the first two properties, just like the one-edge protocol: I'll quickly gain confidence that a genuine solution is real, and I'll quickly discover that a sham solution is false. If there's a time machine involved, I'll quickly become convinced that the prover has a solution even though they don't, because it's easy to fake three or four vertices being properly colored.

If I'm a nefarious verifier with a memory, I can use the extra information that leaks from the two-edge protocol to recover the full solution if one is given, and I can also use it to eventually discover that a nefarious prover is using a time machine to lie to me (when my own illicit copy of the graph- coloring hits a contradiction). The two-edge protocol doesn't fail the completeness or soundness tests. So it must fail the zero-knowledgeness test. How can I tell that? Does the paragraph I quoted indicate _how_ the two-edge protocol fails zero-knowledgeness?

<comment><USER4> I agree, the quoted paragraph is not clear. It seems to me that the Verifier could not be tricked even using the rewinding trick if it was allowed to use its memory (internal copy of the graph-coloring).

<comment><USER7> Well, in the protocol described in the OP, the verifier can't build an internal copy of the graph-coloring, because knowing that two adjacent vertices in the graph are two different colors doesn't help anything; that much is required of any solution. In the protocol I describe, the verifier can do that, because revealing more than two vertices simultaneously leaks information that isn't necessarily true of all possible solutions (at least, it can; if three vertices which connect in a triangle turn out to be three different colors, you haven't learned anything because any valid solution will have that property).

The problem I'm having is that I agree that the one-edge protocol is zero- knowledge (and that a verifier could be tricked indefinitely by a prover with a time machine), and obviously the two-edge protocol isn't zero-knowledge (and, in probably-related-but-I'm-not-sure news), a verifier using the two- edge protocol _cannot_ be tricked indefinitely by a time machine). I can tell that, but I tell it by looking within my soul and thinking "yes, there is no information leak when one edge is revealed, but there is a leak when two edges are revealed". That's not a reliable method; I'd like to know how to prove that information does not leak through a protocol, and I don't see that anywhere in the OP.

<comment><USER13> Roughly speaking, the question here is: can you simulate a multi-edge protocol. That is, can you achieve the following properties using rewinding:

1\. The 'fake Prover' simulating the protocol has no knowledge of an actual graph coloring. 2\. From the Verifier's PoV, the distribution of the simulated (rewinding-based & fake) protocol transcript is identical to that of a real protocol run where the Prover really does a solution. 3\. The simulation still requires only time polynomial in the problem instance (when you include all the rewinding trips).

I think if you follow this through you'll find that simulating a multi-edge protocol that 'looks like' a real transcript is highly challenging.

The reason for condition (3) is to rule out an obvious hack wherein the simulation takes so long that the 'fake Prover' can simply find solve the problem (e.g., by finding a graph coloring in an exponential number of time steps).

<comment><USER7> As I see it, if the transcript consists of a record like the following:

        Trial 1: PASS
        Trial 2: PASS
        Trial 3: PASS
        Trial 4: PASS

etc. etc, then simulating a two-edge protocol is, while more time-consuming than simulating a one-edge protocol, still pretty easy. If the record looks like

        Trial 1: PASS (v1 red -- v2 green, v3 green -- v4 blue)
        Trial 2: PASS (v1 blue -- v2 red, v7 blue -- v9 red)
        Trial 3: PASS (v1 green -- v2 red, v7 green -- v4 red)

then after Trial 3 you can tell that the prover is cheating. The fake trials seem to achieve your properties (1) and (3). I guess they violate #2? What is the "distribution" of a simulated transcript?</comment></comment></comment></comment></comment>


Roslyn Cemetery - <AUTHOR> https://www.atlasobscura.com/places/the-roslyn-cemetery <comment><USER2> Roslyn is also where a some of the tv show "Northern Exposure" was filmed. It's reasonable close to Seattle.</comment>


Ask HN: How to get Indian team member to North America for 3 months? - <AUTHOR> Although Outernet is based in Chicago, most of us work remotely. We're trying to get the whole team together for a 3-month sprint before we release our mobile satellite service. Unfortunately, Manish was turned down for a US B1/B2 visa. Mexico is not an option because it requires him to visit a consulate in another state.<p>Have any Indians had problems with a tourist visa for Canada? Any other ideas if Canada doesn't work out? <comment><USER2> Getting Canadian visa would become tricky if someone is turned down for a B1 / B2 visa, but it's worth a shot. He can also re-apply for a US visa.</comment>


Can Chrome Sync or Firefox Sync be trusted with sensitive data? - <AUTHOR> https://palant.de/2018/03/13/can-chrome-sync-or-firefox-sync-be-trusted-with-sensitive-data <comment><USER2> It sounds like the answer is 'no, unless you encrypt the data before you place it on one of those services.' Which almost defeats the reason for using the service.</comment>


The Solo JavaScript Developer Challenging Google and Facebook - <AUTHOR> https://www.wired.com/story/the-solo-javascript-developer-challenging-google-facebook/ <comment><USER2> I've been using vue just by adding the ref (no build tools) and I've been very happy with it. I'd like to see a good ClojureScript integration, then I'd go all in with a build step.

<comment><USER3> This is exactly how I was using it too. Then I tried to move to the build version and all sorts of stuff broke. This was more than two years ago, but that turned off to it. Nowadays I use svelte.

<comment><USER2> I actually use the build tools for the first time a few weeks ago and it was quite a pleasure as well. I believe there have been some major updates to the tooling recently. I did a lot of prototyping there so I could use ES6 and .vue files and coverted them to templtes and/or js strings by hand when things were more finalized. I don't mind reading and touching up templates/strings, but it not super fun to start from scratch.</comment></comment></comment>


ASK HK: Review my startup: I Worked On - <AUTHOR>

I would love some feedback on my website, I Worked On:
http://www.iworkedon.com
I Worked On is a cross between a portfolio site and LinkedIn.
I won't say anything else, as I'm interested to know what impression people get from landing on the site for the first time not knowing anything about it.
Thanks! <comment><USER2> Hello there,

First of all, the design is very clean. The homepage as a very nice greeting box and a basic news feed of the current project.

I enjoy the UI throughout the website. Again, very clean. Although, the black gradient footer is unnecessary. If you want a gradient, I would make it much more subtle to avoid it from looking tacky.

I would also shrink the header. A smaller, more simple logo would be much more memorable. You can place the logged in user info horizontally beside the "ADD PROJECT" button.

I would also prefer the "skills" to be placed in a categorized list format rather then a tag cloud. Easier to find what you are looking for. Same goes for the "roles".

I would also like to be able to sort the "members". You could sort them by project, geographical location or even profession.

I enjoy the relationship capability similar to a Twitter follow.I registered for an account without any problems.

I would like some AJAX capabilities added to the forms. You can use it for validation. Keep the server side validation in case the user has Javascript off. You can also add some style to the form inputs. Maybe an inset effect. The "Submit" buttons could have a similar style to the "ADD PROJECT" button.

This is a great idea for developers to show what they can do. This is a great app for freelancers trying to build a reputation. Great app.

Good luck!

Karl

<comment><AUTHOR> Thanks Karl, the feedback is much appreciated. I'll get cracking as you've made some great suggestions.

</comment></comment><comment><USER3> Maybe make this a LinkedIn app? Sign in via LinkedIn, see the companies you worked at as headings. Then, beneath each heading, fill in the projects you worked on? Entries are shared on LinkedIn. It's a way to more clearly articulate to the world the types of things you've done.

Given that LinkedIn is the leading business social network, and given that the users of iWorkedOn clearly have an interest in sharing what they've worked on, wouldn't this be a natural fit?

(BTW: title needs to change. Says "Ask HK" (hong kong!?) :-)

<comment><AUTHOR> I thought about using LinkedIn, was afraid to rely on LinkedIn for such a huge part of business, but I may rethink this now.

</comment></comment><comment><USER4> First impression: pretty good, I instantly knew what was going on and signing up worked exactly as expected and was painless.

The /users/view/ pages are not nearly as good or visually pleasing as the /projects/view/ pages. As a user I want someone landing on "my" page to be impressed, not be presented with a rather boring page of text. Screenshots for each project worked on, maybe moving the user's photo over in the left pane, etc may help here.

</comment><comment><USER5> Slighty different take on this idea

<http://whobuilt.it/>

<comment><AUTHOR> There are so many more people involved than just building the site, so one of my goals was to produce a system that would allow everyone involved to get listed

</comment></comment><comment><USER6> Allow users to upload screenshots of projects. This is especially important for designers.

<comment><AUTHOR> You can currently add 1 screenshot of the project, but I'm working on making that easier (and clearer) to do, and allowing more images.

</comment></comment><comment><USER7> Is it possible to add any screenshots or embed any videos to the projects tab? So visitors can have a look at project profiles easier.

<comment><AUTHOR> You can currently add 1 image to a project, but allowing more images/video is right at the top of todo list.

</comment></comment><comment><AUTHOR> Clickable: <http://www.iworkedon.com></comment>


In Ukraine, a Malware Expert Who Could Blow the Whistle on Russian Hacking - <AUTHOR> https://www.nytimes.com/2017/08/16/world/europe/russia-ukraine-malware-hacking-witness.html? <comment><USER2> delirium</comment>


Jumper, fast, lightweight pathfinding Lua library for grid-based games - <AUTHOR> http://github.com/Yonaba/Jumper <comment><USER2> Would love to use this in a Corona SDK project!

<comment><AUTHOR> Some people already did, and it seems to be working flawlessly ;)</comment></comment>


Onion Future Acts (1958) banning the trading of futures contracts on onions - <AUTHOR> https://en.wikipedia.org/wiki/Onion_Futures_Act <comment><USER2> Every time I think about this I can't help but think of the Frozen Concentrated Orange Juice futures.</comment>


Instead of Writing a Thousand Words, Part One: Ideas - <AUTHOR> https://www.laphamsquarterly.org/ideas-infographic/ <comment><USER2> It took me a couple minutes to figure out how to navigate this on mobile.

Swipe right on the bottom block of text (not the map) to advance. Tap on it to read the story for that location, and tap again to return.

I found it annoying enough that I didn't read past the first two pages.

</comment><comment><USER3> "scroll down for more"

where is my scroll bar, why don't space or cursor-up/down work, there's no scroll wheel because I use a drawing tablet instead of a mouse, guess I'm not reading this at my desk.

<comment> munk-a People on HN tend to be a bit picky about web design, but this site is absolutely terrible. In addition to the lack of a scrollbar it has navigation links that let you read _most_ of each section and has several different methods for scrolling in it (sometimes it gives you a big down arrow, sometimes you need to rely on the side bar, the side bar is apparently truncated for "ease of use"). Though, in firefox, arrow keys, space bar, home and end do work while pg up/dn randomly pan the map for some reason.

I am wondering if this was considered an interesting article or just a really good page to send front-end interviewees for as a "let's see how many terrible things you can find" game.

<comment><USER4> In defence of the author, they have used a standard ESRI webapp/story map template.

What blows my mind is that I knew it was going to be this before clicking through entirely based on your comment.

The service provided by ESRI is handy for those with minimal knowledge to make something decent, but it's also easy for people to get carried away and use all the features. This is like the modern equivalent to marching ants, I guess.

</comment></comment></comment><comment><USER5> TLDR: is that humans have a "storied" history of using pictures to communicate. So much so that even space probes have been sent with diagrams of our solar system in lieu of text.

The site has nice interactivity with the map and the associated historic image from the some point in time.

For me the whole post was worth it just to find this little gem of a book tucked away at the end `Ost Trifft West` by Yang Liu [1]. It is a visual representation of cultural differences which I found both wonderfully light hearted and highly informative.

[1]: ISBN-13: 978-3874397339

<comment><USER6> We use pictures, but nearly universally those pictures require a shared culture to understand, knowledge of a complex language separate from the image. The images are metaphor, representations, of complex ideas. On the Voyager probe that language was math and physics. The image is not the communication, but a pointer referencing something in the shared database.</comment></comment>


Hacker News meetup in San Francisco (Wed Apr 22nd 6:00pm Revolution Cafe) - <AUTHOR> http://upcoming.yahoo.com/event/2464397/?ps=6

<comment><USER2> Cool! I'll be there. There is also the OHH at Mission Creek Cafe from 8am to 6pm every Wednesday. <http://www.archivd.com/open-hacker-house>

</comment><comment><USER3> <3 Revolution Cafe. Last time I tried to go to one of these, I didn't know who anyone was and if they were for the meetup. I know it's corny, but should there be a designated meeting color? Orange?

<comment><USER4> Next time, just walk up to people and introduce yourself. Why wear a color when the point of the event is to meet people? Would you really feel that bad if your introduced yourself to someone who wasn't a "hacker?"

I know if feels awkward at first, but talking to strangers gets easier over time.

</comment></comment><comment><USER5> Glad to see some of the meetups are extending to SF as well as down in the Valley. iamelgringos hacker and founder meetups are pretty damn legit though.

Good luck bros.

</comment><comment><AUTHOR> Last time I wrote a very rudimentary sign so that anyone could identify us. I don't have access to a printer now but if someone wants to print a sign it would be great.

Last time we just introduced ourselves, I'm with @blackguardx, it's more fun to just introduce yourself, you might even meet someone new that's not from the meetup hehe

</comment><comment><USER6> Sounds great, thanks for organizing it!

</comment><comment><USER7> great place</comment>


A Nationwide Missing Person's Awareness System - <AUTHOR>

Needing investors to help us obtain the infrastructure for a Nationwide Missing Person's Awareness System which will proved multiple displays across the Nation for public viewing of missing persons. <comment><AUTHOR> Please visit www.mediaforthemissing.org to learn more about a highly visible system that will help keep the public continuously informed of alerts and missing persons.</comment>


Adventures with mmap and Go - <AUTHOR> https://medium.com/@arpith/adventures-with-mmap-463b33405223#.l7eh414rf <comment><USER2> Google code search used mmap and go back in the day: Regular Expression Matching with a Trigram Index or How Google Code Search Worked [https://swtch.com/~rsc/regexp/regexp4.html](https://swtch.com/~rsc/regexp/regexp4.html)

[https://github.com/google/codesearch/tree/master/index](https://github.com/google/codesearch/tree/master/index)

I used mmap in a go project that had large (GByte) hash tables. Sidesteps any GC pauses and makes for very fast file loading.

<comment><USER3> Thanks for the link!

</comment></comment><comment><USER4> Maybe also ask your specific questions over on Go-nuts [0] - Lots of knowledgable Go folk there (including a bunch of the Go devs), and most questions get answered pretty quickly. HTH

[0] [https://groups.google.com/forum/#!forum/golang- nuts](https://groups.google.com/forum/#!forum/golang-nuts)

<comment><USER3> Thanks for the suggestion!</comment></comment>


Kindle Paperwhite - <AUTHOR> http://daringfireball.net/2012/10/kindle_paperwhite

<comment><USER2> I find it interesting that Joshua Topolsky (the Verge) also reviewed this device[1], but was much more impressed than John Gruber. I don't think this results from a preference difference, but rather a perspective difference:

Where Topolsky reviewed the Kindle Paperwhite as an electronic device, comparing it to other tablet and e-reader devices, Gruber weighed the Kindle as a book, comparing its characteristics to the print medium.

Considered together, I find the two reviews complementary. The Kindle Paperwhite beats other electronic reading media, but is still lacks some of the characteristics of print. It's certainly a step in that direction, though.

[1] [http://www.theverge.com/2012/9/30/3433110/amazon-kindle- pape...](http://www.theverge.com/2012/9/30/3433110/amazon-kindle-paperwhite- review)

<comment><USER3> That review was pure cotton candy -- published the day before the device was released, with a few other similar embargoed pieces [1]. I was convinced that he just wanted to keep getting scoops.

I pre-ordered it and got it ASAP, and like it except for the extreme sparsity of settings. The wifi is on either for browsing or page syncing; it should be smart enough to turn off if you're not interested in either. The light can't be turned completely off [although, I admit I can't think of a use case for this]. I was excited at how quickly it transfers files -- the specs say USB 2.0, but it's pretty much instantaneous, even for 100 MB bootlegs. The uneven lighting makes me feel resentful, but of course they're just saving that for v2.0

The Kindle Store is useless at selling me new content -- I have a wishlist of books I'd like to read/buy someday. You'd think offering me a Kindle Version of one of them would be a first choice.

And of course, the paperwhite is rooted, so if Gruber wants he can just add new fonts soon [2].

[1] [http://gizmodo.com/5947435/kindle-paperwhite-review- forget-e...](http://gizmodo.com/5947435/kindle-paperwhite-review-forget- everything-else-this-is-the-e+reader-you-want)

[2] <http://www.mobileread.com/forums/showthread.php?t=192858>

<comment><USER4> > That review was pure cotton candy -- published the day before the device was > released, with a few other similar embargoed pieces [1]. I was convinced > that he just wanted to keep getting scoops.

That's a very serious accusation. Do you have any proof to back it up? If anything, The Verge has been quite critical of technology products, and I have no reason to doubt that there's anything untoward influencing their reviews (other than from blatant Apple fanboyism, particularly on the part of Nilay Patel. Take a look at his recent iPod Nano review[0], for example).

0: [http://www.theverge.com/2012/10/10/3481926/apple-ipod- nano-r...](http://www.theverge.com/2012/10/10/3481926/apple-ipod-nano- review-2012)

<comment><USER5> You start out with:

> That's a very serious accusation

(Which I don't agree with, the way it was written) And then you go on to accuse the same website of something else:

> blatant Apple fanboyism

Seriously? - And how is this related to the OP? And from the review you've linked to:

> The new nano might have Apple's connector of the future, but everything else > about it clings tightly to the past — to a world in which iTunes is still > the center of the digital media universe, not a bloated relic badly in need > of a fresh start and new ideas.

 _This_ is so fanboyish that it's worth the side snark?

<comment><USER4> > Which I don't agree with, the way it was written

The OP's saying that a technology website is allowing itself to be swayed for the sake of scoops. This is one of the most serious accusations you can make of a journalist, because it's basically saying you can't trust anything they write.

> This is so fanboyish that it's worth the side snark?

Nilay gave the device a 7.7 when Apple clearly fucked up with the Nano. There was a TON of potential for smart watch innovation with the previous Nano. Apple even acknowledged it when they added clock faces to the Nano last year. There were very successful Kickstarter projects based on using the Nano as a smart watch. Instead of making that official, Apple fucked it all up by (yet again) completely changing the form factor.

My accusation is very different from the OP's because it's not based on any factual misconduct - it's simply the result of Nilay (like many other people) getting sucked into the RDF and drinking Apple's Kool-Aid far too much. If you watch the Vergecast, you'll understand very quickly that he has a barely concealed raging hardon for all things Apple.

<comment><USER5> I think the first four words here make a huge difference:

> _I was convinced_ that he just wanted to keep getting scoops.

<comment><USER4> I don't see how they do. Of course he was convinced, otherwise he wouldn't be making that statement in the first place. My question was _why_ he thought that.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> "Amazon should hire a world-class book designer to serve as product manager for the Kindle."

I think this comment is just about right. The Kindle team really needs to focus on making the Kindle as good as traditional books, when applicable, but better than books whenever possible. Currently the Kindle fails to be as good as books where it counts most (e.g., clarity/sharpness of text, page layout decisions [e.g., hyphens], font choices, display contrast, index functionality, TOC functionality), and it only does a decent job of employing some of the technological advantages it has over books (e.g., the Kindle has a great weight-to-content-offered ratio, it backs up your collection remotely). It kind of surprises me that the Kindle hasn't already surpassed traditional books in every way. Maybe my expectations are too high, or maybe Amazon is more concerned with the bottom line than responding to readers like me. I don't know.

<comment><USER7> As a (very) avid Kindle user - I'd add the following to your list of features to make the Kindle "as good as a physical book":

      o ability to loan to others
      o physically robust (I've cracked three (3) screens)
      o  extended reading time (on at least two 10 day vacations
         I ran my hyperjuice extended battery down
         recharging my K3 every couple days)
      o random-access speeds/location
      o support for color.

<comment><USER8> One data point: I'm also a very avid Kindle user, and I want exactly none of these.

<comment><USER7> I thought these were actually universal desires - so I'd be interested in hearing why?

o Robust - You don't mind breaking kindles?

o Ability to loan to others - You never lend books? To anyone?

o Extended Read Time - How on earth _couldn't_ you want extended battery life. It drives me crazy to go on vacation and have a fully charged kindle run out of battery. I would kill for a solid 100 hour battery life.

o Random Access - You never want to flick through a book? (Admittedly, the K3 has the +/- chapter view, which is good, but not as good as being able to flick back and forth in a real book - particularly textbooks or a complex Game of Thrones reading)

o Support for color - Really? You don't want any color in your books? Not even Text books?

With the possible exception of "Loan to others" - I can't understand why every single one of those isn't a "Must have" in order for the kindle to be as good as a paper book for everyone. Also, and not coincidentally, they also make for a better eBook experience as well.

I would love to switch to "eBook Only" (I've purchased about 200 books so far for my kindles over the last several years) - but, for some things, I continue to purchase paper books.

<comment><USER9> I'm another data point, and here's my responses:

> _Robust - You don't mind breaking kindles?_

I won't break a Kindle. The Kindle is sufficiently robust, and then some.

> _Ability to loan to others - You never lend books? To anyone?_

No. The only exception was my textbooks in college.

> _Extended Read Time - How on earth couldn't you want extended battery life._

How long does it take to read a book? My Kindle lasts easily 4 weeks, reading about 5-8 hours a week, and in that time I can usually get through a 1,000 page novel. I've never taken a trip where I would be without electricity for more than 4 weeks, and even if I were, I doubt I would want to lug around more than one 1,000 page novel.

> _Random Access - You never want to flick through a book?_

No. Again, textbooks are the only exception, but that's not really a common use case for e-readers.

> _Support for color - Really? You don't want any color in your books? Not > even Text books?_

 _Maybe_ for textbooks, although all the textbooks I've actually enjoyed enough to keep after class have been monochrome.

> _With the possible exception of "Loan to others" - I can't understand why > every single one of those isn't a "Must have" in order for the kindle_

And, conversely, I can't understand why many people would care at all about these issues.

<comment><USER10> I see no reason to not strive for more, but for the most part I disagree.

However, if they really wanted to advance ebook readers instead of just enjoying their dominant position and branching into androids tablets and phones, they ought to try to push the envelope.

Frankly, if I _could_ legally get textbooks and have random access, color and better pen support... I would be so, so keen. I think there are education opportunities as well with good pen options and text books.

Why can't you buy your third grader a Kindle and have their math book, math workbook/worksheets, answers, tutorials, everything in their hand? The technology more or less exists for this.

<comment><USER7> PEN support! YES! How could I have overlooked that one!

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> My top three:

1) Give me back my physical pageturn buttons that I can tap without moving my fingers! Why, Amazon, why?

2) Make the LED whiter, maybe even yellower, instead of bluish. I'm not a color expert, I just know that this color looks wrong.

3) I'm not sure what's up with the font, but pick a font that doesn't look fragile, like some parts of thinner connectors are half-not-there.

<comment><USER12> 1\. This is a funny one, and is the main reason why I'm getting my wife the new one.

My wife loves her Kindle but when we're reading in bed together the sound of her clicking the button drives me up the wall. She likes that she can use a larger font so she doesn't need glasses, but that just means way more clicks- per-minute. I think she's pressed the button so many times it's worn out a bit because it makes a very distinct 'click'. After a while each one is like a gun shot in my ear.

<comment><USER13> Little details like this drive me crazy as well. However, I'm always afraid of voicing complaints like this for fear of looking like a crazy person. Thanks for validating me. :-)

</comment></comment></comment><comment><USER14> My main problem is the color temperature of the light. It should shift from blue to orange as you make it dimmer. Reading with a blue cast light late at night, with the lights turned down sucks.

One of my main use cases is reading a book before bed. Without f.lux-like functionality that use case is significantly worse.

On the other hand, I can turn a bedlamp on and turn the backlight off, which is OK.

<comment><USER15> Nice. And maybe the Paperwhite should ship with a clip-on battery operated LED lamp with the proper color temperature.

</comment></comment><comment><USER16> I agree on most points, and made the same upgrade (Keyboard to Paperwhite).

I love it, but I have three gripes. Two of them the author mentioned: uneven lighting at the bottom and the lack of physical pageturning buttons. The latter of which is _not_ nitpicky as luigi has stated, it does fundamentally change your most common interaction with the device.

The third problem is that I have to go in to settings to turn off wireless. Their 8-week claim only works if there is no wireless on; otherwise it lasts a paltry couple of days. The old Keyboard model allowed you to turn on/off networking while reading a book. This version forces you to go to the home screen, then to settings, turn off networking, back to home, and finally back to your book. That's obnoxious.

<comment><USER15> They moved the wireless control to Settings a while ago, with the most recent system software update. I've got a 4th gen Kindle, so maybe that update wasn't supported on the Keyboard version. It pisses me off too.

</comment></comment><comment><USER17> I've owned a Kindle 2 (returned it within 30 days), Nook Touch (sold it), Kindle Touch (soon to sell it), and now the Kindle Paperwhite.

The Paperwhite is clearly superior to all of them. Gruber's points are all extremely nitpicky.

(1) It's not a big deal to move your thumb an inch to tap the screen. The device is so light that I suspect it would be hard to make a button with just the right resistance so that it could be easily pressed while holding it in one hand. But seriously, moving your thumb isn't hard. Gruber also harps on not being able to operate large screen Android phones with one hand. Just use both hands for crying out loud.

(2) The default Caecilia font is great. I think it's beautiful. Gruber loved picking on Droid Sans, but I think that's a great font too.

It's a worthy upgrade to any of the previous e-ink Kindles.

<comment><USER18> > _(1) It's not a big deal to move your thumb an inch to tap the screen._

No, but it IS annoying.

"It's not big deal" is defensive. It conveys the opposite message, that it _is_ kind of a deal.

<comment><USER17> Nope, not annoying either.

<comment><USER19> Oh, well, if _Luigi_ says so.

Leave a little room for the possibility that others are annoyed by things that you are willing to tolerate.

<comment><USER20> Leave a little room for the possibility that John Gruber is annoyed by things that other humans do not notice.

<comment><USER19> I was _immediately_ bummed when they announced the new Kindle without hardware page turn buttons. It was one of the best parts of the Kindle for me. It's a perfectly defensible gripe.

<comment><USER21> It's what is preventing me from purchasing it. The cheapest kindle has perfect page turn button placement. All I need it to do is turn on and turn pages, and when one of those is worse than what the cheaper model can do, I'm going for the cheaper model.

<comment><USER22> Ditto. I was going to upgrade for the light, but the lack of buttons are making me hold off. I can leave the lamp on. I love just barely squeezing my hand together to turn the page. It's almost a non-movement.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> I love the way he approaches the device. His argument that Amazon should work their asses off making this as perfect as possible for reading books is very compelling. Great buttons - yes. Beautiful, deliberately selected typography - yes. I hope someone at Amazon is thinking the same way - I think I'll wait to buy a Kindle when Gruber says "this is what it should be."

<comment><USER24> I would pay a significant premium for that sort of deluxe luxury device. I doubt Amazon will ever do it because they're all about scale. I wonder if they'd ever work with a third-party for doing that sort of work.

</comment></comment><comment><USER25> I wish Amazon would hire some competent UX people. I love the screens and hate hate hate hate hate hate hate using their devices. I'll put up with the iPad screen to read at night because the Kindle software works _better_ on it. W. T. F.? I'm waiting for an e-ink screen with physical page turn buttons, with _no_ other UI than the absolutely bare minimum to read books. I don't want a keyboard, or a web browser, or even a store. Please, just a THING that lets me read. Does such a device exist? Of course, content is king and therefore no single device will ever suffice, which is maddening in its own special way.

<comment><USER26> I agree with nearly everything you say.

> I don't want a keyboard, or a web browser, or even a store.

It's not the most important point, but I absolutely love that I can finish a book and just go online and buy the next part of a series / a new book.

I read a _lot_ so a convenient method to quickly get new stuff is awesome.

Also, the dictionary. My English is quite okay but many fantasy novels use archaic words I've never heard of before. Without a built-in dictionary I'd have to get the meaning purely from context.

</comment></comment><comment><USER27> "the Kindle still lacks hyphenation but yet insists upon full-justified text. Full justification without hyphenation inevitably results in unsightly gaps between words on a few lines each page."

On my Kindle, at least, words seem to be separated at most 1 em, and any more and they go 'ragged right' instead of hyphenating — which I actually found far more pleasant than even Liang's LaTeX hyphenation algorithm in terms of readability.

<comment><USER28> Looking at my Kindle Keyboard, I have one book (Moonwalking with Einstein) that is ragged-right and another (On Intelligence) that is full justified. Perhaps it's the formatting of the e-book and not the device?

<comment><USER29> Can you (or lubutu) share some pics? Thanks.

<comment><USER28> Moonwalking with Einstein <http://imgur.com/7UJgQ>

On Intelligence <http://imgur.com/QIdam>

<comment><USER30> The second of those is interesting. Most of the lines are right-justified, and just a few aren't. It looks to me as if it's right-justified the lines _except_ for when it can't do so without introducing an unbearable amount of whitespace, in which case it's fallen back to ragged-right.

(You can see it isn't just ragged-right where most of the lines happen to end in the same place; compare the spacing on, e.g., the first two lines.)

I don't think I've ever seen anything typeset that way before.

<comment><USER31> I think the reason you've not seen anything typeset that way before is because it's ridiculous to do it that way! You end up with an awful mix of fully justified and ragged-right... to my eye this makes me expect new paragraphs where there are none, for example.

It's such a shame that Amazon just doesn't seem to care about good typesetting practice. It's maybe just not something Amazon views as a "barrier to sale", but as Gruber says, the Kindle only has to do one thing well, so why shouldn't it do it fantastically well?

</comment></comment></comment></comment></comment></comment><comment><USER32> Does the touch screen require flesh or equivalent, or will it work through cloth and fabric?

One of the nicest things about my first generation Kindle, and it's nice big page turning buttons on the sides, is that I can read in bed on a cold night, snug under my blanket, grasping the Kindle through the blanket.

To turn the page, I simply have to bump the side with the hand that is not holding it. This can be done without taking either hand out from under the blanket. In fact, I can usually just bump it on my stomach or chest.

If I have to actually extrude some fleshy appendage out from under my blanket to turn pages, I will consider that a step backwards.

<comment><USER33> The paperwhite uses a capacitive touch screen which does only respond to flesh.

THe previous model, Kindle Touch used an infrared touch sensor that could be triggered by anything touching the screen, but in my experience it was too easy to trigger by accident.

</comment></comment><comment><USER34> I strongly recommend the Kobo Glo. Amazing backlit ereader.

<comment><USER35> I want to buy the Kobo instead of the paperwhite because I hear the screens are almost comparable and I don't want to be tied to the amazon ecosystem exclusively and the microSD support is a big plus. I need ePub support and I do not want ads. I hear the Kobo Glo screen is just as good.

</comment></comment><comment><USER36> The primary reason I upgraded from a 3rd gen Kindle to the Kindle 4 rather than the Touch was the latter's lack of page-turn buttons. But I've been using the Paperwhite for a week now and it's not been a problem at all.

I just rest my thumb on the bottom right corner and move it about as much as I did with the actual button on prior models.

I was excited about the new fonts when I saw them announced, but will agree with Gruber that none of them are great. I still prefer Caecilia Condensed.

My Paperwhite also suffers from some unevenness in the lighting on the bottom, but I quickly forgot about it. Amazon's product description promises an evenly illuminated display, so it would be better if they actually delivered, of course.

</comment><comment><USER37> I have a kobo touch and I love it. My advice is:

\- buy a simple ereader.

\- Turn Off everything you can: the store, wifi, 3g, recommendations, awards, share, ads.etc ANything with an off button.

\- Once a month or three load it up with some books that you would like to read. Just books. Not too many. Choose, then load.

Basically, de-gadgetize it. Make it into a book. A nice, light book.

Our computer world is a hell of distractions. To me, any reminder that I'm reading on a "device" that can do other things is unwelcome. Even recharging the device breaks the illusions for me.

I was initially frustrated that I didn't have a convenient way o get short PDFs, blog posts and such onto the device. Now I'm glad. Short-form articles would just put me into browsing mode.

The upshot of all this is that unless the manufacturers can get better at things they are already very good at (eg weight, battery life), I want the old cheap one. I don't want any new features.

My default position is suspicion of every "feature." I hear "paperwhite screen" My immediate reaction is I don't want it to feel more like a screen & I don't want it to feel more like a screen and I don't want a brightness button.

</comment><comment><USER38> I don't understand the dislike of Caecilia. Sure, it's not quite a book font, but the kindle isn't quite a book either. For the context, Caecilia looks great.

</comment><comment><USER39> Has anyone here compared it IRL with the GlowLight Nook? Thoughts?

<comment><USER40> Should be significantly better. On the Kindle the light is equal all over the screen. On the Nook it isn't.

</comment></comment><comment> alok-g OP>> It definitely feels different on my eyes than LED/LCD backlighting. ... This new display, even with the lighting turned on, still feels like e-ink.

Does someone know what is going on? As such, the light is light whether from LEDs/LCD or from Kindle Paperwhite.

Kindle may be using less default brightness levels but that could be adjusted for LCDs too. Is lower contrast ratio of Kindle helping since black is not too black [1][2]

[1] Kindle has contrast ratio of ~10:1. See here [http://www.best- ereaders.com/2010/09/02/eink-pearl-vs-eink-v...](http://www.best- ereaders.com/2010/09/02/eink-pearl-vs-eink-vizplex/)

[2] <http://news.ycombinator.com/item?id=4357002>

<comment><USER41> Maybe it's actually white rather than r/g/b close together? I can see that being the sort of thing that would make things look different in a way you couldn't consciously explain.

</comment></comment><comment><USER42> I may not be representative, but I actually prefer the lack of backlighting in my keyboard-kindle. The fonts don't bother me either, but Gruber may have a point here.

I would like a good touchscreen, however I like my page-turning buttons and do not want to give up those. I'm also concerned that battery life will be worse on these newer version, and that is something I care about.

Gruber has a point in that the Kindle should be extremely optimized for reading. I already own an iPad, I don't want an eBook Reader that tries to be a cheap tablet.

</comment><comment><USER43> Agree with most points.

I rant into a bug at the gym.

The usual tap, swipe to turn page was instead activating the font size select. I'm not sure if my sweaty finger (sorry for the image) was the cause, or some other bug in the Kindle.

Amazon really needs to make these devices solid. I like the e-ink for the relaxing time experience AND the fact that I don't have to worry about battery (mostly), I just shove it in my gym bag, something I can't do with my nexus 7, b/c the battery might be almost dead.

<comment><USER44> Kindle Paperwhite newly implements two-finger pinch (smaller font size) and expand (bigger font size). On the way to carrying out the font size change, it pops up the font-size select window, then closes it. It's possible that you accidentally invoked this functionality.

</comment></comment><comment><USER45> So I guess not really worth upgrading from the Kindle Keyboard with a lit cover. Too bad, the cover makes it quite heavy, but I also really like page turning buttons for lazy reading.

<comment><USER46> I like it much better than the Keyboard + Cover. If it is "worth it" is up to you, but I don't have buyer's remorse.

</comment></comment><comment><USER47> I agree about the page-turning buttons. That is why I didn't get the touch and won't get the paperwhite. I don't mind not having backlighting, so I'll stick with the cheapest Kindle.

</comment><comment><USER48> Considering that paper books don't have buttons for turning the pages, I find the complaint about the lack of a button for page turning amusing. I suspect it is still less effort to flip a page on the kindle than on a paper book.

Not that such a button would necessarily be a bad idea (not sure). I suppose it would have to be quite sturdy, as it would be used a lot. Perhaps on the touch screen the clicks are distributed more and so it will last longer.

</comment><comment><USER49> How is the paperwhite with pdf journal articles and textbooks?

<comment><USER50> It won't be any better than any of the previous regular-sized kindles, and the experience sucks on them.

PDFs have a fixed-size baked in, typically 8.5 x 11 or larger, and the Kindle screen is much smaller than that. There's no intelligible way to reflow a PDF, especially not one full of tables and figures like journals and textbooks are. It comes out either unreadably small or with unreadably broken formatting.

So basically it's worthless for that use-case. You want a Kindle DX or a 10 inch or larger tablet to fit PDF content comfortably.

</comment></comment><comment><USER51> My nook touch has great hardware buttons and a touch screen. It's also over a year old now and still works great.

<comment><USER52> Yea, I am very happy with how simple and easy my Nook is. Maybe Kindle's UI has gotten better with the touch screens, but it used to be horrid.

<comment><USER51> What I don't understand is why everyone here in The Bay Area seems to overlook the Nook, or really anything competing with the most well known tech brands.

Competition is great and the Nook is fairly competitive with the Kindle. I went with the nook at the time simply because it was superior to the kindle (it had the touch screen first).

For some reason this guy compares it to an iPad but doesn't even mention the Nook.

</comment></comment></comment><comment><USER53> I no longer read Gruber's posts or reviews of products that do not start with an _i_. Because all he does is just re-post those _i_ posts replacing _is just the right_ with _is just not right_ , which saves him both time and energy.

Thought I shall share the revelation :-/

</comment><comment><USER54> Is it just me or does 'paperwhite' sound all to similar to 'paperweight'? Not a good association if you ask me

<comment> Stealth- I have been thinking this same thing. I constantly read it as the "Kindle Paperweight" and think it's some sort of Kindle rant before I realize.</comment></comment>


AT&T iPhone/iPad Carrier Updates for Emergency Alerts = no tracking worries - <AUTHOR> http://www.pcmag.com/article2/0,2817,2420547,00.asp

<comment><AUTHOR> I'll speak for myself here...my trust in my government must be broken, since the main thing in this article that I notice is the last sentence.

>"WEA is not designed to – and does not – track the location of anyone receiving a WEA alert," reads the FCC's FAQ.</comment>