My theory is that there was a flash fire that pretty much instantly went from "Do you smell smoke" to "Ahhh my face is melting" then one of the brave pilots managed to dial in a rough turn to home into the autopilot before either fleeing the cockpit or dying. Then the plane filled with toxic smoke and sailed along with a dead bunch of occupants until it ran out of fuel. The autopilot then greased a perfect landing in the ocean keeping the plane largely intact where it slid peacefully to the sea floor.

This would explain the oddities, the lack of contact, the rough homeward direction, and its eventual destination.

I don't buy the suicide part because the pilots would assume that the plane would be found. Whereas they could simply screw up the landing and that would make them look stupid but not necessarily suicidal.

And the whole bit about him practising weird things with a flight simulator that is what most people do with flight simulators. A pilot would be the last person on earth do do something normal with a flight simulator. So either he is going to practice edge cases as a skill building exercise or he is going to slalom a 747 through a huge city because that is fun.

My personal bet is that the first bit of debris will show up in New Zealand and this will allow searchers to backtrack the currents to its actual destination.

What this all screams to me is that planes should be sending a regular report up to the satellites. It could even be an efficient system where the satellites don't even bother transmitting it back to earth unless requested. Or they could transmit a summary such as transponder, altitude, direction, speed, fuel, and maybe a vague summary of the system health back to earth and leave the details available upon request only.

Here is the kernel commit message:

seccomp: implement SECCOMP_FILTER_FLAG_TSYNC
Applying restrictive seccomp filter programs to large or diverse
codebases often requires handling threads which may be started early in
the process lifetime (e.g., by code that is linked in). While it is
possible to apply permissive programs prior to process start up, it is
difficult to further restrict the kernel ABI to those threads after that
point.

This change adds a new seccomp syscall flag to SECCOMP_SET_MODE_FILTER for
synchronizing thread group seccomp filters at filter installation time.

When calling seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC,
filter) an attempt will be made to synchronize all threads in current's
threadgroup to its new seccomp filter program. This is possible iff all
threads are using a filter that is an ancestor to the filter current is
attempting to synchronize to. NULL filters (where the task is running as
SECCOMP_MODE_NONE) are also treated as ancestors allowing threads to be
transitioned into SECCOMP_MODE_FILTER. If prctrl(PR_SET_NO_NEW_PRIVS, ...) has been set on the calling thread, no_new_privs will be set for
all synchronized threads too. On success, 0 is returned. On failure,
the pid of one of the failing threads will be returned and no filters
will have been applied.

The race conditions against another thread are:
- requesting TSYNC (already handled by sighand lock)
- performing a clone (already handled by sighand lock)
- changing its filter (already handled by sighand lock)
- calling exec (handled by cred_guard_mutex)
The clone case is assisted by the fact that new threads will have their
seccomp state duplicated from their parent before appearing on the tasklist.

Holding cred_guard_mutex means that seccomp filters cannot be assigned
while in the middle of another thread's exec (potentially bypassing
no_new_privs or similar). The call to de_thread() may kill threads waiting
for the mutex.

Changes across threads to the filter pointer includes a barrier.

https://git.kernel.org/cgit/li...

This whole attempt at automation is trying to replicate a system designed for humans. But other options could make things easier for robots.

• For instance putting something like an RFID tag on clothing so that the robot doesn't have to do a complicated visual assessment of the clothing.
• Most washing machines are also very much designed for humans. But a washing machine that was altered for robotic use would be far better.
• For instance a machine that dumped the clothing out when it was done would be better than a machine where a machine has to reach in and pluck stuff out;
• as would a unified washer/dryer.
• Also the set up of a typical laundry room would be again poor. So to have the machine dump the clothing out onto a rimmed metal surface where the robot could pick things out (remember the rfid tags).
• And folding the clothing would be more based on the clothing itself. The manufacturer could identify the optimal folding pattern (from the rfid tag) that the robot would use.
• Then there are steps like ironing where again a robot wielding a traditional iron would be stupid. But one of those roller press things would be great.

It would be like having a self driving car actually have hands and feet that can operate the steering wheel, tickers, gearshift etc while using eyes mounted on its head inside the car.

