I did this for a decently complex distributed system for embedded devices, and it practically saved my life.
It was in C and I didn't do any language extending/precompiling, but I had interfaces for everything related to I/O, execution actors, randomness, etc.
On target hardware everything used TCP/UDP/real disk, pthreads, normal rand sources, etc. In simulation everything used virtual networking, a single simulation thread stepping all event loops, test-specified random seeds for reproducibility, etc.
It is completely invaluable. I can concisely write completely deterministic system tests that will execute tens of thousands of lines of code. I can fuzz test actor scheduling, I/O problems like dropped packets/msgs, and everything you can think of. I can run the entire test suite in valgrind and other nice tools. I can put a big machine in a corner of the office to fuzz test the suite for weeks on end and email me when a a test fails and tell me exactly which random seed to use to reproduce the failure myself within minutes. I can debug the entire simulation perfectly in GDB.
I've barely begun to describe how great it is to have, how many bugs these tests have caught or what a reliable regression test suite one can build. It doesn't replace testing on target - I do that extensively as well. Big system scenario tests don't replace smaller module and unit tests - I do those too. But deterministic simulation testing saved my sanity. Don't hesitate to evaluate this approach if you're doing something similar.
Could someone with relevant industry insight comment as to why we're not just using IMEI blacklists?
From Wikipedia: "For example, if a mobile phone is stolen, the owner can call his or her network provider and instruct them to "blacklist" the phone using its IMEI number."
Is it because it's actually mutable/not properly authenticated? Or because global blacklist synchronization isn't good enough and not all operators respect them?
The IMEI blacklists don't work across borders. My sister in law's Blackberry was stolen from her at a mall in South Africa. It was reported and added to the IMEI blacklist. A few months later I accidentally added her old PIN as a BBM contact and ended up chatting to a chap in Nigeria.
It isn't farfetched to assume that network providers don't really care about stolen phones in the third world. Until they do, IMEI blacklists won't mean much.
> It isn't farfetched to assume that network providers don't really care about stolen phones in the third world.
Network providers probably don't care about stolen phones in the first world. If they could find a way to ignore domestic IMEI blacklists without too much public outcry, they probably would.
In the US, the top four carriers make almost $8 billion per year selling theft insurance to their customers [1]. I don't have a cite handy, but I recall reading that they also make a huge amount selling replacement phones to people whose phones were stolen.
Samsung planned to do a kill switch on its phones to fight theft a while ago, and the carriers blocked it. Many believe they blocked it to protect those insurance and replacement phone profits.
Sometimes IMEI blacklists mean too much. There was a batch of cheap Chinese counterfeit phones in Bangladesh (IIRC) that all had the same IMEI. One got stolen, the IMEI got blocked, and all of that make of phone was unusable.
As far as I can tell, it is because they are either lazy or the systems are not exposed to the underlings you can actually call most of the time.
I worked closely with carriers and they would resist any attempt for you to do anything in their system and insist it wasnt possible unless you had the cops or the legal system behind you.
In a previous post (a little over a year ago) about the same engine I posted a link to a video with a Q&A with Elon Musk where he was a bit pessimistic about the idea.
I'm not a rocket scientist so I wouldn't know the first thing about it, but if anyone is interested in his (then) opinion it's after 48m55s in the video here: http://www.oxfordmartin.ox.ac.uk/videos/view/211
Elon Musk isn't the expert in this area. Practically no one except Reaction Engine employees and some guys at Area 51 are - in the entire world. It's certainly not an easy thing to do, but since they actually do seem to have the heat exchanger figured out then that's kind of a big deal.
Burying the lead is the whole commercial air travel angle though. What they're building is a fully reusable, cheap to operate SSTO to low earth orbit.
ESA did a review of Skylon and the Sabre engine and said "...the SKYLON vehicle can be realised given today's current technology and successful engine development."
Of course, there needs to be a successful engine development project. Which needs another billion or two to complete according to the CEO/MD of Reaction Engine. (He was a bit more specific than that when I heard him say it, but it is in the ballpark.)
It may very well go that way, but I think unikernels (like MirageOS (http://http://www.openmirage.org/) are very interesting as well. A paravirtualized unikernel should be able to carry less overhead than regular virtualized OSs and be able to operate completely in ring0/kernelspace.
Pair that with all the hw acceleration for virtualization available these days and you may get some pretty lean and fast virtualization that also more easily support hybrid deployments (Container software needs to be built for specific container host OSs and libs(depending on how much is bundled in each container)).
Also, the security implications of containers vs (para)-virtualization are different, so I think my personal jury's still out on that one too.
But I do agree that these are interesting times, for sure. And containers may win, I just don't think it's a done deal just yet. :)
A really important (I think) point with regards to all the comparisons to Go and other similar languages that pop up in every Rust post:
Many seem to think that only Rust is suitable for kernelspace but are questioning whether Go or Rust is more suitable in userspace. A Go library will work in a Go process (due to the need for (shared) GC in the runtime, among other things), whereas a Rust library that avoids GC (which is idiomatic Rust) will (I think!) be able to expose an interface akin to a C library (similar calling conventions, internal data type layout like C, etc), making it usable from practically any language with C-FFI.
Personally, this is one of the things I look forward to the most. We can create drop-in replacements for C libraries, creating a safer (but just as fast) world one library at a time. And if so desired, all the functionality will be available to anything that can interface with C. Even Go. Your Go libs are stuck in Go's universe. Your Rust libs can be made available to anything that can bind to C.
Go eats the C/C++/Python/Ruby cake from the top, but it just can't go all the way to the bottom. Rust can eat the cake from the very bottom (bare metal/kernelspace and up), but just like Go, the sky's the limit - and for many reasons, like e.g. even better constraints on shared data than Go has, I personally believe it will go even "higher".
My two cents. And as always: More knowledgeable Rust people, if I'm wrong, please correct me.
Providing Go code as a shared library that is linkable from other languages is not technically infeasible, it is merely difficult. In 1.4 we aim to be able to load Go programs into a host process (on Android this will enable a Go process to live in the same memory space as a Java process), and also have a more general plan for Go shared libraries.
Brad Fitzpatrick has suggested in one of his talks that Go is interested in being embeddable as well, so I'm excited to see that. I have no doubt they'll do an awesome job.
It's really designed to be a first-class citizen from the ground up in Rust, though. Having no GC, precise control over stack vs. heap allocations, support for native calling conventions, a pluggable runtime, and a very fast FFI helps with that.
Now that "embedded" is being redefined to include ARM processors, we have already seen Go in such contexts. This is a great talk: https://www.youtube.com/watch?v=a4BQRUpQoe8
We'll never see Go on 16-bit architectures or smaller, though.
Embedded and embeddable are different things. Embeddable refers to the ability to call code written in your library from any other environment (and these days, over a C FFI).
> Go eats the C/C++/Python/Ruby cake from the top, but it just can't go all the way to the bottom.
I do bash Go a lot, but it would be possible if the designers took the same approach as Cedar, Oberon and Modula-3. A few GC enabled system programming languages.
- Expand the capabilities offered by the unsafe package
- Offer more control over the GC behavior
- Add a kind of untraced pointer or a GC API for allocating them
I'm a meditation novice so take this with a grain of salt, but the only "For Dummies"-book I've ever enjoyed was "Meditation For Dummies".
It's not a heavy read like some meditation tomes can be but it's not very dumbed down either (IMHO), and it recognizes that some people are interested in the spiritual parts, some the philosophical, while some are only interested in the practical. The book has them all to a good extent, but helps you navigate to the parts that are of use to you.
I'm sure YMMV and different books suit different people, but this one worked well for me. I recommend it, but regardless of what resource you use: There is calm to be found, and it can feel great. Good luck!
Are you saying that there's law in California (i.e. something you can violate that the justice system has the authority to punish you over) that is not freely (as in freedom) available to any citizen (for whatever purpose, reading, distributing, etc)?
As a practical matter, no, its not freely available. There is a reason why no one knows the law, and its not because no one tries, but because their efforts to know the law that binds them are actively thwarted by its publishers.
It is available online, but its unusable for the layman due to ridiculously bad design. You must agree to a contract to use it ("terms of use", "license") and promise never to repeat what you read. Purposely bad design in my opinion. Its 30,000 sections of regulations we're talking about here (there's a further 150,000 sections of California law, 50,000 sections of federal law, and 30,000 sections of federal regulations), and you only know it doesn't apply after you read it. Its javascript-based and uses session cookies, so if you take longer than 5 minutes to read a 30 page section with a bad layout that uses intensely complex verbiage, the next click will "close the book" in your face, and if you have no idea where you were, well, tough luck, there's always prison. If you try and open multiple windows, say, to read another section which is referred to, each window will interfere with each other. (Even trying will likely close the book in your face.) Each click is unbearably slow to load. (29,999 bottles of beer on the wall, 29,999 bottles of beer, take one down, can't pass it around, 30,001 bottles of beer on the wall.) There is no way to give a permalink to your grandma or on your blog, because there are no permalinks. Grandma will have to try and navigate the horrible website herself, and when she likely fails, well, tough luck, there's always prison.
It is available as bulk data on CD-ROM (in California) for a significant price, on the order of $3000 per edition. Did I mention it changes almost constantly? Obviously, no permalinks for your blog.
California is better than most in that the government was sued and forced to release the statutory law on the web.[1] Other states are not so lucky.
Can you point out a state that does not provide their laws and regulations available online? I have never experienced a situation where the laws of a state are not available online for free, and I've researched laws in all 50 states. As for regulations, I've not researched those in each state, but the states that I have looked at regulations in all have them available online, so I think a citation is needed that there are state or federal laws or regulations that are not available freely online.
And what contracts have you entered into for this "free" access? What have you agreed to, what rights have you given up? And when will your obligations end? Do you even know, or did you just blindly click "I agree"?
I know this sounds lame, but freedom isn't free, and you shouldn't have to give up any rights to access the laws that bind you. Period. No exceptions. No compromise.
(I should note the biggest problem with this seems to be codified regulations, not so much the codified laws or gazettes, although some states do require a contract to view the "free" versions of the statutes, such as Georgia and Colorado. And I should note the online version of the Code of Massachusetts Regulations from the Secretary of the Commonwealth costs $110 per year and requires a credit card...)
As a matter of principle, in the US at least, laws to which you are bound are supposed to be freely-as-in-freedom available. That doesn't mean they invariably are, though; people find various ways to extract rent from the law.[1]
Usually the law as enacted by the legislature / ruled by the courts is free, but they might incorporate by reference some non-free rules developed and maintained by commercial entities. These are things like building codes, fire codes, and so on, which might cost thousands of dollars for a copy and not be redistributable. [2] The recentish example (2002) is Veeck vs. SBCCI[3].
I've made a FOIA request for all regulations, including the building codes (which is title 24), with the OAL. They claim not to have them. They claim they don't have the regulations they are entrusted with publishing, and that I should buy them from someone else. I'm sure there's a perfectly legal reason for this, such as being morally corrupt, but legality aside, the current and all former directors of OAL should be impeached for entering into such scandalous contracts. Its simply unacceptable.
I don't usually complain about titles (and I know it's the original one from the article), but I came here with the fascinated (though admittedly skeptical) hope that someone had improved radically on botnet DDoS mitigation techniques. It would be better if the title contained words like perhaps "ad" and "fraud".
There are standards for Home Automation communication out there - ZigBee and Z-Wave. These are the low power communication protocols that home automation devices can use to talk to each other (WiFi is too power hungry and heavy weight). If you take apart a Nest thermostat you can find an unadvertised ZigBee radio buried inside.
ZigBee is an open standard developed by an alliance of device manufacturers. Z-Wave is a proprietary standard developed by Sigma Designs. Both are able to create a low power mesh network for communication between home automation devices. These protocols have been around for a while and are supported by 100s of device manufacturers.
That said, I have no idea what Google/Nest or Apple plan to do. They may be creating their own standards for communication, or they may build a communication protocol on top of ZigBee or Z-Wave.
If you're interested in working with an interoperable standard now though, you can buy off the shelf ZigBee or Z-Wave radios, devices that speak ZigBee/Z-Wave, and build your own HA solution. However, I've found through personal experience that interoperability between devices using the same standard is not always perfect. I'm looking forward to the heavyweights getting into the ring and hopefully cleaning up the industry and making it more interoperable.
It was in C and I didn't do any language extending/precompiling, but I had interfaces for everything related to I/O, execution actors, randomness, etc.
On target hardware everything used TCP/UDP/real disk, pthreads, normal rand sources, etc. In simulation everything used virtual networking, a single simulation thread stepping all event loops, test-specified random seeds for reproducibility, etc.
It is completely invaluable. I can concisely write completely deterministic system tests that will execute tens of thousands of lines of code. I can fuzz test actor scheduling, I/O problems like dropped packets/msgs, and everything you can think of. I can run the entire test suite in valgrind and other nice tools. I can put a big machine in a corner of the office to fuzz test the suite for weeks on end and email me when a a test fails and tell me exactly which random seed to use to reproduce the failure myself within minutes. I can debug the entire simulation perfectly in GDB.
I've barely begun to describe how great it is to have, how many bugs these tests have caught or what a reliable regression test suite one can build. It doesn't replace testing on target - I do that extensively as well. Big system scenario tests don't replace smaller module and unit tests - I do those too. But deterministic simulation testing saved my sanity. Don't hesitate to evaluate this approach if you're doing something similar.