It's worse than just handwaving, it's straight up nonsensical. Perhaps it is literally true that only 2% of distinct accounts that log into Docker Hub have this plan, but for the vast majority of people "using Docker Hub" means "pulling public images from Docker Hub", not "logging into Docker Hub", so by a more reasonable criteria (say % of images pulled) I'm sure its at least an order of magnitude greater.
Interesting to see so many responses along the lines of "that's not been my experience of the industry". I have a theory though at the source of the difference in perception, and it's not that the companies are different, it's that the range between the most productive and least productive software developers is incomprehensibly huge. One of my favorite childhood books features a steam shovel named Mary Anne whose owner avers she "can dig as much in a day as a hundred men can dig in a week". A steam shovel developer is often stuck looking at the hundred diggers and wondering what the heck is taking them so long, but most developers are one of those hundred and spend all day digging without ever realizing just how inefficient they are.
In the UK they have the term "redundancy" (as in "your position has been made redundant"). Can't see that term catching on in the US but it does cover the use of "laid off" to mean "the company chose to eliminate the position I worked in rather than choosing to get rid of me as a person", and thus may carry less stigma.
Nobody has to put in anything other than confidence. Given enough time the bank already has plenty of assets--the whole point of the feds saying "all deposits will be made whole" is to stop the panic withdrawals and thus obviate the need to sell those assets.
I expect the losers in SVB will be the same as for WaMu: bondholders, shareholders, and investors. No reason yet to expect depositors will suffer anything more than inconvenience. And if, like WaMu, the FDIC can rapidly effect a sale to another bank that inconvenience could actually be quite short.
HTM accounting isn't the problem, it's one tool among many and has its uses. SVB's mistake was buying long term paper just as the country was heading into a rising rate environment. This has already put them in a hole they probably can never dig themselves out of (selling stock is clearly not gonna work). I think the only non-disastrous path forward here is an acquisition by another bank big enough to just absorb that paper into its balance sheet. If SVB is smart they'll try to get this done while there's still some value left to sell--if they wait too long it'll turn into another WaMu.
Definitely makes way more sense for a macro pad--you don't hit those keys very frequently so switches are less significant but the key's effect changes often so the screen is useful. Tactility is good, I never liked Apple's Touch Bar for that reason, you had to look to be sure what you were doing. Can't imagine those switches being preferable for the primary keys, but would love to see something like this in the old IBM AT F or XT layout: 10 function keys in two columns on the left side where they could easily be combined with meta keys. Back when I had those (mid to late 1980s) I relied heavily on them, but I almost never use function keys since they moved to the top of the keyboard (and are effectively out of reach).
Definitely sets off my BS detector. They're under no obligation to publicize this so if they want it to be a secret they could keep it a secret. This means they do want publicity, probably so they can raise money. But there's an official way to protect your IP and get publicity: file a patent that details your process.
Yes I was thinking about this from a customer's perspective. In particular I can't tell if Usage is buying/selling/holding reservations in their account but on their customer's behalf, or if they are just automating the buying and selling of reservations but that's all done in the customer's account with the customer's money. If the latter then if Usage disappears one day I assume you might be stuck with reservations you don't want, or without the ones you do want, but in the former scenario the situation could be more chaotic if suddenly resources you depend on simply stopped being paid for.
Curious what happens to resources and reservations if Usage goes out of business? Three years is actually a pretty long horizon to rely on a startup still being around.
It's a tiny amount--I'm guessing I've probably easily logged 20,000 hours of active use in vi by this point, I can't think of any other tool I use regularly that has a better time-of-use/time-of-setup ratio. Compared to the time I've spent, say, installing Ruby gems and fixing dependency conflicts it's a rounding error, and Ruby's only been a focus for a small fraction of my career. To clarify that wasn't ever one 20 hour chunk, that's a rough guess at the total time spent setting it up on dozens of different computers across many different operating systems and window managers. It's typically well under an hour of setup per computer, and much of that time goes towards remembering where to find installers, picking fonts, etc.
For a science fiction novel it was pretty huge--selling over 125,000 copies[1] in its first couple years, and is ranked near the top 10 of all time. This list [2] has it in 12th place overall, but a lot of the others on the list have also been movies, which raises the profile of books a lot.
Setup how? I've used vi/vim daily as my main editor for the past 35 years or so, over that time I doubt I've put more than 20 total hours into its setup. I've been using some evolution of the same .vimrc for decades and it's only accumulated a couple dozen lines. The longest setup task I can remember was a few years ago getting MacVim to launch with one window per folder (with files as tabs, in most cases that equates to one window per repo, handy when I'm working across a couple different ones), but that was all shell work, not within vim itself.
This may actually be illegal[1], particularly if it disproportionally aligns with any other sort of protected factor (like age, sex, or national origin).
Notably these formats are designed to be lossless and very simple to work with programmatically so they were used as the intermediate format in a lot of image processing workflows, even where the inputs and outputs are a more common format like JPG (which is extremely hard to manipulate directly).
If this article doesn't make you sufficiently paranoid may I refer you to my all time favorite Underhanded C Contest, the leaky image redactor from 2008. The winning entry is just brilliant: it's simple, it works perfectly, does nothing tricky, but still allows near perfect recovery of redacted text.
This author, and 99% of anybody writing about, and large majority of anybody attempting to do code reviews misses that there are two very distinct and not particularly compatible purposes of code reviews. IMO the only really important one is identifying code that doesn't do what it's supposed to, either because the author miswrote it or misunderstood the requirement. Critically this is just "what", not how or why. This is often really simple stuff, like getting a sign wrong or storing a value to the wrong field/variable or using && instead of ||. 100% objective stuff. The other purpose I'd more broadly describe as "design review", which is focusing on "how" the code should have been written. In my experience this is mostly subjective and that's what consumes all the time. My suggested approach is to officially delineate the two, and whenever someone raises design or style issues in a code review just say "that sounds like a good topic for the design review". You can actually use PRs for both purposes, just front load the "design review" during the WIP phase for a feature branch, and then do the "code review" before merging into a mainline.
Real world example: a company I consulted for a couple years ago had a lead architect known for nit-picking code issues with junior devs ad nauseam (to the point where potential hires were told to expect it and not join if they didn't think they could take it). Their production system was brought to their knees by a doubled for loop, literally just a duplicated line of code. This code copied messages from one place to another, but almost all of their testing used cardinality 1 so it didn't affect the tests. In production all it took was a couple cardinality 2 cases because there was one edge case flow that could route copied messages back through the loop and this caused cascading failures as 2 became 4, 4 became 16, etc. This error would have been obvious to anybody reviewing the code, even if they didn't really know much about it, but as that module was written by said architect no one else felt qualified to review it.
Sorry for the offtopic remarks, but DevDB is relevant to my interests since I've been working on a similar/related and potentially synergistic tech as an on-again/off-again side project for a few years, and would love to chat with you about it. I've got the same username on GitHub and Twitter as here if you want to reach out through either of those channels.
I have tried moving up the management chain (PM/TPM/Architect/C*). The biggest challenge I found is that generally I was still the most productive engineer available to apply to most problems, so I still spent time writing code (the alternative was like watching a fire burn out of control while holding a fire extinguisher). In some orgs (particularly bigger enterprises) that hit up against a wall of expectations for what people in my role could/should do. Eventually I settled on consulting as better fit--I still do stuff across the full spectrum, but as an outsider I'm not expected to fit into a particular box.
It gets only a sliver of attention compared to Los Alamos and Santa Fe, but Española is actually effectively another LANL company town--the lab is the town's biggest employer and a large portion of the lab's workforce lives there, so e.g. sharing the commute up the hill would be easy. And compared to either of the others (or any FAANG city) real estate is cheap (like 3+BR 2000+sqft on half an acre for < $500K).
Google gained their monopoly over search when they had only a couple hundred employees, competitors definitely do not need to be very big at all to be a threat to Google technologically. The government interventions that will matter will be stopping Google from bribing companies to use their software--no startup can possibly afford to pay Apple $15 billion per year just to be the default search engine on iOS.
It's not at all difficult to imagine many other measurements: minutes driven, type of road driven on, speed at time of crash, whether another vehicle was involved, etc. As a data analyst what I really want though is more granular data so we can figure out whether the published metrics are being cherry-picked.
You can't just Excel the Tether short because the basic premise is no one knows the truth about them. Tether on the surface is a perfect business: people give them real money in exchange for tokens they mint themselves for free. They don't have to pay any interest, they get tons of float, they're denominated in the world's primary reserve currency, they have almost no regulatory burden, the tech is mostly other peoples problem, etc. It's literally impossible for them to lose money, even if the whole rest of the crypto world blows up--unless you believe they're being stupid risky with their reserves, or that they don't actually have 1-to-1 reserves in dollar denominated assets. But if you believe it is only the former (like they have it all in high-yield Chinese real estate developer paper) then why not just short the risky asset directly? The reason people are attracted to this short is because they believe it is in fact the latter scenario, and that eventually some event (or series of events) will reveal the emperor has no (or at least not enough) clothes and the peg will collapse. My point is if/when it does it's going to take everything else down with it: Tether is the market, its daily trade volume is roughly the sum of every other currency's, there is no way BTC/USD can shrug off a USDT depeg.
Simple drip machines are a marvel--I spend more on a month's supply of beans than I do on the maker, and have been getting about 5 years daily service out of each one. Technology Connections made a great video explaining how stupid/brilliant they are https://www.youtube.com/watch?v=Sp9H0MO-qS8
Considering the two risks as independent surmises that BTC goes up substantially (in USD terms) via some mechanism other than printing Tether, which AFAICT never happens. If/when BTC does go up you can simply short again at the higher level. If you're not sufficiently capitalized to handle margin calls you really shouldn't be doing shorts, but even small investors can do this trade by buying the BITI ETF.
Tether effectively denominates the entirety of all crypto valuations, so going to any exotic length to do a specific "short Tether" trade seems silly. Just shorting BTC/USD will have the same effect.
The entire "gig economy" would be much better named the "scofflaw economy". Far more than technology, a willingness to deliberately ignore laws/rules/regulations/decency is the core competency of AirBNB, Uber, GrubHub and pretty much every other major player in the space.
In fiat terms, unless you really believe there is over $60BN sitting in a bank account that they just choose not to show for "reasons", Tether is already insolvent. Since most of Binance's non-self-issued reserves are in the form of Tether they, by extension, are insolvent as well. The open question is how long can they can keep the game going, thus the current rescue fund/proof of reserves/transparency audit circuses.