STOMP – The Simple Text Oriented Messaging Protocol - <AUTHOR> http://stomp.github.io <comment><USER2> I'm a bit confused why people want things like this. I mean, a simple protocol is great. But why text? Text protocol for arbitrary data is always going to make things more complicated than necessary. And even "text" STOMP includes "NULL / octet 0" in the description.

Here are some thing that are complicated in text: escaping data, escaping line endings, type of line endings, escaping headers, encoding and string comparison, data delimitation, preallocating right buffer sizes, parsing long values, parsing numeric values, potential for confusion on what's opaque and what's parsable.

All of these are solved by even the most trivial binary TLV:

        4-byte tag, 4-byte length, lenth-bytes data

It's not going to be telnet-compatible, but it prevents so many issues from ever arising. If you need to debug it, it's trivial to even look at the hex dump of packets.

/rant (I don't understand the obsession with text formats)

<comment><USER3> I'm the author of original Stomp protocol. Much of what changed in 1.1 and 1.2 came from people smarter than me, so blame me for the ugly and them for the good.

Why text? Because I wanted to be able to debug it with netcat, implement minimal but acceptable clients by inspection of the wire, etc. More importantly, I wanted anyone else to be able to do the same.

At the time, AMQP was just starting to get steam, and it was a gross, exceptionally difficult to implement, binary protocol. (AMQP has evolved a huge amount from those early forms.) In looking for something better, the ease of using SMTP and HTTP and the fact that I often _did_ do them directly in netcat to debug or understand behavior, decided the direction.

Sure, SMTP, HTTP, etc., style protocols can be wonky at times, but the number of times I have in fact done them by hand is very high. Avoiding the need to break out Wireshark, and write a message packer on the fly as Wireshark only supports reading what comes across, makes using it, when you don't have a client yet, great. I've had people implement clients, from learning about the protocol to using the working client, _during_ a half hour talk about Stomp. They can do this because it bootstraps on knowledge of HTTP, and text is easy on humans (if more involved for computers).

This ease of examination and manipulation is the same reason that JSON is (approximately) infinitely more prevalent than protobuf, thrift, avro, messagepack, or even smile (which is the exact json semantics, but way more compact and fast to parse). The desperate perl hacker of XML fame is a very real thing, don't ignore the implementation and debug affordances provided by text-based protocols.

<comment><USER4> Hey Brian,

Just wanted to say thanks for Stomp, protocols that are simple enough to be easily reimplemented are definitely underrated.

The Python story for Stomp is not so great, especially working with Twisted (e.g. there I think stompest is the best option available). On profiling I discovered this module's parser was horrendous, contributing something like 30% to my runtime.

Had it been some binary protocol with a complex spec, I might have spent days reimplementing it, but producing a simple and fast parser took only an hour or two, and now my problem is solved.

For others complaining about Stomp, my reimplementation is 116 lines of perfectly testable code, and for a problem domain as simple as wrapping messages up in a few verbs, this is how it should be.

(Will be releasing tinystomp.py at some point, but it needs a little tidying up and documenting first!)

</comment></comment></comment><comment><USER5> When it says that it is difficult to implement the server correctly, I think it's an immediate red flag. We went through this with HTTP (nginx retrying non-idempotent requests anyone), and SMTP. I think the lesson learned that any future protocols should require really good specs and every implementation should follow them.

<comment><USER6> It's not saying it is difficult to implement the server correctly. It is saying "the server side may be hard to implement well". There's a subtle difference there. The reason is not protocol complexity or a poor spec. The protocol is simple and well documented. Rather it is an admission that implementing a queueing server can be hard, depending on the semantics you choose to implement, and certainly is harder than the client code.

The protocol is perhaps not the most efficient. It's primary benefit is the simplicity and level of support in various environments. Having Stomp support for a message broker is a great way of adding low-effort interoperability.

A Stomp based message broker was my first serious Ruby project a decade or so ago, and getting the server "right" for our use case took ~500 lines of code (using sqlite for queues marked persistent), which is incidentally about the same size as the spec.

</comment></comment><comment><USER7> The web site seems to lack a description of STOMP's purpose, or examples of how it would be used.

<comment><USER8> The "1.2" in the nav bar is a separte link, I missed it at first too: [http://stomp.github.io/stomp- specification-1.2.html](http://stomp.github.io/stomp-specification-1.2.html)

</comment></comment><comment><USER9> I don't understand why you'd want to replicate HTTP style interactions for this kind of job.

The headers are massive, take up most of the message and are overly verbose.

I know people fear binary protocols, but they really aren't something to worry about if you make the correct tools (after all, text is binary, its just there are a great many tools to read it.)

If you are serious and actually want to test your protocol/code, then you need to implement a parser that's useable. (either in wireshark or pipeable from netcat) You've done most of the work making the parse for the actual protocol, going the extra mile and wrapping it so it can take STDIN shouldn't be a terrible drag

<comment><USER4> Parsing a few bytes of extra text pales in comparison to sending anything across the network. For example in the time it takes to call an uncontended futex() on Intel Xeon, libxml2 can parse about a kilobyte of XML

</comment></comment><comment><USER10> I thought maybe there was a new version or something. How has the spec for a perfectly common technology which has been stable for several years got this many upvotes?

</comment><comment><USER11> Why wouldn't you try to make this as easy to parse as possible, just as prepend a size to the message at least, and possible to other fields internally too. Make the size a fixed width and it makes reading easier.

I deal with crappy protocols on a daily basis in the form of FIX and other exchanges. I hope to never have to deal with this one.

</comment><comment><USER12> I am the only one who is confused with this protocol: what problem does it solve and exactly what does it do?

</comment><comment><USER13> 2012 is latest release. Need to put (2012) in title, I think.

<comment><USER14> It's a spec. The fact that it doesn't change every month is a plus. It doesn't mean that a site or implementations weren't updated since 2012.</comment></comment>


Newsweek Statement on Dorian Nakamoto - <AUTHOR> http://www.newsweek.com/newsweek-statement-dorian-nakamoto-232092

<comment><USER2> They were re-launching Newsweek paper edition so they compromised their integrity for a big story. Saved us the trouble of figuring out if they had become an organization worth paying attention to. Nope.

</comment><comment><USER3> ""Newsweek has not received any statement or letter from either Mr. Nakamoto or his legal counsel. If and when we do, we will respond as necessary.""

</comment><comment><USER4> that is not a response.

</comment><comment><USER5> They stalk someone, use him to re-launch, send a media frenzy on his turf, he responds with a legally binding method and they pull this… prank? "Well, the letter doesn't have our postal addressed spelled properly: you see, it's not 'Newsweek, Clueless Town, NY' but actually (…) so that's factually incorrect…"

</comment><comment><USER6> Is there anything worth clicking? I'd like to avoid that if possible.

<comment><USER7> No. They're not saying anything at all.</comment></comment>


People Lose Their Employer-Sponsored Insurance Constantly - <AUTHOR> https://www.peoplespolicyproject.org/2019/04/04/people-lose-their-employer-sponsored-insurance-constantly/ <comment><USER2> The point of health insurance is to pay into a risk pool as a collective so that the small percentage of people who end up needing the largest percentage of health care, nobody dies or goes into monumental debt. This can be done via taxes but insurance is a private market solution which should in theory make it more efficient for the sake of maximizing profit.

So then if it's supposedly more efficient, why do I waste multiple hours dealing with insurance bullshit literally every few months?

Start a new job at a startup, need to go to trainings to understand the health care options and choose one, get new cards and website logins, update my info at every provider

New dentist is having difficulty getting my routine care billed to insurance and calls me every week asking for my insurance information again.

Wifes doctor didn't do something correctly when I updated insurance so now I need to call and deal with this big medical bill that I shouldn't have gotten.

Startup got acquired so I get another training for the new insurance options. And get new cards and logins and update with all providers again

Planning to get a surgical operation but nobody can tell me how much it will cost, doctor says "probably whatever your deductible is" except I have a high deductible plan so is it really going to cost me $2500?

Etc cetera. There's no end to the nuisance. If I could choose to just pay more in taxes (hell I'll pay way more than my current premiums) and never deal with insurance again, I would do it in a heartbeat.

<comment><USER3> I think your phenomena might be due to startups? Obviously this is a startup focused board so I am not saying this to mean go one way or another, but I ditched the startup, job hopping life a little while ago, and had to deal with "insurance bs" roughly two times in 7 years.

I am either the luckiest person alive, or maybe there is additional benefits not obviously well represented here to working for a stable, revenue producing organization, but I don't seem to encounter what seems to be the well- represented insurance pains documented here (probably a little bit of both, in my guess).

<comment><USER4> My partner has been employed with the same large international company for 8 years. She had an elected procedure done that is required by law to be fully covered by insurance. She had 3 calls leading up to the procedure with her health insurance company each time asking them if they were certain it would be covered 100%. I thought that this was overkill but she was worried to the point of being paranoid about it. They assured her each time she would not have to pay any money at all for anything.

The procedure was in December. After the procedure she received a 6-figure bill, which she then had to follow up with hours of phone calls back and forth to the insurance company, hospital, and doctor's office. They sent her a revised bill for somewhere around $8,000, and then another revised bill for around $4,000.

The insurance company says it's because the doctor coded the procedure incorrectly. The doctor says the hospital coded it incorrectly. She has had to file an appeal with the insurance company, and the only reason it looks like it will work out is because the insurance company records all phone calls and was able to get records of her original calls before the procedure asking if it would be fully covered. She has still been told to expect that they will deny her first appeal and she'll have to appeal a second time in order to get it covered. This has been causing her immense stress for the past 4 months as she does not have enough money to pay even the $4,000 bill out of pocket.

My experience is that your experience actually is extremely uncommon in America today. Most people who have to interact with the health care system beyond annual checkups have to deal with something like this.

<comment><USER5> She is lucky she is getting that even partially covered if she only got a verbal agreement. My insurance policy has a clause that anything they say over the phone is not a promise to pay. You have to call AND get something in writing to even be eligible for a dispute later.

</comment></comment></comment></comment><comment><USER6> When I quit my job in SF in November 2017, I had $1200 on my FSA. When I switched to COBRA, my FSA account kept its balance, but my VISA card associated with it immediately and unexpectedly stopped working. I was seeing a psychologist at the time and it was awkward when I didn't pay him right away because I thought it would be fine to try and fix my card and pay him the next day (which I did). It felt awkward enough to me that I stopped my therapy sessions with him, because I felt like it had become strained. Anyway, the company stopping my card from working was intentional. It was the same company and the same account but my card didn't work anymore and I had to go through the trouble to submit a claim, and they acted like this was by design that my FSA card would stop working when I quit and switched to COBRA.

Now I'm working remotely and am in a new state (Florida) and not sure I'll stay here long enough to switch everything to this state. I needed to get a fever checked out and ended up paying out of pocket because I was told over the phone that they accepted my out of state insurance, but when I got there in person, they didn't.

What a mess.

</comment><comment><USER7> Health insurance in the United States is a shit show. The Medicare for all that Bernie is proposing is a reaction to the inability of Congress to meaningfully fix the issue.

I personally would prefer a market based approach to fixing the issues with obtaining medical care, but Congress can't do anything because there's just too much money and influence involved.

<comment><USER8> Italy has a thriving market based private health care industry. You can call in and get prices and everything.

Just that it's in addition to the single payer system, which means the private one is cheap because the competition is 'free'.

As a % of GDP, Italy spends a lot less than the US in health care, and people live long and productive lives.

I mention Italy because 1) I lived there and 2) it's not some perfectly run place where everything works. It's not, and yet the health care is still better, overall, than in the US.

