pedrocr

That gave me something to play with with these models and this came out as a claimed disproof of the Dixmier Conjecture:

https://gist.githubusercontent.com/pedrocr/51157b9b2eed8152e...

It seems mathematics has at least gotten a powerful new tool to automate the work to cascade results after breakthroughs are made.

What you are describing is what's called free float market cap and is generally what market indices use to weigh stocks. That way you're only trying to replicate the market of stocks that are actually available to trade. There's nothing new about SpaceX in that respect, plenty of companies have float much lower than their total.

If I was an APT, compromising Tailscale would be priority number 1!

Crowdstrike would be at a much higher priority. They already have a cloud connected root console to all the machines in entire corporations. Compromising your network is small potatoes compared to that.

The computer I'm writing this on has 64 GB of RAM, 1024 times as much. By comparison I have a 20-core Intel CPU with up-to 3GHz speed or somewhere around there, even pretending each core could run at that max speed simultaneously (which they can't), that's only 133-times as much CPU power.

Over that time CPUs have also increased their instructions per clock by 3 to 4 times, so the comparison is a bit closer than that. 5Ghz in CPUs is also common these days which would make it even closer. RAM has also improved in more than just total size though.

It was still more secure than the default if I understand this correctly. On resume from suspend the laptop would still be locked by the encryption key and without access to the disk even if you can somehow circumvent the lock. The only insecurity was that somewhere in the kernel memory the key still exists so if you can somehow extract that from the live system you can unlock it.

+ battery too. I've wondered if a mini pc with battery would make for a good form factor. I often move between places where I have a desk with a screen but still use a laptop because I want to just suspend and resume. If a mini pc had a small battery just to hold its RAM while suspended I could move between places and just plug in a single USB-C cable and have my full workstation up and running. The thermals could be better than in a laptop and having a built-in UPS better than with a desktop. But last time I checked no one packaged things like that.

In the AMA you link they say the tulip mania was probably a bubble just not a major one that impacted the economy meaningfully.

That seems wrong. If you have a way to maintain enough propulsion for long enough you can escape the gravity well at any arbitrarily low speed. You "just" need to maintain that speed long enough for the escape velocity from the gravity well to go below it as it diminishes with distance from the mass.

There seem to be some 15 inch all-in-ones but these days if what you want is a small form factor the answer is surely a laptop. Even if you're just going to keep it on the same desk forever that's what you'd get if you want 15 inch or smaller.

I once made a criminal complaint because of a sewer line that was frequently allowed to overflow into a creek. The prosecutor refused to prosecute the case with the argument that the root cause was "real estate pressure" and so the county (that licenses and taxes any new construction) and the sewage operator (that coercively charges anyone that can physically connect) couldn't possibly be blamed.

Another advantage is you can place the fans all along the wing getting you better stall resistance as the flow doesn't detach as easily. There's already a prototype of a hybrid plane that does this:

https://www.electra.aero/

One of the authors of this paper did a pretty long podcast with Huberman about this topic:

https://www.hubermanlab.com/episode/red-light-to-improve-met...

The show notes have links to quite a few more papers. I have no idea if this is good science but this is not just a one off paper.

That's great if you're compiling for use on the same machine or those exactly like it. If you're compiling binaries for wider distribution it will generate code that some machines can't run and won't take advantage of features in others.

To be able to support multiple arch levels in the same binary I think you still need to do manual work of annotating specific functions where several versions should be generated and dispatched at runtime.

I'm curious if that's still the case generally after things like musttail attributes to help the compiler emit good assembly for well structured interpreter loops:

https://blog.reverberate.org/2025/02/10/tail-call-updates.ht...

This seems to be the Ubuntu bug report:

https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu...

agents were previously spending 3-5 minutes after each call writing manual summaries of the calls

Why were they doing this at all? It may not be what is happening in this specific case but a lot of the AI business cases I've seen are good automations of useless things. Which makes sense because if you're automating a report that no one reads the quality of the output is not a problem and it doesn't matter if the AI gets things wrong.

In operations optimization there's a saying to not go about automating waste, cut it out instead. A lot of AI I suspect is being used to paper over wasteful organization of labor. Which is fine if it turns out we just aren't able to do those optimizations anyway.

They are perfectly good machines as servers and desktop terminals.

On the power usage alone surely an upgrade to a still extremely old 64bit machine would be a significant upgrade. For a server that you run continuously a 20+ year old machine will consume quite a bit.

