Production isn't about speed, efficiency, or obviously "clever hacks."
If I have to sacrifice 50% of my efficiency to ensure that I never get called on Sunday at 3am to fix a broken system, no kidding, I'll make that trade every time.
Production is about _reliability_. And writing reliable code is 10x harder than writing "fast" code.
More complex buffer management in non-garbage collected languages.
man 3 cmsg
For a glimpse into the darker corners of hell. At least you get to grip it there. In GCed languages you have to hope the library designer gave you reasonable controls for timeouts, aborting large data transfers, and releasing buffers efficiently in a bursty network environment.
See all the controls any HTTP server gives you for this. "Maximum header size", "Maximum header(s) size", "Maximum Body Size", "Request Header Timeout", "Total Request Timeout."
None of those were added by default or by tasteful library authors. They were all added to answer to specific emergent security vulnerabilities that were discovered and then were demanded by the users.
ASN suffers from some of the other problems regardless of the encoding.
I was thinking about this more and I think FTP actually had a lot of the right ideas here. You want two channels. One for fast interactive command messaging and a second one coordinate especially just for bulk transfers arranged over the command channel. The design flaw in FTP of putting these on two separate ports put it immediately in conflict with firewall best practices so I think it went mostly unnoticed that it fundamentally is a good arrangement.
What you want is one channel, sequenced packets, with a defined maximum message length that is negotiated at startup and never changes during the life of the channel. This should probably never be more than 65k. There should be a known length packet type, and an unknown length packet type, with any attempt to send more than the negotiated maximum triggering an error and disconnect.
If you do need to send more than the negotiated amount you should open a new connection, in a bulk transfer mode, that after the initial handshake, has no protocol and is merely an associated stream of bytes that are wholly uninterpreted by the middleware layer other than to help you associate it with the sequenced packet that requested its initiation.
You'd actually be able to use TCP (with DSCP even), mostly avoid head of line blocking and multiplexer latencies, and have a reasonable security guarantee in the sequenced packet mode, and never have a protocol which pretends that 4GB strings in the middle of a packet are necessary or even a good idea to "support."
The downfall of this is that it would be much harder to implement it on a serverless architecture and would be nearly as complicated as a protocol as WebSocket ends up being. It might be worth playing with as a concept anyways.
I genuinely dislike CBOR. Formats which require me to calculate the length of the message before sending it lead to bad library design which often leads to easily compromised code. Add in an "indefinite length" option and you've got potentially unbounded client memory usage to watch out for. As if that wasn't enough you get extensible tags so the meaning of any message is entirely dependent on the context it was sent in.
It gives you a lot of decent protocol wire design and then flatly ignores everything we've learned about these types of designs in the last 3 decades. Be on the lookout for client libraries to slowly add in all of these checks as the vulnerabilities are discovered in them.
The OS does not have "appeal." It either works and facilitates my use of my own hardware or it does not.
The only reason to think this way is because you want to turn your paying customers PCs into advertising machines that violate their privacy and turn their hardware against them. There's not amount of "appeal" you can cram into your product that will get me to work against my own interests.
I'd recommend jack audio connection kit if that's your use case. You can generally get the best latency performance that your card has to offer, and the jack connection graph is superlative, in my opinion.
SBF is a dumb criminal, who then screwed over everyone he abused into creating this theft. I honestly can't imagine many easier setups, less sympathetic defendants, or parades of pissed off co-workers willing to put the knife in him before he got it in them.
> SBF did not have any intention of committing a crime.
His fraud started early on, and he used the same tactic over and over again. He lied to his customers about how their funds were held, then abused them whenever any problem involving money came up in his life. Least self aware villan ever created.
They typically don't. When the government doesn't enforce it's own rules, these companies just buy up competition. They strangle the market and they get more inefficient all at the same time.
Hope this helps. I used to do a lot of work in GTK's Glade and Qt's Designer. I was surprised how simple flexbox made it to just recreate those ideas in CSS.
I use flexbox exclusively. My personal opinion is that if you're using media queries for anything other than "screen" vs "print" you're absolutely doing it wrong, in particular, media queries for screen size are a red flag.
To me, the trick to using flexbox effectively is to use it to create fully reactive layouts the way that Gtk or Qt would design them. I create flexbox interfaces in terms of "VBox" and "HBox" containers, I use flex-grow to handle the concept of "box packing."
Once I started seeing it through this lens, and when CSS finally added calc() and other functions writing good and consistent frontend UIs that mimic precisely how almost all other desktop software behaves became incredibly simple.
The only real complaint I have is that after I have a finished product, going back and making changes is harder than what other techniques might afford, thankfully HTML added <template> and by incorporating that liberally into my designs I've regained some of the original careless flexibility I had before it.
> What doctors LIKE are the ones they get used to in their residency, fellowships, and first years in practice.
From observing a family member implement these systems, I'd say that what doctors like is an administration that's willing to listen to their specific complaints and then get the changes or some subset of them implemented in the system. There's often a fair amount of customization that can even be done at the customer level to achieve this.
Seemingly, too many institutional administrators fall in love with the sales pitch and then are demoralized into acrimony when their doctors don't just automatically feel the same way on the roll out day.
> Though they can directly address this by taking photos out of the mix.
You could, with mixed results, I'm sure. There are many other factors to base a prejudice on; for example "does their name /sound/ black?"
Airbnb could also establish an anti-discrimination policy, which if you are caught in these types of incidents, you and your properties will be banned for some amount of time.
I've never used the service, so I can't say for sure, but I can think of at least a few good ways to accomplish this along with a team responsible for checking into flagged events and user reports.
That's the inherent risk of using a third party to host "your account" on a proprietary system. I have sympathy for all these artists, I truly do, but what were they expecting?
If I have to sacrifice 50% of my efficiency to ensure that I never get called on Sunday at 3am to fix a broken system, no kidding, I'll make that trade every time.
Production is about _reliability_. And writing reliable code is 10x harder than writing "fast" code.