2,803 karma · joined July 22, 2012
DHS is arguably a much more appropriate home for the Coast Guard than its previous department, Transportation, given all of the facets of their actual mission (source: father and grandfather both in the Coast Guard for 30+ years).
Long term, sure. In the short term, the rapid rise of housing prices combined with the increased rates and severity of disasters means the extra monthly cost would be enough to price a number of people out of homes they purchased when rates were much lower. While it's easy to say, "They should just move," that has huge transaction costs. Aside from the obvious things, which are already substantial, consider the cost of paying off a mortgage taken out a few years ago and acquiring a new mortgage at current interest rates. That can cost you hundreds of thousands of dollars (which shows up as now only being able to afford a much worse house, probably in a much worse location, if you can continue to afford to own at all), and you are basically gifting that money to the bank by paying off your loan early.
You can understand why such people would be willing to take a chance on not having insurance rather than incur a definite loss, and why it might be tempting to try to come up with some other solution than just unleashing the unrelenting might of the free market on them.
https://people.xiph.org/~tterribe/notes/edt.html
The resulting code (linked at the end of the page) is a bit more complicated than the standard distance transform, but only by a modest constant factor.
It is not their money. They have roughly $11.5 trillion of assets under management, but their market cap is only $161.5b (on net income of about $6b). Compare that to xAI, which has existed for less than two years and has a valuation around $50b.
Whether that is a good thing and ultimately healthy for the banking sector is another question, but you can certainly see how at the time they would not want to incentivize any more panic.
[0] https://www.federalreserve.gov/newsevents/pressreleases/mone...
On the contrary, everyone does use this capability. It is what makes the concept of "retirement" possible.
You borrow money when you are young and do not have much of value to contribute to society (for education, for purchasing a home, maybe for starting other ventures), you earn money during your productive years to pay those loans back and accumulate wealth (in personal or government retirement accounts, in Social Security or other government plans, in a pension), and at some point you are able to invest or lend or that money to others (or have others do so for you in the case of things like pension funds) and live off of the return, hopefully before you become so infirm you are no longer able to work.
I hope we can agree that allowing people to retire before they die is a net benefit to society. Claiming anyone can do that while they are still young with no risk is where you should start to get suspicious. Why should it be easy to get rich?
Every member of the OECD (including Japan and South Korea) and 8 more countries besides [0]? At a minimum.
[0] https://en.wikipedia.org/wiki/OECD_Anti-Bribery_Convention#M...
It is also worse than that, because for most dissertations, your committee is generally going to be more widely-read than the candidate, and have discussed the topic with them for years. Although the candidate may have more specific knowledge by the time they are finished writing the dissertation, the committee is going to have much broader knowledge of the field in general, and is pretty likely to be aware of the relevant prior art anyway.
A closer analogy would be saying the Ph.D candidate must be issued the degree unless a randomly chosen undergraduate can show the research wasn't sufficiently novel.
A lot of times you will send a (possibly large) blob of text repeatedly with a few minor changes.
One example I've used in practice is session descriptions (SDP) for WebRTC. Any time you add/remove/change a stream, you have to renegotiate the session, and this is done by passing an SDP blob that describes all of the streams in a session in and out of the Javascript Session Establishment Protocol (JSEP) API on both sides of the connection. A video conference with dozens of participants each with separate audio and video streams joining one at a time might require exchanging hundreds or even thousands of SDP messages, and in large sessions these can grow to be hundreds of kB each, even though only a tiny portion of the SDP changes each time.
Now, you could do a lot of work to parse the SDP locally, figure out exactly what changed, send just that difference to the other side, and have it be smart enough to patch its local idea of the current SDP with that difference to feed into JSEP, test it on every possible browser, make it robust to future changes in the SDP the browser will generate, etc.
OR
You could just send each SDP message compressed using the last SDP you sent as the initial dictionary. It will compress really well. Even using gzip with the first ~31 kB of the previous SDP will get you in the neighborhood of 200:1 compression[0]. Now your several-hundred kB SDP fits in a single MTU.
I'm sure WebRTC is not the only place you will encounter this kind of pattern.
[0] Not that either gzip or using part of a document as a dictionary are supported by this draft.
So still useful for compression, just in more specialized circumstances.
If you have rainy-day savings for at least six months of expenses (as everyone is advised to do), there is no reason you cannot split those up.
I had a friend whose first job out of school (many years ago) was part of a team at Intel assigned to write tests for their testing tools. When it matters enough economically, it will happen. As you can see from recent news, that is still not enough to guarantee a good result.
[1] https://www.kiseichu.org/e-top
[2] Visible in the tall blue case here: https://static.wixstatic.com/media/079dcd_843c7597ef244423aa...
[1] Net present value [2] of all future payments with a 5% discount rate. 5% is not scientific or anything. This is just a rule of thumb.
Based on my experience with (non-PayPal) financial institutions in the past year, this is going away. For now, it appears you can still force them to fall back to this when providing your login credentials does not work, but who knows how much longer.
Basically, people can front-run your trades, and this is built into the market by design. Also, instead of the winner being the fastest like in tradfi, there is a competitive auction where participants pay for priority. See, e.g., https://archive.ph/W0nvi or pages 7...9 of https://assets.ey.com/content/dam/ey-sites/ey-com/en_us/topi... for examples. Even if you are not the one doing the front-running, you have to be aware that someone else will be.
To make it more exciting there are also implementation bugs: https://archive.ph/9w32t
[0] https://en.wikipedia.org/wiki/Contiguous_United_States
This is obviously the insurer's goal, but in practice competition and relaxing underwriting standards to win business means that many insurance companies do not turn an underwriting profit (the buyer winds up with a positive expected value). But premiums are paid up front and payouts to policy holders do not occur until later, and the insurer can invest the "float" in the meantime, so they still make money.
Obviously the customer could have taken the premiums and invested them themselves, but that also takes time and effort, and may come with risk itself. It is not obvious that insurance is a bad deal even ignoring arguments about the concave nature of the utility of money.
They were clearly boilerplate forms, from several sources (hence the overlap and contradictions), "If any terms of this Addendum conflict with the Lease, the terms of this Addendum shall be controlling," etc., 6 documents and 20 pages after some other terms on the same subject. I claim to have read it, but I make no claims about having understood it.
There is an asymmetry of resources here that gives a large property management company a lot of ability to make your life unpleasant (and rent control gives them a good reason to want to). By the time you end up in court you have already lost.
Sure, it's not "at-will" and you can fight it, but it sure does feel lopsided if you can be told at any moment to find another place to live in one week for any one of a host of reasons you "agreed" to that change constantly.
In theory there could still be room for improvement. Right now ZBar estimates finder and alignment pattern locations to quarter-pel precision, but rounds each module location to the nearest pixel so it can sample a binarized version of the image to decide the value of that module. At the extreme limits of small module pitch this effectively turns the resampling filter in whatever you are using to resize your QR code image into a nearest neighbor filter. You can see why that would start to cause issues. Imagine a version 7 code (45x45 modules) sized to be 80x80 pixels. Most of your columns will be 2 pixels wide, but with binarization, somewhere in there you have to have 10 columns that are only 1 pixel wide. Good luck lining up your grid to hit all of them perfectly (without looking at the timing pattern, which would likely only help in the perfectly axis-aligned case). Some kind of sub-pixel integration of the original image before thresholding to decide each module value could probably do better. That would make decoding a lot more computationally expensive, though.
> I also tested only one background image, so the behaviour may differ greatly with QR codes contained in different surrounds.
This likely does not matter much. It could theoretically affect binarization near the edges of the code (near module boundaries, depending on how you did the resizing), but in practice as long as the code itself is high-contrast, this is unlikely. The more usual issue is that real images often do not have a proper quiet zone around the code, but that is mostly going to be irrelevant for what you are trying to test here.
> The QR codes are generated to be perfectly rectangular and aligned to the image pixel grid, which is unlikely to happen in the real world.
This is a much bigger deal. A large source of decoding errors for larger versions (for a fixed "field of view") is due to alignment / sampling issues. A lot of work goes into trying to find where the code is in the image and identify the grid pattern, and that is just inherently less reliable for larger versions, particularly if there is projective distortion (so the module size is not constant). The periodic alignment patterns try to keep the number of parameters that can be used to fit this grid roughly constant relative to the number of modules in the grid, but locating those patterns is itself error-prone and subject to false positives (they are not nearly as unique-looking as finder patterns), and the initial global transform estimate has to get pretty close for them to work. I am actually happy that damaging these was not causing you more trouble. This is definitely somewhere that ZBar can be improved. It currently does not use the timing patterns at all, for example. I'm not actually aware of an open-source QR decoder that does.
(I'm the original author of ZBar's QR decoder)
Whereas in the US, anyone with a pre-2022 30-year fixed-rate mortgage now has a massive paper profit due to interest rates going up that can only be realized by slowly making their required payments. That gets vaporized instantly if they sell and pay off the mortgage.