Are we about to see a full-blown low power 32-bit MSP430-family processor from TI? If so, what will it be — a new architecture, an ARM Cortex M variant, or something else?"
Link to Original Source
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
I swear on my life, I have the exact same story (Dave or John, is that you?!?!)
Back country camping the Tetons (this was summer 1990 I think), we took care to hoist anything with smell 100ft away, up in the trees... all of a sudden in the middle of the night, we hear an animal, which sounded very large, moving around our camp. Snorfling, walking, breathing, exploring.... it was probably only 5 minutes, but I swear, it felt like an hour. I have never, ever been more motionless in my life. 2 of us think it was a bear, one thinks it was a moose. All 3 of us agree at the time it sounded like a bear, and we all were having visions of huge bear claws shredding our tent into ribbons.
I've lost contact with my buddies (the aforementioned Dave & John), but I am 100% sure if I told this story, they would remember it instantly. Thank you for posting this, as I said, you described my/our experience to a T, so much so that I had to post a reply.
Mixelbin?!?! C'mon man, get with the times!!! All the kewl kids are dropping vowels like a bad habit.
Much better to go for mxlbn, it's way cooler.
Ironically (I believe that is the correct use of the term), mxlbn.com is actually available as a domain name as well. At least as of 4:18pm P.S.T.
Serious question (in case it sounds like I'm being antagonistic):
Since AES is a block cipher, and an AES block is 16 bytes, and since keypresses appear to be transmitted "instantaneously", does that mean for each keypress, a 16-byte block is formed, and encrypted? And what about the encryption mode? (Otherwise doesn't it basically become ECB?)
Seems like a stream cipher would make more sense, although you'd need a protocol on top of that to stay synchronized, since packets can become lost/corrupted.
I could only find a very non-technical PDF on the topic. Interestingly, the wording seemed to imply something like a DH key exchange (one time, during pairing).
The Net interprets censorship as damage and routes around it.
Here we have Sony trying to interfere with routing in order to accomplish censorship. That certainly won't backfire...
Well it depends.
Mr. Polansky himself (while certainly not a security expert or a cryptographer) describes it as a "weakness" built into the system. The streets are littered with products and systems built with backdoors/weaknesses that are found & exploited by attackers (sometimes an insider who knows about or helped implement the weakness.)
On the other hand, while still subject to abuse, if the "weakness" is a 2nd, high entropy key, then you either have to get the key, or break the crypto (getting the key obviously being the attacker's 1st choice). This is different than a backdoor.
C++ is no more complicated to use than C.
This I have to take issue with. I will agree that C++ is a useful language, including embedded systems, but it's much, much more complicated than C. You can write in a subset of C++ which is largely the same as C (never quite the same though), but if you were to draw a Venn diagram of C++'s features vs. C, it's crazy (I went through this exercise, for a presentation). Again, don't get me wrong, I've been using C++ on real time systems for 20 years, but it is an entirely different animal. For an example (this is a quote from Peter van der Linden's outstanding book "Expert C Programming", in fact I think he was quoting Tom Cargill):
"If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?"
There are other examples, but hopefully that one serves as a good example.
If you don't like a particular part of C++? Don't use it.
Here I am 100% in agreement with you, at least when it comes to personal projects. The problem is that when you work in a larger organization with a disparate knowledge of the language, you've got some people writing "C with classes" (if even that) and some people using template metaprogramming, complicated overridden copy constructors, placement new, custom allocators in STL containers, etc. Now, sometimes you can either just "use" that wizard's code and hope for the best, or just read it and run away, but sometimes you have to maintain it.
I am working with a group right now where I am the "C++ expert" in the group (I don't consider myself an expert), and there were a few individuals in the group, years back, that
I won't be surprised if something like Lenticrypt (crypto using a running key cipher which ends up decrypting into different plaintexts) ends up being the nail in the coffin.
It's an interesting thought experiment... just how far will the desperate & ravenous copyright cabal go to claim ownership of bits that aren't even related to their product?
Let's say I have a bitstream that is *almost* bit for bit identical to an MP3, an MKV, etc. How bits have to change before it is no longer infringing? Don't start with things like, "Well, it depends how it was created and for what purpose..." Bits are bits. If I AES encrypt something (e.g. Linux distro) that ends up being 500 bits away from "Star Wars", am I in trouble? Do I have to prove how I created my "almost Star Wars"
I think pretty soon we're going to start seeing big binary blobs (my term, BBBs) that can be transformed into Star Wars, the Oreilly book collection zipped up, or a backup of my dropbox (of course that would be possible today using OTP and 3 different keys, but Lenticrypt simplifies it). So am I going to get sued because these 30 billion bits, manipulated in one specific way, could become Star Wars?
My point is that at a certain point, common sense must prevail. I understand that Amy Pascal likes her $100M payouts, and Tom Cruise likes his $50M movie checks. But all good things must come to an end. Many IT & software development professionals met head-on with the whole "adapt or die" reality when outsourcing to Asia & eastern Europe began years ago. And yet here we are.
First of all, kudos to your small shop for actually signing your executables. I still find myself needing to install software from companies ($100M+ companies) that don't sign their executables (IAR Systems (ARM cross compiler), I'm looking at you, for example...)
Anyway, I just wanted to clarify one thing that you wrote, because a lot of people don't understand the security implications:
Note that all this provides is proof that the exe was created by us
Technically, all this provides is proof that the exe was created by someone who has your private signing key. That's exactly what's going on here with Sony. The whole signing / certificate thing works, right up to the point where the signing key is leaked or extracted. I know you know this, but it's important enough IMO that it merits re-stating...
It's good to know embedded systems are new-ish technology!
Really makes me feel good about the implantable cardiac defibrillators, hard disk drives, engine control units, CNC machines, remote weather stations, mobile phones (baseband), insulin pumps, etc. that I've worked on for the last 20+ years.
A home might have 3-5 desktop/laptop processors in it, while that car on the driveway probably has at least 20, maybe 50, processors in it.
Embedded systems, and the engineers who design the hardware, software, firmware, etc. are kind of like air - all around you, and you don't really notice them, but you sure would if they disappeared.
Now if you'll excuse me, I have a soapbox to step down from, and a lawn in need of protection from young whipper-snappers.
Remember that kerfuffle a couple weeks ago about FTDI bricking products that were using counterfeit FTDI USB-serial chips? Some of the product designers were unknowingly using counterfeit chips bought from companies we've all heard of (no, not Alibaba or Ebay...)
I don't know exactly how this would have worked anyway.
It's been a while since I worked on LTE (call processing, not RF or hardware or even baseband), but I thought that with UTRAN there was a 350 km/h "speed limit" (perhaps up to 500 km/h under certain circumstances) with motion relative to the base station.
(Now that I spent 5 seconds thinking about it, I suppose the sine of the angle (from base station to aircraft, relative to vertical) would reduce the velocity that the plane was moving away from the base station... I think?)
I'm sure there are many other effects such as transmit power, interference, fading & multipath, etc. Sheesh I'm getting rusty...
I'm not trying to be antagonistic, but basically in the same breath, you said that you're not a programmer, yet you judge programming to be a trade like plumbing.
I can't reconcile those two, and I respectfully disagree.
By the way, I totally agree about code riddled with bugs. I work on safety-critical software, and I can assure you, not all software (firmware in my case) is of such low quality. But I'll also concede that the cost and time to develop such software is much longer than your typical slap-happy PHP script running on foo.com's webserver...
"Who alone has reason to *lie himself out* of actuality? He who *suffers* from it." -- Friedrich Nietzsche