s_tec

This disagrees with my experience working in this space every single day.

Most projects in the Node ecosystem will continue to use CJS. If you are writing "Node software", like web servers, there is no reason not to just use CJS. It will remain a well-supported and well-used option for as long as Node stays relevant. CJS stays a "first-class citizen" by not changing anything, so you get your wish by default.

On the other hand, activating Node ESM support is a conscious choice. This will typically happen on a project-by-project basis. When I say "project", I mean a single GIT repository, a single NPM module, a single Web site, or something like that. If your organization is big enough to have multiple teams (mine is), each project typically has its own team.

The interfaces between these projects are usually package.json files. This is true even for giant code-bases like Babel that live in a single GIT repo but have dozens of tiny sub-projects. Within a project, people use local file references like `import('./util/foo.js')`. Between projects, people use bare import specifiers like `import('lodash')` or `import('@babel/parser')`.

So, I think it's safe to say that a team decides to switch on ESM support, they know what is going on within their own little world. Their `import` statements can be ESM-only for local files, and they will have zero trouble. Meanwhile, if bare module specifiers like `import('lodash')` rely on package.json metadata, nobody needs to care what the other teams are doing. Any project can enable / disable ESM support at any time, and nobody will know the difference.

This all goes back to an old organizational principle that the boundaries within a company often manifest themselves as boundaries within the software architecture. This has to do with the communication overhead of coordinating changes between teams. It's easier to codify the organization structure into a versioned interface than to face the chaos of just "winging it". In the Node ecosystem, this translates practically into versioned package.json files and bare module specifiers. If your requirements don't take this into account, then I am genuinely curious in hearing what your workplace culture is like.

> This is the situation we don't want to be in, where the consumer is choosing. The consumer doesn't know. Even if you, a human, read the file, you don't know what the author's intention was.

If I am importing a file URI, then I am the author, and I know what it is. File URI's are primarily used for linking together stuff in the same git tree. If I am using third-party code, it will be a bare module import specifier from node_modules, not a file URI.

I agree that there are weird situations where this isn't the case, but you don't need to worry about those. Why? Because module support in Node is a new feature, and therefore opt-in. The people who choose to opt-in know what they are doing, and are probably running a pure ESM codebase already. The goal should be to make something useful to the 99%, and let the other 1% keep doing it the old way.

If you are already using Rollup, then this will be plug & play. Rollup already assumes that everything you `import` is a module, and puts them in strict mode.

> We really can't though, because its already full of files that are intended to be used with rollup/babel/etc, which have incomplete implementations of esm.

That's a legitimate concern. Even if using "module" itself is too risky, but the approach itself seems solid. If I want to publish something to NPM that supports native ESM in Node, it's easy for me to add something to package.json that indicates my support, without renaming all my files.

My packages on NPM have both CJS and ESM entry points. The ESM entry point is for tools like Webpack & Rollup, which do not understand the .mjs extension. I tried using the .mjs file extension for this, and it just broke things. There is no way we can re-write every Webpack and Rollup config file in existence to be compatible with this.

Right. In other words, if you `import` a file with that line, it should crash. If you `require` the file, it will do nothing. The context can determine the file type unambiguously, and you don't need an extension.

> This was discussed, but one of our goals is to be able to know what type of file something is before reading its contents.

The file extension came from an earlier plan where `require` and `import` could be used on both types of Javascript. Now that the plan uses `import` only for modules and `require` only for scripts, you can get rid of the extension.

> our ESM implementation, unlike CJS, doesn't assume that everything it uses comes from the local fs.

Node is `import`ing from HTTP, it can use content-type like browsers do. This is only a problem for local file systems, which don't have content-type. For that, you can just assume everything is a module. If people need to load CJS, they can use `require` (as the proposal above already says).

Bare import specifiers like `import { foo } from 'lodash'` aren't URI's, so you don't need to maintain compatibility with the browser. For this, you can just use the existing [package.json/module](https://github.com/rollup/rollup/wiki/pkg.module) field to determine whether to enter the ESM world or the CJS world.

