quackerhacker

If Discord is basically proxying the raw packets from one client to the others, isn't that wasted bandwidth (for discord, not the clients). I understand from the post that the goal would be to mask the ip of the users, to shoulder user privacy and the ddos vector. Kudos on silence detection to save overhead.

So video w/audio broadcasting has to be compressed client side, then proxied through Discord's media servers, to the end user's. That's pretty smart...I just wished that I could send my raw stream to a LAN host so I could offload the compression, and allow my LAN host to provide delivery (I'm a nitro user).

So I have an affection for Discord...so I appreciate posts like this.

>"Using the WebRTC native library allows us to use a lower level API from WebRTC (webrtc::Call) to create both send stream and receive stream."

So I'm gathering that discord's voice servers receive multiple persistent connections, then compress the audio streams for delivery to each end user. THIS part is where I can't imagine the on-the-fly cpu usage. Each client's receiving compression needs to also negate their own audio to prevent an echo effect (no point to hear your own voice), but it also means separate compression streams per user.

>" All the voice channels within a guild are assigned to the same Discord Voice server."

I imagine this helps significantly with I/O in converting live streams into 1 stream per end user. I've dealt with video compression (only in ffmpeg) and live syncing time stampings, and I can say from experience that, this is no easy feature. I understand this is audio streams (so lower overhead), but still the persistent voice server needs to handle the incoming connections, web socket heartbeats (negligible), compression (high I/O), and deliver the streams (high memory usage too).

I'm impressed, but would love to hear the specs on the media servers and their DL/UL speeds. My old setup to deliver live video (in sync and compressed) was 6 mini-itx's, 4GB of ram per board, and i3's...my bottleneck was my isp, which I solved with multiple docsis modems and an internal switch (each board had 2 ethernet ports).

>"The overall goal: to ensure at least 100,000,000 Americans had access to broadband speeds of 100 Mbps by 2020. As it turned out, providers blew past that milestone as early as 2016."

First gripe....why oh why could they not make that goal for a symmetrical 100Mbps and not just focused on the DL speed.

If the push is to 5G, I'd welcome it, if the mobile carriers opened ports on consumer plans. I've cherished my coveted unlimited iPad data plan with att used in my mifi with a yagi that points right at the service tower. It regularly sees over 250Gigs a month (check my twitter for that pic).

It takes about an hour before I can start churning clean code and start any code reviews, so I think I’m ok. Really, it’s the 3 in the afternoon feeling that is the drain for me. Alertness fades and I can’t even listen to music without an occasional syntax error.

As a coder, the only real drug I’ve ever really needed has been caffeine. This didn’t start until recently so I’m not sure if I can attribute it to age (early 30’s). My real dependence on caffeine is mainly due to staying up too late the night before (like right now, about 0200 here) and needing to get up and function with 5hrs of sleep and maintain my mental acuity for the workload I have.

To give you an idea of my caffeine intake...about 2 venti black coffees and an 8oz Red Bull.

> "I’ve been able to almost double it by adding a ferrite sheet to the back side of the stator coils to contain the coils’ magnetic field lines."

I never heard of a ferrite sheet, completely awesome! I liked the article, but IMO the title is a little misleading. What I gathered is that he 3d printed the rotor only. I'm assuming the actual 4 layer pcb was etched. The rotor was still wound manually. The hall sensor still soldered by hand.

The print notion implies production automation, which is my only gripe. His hackaday has a more accurate title "PCB Motor".

> “Tell me something good” isn’t meant to be a magic solution.

From a user aspect, I'd imagine the news that's curated to me would be arbitrary. A better phrase for Google to listen for is..."What a shitty day." Then Google could counter with "today may have rained shit for you without an umbrella, but these people are enjoying sunshine."

I'd laugh from the sarcasm, and who knows, it might drive up some sales for Google after I break my Google assistant and have to buy a new one.

Needless to say, I prefer laughter as my cure all over positive news that makes me look on the brighter things. On a positive note to my fellow HN readers....HAPPY FRIDAY!

I don't see that implication in the article. I think you're referring to this part "your guys were detected. They were trading with very big money and there was a lot of fuss about them, about how it’s not the season and when it was the season they traded."

This excerpt most likely implies that the inside trades were for commodities (future contracts) and was sent to one of the relative people involved in the hack.

What would be irony (but of course is speculation) is if any of the brokerages that the hackers submitted trades thru did front-running (matching their trades at entry).

There absolutely has to be tech analysis of a trader's entire portfolio or majority of their trades in order to really investigate before it passes off to human review.

The real beauty in this statement is the merging of fundamental analysis (news releases, ect.) with tech analysis. I don't mean tech analysis in the context of pivot points, sma's, rsi's, ect...I mean tech analysis on the evaluation of the winners of a significant price movement and their entire trades and current portfolio. THAT is the mind boggling algo.

Just b/c a trader makes x amount on a move doesn't mean they had privileged info. A tech eval has to eval their entry and exits to see if they were prime/ideal moves and most importantly their order size and order type, but it ultimately comes down to pattern evaluating their order history across multiple assets and see if their transaction history is generally successful and positions are taking prior to news release...then flag for human review and substantiate evidence.