PS3 finally properly hacked? - <AUTHOR> http://www.engadget.com/2010/01/23/ps3-finally-properly-hacked/

<comment><USER2> Original post: [http://geohotps3.blogspot.com/2010/01/hello-hypervisor-im- ge...](http://geohotps3.blogspot.com/2010/01/hello-hypervisor-im-geohot.html)

</comment><comment><USER3> This could make big screen HD video-conferencing\telepresence available for cheap in the living room.

</comment><comment><USER4> Forgive my ignorance, but what practical purpose does this serve? Is it just to be able to use a PS3 for something else like a render farm, or does it affect how games can be played?

<comment><USER2> Sony advertised Linux support on the older PS3 (the new slim model removed this feature). But even then there was no access to the GPU (Sony was afraid people would make homebrew games). This made is impossible to get even things like video playback working acceptably.

With the hypervisor out of the picture, a real, uncrippled Linux system is possible on the PS3.

</comment></comment><comment><USER5> Time will tell.

</comment><comment><USER6> Excellent news, if true I might buy one.

</comment><comment><USER7> The incentive to hack it was much less since Linux was mostly available anyway.</comment>


Tesla to reduce solar panel prices by up to 38 percent - <AUTHOR> https://www.theverge.com/2019/4/30/18523750/tesla-solar-panels-price-slash-decline-sales-roof <comment><USER2> Massively unprofitable company that is only deploying 25% of the solar product it was just a few years ago is magically able to sell it's product 38% cheaper than competitors over night. Amazing!

<comment><USER3> I fail to see the issue. Technologies improve, resource availability can improve. Automation... so many ways that this can be totally plausible, despite the cynicism.</comment></comment>


Want a longer life? Play tennis - <AUTHOR> https://www.abc.net.au/radionational/programs/healthreport/want-a-longer-life-play-tennis/10576424 <comment><AUTHOR> From the linked abstract: "Multivariable-adjusted life expectancy gains compared with the sedentary group for different sports were as follows: tennis, 9.7 years; badminton, 6.2 years; soccer, 4.7 years; cycling, 3.7 years; swimming, 3.4 years; jogging, 3.2 years; calisthenics, 3.1 years; and health club activities, 1.5 years."</comment>


What they don't tell you about event sourcing - <AUTHOR> https://email@example.com/what-they-dont-tell-you-about-event-sourcing-6afc23c69e9a <comment><USER4> The last section on Operational Flexibility and the inability to change the event history raises a very good point.

Like most of the issues, the solution requires experience to know when you are at the Goldilocks point (Just Right). This specific issue has a lot in common with managing database migrations in django or any other migration system.

The ideal situation is to create migrations that can always be rolled back, but sometimes this is not possible to do operationally. For example, a schema change that restricts a field from NVARCHAR to INTEGER can only be generically rolled back if all of the unconvertable data is persisted. This can be mitigated by structuring the database to avoid these dead-ends, and that really is only gained by hard-won experience.

The problem with undoing operations via new events is the same thing -- unless you have foreknowledge of this kind of problem, it is very easy to accidentally create events that perform un-undoable actions. A very simple example of a problematic event would be something that modifies a foreign-key relationship -- let's say it's a digital asset in a game and you want the ability to transfer ownership of the item from one player to another.

The simple solution is a event like SetAssetOwner(asset_pk, player_pk). This would set the item's player foreign key field to the player's primary key. Easy. However, you have lost knowledge of where the asset came from and cannot undo this operation. A better solution would be to make an event SwapAssetOwner(asset_pk, owner_pk, recipient_pk). Yes, the owner_pk is technically redundant, but it provides a check against someone trying to steal an item with a maliciously crafted SetAssetOwner event that performs no checking. Even better, this operation can be reverted by sending the same event with the owner and recipient arguments reversed. Since these properties are part of the event message, they will be persisted in the event history and all of the information to undo the event is self-contained.

<comment><USER5> Idk why people are saying that ES data is always immutable. They can be by default sure, but if a facility is useful to change the history, why not?

<comment><USER6> If you need to change history you can just create new events that accomplish your mutation -- and even mark them as a type 'change history' or some such obvious identifier so when you inspect the event stream you know exactly what you are looking at.

<comment><USER7> I agree, this is 100% normal in accounting, as the earlier thread pointed out. If there is an error you add journal entries to the end to make the adjustment. It is funny that this sort of thing was invented in accounting in 1494.

</comment></comment></comment></comment><comment><USER8> Good article. I've spent the last year migrating to an event sourced system, so thought I'd share some thoughts.

On the eventual consistency point, I've found you can get quite far with having the read model managing the race condition. This probably doesn't work everywhere, but in our system, multiple users can accept an invitation, so we have something like `InvitationAccepted{invitation_id, user_id}`. It's possible that multiple users might accept the invitation at roughly the same time, but the command-side doesn't really have to be concerned with this - <USER2> can happily allow multiple users to accept an invitation. It's up to the read model to ask, 'has this invitation already been accepted?' \- if not, the acceptance is successful and will be indicated when queried, otherwise the acceptance is unsuccessful (and as a bonus, we can separately record who unsuccessfully tried to accept it). From the user's point of view, when they accept the invitation, they see a spinner until we confirm with the read model one way or the other (this could be done by polling the read model, but in our case we have an event sent back to the client).

Coming up with the event schema and versioning/granularity are hard. We have version numbers on all our events to make this a bit more manageable/explicit (`InvitationAccepted1`, for example). Storing events in a relational database does make it a bit easier to go back and edit/upgrade/delete them (sort-of cheating, but also relevant for GDPR). Also, I think we're going to end up suffering a bit from the 'whole system fallacy', but at the moment namespacing all the events (keeping in mind their expected volume) makes it a lot easier to manage.

<comment><USER9> > It's up to the read model to ask, 'has this invitation already been > accepted?'

I feel like you've skipped over the interesting part of your strategy here. If it's an eventually consistent system, what keeps the read model from having the wrong answer to this question?

<comment><USER10> Not OP, but I am working with a CQRS system.

In CQRS eventual consistency does not mean that we have multiple servers such that we have 2 servers with 2 different answers. It means from a command is issued to an event is propagated to all read models, there is a delay.

You need to handle the race condition at some point or another. From a CQRS point of view, a user accepting an invitation is just an event like any other event. What happens based on that event must account for the possibility that multiple users have accepted, and it's a rather straight forward thing to solve with an ES. The "accept" event with the lowest sequence number is the first.

Having the read side handle it would probably mean that when you have a read model for accepted invitations, you ignore all but the first accepted of an "invitationId".

</comment></comment></comment><comment><USER11> Regarding eventual consistency, a CQRS\ES system can also be synchronous, or partially. You could have listeners for events that need to supply a strongly consistent model and others events that feed parts of the system that don't need strong consistency.

"However the events in a event store are immutable and can't be deleted, to undo an action means sending the command with the opposite action"

Well they don't have to be immutable. I don't see why you can't update/migrate events.

<comment><USER12> I also share same opinion based on my experience. Events can be modified and deleted but that must be an exceptional situation (GDPR and other compliances, etc.). But even if it's exceptional you have to provide a clear and easy way to do so and that increases complexity of the solution by a lot.

Another thing is strongly consistent models, there may be valid requirements in some problem areas to have a strongly consistent and normalized model and use it for command validation. This helps especially well in the case when all requirements are not known upfront and/or business domain changes very frequently. A small change in business may require to completely redo the aggregate roots and logic if you follow standard approach, this is very expensive. A better decision could be to use a normalized SQL database instead of an aggregate root. Such approach may be more flexible in certain cases and have it's own benefits as well as cost and drawbacks.

<comment><USER13> Encryption + lose the key policies seem to satisfy the GDPR. So you don't have to actually delete an event, you can just give up your ability to read its payload.

</comment></comment></comment><comment><USER14> Is it just me or the article never presented a solution to the posited problem: "Since each entity is represented by a stream of events there is no way to reliable query the data. I have yet to meet an application that doesn't require some sort of querying."

The solution is said to be CQRS, and nothing in the article shows how you solve that.

If you unwind the unnecessarily winded florid poetic waxing, it all comes down to "dump it to a database, and query that".

<comment><USER15> "dump it to a database, and query that"

Yes.

In some cases, "dump" is a fold/reduce, and your database is just an in memory data structure, and depending on how much latency is permitted by your service level objectives you might cache the data structure as opposed to regenerating it every time.

There's no magic.

The pattern is analogous to what you would do if your book of record were an RDBMS, and you had to run graph queries. "Dumping" the data into a graph database and running the query there would be a tempting solution, no?

</comment></comment><comment> shady-lady Hopefully bi-temporal tables get added to Postgres soon.

I think it would cover a few of the use cases that people are turning to event sourcing for(excluding scale).

</comment><comment><USER16> I don't see much discussion of event-sourcing simply using a SQL database (i.e. skipping the CQRS part). This would allow you to keep your CP (strongly- consistent) semantics.

While this clearly wouldn't work in high-volume cases (i.e. where you _actually_ need CQRS), it seems like this would be the simplest option for many systems. I see a lot of articles advocating for immediately jumping into CQRS, which seems like a big increase in architectural complexity.

Does anyone have opinions/experience on this approach?

<comment><USER17> Don't you still need a queue in your example? do you lock the whole table when you insert a new record to the table? can you elaborate how this solves consistency?

<comment><USER16> I don't think you need a separate queue; if you have an "Events" table then you can just write everything there.

It solves the consistency problem because you can create your event inside a transaction, which will rollback if another event touching the same source is created simultaneously.

E.g. if you have these incompatible events in a ledger:

CreditAccount(account_id=123, amount=100)

DebitAccount(account_id=123, amount=60)

DebitAccount(account_id=123, amount=60)

You'd want one of the debit transactions to fail, assuming you want to preserve the invariant that the account's balance is always positive. You could put the `account_id` UUID as an `Event.source` field, which would allow you to lock the table for rows matching that UUID.

<comment><USER5> If your idea in the example is that the second "debit" is created by another transaction while your transaction is in progress, then this will not work out. Firstly it requires a dirty read, which is nothing I would rely on in a transaction. Secondly, if the dirty read works, assuming the outcome of several rows is just a read operation, which forces you to rollback on the client and still leaves a window for inconsistencies if you decide to commit. Maybe SELECT .. FOR UPDATE can do a trick here, but that is like giving up life.

To round this up: RDBMS are bad for queue like read semantics. All you can do is polling. Which is even worse if you end up being lock heavy.

<comment><USER10> No matter how you model things and no matter what technology you use, a race condition like this needs to be handled one way or another. You either handle it such that the data is always consistent, or you handle inconsistent data.

You can use an SQL database with transaction and locking to ensure that you will never debit money that isn't there. Or you can save commands in a queue that only a single process at any given time (that incidentally includes the SQL scenario). Or you can use a distributed consensus algorithm with multiple stage commits. There is no way around it.

</comment></comment></comment></comment></comment><comment><USER18> Strong consistency is possible with this model, consider for example git.

One real database that works like this is Datomic, which is competitive with SQL for most kinds of read-heavy data modeling loads that SQL and CQRS is used for.

</comment><comment><USER19> All the issues the author talks about are valid, however, the idea that no one warns you about them is wrong.

If you do even the most basic research into Event Sourcing you will find people warning of these trade offs (foremost amongst them Greg Young, the person who originally set out the idea)

</comment><comment><USER20> I've never quite been able to get my head all the way around "Eventual Consistency". I don't understand how actions that could conflict or resources that could be contended are supposed to work? At some point, something has to say, given two actions A and B that are in conflict, the later action B must fail.

So, where does that happen? When getting written into the read model? Then what, it emits an event saying clearly that the previous action failed? All while there's a client waiting for results?

I'd love to see a worked example based on discrete resources. Such as two people, a box, and a ball; where the ball can be held by either person or in the box, and a person can take the ball from the box but not from another person.

I find the concept intriguing but I don't really get it and I haven't been able to identify in any of the writing where "the buck stops".

<comment><USER21> Conflict resolution is a separate problem that isn't addressed by Eventual Consistency. If I make a write in an EC system, that write may eventually be accepted, it may be rejected, or it could be resolved through something smarter like a CRDT. EC just says that I won't know that immediately; that different parts of the system can have different views of the truth at the same time. And for most business systems that's usually okay, if you're talking about consistency that resolves on a good-enough timescale.

<comment><USER20> Thanks for answering. Is Eventual Consistency a necessary property of a CQRS/Event Sourcing architecture?

<comment><USER21> I don't think it is, but—as usual with EC—if you don't want it there's a performance cost. The way you'd avoid it in a model where writes go into one queue/connection and reads come out somewhere else is when you'd do a write you'd have to block and wait on that write being acknowledged on the reader side (or you build in some sort of side channel to whatever your write handler is so it can tell you when a write has been accepted, if you're doing conflict resolution on the write side (some systems don't and push it off to read- time)).