I know Node rejected the package.json solution back when they were trying to make `import` and `require` interchangeable, but now that they aren't, I think the original performance worries should no longer apply.

Exactly! You have to know whether something is a script or a module before you can parse it, but with this plan, that's always clear from the context.

This is exactly how browsers do it, by the way. If you `import` something, is a module, period. The `<script>` tag is the only place that supports both, so they use a `module="true"` flag to indicate which is which.

I wonder why they kept the ugly .mjs extension. This is a hold-over from an earlier plan, and doesn't seem necessary in this iteration.

This new plan seem to be going down the path that `import` is for modules while `require` is for everything else. If that's true, then they shouldn't need a special file extension for modules - it should always be clear from the context which is which.

The only exceptions I can think of are executable scripts (which could use a command-line option) and packages in node_modules (which can use a special package.json field).

Right, that is correct. To understand how that works, you have to realize that there is no such thing as an "absolute voltage", only the voltage difference between two wires.

In a breaker box, one wire (white) gets tied to ground, and the other wire (black or red) goes between +170 (relative to ground) and -170 (relative to ground). The black and red wires are 180 degrees out of phase, so when the black wire is at +170, the red wire is at -170. This gives a 340V peak difference between the black and red wires, which averages to 240V. You get your normal 120V outlet power between the hot legs and ground/neutral, and you get your 240V dryer & water heater power between the two hot legs themselves.

So, in a normal outlet, we can safely say that one wire is "more positive" than another, and that this flip-flops through time. When we look at voltages relative to ground, though, one wire stays put at 0V while the other goes between +170 and -170. It's just a question of where you put your reference frame.

You are right. Three-phase needs less copper wire for the same amount of power delivery, which is the real reason everyone uses it. It needs less copper because it never has "dead time" where the copper isn't delivering power (hence the desire for constant instantaneous power).

I tried to word my explanation as accurately as I could, but I had to leave out a lot of tricky details for people who aren't electrical engineers. You have to be careful not to mix up regular averages, RMS averages, and instantaneous values when you deal with AC. If you get them wrong, you come to incorrect conclusions, such as the idea that single-phase electricity has zero power. The average voltage is indeed zero, but you can't use regular averages when you calculate power delivery, only instantaneous voltage differences and currents. You get RMS averages when you integrate those instantaneous values over time, and that brings in the the cos(phi) issues you mention.

Regarding three-phase power:

The electrical outlets in your home have two power-carrying prongs. The third prong is just for safety (it connects to the ground), and should never carry power unless something is going horribly wrong. In that case, the power should hopefully prefer to reach the ground through that third wire than through your human body.

Anyhow, the voltage in those two power-carrying wires is constantly switching directions. At one moment, the left wire will be +170 volts relative to the right wire, and then they will slowly switch places over the next 1/120 of a second so the right wire is at +170 volts. They continue trading places, completing a cycle every 1/60 of a second.

At some point in this cycle, the voltage difference between the two wires will be zero, which means that no power will be flowing at that moment (power = voltage * current). On the average, the wires will deliver the same amount of power as-if they had a constant 120 volts between them, which is why people say that electricity in the USA runs at 120VAC. The peak-to-peak voltage is 170V, but the "RMS" average voltage is 1/√2 of that, or 120V.

Anyhow, those brief moments of time where no power is flowing are a problem for a power company, who would like to deliver energy in a continuous stream. So, they build their power system with three wires. Each wire reaches its maximum voltage 1/180 of a second after the previous wire. Since the voltages on each wire are sine waves, when one wire is at 0, the other wires are at +√3/2 and -√3/2 of their maximum voltages. Therefore, there is no point where the power stops. In fact, due to a mathematical quirk, the power delivery is actually constant, even though the voltages on the three wires are constantly changing.

