withjive
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.
I am curious though, as to where you got such a strong notion that shadows can move faster than light...
Cold weld it in space, it's not that difficult with some engineering.
Space X?
Would the logical next step, use GPT-3 to create a 3D world? :)
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
Xcode/iOS's emulator is actually x86 - which is why it seems faster than Android's default emulator.
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.
Previously I would just put my pet projects on Bitbucket because they offered free private repos.
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.
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 :))
So the getComputedStyle() trick doesn't work anymore. Is that what your referring to?
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!
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?
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!
I don't think this is anything more than a toy to play with rust.
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.
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.
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.
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.
Do they rely on your own provided Total Value or if the stranger/host is responsible for opening your package and inspecting it...
> 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.
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.
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.