bkanber

It's really tough. I bet that a good % of failed early stage startups fail because the founders simply can't keep up with the rejection and negativity.

The simple truth is you just have to keep trying, for years and years possibly, before something really hits.

Try not to think of them as rejections. Re-frame it as "this person isn't the right user for us right now." That removes the emotional bent from it, and maybe will force you to ask the question of "who IS the right user for us right now, and who's the right user for us tomorrow?"

> Weeks

I'm sorry, but even with things getting rushed through by regulatory agencies, you cannot expect prelim results to convert to treatments in only a matter of weeks.

That's not how bitcoin was marketed in the early days. And I don't trust it even remotely as a long term store of value.

It'll just be yet another technical advancement that we have to adapt to. And we will.

What gives me comfort is that there's still an operator with a motive. It's funny, as I was reading your comment I half expected it to end with "this was generated by GPT-3". And it wouldn't have mattered, because you-the-person still had a sentiment or a message you wanted to communicate, and then you communicated it, whether or not you actually wrote the message.

It _would_ be better if support chat understood me better and could communicate with me better. Because again, the motive is understood and aligns with mine. I don't necessarily need a human to do the typing. Typing is a lot of work.

In your example, marketing campaigns will continue to be marketing campaigns. I don't worry that the bots will flood your sub more than they already are; if they flood it too much, they destroy any value they hoped to leverage in the first place. The only difference will be that the language in between the spammy links will be more readable.

If someone on a, eg, adult chat forum is whispering sweet nothings at you, again I don't care if an AI wrote the prose; someone still decided to whisper sweet nothings at you. They just hired GPT-3 to do the writing instead of doing a sloppy job themselves.

I think the real problems start when the AI decides to initiate the action. When an AI, not explicitly instructed by a human operator, decides to launch a marketing campaign. That's the dystopia I'm worried about.

Are you perhaps referring to mini USB? USB-C is already reversible.

Usually you can only go after the leaker or anyone republishing the IP. Simply having access to it isn't a crime. Perhaps they could issue some sort of takedown notice for the schematics.

I took it to mean "unofficially and as an outsider".

Here is Bezos' mandate from 2002. Quite prescient: https://jesusgilhernandez.com/2012/10/18/jeff-bezos-mandate-...

Day trading has been a problem ever since it was invented, 45 years ago.

Robinhood is not the first. The whole concept of day trading already "gamified online trading into an addiction", and that started in 1975 and had its peak popularity in the 80s. The author is really just complaining that this gamification is now in app format.

Yes, Electron is a bit of a battery hog. But the Slack app itself is horrendous. If you read through their API docs and then try to figure out how to recreate the app, you'll see why. The architecture of the API simply does not match the functionality of the app, so there is constant network communication, constant work being done in the background, etc.

The nice thing about batteries is that you can add them up to whatever voltage you need. Common electronics voltages are 5V, 9V, 12V, 18V, 24V. You can achieve all of these with different numbers of rechargeable AA or 9V batteries.

However, because of the variety of projects you'll do, to use a wall power source you'll need either a variety of adapters of different voltages, or one of those expensive multi-voltage power adapters, or a proper bench power supply.

So, yes, one of those 5V or 9V wall adapters is perfectly fine to use. You simply buy the female portion of the adapter and connect it to your circuit. However, if you do end up exploring multiple projects early on, using batteries will reduce the amount of new expensive gear you need to buy.

I experienced the same issue when I was in college. I discovered that the way to learn for me was to find a niche category of projects and do them on my own. I actually wrote a blog post about it a while back: https://burakkanber.com/blog/how-i-taught-myself-electronics...

No no, that didn't sound aggressive at all! Though I still wouldn't say the project was trivial, just very limited in scope. And had I done everything perfectly -- meaning, being able to stream code from my head with no errors -- the project may only have taken 3 hours. That's how small it is. I think the finished product is 800 lines of code, server and client together. It's conceptually very small too. (Maybe this is a 'veteran' skill as well, being able to keep things small.)

My point is that a whole 75% of the time I spent on this project was just me flailing around with stuff that wasn't working as I expected (that's relatable at all experience levels!). Perhaps it's true that veterans can get through certain things more quickly than novices can, but we're not immune to the 80/20 rule either! We just get stuck on different types of problems.

Good suggestion, I will have to try that out!

That's a good point! I did not need to relearn core concepts.

The bulk of that 12 hours was actually spent debugging negotiation and timing/race issues in the signaling/SIP layer. Even for me, figuring out how the WebRTC API is supposed to work was a little difficult.

I've never actually gotten { echoCancellation: true } to work for me, but your sibling comment does have a suggestion I need to try out!

Echo cancellation is a pretty lightweight DSP/FIR task. Whether you do it close to the hardware (? I suspect this is not actually the case with getUserMedia though -- it is still an audio stream algorithm) or in the application layer, echo cancellation requires the same amount of added latency.

But in any case, I did say I suspected echo cancellation would shift to getUserMedia. It's not fully there yet, but it will be.

WebRTC doesn't do everything for you; it's really just responsible for tying together ICE with media streams. Signaling is up to you to figure out. For instance, multiple clients in one room: this is part of the signaling layer and is not WebRTC's responsibility (I built this into zonko.chat if you want to see how it works though).