Turing three-phase voltage into two phase voltage is pretty easy. Just pick any two of the three wires and hook them into the home. The difference of any two sine waves is just another sine wave at the same frequency, so you automatically have single-phase power. In practice, the power company will try to balance the load between the three pairs of wires by sending different pairs into different houses or even neighborhoods.

Edit: As several people have pointed out, this isn't quite how it works in real life. See the comments below for details about the hot vs. neutral wire and how both 240V and 120V are available in the home at the same time.

There are three widely-used approaches to managing your own keys:

1. Store the keys on your own device, and also write them down on paper as a backup.

2. Store the keys on a dedicated piece of hardware, and also write them down on paper.

3. Encrypt the keys with a username/password and back that up to the cloud.

Option 2 protects against all kinds of malware, including keyloggers. The device has its own screen and buttons, so you can see the backup keys and verify the destination of the funds without trusting you PC.

For the paper backups in options 1 and 2, there are fireproof options like cryptosteel.

Option 3 gives a really nice UX, since it's feels like a standard username/password login. This is what Lastpass does for passwords, but applied to Bitcoin. Keyloggers are still a threat, and if your password is weak, someone might brute-force it in a database breach situation. Depending on your use-case, this may be worth the tradeoff.

The company I work for, Airbitz, implements option 3. In our experience, far more people lose funds accidentally than due to hackers (at least with self-managed keys). Therefore, a familiar UX is crucial to helping users retain control of their funds. Plus, most people aren't willing to invest in specialized hardware, at least at first. If crypto-currencies are ever going to go mainstream, there needs to be a software-only on-ramp.

