alaties

I went to college starting 2007 (right when CUDA was released) and recall a few things about python that made it attractive in both the comp sci and math departments at my school.

  - python integrated well with lesson plans instructors had
  - python integrated well with the software math departments were using (like MATLAB)
  - python had a very easy to use interpreter environment that worked well on linux, mac, and windows
  - python had (for the era) a massive standard library, making it way easier to consume and process 
    common data file formats like XML or CSV without having to install any extensions 
    (installing extensions usually required admin permissions and... very few at school had those for very good reasons)
  - exposing c/fortran libraries into python was pretty straightforward to do and was relatively stable compared to alternatives.

  - tcl - somewhat popular for embedding but didn't really have a standalone interpreter that made it easy to interact
    with and the syntax didn't really look like C, and really not much of a library to work with

  - lua - similar to tcl, popular for embedding but didn't have a popular standalone runtime and interpreter.
    syntax was closer to C though. didn't have much of a library to work with

  - ruby - had a runtime for experimenting but a less stable API for integrating, plus the language was pretty
    different from C. the library was large but had a larger reliance on installing extensions than python at the time.

  - perl - both unstable and had a horrible reputation by this point as a standalone language that outside of some obtuse
    systems scripting, most people didn't want to touch this with a 12-foot pole. standard library was small and relied a lot on extensions.

  - php - similarly unstable (at the time... i think 5.3 had just come out) and had a horrible reputation... also not even
    sure it had a runtime that worked outside of an apache/nginx context... exposing a c library to PHP at this time was pretty
    straightforward though. relied very heavily on extensions at this point.

  - javascript - node.js hadn't come out at this point... so the idea of running javascript outside of a browser window wasn't really a thing yet.

I believe that led to a first-mover advantage that has held over time.

Would cast iron pots and pans count as thick-bottomed in this case?

I usually use these with electric stoves since they retain heat pretty well. They take a while to warm up though, so there's both time and energy lost in that warming process.

It might be possible sooner rather than later given Chrome OS Flex is a thing now.

As soon as linux can run on M1s stably, I think Flex would follow suit as well.

Yeah... Bird configurations are a little rough to learn. The examples they have on the website are pretty lacking. Their mailing list is usually helpful though.

Quagga is usually easier to find examples for since it's modeled after Cisco switch syntax for configuration (same basic syntax of arista switches).

Both of these really suck to learn as a programmer since you're usually coming into these without much of a network engineering background. I remember struggling a lot with both of these config syntaxes until a network engineer took me under his wing and taught me basics, principles, the engineering challenges of packet switching at scale, etc.

It should be noted that an EXPIREAT triggers a deletion if the timestamp being set is in the past and could lead to an increase in memory and disk pressure during script execution. Worth checking if the behavior there differs in any meaningful way since y'all made the change. EXPIRE usually just marks a key and relies on either subsequent operations to the same key or garbage collection to actually excise the entry and do the subsequent bookkeeping, I believe.

It's been a while since I had to deal with this kind of problem though, so please tell me if things are different now.

I'm kind of shocked no one brought up protobufs yet. protobuf libraries are available in pretty much all mainstream languages and the textproto format is pretty mature.

It's albeit clunkier and less freeform than YAML. And if you ever only plan on using rust the proposed solution here is probably cleaner.

Having portability over multiple languages maintained by large organizations can be useful in some cases though.

I've been similarly frustrated in the past.

Interestingly, I've found that studying other engineering disciplines outside of software engineering to be best. The best explanations and modeling frameworks for concurrency I learned were from network engineering books and a couple hardware design classes I took.

Re: principles around performance analysis and diagnostics, Brendan Gregg is a name you should look up. His book on systems performance is a tremendous resource in both principles and methodology. Even though it's not focused on coding specifically, the same principles apply.

Best option is to force encryption on all bittorrent traffic. Most clients support full protocol encryption (PE or MSE) these days, so forcing it shouldn't be an issue. For libtorrent, you'd set in_enc_policy and out_enc_policy to pe_forced.

Whether a particular client exposes this or not depends. In the case of this project... looks like upstream github.com/anacrolix/torrent does support encrypted connections. Not clear how to force it to use _only_ encrypted connections though.

That greatly depends on use case.

I think if you're looking to write a simple HTTP server with some API functions that talk to some RDBMS at less than 100 requests per second, yeah, C++ is pretty hygienic and safe these days.

