withjive

CIA & Pablo. Exactly.

Yes that is a great of example of reading something on the internet and believing it completely?

You just linked me to a Stackoverflow post about a theory, which turns out to just be completely wrong, while managing to include a few valid facts.

Was a fun exercise, but please don't get your science this way.

Sorry, "apparently" shadows do not move faster than light. Since they are... well... defined by light...

I am curious though, as to where you got such a strong notion that shadows can move faster than light...

From my perspective of American warfare - shooting a $1 million dollar missile at every $100 drone is how they keep the war going :)

You're being down voted because in this case customers are obviously the product. Being sold to Facebook.

Seems quite short sighted to assume space manufacturing processes would not improve - or we would not want to improve them.

Cold weld it in space, it's not that difficult with some engineering.

Space X?

For small range (few km) you can just utilise LoraWAN for free communication.

Similar to how GPT-3 can be applied not only to create Text, but also fill in missing pieces of Images (ie. complete the missing half of a face).

Would the logical next step, use GPT-3 to create a 3D world? :)

It's actually quite easy to strip the DRM on Audible using ffmpeg - which I do to keep an archive of all my purchases.

There's a script on github to get the encryption key for your account by letting it sign in for you.

Then from there it's easy to get ffmpeg to turn the DRM aac to a mp3

If your doing Android Development with the ARM emulator, then its crazy slow. However, if you use the x86 emulator - then you get native speed.

Xcode/iOS's emulator is actually x86 - which is why it seems faster than Android's default emulator.

They go over the effects of compression - which they say only degrades the protection - but at the same time also degrades the identification accuracy of the AI model.

So if your crappy 6 megapixel camera cannot take a clear shot of the cloaked pixels - or effectively applying a blur filter - would also affect the AI detection.

They are lucky in this case because compression does defeat the cloak to some degree— However, compression at those levels also defeats the ability of Facebook to accurate identify you.

What's wrong with personal projects on a Free private Github repo? (they offer those now).

Previously I would just put my pet projects on Bitbucket because they offered free private repos.

As an Android developer during the first G1 era, I feel that Google was really taking advantage of the well established Java developer base.

Having developers already understand Java, was a huge thing for Android when it first came out.

So when you say:

> Wendy’s doesn’t ever use “supersize” in their promotions

IANAL, So I’m not sure Google didn’t do the same...

I also think Oracle is also not happy with that.

This would be for the QtQuick backend.

The QTWebView is a separate plugin component with its own set of dependencies.

You wouldn't want to do that anyways, much more effecient to just communicate from Qt to Javascript webviews (but I'm sure you know that :))

Newer versions (since around 2013) of webkit and gecko limit a:visited style changes to just colour or background colour.

So the getComputedStyle() trick doesn't work anymore. Is that what your referring to?

Very interesting! Great timing for myself, as I just pulled the Chez github repo just last night— a whopping 900mb btw!

Chez became a point of interest to me after learning about it's solid performance (can even do whole program optimisation and across library boundaries).

I wonder how feasible it would be to build a Chez target for Clojure?

Most recently it has been open sourced under a GNU license by cisco, and is even on Github.

Looks like good times for Chez and Scheme!

A few years back the Graal compiler from Oracle caught my attention as it was able to accelerate ruby code on the JVM with incredible results.

However it was not able to support any real world code / frameworks— ie. Rails. (At the time I even downloaded the compiler myself, but it was quite experimental)

Are we any closer to achieving that yet?

I've been a pretty big fan of CMUS and CLI based based audio playback for a long time..

This is absolutely amazing— much more polished than the alternatives—it feels like christmas.

Now I can't wait to contribute a pull request :) Thank you so much!

The fact that there is a "Won't do list" stating that functions won't be supported...

I don't think this is anything more than a toy to play with rust.

While the DOM may always be slow, faster JS (ie. wasm) can provide faster calculations in pure javascript land and better efficiency (better memory management, similar to c++/native stacks).

This is useful for optimizing DOM usage, such as using a virtual dom to avoid excessive real DOM access.

So while it does not attack the bottle necks directly, it will increase the overal perceivable performance of a webapp.

What you said is true, however...

I am referring to the initial offering of Native Client for inclusion into FireFox.

Since this did not happen, Native client did not see the uptake it needed— and the team was destaffed.

Since it was a working platform that actually existed and let you use a modified version of LLVM, it was quite usable.

We could of have powerful native sandboxed apps quite a long time ago if FireFox became PNaCl compatible.

Instead, Mozilla envisioned that the JIT could eventually bridge the native performance gap.

Mozilla defended this ideas such as ASM and emscripten. And now Mozilla is coming close to a more open and performant web.

Project Mortar is different in the fact that it is PDFium and Adobe Flash being allowed via Pepper API — basically it's for sandboxing those current native plugins. This would not be a public web use case.

PNaCl vs WebAssembly was all about letting everybody run sandboxed native code in the browser without any extensions or prompts.

Native Client (the portable version known as PNaCl) was an open source project by google to achieve native performance with sandbox security.

Mozilla wanted a more open web which led to Web Assembly.

Looks like Mozilla won this fight. When Mozilla didn't accept PNaCl and Pepper API proposed by Google, Mozilla went down the ASM path which now led us to Web Assembly being the general way forward.

> The reason GLSL isn't C is because you can't do everything C does on a low end cellphone GPU - so obviously you have to restrict the language.

GLSL limitations has nothing to do with lowend devices and performance (which now is becoming irrelevant compared to desktops).

But rather GLSL is executed on the GPU— typically across many stream processors— this type of parallelization makes using a general purpose language like C difficult.

I think you need to familiar yourself with some shader programming at least, before you critique the author's domain.

Will be interesting to see how they handle duty & customs.

Do they rely on your own provided Total Value or if the stranger/host is responsible for opening your package and inspecting it...

From the article.

> While we're waiting for the papers to be published, we need to be skeptical about the two claims. But the fact that two separate teams have used the same blueprint to make time crystals out of vastly different systems is promising.

ReactNative uses Yoga for it's layout. There's an OSX port already in progress, so cross platform Desktop apps using Yoga isn't that far off ;)

When working with Docker, it is possible to get down to the metal as you mentioned.

Usually by bypassing the docker networking and using Host only network, but then you lose a lot of the benefits of containers in the first place.

For example, weave or calico networking layer on top— which add a fair bit of latency if your aiming for 10M connections— makes scaling containers quite easy

I would imagine that if you plan on using Docker in your infrastructure seriously, you are aiming for a multi host setup with many containers spread throughout— and can settle for 100k connections per container easily.

Indeed, it will be interesting to see what Google can think up compared to the other big researchers.

Though I wonder if the goals are slightly different, as Google is focusing on "Cloud Storage", rather than single hard performance.

Which as they mentioned, the Cloud doesn't need to have great reliability (since data is assumed to be already redundant), this may allow them to decrease the cost of hard drives for exchange in cheaper disks that may fail more.

Doesn't sound like they are expecting to increase size/performance alone with this effort.