Aside from a few cryptographic details (like which elliptic curve to use), this system is identical to [BitId](https://github.com/bitid/bitid). BitID is already being deployed in the Bitcoin ecosystem. For instance, you can see it on the buy/sell service [Glidera](https://www.glidera.io/loginbitidqr).

One benefit of doing this in the context of Bitcoin is that users already have mobile apps that can manage private keys (with backups) and scan QR codes. With Bitcoin, if you lose your keys, you lose money, so there is a tremendous incentive for both users and wallet authors to get this stuff right. Using the same technology for logging in an easy next step.

Most languages from the past 40 years have either been interpreted or JIT'ed. While this has many benefits, it also creates a walled garden where software can only talk to other software from the same ecosystem. You have to make a conscious effort to make Java code talk to Python code, for example.

Systems-level programmers are more interested in targeting the "least common denominator", writing code that runs directly on the CPU without any outside help apart from standard OS calls. This is why almost every language has an FFI bridge that can talk to plan C - C is the least common denominator on any given system, so everybody knows how to talk to it.

To have a shot at replacing C, a new language needs to operate at the same level of the stack, relying only on the raw CPU and OS. C++ can do this, but it doesn't offer much safety benefit over C. ObjectiveC is the same.

This is why Go and Rust are so exciting. They are the first languages in a long time that actually run at the same level as C. Rust has the additional benefit of not even requiring a garbage collector, so it can be used in embedded microcontrollers and OS kernels. Go's garbage is a downside, but maybe not a fatal one.

Besides, even if we had hardware bounds checking, you would still need a language that could take advantage of that. C's memory model is too loose, so there is no place to even hook the bounds-checker in. Think about this:

    struct Data {
        char name[20];
        void *next; // Points to another `Data` instance
    }

If you try writing a string longer than 20 characters to `((Data *)data.next)->name`, there is no way the compiler could ever type-check that, or tell the hardware bounds checker where the limit is. This is why C has to go.

With Chacha20 the worst that can happen is plaintext recovery, which is a lot less bad than full key recovery.

That code looks prettier than some C++ I've seen, though.

As someone who works on a medium-sized C++ codebase, Rust is definitely interesting to me. If nothing else, Rust's dependency management and cross-compilation tools would solve many of our headaches. We use a giant ball of shell script and Makefiles to cross-compile our dependencies for iOS and Android, and Cargo/rustup seem like they would solve much of that. We've also written a complicated system of macros for error handling, but Rust has that stuff built into the language. Oh, and it's just as fast as C++, so we wouldn't take any performance hit. If we could do the project over from scratch, I would definitely push for Rust.

We have been using [Bublé](https://buble.surge.sh) as our transpiler, and it's output is extremely readable. Bublé only supports a subset of ES6, but I think that's a worthwhile tradeoff for better debugging. Sourcemaps are nice too, but sometimes you have to go under the covers to find the real problems.

I run Cyanogen Mod on my phone without any Google services. I would like to see local bus times on my phone, but the app for that won't run without the Google map API. It's the same with many other day-to-day things I would like to do with my phone, but can't. Android without Google is a hobbled and limited experience.

What about the third option, where a hacker can't install a rootkit even if they have physical access? That's what MS tried to build, but is now completely broken.

The AES-GCM mode of operation turns the AES block cipher into a stream cipher. Doing this makes it possible to add authentication on top for relatively cheap. The ChaCha20-poly1305 has a similar construction. These are the two most secure and efficient ciphers available in TLS, so they get a lot of use. If you are sending documents over HTTPS, you definitely want them encrypted with one of these two.

If a security researcher finds and reports a flaw in a system, they can get in trouble for unauthorized access. This is dumb, since we want flaws to be disclosed so they can be fixed. In a certain sense, systems that can be accessed, should be accessed.

The real problem isn't unauthorized access; it's what someone does with that access. Someone who gains access to information but does nothing with it hasn't really done anything wrong. The law should apply only when that access is used for harm (vandalism, corporate espionage, fraud, or whatever is relevant). Right now, the law penalizes the access itself, which is backwards.

If we apply this logic to the FBI, then sure, let them hack away. Without the due process of a warrant, however, none of the stolen information should be admissible in court. The problem isn't the hacking; it's making inappropriate use of stolen information.

Those 48 bytes are the two random numbers used as the private key, correct? The actual public key that gets sent over the wire is the 751 byte thing, if I read the paper correctly.

Diffie-Hellman is a key-exchange protocol. If two people want to exchange some encrypted information, they first need to share a secret key to do the encryption with. The problem is, they can't just send the key in plain-text, since any eavesdroppers would get the key too.

Diffie-Hellman gets around this by having each side share only part of a key, while keeping the other part secret. Both sides can then mix their own secret part with the other side's shared part to derive a common encryption key. An eavesdropper can't learn anything, though, since they only see the shared parts, not the critically-important secret parts.

The Diffie-Hellman algorithm comes in several different flavors. The current state-of-the-art is ECDH, which is fast and uses small keys. The problem is that ECDH only provides security against classical computers. If an eavesdropper has access to a big 256-bit quantum computer, they can work backwards from the shared parts to learn the encryption key.

Big quantum computers don't exist yet, but they might one day. Therefore, cryptographers are busily searching for alternatives to ECDH that don't have quantum weaknesses. We have some alternatives already, but they are either slow or require enormous keys.

This paper shows a way to do quantum-resistant Diffie-Hellman in a way that is significantly faster and smaller than anything we have see so far. It's still a lot slower than the best ECDH (~50 million vs ~50k cycles), and they keys are still a lot bigger (751 bytes vs 32 bytes), but it's still really impressive progress. Many of the alternatives have keys measured in KB or MB, which is obviously impractical.

[edit: fixed numbers]

The website had a link to the headphones in one of the FAQ documents. They are called "Tooks NextGen SPORTEC BAND" ( http://www.amazon.com/gp/product/B01459BC7G)

As I'm sure you're aware, restless leg is an odd "itch" that can only be "scratched" by movement (for lack of any good words to describe it). The movement isn't compulsory, but the discomfort becomes overwhelming without it. I suspect the sensation is there all the time and not just at night, but there are enough other stimuli during the day to drown it out. The brain.fm music seems to have been effective for the same reason, providing a welcome distraction from the sensation.

Restless leg is supposedly a mineral deficiency, but my blood work comes out normal, and supplements haven't been helpful. Up until now, the only remedy I've found is working out in the middle of the night, which replaces the restless sensation with a tired-from-exercise sensation. This only works if I can fall asleep before the exercise wears off. The brain.fm effect is less powerful than exercise, but doesn't have a time limit for falling asleep. I wonder if this is unique to brain.fm, or if it would work with any other type of music.

Besides distracting from restless leg syndrome, the brain.fm music was quite relaxing (more so than ambient or nature music normally would be). I did notice the 3D effect, and wondered what that was about. There is clearly something going on here, but I don't have the knowledge or tools to say what. It sounds like your EEG sleep studies have done just that, so thanks for mentioning those. I had no idea it was so measurable.

This would be worthwhile it if the results are as good as you say they are. I've gone ahead and purchased the headphones - for science! Thanks for the offer, and for your epically-long reply. This type of thing is fascinating to me.

I have tried a both a 15-minute "quick relax" session and a full 8-hour sleep session. Based on the "quick relax" session, I assumed this music was based primarily on binaural beats (hence the need for headphones), but the sleep session didn't seem to use the beats as strongly (if at all). I have trouble sleeping at night due to both stress and restless leg syndrome, and while this music didn't put me to sleep right away (and the headphones definitely didn't help), I do think I was better off last night with the music than without.

I would be willing to pay for this, but the current price is too high. I think about $24/year would be something I could justify (but still not an impulse buy). I listen to a lot of DJ mixes for free on Youtube/Mixcloud and buy a few tracks a month to support the producers I like. If I were to add your service as well, that would more than double my cost of music.

The "kilo", "mega", and "giga" prefixes are part of the SI system of units. They have been around far longer than computers, and are all defined in terms of base 10. A "megawatt" is one million Watts, and has been for over a century. These units don't belong to the computer industry, and computer people can't define them to mean something else just because "byte" is the next word.

If you want to insist that 1KB is 1024 bytes, then you aren't talking about real "kilos", you are talking about fake, computer-nerd "kilos". Stealing these units was wrong, and should have never happened in the first place. The SI isn't being moronic in introducing KiB, MiB, and friends, it's just asking us to return what we've stolen.

It seems like you are actually agreeing with Paul Graham. You see the concentration of political power and the resulting erosion of the middle class, and you want to fix them. Great! Those are the kind of "bad" sources of inequality the original article is talking about.

Paul doesn't want to ignore these problems, he just wants to call them what they are. The only problem I see is that we don't have a good term to cover all these related concepts. Alternatives like "creeping feudalism" don't have the same ring as "inequality", even if they may be more accurate.

Right, but the goal isn't to make a strong or useful encryption tool. The goal is to show that cryptography is, at it's core, rather simple. It's simple enough that we can cram "real" symmetric encryption into the size of a tweet.

It's like building an electric motor out of some scrap wire and some fridge magnets - the motor isn't really useful for anything, but it teaches the basic idea in a way that anybody can appreciate. A useful motor would have bearings, a commutator, multiple windings, an iron core, etc., but adding all that stuff just obscures the basics. Criticizing a school-kid's motor for being weak and inefficient is completely missing the point.

This program isn't supposed to be useful. It's supposed to prove a point.

The interesting thing is how small all these issues are. The Rust ecosystem has really matured a lot if it can now be used to write serious software like games with only minor issues such as these. That's a pretty remarkable feat for the Rust team to have accomplished.

This is a marketing piece for their new GPU, which has ray casting built into the silicon. It's not clear how to access this new hardware (some OpenGL extension?), but they do mention that their chip gives shaders the ability to cast rays.

Their new GPU comes with something called an "RTU", which accelerates the ray intersections. This article is showing off one way to use their fancy new toy: http://blog.imgtec.com/powervr-developers/powervr-gr6500-ray...

How does one actually access this special ray-tracing hardware? Some sort of OpenGL extension? I looked around, but couldn't find any answers. None of their press seems targeted at developers.