Hacker News new | comments | show | ask | jobs | submit | jat850's comments login

To you and the others curious about why the reply button doesn't show up, there is a buffer period after a reply appears before you can reply to it, to mitigate flame wars and such. It's usually a few minutes.

Uhhh does that mean we just found a bug?

If you mean the fact that you can circumvent this, then I'm not sure. It's possibly intentionally left in so that more experienced users have a way around that limitation.

Chicken Licken is another name used for Chicken Little in some variants of the tale.

-----


Completely different definition of the word. Not applicable or comparable.

-----


This one, however, does seem to be relevant:

# assertTrue is retarded, use the normal assert statement assert L

https://code.google.com/p/chromium/codesearch#chromium/src/t...

Along with:

// TODO(darin): Fix this retardation! return buf_->RemainingCapacity() <= (2 * net::kMaxBytesToSniff);

      // HACK: I'm at a loss about how to get the syntax checker to get
      // whether a template is externed or not. For the first pass here,
      // just do retarded string comparisons.
      if (TemplateDecl* decl = name.getAsTemplateDecl()) {
        std::string base_name = decl->getNameAsString();
        if (base_name == "basic_string")
          whitelisted_template = true;
      }

And a bunch of french language files

-----


Those examples you have picked fit the same problem as the initial argument, yes. "retard" in French means "slow" or "late".

-----


So hilarious that someone actually searched the codebase for 'retard' and then assumes it's a slur in french too.

-----


Your reply rubbed me the wrong way, as it implies that being poor, unemployed, or homeless are by definition failures. Perhaps you didn't intend that (or perhaps you do believe it). Not looking for a philosophical argument - just stating my opinion contrary to what yours comes across as.

-----


How is being homeless not a failure on multiple levels? You can be poor by choice and happy with it, I agree. But is any sane person homeless by choice? Not traveling, hermit, not able to function in society, or many other cases. Just wanting to live somewhere and able to do work, but not having a home. To me that seems like a failure on multiple levels: country - global situation that allows people to be homeless, local - no community support or path to employment or investment into people, self - well... unless we give some income to everyone, and you can't claim benefits for not being able to work, you're expected to work for a place to live.

Unemployed is an artifact of the economy. I'd like to be successful enough to be unemployed, but rich and not homeless.

-----


It is a failure on many levels - systematic ones, mostly. But if you read OP's post as not singling out the failure as being personally and solely responsible for their plight, rather than as a systematic failure, then we might simply differ on reading it. Donating money to combat homelessness at a systematic level is (in my opinion) probably a good thing. I just didn't get that sentiment in what I saw, though I allow for the (frequent and possible) chance that I am wrong in my interpretation.

-----


Empathy failure. I hope if you ever screw up really badly there is someone else to give you a hand.

-----


This is exactly what I wrote. Not having a community-level support for cases of "you screwed up badly" is a failure. Same for no benefits when "life screws you up badly". Not sure where you see the empathy failure.

-----


Sorry - replied to wrong comment - should have been the top-level comment by ams6110. Absolutely not aimed at you.

-----


If one takes a very mechanical world-view, then yes, you could say that those properties are a signal of failure. Failure to plan, keep a job, save money, etc.

Being very risk-averse myself, I would constitute all of the above under normal situations to be a failing on my part. Abnormal circumstances obviously change the dynamic a bit as they're almost always unavoidable. E.g. natural disasters, war, large-scale riots, etc.

-----


I agree that risk aversion, planning, and other factors are good preventative measures to avoiding homelessness. The contrary case I can think of is the child who is homeless because the parent is. I cannot rightfully view them as having failed.

-----


That is possibly one of the coolest things I have ever seen. I could spend hours looking through this.

-----


I don't want to challenge too many points of your post here, but I have a couple questions:

"This example also brings up another typical point of confusion in building distributed systems: people actually want "ordered processing", not "ordered delivery". The physical receiving order does not matter: your friend will not attempt to follow instruction #2 without first following instruction #1. If instruction #2 is received first, your friend will wait for instruction #1."

How do you handle that, practically speaking? In say, any system that operates at a scale where you might have thousands of messages per second. One concern I have with holding onto instruction 2 until instruction 1 arrives is, what if it never arrives? The system is blocked, isn't it?

