Slashdot Mirror

Yes. The outcome of the Wigner's friend experiment (Described in more detail by David Deutsch in section 8 of this paper). In that case, the Copenhagen interpretation predicts that we would see no interference, whereas the Many-Worlds interpretation would say that we would see interference.

These experiments you mention have no chance of testing that, because they are looking for completely different stuff. What the interpretations of quantum mechanics differ on is how very large and complex quantum systems behave. I think it will remain impossible in the foreseeable future to do the experiment as described. But in my opinion, a good enough simplification can be done if we have a universal fault-tolerant quantum computer. That, is not that far. I would guess 20 years, if funding keeps constant at the current level.

1) There's really not much difference between optionals and Go's pointers. Variables in Go cannot be uninitialized. They have to contain a valid value, and the default value is the "zero" for the type. But a pointer can point to nil (which is the zero value for pointers). Curiously, Go also allows chaining of nil pointers, but the function specifies the behavior if the container is nil. The two implementations seem to be almost identical.

2) It depends. There's an argument to be had either way, and I don't really know what the right answer is. But the multiple return values make manual error handling in Go far less cumbersome than it is in C or C++. That said, if exceptions are your thing, Java is very good with those, and also shares nearly all of Swift's functionality.

5) I doubt it. It's something that can be handled by libraries just as easily, such as with the Preconditions class in Guava.

Everyone uses MI.

I've never seen a coding standard that didn't wave giant caution signs as multiple inheritance. Google's is easy to find, but dozens more from big companies are available.

Interfaces are different, but (a) that's not really enforceable under JS and (b) that would be totally different from your assertion, which only talked about avoiding the diamond antipattern.

you would use a an OO language that is based on prototypes people like you would not even realize the difference between a prototype based and classed base hierarchy.

You're missing the point. I'm not talking about syntax. I'm saying that the "power" that prototypical inheritance exposes is not worth the complexity that that power costs. Nothing to do with the syntax. Everything to do with all those arguments you made initially for using prototypical inheritance increasing the complexity.

Being mutable or not, that is a security thread. And to ensure immutability you often enforce that certain classes can not be extended classed like "final classes" in Java.

Except, you cannot declare a prototype final, pretty much because then it's no longer a prototype. And that's actually not going to solve the problem I bring up either.

You can change the prototype that an object is based on in runtime. I have no idea what useful purpose it serves. But that simple fact produces a ton of complexity in the code. This complexity has been the historic source of bugs and security holes.

(I work at Google and use C++ there, but what follows is my opinion)

What precisely don't you like about the C++ style guide? (This is almost identical to the internal guide)

- It is true that exceptions are verboten, but honestly it's not particularly limiting. Java gets exceptions right - something is truly "impossible" (in a crash-the-program you-have-a-logic-error sense) and thus you don't need to handle it, or else it's "expected" like an I/O issue and the language forces you to do something with it - either try/catch, or declaring that you're potentially passing it along. C++ doesn't have any such enforcement, which makes it very hard to reason about what a function may throw at you. You rely on everybody in the entire call hierarchy doing the right thing. Reminiscing about my Java days, the lack of exceptions does make some things somewhat more cumbersome to deal with - having to explicitly return a status object, for instance, to deal with plausible-but-atypical cases. But the Google guide is fairly apologetic in this area and basically says "sure, we'd use it if we had a brand-new codebase, but we don't..." and the reasons that follow for why exceptions are hard to integrate into a truly enormous codebase seem sound to me. What do you disagree with about this reasoning?

- There is certainly no rule about "allocate at the top, clean up at the bottom, never return from the middle". In fact, with unique_ptr and the like, there's even less reason to do those kind of things than there's ever been. The local variable part of the style guide actually explicitly encourages as-close-as-possible declaration, and the rest of the style guide is quite gung-ho about unique_ptr (we actually had an internal class for a long time that was sufficiently identical to unique_ptr that they were able to replace all uses and remove the custom type in just a few months). I can find no reference to any sort of prescription about the location of return statements.

- The standard libraries have actually been moving away from exceptions, haven't they? C++11 introduced 'noexcept' and added it to a bunch of methods, and the specs for a lot of other ones guarantee that the only exceptions are from the allocator (e.g. std::bad_alloc). To be clear there is no prohibition against *using* code (especially the standard library) that may throw exceptions.

