opticfluorine

Wow, what a portfolio! This one in particular caught my eye: https://adazshen.com/Viral-Placenta

I have little artistic ability myself, but I am continuously in awe of what artists create. It makes me hope for the optimistic outlook of AI where UBI frees people to pursue creative and intellectual pursuits, rather than constantly trying to push a stock price uphill.

I wonder if you could generate it via a Roslyn incremental source generator instead of as a file to bypass this limit. I'm guessing not, but it does sound like fun.

Minor nit, Joule-Thomson is not just the ideal gas law - it is a separate thermodynamic effect entirely. Case in point, for certain gases the change in temperature due to Joule-Thomson has the opposite sign that you would predict from the ideal gas law alone.

This has interesting applications. For example, you can exploit this with dilute metal vapor in an expanding helium gas to cool the metal vapor to very low temperature - the Joule-Thomson expansion of helium increases the helium's temperature by converting the energy of the intermolecular forces into heat. This draws out energy from the metal vapor. If done in a vacuum chamber, then in the region before the shockwave formed by the helium, the supercooled metal atoms will form small van der Waals clusters that can be spectroscopically probed in the jet. This was an interesting area of study back in the 80s that advanced our understanding of van der Waals forces.

I have occasionally, just for fun, written benchmarks for some algorithm in C++ and an equivalent C# implementation, them tried to bring the managed performance in line with native using the methods you mention and others. I'm always surprised by how often I can match the performance of the unmanaged code (even when I'm trying to optimize my C++ to the limit) while still ending up with readable and maintainable C#.

I personally think this last sentence from my quote makes it unclear:

"In short, if you use this project to generate revenue, the Open Source Maintenance Fee is required."

Perhaps I'm being too semantic, but I don't feel that is an accurate representation of the license terms involved here.

I came across this a few months ago when I was evaluating open source installer options for my own open source project. I have no issue with charging for binaries while the source is available under an OSI license, but this from the README rubbed me the wrong way:

"To ensure the long-term sustainability of this project, use of the WiX Toolset requires an Open Source Maintenance Fee. While the source code is freely available under the terms of the LICENSE, all other aspects of the project--including opening or commenting on issues, participating in discussions and downloading releases--require adherence to the Maintenance Fee.

In short, if you use this project to generate revenue, the Open Source Maintenance Fee is required."

I'll give the benefit of the doubt and assume this is just a difficult concept to succinctly explain in a short paragraph. But that summary - that revenue-generating use requires payment - feels misleading to me. Under their license, nothing stops me from creating my own build from source and using it per the terms of the MS-RL license, including for commercial purposes. So to me it feels like a scare tactic to coerce commercial users into becoming sponsors for the project.

I certainly understand the challenges faced by open source maintainers today, but the specific approach taken here just doesn't feel ethical to me. I ended up passing on WiX for that reason even though I'm not a commercial user.

Wasn't suggesting at all that you use my distro or that you can't use X11 as your solution. Debian is great and I use it for all of my servers. I'm just responding to the assertion that Wayland doesn't work with NVIDIA today, which is really only true if you are using older packages for a more stable distro. Nothing wrong with that, but it's not accurate to represent the current state of Wayland based on a distro known for using older packages.

I have an RTX 4060 with latest drivers, KDE, and Arch. Wayland works perfectly for me. Maybe Debian has some outdated packages that haven't caught up yet?

This definitely resonates with me. One of my favorite pasttimes is to code away on a 2D multiplayer RPG engine, and I've ended up doing at least a few of the projects on this list as part of that (ECS framework, voxel renderer, physics engine). Integration with a scripting engine like Lua is another fun one for a list like this, especially if you try to do it in an idiomatic way for your main programming language and/or leverage code generation and metaprogramming.

One thing I've found I enjoy is working on a larger-scope toy project composed of many loosely coupled systems. It works well for me because no matter what type of project I'm interested in working on, I can usually find something applicable within the larger project. Currently on my to-do list are behavior trees and procedural terrain generation, and honestly I don't know how I'm going to decide which to do first.

I wonder, how close does Godot get with its web export support? The "authoring tool" seems pretty good, and it exports to WASM.

Especially when one of the language's main purposes is to be embedded in applications written in other languages (which are predominantly zero based) - and so you tend to have a lot of back-and-forth integration between these two styles that can get confusing. Even from the C API side, for example, the Lua stack is one-based but addressed exclusively from the host language which is likely zero-based.

It is funny, isn't it? I always wonder how the language would be perceived had they gone with zero based indexing from the start.

I'm a big fan of Lua, including for the reasons you mention. I suspect the reason this one thing is always brought up is twofold: it's easy to notice, and it's very rare these days outside of Lua (if you consider VB.NET to be a legacy language, anyway). Other criticisms take more effort to communicate, and you can throw a rock and hit ten other languages with the same or similar issues.

Having just gone through the exercise of integrating Lua with a custom game engine over the past few weeks, I have to echo how clean the integration with other languages is.

It's also worth noting that the interface is clean in such a way that it is straightforward to automatically generate bindings. In my case, I used a handful of Roslyn Incremental Source Generators to automatically generate bindings between C# and Lua that matched my overall architecture. It was not at all difficult because of the way the interface is designed. The Lua stack together with its dynamic typing and "tables" made it very easy to generate marshallers for arbitrary data classes between C# and Lua.

That said, there are plenty of valid criticisms of the language itself (sorry, not to nitpick, but I am really not a fan of one-based indexing). I'm thinking about designing an embedded scripting language that addresses some of these issues while having a similar interface for integration... Would make for a fun side project one of these days.

To add to this, there are also official Microsoft extensions to VSCode which add absurdly useful capabilities behind subtle paywalls. For example, the C# extension is actually governed by the Visual Studio license terms and requires a paid VS subscription if your organization does not qualify for Visual Studio Community Edition.

