joepie91

No, your cryptocurrency cannot work

Whenever the topic of Bitcoin's energy usage comes up, there's always a flood of hastily-constructed comments by people claiming that their favourite cryptocurrency isn't like Bitcoin, that their favourite cryptocurrency is energy-efficient and scalable and whatnot.

They're wrong, and are quite possibly trying to scam you. Let's look at why.

What is a cryptocurrency anyway?

There are plenty of intricate and complex articles trying to convince you that cryptocurrencies are the future. They usually heavily use jargon and vague terms, make vague promises, and generally give you a sense that there must be something there, but you always come away from them more confused than you were before.

xywei

--- automake.in	2015-01-06 03:25:55.000000000 +0800
+++ automake.in.patched	2017-07-26 13:58:07.086205701 +0800
@@ -3878,7 +3878,7 @@
 sub substitute_ac_subst_variables
 {
   my ($text) = @_;
-  $text =~ s/\${([^ \t=:+{}]+)}/substitute_ac_subst_variables_worker ($1)/ge;
+  $text =~ s/\$\{([^ \t=:+{}]+)\}/substitute_ac_subst_variables_worker ($1)/ge;
   return $text;
 }

lkraider

#!/bin/sh

# It seems it's very hard to set resample output quality with Ghostscript.
# So instead rely on `prepress` preset parameter to select a good /QFactor
# and override the options we don't want from there.

gs \
  -o resampled.pdf \
  -sDEVICE=pdfwrite \
  -dPDFSETTINGS=/prepress \

suprememoocow

- action: ec2_facts

- apt: pkg=lvm2 state=present
- apt: pkg=mdadm state=present

- pip: name=boto state=latest

- ec2_vol: instance="{{ hostvars[inventory_hostname]['ansible_ec2_instance-id'] }}"
           volume_size=20
           device_name="{{ item }}"

simon04

Gradle, Java plugin, Jar MANIFEST, Class-Path is empty

I struggled with with the jar MANIFEST file built with Gradle containing an empty Class-Path. I traced down the problem to the order of the dependencies and jar blocks in the build.gradle file:

Wrong (jar before dependencies):

jar {
    manifest.attributes(

headius

Too much for teh twitterz :)

JVM + invokedynamic is in a completely different class than CLR + DLR, for the same reasons that JVM is in a different class than CLR to begin with.

CLR can only do its optimization up-front, before executing code. This is a large part of the reason why C# is designed the way it is: methods are non-virtual by default so they can be statically inlined, types can be specified as value-based so their allocation can be elided, and so on. But even with those language features CLR simply cannot optimize code to the level of a good, warmed-up JVM.

The JVM, on the other hand, optimizes and reoptimizes code while it runs. Regardless of whether methods are virtual/interface-dispatched, whether objects are transient, whether exception-handling is used heavily...the JVM sees through the surface and optimizes code appropriate for how it actually runs. This gives it optimization opportunities that CLR will never have without adding a comparable profiling JIT.

So how does this affect dynamic