Closing and restarting connections is signaling layer stuff, ie your responsibility.

Echo cancellation is really supposed to be application layer and up to you as well, but I think this will probably shift to be the browser's/WebRTC's/getUserMedia's responsibility at some point.

Re. TURN: ICE is the process that works out whether a specific client needs to relay through a TURN server. The question is: do you need to implement a TURN server? The answer is: yes, you need a TURN server. If you built a P2P app that you want to work for all users, you will always need a TURN server. You can run coturn on the same box that you serve your app from. Most likely a side project will never hit the scale requiring more than a $5 digitalocean box for TURN.

And yes, it should not be a surprise that products are time consuming to build :) WebRTC is plumbing; you probably were expecting something more like Jitsi.

I also decided to learn WebRTC and built a video chat app project: https://zonko.chat

The last time I did any p2p networking was back in 2002 or something when you still had to do it all manually. We used all sorts of fun tricks like NAT hole punching, and using little script endpoints to capture and forward along port and public IP address information.

It was fun to see that all of this has since been formalized under the "ICE framework". I was surprised to see that the STUN spec is only 12 years old now, despite the techniques involved being used for at least 20 years, probably more like 30+.

So if anyone who's new to this whole p2p world feels that WebRTC and the ICE framework is confusing or onerous, I would point out that just a short while ago these were basically just a handful of heuristic techniques developed through trial and error over the years. It's really much easier nowadays! zonko.chat only took me 12 or so hours to build (and seems to be well-supported by chrome and ff, even mobile).

Edit: Upon reflection, I don't even remember how I learned about some of them. The concept of TURN was probably one that I, and many thousands of others, invented from scratch due to necessity (failed to punch the hole? fall back to this custom relay I wrote in perl). STUN was an easy one to figure out yourself, too. I don't remember how I learned about hole punching though. Probably a forum or a book. Or possibly just an experiment ("what if the two connections touch somewhere in the internet at the same time... hey wait, it worked?") What's interesting to me is that the core "ICE" concepts (hole punching, STUN, TURN) are still pretty simple even in their mature, formalized, scientific form. But the concept of "SIP" is much more sophisticated today than it was back then.

STUN fails under symmetric NAT, not strict NAT. That google document makes no citations of that 92% figure, but I assume that's for desktop traffic only. Pretty much all mobile/cellular connections would require TURN too.

So I have both the 4gb pi and the 2gb one. The 4gb pi does a pretty decent job at basic browsing, but Youtube doesn't really work. VLC videos with certain encodings and filesizes work, others don't. I can infer that the 8gb pi is better, but I would probably not use it as a daily driver.

> No, this is a terrible response.

As an aside, this kind of hyperbole really gets under my skin. It wasn't a terrible response. That statement is already technically correct: GET is idempotent, and the definition of idempotency is that it is harmless to repeat.

Your gripe is that OP didn't mention that GET is not only idempotent but must also be "safe"; i.e. that it should not alter the resource. OP got it 50% correct.

Does that omission make his comment a "terrible response"? No -- just incomplete.

> Am I just getting too suspicious?

Yes, I think so. What's the conspiracy supposed to be here?

It's pretty terrible. ORMs like Doctrine use annotations because their philosophy is that a data mapping class should be a pure class that you decorate with annotations. I personally hate that approach and have had no issues avoiding this path over 20 years of PHP development.

To be fair, I've been working in PHP for nearly 20 years and I've been able to avoid annotations almost entirely, except for that one time I used Doctrine and then threw it in the trash.

My own take on it: https://zonko.chat

My thinking is that you should be able to control where you go and which group you stand in.

As a manager, I've seen this play out both ways. These days, great IDEs (and IDE-ish-s) are easier to find (points at VSCode). But just a few years ago the landscape was a bit bleaker, and I successfully introduced Jetbrains/PhpStorm (and also vim keybindings ;) to many team members who otherwise would not have ventured to update their workflow. They all loved it!

More recently, I've shown devs PhpStorm and, after trying it, they want to stick with VSCode. I'm fine with that, as long as the PRs come in clean and they're able to maintain their development environments otherwise.

I use the term "holographic" for a reason. The HUD appears to be projected at a distance of, say, 20-30', and is positioned low on the windshield so that it essentially overlays on the road. You do not need to refocus your eyes on the windshield. Focusing on the road also focuses on the HUD projection.

No, not at all. The HUD is positioned so that you're watching the near-field road ahead. The hologram is projected so that it appears maybe 30' ahead of you, on the road. The HUD also has minimal information. If nav is off the HUD shows you your current speed and the speed limit only. If nav is on, the HUD gives you a simple map display showing your next turn, and that only appears as you approach. It's a really excellent system. Not at all invasive or distracting, and MUCH better focus- and attention-wise when using navigation vs, say, staring at a smartphone or console display.

I don't know which integrators they're using but an algorithm like RKF45 should handle time acceleration with adaptive step sizes no problem. As grandparent said, n-body is very well-known.

Regardless, KSP's workaround of using SOIs is simple and quite effective.