mauricioc

https://www.smbc-comics.com/comic/aaaah

If you have "3 1 5" and you burst 1, you gain 3x1x5 points and the state becomes "3 5", with the two remaining balloons being adjacent to each other.

The "1x3x1=1" part for the earlier example is a typo indeed, it should be 3.

I wouldn't say there's a ton to connect.

What's the point of your rude post? OP already knows this. In fact, they learned it from Tom Lehrer.

Parent's point is that sometimes (but not always) the store is perfectly fine selling you a car for $1 less than what the "price tag" of Delta(G)+1 dollars asks for, so "need" is a bit inaccurate.

For the edge-coloring problem, the optimal number of colors needed to properly color the edges of G is always either Delta(G) (the maximum degree of G) or Delta(G) + 1, but deciding which one is the true optimum is an NP-complete problem.

Nevertheless, you can always properly edge-color a graph with Delta(G) + 1 colors. Finding such a coloring could in principle be slow, though: the original proof that Delta(G) + 1 colors is always doable amounted to a O(e(G) * v(G)) algorithm, where e(G) and v(G) denote the number of edges and vertices of G, respectively. This is polynomial, but nowhere near linear. What the paper in question shows is how, given any graph G, to find an edge coloring using Delta(G) + 1 colors in O(e(G) * log(Delta(G))) time, which is linear time if the maximum degree is a constant.

As you point out, 'icônes' is French for 'icons'; the name is probably related to the fact that the site is built using Vite. Was NES capitalized in the title earlier?

As it happens, I'm the kind of masochist who uses Sublime Text without any plugins for most of my programming, so I find value in letting people stick to their familiar workflow, even if some might see that workflow as somewhere between 'grossly inferior' and 'literally unusable'.

I definitely think there are upsides to not tweaking your text editor config endlessly, so I understand your point :) What I meant with "vim/emacs" is mostly that sometimes you really want to automate a text editing task, and then it's really convenient to have a programmable text editor. It's also very much a case of [0].

I'm a bit curious, how well do these tools handle HTML email?

