Pixi is very focused on the Conda ecosystem and implements a sort of bridge across the Conda and PyPI ecosystems. I am very interested in solving the problems that motivated creation of the Conda ecosystem, but I want to do so by driving forward the PyPI ecosystem so those use-cases can be addressed in _many_ tools instead of just one. This is the main reason you don't see us pursuing Conda package support in uv directly (in the style of Pixi).
There have been several threads about us collaborating or converging, but there are no concrete plans to do so at this time. We share some Rust crates, e.g., Pixi uses our internals to solve the PyPI-side of their dependencies, and we occasionally fix or change things for each other.
I lived in a house built around 1605 in the Netherlands, with some of the windows being hundreds of years old, based on expert opinion. The glass had started to droop downward in certain places, almost like the resin you see in trees. It made me realize that glass is not as rigid as I thought.
I think that glass flowing thing is a myth. The manufacturing method back then resulted in uneven panes and they were installed with the thicker side at the bottom.
I'm not entirely convinced it is a myth, but the practical effect surely is.
I do suspect that over insanely long periods an otherwise undisturbed physical object would flow-sag at some rate under the influence of a constant force in a given direction.
No idea how long that would take, but erosion and other destructive forces appear to dominate so for practical measures any such effect is likely against the noise floor.
It's an amorphous solid last time I dove into this.
The "well it's technically a liquid!" because it "flows" is really not telling the whole story. Like most science, it's just more complex than can be quickly summarized with one sentence, and doesn't quite map to just high school simplifications.
That’s a misconception. Glass does not flow over time; it is a rigid, amorphous solid.
The uneven thickness seen in old cathedral windows is a result of historical manufacturing. Glass was spun into discs that naturally became thicker at the edges, and builders installed the heavier side at the bottom for stability. Physicists calculate that it would take longer than the age of the universe for room-temperature window glass to visibly deform under gravity.
Reference: Zanotto, E. D. (1998). "Do cathedral glasses flow?" American Journal of Physics, https://doi.org/10.1119/1.19026
> That’s a misconception. Glass does not flow over time;...Physicists calculate that it would take longer than the age of the universe for room-temperature window glass to visibly deform under gravity.
so then it does flow over time, just not on a scale where it matters to us.
But this is true for lots of solids, not just glass. Consider creep deformation [0] which is deformation mediated by diffusion of defects in solid materials. It’s a big problem in metal turbine blades, it limits the maximum usable temperature to well below the melting point.
The physical mechanism would be similar in glass flowing in this way, so I don’t think evidence of glass flowing like this should make us think of it as a liquid instead of an amorphous solid
How do you go from “calculate that it would take longer than the age of the universe for room-temperature window glass to visibly deform” to “so the. It does flow”?
Glass flows a higher temperatures where it does act like a liquid, you can study glass blowing for examples, however no, room temperature glass is not a liquid and does not flow, for any practical definition of what flowing is.
I'm building in robotics. Setting up a new 3d camera today. I found that the 10m active USB C cable that I bought transfers power in both directions, but only transfers data in one direction, it turns out to be some weird video USB variant. Next I needed to plug a gripper into a modbus controller. That uses an M8 8-pole 20cm cable. The controller manufacturer recently decided to switch from male to female connector, so now the cable needs to be male-male. After searching online for hours, I believe that is impossible to find as everyone only sells male-female cables.
I'm continuously surprised by how difficult it is to plug things together and how non-descriptive cable "standards" are about the actual capabilities of cables and connectors.
I've recently been modernizing an old milling machine, and learned that for most types making your own cables is not that hard. The one painful thing is that there are a zillion tools involved for the different types of crimps and terminations.
Is there anything like a linter to force you to stay within some subset of c++? I like the language, but it is hard to avoid language constructs that are outdated or enforce a single (or a few) ways of doing things. A c++ subset could be nice.
Nuclear is surprisingly expensive and solar/wind/storage is surprisingly cheap. Even solar in the UK has better economics than nuclear, and it has no shortage of wind.
Unless there is a shortage of wind on a given day/week/month. Then the cheapness is no longer surprising ― you are literally paying only what it costs to provide the electricity now, not at any point in the future.
Maybe the guarantee of 24/7 supply is actually worth something?
The outcome of Contracts for Difference (CfD) Allocation Round 6 suggests wind isn't cheap compared to wholesale electricity prices in the UK, which are already one of the highest in the world. The maths is quite simple.
And that doesn't include curtailment costs, which are not insignificant.
The average strike price for offshore wind in AR6 came in at £59.90/MWh. That's pretty cheap, and much cheaper than any new nuclear. Hinkley Point C's strike price is £92.50/MWh. (note: strike prices are always quoted based on 2012 currency, and get adjusted for inflation)
You can't really compare strike prices to spot prices on the wholesale market precisely because there's so much supply under CfD contracts, which distorts the wholesale market. When supply is abundant, the wholesale price plummets and even goes negative, yet suppliers still want to generate because they get the CfD price. When supply is constrained (eg: cold snaps in winter with little wind), the spot price can surge to £1000/MWh.
In 2024 money offshore was £102 offshore, onshore £89. AR7 estimates are >10% higher. Those prices were not high enough for Hornsea 4, who cancelled the contract (with a big write down for the entire project) after being awarded it.
Yes, like I said, UK CfD strike prices (both nuclear and wind) are always quoted in 2012 prices.
But even adjusting for inflation, offshore wind's £59.90 is a fraction of the retail price that UK consumers and most businesses pay for electricity. There's plenty of margin left for the middlemen (regulator, grid operator, distribution network operator, electricity retailer, etc).
... and Hinkley Point C's £92.50 is £133.79 today, and could be £160+ by the time it actually starts generating in (maybe?) 2031.
The goal of automation is not necessarily reduce personnel, it could be increased reliability, reduced risk to life, reducing waste from scraps, faster lead time, etc
Do you have some references for the pick and place and other reconfiguration things you mentioned. I've been out of this space for a while but last I checked these were still incredibly challenging things to get right.
I'd also like more comprehensive write-ups on such topics but either I haven't found the right sources yet or all the people who know how to set up and keep modern fabrication infrastructure going are too busy raking in the cash and making stuff. ^^
If you like visual media, the "Strange Parts" YouTube channel is an interesting source for glimpses into modern, mostly Chinese factories: https://www.youtube.com/@StrangeParts/
Since you're asking about pick and place specifically, https://www.opulo.io/ is an interesting example of how far/cheap you can push such machinery (and the design in and of itself is interesting from a manufacturing point of view). Not all that relevant from a mass-production point of view, though.
No amount of fine-tuning can prevent models from doing anything. All it can do is reduce the likelihood of exploits happening, while also increasing the surprise factor when they inevitably do. This is a fundamental limitation.
They're different. Most programs can in principle be proven "correct" -- that is, given some spec describing how it's allowed to behave, it can either be proven that the program will conform to the spec every time it is run, or a counterexample can be produced.
(In practice, it's extremely difficult both (a) to write a usefully precise and correct spec for a useful-size program, and (b) to check that the program conforms to it. But small, partial specs like "The program always terminates instead of running forever" can often be checked nowadays on many realistic-size programs.)
I don't know any way to make a similar guarantee regarding what comes out of an LLM as a function of its input (other than in trivial ways, by restricting its sample space -- e.g., you can make an LLM always use words of 4 letters or less simply by filtering out all the other words). That doesn't mean nobody knows -- but anybody who does know could make a trillion dollars quite quickly, but only if they ship before someone else figures it out, so if someone does know then we'd probably be looking at it already.
AI can't distinguish between user prompts and malicious data, until that fundamental issue is fixed no amount of mysql_real_secure_prompt will get you anywhere, we had that exact issue with sql injection attacks ages ago.
I have a background in program analysis, but I'm less familiar with the kind of kernels you are optimising.
- Can you give some more insight on why 12 ops suffice for representing your input program?
- With such a small number of ops, isn't your search space full of repeat patterns? I understand the will to have no predefined heuristics, but it seems that learning some heuristics/patterns would massively help reduce the space.
we're just optimizing linear algebra, which is mostly made up of patterns of simple ops. for instance, matmul is just broadcasted multiply -> sum reduce.
the search does common subexpression elimination by default. if two patterns are unioned in the search space, it applies that union to every occurrence of that pattern at the same time, so using e-graphs it helps keep the search space smaller.
ah i see the confusion. we do common subexpression elimination of the terms in the search space (which allows single application of rewrites to apply to many repeat patterns) but the search can choose to re-use patterns of terms when we extract dags after the search space is built. so various levels of recomputation are searched.
right now since we're profiling kernels, and we have a reference output of the unoptimised version, we can directly measure deviation of profiled outputs "for free" since we're already computing them for runtime. tbh this isn't what i want long term, i want to bake numerical stability natively into the search space to only extract dags that would produce stable outputs. hopefully that'll be solved soon.
This heavily depends on share classes and preferences. Surely the new investor wants better terms. The issue isn't so much dilution as a preference but added risk of never even getting a payout at all.
Follow up: has anyone suggested the projects collaborate or eventually converge?