nuand

https://sat-smt.codes/ is the best introductory to expert, and reference work I've ever read on SAT/SMT solvers

I just ran these past OpenAssistant and I'm seeing a much higher error detection rate. I've tried 6 so far, and it's caught bugs in about 4. OpenAssistant actually had a very good technical explanation of the bug it found in the BubbleSort example.

Wifi is a pretty difficult protocol, but fortunately Linux ships with mac80211. So all that is needed is an SDR based PHY such as https://github.com/Nuand/bladeRF-wiphy/ .

The "fix" Intel pushed out this week is a microcode update that in my experience doesn't fix or address Meltdown at all. The update does however make Spectre slightly less reliable, so I'm going to assume that the microcode update has something to do with fixing, updating, or adding new controls to the branch predictor buffer.

So absent a microcode update that outright fixes Meltdown, there will always be some level of slow-down for vulnerable devices. System calls now jump from user mode code to a stub kernel in "supervisor memory". The stub kernel then does a full context switch (touching %cr3 paging register and wiping a good portion of the TLB), and once the real kernel finishes, it does a full context switch back to the stub kernel. It's all terribly inefficient, and realistically it's unlikely that there will only be negligible performance impacts. It should also be noted that this "work-around" doesn't fix processor, it just makes it so that that there's nothing juicy in the supervisor memory.

You may have to learn to live with this for a while. Even if it takes Intel a month to design and validate a fix for Meltdown, prototype and mass production turn around times mean that no customer will have a processor that isn't vulnerable to Meltdown until April-June 2019.

Nope, it's all in the MAC and additional usermode services that help phones identify to the network using, in most cases, its SIM.

Eventually yes, we can expect to see optical in desktops. Fiber connections are "better" but also much more expensive. The price should eventually come down as volumes increase. The main delaying factor is that copper is still good enough.

Multimedia is the driving force behind increased data usage, and I think we'll continue to need more throughput until we no longer get any benefits from higher resolutions (aka when we have substantially more pixels than rods and cones in our eyes). At the moment a phone with a 4K display saturates your eyes at any distance greater than 2 feet from your face. I think a 16x PCIe 4.0 link will likely provide more than enough bandwidth to generate fully immersive VR experiences, so the question then becomes... why and when will we need optical PCIe 5.0 to quadruple the datarate of PCIe 4.0...

Take a look at slides 9 through 15 of this presentation: https://pcisig.com/sites/default/files/files/PCI_Express_Ele...

