No need to edit aircrack-ng, WireShark does what he did natively (filter out and set channels), and a good realtek chipset allows you to set the scan interval so you can cover more channels (which is why the new ALFAs suck).
Also the DTIM and keepalive can be set such that the MCU can sleep while the phy link maintains a connection without a costly handshake, esp. if using TLS <1.3 to talk to the cloud. Reconnecting costs a shit ton of energy so they usually don't disconnect.
Hacking Wi-Fi has become exceptionally more difficult, as noted by the slow dating of materials at DefCon's WiFi Village over the past 8 years: cracking WPA2 is basically so hard no one bothers, even in CtF games.
Funny you mention Electron: my company switched from Qt to Electron because it opens up a larger pool of developers with instant cross-platform portability with a fraction of the debug overhead.
Before I start, let me state that I am familiar with the notion that there is no such thing as "digital" electronics: everything, ultimately, is analog. I'm focusing on what I have observed in over 4 decades of segregation among engineers, but students and professionals.Considering the typical dichotomy of circuit types: memory, ALUs, VPUs, state machines on the digital side, vs. sense amps,...
That's what is meant by "cult of personality."
Silicon startup challenges are rough. RISC-V is probably the best hope for a new architecture (hint: its not a new architecture).
I worked for such a CEO. In the first year we had four week-long retreats to: an island in WA state, Palm springs, Austin, and Banff (that's where the stats team was). TONS of swag. Aeron chairs. New MBPros. Oh, and champagne fridays. Needless to say it burned through it's good will seed round in 1 year, and the CEO begged for another year's worth of money from friends before shuttering. But hey, hype sells in the software world.
I've been programming with promises for several years now, and I find myself using a common pattern of adding a race timeout promise. It seems like a useful feature, why isn't it implicit when dealing with deferred execution? I run into very few cases where an infinite timeout period makes sense.
I think people don't understand just how badly C++ is broken in reality (vs conceptually) until their paycheck is tied to a real, years-old, multi-developer C++ project. It is not trash talking, it is pointing out truths.
It goes well beyond "any long-lived project has its issues." I think you and I (and many others) know that it is much larger than this, it is a fundamental issue with the language, the standards body surrounding it, and the mess of toolings.
This persists today because C++ is often used to bridge a performance gap between scripted languages and C among younger programmers and academics. (Admit it: we all like that sweet sweet dopamine hit when we take our Python to C++ and the syntax is almost the same.) But that slight performance boost and that "hey this looks like Python but it's really C++" feeling are soon demolished by the accretion of unresolved issues which have enumerated ad-nauseum on HN, including this article.
I've been working with C++ since 1993 (I got a big Borland C++ Compiler as an intern plus 12 VHS tapes of Bjarne himself explaining the language)... my experience with C++ continues right up to today as a contractor having to deal with Arm mbedOS (even Keil struggles to manage hypersensitivity, GNU is a trainwreck for embedded C++) and Tensorflow/OpenCV... and C++ has yet to shake off its flaws. In fact, I think it has added to them exponentially.
For years, I have spent countless hours in and out of work learning new computer and electronics skills. From embedded control systems and building op-amp PID filters, from signal processing circuits to learning every new JS framework and boutique language like Go, Swift and Rust; frontend, backend, devops, AWS, digital ocean, Azure... to re-reading new versions of books on the Linux kernel and...
What is it like talking to a 9 year old who has completed a 4-year EE degree?
Can you walk up to the kid and say, "Hey, solve this bridge/op-amp circuit's transfer function?" or ask a humanities question, "What are the ethical dilemmas inherent in an open discussion forum?"
I guess this is what it feels like to be a young-earth creationist: I simply cannot wrap my head around a 9-year old being able to answer these question, so like a creationist I choose to believe it is a fake.
(You didn't by any chance sail around Cape horn in 2016? I met this really cool older couple in Central America who had been living at sea for 17 years.)
Reading all of the replies I realize that sometime between 2007 and 2012 I just gave up entirely on storing media locally. I don't watch movies (e.g. no cable or netflix), but I've been using spotify for a decade maybe? One response makes a good point: it is a waste of overall bandwidth to stream content.
(the kool-aid)
That author had to jump through so many hoops to make an argument his chiropractor must be rich. Seriously, that entire article was nonsense from top to bottom.
For such an in depth example you really missed this.
I make $100,000 in year X. That covers two brackets, and my effective rate is, say, 25% federal.
SO I have 75k left over.
I invest 5k.
It doubles to 10k.
I'm then taxed on the 5k I earned. Not the 5k I invested.
But do go on about double taxation.
Correct. Which is why income is such a miniscule fraction of the 1% (and above's) earnings. It's all out there in the open. Pick any CEO in the top-100 corporations. Look at their income. Then look at their overall earnings. The bulk falls under capital gains due to stock. Then there is deferred compensation, where taxes are lowered even MORE if you agree to postpone being paid. There are so many clever ways for the very very rich to avoid taxes it boggles the mind.
So go ahead and keep talking about the income tax, they've got you distracted.
I use Keil, IAR, Renesas's compiler, XM8/16/32 from Microchip, and GCC.
Which do you use?
One of the main features of C++, its object-oriented stuff, is built on top of constructors and destructors -- aka dynamic memory allocation. This sort of thing is not desirable on deeply embedded systems due to resource constraints and the very real spectre of heap fragmentation -- embedded stuff tends to rely on static memory allocation done at compile time or system startup.
C++ isn't quite as portable as C -- Not just the compilers which never quite supported the same combinations of features -- even if you just stuck with the ISO-ratified features -- but the language runtime, standard [template] library, and headers are far larger with various implementations including plenty of mis-features and quirks. All of this meant that it was quite common for C++ code to not even compile with a different toolchain -- especially when templates were used -- and even if it did compile, it might not actually function correctly.
If you restricted yourself to avoid the problematic areas of C++ (eg not using templates or dynamic allocations) you'll end up with a language that is basically C. So why not just use C? :)