gothenburg
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...
I don't feel the author is milking any of it to make the article more interesting.
"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."
In: https://mastermind.atavist.com/he-always-had-a-dark-side
Nothing changed really, except that we have one less bloat in the CM rom.
https://github.com/microg/android_packages_apps_GmsCore
An open-source replacement of Google services. You can use Signal with this.
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.
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 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.
OSM has the most complete and updated maps I have ever seen compared to Google Maps and Nokia HERE. And it has much more POI registered as well.
My only issue is that the UI of the Android app is not that good and efficient when compared to HERE.
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.
It's a good thing, not a bad one.
Maybe because the result might be a bit unpredictable and it's better to be safe than sorry?
Computers by nature were never easy to use. And still they are not. And it's a good thing that they are not.
Technical blog writers write long articles so that people can understand what's happening and so that people can work their way around an unexpected problem.
If you can't understand these points, you are better off using Windows or Ubuntu and calling some technical line for help from more experienced people.
I can understand Italian at some degree as well, due to the same reason.
This is scary. I want the tool to tell me "I can't synthesize this" because when it does, it might infer characteristics of the design that I might not want.
Do you have some kind of paper or detailed explanation about this part?
Sometimes a bad design is not bad because it's badly written, it's bad because it's not complying with some timing constraints or because the synthesis tool decided to infer some crazy system from the code the designer wrote.
And I'm not sure if you fully understand the difference between a programming language and a hardware description language. Yes, HDL's syntax might be awkward sometimes (whether it's Verilog or VHDL) but I think you are tackling the wrong problems with the wrong way.
Taking the example you gave:
always @(negedge reset_n or posedge clock) begin
if (~reset_n) begin
count <= 4'b0;
FSM <= init;
end else begin
case (FSM)
init: begin
if (count != 4'h8) begin
count <= count + 1;
FSM <= init;
end else
FSM <= next_state;
end
next_state: // blah
end
end
Can you point exactly what do you think it's wrong with this syntax? And don't compare it with a while() cycle in C, because this is a totally different thing. I'm not saying that this is the perfect way of doing things but there are good reasons why Verilog ended up this way.
I'm really scared with this whole "Hardware design for software developers" thing. Hardware design is very complex and if you aren't careful with what you write, you might end with problems like: CDC, synthesis tools mistaking flip-flops with latches, problems with the insertion of scan chain, and so on.
And by the way, where do you define your clocks in Cx?
You touched the subject of the awkward syntax of VHDL. But what about the syntax of Verilog? The syntax seems to be very similar to Verilog.
And besides of the syntax, what are the other features that this language brings that we can't find anywhere else?
And why do you claim that this is oriented "for developers"? Who are these "developers"? Software guys?