diek

Why would they not include the inter-satellite linkage capability? That doesn't make any sense, given that was a solved problem in the Iridium constellation 20 years ago. That was a huge benefit of Iridium, in that it didn't have to rely on the "bent pipe" of just relaying data between a client and a ground station within the same coverage area. It was literally, "if you could talk to one satellite, anywhere in the world, you would have service".

Varies quite a bit. Some deployments are high CPU, high I/O, some are basically idle. All are running the same docker image.

Try explaining to people that Kubernetes may not be the best option for large-scale hosting. I'm currently dealing with people who want to have a 'one pod per site' deployment model for 500,000 customers. Do the math on how many nodes that is with a 30 or 100 pod limit per node.

Unless you're performing some magic elsewhere in the codebase, this will leak connections if an exception is thrown since you're not closing the connection in a 'finally' block. Alternatively, depending on your version of Python, you could use a 'with' context to ensure the connection is closed.

After reading their 'How It Works' page, it looks like they load the DOM into headless Chrome, let all the JavaScript events fire, wait for rendering to complete, and then serialize the DOM afterwards. Whereas with just rendering the React component you're getting the resulting HTML but you're not seeing the effect of actually executing any referenced JavaScript and the resulting DOM how a browser would see it.

> Successful, popular concurrent platforms like [...] node.js, eschew threads in favor a single-threaded, async/non-blocking code model

Except that Node (by way of libuv) uses thread pools internally for things that it deems to be CPU-intensive enough to need it, like crypto.

Python 2.7 has terrible thrashing in the way the GIL is acquired that is exacerbated as more threads are used. Dave Beazley has given great talks with the technical details: http://www.dabeaz.com/GIL/

> In seating, we mix engineering teams with non-engineering teams

In my experience this is a huge productivity killer for engineering teams. No, sitting us down next to the recruiting guy doesn't make the recruiter better at technology or the engineers better at understanding recruiting. It mostly just makes us hate the person who talks on the phone all day while we're trying to work.

Actually, funnily enough I just went through and built a semi-freestanding exe to load a jlink'd Java 9 JVM: https://gist.github.com/anonymous/cb6e81a36247563d423f36df19...

The only dependencies this particular ex has is on user32.dll and kernel32.dll so it can call LoadLibrary and GetProcAddress, but if I wasn't interacting with those I could remove those dependencies (though then the exe wouldn't be able to do a whole lot of interesting things).

If you look at the file in a hex editor, it's mostly just empty space as it just has four 1k sections with a little bit of data at the start of each.

So, like IntelliJ? We should port IntelliJ to Electron?

> Specifically, the NRA is an industry-funded group that has lots of it

That's just not true at all:

https://www.quora.com/Where-does-funding-for-the-National-Ri...

(edit: bah, in the time verifying my sources, three other people posted the same info :) )

I probably helps that the current CTO of Evernote used to work for a higher-up VP in Google Cloud for years when they were with Yahoo and GoDaddy.

If you ran a game written in C++ that kept running out of memory and crashing, would you say C++ is "heavy"? Solr (and Lucene internally) maintain large in-memory data structures as well as memory map (usually) on-disk segment files. How much memory they use is determined by many, many configuration options within Solr. This has nothing to do with the JVM.

Same thing with Clojure. It basically bootstraps the entire Clojure environment on each process start. The JVM itself starts up in tens of milliseconds.

"IO-bound multithreading is fine" has been the Python mantra for the last 20 years. Lo and behold, someone actually gathers some data and comes to find out that is absolutely wrong. For the last few years they've had a revamped version of the GIL, but that still has a burden of proof that can only be validated by profiling real-world applications.

A community can't make flat-out invalid claims for two decades and then expect everyone to take them at their word that everything is fine now.

No, they're not. Is IntelliJ "doing it wrong" to release every three months[1] ? Absolutely not. A release can change things about a product, and you want to ensure you are pushing those changes (UI, behavior, plugin APIs) at a pace that matches the users. You don't want to be pushing changes to a plugin API every day. The surface area of stability that has to be maintained at that point is insane.

In the interim, you should definitely be able to build off master. Your CICD server should build and run tests on every commit to master. Then a release gets a tag in version control and you should be able to issue bug fix releases for only that specific version. Telling customers, "There is a critical security bug in version X, but in order to fix that bug you need to upgrade completely to version X+2" is not an acceptable answer.

Note that the description above works best in my experience for products that push a release artifact (like IntelliJ) versus a service like GitHub. Release management approaches will vary based on the product.

[1] https://www.jetbrains.com/idea/download/previous.html

