pilaf

These photos look colorized. Likely not the original colors of those robes.

Was I not paying attention before or has the rate of new discoveries in Pompeii gone up drastically in recent years?

OP meant that "yes" is not a word in Spanish. The word "sí" is indeed the affirmative and it's used mostly the same as yes in English.

You're probably referring to Cycles X [1], which if I'm not mistaken has already been released.

It will never be on-par with Eevee's performance though as they are fundamentally different approaches to rendering: Cycles is a physically-based path-tracing engine, while Eevee uses rasterization through OpenGL.

1: https://code.blender.org/2021/04/cycles-x/

Oh, I thought IceWeasel had been renamed to IceCat, but the repo you linked to has recent activity and calls it IceWeasel, now I'm a bit confused. Glad to see it's active though.

This made me look into Firefox forks/alternatives:

Librewolf [1] seems to be fairly active (last commit on Codeberg was last week) and up-to-date with the latest upstream releases (mirrors FF's versioning scheme and matches their latest). Has a nice focus on privacy and no-telemetry.

Floorp [2] also looks active (last commit last week), also claims focus on privacy. Based off FF's extended support releases so it may lag behind in latest features.

Waterfox [3] is also active (last commit a few hours ago), also big focus on privacy, but it uses a custom versioning scheme so I can't tell how closely it follows FF's releases.

GNU IceCat's [4] latest release was in November 02023, so it looks like it may be abandoned.

Does anyone have any experience with any of these, good or bad? With all of them more or less promising the same things it's hard to tell which one may be the better option.

1: https://librewolf.net/

2: https://floorp.app/en

3: https://www.waterfox.net/

4: https://icecatbrowser.org/

I'm doing well! Hope you are too.

I sometimes come across your comments here, but I rarely have a chance to reply. I almost write the year as 02020 above just in case you found it, now I'm sad I didn't.

To add to that, quoting from the paper [1] (published in 2020):

> ACKNOWLEDGMENTS:

> Dylan, Juli, Bruno and Massi are a group of 18/19-year-old friends from Buenos Aires, Argentina. The original idea came to Juli while having a shower. Bruno calculated the prime-generating constant, first by brute-force and then by finding its formula. As the investigation continued, Juli and Bruno were joined by Massi and Dylan. Later, the team contacted mathematician James Grime who helped by tidying up some of the proofs and writing this note. So ∞ thanks to James!

1: https://arxiv.org/abs/2010.15882

The page's background turns to fairly unpleasant pink once you scroll past the middle point. Is that the norm for design.google blog posts or is it some kind of subtle messaging about the new gradient?

Also the replacement of the mouse cursor with that negative-color circle is visually interesting, but it suffers a lot from input lag which gets on my nerves.

I would guess so. Their blog also has a big gap between 2020 [1] (when the Servo team was laid off from Mozilla) and 2023 [2] when they found new funding and restarted development, with nothing else posted in between.

1: https://servo.org/blog/2020/11/17/servo-home/

2: https://servo.org/blog/2023/01/16/servo-2023/

I think the title (and the article to a degree) is misleading. Something like "Japanese bureaucrats finally plan to update severely out of date official romanization scheme" would be far more accurate.

The examples in the top table make it clear, I've never once seen judo romanized as zyûdô, it's always jūdō. Out of curiosity I asked a native Japanese speaker and although they could figure out what word it was they had never seen the former romanization either.

The title also makes it sound like a new romanization system was just created, when in fact it's just modern Hepburn, which is how everyone other than the Japanese government has been romanizing Japanese words for ages. The article does mention Hepburn to be fair, but then it makes it sound like the proposed changes are something new and not the de facto standard.

When typing in Japanese I tend to type "tu" instead of "tsu" or "si" instead of "shi" because the end result is the same (つ/し) and I save a keystroke, I assume most people who regularly input Japanese with a QWERTY keyboard do the same. The revised romanizaton from the article prefers "tsu" and "shi" though.

Yeah I think you're right, unless you often visit those places it's more common to just see their names only when you pass by their train stations or see them on the train maps, so the "mb" spellings stand out more.

Tokyo Metro romanizes 日本橋 as Nihombashi, you can look up the station on Google Maps and check out the photos, the signage showing "Nihombashi" shows up pretty soon.

Google Maps itself also romanizes it as Nihombashi. Same applies to 神保町 (Jimbōchō), for instance.

https://maps.app.goo.gl/5gDMNmqJwsHTsEUk8

The Computer Language Benchmarks Game has some compared benchmarks:

Ruby+YJIT vs Python: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Ruby+YJIT vs PHP: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Ruby+YJIT vs Lua: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

What a great resource, thanks to whoever put this together.

To anyone who enjoys contorting the language to make it do weird things for fun, quines, and those sort of things, I really recommend Tomoya Ishida's talk at RubyKaigi 2024. It's in Japanese, but there are subtitles, and the slides speak for themselves. Some of the more whimsical uses of Ruby I've seen in a while. Keyword to peak your interest: animated quines.

https://www.rubyvideo.dev/talks/keynote-writing-weird-code

https://www.youtube.com/watch?v=k6QGq5uGhgU

Yeah, happened to GIMP as well, for a while they didn't have anyone in charge of macOS builds, so they just skipped the platform for a few releases.

For me it's gotten a lot better since one or two versions ago. There's still some lagginess, but it's nowhere near the horror show that it used to be, and they fixed some excruciating screen resolution issues as well. I used to avoid Inkscape on macOS like the plague, now I can use it fairly comfortably.

I haven't used Graphite, but from what I've seen it allows for non-destructive procedural editing using nodes (à la Blender), which Inkscape mostly doesn't do.

According to the specs the <html> tag can be fully omitted. From MDN [1]:

> The start tag may be omitted if the first thing inside the <html> element is not a comment.

> The end tag may be omitted if the <html> element is not immediately followed by a comment.

1: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ht...

That's very quick judgment based on pure speculation. Do you know what the numbers look like for your own country? Are those stats even published?

Would be nice if the hidden by default C code was syntax-highlighted as well.

> Maybe Ruby isn't used for accessible web development.

What an unnecessary comment. Sure, the docs website could use more work, but what does the choice of a language used for back-end development have to do with the quality of the front-end code (non-Ruby) in those same projects?

Monthly inflation since December 2023 has followed these numbers:

  * Jan - 20.6%
  * Feb - 13.2%
  * Mar - 11%
  * Apr - 8.8%
  * May - 4.2%
  * Jun - 4.6%
  * Jul - 4%

So yes, inflation has gone down.

Inflation for August is not yet known, as it's only measured for the completed month and revealed a couple weeks into the following month. It's expected that August should also hover around 4% though.

For comparison here are the last 6 months of 2023:

  * Jul - 6.3%
  * Aug - 12.4%
  * Sep - 12.7%
  * Oct - 8.3%
  * Nov - 12.8%
  * Dec - 25.5%

Source: https://www.indec.gob.ar/indec/web/Nivel4-Tema-3-5-31

But the number 3 is there just because we decide to calculate digits in base 10. We could encode Pi in binary instead, and since it doesn't repeat it necessarily will never be a point where there will never be another 1 or a 0, right?

> Where on the roadmap is GPU compositing? In modern browser programming, I kind of take for granted that I can control the rendering “layers” and certain CSS properties, like “transform,” will be accelerated.

AFAIK there's some support for it already, but it has to be enabled explicitly with --enable-gpu-painting. I can confirm that with that switch Ladybird can do 3D CSS transforms (which don't work without it).