But at that point you're just simulating something you probably already had before going to CQRS/ES, so you would only want to do that in very select cases. Otherwise there's really no point to the architecture...

</comment></comment></comment></comment><comment><USER22> I've worked with event sourced systems quite a bit in production and at scale, and have written a book on Akka and another one on related topics. While I have been an advocate of the approach, My experiences are guiding me away from implementing Event Sourcing in many use cases (especially where the entities are long lived). While CQRS is more complex, I'm more likely to implement CQRS without event sourcing, where an entity is responsible for its own persistence using whatever mechanism we deem suitable, and emits events that can be used for the view (or the data can be viewed as read only.) Ultimately a bounded context is there, and you send it commands and get out events. You have to evaluate the recovery and persistence mechanism based on your needs. Exactly once delivery is a pipedream so it doesn't matter how you're persisting the event and delivering it, evaluating line by line, crashing somewhere it's going to be possible to emit an event twice somewhere (eg if the outbound projection emits the event but doesn't persist its offset.) You need to deduplicate somewhere to get exactly once processing semantics. There _are_ simpler approaches to persistence that work just fine with the same delivery guarantees that work fine in the place of Event Sourcing. Nobody talks about any alternatives though - everyone defaults to event sourcing. My intuition guides me to look at other options having been burned one too many times, watching organizations collapse around 100% event sourced applications, etc.

I'm still working on event/message driven systems (today with Elixir mostly) but I've started to make architectural compromises to move away from especially event sourcing. Event Sourcing + CQRS may be prescriptive but it's very hard for new developers to pick up and understand the layers of abstraction underneath eg Akka + the Persistence Journal. And I'm not sure I can trust many of the open source libraries outside of Akka to be honest. I've had to dig into the depths of postgres journal implementations and apply windowing to journal queries for example because they weren't burned in at the scale I was working with (partially because I inherited an application with a single entity in a context which had many million line long journals - <USER3> highlights a design error though but hopefully you can see my point.)

You don't _need_ to use these patterns but you can still apply DDD and event/message based abstractions, and publish events. An entity can write its state to a record and then apply the state in memory as well without using a journal given you handle exactly once processing semantics correctly. This means there are knobs and dials. The problem with event sourcing in the greater picture is that it's descriptive of an approach, and there aren't many clear alternatives that people are talking about that work in similar system designs. If you have very long lived entities, or only a few of them, it gets especially difficult to keep the system alive over time, but for those use cases it doesn't mean you should stop receiving commands and emitting events.

You always here about the idea of the approach, never the reality of maintaining these systems, or the inappropriate use. In one implementation, there is one entity that receives thousands of events a day, and lives forever. How do you maintain the journal while changing the code, keep it alive over time? I've watched event sourcing and CQRS sink projects and teams. I've watched well paid contractors unable to figure out how to cluster and scale these systems. The barrier to entry for people to become effective can be high and you should understand the long view in terms of people required and cost over time and validate the approach for your use case very carefully. Again, the fact that everyone talks about event sourcing and no closely related alternatives makes it seem like the gold standard or the only option but there are other (simpler) ways to deal with your persistence in an overall similar architectural approach.

<comment><USER23> I've re-read your post a couple of times, but still find it confusing. It reads like you're an early-adopter, and got burnt multiple times by design flaws, and people not being familiar with it.

Suppose ES/CQRS is designed well, and a well-understood mechanism, would you still move away from it? For which scenarios? I can imagine exactly-once delivery not being a problem in all scenarios.

And what is the problem with long-lived entities? Solely the fact it takes longer to reconstruct current state?

