dom0

Suggestion: "Tech firm fighting federal order for data on visitors to an anti-Trump website"

Or "Tech firm fighting federal order for visitor's data of anti-Trump website"

v "Tech firm fights federal order for visitor's data of anti-Trump website" — can't even gzip it!

It is possible to do more after a fork (cf. async-signal-safe), but it's hairy enough to just say — don't, always exec (similar to how doing actual work in a signal handler is generally a very bad idea).

With Python that's a lot of stuff; I suggest running strace python some_small_script.py to see just how much data Python loads on every single startup.

Things that happen when you employ folks full-time to work on something.

Considering who funds a lot of FS development on Linux, this isn't that surprising — using O_DIRECT is really really complex and also not in the kernel, so a neat-o way to keep others from doing the same.

There are no QA processes per se for all file systems. The kernel is pretty much a bundling of many projects and the big file systems are their own projects, managed largely indepently from the Linux masters.

Differing 64 bit data models don't really matter when software depending on exact widths uses exact width types. Unfortunately, on MSVC this hasn't been supported for many years out of the box, so each project had to include its own stdint.h replacement one way or another to do this.

You're both wrong.

P is the union of all TIME complexity classes defined by n^k for every natural k.

NP is the union of all NTIME complexity classes defined by n^k for every natural k.

NP completeness kinda works around the uncertainty of PxNP (with x ∈ {⊆, ⊊}), because it defines some sort of "weak subset" of NP comprised of "pretty sure these problems are not in P[, because no one yet thought of a polynomial reduction to a problem in P]". The last part in brackets is the catch here; if we could show that it is not possible, then P!=NP would immediately follow, and NP completeness would become a largely pointless exercise.

There are a bunch of major assumptions which are not rigorously proven, but generally assumed (hence assumption) to be correct, frequently backed up by a large body of heuristic evidence.

P!=NP is one of them.

> breaking

This preprint "implies P not equal NP".

> There are a lot of people in that boat, and they need better options.

Land isn't coming to you, folks, you must start rowing if you want to get there.

Rewrite bit for bit. Module for module. Package for package.

No, it must be explicitly released. The GIL must be held to invoke almost all Python runtimes (main exceptions: acquiring the GIL, low-level allocator).

Depending on where you want to go and the application, such things may be good idea for a low number of workers but can become a major bottleneck.

Just like you can share memory between processes, you can also share OS-level locks and semaphores between them. A distributed lock manager is not required for the single-node case.

Unless your model actually consists of a large number of Python objects (and not a handful of PyObjects referencing something like a np array), there isn't really anything blocking you from doing so. You can have a master process map the blob of static data into a block of shared memory that's mapped by the secondary processes; ctypeslib lets you access it as a numpy array again.

Removing the GIL (in a non-braindead way) likely entails breaking all existing code using the C API. PyPy could do so without breaking cpyext, by maintaining the illusion of a GIL whenever control passes to cpyext.

> (see Amdahl's law)

Amdahl's law bears little relevance to throughput computing (i.e. most servers).

> (It's also buggy, has internal race conditions, and easily leaks resources.)

There is also at least one memory corruption bug in multiprocessing (linked a few months back by a fellow HN reader).

> It's just an implementation detail of the underlying VM.

Python itself is just an implementation detail of the underlying VM.

The most general layer in Linux (VFS) doesn't really support asynchronicity, so changing this would require a bunch of changes to every tree and out-of-tree FS - not viable. However, the usual suspects (ext, xfs) actually use a bunch of other APIs as well, where the FS itself is often not involved in simple stuff like a read(2). This theoretically would allow async IO on files in many cases; I believe there is ongoing work in this direction, though. For now, only raw / O_DIRECT is async.

Cease your investigation

No, this is about the EM field. The magnetic field of CRTs is very weak (so weak that it is dwarfed by nearby rail power lines which have a rather weak M field as well; so weak that you have to recalibrate for monitor movement relative to earth's M field).

I doubt this works, at all, for a variety of reasons.

Is such a thing even possible?

The way things turned out the work from this era defined what computers can and can't do, not the other way around, which would likely not satisfy many mathematicians.

> The GIF method is probably constantly leaking memory.

If the browser only keeps compressed frames, 16 GB will last for more than a year.

Interesting. Firefox' developer console does not understand this kind of request properly and shows its termination after the first frame. Chromium on the other hand handles it correctly.

Google and Facebook are bigger than a single country now.

Never saw /cgi-bin/ in a form URL? Or the occasional xycorp_isapi.dll? :)

> it's procedural (like C and Fortran)

Wait... do you actually believe that? Tons of C software is OO through and through, has been since C existed.