Fun fact: Andreas has also worked on Konqueror/KHTML back in the day, or so I remember him saying in one of his videos.

> is there a "ffmpeg in the browser"?

I don't know if this project uses it, but there's ffmpeg.wasm [1].

1: https://github.com/ffmpegwasm/ffmpeg.wasm

> People won't stop using Chrome as long as they keep up the current pace of glomming on more complex APIs and syntax. No other team can compete.

I don't have any delusions of Ladybird ever touching Chrome's market dominance, but I disagree that no competition is possible if the goal is building an usable browser. Sure, web standards are blown up out of proportion and keep on growing, but how much of those standards are actually used on a daily basis? How many websites can't work without the GravitySensor or HighlightRegistry APIs [1][2], just to name a couple? How many new standards become absolutely indispensable vs being just bloat never touched by 99.9% of the web?

Ladybird, Servo and others don't need to catch up to Chrome in terms of features to be useful, they just need to cover the metaphorical 20% of the specs to support the 80% of the web. In the case of Ladybird at least that seems to be the principle guiding its development, with devs dogfooding it and implementing specs to scratch their own needs.

But I understand I'm probably arguing a different point than you were.

1: https://developer.mozilla.org/en-US/docs/Web/API/GravitySens...

2: https://developer.mozilla.org/en-US/docs/Web/API/HighlightRe...