To me there are two kinds of elite. The classic one that generally serves only the rich elites is a university that is very hard to get into.

But the second kind would be one where they teach hard things to high levels and thus it is hard to graduate from. With an online scenario it could be possible to let pretty much everyone in and let the actual courses be the filter.

That said, I have a nephew who recently graduated from a third rate university's engineering program. Basically they taught them shit but worked them to the bone. If you didn't have a fantastic work ethic and discipline then you may very well not complete the course. But the engineering skills learned would be borderline useless.

So what I would love with an online truly elite university would be basically opensource courses. That is all the materials, videos, tests, etc would be published. This way they would have trouble concealing the fact that their course sucked.

She messaged me in fear from some article that said the new uTorrent would set her motherboard on fire. She probably doesn't know what a motherboard even is. I can't wait to see the stats on uTorrent market share over the next month or two.

There must be an economics term for when a good product gets more and more exploited by the MBAs who take over until they haven't just damaged the reputation of the product but basically lynched their own brand.

For instance I am certain that if it weren't illegal that Air Canada would use their employees and probably their passengers for fuel. Only regulators have generally kept the MBAs that run that company from setting itself on fire.

I don't think Docker is aimed at the enterprise, it's aimed at making it easier to deploy applications.

Let's take a really complicated cloud application,.... the OpenStack services.

Docker can used to deploy Openstack in 3 min.:

https://www.youtube.com/watch?...

I watched a news magazine show where they were able to meet up with Nigerian "my uncle the king needs you to transfer $200 million" scammers. They had little trouble meeting them in Montreal Canada.

They went to the authorities and asked them why they didn't pursue these sorts of things and they blah blah'd about getting cooperation in Nigeria. The reality is that many of the contacts are with Nigerians in places like Canada and the UK.

The reality was that too hard actually translated into "not easy enough"

"The issue is that security features are hampering performance"

This is not always true (especially in this case).

OCSP stapeling is faster than normal OCSP.