<comment><USER22> I'm only saying it isn't the only approach, even if you're keeping the source of truth in memory. It's the most prescriptive approach for sure so is the one people tend to go for first but there be dragons in managing especially long lived journals. Migrating the journal over time, figuring out how to truncate it (especially if there is an initial creation command/event that describes the rest of the life, or periodic updates to the structure - you have to keep all of that data forever potentially to know that it's going to wind up being correct.)

And yes long recovery times are an issue unless you want to keep every entity in memory forever and ever, or you can tolerate extremely slow turnaround times. There are knobs and dials here that are subtleties that people won't think about until after they launch.

If you have a hammer everything looks like a nail kind of thing. There are other ways to handle problems that are only marginally different in how they persist and recover state, yet are far more usable for certain use cases. I'm extremely skeptical when I see someone gung-ho for event sourcing if they've never used it though. I tend to look at the problem very hard to see what else we could do for persistence while still maintaining the "source of truth" in memory.

</comment></comment></comment><comment><USER24> It's really important to manage versioned schema for events and defining rules around evolution of schemas, hopefully with tooling support like via Avro's Schema Registry or Protobuf's forward and backwards compatibility guarantees.

</comment><comment><USER25> Still like the idea but it is more complex to do it right and keep it right.

Would only do this with a good team and a real problem where this would be useful.

Rdbm goes very far

</comment><comment><USER26> CQRS: "Command Query Responsibility Segregation"

Fowler's post is predictably excellent: [https://www.martinfowler.com/bliki/CQRS.html](https://www.martinfowler.com/bliki/CQRS.html)

<comment><USER27> This is already cited and linked in the article (along with Fowler's article on event sourcing).

</comment></comment><comment><USER28> CQRS & Event Sourcing are good ideas, but putting yourself ON PURPOSE with eventual consistency is _nuts_.

Until your are in the facebook-big-data scaling challenging, you don't need the madness of lose ACID. You can get terabytes of data easily on a single server, and even partition by company, customer or similar that still allow to keep domain-level consistence.

Now, I put the events after my normal CRUD operations (ie: I emit CRUD + Save to event in a single transaction). Is super easy of operate and keep coding familiar and predictable

\----

I think the ideal EE database engine must be like:

Have a log Table, and a index/subtables for each validation (ie: to check uniques, aggregates, counts, etc.)

So, if a have a customer related events, I have:

\- Index on: code, name

\- SubTable: code, name, isactive

all the other fields are not need for validation so are recovered from the log.

In ACID:

\- POST Command

\- Validate data with the index,

\- Save to log

\- Emit blocking events (events that need to be at the same time after the save)

\- Commit

Eventual:

\- Emit lazy events (events that not need ACID, like to fill external sources)

</comment><comment><USER29> I'm glad somebody else said it. It seems lately a new meme is coming around (by many people independently) all saying:

Wait, event sourcing / immutable data doesn't scale.

I was doing event sourcing in 2010, and loved it. It was incredible. But by the time I started hearing people call it "event sourcing" I had already moved on to:

State-based, graph CRDTs.

They combine the best of event sourcing with the best of distributed state replication, and are super scalable!

Now even the Internet Archive[1] is running it (in 2014 I implemented it into a library that they are now using - [https://github.com/amark/gun](https://github.com/amark/gun) )

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

</comment><comment><USER30> They didn't even tell me what event sourcing is.

<comment><USER31> As I understant it:

Consider you have a database where you store the account balance.

If you want to update the account balance you might update the row for that customer, e.g.

tblAccounts \</comment></comment><comment></comment><comment> | AccountHolderId | AccountBalance |

update tblAccounts set AccountBalance = @NewAccountBalance;

In an EventSource database instead you wouldn't update the AccountBalance column. You would store something like:

AccountEvents | AccountHolderId | AccountBalance + 100.00 | AccountHolderId | AccountBalance + 150.00 | AccountHolderId | AccountBalance - 80.00

Then ifyou wnat o get the current balance you can just take the opening balance and add 100, add 150 and subtract 80.

Periodically you need to collapse these as querying for the balance could end up requiring going through a large log of events. So you snapshot at some point in time. So assuming an opening balance of zero, we could snapshot the above to 170.00.

It feels like you get auditing / logging of all changes out of the box, also if you are working in functional programming or a system where you constrain side / mutability as much as possible you sort of eliminate your db as a giant mutable object. But you also get the downsides this article talked about.

<comment><USER32> Account balance is a bad example, because it cannot be solved using event sourcing. A key to event sourcing is eventual consistency. The account balance cannot be eventually consistent, otherwise it will allow double-spending. It has to be immediately consistent.

<comment> UK-Al05 Not if the event sourcing aggregate rehydrates on the request to spend, and sends failure or success back.

</comment></comment></comment><comment><USER33> Sounds like OLTP transactions and aggregated state only with hip names.

</comment><comment><AUTHOR> Guys, just need to say that this article is not mine!

</comment><comment><USER34> _If we choose to build a business critical functionality around this eventual consistency can have dire ramifications. There are use cases that availability is the needed property of a system but there are also use cases where consistency also is, where is better to not make a decision rather than making it based on stale information._

I see this issue raised quiet often. If consistency is paramount you can make commands on certain aggregates be synchronous all the way to updating the read model. There's nothing that says you MUST have a queue in-between the event log for an aggregate and the logic that updates the read model. Use common sense.

 _Typically shines the most when pinpointing parts of the system that benefit from it, identifying a specific bounded context in DDD terms, but never on a whole system._

I feel like Greg Young has taken great pains to make this clear. This should be taken for granted when attempting CQRS.

 _Also your events will be based on a SomethingCreated or SomethingUpdated which has no business value at all. If the events are being designing like this then it is clear you're not using DDD at all and you're better of without event sourcing. Finally, depending on the requirements on how the synchronous the UI and the flow of the task is the eventual consistency can, and most of the times will, have a klinky feel to it and deliver a poor user experience._

If the read and write model are being updated asynchronously from the UI you're gonna have to adopt an optimistic caching scheme on the client. This is why GraphQL subscriptions are pretty much boilerplate for any client I build against a CQRS service. The Apollo client seems to handle this rather well.

 _Converting data between two different schemas while continuing the operation of the system is a challenge when that system is expected to be always available. Due to the very nature of software development new requirements are bound to appear that will affect the schema of your events that is inevitable._

I hereby give you permission to use the Strategy Pattern. Problem solved.

 _The events can't be too small, neither too large they have to be just right. Having the instinct to get it right requires an extensive knowledge of the system, business and consumer applications, it's very easy to choose the wrong design._

Greg Young and others have talked quite a bit about how to bound aggregates.

 _However the events in a event store are immutable and can't be deleted, to undo an action means sending the command with the opposite action._

This is why bookkeeping systems have the idea of "journal entries". I haven't implemented one for an event sourced system but I can see how this might work.

Overall great post. Really enjoyed that the author took the time to walk us through all of these issues. Most are non-trivial.</comment>


Captchas are Becoming Ridiculous - <AUTHOR> https://www.andrewmunsell.com/blog/captchas-are-becoming-ridiculous <comment><USER2> The squished-up word is the control word, and the straight one is the unknown one. You only need to get the wavy word right and just guess at all the cut- off examples.

<comment><USER3> I've solved a lot of captcha's in my time, and really have never experienced the trouble the author is detailing. Not only am I relieved when I see a reCaptcha since they are some of the easiest and most forgiving challenges, but I don't recall ever having repeated bad/unsolvable challenges presented on the same page.

Sure, maybe sometimes you get a weird one and fail it. But typically the next challenge is easy to pass. Seems the author cherry-picked some of the worst reCaptcha examples for the article, but wrote it in a way that made it seem they were presented back-to-back.

Besides this -- the article makes no attempt to offer a better solution.

Captcha's are really the best way we have right now to "prove" someone is not a bot. Hidden Form fields, etc, don't work and are easily spoofed. Sure Captcha's can be beaten by bots sometimes -- but I trust Google's scale/volume with ReCaptcha to handle that for me (for the most part).

Captcha's are not going anywhere anytime soon.

<comment><USER4> >Besides this -- the article makes no attempt to offer a better solution.

That's completely irrelevant. Criticism is not about solving the problem. It's about pointing out that the current solution is inadequate.

Most movie critics never wrote, directed, or acted in movies. It doesn't invalidate their criticism.

In fact, your criticism of the other poster's criticism doesn't offer a better solution than criticism either. You simply criticize that post. (And that's OK, if ironic.)

<comment><USER5> Absolutely.

I hate with a passion the attitude of "Don't bring me problems. Bring me solutions". Sure, if you've got a solution as well, that's great. But I'd much rather know there's a problem that you don't have a solution to than be completely ignorant of it.

<comment><USER6> I go even a bit further: don't bring me solutions, just tell me what makes your life difficult.

As a tools developer, I observe that user-provided solutions almost never address anything outside their specific problem, which is potentially only one of many things the feature with the issue is designed to address.

Some of my colleagues tend to point to user feedback as gospel, including the ways suggested to "fix" the issue. But those fixes are often myopic and laden with technical debt.

But I will never disbelieve a claim that something is confusing, or hard to use (almost never, anyway; some people are idiots). Just don't be offended if I don't fix it in the way you came up with.

</comment></comment></comment></comment></comment><comment><USER7> Here's something interesting. If I go to the ReCaptcha demo page in Chrome that is logged in to Google, I get all house numbers, a lot of which seem like easy OCR. If go to the same demo page in Incognito mode, I get the two word version instead, like this blog is complaining about.

[http://www.google.com/recaptcha/demo/](http://www.google.com/recaptcha/demo/)

<comment><USER8> Yes: reCAPTCHA now keeps a profile of you and gives humanoid users easier reCAPTCHAs.

[http://googleonlinesecurity.blogspot.com/2013/10/recaptcha-j...](http://googleonlinesecurity.blogspot.com/2013/10/recaptcha- just-got-easier-but-only-if.html)

<comment><USER9> in other words, it's not giving you reCaptchas, it's giving you unCaptcha's yet so you can do work for them for google streetview.

</comment></comment></comment><comment><USER10> The audio captchas are psychotic. They are scarier sounding than anything I've heard in a horror movie lately, and I have never been able to solve one.

<comment><USER11> Psychotic and almost impossible to solve. I tried an audio captcha recently on a whim and I was bewildered.

I think any site that uses reCAPTCHA must not have any regular vision impaired users.

[https://www.youtube.com/watch?v=HhFLC8ZZQeM](https://www.youtube.com/watch?v=HhFLC8ZZQeM) [https://www.youtube.com/watch?v=KNVcIogEXOo](https://www.youtube.com/watch?v=KNVcIogEXOo)

<comment><USER12> Analysis of audio captchas has led to a number of exploits for several captcha systems including recaptcha - which is what all that horrible obfuscation is trying to prevent.

<comment><USER10> It seems to be really good at preventing visually impaired users from using your site. Unless it is true that they really do develop better hearing.

<comment><USER12> I don't know how you would solve that problem, other than not having one at all, which of course wouldn't be fair. Having the audio clearly describe the solution would make the captcha useless.

</comment></comment></comment></comment></comment><comment><USER13> Here's the one I got on linkedin recently

[https://twitter.com/check_ca/status/480784849260019712](https://twitter.com/check_ca/status/480784849260019712)

<comment><USER14> I got one in Hebrew once:

[http://twitpic.com/8u8un4](http://twitpic.com/8u8un4)

<comment><USER15> Looks like something you might get with CRAPCHA:

[http://crapcha.com](http://crapcha.com)

<comment><USER16> Brilliant. I think I'm going to use this on my site and ask humans to not enter anything. Anyone entering something will be considered a bot.

</comment></comment></comment></comment><comment><USER17> I was just thinking this yesterday when I had to recover a Flickr account I hadn't used in ages. I had to solve captchas from Yahoo and Microsoft.

The Yahoo captcha used rotating, bouncing letters on a scrolling background of more letters - ridiculous. Microsoft's was just a typical smeared mess, but no easier to actually solve.

I think I failed each at least 3 times.

It's not just difficult captchas, but use of them everywhere. The site my university recommends for ordering textbooks starts inserting captchas if one searches more often than perhaps twice within a minute. Another I can't recall the details of requires a captcha solve to make any sort of profile change despite being previously authenticated.

<comment><USER3> The article's largest complaint is not being able to read one (1) of the two (2) words in the captcha challenge.

ReCaptcha only requires one (1) out of two (2) words to be correct in the challenge.

It presents one known-by-the-system-word, and one not-known word. If you get the known word correct (the easier of the two to read) then it passes the challenge.

ReCaptcha then pools the answers for the second not-known word and after pooling thousands (or more) responses, then that word becomes "known" based on the average answers (and then that word is "digitized" and used by google maps, or ebooks, etc).

<comment>~

And for those wondering, I find it easiest to read captcha's by just looking at the letters by shape.

Going down the list in the article:

onightsl secretary.

. phaRega

o ndaaar

proximity rsgrrem

and khseeke

. azedcg

elearsal 5

ination amesye

se ebtyR

Reomi now

ivestshm nwre

Again, it's important to note, you only have to get _one_ of the two words correct to pass the challenge. So.. probably 99% of the above list would pass.

<comment><USER18> No, the problem the author mentions is _explicitly_ with ReCaptcha. He addresses your edit in the article, which you would know if you actually read it and didn't just skim. The problem, as evidenced by the author's many examples, is that the control word is often distorted beyond reasonable recognition, and the new word is not valid data. So _neither_ of the two words is solvable.

 _Edit in response to your edits_

You've deleted your previous edit. Still, even with your current edit it is clear you are not actually reading the article. You say:

 _Again, it 's important to note, you only have to get one of the two words correct to pass the challenge. So.. probably 99% of the above list would pass._

However, the author of the article explicitly states that he did this:

 _I decided to just guess the first word and hope "secretary" was the control. It wasn't._

So the author correctly identified one of the two words (and makes the same identification as you did), but was still rejected because it was not the control word.

You obviously don't have an accurate understanding of ReCaptcha implementation, and you apparently are not reading the article with comprehension, despite claiming several times that you have.

<comment><USER3> > You obviously don't have an accurate understanding of ReCaptcha > implementation

I do (I've implemented them many times), but no point in arguing.

I must be the only person who finds the level of security a captcha provides worth the 1 to 2 seconds it takes to type in a Captcha. And if done properly, you should only have to type a captcha once per site.

Which is easier? Allow form spam on your site, or have a user type a captcha once the first time they visit and decide to post a comment or something? Captcha's have provided a tradeoff between inconvenience and protecting your site.

<comment><USER18> Pardon my confusion, but wasn't your original comment arguing _against_ homebrew Captchas?

Also, you say that you have an accurate understanding of _ReCaptcha_ implementation based on the qualification that you have "implemented them many times". ReCaptcha was created by Google, so unless you work for Google on the team that implemented ReCaptcha, it doesn't seem possible for you to have "implemented them [ReCaptcha] many times".

<comment><USER19> Minor point, but reCAPTCHA was purchased by Google, not created by them.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> I'll repost this once again. Why you should never use a CAPTCHA: [http://www.onlineaspect.com/2010/07/02/why-you-should- never-...](http://www.onlineaspect.com/2010/07/02/why-you-should-never-use-a- captcha/)

<comment><USER21> The proposed alternatives are crap. Why shouldn't an attacker read the CSS...

<comment><USER20> Many (maybe even most) people who use CAPTCHAs are never going to be targeted with a personalized attack. Instead they're using CAPTCHAs to prevent generic, spray and pray spam. The bots know how to post a comment on a Wordpress blog, but making even a small tweak to your comment form can get rid of 99% of them.

</comment></comment></comment><comment><USER22> Lately I've noticed 90% of my captcha's being a single number. That is it. A number like "1057" with nothing else. what do they honestly expect me to do with this?

Basically I have to fill in the number and then guess whether it was the first or second set of characters and fill out bogus before or after the number and hope I got it right. The numbers weren't even hard for a computer to read. The only thing it does is waste everyones' time.

<comment><USER16> This happens when they already know there is a fair chance that you are human. So they give you an easy one and get their OCR for free. You are probably already logged in your Google account when it happens. Go incognito, browse with Tor, etc. and you will get the impossible ones.

</comment></comment><comment><USER23> What is everyone thoughts on this type of CAPTCHA?

[http://areyouahuman.com/site-owners/playthru/](http://areyouahuman.com/site- owners/playthru/)

<comment><USER24> it's interesting but two things come to mind. Viewing it on this site makes it seem like it's great, but what about in context? If i came across that, I'm forced to think more than a capthca, just since it's so different and unexpected (maybe that goes away if it's very widespread). Also, it looks like an annoying banner ad game from orbitz or something of years back - that might make me avoid it, ignore or just not trust it.

<comment><USER25> in context we get about 40%-60% higher conversion rate depending on the use case and have over a 95% success rate. we have a lightbox mode that makes it really apparent what you are doing and only has you attempt a captcha after you submit and the form is validated.

</comment></comment></comment><comment><USER26> I can't believe we have not figured out something better than captchas by 2014. I would imagine Google could figure at least how to bake something into Chrome which many would eventually follow. It's asinine that all legit customers have to go through such a silly, completely unrelated hoop.

<comment><USER27> Google _has_ figured out something "better". Basically they use all the data they collect on you to determine whether you're likely to be a bot or not. If not, you most likely won't even see a captcha. (And if so, you'll get a difficult one.)

<comment><USER28> It must think I'm a bot, then. I get captchas all the time, and they've been definitely getting harder and harder to solve over time. I suspect their algorithm pushes me further and further into the bot camp the more captchas I fail (I have about a 10-20% success rate now, and it's dropping). At this point, I only stick around for the 5-6 tries it takes if I REALLY want to use whatever service it's guarding. Often, I'll just leave the moment a captcha appears because I don't want to be bothered. If it's a contact form, I'll use google to find a direct email address or phone number instead (Yes, I've had to resort to that approach many times).

<comment><USER27> Hmm ya, I could certainly see a positive feedback loop developing. Out of curiosity, do you regularly log into a google account and/or use services like gmail? I'm guessing not, since presumably that would give it plenty of data. (Unless you actually are a spammer... ;) ) Also, are you connecting from a location that Google might see as more likely to produce spam? (I would guess any non-"western" country to some extent, with Nigeria likely being at the far end of the scale.)

<comment><USER28> I have gmail open most of the time, but it rarely asks me to log in. It's only when I try to use other services that use recaptcha, or the rare occasions where I have to relog into google and mistype my password more than once. Last time that happened it locked me out of my account for 24 hours because I couldn't solve the captcha (although I could still access gmail on my phone).

</comment></comment></comment></comment></comment><comment><USER29> I always worry that they're getting harder because I'm getting old, so it's comforting that an arms race against bots is the real cause! :)

<comment><USER30> I literally had the same thought after I unsuccessfully tried to get through a captcha for 10 minutes.

It was for a contact form on a vendor's website. Ended up going with another vendor who had identical product

<comment><USER31> would you wait instead of entering captcha with hashcash.io widget? Widget like that - [https://hashcash.io/auth](https://hashcash.io/auth) (notice unlock switch)

<comment><USER30> absolutely not -- at least not on every login into a service.

the on/off metaphor is not clear either - at least make the "login" button be not enabled until the switch is moved

Its sitting on the login form for at least a minute now, filling up the switch background btw

</comment></comment></comment></comment><comment><USER32> We need a browser extension to help us solve captchas with OCR. This is indeed ridiculous.

<comment><USER33> I thought about this as well. I went and registered instacaptcha.com but I never managed to do it and the domain expired.

Seems to be doable. The user pays 1 usd/month and gets 100 credits. The extension author can outsource the solving to [http://antigate.com/](http://antigate.com/) and get the answer in 15 seconds.

</comment></comment><comment><USER34> I think it's time to move to the ultimate captcha: "Is this post spam?"

Then we just hope that the spammers create a perfect solver again :)

</comment><comment><USER35> I realised an intersting thing there. I also get those complex captaches using firefox. But I also have an Opera12.17 running. With this one my captchas for the same page are ridiculousy easy. Sometimes it's just an house number. One item. I never had one even close to what I get on FF.

<comment><USER36> I think it depends on a cookie. Once you correctly solve a dozen or so hard captchas they'll give you easy ones from then on.

<comment><USER35> That would be the logical thing to do. Unfortunately I rarely use Opera. I can't remember solving more then 5 captchas with it. I use FF most of the time with hunderts of solved captchas there. (FF Private Mode did not help either)

</comment></comment></comment><comment><USER37> I have this fear that skynet originally started as a captcha solver algorithm. :p

</comment><comment><USER38> A paper came out awhile ago showing that neural networks are extremely vulnerable to adversarial examples [1]. They showed even slight perturbations of an image generated with their method could cause NNs to misclassify it, but appear no different at all to a human. I am interested if methods like this could be used to extend the life of CAPTCHA a bit longer, even as computers are starting to beat even humans at object recognition tasks.

[http://cs.nyu.edu/~zaremba/docs/understanding.pdf](http://cs.nyu.edu/~zaremba/docs/understanding.pdf)

<comment><USER39> I think you have made a good point and possible solution here. But I am keen to see if researchers can quickly address this issue with NNs. Someone might find an easy fix to this problem.

</comment></comment><comment><USER40> We found that neural networks can solve CAPTCHAS much better than humans, 99.8% on the "hard" ReCAPTCHA instances: [http://arxiv.org/pdf/1312.6082.pdf](http://arxiv.org/pdf/1312.6082.pdf)

This is why visual recognition is just one of the signals you need to use to tell humans and computers apart [http://googleonlinesecurity.blogspot.com/2014/04/street- view...](http://googleonlinesecurity.blogspot.com/2014/04/street-view-and- recaptcha-technology.html)

</comment><comment><USER41> Dear website owners, please, do not use reCaptcha. As was noted in other comments, Google discriminates against the users who try to protect their privacy by showing them nearly unsolvable variant. For instance, I see the hard version all the time since I started to use Privacy Badger for Firefox. It is also not impossible that they discriminate by user-agent.

And generally it is a very bad idea to choose the most popular service among the alternatives, as by doing so you are contributing to the centralization and monopolization of the Internet.

<comment><USER6> It's almost like, if they already know you're not a bot, they don't have to try very hard to re-prove it, or something.

Think of it in a Bayesian sense.

If 10% of anonymous users end up being bots (the prior), and the "hard" recaptcha has a 1% false-negative (incorrectly identifying someone as a human) rate, then of the anonymous users who succeed in getting past the recaptcha, .1% will be bots (the posterior).

But if 1% of sign-in users are bots (probably less than that), you only need a recaptcha with a 10% false-negative rate to achieve the same bot throughput limit. And, those users are less frustrated.

<comment><USER16> While Google is worried by the false negative, we as users measure frustration with the false positive (failures to identify an actual human) rate. Ideally they would find a system where both rates are independent or where false positive are rare.

<comment><USER6> Ideally, yes.

</comment></comment></comment></comment><comment><USER42> [https://www.youtube.com/watch?v=kNdDROtrPcQ&feature=kp](https://www.youtube.com/watch?v=kNdDROtrPcQ&feature=kp)

Pretty neatly conveys the feelings on this topic.

</comment><comment><USER43> It took me about 30 min and >15 captcha's before I could register for this site. The audio didn't help either...

They __are __getting ridiculous.

</comment><comment><USER44> [shameless blog post promo ahead]

One simple way for minimizing junk going through automated submits. Idea without using recaptcha at all: [http://ademsha.com/notes/simple-proposal-to- stop-spam-going-...](http://ademsha.com/notes/simple-proposal-to-stop-spam- going-through-web-forms/)

It works only with JS enabled and uses randomization in order to stop bots learning how to avoid it.

</comment><comment><USER45> I have to type this awful thing every time I log into Envato and I can never get it right. It's so frustrating. Envato refuse to acknowledge its an issue.

I don't even get the point of it since you can get passed them by just hiring people off like at [http://antigate.com/](http://antigate.com/) for as little as 70c per 1000 captchas

</comment><comment><USER46> If computers get so good at solving captchas, are we also getting better OCR?

Time to switch to next, harder, AI problems as captchas :)

<comment><USER47> I hate to be so simple but XKCD said this first

[https://xkcd.com/810/](https://xkcd.com/810/)

</comment></comment><comment><USER48> Recent discussion, [https://news.ycombinator.com/item?id=7419667](https://news.ycombinator.com/item?id=7419667) (there are others)

Also a couple of examples [http://alicious.com/hard-recaptcha- huh/](http://alicious.com/hard-recaptcha-huh/).

</comment><comment><USER36> Since 2012 there have been some changes that make it easier under "normal" conditions: [http://googleonlinesecurity.blogspot.com/2013/10/recaptcha-j...](http://googleonlinesecurity.blogspot.com/2013/10/recaptcha- just-got-easier-but-only-if.html)

</comment><comment><USER27> Is it not obvious in the first case that "secretary" is the unknown word? Clearly ocr wasn't able to read it due to the fading. Likewise, the cut off words spanning two lines in the later versions are obviously the unknown words. The author states right at the beginning that he understands there is a control and an unknown word; he then proceeds to "hope" that the obvious unknown word is the control in the first case, then skip numerous captchas where the control word is straightforward and the illegible word is obviously the unknown. This certainly sounds like willful ignorance for the sake of a blog post.

Also, '"Onightsl"? "Onighisl"? Are those even words?' No, my understanding is that dictionary words are never used as the control, so as not to be vulnerable to dictionary attacks.

Edit: I'm not suggesting that these captchas are in any way good; they do clearly have issues. I'm just saying that storyline in the blog post seems contrived. To me it would be more convincing if presented in a more genuine manner. However, perhaps he was simply very unlucky.

<comment><USER49> What a concise description of why captchas as they exist today are just awful and we have to come up with a better solution!

There you are, talking on and on and on about some tiny unimportant but extremely specific implementation detail no one should ever have to care about. People shouldn't have to read a manual about the inner workings of this captcha implementation (and have some experience with what types of text computer vision is good and bad at recognising!) to have any chance solving it.

In this case the author clearly had no idea how that control/unknown system works in detail (it seems like they, just like me, only know that you do not have to recognise both, but they didn't really understand the reason for that – nor should they have to) but that doesn't really matter for their argument even a tiny bit.

<comment><USER27> Fair enough. I didn't mean to suggest that these captchas are in any way _good_. Only that the author does appear to have technical knowledge of how they work - otherwise they wouldn't use terms like "control word", so it seems that the difficulty experienced was likely contrived for the purpose of writing the blog post.

For me at least, the point would have come across better if that (seemingly) false ignorance were dropped. (Either that, or frame it in terms of, "Here's what an average user sees when they try to log in," or something along those lines.)

</comment></comment></comment><comment><USER50> I believe that this will eventually become a losing game. Normally there's an arms race between those creating security and those thwarting it. In this case, once the recognition schemes are as good as humans, the game is over for good.

</comment><comment><USER51> If only we could invent the verbal equivalent of a trapdoor function. A word puzzle that would be extremely easy for computers to generate and humans to solve (since we understand language), but extremely hard for computers to solve.

<comment><USER52> It's a nice idea, but you have to consider the complexity of the word puzzles compared to the average human's brain power. Most people are quite dumb. If there aren't a sufficient number of problems/answers, or they're simple enough for computers to solve, or they're too complex for a minority of humans to solve, you're boned.

The whole thing is a technology arm's race. The best solution would be one where you simply verify fixed private information. We use captchas for verifying a human being is not a bot, right? And we do that because we assume the user is anonymous for a short time.

Instead we could simply provide a secured authentication gateway where one could provide private information that is linked to a human identity. That way it can't be abused unless they have an unlimited supply of stolen identities. Even better would be if everyone signed up for a TOTP service provider and used their token generator and service-account to prove their human-ness without needing to put in sensitive information. But that's probably too much work.

<comment><USER53> > Most people are quite dumb.

I know what you're trying to say here, but consider today's xkcd[0] as a counter-point. I think "most people" are quite capable of solving a lot of puzzles. This issue is that any puzzle that we can solve in a reasonable timeframe is often a good target for a computer-generated solution as well.

[0] [http://xkcd.com/1386/](http://xkcd.com/1386/)

<comment><USER54> The xkcd is only necessarily true when it is the median average that is considered. However, most people are not necessarily of mean average intelligence.

</comment></comment></comment></comment><comment><USER55> Off topic slightly, but does people with dyslexia have a hard time with captchas?

<comment><USER56> I have dyslexia, no problems with captchas though. In fact I found the examples from OP article to be not all that difficult. Maybe it's because when I am solving the capture, I just look at one letter at a time, instead of trying to read and comprehend the word. I found it that in many cases the control word isn't actually a word at all, just string of characters. I usually have 80-90% success rate nowadays, used to be 100%, but they are really getting more and more difficult.

</comment></comment><comment><USER57> Easy... A stereogram "captcha" ... What's the hidden 3D image? More fun too... [http://www.brainbashers.com/stereo.asp](http://www.brainbashers.com/stereo.asp)

<comment><USER58> NO!!!!!!!!!!!!!! Please NO! I'm stereoblind but also not a bot.

[http://en.wikipedia.org/wiki/Stereoblindness](http://en.wikipedia.org/wiki/Stereoblindness)

</comment></comment><comment><USER59> [http://www.newscientist.com/article/dn24476-software- beats-c...](http://www.newscientist.com/article/dn24476-software-beats- captcha-the-webs-are-you-human-test.html)

</comment><comment><USER60> This is where Facebook comes in handy! Please add your captchas there: [https://www.facebook.com/IHateCaptchas?fref=ts](https://www.facebook.com/IHateCaptchas?fref=ts)

</comment><comment><USER31> It is funny how link [1] from my app solving this problem got more upvotes :)

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

</comment><comment><USER61> There are plenty of tricks around Visual Captchas. What you need is a semantic captcha that's only recognizable as such by a human. Hide a simple question somewhere in a piece of text.

<comment><USER62> Who writes the question and answer?

Although...maybe you could outsource the question and answering to Mechanical Turk. Turn the whole thing on its head. Have a real person write a question to try to trick the bot into revealing its botness, have the real human grade the answer.

</comment></comment><comment><USER63> The problem isn't captchas, but users not understanding how to interact with them. So what if a few are bad? Hammer out best guesses, fast as you can, until you're successful. It's not as if you're graded on accuracy. There is no reason to ever resort to the refresh button,

Out of curiosity, I went and opened the demo page ([https://www.google.com/recaptcha/demo/ajax](https://www.google.com/recaptcha/demo/ajax)) in a new incognito window and timed myself. I can do about 8/minute at maybe 90% accuracy.

Captchas are only a problem if you compulsively refresh in hopes of getting something clear.

<comment><USER64> After I've filled out 20 different forms the last thing I want to do is deal with a completely illegible captcha which might go far as to refresh the entire page or wipe out what I've entered in certain fields (password, ssn, etc) each time I get it wrong. That's one way to push me away from signing up for your service.

<comment><USER63> That's not really a problem with recaptcha so much as the integration with the rest of the site.

<comment><USER65> Well then you obviously understand some websites have problems with this, so why would a user risk losing all of their filled out data?

</comment></comment></comment></comment><comment><USER66> I've recently seen a bunch of them with just one number. Just a single 7 or 4 on a white background and nothing else. Kind of scratch my head at those ones.

<comment><USER67> Do you mean the house numbers/street signs? Like these: [http://i.imgur.com/yD1FrlH.jpg](http://i.imgur.com/yD1FrlH.jpg)

If it's those, I guess google uses recaptcha to get data for streetview.

<comment><USER66> I've seen that, but I've also seen plain black numbers on white that look like they're right out of MS Word. Got me.

</comment></comment></comment><comment><USER68> hmm, I have to say I haven't had a recaptcha that bad yet, but I have had some bad ones.... But uh... on the first bad recaptcha when trying to guess their password they thought - this recaptcha is ridiculous I will try to solve it of course but just right now I am also going to screenshot it because this is naturally the first thing I think to do!

</comment><comment><USER69> I agree that those captchas are obscenely bad. :)

I think we really, really need a replacement solution for them that works as reliably vs. bots.

<comment><USER70> So at what point do we 'switch over' which is to say that the Captcha code realizes that if you _solve_ it your a robot/script because humans can't ?

<comment><USER69> The API stuff that solves these captchas is really akin to Amazon's Mechanical Turk and outsourced to places like India.

[http://antigate.com/](http://antigate.com/)

Scroll to the bottom.

</comment></comment></comment><comment><USER71> I experienced animated GIF captchas with Yahoo's login process. Not sure if that was better or worse than reCaptcha.

<comment><USER72> I don't get why they're doing this. Animation _adds information_ and makes CAPTCHA easier to break!

Attacker can choose the frame that's easiest to attack and they can segment better with help of motion vectors and differences between frames.

</comment></comment><comment><USER73> It's difficult, but I was able to read all of those captchas (the wavy ones). Maybe it's a special skill?

</comment><comment><USER74> If i am relaxing back and have to enter a difficult captcha to watch a movie, I am not watching that movie.

</comment><comment><USER75> This made me remember: I once saw a website with a moving captcha.

Can't remember where I saw. Anyone knows?

<comment><USER76> Comcast does that on their password reset pages. E.g., go to [https://login.comcast.net/myaccount/reset](https://login.comcast.net/myaccount/reset), type in "foo", and click "Next."

Edit: From checking the source, it looks like they're using NuCaptcha ([http://www.nucaptcha.com/](http://www.nucaptcha.com/)). Looks like O2, Groupon, and StumbleUpon are also NuCaptcha customers. You can see examples on this page: [http://nucaptcha.com/features/security- features](http://nucaptcha.com/features/security-features)

<comment><USER77> There is a blog post about defeating NuCaptcha here: [http://www.elie.im/blog/security/how-we-broke-the- nucaptcha-...](http://www.elie.im/blog/security/how-we-broke-the-nucaptcha- video-scheme-and-what-we-propose-to-fix-it/)

</comment></comment></comment><comment><USER78> I had one read 'drink issue' once... Wasn't sure if normal capture or advice.

</comment><comment><USER79> Shoulda stopped at number 5: "and khseeke" seemed pretty clear to me.

But point taken.

</comment><comment><USER80> I've said it before, I'll say it again: hashcash.

</comment><comment><USER81> Alternatives exists, but the usage is low.

A simple solution is google Authenticator (or similar systems).

The only problem is a system for all kind of users and equipment.</comment>


Ask HN: What do you do to improve every day? - <AUTHOR> I've often heard/read that one should aim to improve themselves a little bit each day (e.g. improve by 1%, whatever that means, every day and your progress will compound over time).
To those who DO subscribe to this notion, what do you do to improve every day?
To those who DO NOT subscribe to this notion, why not? <comment><USER2> I usually work in terms of Pomodoros which I use as my deep work outlets. I try to hit as high number as I can get. My personal best is doing 20 pomodoros in a day which translates to 10 hours of focused work.

P.S: A pomodoro is 30 minute work followed by a short break.

</comment><comment><USER3> I break it down into 3 sections. Physically, mentally, and at work. If I improve at all of those, even marginally, it's a win for the day.</comment>


CVE-2014-3466: GnuTLS buffer overflow - <AUTHOR> https://bugzilla.redhat.com/show_bug.cgi?id=1101932 <comment><USER2> If I remember correctly, something similar demonstrated by someone(a bounty hunter) a few months back, and was featured on HN front page as well.

I remember it was maybe related to Facebook, and not to TLS/SSL specifically. Very similar.. sending excessively long session id values.

I wonder if excessively long session id values can break something else as well?

<comment><USER3> Excessively long data is a cornerstone of security vulnerabilities.

> I wonder if excessively long session id values can break something else as > well?

Yes, with p~=1.

<comment><USER2> Indeed it is, but what I was curious to know more about the particular case of session IDs.

</comment></comment></comment><comment><USER4> PoC (not weaponized and ugly code due to lack of time): [https://github.com/azet/CVE-2014-3466_PoC](https://github.com/azet/CVE-2014-3466_PoC)

hf.

</comment><comment><USER5> At least it's a client only vulnerability. Hope your servers don't make outbound connections! :)

<comment><USER6> Because clients don't get re-routed through malicious redirects to unexpected servers. The consolation is that GnuTLS isn't used for popular web browsers.</comment></comment>


Lutris Open Gaming Platform - <AUTHOR> https://lutris.net/ <comment><USER2> It's been a while since I played with Enhydra. Awesome it's still around, in one way or another.</comment>


On Data Privacy, India Charts Its Own Path - <AUTHOR> https://www.nytimes.com/2019/12/10/technology/on-data-privacy-india-charts-its-own-path.html <comment><USER2> This is good in the aggregate. Just like Google employees in mountain view do not want Russians interfering with American politics and privacy data, Indians do not want valley companies influencing politics or privacy decisions for them</comment>


How We Solved the Worst Minigame in Zelda's History [video] - <AUTHOR> https://youtu.be/1hs451PfFzQ <comment><USER2> Hi there, I'm one of the people that worked on this project. By way of summary, we used Ghidra to reverse engineer Wind Waker's binary and discovered its using a very weak RNG and a fixed seed. With that we used statistical methods to determine our position in the RNG period and narrow the game randomness to the point of guaranteeing a win.</comment>


Vapor.js is a new amazing JavaScript framework - <AUTHOR> https://github.com/madrobby/vapor.js <comment><USER2> OK but how do I set it up with webpack?

</comment><comment><USER3> Bummer, doesn't work with React

</comment><comment><USER4> Old but gold</comment>


IPad App Idea - You are free to take it - <AUTHOR> http://marcgayle.com/2010/04/23/iphone-and-ipad-app-idea/

<comment><USER2> No comment on this idea, but I'd love to see more of this (vs Ask HN or Tell HN about my startup).

If you're not going to implement something tell the community. Let us vote it up if we think it's good.

</comment><comment><USER3> _The trick is to start with a bang, say giving away 500 – 1,000 iPads in the first 48 hours._

Hi, the 1990s called, they want their dot-com bubble back :-)

</comment><comment><USER4> I'm going to assume you couldn't charge to play, otherwise you'd certainly run afoul of gambling laws, so it'd have to be funded by advertising revenue, right? Perhaps show a full-on thirty-second video ad before you get to play?

If the economics of that work out, then why should it be an iPad-only affair? Why not do it web-based so everyone can participate (and also avoid whatever issues Apple might have with it being in their app store?)

Now I'm not sure the economics of it could ever work since the amount an advertiser will pay is pretty small meaning the prizes are either too small to bother with or too rare to have a significant chance of winning regardless of how popular the site gets, but hey, if you can figure out a way to do it...

<comment><USER5> Could have the interstitial ad after the scratch but before the result is shown? People would be paying more attention then. Work in a survey question even.

<comment><USER4> Hmm, well I looked up the cost of video advertising and if this three-year-old article is to be believed:

[http://adage.com/webvideoreport/article.php?article_id=12851...](http://adage.com/webvideoreport/article.php?article_id=128516)

then the prices are somewhat higher than I thought -- anywhere from $15 to $100 CPM, or between 1.5 and 10 cents per ad view. I suppose if you were selling at the high end of this range you could fund some reasonable prizes -- how about a one in ten thousand chance of winning an iPad and a one in ten chance of winning a voucher redeemable for a chocolate bar at your local 7/11? At the low end of the range the value proposition becomes a lot iffier, though.

</comment></comment></comment><comment><USER6> The legalities around running lotteries and/or contests might come into play here... do your research if you feel like venturing down this path.

</comment><comment><USER7> I like the idea but can't help thinking someone somewhere will use an actual coin to scratch...

</comment><comment><USER8> I think app store prohibits gambling games, so you couldn't actually give stuff away.

Good idea tho.

<comment><USER9> I think the App Store also prohibits "giveaway" apps (see the comment on the blog).

<comment><USER10> Couldn't the issue mentioned by the comment be addressed pretty easily? Just have a blog or twitter client that announces the giveaways as well; "Giving away: A shiny foo! To enter, use our iPad app!"

</comment></comment></comment><comment><USER11> Why don't state lotteries do this? no more paper waste

maybe build a product and go pitch it to them.

<comment><USER12> Are the iPad people really the type of demographic that buys state lotto tickets?

</comment></comment><comment><AUTHOR> FYI: Seems someone has launched almost the same thing just recently:

[http://itunes.apple.com/us/app/lotto- tickets/id360953651?mt=...](http://itunes.apple.com/us/app/lotto- tickets/id360953651?mt=8)

</comment><comment><USER13> Feels like a better Touch app, especially because anyone who has the disposable income for an ipad probably isn't a huge fan of lotteries.

</comment><comment><USER14> That's a cool idea

</comment><comment><USER15> This sounds too much like GiveawayOfTheDay.com. They don't charge, so all they can give away is pure crap software.</comment>


Only 22% of Australia is covered by Tesla's charging network - <AUTHOR> http://www.finder.com.au/tesla-superchargers-map <comment><USER2> Since Australia is a few major cities and many many small towns, even 22% is a pretty remarkable number.

That said, that oddly traditional roadtrip from Adelaide to Melbourne is 727km (451 miles), so not the kind of trip you're going to be able to take in your Tesla.</comment>


Show HN: Growth is shit? is it worth to spend time on growth hack early? - <AUTHOR> https://medium.com/its-an-app-world/growth-hack-is-shit-bdb82ec12aeb <comment><USER2> [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)

[...] _For example, blog posts, email signups, and fundraisers can 't be tried out, so they don't count as Show HNs._ [...]</comment>


Show HN: CLI for working with CircleCI and .env files (Written in Go) - <AUTHOR> https://github.com/KensoDev/circle-env <comment><AUTHOR> Little CLI I wrote to make my life easier working with ENV variables.

This makes my life much easier building Docker images on the CI.</comment>


Nuklear: A small ANSI C GUI toolkit - <AUTHOR> https://github.com/vurtun/nuklear <comment><USER2> Shame that you specify pixels in the function calls themselves. If it were really abstracted, it would have an arbitrary 'size unit' which the glue code could translate on the backend.

In a world where one user has a 1366x768 screen and her neighbor has a 4k display, we need to move past interface code specifying pixel sizes up front, both on the web and off.

<comment><USER3> I always have an idea in my mind that we should scale / show the interface based on font-size, adjusting borders / button accordingly

p/s: obviously I have NO idea how easy / complex this would be, just an idea given that sometimes text contained in an element bleeds / overflows / outright missing

<comment><USER4> Problem is, we still have jpgs. As long as we have raster images (instead of vector images), we'll be laying some things out based on pixels.

And as long as we have photographs, we're going to have raster images, for the foreseeable future.

<comment><USER5> Rasterizing vector images to different sizes without getting blurry results is not trivial.

<comment> iso-8859-1 If all targets have a relatively high DPI, does that still hold? Wouldn't it be more correct to say "it isn't trivial to rasterize vector images for low- DPI displays?"

</comment></comment></comment></comment></comment><comment><USER6> It looks cool, though the claim about having no platform dependent code must be false... either they have it or they depend on someone who does. Since it's all in one file and I'm on an iPad right now, I didn't try to discern which case it is.

What is the appeal of the implementation hiding in the header file? Is it a 'thing' nowadays? It makes every file that includes it read all 15k lines, and makes you put a special #define in one of your source files, just to avoid having a C file. That doesn't feel like a good trade-off to me. If I used this code in a project, I'd build a static library out of it first thing, and go about my business.

<comment><USER7> Sean Barrett (of stb headers fame) has written about the reasons for header- only libraries here:

[https://github.com/nothings/stb/blob/master/docs/stb_howto.t...](https://github.com/nothings/stb/blob/master/docs/stb_howto.txt)

If compile-time is a concern (it isn't in my experience, at least if the rest of the project is C++ code), you can still wrap the library-header into your own header and put include-guards around it :)

PS: also see here: [https://github.com/nothings/stb#why-single-file- headers](https://github.com/nothings/stb#why-single-file-headers)

<comment><USER8> Because apparently archived files are just too much for Windows devs?

<comment><USER7> Did you ever try to link with externally compiled libraries on Windows? :)

It's an absolute mess, the lib files are incompatible between Visual Studio versions, whether threaded/non-threaded/DLL/static MSVC runtime is used, whether linktime-code-generation is used, if there's C++ code in it, a release lib cannot be linked against a debug executable, etc etc etc...

Only sane solution is to drop the sources directly into your project. Whether it's just a header or a header/source pair is just a small detail, admittedly.

<comment><USER6> Putting external library source files directly into my project does not sound sane at all, and it is definitely not the only option for static libs on Windows. You can also make the library project a component of your solution, and add a reference to it in dependent project(s). That way, they have proper separation but are all built from source.

Having now read the rationale for single header libraries, I am completely unconvinced. These people either don't know how their tools work, or are making bad choices to coddle people who don't. Even forgetting the wasted time parsing the #ifdef'ed out implementation section over and over, it screws up separate compilation. Every time you tweak the implementation section, all the files that #include it will recompile for no good reason.

<comment><USER7> I was convinced of the header-only approach when I replaced DevIL, libpng and libjpeg (all of them made of a myriad of source files and build options, not to mention using non-portable build systems that don't really work out of the box on Windows) with 3 stb headers: stb_image.h, stb_image_resize.h and stb_image_write.h

Even if the compile time is affected (which I never noticed) this is only a minor inconvenience compared to the wins those 3 header files provide.

<comment><USER9> It's not either "build-system dependent mess" or "everything in header." The alternative to "everything in header" is "header file has interface, .c file has implementation." Then you add the .c file to your project, include the .h file, and it works better than "everything in .h" since instead of 20,000 lines all other .c files in user projects have to see only a few hundred lines, which compiles faster. And that's how C projects were supposed to be organized since the beginnings. You don't have to have dynamically bound files if that isn't needed. Some licenses insist on dynamical linking, but when you make your library, your decisions on how it's linked are independent of your decision to stuff the implementation in .h.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> An alternative (in C++, but with C API maintained):

[https://github.com/ocornut/imgui](https://github.com/ocornut/imgui)

<comment><USER11> the difference being that, when i saw nuklear's README, i just wanted to learn enough C to be able to use it... with imgui the first reaction was (the first time i saw it), that i won't be able to use it for software targeting non- geeks. (and i really would like to have a good lightweight UI framework for C++!)

it might be just the screenshots, i've not tried any of both, but comparing the two README files, i cannot say that they are real alternatives.

even if -- very likely -- both are very good toolkits!

</comment></comment><comment><USER12> A really enjoyable talk on the topic by Casey Muratori ([http://handmadehero.org](http://handmadehero.org)): [http://mollyrocket.com/861](http://mollyrocket.com/861)

</comment><comment><USER13> Looks like a great piece of tool! Very often you want to throw something together and the development grind to a complete halt because having to fiddle with the UI integration. Problem solved!

X11 example doesn't seem to run here, on my debian sid+nvidia blobs drivers. The GL* do work tho, abeit with un unreadable font (I'm on a 32" 3180x2160 screen)

X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 70 (X_PolyFillRectangle) Serial number of failed request: 29 Current serial number in output stream: 102

</comment><comment><USER14> Really pretty. Given how small it is, I wonder how difficult porting it to other languages would be; it might make a decent little reference spec for lightweight GUIs.

</comment><comment><USER15> Would be awesome to combine it with something like [https://bitbucket.org/rmitton/tigr](https://bitbucket.org/rmitton/tigr) which is a small and tidy window creation/input processing lib, because I find glfw and SDL too bulky for casual C/C++ programming.

<comment><USER16> There is nothing really dependent on any of the provided demos. As long as you are able to provide an OS window, input and a way to either draw basic shapes or vertexes you are good to go.

</comment></comment><comment><USER17> Rust bindings might solve rust's lack of a prominent GUI toolkit...

Or a straight port to Rust (either imgui or nuklear)

<comment><USER18> Rust has GTK and qtquick bindings, and there is also [https://github.com/pistondevelopers/conrod](https://github.com/pistondevelopers/conrod) which also uses immediate mode. Nuklear looks like it's more capable right now than conrod, though, so Rust bindings could still be good to have.

</comment></comment><comment><USER19> In case anyone wants to see a C++ framework that evolved over time and then was inextricably tangled up in the one application that really used it, check out OpenOffice/LibreOffice's Visual Component Library (VCL).

A demo program can be found here:

[https://cgit.freedesktop.org/libreoffice/core/tree/vcl/workb...](https://cgit.freedesktop.org/libreoffice/core/tree/vcl/workben/mtfdemo.cxx)

A more complex, feature complete demo can be found here:

[https://cgit.freedesktop.org/libreoffice/core/tree/vcl/workb...](https://cgit.freedesktop.org/libreoffice/core/tree/vcl/workben/vcldemo.cxx)

</comment><comment><USER4> When I look at GUI APIs, the first question I ask is, "How easy is it to get things where I want them on the screen/page?" Because that is the fundamental problem for any layout engine.

<comment><USER20> That's an easy question to ask if you know the screen aspect and resolution. What if you don't know either or both? The question suddenly shifts to "Where do I want things on screens?" and suddenly it's not about library anymore.

<comment><USER4> _That 's an easy question to ask if you know the screen aspect and resolution._

Surprisingly, in a lot of GUI libraries, it's not an easy thing.

</comment></comment></comment><comment><USER21> This looks quite nice. But they did fib a bit about no dependencies. It is apparently built on top of GLFW3 which is a nice, small C library that gives you a native window and input handling.

<comment><USER22> There's also a pure X11 version, which only pulls in what X requires:

      $ make
      gcc main.c -std=c89 -pedantic -O2 -D_POSIX_C_SOURCE=200809L -o bin/zahnrad -lX11 -lm
      $ ldd bin/zahnrad
               linux-vdso.so.1 (0x00007ffe32df9000)
               libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f8468746000)
               libm.so.6 => /usr/lib/libm.so.6 (0x00007f8468441000)
               libc.so.6 => /usr/lib/libc.so.6 (0x00007f84680a0000)
               libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f8467e7d000)
               libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f8467c79000)
               /lib64/ld-linux-x86-64.so.2 (0x00007f8468a88000)
               libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f8467a75000)
               libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f846786f000)

<comment><USER21> Cross platform is a key feature. Thats why glfw is so nice. Unless you want to write the grungy windows bits for all your platforms I don't see any problem with useing glfw. Its a solid library.

<comment><USER7> GLFW is great, but it's limited to GL or Vulkan as 3D backend. There's a context-less mode now (created for Vulkan I think), but I haven't seen GLFW used together with D3D or Metal yet. It's fairly easy to rip the relevant window- and input-handling code out though.

</comment></comment></comment></comment><comment><USER23> A couple of tweaks needed to get the example in the README to compile: wrong number of arguments in call to nk_button_text(), and need to take the address of ctx in the call to nk_end().

</comment><comment> iso-8859-1 Can I use this on DOS? I am looking for a successor for [http://intron- trans.hu/agui.html](http://intron-trans.hu/agui.html)

<comment><USER24> Yes, you'd have to implement the drawing and input handling code but this seems like it would be a good fit. You need to implement a fair number of drawing primitives, but certainly less work than a whole GUI.

</comment></comment><comment><USER25> I haven't tried this one yet, but I've tried another immediate mode ui library before and it seemed to busy loop a single cpu core. Is that normal for IM GUIs?

<comment><USER26> You may test it. It is straight-forward do build, e.g. I tested the sdl2 demo (demo/sdl/) and CPU usage was <10%.

I did not dig further, but I like the general idea, as GUI toolkits are biiiiig.

<comment><USER25> I'll give it a try but <10% for an otherwise idle gui sounds like an architectural flaw/disadvantage. An idle gtk2 window sits at 0% cpu.

<comment><USER25> Tried and it's 2%. Not quite gtk's 0%, but better than my last test of an immediate mode ui.

</comment></comment></comment></comment><comment><USER27> Another cool one [https://github.com/fruxo/turbobadger](https://github.com/fruxo/turbobadger)

</comment><comment><USER28> Any hint on how to compile any of the demos on OSX ?

<comment><USER29> I've got it running on OS X with some modifications:

\- In the Makefile, use

      LIBS = -lglfw3 -framework OpenGL -lm -lGLEW

\- In the main.c file of the project, change headers to use <OpenGL/gl.h> and <OpenGL/glu.h>

\- In the shader code, change "#version 300 es" to "#version 400" for both the vertex and fragment shader.

I'll try to make a PR with conditionals if I can find the time today.

</comment></comment><comment><USER30> "Use at your own risk" is not an adequate license, I'm afraid.

Someone concerned about licensing can't touch this with a ten foot pole.

<comment> iso-8859-1 What do you mean? It says public domain in the README.

</comment></comment><comment><USER31> Unfortunately, the font looks very fuzzy (out of focus) when running the extended example. Is there a way to fix that ?

</comment><comment><USER4> nuklear.h is 20,000 lines long. Is the whole thing written in the header file?

<comment><USER32> Yes! [https://github.com/nothings/stb#why-single-file- headers](https://github.com/nothings/stb#why-single-file-headers)

<comment><USER33> I'm confused by the reasoning... why can't you just statically link your distributed exe?

<comment><USER24> Static linking is "easy" on any particular platform for a particular target. But build systems and IDE and all that junk make things more complicated. You might want to build the library with the same flags as your main app, for example. You might have several target architectures you need to build and link against (i386, x64, amd) x (debug, release, QA). Etc, etc.. It also makes it easier for the compiler to inline things.

Header only libs just make all these problems go away, and (IMO) there's not really any downside.

<comment><USER34> > and (IMO) there's not really any downside.

Well, the downside is that it's literally in _one_ header file. Besides being gigantic, it's extremely annoying to search and parse by hand - this is an issue when that's also serving as the documentation. Especially in this case, it would be much nicer to have a "nuklear" folder with a bunch of separate (appropriately named) headers. The single `nulkear.h` header could just `#include` them as necessary.

<comment><USER35> It's a lot easier to search and comprehend 20,000 lines in one header file than 1,000 lines in each of 20 separate header files.

<comment><USER34> I respectfully disagree. If they are separated into thoughtful modules, then it would be much easier to parse by simply looking at the file and folder names and going from there. This will especially be true when this expands past it's current state, and it becomes impossible (Or more impossible) to see what uses what.

IMO, 20,000 is already way to much, but when that reaches 100,000 even just editing it will be a chore, let alone using it. It will simply be unmaintainable and unusable. I say this having worked on code bases which have reached that point and attempted to deal with the issues it creates. There's a reason every decently sized code base out there uses multiple files and a hierarchy. It's a natural way to create modular code, and modular code is simply better code.

<comment><USER35> It depends on the editor, I think. It's criminal that so many editors still can't do what BRIEF did 20+ years ago, and give you a quick and easy way to surf through all C/C++ functions in the current translation unit. (e.g., [http://i.imgur.com/dmlCCpH.png](http://i.imgur.com/dmlCCpH.png) ).

That's why I still use a buggy BRIEF clone instead of a modern IDE. If I were forced to use someone else's idea of a code browser that was architected around files rather than subroutines, I'd probably be more inclined to agree with you.

The idea that the most appropriate way to organize source code happens to correspond to something that a (likely-long-dead) OS implementer chose to call a "file" is a notion that doesn't get challenged often enough.

<comment><USER4> Eclipse does that.

<comment><USER35> Yeah, there are plenty of editors that do, but none that I'd want to use on a day-to-day basis.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER24> Nice job! This looks great.

</comment><comment><USER36> the SDL demo has lots of dependencies obviously, so it's really not something self-contained. I'm always excited any neat GUI for C, but this one seems like just a layer on top of existing GUI libraries, what's special about it? Please shed some light.

If it's really light-weight and self-contained it will be very useful for some embedded systems with a screen.

      $ldd bin/demo
    	linux-vdso.so.1 =>  (0x00007fff46f49000)
    	libSDL2-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 (0x00007f3587140000)
    	libGL.so.1 => /usr/lib/fglrx/libGL.so.1 (0x00007f3586f5e000)
    	libGLEW.so.1.6 => /usr/lib/x86_64-linux-gnu/libGLEW.so.1.6 (0x00007f3586cf2000)
    	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3586934000)
    	libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f3586647000)
    	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f358634a000)
    	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3586146000)
    	libpulse-simple.so.0 => /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 (0x00007f3585f42000)
    	libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f3585cf9000)
    	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f35859c4000)
    	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f35857b3000)
    	libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f35855a8000)
    	libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f35853a5000)
    	libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f3585195000)
    	libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f3584f8c000)
    	libXss.so.1 => /usr/lib/x86_64-linux-gnu/libXss.so.1 (0x00007f3584d88000)
    	libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f3584b83000)
    	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3584965000)
    	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f358475d000)
    	libatiuki.so.1 => /usr/lib/fglrx/libatiuki.so.1 (0x00007f3584640000)
    	/lib64/ld-linux-x86-64.so.2 (0x00007f3587469000)
    	libpulsecommon-1.1.so => /usr/lib/x86_64-linux-gnu/libpulsecommon-1.1.so (0x00007f35843e1000)
    	libjson.so.0 => /usr/lib/x86_64-linux-gnu/libjson.so.0 (0x00007f35841d9000)
    	libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f3583f94000)
    	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f3583d76000)
    	libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f3583b6c000)
    	libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f3583965000)
    	libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f358375c000)
    	libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f35834f5000)
    	libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f35832ef000)
    	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f35830ec000)
    	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f3582ee5000)
    	libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f3582ccb000)
    	libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007f3582a81000)
    	libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f35825b1000)
    	libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f3582385000)
    	libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007f358217e000)
    	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f3581f61000)

<comment><USER7> I have only experience with dear-imgui so far (mentioned in the readme), but nuklear should be very similar in its requirements. You basically just need a GL context (or other 3D APIs equivalent) to write a wrapper for, SDL is sort of overkill for this.

In my case I integrated imgui with my "weekend engine" Oryol, which has a very slim wrapper around 3D APIs, and I have this running in WebGL (via emscripten) and GLES2 on Raspberry Pi 2 (should also work on the original Pi). The resulting executables are small enough for most 32-bit embedded platforms (a couple hundred KBytes), and have a much shorter list of system dependencies. On Raspberry Pi it doesn't even need a window system, it runs straight from the Linux terminal and uses the Pi's EGL wrapper.

For instance here's the WebGL imgui demo (325 kByte): [http://floooh.github.io/oryol/asmjs/ImGuiDemo.html](http://floooh.github.io/oryol/asmjs/ImGuiDemo.html)

<comment><USER36> cool, checking it out now

</comment></comment></comment><comment><USER37> The author of Nuklear mentions it in the readme, but in case people don't spot it, there's another cool project in this family, imgui: [https://github.com/ocornut/imgui](https://github.com/ocornut/imgui)

</comment><comment><USER38> It would be nice if a GUI toolkit just targeted ncurses and you could further skin it to run in the browser, gtk or kde separately. a bit like react-native.

<comment><USER39> well, this library seems to be render agnostic:

[https://github.com/vurtun/nuklear/blob/master/nuklear.h#L133...](https://github.com/vurtun/nuklear/blob/master/nuklear.h#L1338)

So _in theory_ you could just write the rendering code for ncurses, browser, etc.

</comment></comment><comment><USER40> I'm glad they didn't name it "nu-kew-lar."</comment>


Bill Gates on iPad - Users are frustrated. They can't type or create documents - <AUTHOR> http://mashable.com/2013/05/06/bill-gates-ipad-apple-surface-windows/

<comment><USER2> I use Pages and Numbers for my iPad. When I want to do a presentation, I will use Keynote. I am not frustrated at all with my iOS devices. I can't say the same when I demoed a Windows 8 Laptop. I'm not a Windows basher as I use Windows 7 Ultimate on my laptops and look forward to Windows Blue. Bill should look into the frustrations of users of Microsoft before criticizing other devices.</comment>