If you need to play around with memory management strategies like non-default allocators then yeah, the knives are still very sharp and will cut you if you're not careful. This comes up a lot when writing C++ extensions for scripting languages like PHP, Python, etc and you have to interact with objects managed outside of your C++ code.

These kinds of cameras produce pretty high volumes of data, since it's picture + 3D dot cloud per frame. My guess would be even 1G over wifi wouldn't be enough throughput without some compression engine in place.

It'd be wherever in the network path has the most contention, all else being equal.

For a home environment, this would most likely be at the Internet Gateway level, since home networks usually operate at >100Mbps transfer rates between nodes, but to the internet have <=100Mbps.

That all being said, contention at the gateway level like this would be assuming that KCP and TCP are both being used for, say, large file downloads.

If KCP is limited to use for sharing game state data for a game like Counter Strike, then the likelihood that KCP would consume all available bandwidth within a given time window is low, since the data rate is measured in hundreds of Kbps, not Mbps.

While there are similarities within the videogame industry, one has to understand that the plight of a developer is no where near as tragic as that of an animator in Japan.

For a developer, the skills learned for working in the videogame industry are highly transferable to better paying jobs outside of video games. Skills learned on the job are also equally valuable outside of industry. When a developer is ready to leave the videogame industry, they have skills that are in demand and are able to get positions equal to their experience.

For a 2D animator, keyframing and tweening are not well-payed skills outside of the anime industry. Skills learned on the job are equally not well payed. When an animator is ready to leave the anime industry, they have to start at the entry level of whatever new industry they're entering.

To find that the last few years of your life are deemed meaningless by the job market after working your ass off day and night... That is a real gut punch.

GMail absolutely caches images. The cache is primarily for performant delivery of data over mobile networks though and reduced load of repeat same-day viewing, and less for privacy.

While their cache is large, it's not infinite. If what you're interested in is whether a customer engages with an email multiple times over a few days, you'll likely get the pixel hits to confirm it over that time period. Of course, as you imply, you wouldn't be able to collect how many times an hour a single customer has viewed an email sent to them.

Eh... Not really... It's pretty easy to generate a unique image url per customer and use that to determine whether a customer opened the mail or not and it's about the same cost as a traditional tracking pixel, complexity-wise.

Depression and medication side effects I'm still working through. There's an intense fog that forms in my head when I try to think through a problem that didn't use to be there. Even problems I've solved before I have much greater difficulty with than I remember having.

I wish it were so simple. Usually, to get data from switches you'll have to poll them via SNMP. Polling via SNMP from a production network usually requires a lot of finagling and working with the network engineering team to expose IP addresses of the switches to be polled.

Brian Brazil (one of the co-authors of Prometheus) wrote an snmp polling tool to use along Prometheus (snmp_exporter). You'll have to find the snmp index file that matches your switch. If one doesn't exist... You're in for a hellscape of snmp probing and determine what is where. On top of that, switch manufacturers regularly do not test snmp values upon firmware releases, so bugs crop up at the counter level regularly between firmware versions. At my last job dealing with this, we when back-to-back with firmware snmp bugs with juniper qfx10ks where counters were regularly off by 1 terabit (easy to work around) to interface data not being exposed via snmp so all reported values were zero...

The bright side is once you have SNMP polling working for networking gear, it's not too hard to extend to power equipment and other data center devices.

While I agree with the sentiment of meeting the developers where they are, I'm pretty sure the upfront licensing costs of Windows would have made Stadia a non-starter. I also doubt Google could have gotten a decent bulk licensing deal for this use-case given Microsoft demonstrating interest in cloud gaming with the XBox Game Pass streaming features.

We also have to remember that even if the underlying tech was Windows, PC games implementing multiplayer can be locked to a single environment like Steam, Epic, GoG Galaxy, Windows Store and not offer cross-play amongst them.

Had a similar problem a couple years ago where I needed to use alternative DNS libraries to troubleshoot issues in a company's infrastructure.

Golang's rules for what implementation to use are found here: https://golang.org/pkg/net/#hdr-Name_Resolution

A really solid alternative DNS client implementation can be found here: https://github.com/miekg/dns. Real easy to read and vet compared to a few other libraries I ran into when working on this problem.

The answer is that it works pretty similarly, but GPUs usually do this in specialized hardware whereas mmap'ing of files for DMA-style access is implemented mostly in software.

