HN user

withjive

238 karma

Database software engineer from Canada Clickhouse & Postgres <3

Posts0
Comments53
View on HN
No posts found.

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...

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

I love ARM 6 years ago

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.

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 :))

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?

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.

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.

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.