Shorter and more secure alternative with elliptic curve zero-knowledge proof - for example with a 160bit curve you could have a 240bit (30 byte) licence key comprised of a 160bit field element and an 80bit hash.
HN user
meta_AU
Making test points for all your testable functions and aligning them to a stripboard really simplified making a testing jig. You can solder some pogo pins to the strip board and just press each board to your jig to program/test it.
Also, I've found renumbering passives to keep the same values in contiguous groups to simplify hand prototyping. You end up having dozens of 0.1uF for example and it's nice to knock them all out instead of switching between different components
The algorithm for the first example reads just like an implementation of a SAT solver. Set a variable, propogate clauses, backtrack on conflict (learn new 'rule' from conflict).
Maybe add a definition of 'risk' in the quick summary. It tends to man different things to different people, and linking back to a definition (e.g. the effect of uncertainty on objectives) helps keep discussions on track.
the same way that if you lift for 3 months, it achieves nothing.
I'm probably missing the point - but that first 3 months of training is where you make the fastest growth and can double the weight you lift (from untrained to novice). Sure - you aren't going to compete at a world level after 3 months, but it doesn't seem right to describe it as 'nothing'.
Misleading title, should be changed to 'Why we moved from flopnax to rilkef and you should too'.
For some of the unsupported targets there is the Rust->C compiler. Haven't used it myself but I've seen that, for example, the ESP32/ESP8266/Xtensa is supported by it.
From memory WeChat verification only allows one verification every few months (and only if your account is old enough). In theory you can get a hostel employee to verify you, but they have usually used up their verification for that quarter.
A useful example project would be an FFT or OFDM accelerator for a microcontroller. Most microcontrollers really struggle with FFT so it is an example where a small uC and a small FPGA can be cheaper than a large uC. Sliding window FFT is going to be another good example where the FPGA option is competitive.
Sometimes 1.1.1.1 is used as a testing value, and can get blocked for reasons. CloudFlare is getting a huge amount of spam IP traffic to 1.1.1.1 from misconfigured equipment, it wouldn't be too surprising if some upstreams have firewalled valid IPs.
Probably also because ammonia is polar, three positive protons and an electron pair in a tetrahedral arrangement. Whereas H2 is two protons hiding an electron pair in a linear arrangement.
Circa 1992.
Listened to American Kingpin on audiobook during a recent trip. It was pretty entertaining if anyone wants more information on this topic.
If you have a look at any Zachtronics games you can see one way of doing it. It is just a leaderboard represented as a histogram. A separate one for instructions, cycles, etc. No need to know the best, just keep track of what other people have achieved.
It depends how often you want to update things I guess. A wildcard costs less than $50 a year these days, so if that might be better for some people than renewing their LE every few months.
The other option is to register a domain and use that to get either LetsEncrypt cetts or purchase a wildcard.
Additionally, the accuracy of the PCB fab when drilling holes is going to be better than when routing the edges of the board. Just need to ensure you pick a hole diameter that matches the fabs drill sizes. (and oversize the hole a little or the fit is going to be very tight)
I'm not really following the trapdoor reasoning. Both RSA and elliptic curves are based on having a system where 'exponentiation' commutes and the 'logarithm' is computationally difficult. RSA only needs the two generator primes to make finding the 'inverse' of the e exponent computationally tractable, once that is done the 'trapdoor' isn't used any more. There isn't an equivalent of that in elliptic curves in my understanding of them.
From memory, GCC does one NewtonRaphson iteration on the approximate result so the error is much lower (closer to e-9 from memory again). They don't use the approximation directly in fast-math mode.
Sure,but you are judt bolting one heat engine to another (the motor). I'm assuming the efficiency of the motor is better than the TEG (generally the case), so why not just draw power from the motor instead?
This technology is probably more applicable to situations where you have a source of low quality heat and you want to extract a tiny bit of power.
It is the inverse of the square root. If you want to normalise a vector, you divide the components by the length. The length is the sqrt of the sum squares (Pythagoras). Divide is more expensive than multiply. So get the inverse sqrt of the sum of the squared components, then multiply the components by the inverse sqrt.
Heat engines generate work (power) through the movement of heat from hot to cold. Conventional systems (steam turbines, Stirling engines, regular thermoelectric generators) require a temperature difference of much higher than 5C between hot and cold, which limits the situations they can be used in. This apparently can work at much lower temperature differences than other systems while generating 'useful' amount of work.
Anyone trying to work out if Mikrotik has some equivalent of this SQM, looks like no. Well, not explicitly fq_codel or any extensions. Though using the sfq queue system with traffic shaping seems to give the same improvement to bufferbloat.
When reading through the problem statement I started wondering why a distributed tracing system, like Zipkin, wouldn't work. A microservice architecture seems very similar to most reactive programming systems, and distributed tracing is just the equivalent of some really nice tooling ontop of printf.
Seems like a debugger for reactive systems should be let you attach to a running graph and extract/visualise traces.
Running K8S on other environments isn't a difficult job, but you do need a certain level of experience running systems. You need to set up EtcD, in prod you have 3 or 5 of them - there are a couple of topologies for running EtcD and peer discovery (you will need to RTFM). This is all your K8S state, so you need to set up backups for these.
Each node you are going to include in your cluster needs to have docker and kubelet running. You will need to start kubelet with your init system (systemd, etc).
Then all you need is to bootstrap a control plane. The control plane has 3 components. The API server needs to communicate to etcd, everything else just talks to the API server. The API server is stateless and can (should) have multiple instances running. The other two parts are the Controller and Scheduler. Also stateless. The tool Bootkube[1] can generate all the configuration and perform the bootstrapping for you.
To answer your dot points, all but 4 are easy enough with using the kubernetes docs and some systems/networking knowledge. Point 4, assuming you mean starting new machines based on load, will require you to look at which systems are supported by the autoscaling system and potentially add an integration for your environment. There is the horizontal pod autoscaler that will run more of your service when needed and the cluster autoscaler[2] which will start more machines when it can't run as more instances of your service on the current number of machines.
Edit: There are also tools like Patroni, Stolon, and postgres operators that will assist with your DB (postgres in this case) management. Scaling, HA, backups, etc.
1 - https://github.com/kubernetes-incubator/bootkube
2 - https://github.com/kubernetes/autoscaler/blob/master/cluster...
I've always liked how K8S release notes come with a series of blog posts doing a deep dive into each feature. But when I think back on it, because they come out after the release announcement I end up forgetting about them until the next release.
I wonder if releasing the posts in the period leading up to the release would be better, or if that would just lead to artificial delays on the actual release.
I used to worry about being over dressed or underdressed for interviews or events. At some point I just decided that I'd never looked at someone else and considered them to be overdressed, so maybe there is no such thing. Dress in what makes you feel confident while also avoiding being underdressed. If you have a suit and the other person is in a t-shirt, they are more likely to think "looks sharp", or "they are taking this seriously" than anything negative (as long as you don't appear to feel uncomfortable in what you are wearing).
Shorthand for 1.7kW or 1,700 Watts. The shorthand is common in some fields, I've mostly seen it in electronics where you might have 4k7 to represent 4.7 kOhm or 4,700 Ohms.
xip.io is one service that will wildcard for any IP address.
Is there not any issue with having a hashed version of the email, given the entropy of an email address is quite small?