deanfranks

(HUMOR) Are you sure it was a mistake? They are politicians...

For better or worse, most commercial embedded development is done in C/C++. If you are already familiar with these, start with Atmel Studio and an AVR 8 bit processor (easier to learn the hardware side, simpler processor) or mbed.org and one of the supported boards (STM32 Nucleos are cheap and have built-in JTAG programmer/debugger with a wide range of processors).

Pay could be higher or lower, you will almost certainly take a cut initially but there are plenty of high paying embedded development jobs.

"SQL for Smarties", Joe Celko -- an excellent resource

And even then, Kotlin, not Java.

We have been using Asterisk (SIP/IAX) for about 7 years both on "cloud" servers and field communication devices with no issues on production devices (only minor problems during development/qualification). Our experience has been very positive and the community is very helpful.

If you are looking for speeds on the order of 0.0024 Mbps (2400 baud) then maybe. You could use amateur radio packet radio gateways and radio modems and set something up.

You could do it legally (in the US) by paying a token amount and getting a part 90 business license or possibly by using MURS frequencies instead of FRS/GMRS.

Take a look at Autodesk Fusion 360. It is free to makers / small startups. I use it extensively for product prototype development including for 3d printing and subtractive machining. Another good resource is McMaster Carr, they have downloadable 3d models for most of what they sell. Having accurate 3d models for all the fasteners and other parts makes a big difference in quickly building a 3d model as well as the quality of renderings done in the cad system.

Get a good lawyer, even if you only pay for a couple of hours. There are things you can do immediately (depending on whether you received a letter or they actually filed a suit) that may make them go away.

I was party to one of these a couple of years ago and if we had received good legal advice early it would have been much less expensive in the long run.

As a developer it is worth it as long as you have separate teams responsible for development and production. Segmentation means that a prod server can't accidentally be configured to access a dev resource (db instance, etc). If you have development hand off installation packages and instructions it also means that dev never has to touch prod servers (except read access to logs, etc). It also eliminates the temptation to "temporarily" use a dev machine/instance as part of prod to solve a problem (and then leaving it that way for years).

I would start with Octave. You can use it to quickly learn the math behind music synthesis and experiment with the various methods. It is open source and available for Windows,Linux,Mac and Android (at least, there are probably other ports).

Then you can concurrently learn a programming language (IMHO based on your post, Python might be a good place to start).

You might also take a look at CSound which is a dedicated environment and programming language for sound synthesis. The CSound documentation pages also have references to a wide variety of other available systems (like Max and Reaktor).

If you are going to ultimately create audio apps for the iphone then I don't think you can avoid C/C++/Objective C but you will have an easier time doing the sound synthesis experimentation in an environment tailored to that function.

I think that would be a square peg in a round hole. If you want open, what's wrong with ODF?

It is not a high-end notebook construction-wise, but I have had very good luck with a Toshiba S70 with a full-hd screen. $499 on woot and it has a 17.3" screen, i7, a second sata bay and 2 open DIMM sockets. Battery life is good and it uses a common power adapter. It has reasonable internal speakers (better than average, not a gamer machine). Mint 17 runs like a clock and all hardware is supported by a standard install.

I wouldn't want to drop it though...

Stock certificates may also be subject to dilution at the whim of the majority shareholders.

Easy, abolish the TSA

Another non-answer for your question, but I'm not convinced that WiFi is the way to go for IOT. WiFi networks don't deal well with large numbers of clients, power is an issue and setup can be a pain.

POE would be nice for new builds where the cabling is not a problem but I don't think it is practical for anything you would want to retrofit into an existing residential structure.

If I had to bet, 6lowpan is probably going to be the winner in the wireless IOT fabric arena.

What microcontroller/board/etc is best depends totally on your application. Do you need low power, do you need processing power, do you need a significant web management interface?

I have chosen the STM32 ARM line and 6lowpan using atmel zigbee chips but your mileage may vary.

A couple of years ago IKEA NA sold a motorized sit/stand desk. No idea why they stopped carrying it, but I would assume slow sales was the reason.

C++ or Delphi (pascal) via Embarcadero

Yes, a significant number of our users still use Windows XP and building things to XP compatibility increases the chances of running under Wine for the 0.5% or so of our users who want to run linux.

