It's not about that. Paul Le Roux never claimed to be the creator of TrueCrypt, what we have are clues that connect him to working on E4M, then working on SecurStar, porting encryption algorithms from SecurStar to E4M and getting fired due to that. And then a project named TrueCrypt and claiming to be based on E4M started to surface.
I am not expecting Le Roux to be the true creator of TrueCrypt but this seems to be a pretty solid link between Le Roux and TrueCrypt.
Now about Wright, he can't even write a proper blog post with proper working scripts about cryptography...
As already stated I don't believe Wright's claims at all, and I find the whole thing pretty silly as we already have quite a few viable candidates/teams for Satoshi in the public record. I simply stated an interesting observation linking two related technologies and circumstances surrounding them :)
What do you mean? It was explained on part 2 that the code for TrueCrypt was built on top of E4M.
"I asked him what he meant, and Hafner told me that in the middle of the development work for DriveCrypt, he discovered that Le Roux was still working on E4M and had incorporated some of his work for SecurStar into his personal project.
(...)
In 2004, a group of anonymous developers did exactly what Hafner had feared: They released a new and powerful, free file-encryption program, called TrueCrypt, built on the code for E4M. “TrueCrypt is based on (and might be considered a sequel to)” E4M, a release announcement stated."
It was. It also has almost nothing to do with anything in the whole series. It should've been one fact in isolation about one part of Le Roux's history. Instead, the author keeps dropping lines about Truecrypt as if to tie Le Roux's name to it and imply he's been behind its funding or shutdown. Without evidence. Repeatedly.
He's better off just leaving it off except the E4M-Truecrypt beginning and the question in court. It wasn't relevant to anything else unless I'm overlooking something. THe rest of the article is about pharmacies, call centers, hitmen, and so on. Nothing to do with TrueCrypt.
I don't agree with your view. The author briefly mentioned the relation E4M-Truecrypt only 2 times as it found some kind of evidence or relation between those two projects. And it is valid as the involvement of Le Roux in the Somalia wars, for example.
I don't feel the author is milking any of it to make the article more interesting.
I get why you're saying it and all. It's just that this article really plays on the E4M-Truecrypt connection and jumps between Le Roux and its story. See here:
The Hacker News comments and title showed many were already thinking a grand reveal was forthcoming of how Le Roux was financing Truecrypt all this time. It keeps getting mentioned even though it has nothing to do with Le Roux's life or story post E4M. Here's an alternative that's more accurate for the significance of Truecrypt to the story:
The original paragraphs on E4M and Truecrypt spinoff stay. After sentence "...message boards for good," the author stops talking about Truecrypt entirely. He should mention PhoneCrypt offer in isolation as it was significant. Later on, might mention for the trial question the context that some people suspected Le Roux might have funded or worked on Truecrypt all this time. Then show he was asked, said yes for E4M, and no for Truecrypt. Then move on.
I mean, there's not much reason to talk so much about Truecrypt, Snowden's view of it, and so on if there's nothing tying Le Roux to Truecrypt. That someone built on his work and it turned into a solid tool would be enough to say. The only good thing I could think of is that the author is trying to encourage people to use Truecrypt and such strong, OSS encrypt by embedding it into his piece. That would be annoying but justifiable in a greater good sense. Still not relevant to Paul Le Roux, though, past fork of E4M without evidence he was behind Truecrypt.
I'm not sure there's a need for the author to be trying to encourage the audience to do anything. A central theme of the story is building Le Roux up to seem as big/talented/accomplished as possible. Things like the fact that he has logging and mining concerns are brought up repeatedly despite them not being directly related to him getting busted for meth, but they serve to keep you thinking "this guy is achieving a lot". You can pick it even from the title of the series.
Truecrypt is very well known amongst tech literate people and Snowden at least is well known amongst the rest. By repeatedly driving home the fact that Le Roux was responsible for the foundation of this software, it makes him seem more impressive in the readers mind.
I could see that. Yet, Truecrypt and its successes were some other group's work. He just made essentially the prototype that had enough functionality to give them a head start. In its original form, it wouldn't have achieved all the stuff described for Truecrypt in the article.
So, saying he made E4M that others' turned into Truecrypt... then dropping Truecrypt... is more honest if we're talking his accomplishments. Not Truecrypt developers' accomplishments.
Has been working reasonably well for ~10 days now. Note that I'm on Android 4.2, so I might have missed something with regard to newer Android versions.
It shouldn't have any implications for the customer, performance/power consumption/reliability are much more defined during the design phase than the fabrication phase.
The end user shouldn't worry, or even think, in what foundry was the chip fabricated in because it doesn't really matter if you are not the engineering team.
Manufacturing process definitely impacts transistor performance including critical things like leakage and speed/voltage trade-offs. I'd be quite surprised if benchmarks that included power consumption couldn't distinguish between the two sources. As to whether it's going to be noticeable in practice - who knows, but the fact that apple's risking it suggests they're confident enough.
Similarly, I'm not sure how you expect reliability not to be affected by process; of course it'll be. But how often have you heard of a chip failing after it passes initial validation (something presumably apple does have a hand in)? It's not going to matter.
Just a note before anything else: it's not a "manufacturing process". Nobody is laying out the transistor by hand, it's a fabrication process. (I apologize for nitpicking in the wording, but it's important)
Apple does these kind of things for two main reasons: Because they have the money and because they want to test both fabrication processes for future products
The differences between a 14nm process and a 16nm process are quite minimal mostly because one process can offer some advantages over the other one. For example: it's expected that the smaller process has bigger leakage current, increasing power consumption, while it's expected for the bigger process to produce more heat.
In the end, you could say that if you sum the advantages and disadvantages of both, you will not reach any conclusion if you are not the engineering team looking for extreme optimization and with Apple's resources at your disposal.
It's just hard to come to a concrete conclusion from a consumer's point of view.
It's not just 14nm vs. 16nm though - two 16nm processes can still have significant differences due to materials
And even "16nm" something of a marketing term - something tiny feature in there is at 16nm resolution, but lots of other things are larger. And which things are how large, of course, also matters...
You can't have one process consume more power and the other process produce more heat. Power is converted to heat at 100% efficiency so more heat must mean more power.
That's... sort of exactly wrong. The process design rules (and transistor models) define the envelope within which the design must exist. The days of simple scalable design rules that port between fabs are long gone. Every process has its own crazy rules about how to draw a transistor.
Now... it's true that all the media reporting so far seems to treat TSMC's 14nm and Samsung/GlobalFoundries's 16nm processes as "essentially the same from a design perspective" (though both seem to lag Intel's 14nm in density). But until parts reach the market we won't actually know.
I didn't say that the fabrication process doesn't influence the characteristics of the final chip, I was stating that the design itself takes the bigger role of the chip's optimization and that from the end user's point of view, it doesn't matter if the A9 is fabricated in TSMC or in Samsung's fabs.
Actually, if they are dual sourcing the same chip from a 14nm process and from a 16nm process as well, it's very likely that they had to use different analog designs, so the 14nm chip probably has advantages that the 16nm chip has and vice-versa.
It's pointless for the end user to nitpick differences of the same chip in 2 equivalent processes when the software is going to mask everything out.
And I'm not saying this because I read it in the media, I affirm this from experience in the semiconductor industry.
The UI got a major overhaul recently (switched to material design) which made some things nicer. I also saw/see the UI as a problematic part of OsmAnd however I recognize it's not easy to pack all the features OsmAnd offers into a GUI and both please beginners and expert users.
Verilog and VHDL already simplify hardware design a lot. They seem to have a great learning curve due to the nature of hardware design.
Most people gain a lot of confidence in software development and try to design hardware like they would program a system. And then they complain that Verilog and VHDL is too complex.
Verilog in particular leads you into that trap, though. Because you can write conventional sequential-execution programs in it, and usually have to when writing testbenches. The nomenclature of "process" and "task" imply they behave like software - and they do, in the simulator. Then there are the hoops you sometimes have to jump through in order to get the synthesis to behave as you want: "reg" is not always a D-type flip flop, and is mandatory in some places where it doesn't synthesise to one.
Rather difficult to extinguish an open source project that in no way depends on Microsoft.
The most annoying thing they could do is unsign the drivers somehow (difficult, since programming is done over a generic FTDI chip or directly in the case of the Mega32U4) and force people to develop using a different platform.
I suppose if everyone hopped on the Windows bandwagon and then Microsoft pulled their project, it would be an issue. For instance if suddenly you no longer had access to the services, but that's not really a killer.
You can buy Arduino clones from China - I've never paid the 'official' Arduino or Sparkfun mark up. You can make your own minimalistic board since the bootloader is freely available. You could even go barebones and learn to code for AVR chips without Arduino getting in the way (it's cheaper and leaner).
>Rather difficult to extinguish an open source project that in no way depends on Microsoft.
ahem, There was a court case about this sort of thing, U.S. v. Microsoft. Java wasn't open source, yet but I still think it is relevant to your first comment. The issue is not what MS can do to Arduino, but what MS can do that causes trouble for people on other OS platforms.
I'm not proposing that this is an MS strategy, but that sort of thing is not unprecedented in MS' past, so it's not unreasonable that some might be skeptical of MS' intentions. In reality, the open source hardware hobbyist movement is so small that it defies good sense to think it could be a critical part of a MS dirty tricks campaign. OTOH, maybe MS is really bullish for the IoT.
>You can buy Arduino clones from China - I've never paid the 'official' Arduino or Sparkfun mark up.
Good for you!
> You can make your own minimalistic board since the bootloader is freely available.
You're right in that the bootloader is a big part of the magic here. A freely available bootloader, and a barely-passable IDE (that runs on any platform) are the two things that set Arduino apart from all of the other similarly capable kits that came before it. If you appreciate the bootloader, you might consider paying the "'official' Arduino markup" at least once.
>You could even go barebones and learn to code for AVR chips without Arduino getting in the way (it's cheaper and leaner).
You could, but it's not cheaper, since you'll need an AVRISP, or something similar, you'll also need to spend a lot of time learning about microprocessor minutiae before you ever get to anything interesting.
No, worst case is more like Arduino focuses on MSVS interoperability and sort of abandons the cross-platform IDE; but it wouldn't make much difference now anyway. I hope it turns out well and ends up introducing more people to open source hardware; and I doubt it will cause anyone to adopt Windows over Linux or OSX.
In this case I think the benefits far outweigh the risks.
Now it _sounds_ like you're being snarky because I'm not directly supporting Arduino.cc, but my point was that the beauty of open source is that somebody else can produce things a lot more efficiently/cheaply than you can and there isn't one controlling entity. I do own an 'official' Arduino Leonardo, but when you can buy more from eBay for $3, it's hard to justify paying 6 times the price, plus shipping, from Sparkfun.
It is certainly cheaper in some cases: the Pro Micros run Mega32U4's which have built-in USB controllers; all you need is a micro-USB cable. I prefer to code for AVR directly for a number of reasons, and Arduino boards make excellent dev platforms once you replace the bootloader with LUFA or something similar. Otherwise a tinyISP is a few dollars from eBay (they're hardly clones, since there are no official suppliers anyway). You get the option of using Atmel Studio although it's Windows-only anyway.
I'm really not a fan of the Arduino IDE either, so if Microsoft wants to bring in Visual Studio support they're more than welcome!
>In this case I think the benefits far outweigh the risks.
I'm starting to suspect that you may not be in the primary target audience for Arduino.
>Now it _sounds_ like you're being snarky because I'm not directly supporting Arduino.cc
Yeah, kinda. I don't know you so I'm not really meaning to be too judgmental. I also purchase a few clones here and there, and I encourage others to do so as well.
>It is certainly cheaper in some cases: ...
Those are some good points, but I'll note that they (built-in USB, $3 ICSP doohickeys, etc.) are relatively recent developments; and sometimes beyond the capabilities of a lot of the Arduino's primary audience.
Open source? Windows IoT requires Visual Studio and Windows (Windows Remote Arduino is a WinRT (WinRunTime) component). http://www.arduino.cc/en/Main/Software
Yes it's a good thing (for the tinkerers of this world) and I suspect its a long term view for MS. If young tinkerers can tinker away on some of the cool hardware out there leveraging MS products/tools for free (in the same way they can using linux tools) then in the future maybe some of those young folk will bring to this world some awesome startups also using the MS tool chains, a chain they may well be prepared to exchange cash for - but certinally a chain they will be familiar with.
Of course those not happy with that can fork the Arduino and its tool's - as far as I know they are all open.
Of course it may lead nowhere MS and they may well drop it when the return does not pan out.
Integrating the Arduino firmware with a Windows GUI app will be a lot easier if the firmware was generated from within MSVS. I could imagine automatically generated bindings to hardware functions. I can also imagine an automatic custom "device driver" generator; and then maybe an all-in-one installer roller thing. There are some pretty cool possibilities.
Assuming M$ is always evil is still a personal opinion, doesn't mean it's bad. Replace M$ with Google, Apple, Amazon or any other company doing the same thing, does it actually bring out any meaningful conclusion?
I assume better Ardruino support on Windows is a good thing.
IMO some huge potential is missed by the community's collective lack of interest in leveraging Processing (or any other similar thing) to make GUI + open hardware goodies. MS has the potential to do some good here by integrating in an open source friendly way, or they could attempt dirty tricks. I'll encourage/hope for friendliness and interoperability.
I am not expecting Le Roux to be the true creator of TrueCrypt but this seems to be a pretty solid link between Le Roux and TrueCrypt.
Now about Wright, he can't even write a proper blog post with proper working scripts about cryptography...