> It is not an issue for apps which spend most of the time doing I/O.

This is a common misconception that doesn't seem to be backed up by any data.

Dave Beazley did a number of performance tests with profiling, looking at GIL contention in a multi-core scenario: http://www.dabeaz.com/python/GIL.pdf

The results were that even IO-bound workloads still suffered because of the poor implementation of the GIL (details on slide 35 or so). This was an issue up until Python 3.2 (!) when a new GIL implementation was added, which he also profiled: http://www.dabeaz.com/python/NewGIL.pdf

You can watch 3-gun matches on YouTube right now that fire 40 shells while running and gunning.

> Lethality of all of those other methods is significantly below that of a semi-automatic rifle.

That's just not true. In Somalia, U.S. Army soldiers actually complained about how the AR-15 round (5.56 NATO) wouldn't take down enemy combatants in a single shot.

Compare that to, say, the bombs used in the Boston Marathon. It's a night and day difference. If you're trapped in a crowded nightclub that's on fire, your odds of survival are abysmal.

People survive serious gunshots every day with proper medical attention. One of the big issues in the Orlando shooting was the 3 hour wait before any of the victims got medical attention.

You don't have to stop to reload at empty, you can just keep feeding the magazine after every shot or two. 50 (2 3/4) shells isn't an unrealistic loadout.

That's only a valid comparison to mass shootings, which are a tiny, tiny percentage of gun deaths.

By comparison, referenced in my other comments, if someone really wanted to kill everyone in a theater they could do it with a container of gasoline, or a pressure cooker. Newtown could have been accomplished with a sword, given the size difference of the attacker to the victims.

Anyone who wants to kill you can, with any number of objects readily accessible. This is only evident to some people when they think of an object like an AR-15 because they don't think about all the other ways they could be killed.

The problem with this argument is that in the timeframe the Orlando shooter was given (3 hours), a shotgun could have easily been a mass casualty producing weapon.

It's the substitution problem. The argument (seems to be), "If we ban semi-automatic rifles, that person who wants to kill all those people won't be able to harm anyone."

History has shown us this simply isn't the case. People who want to kill people will kill people with whatever means available. Happy Land, Oklahoma City, etc are just examples of this. I didn't see a huge push to ban pressure cookers after the Boston bombings.

It looks like the 1,500 number includes all deaths of children under 18. However -- without going into that particular dataset -- these numbers are normally inflated by gang violence and include 17-year-olds killed in shootouts with police. I'm certainly interested in more data, but it's hard to find summary datasets that aren't slanted.

Just out of curiosity, where would you draw the line? Mini-14? Shotgun? SKS?

Is it a capacity issue? caliber? detachable magazine? or a combination?

I like the analogy of swimming pools. I don't _need_ a swimming pool, and having a pool by definition makes neighborhood children and visitors with children to my house less safe.

In fact, children under 15 are about 40 times more likely to die by swimming pool than by an accidental firearms discharge [0].

I still have a pool. There are reasonable laws about having auto-closing gates and a fenced-in yard. I don't see anyone clambering to tighten restrictions on assault swimming pools.

Likewise, semi-automatic, detachable-magazine-fed rifles are responsible for something like 2% of shootings. The only real place they have significance is in mass shootings. The only refute I have to, "but if we ban these rifles we won't have shootings" is that it would just happen through a different means. The Happy Land Fire killed 87 people, not a shot fired. Timothy McVeigh killed 189 people with fertilizer... and that was in 1995 -- under the "Assault Weapons Ban" of 1994.

[0] http://www.m1-garand-rifle.com/gun-safety/firearms-versus-sw...

That's nonsensical. You may as well say, "Everyone should spend 25% of their startup's time on ensuring African children have access to food and clean water."

When someone asks, "Why should we do that?" you respond with, "What, do you hate African children?"

Just out of curiosity, what other languages do you have experience with?

Using the Java 8 'stream' API:

   IntStream.iterate(0,  i -> i + 1)
	.mapToObj( i -> Collections.nCopies(i, i % 2 == 0) )
	.flatMap(Collection::stream)
	.limit(1000)

Generate an infinite series of incrementing numbers, starting from 0, map each to a stream of boolean indicating true/false, flatten that stream of streams, then limit the output.

The GP qualified that this is better with newer JDK versions. For instance, in Java 8 you can do:

    IntStream.range(0, 100).filter(i -> i % 2 == 0);

> whereas the transition from Java 6 to later versions is proving to be next to impossible

I've never heard of anyone having issues going from Java 6 to later versions, at the language level or JVM level.