Thank you so much. Please just make a free site and add your email with notifications enabled or signup for the newsletter. I'll be posting some pretty detailed and mind-blowing updates soon
In a perfect market, the market maker who sells you that option offsets it with correlated assets in the other direction, eg by buying or selling stock that is sensitive to the election.
Large trading firms exist on finding and exploiting small arbitrages between various correlated assets. If you assume a perfect market with infinitely many participants and infinite liquidity, then this “works” - there is no distortion at scale.
This is awesome, but I'm not sure what the long-term use case for the intersection of low-latency integration and non-production-stable is? I'm saying this as someone with way more experience than I'd like to in using reverse-engineered APIs as part of production products... You inevitably run into breakages, sometimes even actively hostile platforms, which will degrade user experience as users wait for your 1day window to fix their product again.
Though I suppose if you can auto-fix and retry issues within ~1minute or so it could work?
I think it's pretty likely that they just don't look at or test Newpipe when they change their APIs. If the change doesn't break any official clients, it goes through.
With how large Youtube is, I iimagine API changes are not infrequent.
Well, then a service like Integuru would be perfect for Newpipe! Maybe someone should suggest them to use this awesome service? (I am pretty sure Alphabet would be really happy about that one! :D)
This is a very important question. Thank you for bringing this up! Currently it requires human intervention to auto-fix integrations as someone needs to trigger the correct network request. We are planning on having another agent that triggers the network requests through interacting with the UI and then passing the network request to Integuru.
I see - I suppose that’s a fair viewpoint to have!
I’m not much of a python programmer but my experience with the language would make me tend to agree actually. There are bigger fish to fry and so the effort to go after this relatively tiny sardine is perhaps not worth it.
I don't understand this. To me, a bare exception is explicitly that. By not providing a specific exception, you're saying "nothing specific, literally anything".
Why would you go through all the hassle of setting up an air-gapped system, only to stop at enforcing strict code signing for any executable delivered via USB?
Just the fact that one can insert a USB drive into the air-gapped system amazes me. I remember my days as a contractor at NATO and nothing could be plugged into those machines!
I guess the problem is that most air-gapped guides and practices out there mostly focus on sucking the "air" out of computers: internet, networking, bluetooth, etc from the get-go ("remove the network card before starting!"). But even air-gapped systems need some sort of input/output, so a keyboard, mouse/trackpad, displays and monitors will be connected to it - all pretty much vectors for an attack; a base sw will be installed (making possible supply-chain attacks); largely USB drives and even local networking may be present.
As a general rule, I'd say anything that executes code in a processor can be breached to execute malicious code somehow. Signing executables helps, but it's just another hoop to jump over. In fact I thought the threat in OP was about a USB firmware issue, but alas, it was just an executable disguised with a folder icon some user probably clicked on.
To make things worse, critical hardware (trains, power plants...) vendor's fondness for Windows is notorious. Just try to find nix-compatible infrastructure hardware controllers at, say, a supplier like ABB who (among other many things) makes hydroelectric power-plant turbines and controllers: https://library.abb.com/r?dkg=dkg_software - spoiler, everything is Windows-centric, there's plenty of non-signed .EXEs for download at their website. This is true in many other critical industries. So common it's scary these things could be compromised and the flood gates, literally, opened wide open.
Air gaps are easily enforced and require absolutely zero technical knowledge.
You just need a PC and then have a CD delivered through a trusted source – embassies should already have a way of ensuring physical integrity of their mail.
The technical knowledge needed for code signing, especially now with trusted hardware modules, is orders of magnitute more complicated than that.
Not just knowledge: code signing is going to be a lot of whack-a-mole work dealing with every tool you use. I’d expect that to cost more than you expect and get political blowback from whoever needs tools which get broken.
Why worry about the blowback? That's the corpse talking, if I hear, "This disrupts our workflow," I'm even more confident that I should rip the band-aid.
Offices that don't follow security practices uncovered because they never called for help, another chance for drifters on autopilot to walk away from the job because it just got too hectic, stop paying licenses for a bunch of tools you didn't realize you were paying for and don't need, find replacements for all the tools that are not actively maintained, or don't have cooperative maintainers.
It's a healthy shake-up and our society at large should be less scared of making decisions like these
You’re assuming that everyone shares the IT security department’s priorities. If you tell someone senior that they can’t use a tool they need, you might learn that they have political clout as well – and the context here makes that especially plausible.
1. Slack has network effects: we connect with customers on Slack (or M$ Teams for enterprise…)
2. I don’t want to innovate on “back office”. Slack works, is sufficiently affordable, and costs no social credit with employees.
3. I know I won’t run into problems in the future. This kinda ties into (2), I don’t want to innovate on back office, but to make it concrete: Deel, Rippling and the other M$ AD clones all integrate with Slack to set up permissions and SSO with zero effort.
4. Slack has lots of sensitive info about us and pur customers, which makes it SOC-2 relevant. I want to use “industry standard” tech for anything compliance related. Though I don’t recall that this would have ever been a problem on security questionnaires, and not many years ago Slack was the “young kid on the block” themselves & managed, so idk if this is actually a valid point.
—
If you give me a feature parity clone of slack for half the price, I’d certainly switch, but anything less than feature parity and I probably wouldn’t. I don’t need to or want to take risks on internal tooling.
I don’t need to or want to take risks on internal tooling.
That's an interesting take. I'd argue that there's nothing more important to innovate on. The reason? Because I believe that "the ability to learn faster than your competitors is the only true source of sustainable competitive advantage" and, concordantly, that your internal tooling and processes are crucial embodiments of your organizational learning.
Of course that learning and improvement on "back office" has to be in service of delivering better products, or reducing expenses, or better understanding your customers or something in order for the payoff to manifest.
My understanding was that the extra parameters required for the second attention mechanism are included in those 6.8B parameters (i.e. those are the total parameters of the model, not some made-up metric of would-be parameter count in a standard transformer). This makes the result doubly impressive!
Here's the bit from the paper:
> We set the number of heads h = dmodel/2d, where d is equal to the head dimension
of Transformer. So we can align the parameter counts and computational complexity.
In other words, they make up for it by having only half as many attention heads per layer.
Some of the "prior art" here is ladder networks and to some handwavy extent residual nets, both of which can be interpreted as training the model on reducing the error to its previous predictions as opposed to predicting the final result directly. I think some intuition for why it works has to do with changing the gradient descent landscape to be a bit friendlier towards learning in small baby steps, as you are now explicitly designing the network around the idea that it will start off making lots of errors in its predictions and then get better over time.
This certainly contributed to people preferring card over cash, making merchants loose ~3% per transaction.
That ship has long sailed, but it does male you wonder: if everything was priced at increments of, say, quarters, would enough people still use cash to offset the lost sales from the allegedly less appealing pricing?
Cash also has costs - mistakes in making change, forgeries, time to count/cash up, time to visit banks for cash deposit and/or getting change, theft - it’s been estimated that these can easily exceed any costs of handling credit/debit cards.
I run a business with lots of daily transactions. The cost of balancing cash drawers, getting change, making deposits and balancing those activities in accounting, all totalled, is still cheaper than to pay the credit card fees. Also it's kind of a fixed set of time regardless of how much cash it is. So more cash is more savings but there is definitely a point where if the cash amount gets to low it would be cheaper to go all card.
I think that cheaper propaganda is probably from theft in mostly places that hire minimum wage workers and treat them like slaves.
Could you elaborate? I have many years experience running a gas station. For five daily’s employees, handlung cash is about 4 hours labor a day. This is counting the till prior and after shift, validating voids and receipts, handling checks, cashiers checks, and bagging and dropping the cash. With cash there is always slippage, and it is never in the ledgers favor. So cash increases labor costs by 10% and incurs about 1% direct loss a day, prior to bank fees. Where as credit cards end up being about a 2.5% overhead.
Wait, you can still pay by check in stores in the US? That was phased out in the UK like 15 years ago. And even before then, I only ever saw old people do it.
I think in part it's because its harder to transfer money between banks in the US - no equivalent of the faster-payments-scheme which allows a free transfer within a few minutes in the UK. Cheques do provide a layer of universal compatibility.
I think its also the reason behind the success of Venmo (and earlier PayPal) to allow for free/very low-cost money transmission.
It amuses me that venmo / cashapp (multi billion $ innovative startups that reimagined something) simply do what regualar banks do and have done for decades in the rest of the world.
I don't have experience with a gas station so mine could be very different. I'm at 1-3 daily employees.
For me it's:
- counting the till pre and post : It takes about 3-5 minutes a till. (money counters are awesome, and I setup all pricing increments to avoid anything below a quarter, which wouldn't be practical for an average gas station. But it could be done down to the nickle or dime) I don't count before and after, just after. The before till should already be done from counting the after and using for a shift the next day.
- validating voids and receipts : it's mostly fully automated via the POS. Maybe 10 mins when something odd happens but it's not common.
- checks and cashier's checks : we get almost zero of these.
- bagging and dropping cash : labeled bags and a drop safe, I don't count until at least the next day, all in one quick go. All the time is in the counting part.
- cash slippage - ours has usually been fairly close. Some times a bit over sometimes a bit under. If its a few dollars off every now and then I don't worry about it. If its consistently off, either way, it signals a problem, usually in training. But every now and then its nefarious and corrected.
So weekly time breakdown is probably:
- counting daily tills : 30-45 mins
- making the change request, deposit and going to the bank, Ill just say 1 hr as the bank is about 10 mins away. I also usually do this when already out for another reason and I usually go only once per week as cash is so low post covid. I used to go 2-3 times a week pre covid. But if we have a large cash day I will make an extra trip so we are not sitting on as much.
- misc accounting etc. : our QuickBooks auto syncs to the POS, with each day's sales recorded and the corresponding expected credit card and and undeposited cash account records created. So when the physical cash deposit is made it with auto match the record already created by the POS and I just click the match button. But other things always can happen in the chain so let's give another 10 min buffer here.
So I'm out 1.75-2ish hrs/week, which actually feels like more than I spend on it. So for quick math for each 10k sold per week at a 2.5% cc rate (ours is higher around 2.8ish). That's $250 in credit card fees. That's About $125/hr to handle the cash vs take the card. Looking up the average gas station sales of about 109k/month that is around $2,725 in fees. So even quadrupling the time I spend that would yield a savings rate of $340/hr spent handling the cash. Seems worth it.
Cash indeed has a high handling cost. In my country and many others, withdrawing cash at the supermarket teller with your card is free (as in no ATM fees) because it reduces the amount of cash handled and transported by branches. They'd rather eat the cost of a card transaction than pay cash handling costs.
I don't know, but I find I use cash much more readily when the price includes tax, because I can confirm ahead of time that the cash in my wallet is enough without breaking a 20 for a pile of coins.
I see what you're saying, but I don't think it applies in this case. Correct use of jargon helps domain experts communicate with higher precision, and papers tend to be written by domain experts for consumption by other domain experts.
Of course there are some (possibly many!) papers where jargon is abused to make something sound smarter. Sometimes this can also happen unintentionally.
In this case, "compute-optimal X" is standard terminology used in large-scale ML model design for finding the most optimal tradeoff with regards to compute when trying to achieve X.
Here, the paper is about finding the optimal model size tradeoff when training on LLM-generated synthetic data. Imagine you have a class of LLMs, from small to infinitely large. The larger the LLM, the higher the quality of your synthetic data, but you will also spend more compute to generate this data ("sampling" the data). Smaller LLMs can generate more data with the same compute budget, but at worse quality.
The paper does some experiments to find that in their case, you don't always want the largest possible LLM for synthetic data (as previously thought by many practitioners), instead you can get further by making more calls to a smaller but worse LLM.
Do you have a write-up somewhere of how you built this? I think there is a lot that I (and probably many here on HN) can learn from you.
reply