<comment><USER9> All other first world nations pay less. On average they pay less than half what the US pays. The fully socialized systems, like the UK, seem to trend lower in cost, as low as one third the cost of the US. But really, the takeaway should be you need universal healthcare with significant government cost controls on drugs and procedures, after that almost any arrangement of public/private administration works (but the caveat that it looks like the more private companies are in the healthcare mix, the higher the costs seem to run).

<comment><USER10> Without the U.S. subsidizing the drug research R&D, who pays for it?

You could fill notebooks with worthy, approachable hypotheses for any number of diseases that could show promise if given the funding.

But if everyone makes it law to cap prices - fewer scientists, labs, studies are performed.

The money has to come from somewhere.

I think countries take for granted the progress we've made. No progress is made without incredible intellectual efforts and monetary backings.

<comment><USER9> This paper gives pretty interesting breakdown of how private companies are increasingly bad at paying for it.

[https://www.ucl.ac.uk/bartlett/public- purpose/sites/public-p...](https://www.ucl.ac.uk/bartlett/public- purpose/sites/public- purpose/files/peoples_prescription_report_final_online.pdf)

One quote from the paper: In the last ten years, Pizer has spent US$139 billion on share buybacks and dividends compared to US$82 billion on R&D.

Edit: It shouldn't require massive profit margins to make the drug industry work for a basic human need like healthcare. Other sectors for human basics like the grocery industry, run on margins of 1-5%.

<comment><USER10> Food production is predictable. Finding a safe, effective treatment for Alzheimer's is not.

If you want thin margins, maybe government research wing can take its findings from idea to market (imagine waiting on a cure and that's your only hope?)

But you can't force a private company to operate on low margins by way of capping prices, you'll kill them. You can't taje away their ability to control their risks (cash flow). Drug R&D already has a huge failure rate and now the company can only take a 5% profit on the slight chance they've found something effective?

<comment><USER9> If you look at the paper, private drug discovery is creating drugs at a declining rate. I would suggest this is because those private efforts are much less research than development, and it's actually the public system that drives much fundamental research. And the drugs to market rate is in serious decline because of a the widespread application of increasingly austure public funding budgets for medical research causing an early pipeline bottleneck.

<comment><USER10> When you dump a link to a 60 page pdf and you're going to reference it, please list the page number and/graph you're referring to. I don't want to guess.

<comment><USER9> Sorry, Fig 1, page 15 is the data on drugs discovered per billion. Table 1, pg 18 shows some sample breakdowns of drug investments broken down between basic research and commercial development.

I don't necessarily subscribe to everything in that report, but I do think that modeling drug development in terms of a simple risk-reward model for the private drug industry needs further thought.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> One of the fundamental reasons why I haven't really bothered doing startups or running a small business myself is the radical uncertainty over health insurance for myself and my family. It's not just plain $$$ and career risk, it's the "suppose you will go bankrupt and your family has permanent medical issues now" risk. That game is for the wealthy or healthy single people

In addition, each insurance plan has slightly different doctors that sign on, so when there are changes, you might wind up needing to use different doctors or worse, health systems.

It'd be much better for me, personally, to require providers to all accept some US Public Single Payer plan (or whatever you call it) as part of opening a practice and seeing patients.

(I don't speak in any sense for my employer, who is in the health care space: this is just an engineer's personal musings)

<comment><USER12> > One of the fundamental reasons why I haven't really bothered doing startups > or running a small business myself is the radical uncertainty over health > insurance for myself and my family.

I joined a startup once, but it was in Europe, so these issues weren't even on my radar or the company's radar. With government healthcare and government unemployment insurance, it's a no-brainer. The only risk is to your lifetime earning potential. Stay at a solid job with a solid salary, or take a shot at the startup lottery. Your health or your family or your home are just never on the line by taking that risk.

The amount of time and worry you have to spend on healthcare for yourself and your family in the US is absolutely off the charts, and this cost is completely hidden! Time that companies have to spend on acquiring healthcare insurance for their employees is _wasted_ time. Time that employees have to spend on researching the insurance options their company is offering them is _wasted_ time. Time that you spend dealing with healthcare providers to ensure that you're covered by your insurance is _wasted_ time.

In Europe the time spent on this is, for the most part, 0. Companies don't spend time on this. Employees don't spend time on this. But noone in the US seems to regard this waste, this cost, as something fixable. Noone seems to think of the competitive edge this gives EU companies, or want to have the same competitive edge. Why? Why are US companies and US employees just completely resigned to the thought that healthcare just is a massive _necessary_ headache for everyone?

<comment><USER13> And yet the US is still way more entrepreneurial.

</comment></comment></comment><comment><USER14> Employer sponsored health insurance is an outpost of neofeudalism. Swear your fealty to a lord or go without.

<comment><USER15> Employee sponsored health insurance is a result of "centrally planned" economics - [https://www.nytimes.com/2017/09/05/upshot/the-real-reason- th...](https://www.nytimes.com/2017/09/05/upshot/the-real-reason-the-us-has- employer-sponsored-health-insurance.html) ... it has nothing to do with feudalism or even what employers wanted, but has a lot more to do with government officials who thought they could design an economy.

<comment><USER16> The reasons things start, and the reasons they persist, are often quite different.

The US doesn't seem to have subscribed to strongly-cenralised economic policy for nearly 70 years. And yet the employer-feudal healthcare system continues.

Preponderance of evidence suggests that dominant economic, financial, and power structures prefer it that way.

The origin story is an interesting footnote, no more.

<comment><USER15> While it's true the reason things start and persist are different, many would disagree about the level of central planning in the US, with healthcare being an example odd where there is a good deal of government control (everything from pricing of procedures, drug approval, and licensing to name a few). Whether that's a good thing is another question, but I think it's oversimplifying to conclude that the problem is all due to corporate feudal overlords and not at all due to government policy. Further, there is a lesson to be learned concerning unanticipated co sequences in the origin of the current system that we're in danger of repeating by having further government control of healthcare.

</comment></comment></comment></comment><comment><USER17> The fundamental problem is no body knows the cost of anything beforehand. Neither insurance company not doctors tell the cost of the care. Its really frustrating ! The first step to fix the problem is getting the cost of the care transparently. Without this i am not sure how any of the scheme works whether it is done by govt or private insurance companies !

<comment><USER18> This also translates to the cost for labor. How much your company is paying for insurance seems to have little correlation to how good your insurance is, so Company A could be paying an extra $5k per employee because they don't have a good HR department.

It also means that every job offer has to be examined not only for salary and culture, which are usually pretty easy to see; but also benefits cost. I've had offers that were an over 20% raise which would have all been eaten by insurance costs. I've looked at my "benefits cost breakdown" at similar companies only to see that one is paying $90k for me and one is only paying $70k, on similar salaries of around $60k.

These insurance costs are not something usually shared outside the company, and they are hard to get until the last stages of your job offer.

</comment></comment><comment><USER19> it's a shit show. I had "great benefits" at my last job accept when i needed them

1\. when something happened and i needed physical therapy it turned out my copay was like 6k so i just DIY my own therapy..

2\. when changing jobs i had a month gap, so i bought COBRA and 3 things went wrong.

        a. it cost $1300 for a month of coverage (even with a 2k deductible)

        b. since my last day was before a weekend, they actually covered my only until that same day next month, so i still had a gap of coverage (might be my employer but still sucks people have to be faced with this bs)

        c. when i did go to a routine physical healthcare provider still denied the claim and i was sent a full bill. after hours of calling it turned out they initially rejected it, but then accepted months later and i was left with _*some*_ expenses ?!

all this BS while dealing with expensive benefit package.. i can only image what self employed people must go through..

</comment><comment><USER20> I don't understand why the article uses labor turnover or health plan churn. Why would that be relevant to the original bolded premise that people like their better coverage sponsored by employers?

If I leave a job or get laid off, usually I'll get a similar job that has similar insurance. Now maybe you could argue that there's a big risk of an insurance gap or that something like COBRA is unfairly priced, etc., but that would have more to do with unemployment insurance and virtually nothing to do with the basic structure of health insurance.

When I "churn" in the insurance market, it is almost always going to be a super short-term switch from Insurance A to Insurance B (both via employers) where A and B are incredibly similar.

That seems perfectly consistent with saying that people love employer-provided insurance quality. The employers have to offer the same high quality insurance everywhere, or else people won't switch. As a result, they _do_ provide the same high quality insurance everywhere, to ensure insurance is not a sticking point that creates job movement friction.

Of course there are outliers offering bad insurance and classes of labor like Wal-Mart retail staff that get screwed by deliberately bad corporate actors, and I'm sure anybody reading this with a personalized anecdote will angrily try to refute me.

But in the aggregate, these are exceptions, and most people like their insurance for the most part and find that almost all possible employers (for them) offer such a nearly fungible set of insurance plans that they can churn jobs without significantly worrying that the insurance they like will be very different at company A vs company B.

There could be many arguments for nationalized healthcare, but this article seems pretty much wrong from its main thesis. People "keep" the private insurance they like all the time, because "churning" the coverage is not at all similar to giving up the coverage or making concessions or compromises for the next plan of insurance you accept from an employer.

</comment><comment><USER21> These numbers are super misleading. 72% were continuously enrolled, but 16% switched to a different employer plan! We don't know how many of those were the same employer or if the spouse just had access a better deal that year or what. Either way, 88% were covered by their employer plan. 12% is entirely different from 28%. We all have to do open enrollment, but that's entirely different from losing coverage and finding something new!

I'm totally on board with Medicare-for-All but we don't need smoke and mirrors and misleading statistics.

<comment><USER18> This is still important. I changed insurance with no gap, but it reset my fully paid deductible.

</comment></comment><comment><USER22> Healthcare finance is a mess in the US.

</comment><comment><USER23> Pelosi is a moron who doesn't even know how the current insurance system works. Of course people lose their insurance. And ACA insurance often doesn't cover the same things as the employer-based insurance. If people need to get on Medicaid, they need to wait months before it starts, months without coverage. Everyone needs healthcare and few people can afford to pay the exorbitant costs of it in this country. And of course, if you get injured on the job, you have to fight a whole different system that shouldn't exist either. Of course Pelosi has her own insurance and plenty of money so like so many rich assholes in congress and elsewhere doesn't care and doesn't want to improve healthcare coverage for the rest of us. Let us get sick and die. Even with insurance this is often the case. Pelosi's a moron on this issue and many others. She's almost as clueless as the Republicans who get off on kicking people off of Medicaid and watching them get sick and die. How can the US even be considered a developed country anymore when we let our own people get sick and die so a few rich assholes can get richer?

</comment><comment><USER24> Am I correct in understanding that Medicare for All plans to abolish private insurance? I prefer there be a system where you can get private insurance if you want, but if you go without you are automatically on Medicare.

</comment><comment><USER15> One thing this article doesn't discuss: at least some of the times where I "lost" my employer-sponsored insurance (either because I switched jobs or because my start-up decided to switch providers), it went to something better than what I had before, and most of the time it was a change that was a matter of indifference (from one major plan provider to another where everything was pretty similar). In most universal health care proposals I've seen, "leaving," isn't really an option, you're just stuck with The Healthcare Option.

Whatever the merits of the more general arguments for or against, it seems like we should at least not put a finger on the scale.

<comment><USER25> It is highly unlikely that you will be left with no options. Under most universal health care systems, private insurance plays a complementary role[1]. Also, if we go the public option route, it would compete against, rather than replace, the private insurance market.

[1] [https://www.vox.com/health-care/2019/2/12/18215430/single- pa...](https://www.vox.com/health-care/2019/2/12/18215430/single-payer- private-health-insurance-harris-sanders)

</comment></comment><comment><USER26> People [in the US] … ;)

<comment><USER27> As much as your comment might be taken in the wrong way, it _is_ important to point out first world countries have this sorted. I simply don't get it. When did patriotism become about military might and waving flags instead of making sure your fellow countrymen don't live in agony, fear, and poverty?

<comment><USER28> I'd say about 1946, or whenever the cold war is said to have officially begun. Or maybe even earlier during WW2.

That being said the sentiment was never a good one, and we do need to move on from it.

</comment></comment></comment><comment><USER29> If you want a good example of government supplied health insurance, go to your local VA hospital, and see if that is the kind of health care you really want.

<comment><AUTHOR> The goal is for government-funded, not government-run. At least in the context of M4A.

</comment></comment><comment><USER30> Medicare-for-All is some sort of "far left" fantasy in the United States, but single-payer healthcare is center-right dogma in every other developed country. I have no idea why this is so hard for the American right to grasp: single-payer healthcare is a social program, but it's not the same as socialism. We aren't trying to steal the means of production from you in some sort of revolution, we just don't want people to die from preventable things. It is entirely possible to have a single-payer healthcare system alongside a thriving capitalist economy. This sort of foundational public service actually makes economies better, not worse. It's not a burden on the market to have healthy workers.

<comment><USER31> "single-payer healthcare is a social program, but it's not the same as socialism"

American politics is geared towards appealing to the extremes. Social programs are "socialist" and get connected to the Soviet Union, cuba and Venezuela. If you say something that's even slight politically incorrect you are immediately labeled as a "racist" that should be removed from your job and all public discussion. There is no interest in discussing problems and finding solutions. It's all about anger.

<comment><USER32> Couldn't agree more.

</comment></comment></comment><comment><USER33> Yes, people do lose their insurance constantly when they switch jobs...and then immediately sign onto their new plan. Is the argument that switching insurance plans is stressful? What's stressful is remaining uncovered. Switching plans is hardly comparable to the transition to a Medicare-for-all program.

<comment><USER34> > Yes, people do lose their insurance constantly when they switch jobs...and > then immediately sign onto their new plan.

Lets say you payed for insurance, but were healthy for the 90s. So ~10-years of paying insurance. Around 2005, you are diagnosed with Diabetes, so your insurance pays for your care.

Around 2007, the recession happens and you lose your job. You immediately find a new job, but you need to get new insurance. Diabetes is now a "pre-existing condition", so your insurance no longer covers your condition.

Its important to recognize that changing health-plans is a regular event, that shouldn't punish people with chronic conditions. Diabetes is lifelong, once you get it, you live with it for the rest of your life. Insurance companies don't want to pay for that kind of issue. With all talk about "Repeal and Replace", its important to recognize the tradeoff.

As long as "pre-existing conditions" are banned in the USA, I don't think its a big deal to lose employer sponsored health care (at least, compared to pre- Obamacare). We should build a world where it is easy to lose (and regain) health coverage... compared to the pre-Obamacare world where it was a big risk to lose coverage. Hopefully laws of the future make it easier to switch health care plans without problems.

<comment><USER35> If you find a new job and you're eligible under group insurance, the insurance company can't deny a claim under pre-existing conditions. This was true before the ACA. What the ACA changed was that insurance companies couldn't exclude treatment based on preexisting conditions if you go on the open market.

<comment> pickle-wizard Pre-ACA group plans could deny preexisting conditions for a time period equal to the time that you were uninsured.

When I switched job I would get a letter from previous insurance company stating the dates that I was insured. Once I actually had to provide that to the new company.

<comment><USER35> It seems like we are both partially correct. They could deny you for up to a year for a pre-existing condition prior to the ACA.

[https://twocents.lifehacker.com/you-could-be-denied-pre- exis...](https://twocents.lifehacker.com/you-could-be-denied-pre-existing- condition-coverage-by-1826865657)</comment></comment></comment></comment></comment>


Redis 4.0 - <AUTHOR> https://groups.google.com/forum/#!msg/redis-db/5Kh3viziYGQ/58TKLwX0AAAJ <comment><USER3> _" 9) Active memory defragmentation. Redis is able to defragment the memory while online..."_

I'm so amazed that this is a thing.

<comment><USER4> Memory fragmentation is largely related to the allocator you're using (ie: glibc malloc, jemalloc, tcmalloc) and previously it was up to the OS to manage this (ie: freeing up unused memory).

Now with active memory defragmentation things are a bit more pleasant, specifically with high delete load actually freeing up unused memory in a timely manner without impacting performance too much.

Previously, to fully recover unused memory, you would have to restart the Redis server. Obviously this is not feasible but when Redis is using >50% more memory on a 120GB machine than it should then you will have to consider this an occasional housekeeping option -- now, as mentioned, this ridiculous task is no longer necessary.

<comment><USER5> 120GB on a single thread, yeah. Redis has been abused for quite some time but 120GB is way out of reasonable reach for current CPU arch if you use a single core only (even if you switch off hyper threading)

<comment><USER6> Call me a slowpoke, but I wasn't aware that Redis was single core!

<comment><USER7> It makes it great for storing distributed locks, semaphores, and thanks to Lua scripting it can store/update cache invalidation lists - <USER2> [https://github.com/Suor/django-cacheops](https://github.com/Suor/django- cacheops)

</comment></comment></comment></comment></comment><comment><USER8> @antirez: Congrats! Are you going to modularize disque now that v4 is ready?

<comment><USER9> Yes, one of the top items in the Redis 4.2 roadmap is to port Disque as a Redis module, so the steps are: 1) Implement a Redis Cluster modules API (I've already some draft design, basically there are low level stuff to enlist nodes, broadcast messages, send one-to-one messages, and have callbacks called when we receive a message), and then port Disque as Redis module on top of such API, so that we can both validate that the Cluster API is good enough with a real project, and can make Disque a first citizen of the Redis ecosystem without all the code duplication, that in the end, made the project extremely hard to sustain. Thanks.

<comment><USER10> I look forward to Aphyr scrutinizing it. No disrespect to you, his posts are always fun to read and show how hard it is to get this stuff correct.

</comment></comment></comment><comment><USER11> If you want to try out some of the modules already available: [https://redis.io/modules](https://redis.io/modules)

</comment><comment><USER12> Maybe with the new modules support there will emerge some explicit way to do robust worker/job queues? So you don't have to remember your BRPOPLPUSH/LREM dances (or whatever it is) just so.

<comment><USER13> Antirez has talked about moving Disque to a Redis module, which should solve that problem neatly. I'd love to drop our RabbitMQ dependency and move queueing into Redis.

<comment><USER14> Why?

<comment><USER13> One less service to manage, plus RabbitMQ's options for dealing with network partitions are all terrible. If you want to run a RabbitMQ cluster, you don't have any option that avoids data loss.

<comment><USER15> Can you even avoid data loss with partitions in a AP system like RabbitMQ?

<comment><USER13> RabbitMQ is not strictly an AP system. Its clustering functionality supports several different modes for handling partitions (all of which allow for data loss) and is CP. Federation, which you should use if your network between nodes isn't super reliable, is AP.[0]

What I'd like to see is clustering with support for merging data between nodes. You'd probably end up with duplicates, which I'm OK with, but you'd avoid the data loss that happens with other modes like Pause Minority, where messages get dropped on rejoining a cluster.

[0]: [https://www.rabbitmq.com/distributed.html](https://www.rabbitmq.com/distributed.html)

</comment></comment></comment></comment></comment></comment><comment><USER16> Redis Cluster connecting to nodes via DNS instead of IP would vastly simplify deployment on K8s.

<comment><USER6> How do you solve this problem? Can you use headless K8S services for that?

<comment><USER16> You can use a StatefulSet which gives a fixed hostname per pod. Then you can have a sidecar pod that monitors the cluster, discovers the IPs of all pods, and uses redis_trib to create and maintain the cluster. It's a hassle to make it robust though.

<comment><USER6> Don't see why you would do that, instead of a headless service.

</comment></comment></comment></comment><comment><USER17> Is there a Redis PPA for Ubuntu 16.04 that is supported by the redis team?

<comment><USER18> Redis is of the the very few applications , that I install manually almost every time.

trick is to use the utils/install_server.sh

<comment><USER11> hey, I wrote that little script years ago, glad to hear someone (besides me) is still using it! :)

</comment></comment></comment><comment><USER19> Anyone know when we might see this on AWS (Elasticache)?

<comment><USER20> I don't like the Elasticache offering of Redis at all. It is severely limited if you are not just using Redis as a cache. There is no way to scale up/down the size of the node without putting it down(this is possible if you run it on EC2 as well as you have access to commands related to replication that are not allowed on Elasticache). We have had master restarting instead of failing over to slave and in the process coming back with no data. Even the snapshot is only taken once in a day.

</comment></comment><comment><USER21> LFU policy sounds really interesting!

<comment><USER9> Thank you, there is more info in this blog post: [http://antirez.com/news/109](http://antirez.com/news/109)

<comment><USER22> Awesome write up. I can't wait to try out LFU with our usage. I have a suspicion that our cache hit ratio will see a nice bump.

I've said this before and I'll say it again...thank you for all you do!

</comment></comment></comment><comment><USER23> It seems it even supports nearest search for lon/lat points by default... Quite nice since most RDMS don't even support it be default.

Although I'm curious to know what algorithm it uses for nearest search, it doesn't talk about it in the doc.

I don't really understand what redis should not be used for, I guess it's not for complex queries? Conventional RDMS really seem to belong to the hard disk drive age. So the difficulty resides in having well designed data schemes.

<comment><USER24> I adore redis, I use it for tons of stuff, but I still like to keep my single- point-of-truth for critical data in an ACID, transactional relational database.

I frequently denormalize that data INTO redis so I can answer certain classes of queries quickly. I'm also very happy with redis for caching, rate limiting, inter-process-communication, distributed locking and tons of other fun use- cases.

</comment></comment><comment><USER25> Any news on when this will be on Azure Redis Cache ?

[https://azure.microsoft.com/en- us/services/cache/](https://azure.microsoft.com/en-us/services/cache/)

<comment><USER26> Wouldn't expect it in anything less than 3-6 months tbh... depends on how anxious MS is to git this into place.

</comment></comment><comment><USER27> Interesting coincidence (or maybe not...) Redis was discussed on the Floss podcast that I listened to earlier today and now I have an inkling of what Redis is. My first exposure to Redis was to ponder where it came from after I tried to run Gitlab on my puny (J1900, 4GB RAM and spinning rust) file server. It was spectacularly non-performant with most page loads timing out. I suppose it was because Redis had insufficient RAM for operation. Redis may be scalable toward large busy systems but seems less so in the other direction. I thought it would be cool to have a real Git server but this one was not it.

During the podcast the Redis guy mentioned that 4.0 was on the verge of being released.

<comment><USER28> The issues you had may have come from GitLab not having enough resources available to handle everything, as opposed to Redis itself; anecdotally, I have an application with a couple thousand keys in it that only uses ~5MiB of RAM.

<comment><USER29> Yeah, I'm in the same boat - I have a redis I use for caching auth tokens and some other values for a small service, and it doesn't take much ram at all. (5-10 MiB)

</comment></comment></comment><comment><USER30> I've said it before and I'll say it again: I am _so_ smitten with antirez (and redis)! One of my favorite projects for sure.</comment>


How I reverse engineered my bank's security token - <AUTHOR> http://valverde.me/2014/01/03/reverse-engineering-my-bank%27s-security-token <comment><USER2> Think about it for a moment. He did all this (impressive) work just because the application that the bank provided sucked.

Now, once he writes a better app, what do you think the bank will do? Hire him (or buy the app), or fight him?

How much effort do we collectively waste because of moronic organizations that force their crap upon us, that we cannot escape from? (You can go to a different bank, but what if they all uniformly suck?)

<comment><USER3> I don't really agree with the description of the app: "the application that the bank provided sucked". What's the reason for this? The only thing he didn't like about the app was that when he reflashed the phone he had to re- register it. ("calling the bank every so often after changing ROMs, resetting or changing phones") Does that app suck? I don't think so, you should reauthorize the app on every new device and if reflashing your phone makes it look like a new device, that's not really the app's problem, is it?

> what do you think the bank will do? Hire him (or buy the app), or fight him?

Ignore. Most likely they didn't write the app, but rather contracted the work to some company that specialises in writing apps. There's no reason for the bank to hire him. He didn't produce any better app either.

I'm all in for a good rant about companies preventing reverse-engineering and modifications of software, but I really don't believe this is the right article for it.

<comment><USER4> He was able to reverse engineer the whole process. The bank's app definitely sucks.

<comment><USER5> Actually, being able to reverse-engineer and thus also being able to audit the processes and protocols being used is widely regarded to be a good thing, improving overall security standards.

</comment></comment></comment></comment><comment><USER6> Wonderful work, and thank you for documenting the experience. From the title, I thought this would be a story about decoding a banking website's cookies and gaining access to other peoples accounts, or something similar. I was quite surprised to see that your bank did basically everything right. I was also surprised that you went so far as to implement an embedded clone. Very cool!

P.S. Consider yourself lucky to have such a bank. Here in the U.S., our major banks do not take security seriously by any stretch of the imagination (they have little incentive to).

</comment><comment><USER7> This post had me guessing, but good work. First I saw the card with codes and thought you'd be showing that they weren't randomly created. But then you went on to the app -- and from the "What you'll need" section, when I saw the decompiler and the rest, I thought, "I know what comes next," but again I was surprised. You went above and beyond with the decryption of obfuscated error messages, etc. I could have guessed that it was OATH TOTP, as that's how these apps should work. Congrats on getting there from the source code, and indeed it's too bad they didn't retain compatibility with Google.

To fix the bug you mention -- root access from phone -- perhaps you could use something like Yubikey Neo loaded with ykneo-oath. I was searching the code for ykneo-oath (it's a java applet for the small key) to see where the timestamp was used for the dates, but it appears to be part of the YubiOATH app: [https://play.google.com/store/apps/details?id=com.yubico.yub...](https://play.google.com/store/apps/details?id=com.yubico.yubioath) So you'd have to modify the app source (it's on github). The advantage, however, is that your secret isn't stored on your phone and vulnerable to root apps. Instead, your secret is on a mostly-offline key inaccessible from your phone. There's a YouTube video on how it uses NFC to get that OTP from the Yubikey when you need it. In case you're somewhat extremely paranoid, this might interest you. :) For the truly paranoid, you've found a way to disable account recovery methods while mixing time-based and counter authentication mechanisms ;-)

<comment><USER7> Oh -- and just don't put your phone in the same pocket as your YubiKey! ;-)

</comment></comment><comment><USER8> While I don't know about the situation elsewhere in the world, here in Germany most banks retired the single use codes (called TANS or (if indexed) iTans) quite some years ago for being insecure.

Most online banking will now require a code created per transaction that is 1. either send to you via text on your mobile phone (and is thus prone to phone malware) or 2. is generated using an external device and the chip on your banking card[1] (a true two factor authentication). Both system will show you the exact details (target account, amount to be send) before confirming the transaction. A virus on the computer is not sufficient to hijack your account.

Just out of curiosity: What security measures do your banks employ and do they allow you to upgrade to a higher security level?

[1][https://www.ksklb.de/privatkunden/banking/chiptan/chiptan_fa...](https://www.ksklb.de/privatkunden/banking/chiptan/chiptan_faq/FAQ- TAN-Generator.jpg)

<comment><USER9> For my bank (Nordea in Finland), it's numeric user id + single-use 4-digit code (on a physical card; they automatically mail you a new one when you're starting to run low on codes) to log in to net banking. A random one of ~30 multi-use verification 4-digit codes is then used to confirm a transaction.

In addition, the Nordea mobile app uses a request to activate a single 4..8-digit password for read only access to your information. (I may have reverse engineered the app a tiny little bit to find this out. The underlying HTTPS API is, as one might imagine from a banking app, terrible.) Beyond that, you still need the above login procedure to do writes (transactions) with the app.

<comment><USER10> Nordea's finnish service was the simplest, most comfortable service of all the (4) european banks I've tried.

And I liked that their service is not fancy for fanciness' sake. (In terms of the way the website looked and functioned)

Not anymore a customer, unfortunately.

<comment><USER9> I agree. The competitors are starting to pass Nordea wrt technology though -- I've only heard good things about OP-Pohjola's Pivo app ([https://play.google.com/store/apps/details?id=fi.op.android....](https://play.google.com/store/apps/details?id=fi.op.android.lompsa)), and apparently Danske Bank has some sort of analytics built-in to their webapp nowadays too.

That said though, I'm so happy Nordea finally added free TSV export of bank statement data. I rolled my own analytics script in Python based on that... :)

</comment></comment></comment></comment><comment><USER11> Just another example of a proprietary implementation tweaking a de-facto standard / well-known algorithm (RFC 6238) just enough to be annoying.

Fresh in my mind is the Wii U controller reverse-engineering presented at 30C3, where the WPA-PSK handshake protocol was tweaked by performing bit- rotations on the resulting keys.

</comment><comment><USER12> A good lesson for those of us who have had the idea of building a similar app to generate one-time passwords. Now we have a better idea of the minimum that needs to be done to build such an app securely. Thanks.

<comment><USER13> What exactly does this give you as a minimum? If you distribute code to a client, they can look at it. The only way to prevent this is relying on some sort of "trusted hardware" model or not distributing code.

</comment></comment><comment><USER14> The only point of these token generators is to provide a stream of tokens, so that if the generator is cloned (which is trivial), that can be detected. That's it. As far as I can tell, this attack does not prevent the server from detecting a cloned token.

(To do that, you would have to install a new client on the victim's device that will increment its counter and tell you the counter when you ask.)

<comment><AUTHOR> This specific token is time-based, so a clone would not be detected.

On the other hand, counter-based tokens as you described them do exist, and it would indeed be simple to detect if one of those was cloned.

I wouldn't even call this an attack, given that you would need physical access to a rooted device to carry it out.

<comment><USER14> Ah, time-based tokens are basically against adversaries with physical access to your time-based token. Good against password guessers / leaked password databases, however, which is a much more realistic attack these days.

<comment><USER11> OTP tokens usually don't protect you against server database compromise because they're completely symmetric. The server has a copy of the seed/key stored in the clear. OTPs really only protect you against key logging

<comment><USER14> I mean for the password reuse case. You use the same password for example.com and Gmail. Someone steals the example.com password database. They still can't log into your Gmail account because they don't have your second factor.

</comment></comment></comment></comment></comment><comment><USER15> Thanks valverde, quite interesting work, and very well written.

</comment><comment><USER16> Dark grey text on a light grey background. :(

Apart from this, awesome read.

</comment><comment><USER17> It looks like this is down, does anyone have a mirror? It's frustrating to read all the gushing comments and not be able to read the post!

<comment><USER18> [http://web.archive.org/web/20140104041807/http://valverde.me...](http://web.archive.org/web/20140104041807/http://valverde.me/2014/01/03/reverse- engineering-my-bank's-security-token/)

</comment></comment><comment><USER19> Interesting

I suppose my bank token uses the same structure and produces a similar code (but I haven't reversed engineered it though)

</comment><comment><USER20> A very interesting read. Also, I think I saw you on facebook's hackathon this year!

</comment><comment><USER21> Why obscuring error/debug messages? Couldn't production just go without it?

</comment><comment><USER22> he is going to get a very awkard phone call from the bank...

Some years ago I stumbled with something similar on a webpage, posted it on reddit, and the next day the IT manager of the company called me... it was one of the most embarrassing days of my life.

Lesson: don't mess with other peoples work just because you can...

<comment><AUTHOR> I recognize this as a possibility and I would definitely take it down if the bank requested it.

On the other hand, if anything, I exposed that they did a good job. They could have rolled out their own crypto, or some flawed form of code generation, in which case I would have disclosed it to them through proper means. But they adhered to standards (TOTP, RFC6238) and protected their data as well as possible. This article should be seen as praise.

Then again, corporations aren't always that understanding, which is why I would be happy to comply.

<comment><USER23> I agree. If anything, reading this analysis would make me feel /more/ comfortable about the security of this bank's software, not less It seems that they did pretty much everything right, if a bit strangely, in some cases.

TOTP and co. require a private key, just like all crypto. If you have that private key, bad things happen. This is not exactly news at 11.

</comment></comment></comment><comment><USER24> Wow, that's commitment!

</comment><comment><USER25> Article is 404 inside of 5 hours. That's fairly swift. (assuming OP didn't remove it himself)

<comment><USER7> I do not see a 404, perhaps it was temporary?

</comment></comment><comment><USER26> Well explained, nice read!

</comment><comment><USER27> Just one word. Wow!

</comment><comment><USER28> Nice work!

</comment><comment><USER29> dat hax</comment>


Flexbox Cheatsheet Cheatsheet - <AUTHOR> http://jonibologna.com/flexbox-cheatsheet/ <comment><USER2> Great cheatsheet; I'll definitely use it. Don't know if you're a react native developer or not but it would be neat to annotate these with info about which properties are supported by react native's layout, since it's not a 100% clone of flexbox.</comment>


Basic Backbone.js input validation - <AUTHOR> http://abernardes.github.com/2012/05/08/backbone-js-input-validation.html

<comment><USER2> Great example! Although it looks like if you click Add Task and then click cancel it adds a value of "null".

<comment><AUTHOR> Hi there, thanks for your input. I've made a follow up post about the fix. Here's the link in case you're interested: [http://abernardes.github.com/2012/05/09/tdding-with- backbone...](http://abernardes.github.com/2012/05/09/tdding-with-backbone-js- and-jasmine.html)

Cheers, Andre</comment></comment>


The Differences Between Android and iPhone Users at Hunch - <AUTHOR> http://daringfireball.net/linked/2011/08/19/hunch-iphone-android

<comment><USER2> In other words 100% of Apple users are more likely to ignore disclaimers and believe what people tell them if it sounds pro-Apple. :D

 _Hunch does not evaluate or guarantee the accuracy of any advice or content on the Hunch site. Full disclaimer_

</comment><comment><USER3> It is always interesting to see how people interpret statistics.

I would describe Android users as a younger demographic who live spread out across cities, suburbs, and the country. I would describe the iOS users as middle-aged rich women who live in cities.

None of the other data is really that meaningful when you start with a such a different base. Are rich city dwelling women more likely to identify as politically liberal? Obviously. Are young people more likely to make less money? Again, this is not rocket science.

The follow/lead thing is highly amusing. In my experience the largest "I lead" responders in a survey are people who are uncomfortable thinking of themselves as anything other than unique snowflakes but this has no bearing on actual lead/follow behavior, it may actually be inversely correlated.

Disclaimer: Android phone user, and iPad user/dev.

</comment><comment><USER4> I dislike Gruber so much that I can't read that lede as anything other than antagonistic.

</comment><comment><USER5> Nothing surprising here. Cheaper phones/plans = higher % of lower income ownership.

</comment><comment><USER6> Note the wording: "27% more likely to SAY they tend to lead" - yet they follow Apple like sheep.

Have you looked across the table in your Starbucks lately? Guess what, the person on the other side has the exact same iPhone as you do. And it is not because they are trying to imitate you, either.

<comment><USER7> Avoiding a product just because it is popular is another kind of sheep behavior.

People are free to buy whatever they want without being judged for it. Please stop being a troll.

<comment><USER6> The whole article is kind of a Troll, isn't it?

</comment></comment></comment><comment><USER8> TFA: <http://blog.hunch.com/?p=51781></comment>