First, "just use" is doing a lot of work in that sentence, because DPDK is much harder to use than XDP. The authors of this blog were surprised they had to do their own checksumming, for instance.
Maybe more importantly: they're not building a middlebox. DPDK ultra-high performance comes in part from polling. It's always running. XDP is just an extension to the existing network driver.
It’s boggles my mind that enterprises or SaaS wouldn’t be following release cycles of new models to improve their service and/or cost. Although I guess there’s enterprises that don’t do OS upgrades or pathing too, just alien to me.
They're almost never straight upgrades for the exact same prompts across the board at the same latency and price. The last time that happened was already a year ago, with 3.5 Sonnet.
Same background as me, however I moved into cellular/mobile - not really any official routes I know of in the industry, certainly not like a Cisco track.
Typical route is work at a Telco or IoT company as Network Eng or Developer and naturally pivot into telco learning on the job.
Vendors will run training courses when you buy their kit which helps a little, but it’s mostly self learning or on the job.
Services like this are actively in use by most Banks/ATMs around the world on most mobile carriers, just via creative but common reusing of long standing mobile/telco protocols.
GSMA are actively attempting to lockdown them existing methods, as they’re built on trust in a very untrustworthy environment between carriers, and in some cases state actors.
Sure on the face of it this isn’t brilliant to the average HN reader, but with context it’s a significant improvement vs where we are today.
How about an easier and better solution, stop using a broken protocol and enforcing the use of phone numbers as an identification for critical information or banking, there are better and more secure ways, and just keep the GSM network for emergencies and 911 calls.
Well, all of the 3GPP mobile networks switch to a different logic for emergency calls. In the GSM case all emergency calls (112 is hardcoded in the specification and there is a provision for both USIM and the network to add more numbers that behave that way) use different RR layer protocol that deals in physical addresses (ie. IMEI) and the whole process is streamlined. The MS that initiates emergency call will just uplink an emergency RACH frame to anything that it is synchronized with and the network will respond by allocating traffic channel for that, there is no kind of GSM signaling nonsense with multiple packets involved in that.
Difficulty: nothing that requires an end-user to understand PKI; and also would not impede a lawful (and for the purposes of this conversation: ethically necessary) police wiretap.
> nothing that requires an end-user to understand PKI
None is needed, how hard it’s for a bank handing over physical tokens to the customers when they open an account or mailing them to existing ones?
- You can loose them? Sure, just like any smartphone or even government ID, but the process after to replace is what will make you careful next time.
- They can be stolen? Same as above
- They can be used in banks or even for online banking, just tap it with your NFC enabled phone (yubico is an example)
- They can be used by someone else? Sure, just like your phone.
- However, no sim-swap attacks or similar, so in theory it’s better given no negligence from the users which is always the biggest risk anyway, but overall it’s an improvement.
>and also would not impede a lawful (and for the purposes of this conversation: ethically necessary) police wiretap.
Why would the police wiretap a banking verification, they can wiretap the transaction at the banks if they are legally authorized.
> stop using a broken protocol and enforcing the use of phone numbers as an identification for critical information or banking, there are better
There are no better ways for the average human (who doesn't have a clue what 2FA means but can understand being sent an SMS and using the code in it to access an account).
Authenticator tokens are absolutely passe right now, there probably is single-digit percentages of people who don’t have at least one Authenticator code on their phone.
And for the handful of people who just don’t have a phone… RSA/Duo tokens exist for a reason.
SMS allows a whole class of additional attacks, it’s a terrible system and should be removed.
A mobile app running on a phone that does not receive security updates anymore (or the user not installing them) and a platform fully accessible to the NSA. I really prefer hardware tokens distributed by the bank. Even if the implementation might suck from cryptographic point of view, they are offline.
Being pragmatic you’re not going to convince every Mobile network vendor to implement a new protocol, and then have every mobile operator invest in replacing their cores to support it, all in the name of a better solution.
You don’t convince, you avoid that risk completely by not using GSM as the medium of identity verification, just regulate an identity verification mechanism for banks and such, and don’t mandate it for the users so they are free to choose or opt-out.
Assume your friend does no more than a day a week, and in 5 years you’re worth a huge sum on money - what percentage do you think would fairly reflect his reward, that’s the percentage you should give now.
If you give 5% for example, there’s no reason you can’t give more in time based on increased input, but don’t give something you’ll regret in the future.
>> If you give 5% for example, there’s no reason you can’t give more in time based on increased input, but don’t give something you’ll regret in the future.
What would be your method to "give more in time based on increased input"?
Say now I give them 10% equity based on 1 day per week commitment. What's your suggestion if after 6-month, they increased to 3 days per week commitment?
If you pursue this, make sure to research the tax implications of giving away large chunks of equity post-founding.
If you wait until the company has a large valuation, your co-founder could be taxed on the stock's current value, even if they aren't making enough salary to pay the taxes. This is why many founders purchase the equity up-front (at a very low par value) then do reverse vesting (where the company can claw back the equity under certain scenarios).
You can negotiate that with them either ahead of time in an agreement, or when they are able to commit more time. It should be in both your interest to negotiate that in good faith if the startup is doing well.