In my case, I use mu4e in emacs to read my mail. Very basic HTML works by default via emacs's native HTML renderer (see, e.g., [1] for old screenshots). That's my preferred solution because I like the keyboard consistency (it's just an emacs buffer) and because there is a command to view the email in an external browser if needed, but it is also possible to render HTML email accurately in emacs by embedding a webkit widget [2]. As for writing, you can write in Org mode format (emacs markdown, if you will) and it gets converted to HTML on send.

[0] https://www.xkcd.com/974/

[1] https://lars.ingebrigtsen.no/2015/02/10/eww-now-with-fonts/

[2] https://www.reddit.com/r/emacs/comments/l60p6a/howto_mu4e_an...

Of course, the classic response is "get a better MUA you luser"

Git is distributed and allows you to work efficiently with poor connectivity, having full history available at any time, which is a big accessibility point for people with limited connectivity (and also helps people working while traveling, for example). If you do have any email client, you get all of this as well, plus arbitrarily powerful, low-latency filtering and searching. I recommend Greg KH's "Patches carved into stone tablets" talk [0].

Despite your "luser" strawman, people advocating for client-side MUAs mean well and have a point. Try replacing "webmail" by "Notepad" and "client-side MUA" by "emacs/vim" to see how your argument sounds. You probably spend a decent amount of time interacting with email, and the investment in setting up a fast, flexible and powerful environment (preferably reusing your text editor for composing messages) for doing so pays for itself soon.

[0] https://www.youtube.com/watch?v=L8OOzaqS37s

https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...

Edit: For further context for Linus's reply, there's http://web.archive.org/web/20250206022420/https://social.tre...

Volume 4, Fascicle 7 was officially released this week! The latest draft ("prefascicle", dated December 2024) is available at https://www-cs-faculty.stanford.edu/~knuth/fasc7a.ps.gz. As Knuth says, the contents "agree fairly well with the contents of the first paperback printing of Volume 4, Fascicle 7, except for parts of the index. As usual, the prefascicle is 'frozen' and will not be maintained, while the paperback will gradually improve with time."

The real scandal here is the pressure to remove a maintainer based on vague "code of conduct violation grounds" when the supposed "violation" is just expressing an technical preference on code he maintains. Shamelessly weaponizing a code of conduct like this should be a code of conduct violation in itself.

(I am a big proponent of language interop as an alternative to big rewrites. But opinions differ, and my opinion is worth nothing because I'm not a maintainer of the relevant code.)

The function defined in the video is "Given a pair of points A and B on the curve, output (x, y, z), where (x, y) is the midpoint and z is the length of the segment connecting A and B", and the pictures are of its image, not its graph. But if you define it visually, then it's very natural to misunderstand it the way you did, since the picture looks a lot like a function graph of a function which takes midpoints (instead of pairs of points) and returns the distance corresponding to that midpoint (which is not well-defined, as you pointed out). If this happens, the viewer is then completely lost, since the rest of the video is dedicated to explaining that the domain of this function is a Möbius strip when you consider it to consist of unordered pairs of points {A, B} (as one should).

Ultimately, if you don't have a 100% formal version of a given statement, some people will find a interpretation different from the intended one (and this is independent of how clever the audience is!). I think 3Blue1Brown knows this and is experimenting with alternate formats; the video is also available as an interactive blog post (https://www.3blue1brown.com/lessons/inscribed-rect-v2) which explicitly defines the function as "f(A, B) = (x, y, z)" and explains what the variables are.

The fact that "given a large enough audience (even of very smart people), there will be different interpretations of any given informal explanation" is a key challenge in teaching mathematics, since it is very unpredictable. In interactive contexts it is possible to interrupt a lecture and ask questions, but it still provides an incentive to focus on formalism, which can leave less time for explaining visualizations and intuition.

Now I really want to go to a "Sexuality, Gender and Hacking the RP2350" talk. Maybe next year?

Valid point, but I will also amend your nitpick: Schwarz is also a name of a lot of people :) Both refer to hair colour, I think. "Schwartz" was a valid spelling for the colour many centuries ago (see, e.g., item 15 in [1]), which makes sense since both spellings are pronounced the same way. Surnames don't follow spelling changes, so that's the only situation in which both variants coexist now. In maths, you have the Cauchy-Schwarz inequality and Schwartz's theory of distributions.

[1] https://woerterbuchnetz.de/?sigle=DWB&lemid=S04549

The WHO [0] reports 60 thousand Covid deaths this year so far, and around 250 thousand deaths in 2023.

[0] https://data.who.int/dashboards/covid19/deaths

Previously: https://news.ycombinator.com/item?id=38779480

The grandparent thought this was implausible, researched it as an outsider (with a slight bias towards thinking the claim is false, which is not a problem per se) and still didn't find any refutation. While I applaud the impetus behind the research, I'm more inclined to believe the apocryphal story after reading the attempt to refute it; not every piece of gossip will be supported by a written statement.

Raymond Chen has been writing his blog for more than 20 years now, almost 7000 posts. It is a treasure trove of information and first-hand account. I can see an argument for peer-reviewing every post, but I think it would have limited (a lot) the amount of "from the trenches" knowledge we get from him.

Your reference to the Parallax Propeller is domain-specific and a bit anachronic; you're talking about embedded computing, while he is talking about general-purpose computing a few decades prior. The point of the post is that general-purpose computing was different in the past (in a sense, that's the theme for the whole blog! that and compatibility hacks), so going this far back is necessary.

The whole page is tongue-in-cheek. In the '90s, <blink> was only supported by Netscape while <marquee> was only supported by Internet Explorer, so combining the two didn't make a lot of sense. Mozilla only added <marquee> support in 2002: https://bugzilla.mozilla.org/show_bug.cgi?id=156979.

This makes it seem like they invented XHR and did nothing with it, but Outlook Web Access already used XHR for dynamic/asynchronous update of an email web interface context four years before Gmail.