(as a side note SPDY or HTTP/2 only works with HTTPS/TLS in practice and is faster than HTTP and in many cases faster than HTTPS. Obviously TLS and even TCP on the server need to be properly configured for that as they a large number of optimizations which might not be enabled by default: https://istlsfastyet.com/ )

The summary and many commenters here are also wrong/confused about what is going on.

OCSP is a protocol to ask the CA over HTTP the status of a certificate. The CA then creates a OCSP-response which is timestamped and signed by the CA.

Every time you visit a HTTPS-website and the browser hasn't done a recent check of the OCSP-status it will ask the CA for such a status. It will ask if the certificate the webserver uses is still valid.

This means extra TCP-connections, extra DNS-lookups, extra HTTP-request, time at the CA to create that response. And even some loss of privacy (the CA and any network between you and the CA obviously now can see the site you are visiting !). This also means the CA get a lot of requests to handle and the CA is becomes a single point of failure. Vulnerable to DOS-attacks

The solution to this problem is to have the webserver request an OCSP-response from the CA at a certain interval.

Now when your browser connects to the website the webserver can include the timestamped OCSP-response in the negotiation protocol. Thus the browser doesn't need to contact the CA itself.

Thus if all webservers do this, the CA will not only not be a single point of failure any more, but also not have to create that many OCSP-responses speeding up that operation for any remaining sites.

Now why do Firefox and Chrome include an extra blacklist ?

This is because pretty much every CA included in the browser uses 'intermediate certificates'.

Thus a certificate chain looks like this:

- CA-root-certificate
- intermediate certificate
- website-certificate

The browser includes a copy of only the root certificate.

It doesn't know which intermediate certificates are valid. It needs to do a seperate OCSP-request for that.

And OCSP-stapling protocol sort of has an unfortunate 'flaw', it can only include a single OCSP-response when setting up a TLS-connection.

So what do the browser vendors do:
- include the root-certiciate
- include a automatically updating blacklist of revoked intermediate certificates
- support OCSP-stapling so they know that website-certificate is still valid.

Now you know why this is done.

And now to get back to the performance: OCSP-stapling is faster than contacting the CA directly and including a blacklist of revoked intermediate certificates is also faster than contacting a CA directly.

All they need to do is to pay the scammers with a CC and watch where the money goes. Then go knock some heads.

As they say, follow the money.

Actually I hate how many people beat the crap out of templates. I love the cleaner implementations of templates when used for things like vectors but I was looking at this guy's code and he was using templates in some obtuse way to literally initialize integers. I forget how he did it but he made "int x=5;" very very complicated.

The other thing that I see people doing is the nightmare of "future proofing" their software with templates. They will write functions that only take a single input type and return a single output type and use templates so as to make this generic. Except that this isn't some API situation but just a function that will probably never ever ever ever be expanded.

I lump these people in with those who will comment like this:

// This function will get the user's ID from their username
// Takes one parameter username which is the user's username
// Returns one integer representing the user's ID.
// Returns zero if the username is not found
// CREATED BY: Unknown [IP:123.123.123.123] on Jan 1, 1970
// MODIFIED BY: Unknown [IP:123.123.123.123] on Jan 1, 1970
// MODIFIED BY: Unknown [IP:123.123.123.123] on Jan 1, 1970
// MODIFIED BY: Unknown [IP:123.123.123.123] on Jan 1, 1970
// MODIFIED BY: Unknown [IP:123.123.123.123] on Jan 1, 1970
int GetUserIDFromUserName(string username)
{
//Set the user_id to its default value
int user_id=0;
.... some kind of username lookup ...
//When complete return the user's id if any matches found. Otherwise return -1
return user_id;
}
Now these same pedantic asshats are doing the above function using templates just in case the user ID become boolean or something or the username becomes a float.

Basically some asshat at NeXT chose Objective-C and that has sort of percolated through Apple. Originally the only way to do iOS apps was Objective-C; so I learned Objective-C. I hated every minute of it. All those damned, [][]][[. The moment I found an environment where I could go back to C++ I was gone.

So if you have to make an iOS app and you must use the iOS SDK then I guess you should learn objective-c. But under any other circumstances learn C++.

One other bit; I looked at godot and I would suggest that you just jump in with cocos2dx. It is great if you are 100% 2D. What I am looking at doing is what some call 2.5D and this is where I am having the most problems with cocos2dx.

Already a few disappointments. One is that the installed app is around 250Mb for what is effectively hello world. Also the whole environment is slow as molasses and I have a mac pro 2013. On the good side I think that I could develop just about anything that popped into my head. I am a bit worried about this being one of those silver bullets where the normal parts are developed so quickly that the project is seemingly 90% done in no time but the fiddly bits then take 10x as long. One other thing is that I like to release my iOS apps going back to iOS 5.1.1

I love cocos2dx but I am starting to balk at the 2d part. They are introducing 3D so that is good. The documentation for cocos2d is sparse. The executables are small and the startup delay isn't too bad. It is 64 bit for IOS (critical). Very multi-platform (Win, Mac, iOS, Android, Linux, and I think mobile windows). Their release schedule is very fast. Also the C++ is pretty close to the bone which means that the project sort of marches forward at a steady pace including the fiddly bits.

I recently played with Gameplay3d and was actually quite impressed. Very simple and it just sort of works. The only huge thing was that importing assets in from something like Maya was cumbersome and sort of sucked. The documentation is nearly nonexistent (documentation with useful examples) their sample code was trying to show off how they were such efficient coders and didn't separate out each bit of functionality.

The platform that attracts me the most is Openframeworks. Except that they don't yet do 64 bit on iOS which is a show stopper. They are promising this with their 0.9.0 release.

But I might have spoken too soon. I am going to continue now with cocos2d and probably deploy version 1 of my present project in that. But I am going to spend an hour an evening seeing how hard I can push Unreal.

What worries me is that with Unreal I might alter my game to fit their environment which might make for a very beautiful game that isn't much fun instead of the ugly game that I make that is fun.

Ah, but then it will just reappear. You have to go to some other spot and delete the album from your account. If I understand correctly Apple put out a U2 removal tool; like it was a virus or something.

Thanks epic. I literally just started re-coding my game from Cocos2d to Unreal. My only regret is not doing this sooner; once I saw how well this worked with mac and the clean C++ just wow.