PCIe signals are generated by transceivers -- devices within chips that are specialized in signal conditioning e.g echo cancelling, emphasis/de-emphasis, dynamic impedance matching. These transceivers and the analog and digital techniques they implement get better with time. This is easily measurable by looking at the Bit Error Rate of data or by looking at eye diagrams (see slide 15). As data rates increase things like drive strengths, impedance mismatches, and a number of other properties of silicon will "close the eye" meaning the transmitted "0"s and "1"s are not different enough for them to be distinguished by a receiver enough of the time to successfully decode a packet. (PCIe is packet based, it's surprisingly somewhat similar to Ethernet). But essentially as our understanding and processes for manufacturing semiconductor devices increase, we're able to "open the eye" more, at which point the industry decides to increase data rates.

$6.9 billion? sounds like this fire is razing quite well

The Google ads ban does not affect players like LendingClub/SoFi/Avant since they are long term loans with interest rates similar to credit cards.

Yea, I am too

Been working on this for a few months, and just added the finishing touches. It's a high performance ADS-B receiver that can detect and correct multiple bit errors and packet collisions. The FPGA offload allows a Raspberry Pi to process samples in realtime, where as a recent i7 would not be able to keep up without the hardware offload.

I'm planning on doing a mini series explaining the MATLAB, C, and VHDL design flow behind building a high performance hardware modem. The first article can be found here, https://www.nuand.com/blog/bladerf-vhdl-ads-b-decoder/ Questions or suggestions are welcome, I would like to use them to improve my writing style and this mini series!

Yes, you are correct. Some parts of LTE and WCDMA use a pre shared secret and rolling keys to allow UEs to identify themselves to the mobile network. There are however many non-data carrying parts of LTE that are not encrypted or authenticated, sort of how 802.11 has AES but management frames are still fully unecrypted.

It will depend on the material, but I don't think 802.11ad can even penetrate through sheetrock. Honestly it may even be so bad that a sneeze could knock your connection out for a few seconds.

The laser analogy is definitely accurate given today's technology. I just don't think they'll be able to productize something that has that high of an antenna gain. I'm really hoping and thinking that we'll see some smart antenna advances.

60GHz also limits you to direct line of sight. 60GHz propagates similar to a spotlight.

The "statistic" seems to make a point that taking a bet on a strategy and losing is incompetence.

If you want an introduction to assembly with the hopes of achieving super complicated in the future, I would suggest taking a look at the Intel manuals [1]. Volume 1 specifically offers an overview of the processor's architecture and underlying components (registers, ALUs, branching); it's actually a pretty useful textbook. Volume 2 walks explains each and every single instruction and what it does. Volume 3 is a programmer's guide to the Intel processor, which is what might help you quite a bit, it provides examples of using stacks, function calling, memory management, and SIMD instructions.

[1] https://www-ssl.intel.com/content/www/us/en/processors/archi...

Monitor mode is a MAC level concept, and doesn't alter any of the RF characteristics that would make operating this device illegal. (This is not legal advice. Consult with an attorney, etc etc)

OFDM 802.11 rates already have a significant amount of Forward Error Correction. 802.11g uses a convolution encoder and Viterbi Decoder [1], and 802.11 HT rates (n, ac, ad) can also use Low Density Parity Codes (LDPC) [2]. The problem with Forward Error Correction is that it can't deal with too many sequential errors, so many modems use something known as an interleaver. An reorders bits as they are sent over the air, so instead of sending LSB to MSB or vice versa you are sending bits in a random yet mutually known order. This causes link quality issues such as interference to not interfere with continuous bits (to the benefit of the FEC decoder). The problem with an interleaver is that it causes latency to go up. If you interleave based on 256 bits of 2048bits, you can't decode blocks of data until you've received all of this bits. So the 288 bit interleaver that 802.11 uses won't cause many problems if you're streaming but if you are interleaving data across multiple packets you will notice a spike in video latency.

[1] https://en.wikipedia.org/wiki/Viterbi_algorithm [2] https://en.wikipedia.org/wiki/Low-density_parity-check_code

OpenBTS and YateBTS need a full-duplex radio to function. So far only Ettus radios and bladeRFs [1] have those capabilities. The bladeRF is also the cheapest option, costing in the low 3 figures (with coupon code HKRNWS). Full-disclosure, I make the bladeRF.

[1] http://nuand.com/bladeRF

Cellphones are half duplex but the basestation is generally full-duplex. A half-duplex basestation could probably handle no more than one cellphone. OpenBTS and YateBTS, as well as most commercial basestations, have design patterns that require tight timing capabilites that in turn lend themselves to running on full-duplex basestations.

The options, RSU, and NSO packages remain as-is. The only thing that changes is the tax situation. Excercising options after a stock is publicly traded is viewed and taxed exactly as income.

Would anyone use Altium, KiCad, or Eagle if they had access to OrCAD, Allegro, or PADS?

Having used all of those tools, I can say that KiCad and Eagle will remain relegated to the low layer count, and at most moderately populated PCBs. Altium still has issues with large designs, but it's got its advantages, it's very easy to work with industrial designers within the Altium ecosystem. Altium also supports some decent auto-routing and DFM tools but does not have a simulator of any kind.

Cadence's OrCAD and Allegro offerings, and Mentor Graphic's PADS suite have tools for everything from designing with microvia (laser etched single layer vias) to highly configurable constraint management tools that allow for configuring some very powerful auto-routers and interactive tools. The big two tools also have simulators like PSICE, and integration with RF design tools like Keysight ADS, Genesys, Momentum, Hyperlynx, and HFSS. If your design has any RF components or high speed buses like DDR, PCIe and USB, you need to run your designs through these tools to verify your design. Eagle, and KiCAD are great for breakout boards. Altium can be used for some pretty simple products. But I'd never use anything but Cadence or Mentor Graphics tools for anything that had a signal that operated at more than 50MHz.

Zimride came first and eventually changed its name to Lyft. Zimride offer a carpooling ride sharing matching service.

Seems like an interesting approach. However the 21x speedup seems a little underwhelming considering the speed of the Zynq's programmble logic fabric and how parallizable NNs are. They're quoting a 21x speedup over the ARM processor on the Zynq 7020, which is on par with what powers the RaspberryPi 2. My guess is they didn't pipeline their design enough or appropriately causing one of the datapaths to significantly limit their throughput.

From the article: "Banks say interchange fees help cover the cost of fraud. Retailers argue that fees should therefore decrease if fraud is reduced."

In my three year history of taking credit card payments online there has never been a time when I was not made to bare the entire cost of the chargeback plus Stripe's chargeback fees. So I am wondering When, if ever, does the bank or the processor bare the costs of a fraudulent purchase?

OpenBTS, YateBTS, OsmoBTS, and Osmo-BB are already doing some pretty interesting things. They could interact with existing networks if the devices running them could be FCC certified.