In a nutshell the style guide is, in order, "be readable" followed by "be consistent". It is hilariously easy to write unreadable, bug-prone C++ code. Nobody cares if your code is perfect and correct, they care if the next guy along can modify or use it correctly and it is useful to have a style guide to make some of the more hard to reason about things impossible. How many different bits of code could the statement 'a = b;' potentially execute? (It's a lot - copy constructor, operator=, operator Foo(), etc.) The style guide limits it to just a few things you might have to consider, so that when you use some code someone wrote 6 years ago there's not so much to look at. C++ has references and pointers, which is great, but at least with pointers there's a hint that you might have "spooky action at a distance" so the guide mandates their use for out-params which seems perfectly reasonable since it's basically arbitrary which to use - and in practice, it's a really handy hint to have when you're reading. Unless you're passing an address, you know your copy can't be modified. IMO, way more readable.

If you've really been hanging up on recruiters because you object to the style guide, it is probably worthwhile to actually ensure that your understanding of it is correct and up to date. It has changed in recent years as C++11 has become better understood and it is fair to say that it is far more liberal to things like lambdas, template metaprogramming, operator overloading, copyable classes, etc - than it was a few years ago.

(I work at Google and use C++ there, but what follows is my opinion)

What precisely don't you like about the C++ style guide? (This is almost identical to the internal guide)

- It is true that exceptions are verboten, but honestly it's not particularly limiting. Java gets exceptions right - something is truly "impossible" (in a crash-the-program you-have-a-logic-error sense) and thus you don't need to handle it, or else it's "expected" like an I/O issue and the language forces you to do something with it - either try/catch, or declaring that you're potentially passing it along. C++ doesn't have any such enforcement, which makes it very hard to reason about what a function may throw at you. You rely on everybody in the entire call hierarchy doing the right thing. Reminiscing about my Java days, the lack of exceptions does make some things somewhat more cumbersome to deal with - having to explicitly return a status object, for instance, to deal with plausible-but-atypical cases. But the Google guide is fairly apologetic in this area and basically says "sure, we'd use it if we had a brand-new codebase, but we don't..." and the reasons that follow for why exceptions are hard to integrate into a truly enormous codebase seem sound to me. What do you disagree with about this reasoning?

- There is certainly no rule about "allocate at the top, clean up at the bottom, never return from the middle". In fact, with unique_ptr and the like, there's even less reason to do those kind of things than there's ever been. The local variable part of the style guide actually explicitly encourages as-close-as-possible declaration, and the rest of the style guide is quite gung-ho about unique_ptr (we actually had an internal class for a long time that was sufficiently identical to unique_ptr that they were able to replace all uses and remove the custom type in just a few months). I can find no reference to any sort of prescription about the location of return statements.

- The standard libraries have actually been moving away from exceptions, haven't they? C++11 introduced 'noexcept' and added it to a bunch of methods, and the specs for a lot of other ones guarantee that the only exceptions are from the allocator (e.g. std::bad_alloc). To be clear there is no prohibition against *using* code (especially the standard library) that may throw exceptions.

In a nutshell the style guide is, in order, "be readable" followed by "be consistent". It is hilariously easy to write unreadable, bug-prone C++ code. Nobody cares if your code is perfect and correct, they care if the next guy along can modify or use it correctly and it is useful to have a style guide to make some of the more hard to reason about things impossible. How many different bits of code could the statement 'a = b;' potentially execute? (It's a lot - copy constructor, operator=, operator Foo(), etc.) The style guide limits it to just a few things you might have to consider, so that when you use some code someone wrote 6 years ago there's not so much to look at. C++ has references and pointers, which is great, but at least with pointers there's a hint that you might have "spooky action at a distance" so the guide mandates their use for out-params which seems perfectly reasonable since it's basically arbitrary which to use - and in practice, it's a really handy hint to have when you're reading. Unless you're passing an address, you know your copy can't be modified. IMO, way more readable.

If you've really been hanging up on recruiters because you object to the style guide, it is probably worthwhile to actually ensure that your understanding of it is correct and up to date. It has changed in recent years as C++11 has become better understood and it is fair to say that it is far more liberal to things like lambdas, template metaprogramming, operator overloading, copyable classes, etc - than it was a few years ago.

(I work at Google and use C++ there, but what follows is my opinion)

What precisely don't you like about the C++ style guide? (This is almost identical to the internal guide)

- It is true that exceptions are verboten, but honestly it's not particularly limiting. Java gets exceptions right - something is truly "impossible" (in a crash-the-program you-have-a-logic-error sense) and thus you don't need to handle it, or else it's "expected" like an I/O issue and the language forces you to do something with it - either try/catch, or declaring that you're potentially passing it along. C++ doesn't have any such enforcement, which makes it very hard to reason about what a function may throw at you. You rely on everybody in the entire call hierarchy doing the right thing. Reminiscing about my Java days, the lack of exceptions does make some things somewhat more cumbersome to deal with - having to explicitly return a status object, for instance, to deal with plausible-but-atypical cases. But the Google guide is fairly apologetic in this area and basically says "sure, we'd use it if we had a brand-new codebase, but we don't..." and the reasons that follow for why exceptions are hard to integrate into a truly enormous codebase seem sound to me. What do you disagree with about this reasoning?

- There is certainly no rule about "allocate at the top, clean up at the bottom, never return from the middle". In fact, with unique_ptr and the like, there's even less reason to do those kind of things than there's ever been. The local variable part of the style guide actually explicitly encourages as-close-as-possible declaration, and the rest of the style guide is quite gung-ho about unique_ptr (we actually had an internal class for a long time that was sufficiently identical to unique_ptr that they were able to replace all uses and remove the custom type in just a few months). I can find no reference to any sort of prescription about the location of return statements.

- The standard libraries have actually been moving away from exceptions, haven't they? C++11 introduced 'noexcept' and added it to a bunch of methods, and the specs for a lot of other ones guarantee that the only exceptions are from the allocator (e.g. std::bad_alloc). To be clear there is no prohibition against *using* code (especially the standard library) that may throw exceptions.

In a nutshell the style guide is, in order, "be readable" followed by "be consistent". It is hilariously easy to write unreadable, bug-prone C++ code. Nobody cares if your code is perfect and correct, they care if the next guy along can modify or use it correctly and it is useful to have a style guide to make some of the more hard to reason about things impossible. How many different bits of code could the statement 'a = b;' potentially execute? (It's a lot - copy constructor, operator=, operator Foo(), etc.) The style guide limits it to just a few things you might have to consider, so that when you use some code someone wrote 6 years ago there's not so much to look at. C++ has references and pointers, which is great, but at least with pointers there's a hint that you might have "spooky action at a distance" so the guide mandates their use for out-params which seems perfectly reasonable since it's basically arbitrary which to use - and in practice, it's a really handy hint to have when you're reading. Unless you're passing an address, you know your copy can't be modified. IMO, way more readable.

If you've really been hanging up on recruiters because you object to the style guide, it is probably worthwhile to actually ensure that your understanding of it is correct and up to date. It has changed in recent years as C++11 has become better understood and it is fair to say that it is far more liberal to things like lambdas, template metaprogramming, operator overloading, copyable classes, etc - than it was a few years ago.

Using C++ in Mozilla code
Google C++ Style Guide

Obj-C is not as portable as C++

And C++ isn't as portable as C.

Straw man, the question is Obj-C v C++ not C++ v C. And for nearly any practical sense you are mistaken, its rare to find an environment that has C support but not C++.

Or as efficient.

Speaking as an assembly language programmer, you have been misinformed. Can C++ classes and templates be misused, absolutely, but that is a programmer's error not the language's. Can an STL class be overkill, yes, but the STL is about convenience and correctness not performance, and a programmer's misuse of such a library is another programmer's error.

**IF** and when it matters code can be written in a C'ish manner, possibly with minor use of classes or templates, and the generated code will not suffer. To be honest when dealing with extremely time critical code if C++ is going to be replaced I will replace it with assembly.

Limiting your options to C in the non-time critical portions of you code is completely unnecessary. You can write the C'ish code I mentioned above or you can write pure C code if you with for the minor amount of code that is time critical.

There really is no downside to using C++ in core code rather than Obj-C.

But there are downsides to using it in this capacity rather than C. Which is why few do so.

Again, a straw man, and again you have been misinformed with respect to C++'s usage. Ex: "C++ is the main development language used by many of Google's open-source projects." http://google-styleguide.googl...

The problem is not inefficient coding style. The problem is that people not knowing what they're (really) doing leads to security issues. If a person does not know WHY he is supposed to do something and just does it because he's told to do it, he does not know what to look for when trying to avoid pitfalls.

Look at the OWASP Top 10. And while I don't think too highly of them as an organization, their top10 reflect pretty well what problems I find in web apps during audits myself. Even though it looks almost unbelievable that SQL injections are STILL the leading cause of web insecurities. Despite there being a near foolproof silver bullet for this problem (parameterized queries and prepared statements, if used correctly). There is exactly NO reason why (with programmers deserving that name) this should even still be on the list. Let alone at the top spot.

Of course people use frameworks and languages that allow abstraction. Actually this can well increase security, nobody in their sane mind would write their own security libraries. And while some might now cry that OpenSSL is maybe not the best example with heartbleed and POODLE still well in our memory, you do NOT want to see the security holes the average roll-your-own security implementation has. Using libraries is a GOOD thing.

But the person using it has to know what they're doing! Just copy/pasting something off stackexchange is NOT going to end up in decent code!

Though youtubes design decision probably predates this. Google's own style guide states that unsigned integers should not be used simply to indicate a number will never be negative and instead to use assertions for that. Basically it emphasizes not to use unsigned integers unless there is a really good reason to do so.

Because they were following the Google C++ Style Guide?

"You should not use the unsigned integer types such as uint32_t, unless there is a valid reason such as representing a bit pattern rather than a number, or you need defined overflow modulo 2^N. In particular, do not use unsigned types to say a number will never be negative. Instead, use assertions for this."

Coding standards: pick anything and stick with it. Use Google's. Why not? (Haha I note they are using svn.)

http://google-styleguide.googl...
https://google-styleguide.goog...

These types of decisions are many times arbitrary and one valid approach rarely is any better than another.

Coding standards: pick anything and stick with it. Use Google's. Why not? (Haha I note they are using svn.)

http://google-styleguide.googl...
https://google-styleguide.goog...

These types of decisions are many times arbitrary and one valid approach rarely is any better than another.

I would like to mention my pet project, IOVAR, hosted on Google Code. One of its goals is to aid in rapid development/prototyping as it bring shell scripting concepts to the web. IOVAR is currently in a usable state but lacks a "getting started" guide so I won't yet call it a beta release. I've licensed it with MIT license and would love some feedback or help!

Interesting page they link to on there: http://vimcolorschemetest.goog...

With ABP enabled, that soaks up 1.96G on my machine.
Without, it soaks up about 540M. That's impressive.

Not trying to flamebait here, but genuinely puzzled - what is possibly so great about the N900 versus something like a rooted Nexus 5? I see comments about cyanogenmod, etc. being a bit unstable - but comparing it to the N900, where very few people actually cared about building the OS ? The next version of the VM - ART - is nothing to sneeze at as well.
I'm not sure if you know, but when you install cyanogenmod (or one of the hundred different ROMS that people are actively developing on xda-developers), you get a Google free operating system. There is NO integration with Google. It is only if you install the "gapps" package, that you get the whole google shebang - play store, services, etc.
As a hacker friendly phone, I can develop on the N5 using Python, Golang, Scala, C#/Mono, QT, etc. - is there a usecase at which the N900 blows this out of the water ?
The only valid point I can think about is the keyboard - yes, it is a paradigm shift. But for daily use, smart keyboards like Swiftkey, Touchpal (pure open source) will serve you very well. For your developer needs, connect a monitor through HDMI/MHL and use a microusb adapter .
You have a first grade terminal emulator, IRC, low power bluetooth, built-in VPN + tethering - I would argue much more suitable for the developer than the venerable N900. Did I mention quad core processor, GPU and 2 GB of RAM with a brilliant display ?
If you want, you can install other OSes on the phone.

The great part about Java is that there are so many libraries for it.

http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/primitives/UnsignedInteger.html

I can't answer your specific question (I am mostly ignorant of PHP), but perhaps I can be of help with the broader issue of helping people learn about secure coding practices.

One of the basic principles of secure coding is to validate user input to ensure it is what you expect. If you are checking the image size and MIME type you are headed in the right direction. Whether you've gone sufficiently far, I'll leave to PHP experts.

To get started learning more, you can do worse than the OWASP Top 10 (PDF) -- skip to page 5 to bypass a thicket of jargon that may confuse you at first. Probably other readers can suggest other, gentler, starting points. I am suggesting the OWASP Top 10 because it's commonly cited and because it discusses how to prevent each of the major classes of application vulnerabilities. It's not perfect. It will take some time and thought for a newcomer to digest, but for me the effort was worth it.

You can also go to OWASP meetings if there is a chapter near you, or maybe find a local PHP user's group and ask about security.

The next step will be HTML6 that can be downloaded and can run offline like a normal application. Then someone will start build a web browser in HTML6, and try to sell it as something "new" and in the "cloud". That will be a HTML6 extension HTML7.

No really, WTF? Finally we reached the technology that any mobile phone can be faster then anything 20 years ego. But noooo, now we need to put everything on the web. So it will run 100x slower, tied to a browser, and if the Internet connection goes down, so go your data and your app.

Of course Apple, MS and Google are very happy of this development. So are Hollywood studios and music publishers. So they can exercise tight control over the apps and the content and Google can get all your stuff what you do on the computer/device and data mining it for ads.

I was /really/ impressed with WebGL. http://webglsamples.googlecode.com/hg/aquarium/aquarium.html
It runs with about 20 fps and uses up 15% of my CPU. I'm /really/ impressed. You know I can run the same demo with 400fps and 1% CPU usage? Yes it runs in the web browser, so what? Just let me download the app and I can run it too. With Java and JOGL you had the option 10 years ego. But whatever.

For SVG, you can use Sketsa (not free unfortunately), or for just minor stuff in a browser window: svg-edit.

Mr Buzzword doesnt know what he is talking about...

I'm glad you admit you don't know what you are talking about. I wish more people who didn't know would admit it right up front like you did.

The fact that the pointers use an extra 4 bytes is a negligible detail because the L1 caches are huge in relation to those 4 bytes. You would need a very large amount of pointers within the cache to have any sort of measurable effect, so large that following even small percentages of them (why are they in the caches if you arent using them?) will always cause significant L1 thrashing.

The fact that pointers (and anything dealing with size or offset) uses DOUBLE the size, and isn't negligible. It's effectively halving the size of the caches (total size, line size) in terms of the number of pointers/ints that they can contain.

But an even harder argument for you to try to refute is that Intel isnt stupid. The cache parameters (total size, line size, number of sets, for each level of cache) are optimized for 64-bit computing on their 64-bit processors. Intel didnt choose a 64 byte L1 line size willy-nilly. Intel didn't choose 32KB of L1 data willy-nilly. Intel didnt choose 8-way set associativity for their L1 willy-nilly.

I'm not going to refute that, nor is that directly related. However, as a side note that I don't want to get tied up in, I will point out that even Intel isn't flawless in their execution. For example, see their assumption about netburst being scalable to 10GHz and the fallout from that not being correct.

Now, after you spend a day figuring out what line sizes and set associativity are, and what impact they have, dont bother replying.. because by that point it will just be desperation on your part.

You assume too much, based on too little. You don't know me, yet you assume you know what I know. That's a pretty neat trick, and you would be wrong. Let me clarify. I've been performance tuning before you were likely born (based on the average age of the slashdot readers). I've written my own kernels, and I was even in talks with a major company to help them write theirs (Yes, you've definitely heard of them, in fact I'd be surprised if they weren't mentioned at least 10 times in this thread) as they copied/stole some of my concepts for an earlier release of their OS.

That said, I'll leave you world of misconceptions on hypothetical performance tuning and bring you into reality:
Firefox 32-bit ON MY MACHINE, scores 12784 on the V8 benchmark located here: http://v8.googlecode.com/svn/data/benchmarks/v7/run.html
Firefox 64-bit ON MY MACHINE, scores 9874 on the same V8 benchmark.

Obviously Lucy, you've got some 'spaining to do.

What is it with open-source leaders and their irrational hate of C++?

I don't think it's irrational. It's just for different reasons than many individuals may have.

It is perfectly possible for someone extremely competent in C++ to write code that someone else, with an equal level of knowledge and experience, can't make heads or tails of without some serious review time.

And then there's an additional problem that, because C++ is such a complex language, it's possible for people with more experience to write better code that people with less experience simply can't yet understand. And by less experience, I mean someone who understands the problem and the general solution, but only has 5 years of heavy C++ use. This problem of pure language complexity and a huge ramp-up time may not be unique to C++, but it's something C does not really suffer from.

I say this as someone who absolutely loves C++ and uses it daily. I love the complexity. I love to play around with templates to do some micro-optimization that I'd probably never put in live code. But I must say, the idea of being a maintainer -- reviewing and committing a diverse set of patches like Linus has to do -- for a C++ project sounds incredibly daunting for the reasons given above.

Often, this leads to atrocious usage guidelines that significantly hamper the flexibility and power of the language in an attempt to make it more accessible.

I've copied most of this from a reply I made to the Phoronix thread.

There's a lot of work involved in going from Apple's source releases to working cross compilers and then a lot more work involved in going from working cross compilers to well tested ones that generate the same binary code that the native versions generate (and allow things like code-signing) You can use my fork of toolchain4 to avoid this work if you want:

Binaries:
https://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Linux-120724.tar.xz
https://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Windows-120614.7z

Source:
https://github.com/mingwandroid/toolchain4

Using these you can build both iOS and OSX software using either gcc or llvmgcc on either Linux or Windows. You need to bring your own SDK of course. I've not yet looked into the feasibility of building Darwin libc or any of the other system libs (nor the legality of distributing these). I think there's definitely a gap for the OSX/iOS equivalent of MinGW-w64.

My build scripts and patches are a bit untidy, I'm currently engaged in an effort to merge this work into crosstool-ng which will force me to clean things up.

I've copied most of this from a reply I made to the Phoronix thread.

There's a lot of work involved in going from Apple's source releases to working cross compilers and then a lot more work involved in going from working cross compilers to well tested ones that generate the same binary code that the native versions generate (and allow things like code-signing) You can use my fork of toolchain4 to avoid this work if you want:

Binaries:
https://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Linux-120724.tar.xz
https://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Windows-120614.7z

Source:
https://github.com/mingwandroid/toolchain4

Using these you can build both iOS and OSX software using either gcc or llvmgcc on either Linux or Windows. You need to bring your own SDK of course. I've not yet looked into the feasibility of building Darwin libc or any of the other system libs (nor the legality of distributing these). I think there's definitely a gap for the OSX/iOS equivalent of MinGW-w64.

My build scripts and patches are a bit untidy, I'm currently engaged in an effort to merge this work into crosstool-ng which will force me to clean things up.

$ apt-cache search google authenticator
libpam-google-authenticator - Two-step verification

It's in Debian repositories (And probably Ubuntu.) You can download it yourself and integrate it into anything that supports PAM.

I have my code on both my phone and iPod touch so I always have something on me that can generate the code. The 'backup codes' are in a safety deposit box with other documents. Not sure if it actually is secure but it feels a bit more secure knowing that to get into my home server you have to have both my password and one of my devices. (And if I lose one I can easily generate a new key).

It makes a QR-code in the bash terminal that you can take a picture of with your devices.

I tried Chromium. There is a problem: I've become addicted to tree-style tabs, courtesy of the Firefox extension.

Chromium/Chrome had this feature natively for a long time, until the developers disabled it in a sneaky-Pete maneuver that pissed off a bunch of people.

The obvious response, to write a Chromium extension for Tree-Style Tabs, is not an option. The Chromium plugin API does not expose the functionality necessary to do so.

Webkit (Chromium/Chrome's layout engine) seems to be a little faster than Gecko (Firefox's equivalent), but I would prefer to use a browser that gives the user (ME!) control over it, even at the cost of some rendering speed.

The time I would gain in rendering efficiency would probably be lost trying to scan this, as opposed to this.

Classes Classes are the fundamental unit of code in C++. Naturally, we use them extensively. This section lists the main dos and don'ts you should follow when writing a class.

Doing Work in Constructors In general, constructors should merely set member variables to their initial values. Any complex initialization should go in an explicit Init() method.

Default Constructors You must define a default constructor if your class defines member variables and has no other constructors. Otherwise the compiler will do it for you, badly.

Explicit Constructors Use the C++ keyword explicit for constructors with one argument.

Copy Constructors Provide a copy constructor and assignment operator only when necessary. Otherwise, disable them with DISALLOW_COPY_AND_ASSIGN.

Structs vs. Classes Use a struct only for passive objects that carry data; everything else is a class.

Inheritance Composition is often more appropriate than inheritance. When using inheritance, make it public.

Multiple Inheritance Only very rarely is multiple implementation inheritance actually useful. We allow multiple inheritance only when at most one of the base classes has an implementation; all other base classes must be pure interface classes tagged with the Interface suffix.

Interfaces Classes that satisfy certain conditions are allowed, but not required, to end with an Interface suffix.

Operator Overloading Do not overload operators except in rare, special circumstances.

I am particularly struck by the depreciation of inheritance and the promotion of composition (has a rather ithen is a). This is a design decision I very much indorse, and I have done so over the course of many years. It has caused me trouble, because C++ code geeks think that if you are not using inheritance, you are doing a bad job. They're wrong. I know that I even was not hired on a couple of occasions because I expressed this opinion. I was very pleased when I saw that Google uses the same strategy.

I always through most of the patterns in the Design Patterns book could have been better described as 'Workarounds for language(or library) limitations'

As a good example of this in practice, see how Guava's EventBus replaces a huge chunk of the Publish-Subscribe pattern.

A similar written guide was produces for Yet Another Perl Conference organisers. It's here

Normally, I'd say that the parent was being unhelpful, but in this case with the the Scripting Layer 4 Android (SL4A) already having done most of the work for you, it would actually pretty easy to do this. Here are the beginning of their instructions:

Introduction
Part of the SL4A project is to define an API for others to develop new interpreters that SL4A (or any other compatible project) can support. Currently, this standard is for interpreters that can be run as a binary in a separate process. This standard will be extended in the future to also support running JVM based interpreters in process.

The Easy Way is a step-by-step description of how to build an interpreter APK that is compatible with SL4A.
The Way of Samurai describes how to use the interpreter.jar in your own project to interface with SL4A.
The Way of Zen describes the API in detail.

[...]

And yes, I'm aware that the original question mentions SL4A, but says that that it doesn't provide "exhaustive" access to the platform, which triggers the question for me, what access does he want? Just tell me one thing that he wants (please not a fully shopping list), just have him pick one item, and I'll show him how he can add it to the the Scripting Layer for Android himself.

And yes, I do realize that's really not the original question that he was asking, and to that, I'd reply that not everyone in life always get what they want. "Basic" may be at the center of his Universe right now, but it's certainly not the de facto language for everyone these days and it would be presumptuous for him to think that his opinion should override everyone else's opinion on the matter. And it would also be presumptuous to think that a big faceless corporation, with so many developers and so many resources, should cater to *his* every individual needs all because it would be so simple and so easy to do for them. I'm afraid that's not how corporations work. Corporations usually have their own agendas and their own whims to cater to.

NaCl is not portable. NaCl apps only run on x86 and x86_64, not ARM or PowerPC or anything else.

Which is why there is PNaCl

Which is an interesting research project, but it's too early to say if it will achieve the goals of complete portability and full performance.

NaCl is not portable. NaCl apps only run on x86 and x86_64, not ARM or PowerPC or anything else.

Which is why there is PNaCl

It's becoming obvious that browsers need to support a runtime like LLVM in addition to or instead of javascript. That way, the developer could use their language of choice and just compile to LLVM byte code instead of to javascript

Yes. It is.

Agreed, though progress is being made. Both Mozilla and Google have submitted proposals to the W3C, and already have some support in their browsers. Firefox uses the Audio Data API, and Chrome the Web Audio API. Obviously it'll be a while before one gets standardized (given the W3's track record, could be a very long time) and support becomes universal across browsers, but it's a start.

1-Perception of speed is more important than a synthetic benchmark number....

What!? You mean that "Classic Scheme benchmarks, translated to JavaScript by Florian Loitsch's Scheme2Js compiler" don't capture the use cases of modern websites?

http://www.dd-wrt.com/wiki/index.php/Noob-Friendly_Customized_install.sh_for_compiling_from_source

http://www.dd-wrt.com/wiki/index.php/Building_From_Source#Building_DD-WRT_From_Source

http://firmware-mod-kit.googlecode.com/svn/trunk/ firmware-mod-kit-read-only

svn://svn.dd-wrt.com/DD-WRT

What's the problem? It seems it is not as easy as "emerge dd-wrt", but it seems they have all or most of the stuff there.

Even better: update your adblock plus lists to include the URL

https://adversity.googlecode.com/hg/Antisocial.txt

This list will block (or attempt to block) all third-party "Social" sites' widgets on pages not owned by the parties themselves. To install, find the add new subscription field fo AdBlock plus and paste in the URL above. Details for Chrome (but work for AdBlock plus in any browser) here:

http://techpp.com/2011/06/16/how-to-disable-facebook-like-buttons-in-chrome/

There's an updated UnxUtils on googlecode.

Google APIs generally use Authsub (A google invented protocol), or the combination of OpenId and OpenAuth, possibly using the Hybrid Protocol,

Thankfully to the jailbreak community the author is still making the app available. similar to how apps removed/deleted from apple app store can by got via cydia, and those removed from cydia can be got from installous. same goes for this app, it's moved to the jailbreak community and you can also download a copy off demonoid/kat.ph to install if you really want it. also you can pick up the source code and install it yourself http://moonblink.googlecode.com/svn/trunk/

svn checkout http://moonblink.googlecode.com/svn/trunk/ moonblink

This command will clone the svn repository into a new git repository, preserving history.

Warning: It will take a few minutes. Also, if your slashdot preferences add "[googlecode.com]" to the url, remove it.

git svn clone -s http://moonblink.googlecode.com/svn/ moonblink-read-only

It's available on google code still. It's a little bit of a pain to build...I had to combine the HermitAndroid and HermitLibrary src into the Tricorder project, and then delete said libraries. (but I build with CLI, eclipse may end up being easy peasy) svn checkout http://moonblink.googlecode.com/svn/trunk moonblink-read-only As I'm not an anonymous coward, if I distributed the APK, would the DMCA trolls smash my head open?

The supposed password, as it appears on page 148 of the pdf version of the book, is ACollectionOfDiplomaticHistorySince_1966_ToThe_PresentDay#

Supposedly applies to "cables.csv" but not to the insurance.aes torrent released last year by Wikileaks.

Here you go. Relevant piece:

In general, constructors should merely set member variables to their initial values. Any complex initialization should go in an explicit Init() method.

Yes, let's not do our work in the constructor, let's make it so that the user has to know to call an Init() method to not get an object in a bad state. So basically they have some really lame justifications for this and yet all this does is make the code more error prone since you have to know to call an extra method just to get your object constructed properly which is fucking dumb.

I have Sprint, they've never given me a problem about tethering. As far as I can tell, there's no data cap on my unlimited plan (2 Epic 4G phones, $150 /mo unlimited everything family with the 4G premium, both phones are rooted and running Froyo 2.6.32.9).

My wife is a heavy media consumer with Pandora and Netflix. Occasionally my AT&T home internet goes out, and I stay online for work and play by using Wired Tether (http://android-wired-tether.googlecode.com/) because my desktop doesn't have 802.11. I frequently use the Wireless Tether (http://android-wifi-tether.googlecode.com/) when I'm out and about with my laptop, as my "4G" (San Francisco bay area) is generally faster than free WiFi and I don't have to deal with a gateway.

All told, it's rare for us to be under 4 gigs per month, and I haven't received any communication from Sprint other than the occasional text advertisement and our monthly statement, but YMMV.

I have Sprint, they've never given me a problem about tethering. As far as I can tell, there's no data cap on my unlimited plan (2 Epic 4G phones, $150 /mo unlimited everything family with the 4G premium, both phones are rooted and running Froyo 2.6.32.9).

My wife is a heavy media consumer with Pandora and Netflix. Occasionally my AT&T home internet goes out, and I stay online for work and play by using Wired Tether (http://android-wired-tether.googlecode.com/) because my desktop doesn't have 802.11. I frequently use the Wireless Tether (http://android-wifi-tether.googlecode.com/) when I'm out and about with my laptop, as my "4G" (San Francisco bay area) is generally faster than free WiFi and I don't have to deal with a gateway.

All told, it's rare for us to be under 4 gigs per month, and I haven't received any communication from Sprint other than the occasional text advertisement and our monthly statement, but YMMV.

It wouldn't be difficult for Google to add it to Google Talk (unobtrusively, turned off by default)...

It works on Google Talk's network already via third party software. Thus, no XMPP server modifications needed.

An example is RealJabber experimental demo chat software whose source code I posted at http://realjabber.googlecode.com/ ... I tested XEP-0301 real-time over google's XMPP severs (gmail.com / talk.L.google.com) ... Google was able to handle up to more than 10 XMPP messages per second very easily, but XEP-0301 limits it to a recommended setting of just 1 XMPP message per second maximum, to be gentle on the network. (In fact, that's probably comparable to text-happy kids who say "Hi" "wassup" "u?" and type those messages once a second before transmitting them -- ha ha -- annoying to our group, but the XMPP network clearly can handle a protocol that requires a once-a-second message rate.)

I am working with several parties that are creating clients for Android as well as in AJAX/JavaScript (Linux/Android/iPad compatible). To prevent annoying users, Google could keep it turned off by default, but just an on/off menu item or button. Turning on/off real-time text like turning on/off audio or video. (It shouldn't be annoying as Google Wave that way, yet provide an important service for deaf people like me, and for people who *do* feel like turning on the feature -- even 1% or 10% is still a lot of people).

In fact, some existing chat software sometimes have real time text already (AOL AIM's "Real Time IM" -- a feature that is turned off by default and is a feature usually not discovered by most non-deaf people. Unfortunately, it is proprietary, unlike the open XEP-0301 protocol that anyone can use over Jabber/XMPP.)

P.S. You can't believe how some of us deafies are stuck with older technologies. For example, our text telephones (TDD / TTY) run at 45 baud! (Yes. 45. that's slower than 300 baud -- don't believe me? -- see http://en.wikipedia.org/wiki/TDD/TTY ..)

The WebGL is buggy and most of Mozilla's demo's wont run and the aquarium webGL experiment does not render properly.

I downgraded back to Firefox 4.01 and the problems went away. I have an ATI 5750 with the latest drivers under Windows 7.

The good news is Microsoft's IE fishtank demo topped 60 fps just like IE 9 with DirectWrite enabled. I am going to wait until 5.01 before I upgrade.

Microsoft supports CSS 3D instead. Seriously Microsoft is right about security flaws in OpenCL and WebGL as skeptical as I am.

I read stories here on slashdot with computer scientist publishing articles saying how bad OpenCL is from a security stand point. No user priveldges at all in using the GPU.

If only drivers did not contain scripts, trusted, and untrusted code in a demonic bastion could we trust them. Check this out, when a null hits a texture load api? A simple Javascript could root the system easily using webGL and read your ram just like that example above printed out the contents of the users VRam as a texture.

Another example of hardware acceleration with security gone wrong is flash. It seems the new flaws of security are graphics related. We need a new graphics API, frankly Intel, Nvidia, and ATI have shitty and horrible drivers no matter what the platform is. Even my ATI 5750 can not render the stupid aquarium right with Firefox 4 in Windows 7. I admit I am not a hardware expert but it seems the driver model in itself is flawed.