Mutjake

Dunno about the catchy, but Runtime as a Service could fit the *aaS pattern.

Nutrition studies are, to my understanding, a tough nut to crack i.e. it would be prohibitively expensive to hire people to allow full monitoring and regulation of their diet. Imagine using just cinnamon to spice your food every day for an extended period.

So, AFAIK these studies are often based on questionnaires (=fuzzy indicators, easily skewed as people want to decorate their answers for the better etc.) and the sample sizes are limited, so the results cannot be directly ingested as facts.

But that’s often the best we have due to the state of affairs. Option is to not do the studies at all, which seems counterproductive. At least we can duplicate the studies if the results seem promising, maybe combine some other dietary studies for a meta-analysis to try to improve the accuracy.

Not to downplay the risk of science-clad marketing with food&nutrition, what I said does not mean I carefully read the study or that it’s correct. Just wanted to contribute the general view I’ve adopted for these types of studies — the field is NP hard if you want to produce concrete facts as results, so read them with an inquisitive mind. And yeah, check for independece, it certainly doesn’t hurt :-)

Got sidetracked for a bit, but summa summarum: they probably did questionnaires, and had to live with people commonly using those mixes of spices since they cannot really insist them on using just one (or factor out the effect of other spices, since people mix in the other stuff anyways, if ask if they spice with turmeric).

If it was licensed under GPL, my bet is that Apple would not have adopted it at all.

275 € in Finland, when done online (+you’ll need a bank account for the company). AFAIK many people DIY.

In many jurisdictions there's a major problem with taxation: if you sell something from a person to another, you can usually do it tax free, at least on a small scale. If you create a company to facilitate this process, and the company acts as a middle man by buying the things from one person and selling them to another, the company probably needs to pay value added tax from the sale. In Finland, for example, that's a 23% added cost. And if you take commission, you'll need to pay the tax for that as well.

Not a 1=1 match, but you might also want to check https://github.com/aoh/owl-lisp if you need a Lisp that produces C code to gain the optimization goodies of different C compilers.

Roughly the upside is that (in theory) the attacker needs to defeat each cipher separately (barring that the combination offers some shortcuts where one cipher interacts with another so that some computational complexity can be eliminated). Downside is that the performance takes a hit (processor/bandwidth [if blocksizes don't match, dunno if this is an existing risk]), which might not be trivial.

Disclaimer: I assume that existing, proven implementations are used and out from one cipher is handed over to another as input, keys and IVs and other crypto mumbo jumbo are not recycled and that the implementation does not offer new side-channel attacks somehow etc etc.

Personally I'd wait for a while to allow more competent people to analyze the library. In the meanwhile one can do performance profiling to roughly calculate how much beefier servers are needed in a real-world scenario due to extra crypting and decrypting :-)

It's a nice way of summing up the general principle. Unfortunately I can't take the credit for coming up with that one :-)

One nice way of describing fuzzing is that it is running a search problem (searching for bugs) using more or less guided Monte Carlo method for the program's input space. Generally the testing should also be automated (test case injection and testing oracle), so that one can beat the program with enough test cases for the fuzzing to be viable.

Relating to the practical example: if one is trying to find bugs from the UI code (or it is the only way to feed inputs to the program), monkey method of fuzzing is the way to go. But if one tries to test the deeper layers of the program, it is beneficial to try to find the lowest layer of inputs we can access, since it enables faster input of test cases and thus makes the fuzzing more effective.

One way of the other, my opinion is that both are fuzzing, by the definition I gave for it :-)

It's not antiquated at all, it is still very relevant for security testing. If you're hunting memory handling bugs, for example, fuzzing is probably the most cost effective way of doing it, if you can automate instrumentation (sample input and testing oracle, IMHO AddressSanitizer is the best option for the latter ATM). If you're interested, you might want to check the wiki page of Radamsa, a general-purpose fuzzer (shameless plug for my collague): https://code.google.com/p/ouspg/wiki/Radamsa

I'm not sure how up to date the CVE list is, but it probably gives you an idea, if the fuzzing is still relevant or not :-)

Nice :-) One can do something akin to this by using Radamsa -- https://code.google.com/p/ouspg/wiki/Radamsa (shameless plug) -- to fuzz bitmaps. Similar imagery is common when fuzzing browsers with image-containing samples and can be quite mesmerizing to observe. Fuzzing other media formats (such as MIDI or audio files) can also yield "interesting" results.

From http://www.infoq.com/interviews/johnson-armstrong-oop

" Is Erlang object oriented? Joe Armstrong: Smalltalk got a lot of the things right. So if your question is about what I think about object oriented programming, I sort of changed my mind over that. I wrote a an article, a blog thing, years ago - Why object oriented programming is silly. I mainly wanted to provoke people with it. They had a quite interesting response to that and I managed to annoy a lot of people, which was part of the intention actually. I started wondering about what object oriented programming was and I thought Erlang wasn't object oriented, it was a functional programming language.

Then, my thesis supervisor said "But you're wrong, Erlang is extremely object oriented". He said object oriented languages aren't object oriented. I might think, though I'm not quite sure if I believe this or not, but Erlang might be the only object oriented language because the 3 tenets of object oriented programming are that it's based on message passing, that you have isolation between objects and have polymorphism.

Alan Kay himself wrote this famous thing and said "The notion of object oriented programming is completely misunderstood. It's not about objects and classes, it's all about messages". He wrote that and he said that the initial reaction to object oriented programming was to overemphasize the classes and methods and under emphasize the messages and if we talk much more about messages then it would be a lot nicer. The original Smalltalk was always talking about objects and you sent messages to them and they responded by sending messages back.

But you don't really do that and you don't really have isolation which is one of the problems. Dan Ingalls said yesterday (I thought it was very nice) about messaging that once you got messaging, you don't have to care where the message came from. You don't really have to care, the runtime system has to organize the delivery of the message, we don't have to care about how it's processed. It sort of decouples the sender and the receiver in this kind of mutual way. That's why I love messaging.

The 3 things that object oriented programming has it's messaging, which is possibly the most important thing. The next thing is isolation and that's what I talked about earlier, that my program shouldn't crash your program, if the 2 things are isolated, then any mistakes I make in my program will not crash your program. This is certainly not true with Java. You cannot take 2 Java applications, bung them in the JVM and one of them still halts the machine and the other one will halt as well. You can crash somebody else's application, so they are not isolated.

The third thing you want is polymorphism. Polymorphism is especially regarding messaging, that's just there for the programmer's convenience. It's very nice to have for all objects or all processes or whatever you call them, to have a printMe method - "Go print yourself" and then they print themselves. That's because the programmers, if they all got different names, the programmer is never going to remember this, so it's a polymorphism. It just means "OK, all objects have a printMe method. All objects have a what's your size method or introspection method."

Erlang has got all these things. It's got isolation, it's got polymorphism and it's got pure messaging. From that point of view, we might say it's the only object oriented language and perhaps I was a bit premature in saying that object oriented languages are about. You can try it and see it for yourself."

It depends a lot on how one defines OO, but in this regard he has -- or at least he has given some thought for it.