If your claim is that Google popularized the ideas behind Ajax, then I'll happily agree: The term Ajax was invented outside Google [0] to describe Gmail front-end inner workings. My first contact with Ajax-like technologies was certainly Gmail in 2004 and not OWA in 2000, so I am not denying the merits of popularization. But I think even saying Google "developed the technology into" Ajax is unfair to OWA, given that Microsoft was pushing the other components of Ajax for a lot longer as DHTML (which led to standardizing DOM [1]; document.all anyone?) and OWA used DHTML+XHR, which was at the time essentially a non-cross-browser version of Ajax (props to Mozilla for implementing a compatible version of XHR and shipping it as part of Mozilla 1.0 in 2002).

I won't argue for Microsoft any further, though, because the "cross-browser" part is key. The fact that they invented and shipped these things in IE with no effort to standardize them (as part of their embrace, extend, extinguish approach) was a big headache for cross-browser compatibility. Google gets most of the credit for Ajax because web developers hated Microsoft's approach to the web at the time (for very good reason). It is interesting to compare Microsoft's behavior back then with Google's current approach of flooding standards bodies with (at times half-baked) proposals.

[0] https://web.archive.org/web/20150910072359/http://adaptivepa... [1] https://www.w3.org/DOM/faq.html#DHTML-DOM

Microsoft invented Ajax/XMLHttpRequest for Outlook Web Access.

Duolingo courses are no longer created by volunteers. They stopped the volunteer program in 2021 [1], right around the time they increased monetization efforts. They offered part-time jobs and a $4 million reward fund to previous volunteers when closing the program, which I thought was pretty kind.

[1] https://blog.duolingo.com/ending-honoring-our-volunteer-cont...

An important part of reading mathematics is mentally filling in the "correct" interpretation for terms. The optimal amount of detail typically depends on the target audience. Part of that is because making notation fully specified in English is typically cumbersome: If they had written "as their second non-repeating prime", someone could come along saying "shouldn't it say 'second-smallest' or 'in increasing order' as well?". In papers, the use of such terms would typically be accompanied by a formal definition using more precise (but not fully precise, see the talk below) mathematical notation.

I mention this not to be pedantic, but because inferring the "invisible" part of mathematics (when it can be done) instead of asking humans to do it explicitly tends to be a big usability improvement in theorem provers. Andrej Bauer has a nice talk about it at https://www.youtube.com/watch?v=wZSvuCJBaFU

An argument on a public forum is not won by whoever shouts the loudest or has the most "courage". If expressed clearly enough, it suffices (and is much wiser) to explain your ideas once and let the readers decide.

https://en.wikipedia.org/wiki/Frequency_illusion perhaps?

He had a brilliant Yorkshire accent

There's a talk of his on YouTube for anyone curious: https://www.youtube.com/watch?v=E8BNIohtyMQ (it's unrelated to Ramsey theory but also very interesting).

It's a great book and I'm happy to see it get attention, but this was previously posted at https://news.ycombinator.com/item?id=38106860

To emphasize chpatrick's point below, there are two definitions of "reproducibility" in this context:

* Input reproducibility, meaning "perfect cache invalidation for inputs". Nix and Guix do this perfectly by design (which sometimes leads to too many rebuilds). This is not on the radar for Debian and Arch Linux, which handle the rebuild problem ("which packages should I rebuild if a particular source file is updated?") on an ad-hoc basis by triggering manual rebuilds.

* Output reproducibility, meaning "the build process is deterministic and will always produce the same binary". This is the topic of the OP. Nix builds packages in a sandbox, which helps but is not a silver bullet. Nix is in the same boat as Debian and Arch Linux here; indeed, distros frequently upstream patches to increase reproducibility and benefit all the other distros. In this context, https://reproducible.nixos.org is the analogue of the other links you posted, and I agree Nix reports aren't as detailed (which does not mean binary reproducibility is worse on Nix).

Your comment can be misinterpreted as saying "Nix does not do binary reproducibility very well, just input reproducibility", which is false. That's the whole point of the milestone being celebrated here!

Shumway happened before Flash EOL, so it's likely that Adobe forced development to stop. Although Ruffle existed before January 2021, it flew under the radar back then. Even if Adobe had no hand in it, it's much easier (and less risky) to fund an implementation after the official one reaches EOL.

XP stands for "cross platform": https://www-archive.mozilla.org/xpfe/