Delphi -> C# is a pretty short walk, and there are lots of C#/.NET jobs around. As for learning C#, there are lots of good books and you can download Visual Studio Express and just dive in.

Not with a strong cypher. Any single bit change in the source will result in what looks like a new pseudo-random output.

Determining the private key given the public key in RSA-2048 requires factorizing large blocks of very large numbers which is not practical given current computing hardware. People are working on "smart" attacks that solve the factorization problem from a theoretical math angle instead of a brute force computational approach and there is some consensus that RSA-2048 may be broken in the next few years. A transition to Elliptic Curve Cryptography (ECC) is underway and RSA has never been approved for Suite-A or Suite-B encryption which might lead one to believe that the NSA has known about the weakness of RSA for a long time.

If the cypher being used is secure, encrypting a block of 1s or 0s will generate an apparently random stream of 0s and 1s. There will be no way to determine the private key from the output of encrypting a block of known data with the public key.

Are you asking what languages fill that gap, or how C programs interface with assembler libraries and OS interfaces?

Or get the best of both and get an Aeron lab stool and use with a sit/stand desk. You can stand when you want to, and just pull up the stool to sit.

http://www.hermanmiller.com/content/hermanmiller/english/pro...

If you want to learn assembler to analyze malware, learning x86 assembler under linux or windows is where you should start. If you really want to start with a microcontroller, the AVR is a good place. You can use one of the Atmel XPlain boards or an Arduino with the Atmel Studio. I would recommend getting an AVR Dragon JTAG interface, being able to debug at the hardware level is invaluable when you are learning or doing "real" development in assembler.

Note that a good portion of the learning curve for AVR or other microcontroller assembler is learning the hardware environment and learning about interrupts, execution environment setup, etc etc. None of this is particularly useful for malware analysis on x86 hardware.

If you are going to analyse malware under Android/etc then ARM is not such a bad idea. The PI or the BeagleBone are excellent platforms for getting started. Be aware that ARM assembler is a bit of a beast and is probably not a good first architecture to learn.

I am not an attorney, but my understanding is that you do not have to respond to the letter in any way unless they have filed a complaint. You might want to respond in a way to try to prevent them from filing a complaint (possibly provide them with conclusive prior art examples and threaten to respond by trying to invalidate their patent (expensive)). Letting them know you have no money to defend yourself is probably not a good strategic move.

Be aware that if they file a complaint you will have to have a lawyer licensed to practice in the state where the complaint is filed (PITA).

It would be ugly. For many architectures, locals are referenced relative to a [stack] frame pointer. The local variables from the original context of the function containing the catch would need to accessible, and any additional local variables allocated during the execution of the catch could not be added to the area addressed by the frame pointer because that portion of the stack would contain return addresses and locals for the function throwing the exception, the exception data and any additional functions between the catch function and the throw function.

If is far from impossible to implement, but it would be messy.

IMHO try/catch blocks for this kind of retry logic would have to be very small in scope to be practical and maintainable. Any significant complexity in the scope of the try block (multiple nested functions, etc) is going to create two very tightly coupled sets of code non-obviously separated in the source. This kind of pathological coupling is evil.

Since the scope should be kept small, I would always opt for comprehensive sanity checking before the operation rather than complex, oddly coupled code that is almost impossible to test.

I don't think this would work on the code or compiler end. For the compiler, when an exception is thrown, the stack is unwound back to the most recent try so the exception handler can be run in the scope of the try. In order to implement this, the portion of the stack that is unwound would have to be saved somewhere and when the recover is executed, the stack would have to be unwound back to the try again, the saved portion of the stack would have to be "repushed" and execution would resume.

On the code end, how would the exception code know what failed and what to twiddle to fix things? The logic associated with the exception code would be extremely complex and tightly coupled to the "downstream" code. It would make much more sense to validate things before performing operations you know might fail to reduce the chances that an exception would occur. Remember that executing the throw portion of an exception is extremely expensive. Exceptions should only be used for exceptional cases, not as a flow control mechanism for a common execution path.

I switch back and forth between metal working and wood working on a daily basis and have used metric for both for 15 years. With the wacky thicknesses of plywood/etc fractional units are just not convenient any more.