Thanks! By retrofitting I mean having to have a new protocol with this new opt-in method where some apps will be getting integer scales and go through a transform and some apps will be getting a fractional scale and rendering directly to the output resolution. If this had worked "correctly" from the start the compositors wouldn't even need to know anything about scaling. As far as they knew the scaling metadata could have been an opaque value that they passed from the user config to the clients to figure out. I assume we're stuck forever with all compositors having to understand all this instead of just punting the problem completely to clients.

When you say you supported this for quite some years was there a custom protocol in KWin to allow clients to render directly to the fractionally scaled resolution? ~4 years ago I was frustrated by this when I benchmarked a 2x slowdown from RAW file to the same number of pixels on screen when using fractional scaling and at least in sway there wasn't a way to fix it or much appetite to implement it. It's great to see it is mostly in place now and just needs to be enabled by all the stack.

Seems like the support is getting there. I just checked Firefox and it has landed the code but still has it disabled by default. Most users that set 1.5x on their session are probably still getting needless scaling but hopefully that won't last too long.

That's what I referred to with "we'll be finally getting that in Wayland now". For many years the Wayland protocol could only communicate integer scale factors to clients. If you asked for 1.5 what the compositors did was ask all the clients to render at 2x at a suitably fake size and then scale that to the final output resolution. That's still mostly the case in what's shipping right now I believe. And even in integer scaling things like events are sent to clients in virtual coordinates instead of just going "here's your NxM buffer, all events are in those physical coordinates, all scaling is just metadata I give you to do whatever you want with". There were practical reasons to do that in the beginning for backwards compatibility but the actual direct scaling is having to be retrofitted now. I'll be really happy when I can just set 1.3 scaling in sway and have that just mean that sway tells Firefox that 1.3 is the scale factor and just gets back the final buffer that doesn't need any transformations. I haven't checked very recently but it wasn't possible not too long ago. If it is now I'll be a happy camper and need to upgrade some software versions.

Originally OS X defaulted to drawing at 2x scale without any scaling down because the hardware was designed to have the right number of pixels for 2x scale.

That's an interesting related discussion. The idea that there is a physically correct 2x scale and fractional scaling is a tradeoff is not necessarily correct. First because different users will want to place the same monitor at different distances from their eyes, or have different eyesight, or a myriad other differences. So the ideal scaling factor for the same physical device depends on the user and the setup. But more importantly because having integer scaling be sharp and snapped to pixels and fractional scaling a tradeoff is mostly a software limitation. GUI toolkits can still place all ther UI at pixel boundaries even if you give them a target scaling of 1.785. They do need extra logic to do that and most can't. But in a weird twist of destiny the most used app these days is the browser and the rendering engines are designed to output at arbitrary factors natively and in most cases can't because the windowing system forces these extra transforms on them. 3D engines are another example, where they can output whatever arbitrary resolution is needed but aren't allowed to. Most games can probably get around that in some kind of fullscreen mode that bypasses the scaling.

I think we've mostly ignored these issues because computers are so fast and monitors have gotten so high resolution that the significant performance penalty (2x easily) and introduced blurryness mostly goes unnoticed.

Take a look at this HiDPI rendering example in Leopard

That's a really cool example, thanks. At one point Ubuntu's Unity had a fake fractional scaling slider that just used integer scaling plus font size changes for the intermediate levels. That mostly works very well from the point of view of the user. Because of the current limitations in Wayland I mostly do that still manually. It works great for single monitor and can work for multiple monitors if the scaling factors work out because the font scaling is universal and not per output.

That's probably better than most scaling done on Wayland today because it's doing the rendering directly at the target resolution instead of doing the "draw at 2x scale and then scale down" dance that was popularized by OSX and copied by Linux. If you do it that way you both lose performance and get blurry output. The only corner case a compositor needs to cover is when a client is straddling two outputs. And even in that case you can render at the higher size and get perfect output in one output and the same downside in blurryness in the other, so it's still strictly better.

It's strange that Wayland didn't do it this way from the start given its philosophy of delegating most things to the clients. All you really need to do arbitrary scaling is tell apps "you're rendering to a MxN pixel buffer and as a hint the scaling factor of the output you'll be composited to is X.Y". After that the client can handle events in real coordinates and scale in the best way possible for its particular context. For a browser, PDF viewer or image processing app that can render at arbitrary resolutions not being able to do that is very frustrating if you want good quality and performance. Hopefully we'll be finally getting that in Wayland now.