https://insujang.github.io/2017-04-27/gpu-architecture-overv... has a pretty good visual of what's doing what for GPU DMA. You can imagine much of what happens here is almost pure software for mmap'd files.

My family has owned Lexus cars and dealt with dealers along the east coast for 30+ years. Maybe we've been lucky all along, but every one of them have provided similar experiences like the one described in the OP. Purely anecdotal but maybe there's a trend in Lexus to have great customer service at dealerships. I wouldn't be surprised to discover that there is a crappy Lexus dealer, but my experience in Pennsylvania, Massachusetts, and Florida indicates otherwise.

I think ineffectual is wrong here, re: Trump. By State Department metrics alone, we pay more now for less people and less passports processed than before Trump took office. Anecdotally, we tend to have less State department representation at trade and industry conferences around the world. It's not very clear to my why we're spending more on the State department under Trump than any year under Obama if we're doing less with it...

You can compare the financial reports on their website: https://www.state.gov/plans-performance-budget/agency-financ... and https://2009-2017.state.gov/s/d/rm/rls/perfrpt/index.htm

It's not unusual for a server to also be a router in a layer 3 link aggregation setup. It's extremely common for IPs to be load-shared amongst servers using ECMP. If each server is connected to 2 Top-of-rack (TOR) switches and advertises the route to the shared IP through both TORs, you can very easily have ICMP probes used for PMTU take the wrong route and be dropped. The result is a TCP session with a default MTU that may not work along all traversed paths and will suffer from fragmentation.

I'm not sure this statement is generally true for Netflix's use case.

UDP provides no out of order packet handling which _needs_ to be handled for video streaming. UDP is by default unbuffered throughout transport and tends to cause greater stress to client systems since they need to respond per packet rather than per traffic stream (IP+port combo). As a client developer, you end up reimplementing 90-95% of what TCP gives you out of the box at great development and QA cost. You also drain battery on mobile devices with all the interrupts your causing doing UDP. The upside with a UDP-based implementation is the latency from server to client display is usually much less (tens of milliseconds vs hundreds to thousands), but the trade-offs involved are almost never worth it for a static media streaming site like Netflix.

Even dynamic media streaming sites like Twitch rarely dip into UDP server-client implementations unless there are some unusual requirements.

You might wanna look at using something like zap instead, as it enables you to do runtime loglevel changes...

Discord attempts to monetize by offering a sales platform for game developers integrated into their chat server.

https://discordapp.com/sell-your-game

Collusion is when the parties coordinate on the price increases. If they both increase prices independently to achieve profitability, then I don't believe that to be illegal.

That's easy to say in general.

However, in the case of mitigation of a Denial of Service attack, using IP blocking is an effective temporary measure.

From my experience in dealing with HTTP DDoS-style attacks there's usually a pretty consistent block of IP addresses where the attack originates from, i.e. an AWS or Hetzner IP range. When the choices are to block IPs temporarily or have the entire service go down due to resource exhaustion, the choice is pretty clear cut.

We'd implement the block to keep our service up then report attacker IPs to AWS or whoever maintained the range in question. As the attack waned, we'd re-enable the range.

Of course, IP blocks usually did not work as well with udp-based reflection style DDoS mitigation, but we'd still see certain IP ranges responsible for significant portion of the attack.

We ran our own hardware though, so resources like CPU and inbound bandwidth weren't elastic enough to outpace an escalating DDoS past 120-140 Gbps. We also eventually moved to adding DDoS mitigation through third parties like CloudFlare.

It really depends on the conference.

Ones like Strangeloop out in St. Louis offer an incredible diversity of talks, topics, and forums offered: from language deep dives and workshops to architecture talks to rather arcane talks about modifying an automatic sewing machine to print jpegs onto sweaters and more casual forums on topics like validating resilience and durability guarantees of different datastores.

Ones like Google's series on GCP are exactly as you described though.

If you have your own dedicated IP range and you are advertising routes correctly, then you're as close to ownership of your IP addresses as Google or Facebook are of theirs.

ARIN and RIPE control allocations, but do not control routing to allocated ranges.

Even with peering in place behind the scenes, cloud providers would still usually charge for egress from storage and cdn services to a provider like cloudflare.

What Cloudflare et al are doing here is utilizing the peering connections that they have already in place and not billing at the usual egress rate when traffic routes over these peering connections.