ktRolster

The GNU team did this when they added or changed behavior to the original tools. A lot of them have flags like -posix and such which give them a strict set of behaviors.

I think he wanted more discoverable everything, the undo was just used as a particularly bad example on the iPhone.

He wants the world to be more discoverable, to modify our very culture so that learning is easy (an example he gave was with math, so it's not just a small, 'smart' percentage of the population who actually gets it, but everyone absorbs it from a young age).

Look at Squeak. http://squeak.org/ The idea that you should be able to dig in and modify things is very powerful.

Another way to look at it is in terms of discoverability: you are at one level of understanding (using the phone, clicking on things), and it should lead you to a deeper level of understanding (perhaps moving things around, modifying them). At each level, there are hooks inviting you deeper, drawing you in. Ideally you get down low enough to start programming, to actually understanding how assembly and the CPU works, so there is no longer any area of magic.

It seems to be something that's easier to do at a local level.

You owe it to yourself to get the best possible compensation package, because no one else will do it for you.

http://www.zerohedge.com/sites/default/files/images/user5/im...

I fully admitted that string manipulation is absurdly bad and error-prone, then built on that by showing a way to make it better. Use ktStrcat() instead of strCat(), then you don't have to worry about truncation. Use ktSprintf() instead of snprintf(), then you don't have to worry about truncation. I wish you had understood.

Another thing I've done that will work if you have a lot of strcat(), is make a string struct:

    ktString {
       int len;
       int memlen;
       char *str;
    }

    bool ktStrcat(ktString s1, ktString s2);
    bool ktSprintf(ktString s1, ...);

     #define ktCstr(x) (x)->str

    write(sock, ktCstr(s), s->len);

DJB did something similar in qmail, I don't recall the details but you can look at the source code as easily as I can, and it eliminated security problems.

When I'm working in Java, I find that most of my string parsing uses the split() function. This is a pain in C, because even if you had a split() function you'd need to deal with memory allocations. Most of these are solved with a memory pool. In my own library, I also added runtime, grammar-based parsing functionality. So to parse a CSV line you might do something like this:

    char *g = " S   -> WORD | WORD , S;"
              "WORD -> [^,]";
    results = parsegram(g, inputString);

Most of the criticisms you hear about C today (type safety, memory safety, no garbage collection) were criticisms that C got when it was first invented.

In fact there are fewer criticisms of C than there used to be: a lot of the early criticism centered around syntax, but the C syntax kind of won, so you don't hear that anymore.

For example, he points out that to connect C to existing parts of the system (which is the OS and OS level tools), all you have to do is call the functions. If you want to call a C library from a Java program, it's a lot more work. Furthermore, C has the capability of understanding Java structures (although it's awkward), but Java has no way of understanding C structures from within the language. There is no way to model a driver I/O port in Java, but in C there is.

The paper is worth thinking about. If you are creating a language, take interoperability between already existing languages into consideration. JNI is ok, but think how much better it could be if it did auto-marshalling of objects!

https://imgur.com/a/aTpj2

In practice, OpenSSL should not be considered secure. At best it can be considered as a way to stop script kiddies.

That's higher than I expected.