I'm not totally sold on embrace-extemd-extinguish here, but learning about this case was eyebrow raising for me.

When I used to work in defense contracting, this is precisely what we (the contractor) did. We would buy up all available stock of any difficult-to-replace parts (often specific SBCs) when the manufacturer announced end of life.

I've ruled out several properties in my current homebuying search for this exact reason. Having lived next to the neighborhood collection pond once before (a rental thankfully), I'm extra paranoid about stormwater and drainage now.

I've seen a number of homes in my area where the builder received special permission to build right where the drainage needs to go. Some were beautiful and I was tempted to give it a shot, but your story reminds me that I need to trust my gut on this issue and head for high ground.

My organic chemistry professor always liked to point out that while CO2 is a gas that is easily dealt with following metabolism, SiO2 - silica/quartz - is most decidedly not a gas. Add that to the list of challenges for silicon-based lifeforms. Not to say that it isn't possible, but it does constrain the solution space somewhat.

Out of curiosity, if it is known that the nth bit is set, don't I also have the same risk but in (n-1) bits? Genuinely curious here.

Edit: Ah, nevermind, I see now why I don't have that issue. It's because I can't easily iterate the primes in that domain even though I can iterate the reduced number of bits. Thanks!

For the purposes of key generation, however, wouldn't you want the full n bits of entropy? Otherwise the search space for a brute force factorization (haha right) is 2^(n-1) instead of 2^n, or half as many possibilities. The domain of the product is still [0..2^(2n)] so the resulting key is the desired 2^(2n) bits.

I guess another way to pose my question would be: is there an issue with sampling the entire 2^n space that makes us only take the highest 2^(n-1) subset of integers instead when selecting factors for a key?

The random number returned is OR-ed with 0b1000000000000001 to set its first and last bit to 1. The last bit set to 1 makes it an odd number and the first bit set to 1 ensures that it is a sufficiently large number which covers the entire range of bits I need.

I can understand setting the low bit to 1 since an even number will never be a prime (edit: obviously except 2). But why set the high bit to 1 as well? Admittedly I don't know much about prime numbers or crypto, but it seems to me like this is just giving up a bit of entropy unnecessarily. What am I missing here?

Not disagreeing with your point, but it couldn't be a compiler optimization, could it? The compiler isn't able to infer that the class will not be inherited anywhere else, since another compilation unit unknown to the class could inherit.

Very similar experience here, and I ended up going directly into industry instead of a postdoc because I had the same realization. I'm glad I did it that way, though, because I'm very proud of my research and I think we did something very interesting and novel.

Welp, glad I didn't go through with trying to contribute to TMW. That's disappointing to hear. I've had a much better experience trying to build my own MMO engine instead.

In 200 years this is going to be like when we discover yet another proof of Euler or Gauss, 20 years after a current mathematician arrived at the same result.

One reason is new applications in legacy enterprises that are slow at adopting newer/better languages for a variety of reasons. I used to work as an embedded SWE for a Fortune 500 that made heavy use of C++ and was very resistant to Rust/Zig/others, but was much more willing to adopt newer versions of C++ for new projects. Although I would have preferred to work in Rust, having features like these would have been great in that environment.

Speaking as someone who used to work in DFT (the computational side), the multiple interesting computational results showing band structures often associated with high-Tc superconductors seemed interesting. It's a long shot (because prediction via DFT, as opposed to explanation, is difficult to say the least), but if I was still in the field I would be searching the nearby material space for similar materials that both exhibit the interesting band structure, and also exhibit that structure in the most thermodynamically preferred state. To my understanding this was one of the issues with LK-99 - even though the computationalists found that possible band structure, it was thermodynamically disfavored vs another copper substitution that did not exhibit a similar band structure through DFT calcs.

That being said, even if you did find an interesting band structure with a viable thermodynamic pathway for material synthesis, it says nothing about whether it has a room temperature Tc or some lower Tc. But regardless, it could lead to the discovery of some interesting new high-Tc superconductors. Or nothing, since that's how DFT (and more broadly, basic research) goes.

I'll bet there are labs doing something similar to this now.

If I'm not mistaken this doesn't appear to be a catalyst. The reaction is driven by the irreversible formation of a strong P=O double bond, and the reagents are consumed. So great for chemical synthesis, but no clear path to fuel cell type reactions.

Is maple walnut ice cream not a thing across the US? I grew up in New England not far from the Canadian border, now live in upstate NY and have easy access to maple walnut ice cream. Never realized how lucky I was.

The LBNL DFT paper isn't claiming to have modeled the strong correlations. Rather, they observe a specific feature of the band structure (flat bands crossing the Fermi level formed from d-orbitals) that have also appeared in DFT calculations of other high-temp superconductors and are considered a signature of those materials. In the other high-Tc materials, the calculations are consistent with experiment, and so the unexpected appearance of these bands in the reported crystal structure is seen as a signal of "hey, if this turns out to be real, we can explain it with current physics." That's something that previous fraudulent claims of room temperature ambient pressure superconductors (University of Rochester group) couldn't do.

The other interesting conclusion of the LBNL paper is that the low-energy physics of the electronic structure can be effectively modeled by a two-level effective Hamiltonian. This is a common pathway to bridging the gap between DFT calculations and theoretical understanding of strong correlations.

None of the serious scientists are saying "hey, look, DFT predicted it so it's true." Rather, it doesn't rule it out, and it suggests that it could be understood with our current physics. That's significant in itself.

As a fully remote manager who has never been an in-office manager, I have to wonder if the control being lost is really necessary. In two years of leading a department of 25 engineers, I've never found a need to exert any control that I couldn't from my home. This is at a Fortune 500 (non-FAANG).