But the VM detection has to occur BEFORE you setup the clever encrypted CPU stuff so that code is then vulnerable to the usual debugger cracking techniques (without worrying about the encryption stuff).
Basically a lot of authors thought they'd get 'ahead of the game' and publish PHP6 books very early. If a 'real' PHP6 was released now, there would be confusion.
I wouldn't chance it; the first time I implemented IPNs, I had to spend almost a week on R&D aimed purely at discovering and working around all the undocumented fuckups.
Webhooks are not hard. That Paypal fails at them this badly makes me think their infrastructure is a (much larger) disaster waiting to happen; if I still did freelance work, I would be moving all of my clients to Stripe right now, before the next inevitable mishap.
They actually do the right thing with a 301 redirect, and re-post to the new URL. I did a site wide http->https redirect, and surprisingly the IPN script continued to work.
"In 1978 Roy Trubshaw, a student at Essex University in the UK, started working on a multi-user adventure game in the MACRO-10 assembly language for a DEC PDP-10. He named the game MUD (Multi-User Dungeon), in tribute to the Dungeon variant of Zork, which Trubshaw had greatly enjoyed playing.[18] Trubshaw converted MUD to BCPL (the predecessor of C), before handing over development to Richard Bartle, a fellow student at Essex University, in 1980.[19][20][21]
MUD, better known as Essex MUD and MUD1 in later years, ran on the Essex University network until late 1987,[22] becoming the first Internet multiplayer online role-playing game in 1980, when Essex University connected its internal network to ARPANet."
PLATO was a network of systems, not just one. By 1978 there were PLATO systems in Illinois, Minnesota, Delaware, Florida, Belgium, and other locales, all internetworked using what was called "the link", a high-bandwidth connection between these various CYBER mainframes. PLATO had collectively many more users than ARPANET during this time; ARPANET's population wouldn't exceed PLATO's until probably around 1981, though it might even be later.
It always seems a little odd to me that bitcoin is associated with criminal enterprise. Surely with the transaction record public, it's rather easier for the police to "follow the money" than with cash etc?
You can "follow the money" electronically, but unlike bank transfers there's no physical connection. Going from imaginary point 1 to imaginary point 2 doesn't really tell you anything.
But some transactions are ultimately linked to the physical world, and that gives a window through which more can be pinned down over time. Operating from just the blockchain doesn't tell you very much, but combined with other things it's a lot more informative than cash movements. You're never leaking less than you think.
Bitcoin mixers can make it almost impossible for people to follow bitcoin transactions, providing that the number of coins in the mixer far exceeds the amount you are trying to mix.
Again, you're never leaking less information than you think. I also expect that using bitcoin mixers will be prosecutable under AML laws in the medium term, if they aren't already.
> And there's no simple excuse for the preprocessor; I don't know exactly why that exists, but my guess is that back in the 1970s it was an easy way to get at least an approximation to several desirable language features without having to complicate the actual compiler.
Clearly this guy has never had to deal with a large, complicated code base in C. Dismissing the preprocessor as a crutch for a weak compiler shows a significant ignorance about the useful capabilities that it brings.
I assume when he says "no simple excuse", it's more pointing to the massive problems that the mere existence of the macro pre-processor introduces for reasoning about the text of any C or C++ program, for programmers, tools, and compilers.
I've worked in a code base where, tucked away in a shared header file somewhere up the include chain, a programmer had added the line
#define private public
(because he wanted to do a bunch of reflection techniques on some C++ code, IIRC, and the private keyword was getting in his way)
Now regardless of whether that's a good idea, if you are reading C or C++ code, you always have to be aware, for any line of code you read, of the possibility that someone has done such a thing. Hopefully not, but unless you have scanned every line of every include file included in your current context recently, as well as every line of code preceding the current one in the file you're reading, you just can't know. Clearly this makes giant headaches for compliation and tools, as well.
So yeah, of course every mid to large C / C++ program uses the macro pre-processor extensively. You can do useful things with it, and there's no way to turn it off and not use it, anyway, given the way includes work in C / C++, so you might as well take advantage of it.
But it's not an accident that more recent languages have dropped that particular feature.
The only time I have seen actual conditional compilation used in C# was hilarious - I was given a pile of code that had preprocessor directives used to make private methods public so that they could be unit tested. However, if you switched the compile time flag to the "production" state nothing compiled....
I doubt he meant that it was not useful, rather that the usefulness might have been better served as a function of the compiler rather than some disconnected transformation tool.
Of course this thought process would eventual bring you down the road of macros systems such as those in Lisps, but that's going to be more difficult with a language lacking homoiconicity of code and data.
There are macros in many non-homoiconinc languages (eg. Rust, Dylan), and there are add-ons for several of the languages lacking them (eg. SweetJS for Javascript, MacroPy for Python).
It was a long one, and I'll admit I only skimmed it.
But from a glance, it looks like the one writing the rebuttal didn't really understand the criticism, and is himself 100% captured by the exact mindset which the original article criticized PHP for having.
This guy is the one who will be standing at the door complaining that you just broke his house. He is what is wrong with PHP.
And naturally, however much sense he thinks his argument makes, it will still be wrong. It's in the very nature of this situation.