Wouldn't that need a huge amount of extra hardware to do that filtering when the routers in each customer's home are mostly idle? Just setting egress filtering as the default and letting users override that if they need to for some reason should be a good outcome. The few that do change the default hopefully know what they are doing and won't end up part of a DDoS but they'll be few anyway so the impact will still be small.

You've now ignored the simulations others have done, after insisting on those repeatedly, and have started making your own to again conclude solar and wind must not be viable and nuclear necessary. Meanwhile I'm still waiting on any kind of study that says nuclear can be built at anything approaching a viable cost. This is not a reasonable way to discuss something.

No I'm not, I have no idea how you are getting that idea. I'm asking for an analysis showing that Minnesota's winter needs can be met without building nuclear plants. That's it. You can solve that problem in any way you like, including importing power from other states and nations.

If that's your assumption then this is a non issue. Minnesota is currently less than 2% of total winter electricity demand in the US. Lets be pessimistic and assume that because it needs more heating in winter than average those 2% become 5% with electrification of heating nationwide. Even if 100% of that electricity needed to be imported from other states that's still a very small amount of the total. You could import all that solar and wind energy from other states if you can't produce any at all locally. The scenario is obviously much better than that, you'd only need to cover the shortfall which is what already naturally happens in joint grids all over the world.

Meanwhile, nuclear is here now, and it works. I don't think we should be betting our future on unproven tech.

I'm still waiting for a link that shows that nuclear can be built at anything approaching reasonable cost. In all these discussions that's always presented as a given and then all the discussion is on the shortfalls of renewables. Meanwhile the actual reality on the ground is that the renewable roll-out is rising exponentially and nuclear projects are practically non existant.

I don't know what a "nuclear roll-out simulation" is, exactly.

Any simulation where building nuclear power plants makes economic sense would do.

I'm unconvinced that renewables+storage alone can solve the Minnesota winter problem.

You're again asking for simulations about Minnesota specifically which doesn't make sense. Unless you're thinking of seceding from the union and closing the borders to energy trade, as long as the US as a whole can do it Minnesota in particular can be a net energy importer in winter if that's what's needed. Here's the RethinkX simulation of that:

https://www.tonyseba.com/wp-content/uploads/2020/11/Rethinki...

"Our analysis makes severely constraining assumptions, and by extrapolating our results from California, Texas, and New England to the entire country we find that the continental United States as a whole could achieve 100% clean electricity from solar PV, onshore wind power, and lithium-ion batteries by 2030 for a capital investment of less than $2 trillion, with an average system electricity cost nationwide of under 3 cents per kilowatt-hour if 50% or more of the system’s super power is utilized."

This is almost 5 years old at this point. Others have linked other such analysis. At this point asking people to show them simulations for renewables while trying to argue for nuclear is disingenuous. Renewables are the ones being built out at scale all over the world while nuclear struggles to deliver new projects and doesn't seem to have a viable path to being cheap.

You're again talking about simulating only Minnesota I suspect. If you want a realistic simulation there are others in the thread and RethinkX has had a whole-US simulation for a long time. What I've never seen is a nuclear roll-out simulation that argues that's a good option. Do you have one of those?

I'm confused. Who has agreed that solar+wind is off the table? Approximately no one has effectively decided nuclear is the right answer for a long time. If the proof is in what the market is actually building, solar and wind are the winners by huge margins.

What's commonly done in these arguments, and you did some of that, is declare that from first principles nuclear is the solution and we aren't only doing it for other reasons. Yet while there are plenty of simulations of doing full grids with only solar, wind and batteries there's never one where a full nuclear roll-out actually makes sense economically.

Canada isn't small, it produces almost 10x the electrical energy that Minnesota does. But I wasn't even giving it as an example of total capacity just of a neighbor that has a bunch of hydro that can be useful in some moments. And it works both ways too. When Minnesota has excess wind Canada can benefit. The same exercise needs to be modelled with all demand and capacity within viable transmission range. And with the advancements in HVDC that range keeps increasing.

Why would you model Minnesota specifically when that state is part of a larger region that can tradeoff power over time? Canada's hydro is much more "here" than the hypothetical new nuclear plants Minnesota would have to build.

Splitting up the world in areas and then claiming you need to solve a different problem in each is throwing away probably the most cost effective way to get cheaper energy, more grid interconnection and more price mechanisms to shape supply and demand.