mrmekon

At the time of this comment, r/restorethefourth has 19,511 subscribers. The US has a population of approximately 319 million (WolframAlpha estimate).

We are the 0.00612 percent!

I don't know about the EU, but in the U.S. your statement is simply not true. Somebody absolutely can follow you around taking photos or videos, as long as you are in a public space and they can come up with any non-malicious excuse (i.e. it's an art project!).

Stalking laws vary state-to-state, but you generally have to prove it is specifically "for the purpose of harassing and intimidating".

See also: paparazzi

See also: http://www.victimsofcrime.org/our-programs/stalking-resource...

Yes, although I make fun of LLVM for the non-optimal code, I really doubt anyone would consider them 'bugs' -- and I did not. They aren't bugs, they are just optimizations that we haven't found a good way to automatically identify yet.

Though, it does seem to always store the old stack pointer in r7, even though it doesn't restore from r7, and even though my inline assembly block specifies r7 on the clobber list. That might be a bug, but it's a single 'add', so who cares.

It's not the extra 1000 instructions of this call that is concerning. It's the extra 1000 instructions per thing-that-would-have-just-been-a-null-check summed over every running process on your machine if this actually took off as a standard idiom.

If we keep adopting readability tricks with orders-of-magnitude differences in speed compared to what we're replacing, we'll just keep getting slower and slower code.

They don't optimize to:

  cmp r0, #0
  beq exit

This is the response I was looking for. We keep making computers 2x faster, and then making software architecture 4x more wasteful (given, it's also 20x faster dev time).

"if (ptr == NULL)" is usually two instructions and an instruction pipeline flush. That sucks, but I can't even imagine what the processor ends up executing for the Ruby lambda callback. Slightly more readable code at what cost?

I'm always amazed by the strange assembly generated by modern compilers. LLVM will auto-vectorize a routine into this awesome NEON SIMD masterpiece... and then throw in a bunch of completely redundant stack loads/stores and refuse to use any registers except r0 and r1! 0_o

You can tell where the devs with Ph.Ds in compiler design are putting all of their effort :)

It usually is inline assembly, but you write it in C first and copy the disassembly as a starting point. We do this in the embedded world a lot because we're constantly switching architectures, and nobody memorizes the instruction set of every architecture :)

The most common reason is using architecture-dependent instructions that the compiler doesn't generate well, or doesn't generate at all. Examples are SIMD (auto-vectorization is nice, but far from perfect) and DSPs that have specific multiple-and-accumulate instructions or flags that change the behavior of the accumulate register.

In a project I'm currently working on, inlining was still inferior to fully native ASM. LLVM generated unnecessary stack loading in the prologue, and the completely unused memory access had something like a 4% speed penalty.

Everybody I know who writes assembly language in practice now, self included, prototypes most of it in C first -- why not take the huge headstart from the compiler generated ASM?

And I usually prototype the C in Python first :D

These things are fun, and certainly not new. You can buy devkits that already look quite unobtrusive: http://en.wikipedia.org/wiki/SheevaPlug

The one in this article looks like a fire hazard. I guess that's one way to cover your tracks :P

1. The general public won't install an APK outside of an "App Store" equivalent

2. https://play.google.com/about/developer-content-policy.html

3. Many of the devices are locked and can't be rooted

I moved here from the U.S. The process was fairly fast and simple, and as soon as you have a work permit you get all of the social benefits. It only takes 5 years to get citizenship, too.

It's supposed to be fairly easy to bring a spouse (different or same sex), or even an "unmarried cohabitating partner" with you.

They even offer work permits for self-employed workers, though that requires quite a bit of extra paperwork (you have to proof self-sufficiency). I heard you can start a business here and request something like a 2-year grace period before you have to proof you are self-sufficient.

I moved to Sweden from the U.S. about 3 months ago, and it was a very easy process (I already had a job lined up here).

The hardest part is international interviews: they really want you to interview in person, and they really don't want to pay for international airfare to do it. The best way, if you can make it work financially, is to plan a 2-month "interview vacation" here.

Sweden has a pretty easy immigration path, is fairly friendly to immigrants, most natives speak English, and has a large tech community with not enough local talent.

I don't think these 'quick intro to bitwise operations' and/or 'cool bitwise operation tricks' articles ever go into enough detail to be safe.

Bitwise operations can be _extremely_ useful, but it's surprisingly difficult to use them in a correct and portable way. I have no idea where you can go to learn all the intricacies involved.

One killer that's always listed is "divide an int by 2: n >> 1" with no reference to how it behaves differently than the "/" operator (bitwise rounds towards negative infinity, / rounds towards zero). It's not incorrect, but that detail can be extremely important.

You can set most, but not all, of the sounds to 'None'. There still seem to be a bunch of sounds that you can't control. And manually configuring the whole phone to be silent is quite time consuming, especially since you have to may have to do it for individual apps, which may or may not even support it.

My 3GS has a broken Ring/Silent switch that is permanently on 'ring'. I've been trying for a year to find a reliable way to make it shut up -- I'm a 'silent always' kind of guy, and that switch failure made me hate my phone. This looks like a pretty great solution!

Dock speakers connect to the iphone through the same interface. The high end ones have ARM cores, they have wifi, they might even run Linux. There is a theoretical chain of trojan --internet--> PC --wifi--> speaker --usb--> iphone.

This is, of course, insanely unlikely today. But in a few years, when everything has a 1GHz ARM core and an internet connection, we very well might start seeing malware that jumps devices and infects entire households.

Nothing is anything. We're all just subatomic particles destined for heat death

But, really:

openpgpjs, the topic of the article, is a program that implements the OpenPGP standard, and the cryptographic algorithms it depends on.

node-gpg, the topic of this comment, does not implement any part of the OpenPGP standard, nor any cryptographic algorithms. It executes a local C program, GnuPG. If you don't have that C program, it does nothing.

Suggesting that they are the same thing is silly. The distinction is massive.

Otherwise, I could claim I just implemented a world-class PGP implementation! To try it out, just run: perl -e "exec 'gpg'"

Except this library doesn't have proper memory protection, and node.js has system access so it could just use GnuPG and be a lot more secure (and almost certainly faster, too).

This is not a PGP library. It's a wrapper around gpgme, which in turn is a wrapper around gnupg. node-gpg just exposes the GnuPG command line as javascript functions.

If anybody uses this, please keep in mind the differences in security possibilities between native C code and Javascript.

Both this and GnuPG encrypt and decrypt data with PGP keys. GnuPG, however, does this securely, in many, many senses of the word. For instance, GnuPG maps all of its buffers to protected memory pages, and clears its buffers frequently and early.

A very large portion of GnuPG's code is dedicated to protecting your private keys, and the techniques that they use simply aren't available to javascript.

This doesn't mean the JS library is bad, it's just a good thing to keep in mind. Don't run your nuclear launch codes through this.

There's also offshore tax havens, political action committees, and patent trolls. Some unethical things are legal.

There's also underage sexting, media piracy, cryptocurrencies, and marijuana. Some things aren't globally agreed upon as ethical or unethical, but the law still attempts to address them.

Identifying the overlap is difficult.

You know, there's more than one set of laws in the world.

If I hadn't seen DJB's name on this, I would have read the abstract and thought "bullshit!" Now I just assume it's the most brilliant protocol ever written, and the source code is completely illegible :D

It's completely reasonable to just e-mail him directly. Generally you would explain in the first few sentences what your connection is and how you found his e-mail address.

I've done similar with good results. People are usually a lot more willing to help if you have anything in common at all.

If Motorola and Cisco and other big tech firms have no trouble producing ASICs, why would the NSA? You don't need to fab them yourself, you just need designers and a fab partner.

GCC explains here:

http://gcc.gnu.org/onlinedocs/cppinternals/Token-Spacing.htm...

I can't find anything in the C spec that says this is strictly required, but that doesn't mean it's not in there.

This is a frequently repeated oversimplification. (L)GPL is not incompatible with iOS, it is incompatible with the Apple App Store.

It is fully, 100% GPL-compliant to release a (L)GPL'd iOS application linked to a (L)GPL'd library, as source code, with instructions on how to build and load on your iOS device.

It is /probably/ not compliant to distribute that through the App Store, though there is some disagreement, and it has never been taken to court.

It is /definitely/ not compliant to distribute a proprietary app that links to an (L)GPL'd library through the App Store, since Apple only permits static linking.