-----


The client is blocked but the producer is not. As soon as the client gets #1 it can process #1 and #2.

Here's a real world implementation discussion of this sort of stuff: https://github.com/couchbase/sync_gateway/issues/525

-----


How big do you make the receiving queue on the client's side? How many instructions past #1 can it store while waiting for #1?

-----


Yes, the consumer will be blocked for that particular transaction. The consumer can happily process other transactions in the meantime.

It's important to note is that no matter how you want to slice it, if instruction 1 never arrives, somehow you need a protocol to re-request it from upstream until you get it.

Whether that protocol lives in your middleware (e.g. an "at least once" message queue implementation that buffers messages and delivers them to your application in order) or in your consumer application logic (e.g. the application buffers messages and can send a request for a missing message over another channel), something is going to have to keep track of these things and buffer messages in the meantime.

This is why message queue middleware appears so convenient -- your application never has to see any of this complexity. I say appears because message queues can't do at least 3 things:

(a) It can't understand your application message processing order (which is NOT the same as your physical sending order): notice that how the message queue middleware and application determine if a message is missing are at fundamentally different levels of abstraction. The middleware can, at best, use e.g. sequence numbers or checkpoints to figure out a message is missing. An application has higher-order business knowledge about what the messages mean and so can determine if a message is missing much more intelligently. An application can also happily process other valid sequences of instructions without waiting for all preceding but possibly unrelated messages (e.g. it can accept an order for client A while still waiting for client B's full order to come through).

(b) Message queues DO drop messages so again without a higher-level protocol across the transaction sequence to manage this you will have a problem if you require all messages to be processed.

(c) You can't easily replay an event e.g. because your consumer stuffed up processing. It's true that many message queuing implementations can keep a duplicate journal and allow you to replay from there, but this is probably an opaque data store. You can probably inspect the message, but ultimately you will end up writing application-specific logic to figure out which message to replay, whether the copy of the message is retrieved from the message queue system or from upstream.

At that point, the end-to-end principle [1] applies and you start to wonder if all that intelligence in messages queues is a waste. I'm personally looking at moving over to using DDS for data distribution and RPC over DDS to do replay and reconciliation between publisher and consumer.

[1] http://en.wikipedia.org/wiki/End-to-end_principle

-----


I don't know much about Facebook's current offerings, but the answer to your question might depend on what other ubiquitous services they offer now or in the future. Maybe they'll become equally entrenched in the online payment market, or things of that nature. I don't and can't know if that will leave them at their 235B market cap, or if it will be lower or higher.

-----


Your last sentence was heart-breaking. Whether or not the list applies to you - whatever you've gone through - and whether you are somewhere along that autistic spectrum - none of them define you on their own. You are not the sum of checkboxes on a list. You're a person who has survived a series of challenges. Keep surviving and keep being a person, not a count of checkboxes.

-----


You may not be aware that in some jurisdictions (Quebec is an example), marriage is not a sufficient legal reason to change your legal name, yet most people informally identify with a spousal name change. It would seem like an overstep for Facebook to regulate against this by policy. That's only one of many, many examples where people shouldn't be forced into using their legal name simply BECAUSE it's their legal name.

-----


Would Apache Samza fold in here better, perhaps?

-----


I don't know much about Samza, but I don't think stream processors are what we (I work with the author) are looking for. We don't really have a lot of "stream processing" to do, and aggregate functions are usually computed on-demand. Also, still have to put results from the stream process somewhere, right? Back into Kafka is something people do, but we still need indexing capabilities. As the post mentions, we use MySQL for time series storage, but we also use Kafka in front as a durable log.

-----


You're welcome to email me if you like - it's in my profile. Kafka and Samza are intended (generally speaking) to go hand in hand. Samza is a re-imagined datastore that Kafka can shuttle data into. I've been investigating Samza quite heavily specifically for time series data storage. I'd be happy to share thoughts.

-----


While I'm not using Samza, Spark Streaming also works pretty nicely in this case, although it is not so focused on keeping state (it can, though, using the checkpointing system and the `updateStateByKey` transformation) and thus might not perfectly stable if you require to handle failures without reprocessing.

-----

More

Applications are open for YC Summer 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: