evmar

It's not, I linked the patch. (I don't fully understand the patch so I'm happy to be corrected here, but it looks like it was an ordinary "use atomics incorrectly" bug.)

It's interesting, I read this and had the opposite conclusion -- people are still writing racy code using Rust.

I mean, it's great that you can write threaded code with more confidence, but it seems the conclusion here is that Rust gives you more confidence but not absolute confidence and you still need the normal stable of runtime detection tooling. The second fix[1] in particular resembles the bad pattern of "sprinkle atomics it until it works" you see in non-Rust languages.

(If this comment raises your hackles, please read the "no true Scotsman[2]" fallacy before responding.)

[1]: https://hg.mozilla.org/integration/autoland/rev/044f8b594c71 [2]: https://en.wikipedia.org/wiki/No_true_Scotsman

Here’s a good post by a kernel hacker that suggests how a tool like this can aid in debugging subtle corruption: https://blog.valerieaurora.org/2008/02/17/howto-debug-silent...

Looks neat! My wife is a dentist so I hear a lot about developments in this area.

The first question I have is about the business model — people already sadly often cut the dentist when cutting costs, so it seems like it would be hard to get a lot of people paying you $50-100 for a test whose outcome is either “you are ok” or “more costs incoming”. How do you see it working?

If you’d like more, the Wikipedia community on Reddit regularly shares neat articles like this one.

The definition of `new Map`:

https://www.typescriptlang.org/play?#code/FDDGHsDsGcBcAJrwLz...

(I still think this is actually due to bug in TypeScript, see https://github.com/microsoft/TypeScript/issues/31990 .)

It's worth noting that this (good) example is unrelated to unsoundness, too -- it's related to built-in APIs using 'any'.

Within Google we include a "strict" d.ts in every compilation that shadows this API (and one other) with one that instead returns "unknown". We have talked about going through the whole TS API and removing all the 'any' in this manner for this reason.

(I worked on Chrome.) I remember struggling over how to word this page. At a technical level Chrome the program can only control what it itself does, which is also what the page promises. Unfortunately despite that the result is still confusing to users (and judges, it appears).

My favorite plain text protocol is HTML server sent events, within HTTP. It's really trivial to make a server produce these -- it's just some simple newline-delimited printfs() to the socket -- and they manifest client-side as simple event objects.

https://html.spec.whatwg.org/multipage/server-sent-events.ht...

The OP is talking about technical details like static linking and language ecosystems, but if you zoom one level out, this comment correctly pins where the underlying problem actually lies: that the distribution maintainers inject themselves into the development process of all the software they ship.

When A/B are not well-maintained upstream, distributions can assist by updating its dependency D, but even when A/B are well-maintained upstream, distributions still might monkey with them when D changes, even when that change to D actually breaks the software. To me, the root cause is that the distributions are effectively attempting to participate the software they ship, but do so by getting in the middle, rather than participating upstream.

As a former author of some well-maintained upstream software I found their involvement made the software overall worse, but as a user of a distribution I find their maintenance of otherwise unmantained software sometimes helpful. In other words, I think the goal is admirable but the mechanism is wrong, and doing things like adding more dynamic linking only further enable the bad behavior.

Chrome is a pig for sure, but most attempts I see at measuring memory consumption are wrong. The two main ways they're typically wrong is either by misunderstanding how memory works (which is to be expected, it's subtle![1]) or by doing the measurement wrong (e.g. confusing CPU usage for RAM, or looking at the wrong process, or using a memory consuming extension in one setting but not the other). I think this post does both.

(Disclaimer: I worked on Chrome. I believe the conclusion "uses a lot of RAM" is correct, but it doesn't mean the reasoning that led to there is right.)

[1] http://neugierig.org/software/blog/2011/05/memory.html

You are totally right, thanks for catching my mistake.

My blog post linked above goes more into the consequences -- ideally you'd formally define what the allowable language subset is.

I was confused by this comment as well. I think what it's saying is that google-closure-compiler-js (note -js) is no longer maintained, and that to explain why it's using the (still maintained) google-closure-compiler (note no -js).

This whole page is weirdly similar to a project I did, for the same purpose:

https://evmar.github.io/js-min-bench/

What I discovered there is that the best minification is one where you just produce an empty file -- it's 0 bytes of output and extremely fast.

And if you say "wait, I have have the additional requirement that you didn't break the code in the original file, obviously!", you then must define what exactly "break" means in that requirement-- for example, it could be that some user requires that someFunction().toString().charAt(10) == 'a', in which case even removing whitespace counts as breakage.

You might think the above is just being overly pedantic or pathological, but it demonstrates a principle that actually ends up mattering, which is that you can't evaluate a minifier unless you define what a successful minification even means. Particularly in the case of more advanced transformation.

I went into it more in this post:

http://neugierig.org/software/blog/2019/04/js-minifiers.html

I went through a similar thing with my son. The best part was when an acquaintance recommended the “easier on the stomach” variant of one of the popular formula brands. I checked the box, first ingredient: corn syrup!

For what it’s worth, it’s very hard to be sure switching brands is the causation of a better outcome vs just a correlation. Babies change rapidly so it’s possible that unrelated development is there true source of recovery. But it was definitely a dramatic difference for us exactly when we switched formulas too.

It’s ironic, seeing this sentiment from this person in particular. My short list of “people who are jerks to free software maintainers” has him at the top.

I grew up in a small town in the PNW that has a yearly salmon festival, and it wasn't until a post from HN[1] that I learned/realized that the whole system of "fish hatcheries" that my town celebrated is kind of a horrible bandaid over the ecological disaster we perpetrated.

[1] https://news.ycombinator.com/item?id=21298472 , definitely worth a read if you care about salmon

I meant that the internal code name of the Google browser project was "chrome", under the assumption it would change when it was time to release.

> (Ironically [the Firefox UI bits] were called “chrome” before Chrome even existed.)

Not ironic, intentional. Chrome was made by former Firefox engineers, and the name was a joke about exactly this. I remember struggling to come up with a better name for the app other than this code name and then they eventually launched it with it anyway.

After 10 years as a vim user, I switched to emacs in part for the gdb integration. (It turns out you can run emacs with vim keybindings and get the best of both worlds -- vi keybindings but a real programming language for scripting...)

The Google File System (GFS) paper from 2003 mentions erasure codes. Which isn't to say they did it then, but rather that the technique of using erasure coding was known back then. (And surely before GFS too, I just picked it as an example of a large data storage system that used replication and a direct predecessor to the systems you mentioned.)

https://static.googleusercontent.com/media/research.google.c...

Suppose project B uses lax tsconfig settings. Now suppose strict project A imports from B. If A uses B via d.ts it may be ignorant of most of B's choices. But if A uses B as source, A's strictness settings will now attempt to apply to B.

Another consideration is that it only works if all the code agrees on tsconfig settings (e.g. strictness settings and path resolution). That can work in a monorepo but won't work if you mix libraries.

What you wrote is true, but it also seems to me unlikely that the OP is going to set up a sandboxed hermetic build to process a handful of pngs for her zine. I was instead explaining why Ninja doesn't attempt clever tricks to try to better approximate correctness.

Re a new version of inkscape: Ninja does not force fully-correct builds, so it's on the author of the build.ninja file to either model this or not. (This is part of Ninja's objective of not mandating policy.)

To get this fully correct, note that you would need to model all inputs that Inkscape might read, which includes not only binaries but also configuration files or dynamically-loaded plugins. Some systems (I think tup?) track this by tracing executed binaries to see which file system operations they do.

Even with tracing it can be really subtle: for example if a C file has an #include "foo.h", creating a new file named foo.h earlier in the include search path is a meaningful change, which means a file-access-tracing build system also needs to track file-not-found results from previous executions.

(For C programs, also note that getting header dependencies correct includes similarly tracking all the headers in /usr/include that your program transitively includes. See the -MD vs -MMD flags to gcc.)

Thanks so much for answering! I think what I'm trying to understand is why you'd want to target chemicals if other options like surgery also are targeted. Is the application then for tumors that are hard to remove surgically?

I think all of the things you just wrote are true, but I don't see how they answer the question I asked... ?

My layman's understanding of chemo is that it's meant to be systemic: surgeries and radiation are targeted at the tumor itself, while chemo is meant to hopefully wipe out cells that have reached other parts of the body.

But the description from this article suggests they're trying to make the chemo more targeted to the site of the tumor. That seems to counteract what I had understood to be the point of chemo.

Can you explain? (In case it wasn't obvious from the above, I have low knowledge in this area.)

It's such a common inside joke that people even make variant jokes in reference to it, like maybe: "Subject: An update on evmar / Body: No, I'm not quitting, I just got a new puppy!"

I haven't touched it in many years, but:

I think (a) it's still possible, per https://chromium.googlesource.com/chromium/src/+/master/docs... .

(b) Creating new .so files that shadow functions in others is an interesting idea! I think you're implying that the executable wouldn't pick them up for free, which I think is true, but I'm not actually sure. I forget the details of how this works but it might be that you could just play tricks with the order of the files to make them shadow.

In practice with a fast linker (I used gold at the time, but I think lld is even faster than gold now) it doesn't matter so much as long as you keep the component libraries small enough. But my info is also nearly a decade out of date now...