HN user

gothenburg

33 karma
Posts0
Comments19
View on HN
No posts found.

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...

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.

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."

In: https://mastermind.atavist.com/he-always-had-a-dark-side

The WhisperPush already existent in CM12 also required the Google Play services to work. So until you installed Gapps, you had no way of using it.

Nothing changed really, except that we have one less bloat in the CM rom.

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.

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.

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.

I have been using OSM on Android for a while (through OSMAnd) and I disagree with you.

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.

Megaprocessor 11 years ago

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.

Maybe because those updates might break some other custom packages or custom configurations that you might have?

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.

Be careful, that's a huge fallacy. Just because you can notice the etymology that doesn't make you a prodigy at a language. Everybody can do that, the tricky stuff is in actually learning the language.

This is true. I'm Portuguese and I can read full texts (even books) and I never had a course, or even a lesson, of Spanish.

I can understand Italian at some degree as well, due to the same reason.

"Another property is that there is no synthesizable subset in Cx. As far as I know, this is very rare in languages for hardware design, but the language is entirely synthesizable. You never have to think about synthesis versus simulation. Exactly like in software, nobody ever wonders if they can write code that won't run on the processor :-)"

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.

What I really wanted was a better explanation of Cx's advantages other than "The syntax is similar to C".

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
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?

I fail to understand what kind of advantage this language brings to the table compared to the existing solutions.

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?