This is a great update! I hope the authors continue publishing new versions of their plots as the community builds up towards facility gain. It's hard to keep track of all the experiments going on around the world, and normalizing all the results into the same plot space (even wrt. just triple product / Lawson criteria) is actually tricky for various reasons and takes dedicated time.
Somewhat relevant, folks here might also be interested in a whitepaper we recently put up on arXiv that describes what we are doing at Pacific Fusion: https://arxiv.org/abs/2504.10680
Section 1 in particular gives some extra high-level context that might be useful to have while reading Sam and Scott's update, and the rest of the paper should also be a good introduction to the various subsystems that make up a high-yield fusion demonstration system (albeit focused on pulser-driven inertial fusion).
Cool. To be totally honest, I'd feel a lot better if we could just extend robots.txt especially given that we finally have a standard for it with IETF RFC 9309: https://datatracker.ietf.org/doc/html/rfc9309
Also might be worth looking at llms.txt (https://github.com/AnswerDotAI/llms-txt), though it's aimed to be more of an agent-friendly sitemap.xml alternative.
I imagine you must be talking primarily about single services, but the question is primarily focused on the sort of necessary infrastructure that is required to build some kind of intranet for developers.
The micromanagement task in StarCraft Broodwar (with TorchCraft) that has been used by a few people already in the past year to do some RL research has been tackled basically only with #units > 1, because getting a balanced 1v1 is possible only with certain combination of units, and it's indeed pointless otherwise.
Kiting is maybe a notable exception, but it is also restricted to a relatively small group of unit matchups.
@wfunction: yes, TorchCraft includes a serializer that compresses the useful game state into a relatively small struct. That is then further compressed with other tricks and zstd.
>It is a very dangerous idea to seek a fairier distribution of wealth by taking it from the rich. If you doubt it go ask Venezuelans or Cubans if it worked out for them.
FYI most countries already do this in the form of somewhat progressive taxation. Some however do this more than the US (say, the great majority of Europe), and they do pretty much fine.
I also don't see how this is "dangerous". For who, the general population? The socio-economical system? The environment?
A lot of research done in Microsoft Research is blue skies research that has nothing to do with MSFT's goals. Hell, MSR for the past decade has set the example for open research in industry-controlled labs, so I would have been surprised if MSFT hadn't already started sponsoring theoretical research in STEM subjects.
(This doesn't justify a lot of the crap that MSFT and other tech corps have done to our industry over the years, but we should give credit where it's due)
We can reasonably assume it's nothing more complicated than what you can do using a combination of machine learning libraries and OpenCV (however if they have instead some new technique, I hope to find a paper from them in a few months :) ).
EDIT: Adding more details.
If you are looking for similar ideas, you should read papers in the area of object-class segmentation / classification[0][1][2], and generic supervised learning.
To add more generic info, as it is shown in the video we have quite a few prototypes and we are now working on the final design of each piece of hardware (including the control board).
Because in Europe the belief that important and wide research should be carried out by "public" research is much stronger than, say, USA. Also while we have seen a somewhat invading process of privatisations ( :( ), European universities are still largely owned publicly and financed via public funding, therefore most [public] moeny for research should and will be directed to them for the time being.
You could then argue that it's not as efficient as the VC model, but:
- I haven't seen any study confirming such thing
- It doesn't seem easy to achieve a reasonable compromise between open research and R&D protectionism unless you are a big company
- Academia, even with all its politics and problems, is still a fast and active environment for scientific research
Currently the most used and supported framework is ROS[1][2], so I don't really see myself using this framework for either research or my hobby projects unless they implement an interface to talk and live with ROS itself...
As the top commenter said, the problems do not end with choosing a good editor and fixing its display methodology. Git and many other VCSs create noisy diffs whenever space is added and forgotten, which ultimately complicates the life of developers that want to review changes.
Even if your editor were able to make display diffs in a clean way, you would still have a dirty history when for instance using less/more or other tools (not to mention the merging issues problem).
Emacs AFAIK can do all those things, with different degrees of integration depending on the language. For pure C, for instance, Emacs has always been the "IDE" of choice for years in UNIX(ish) environments. Thanks to Clang C++ is now covered too. For Lisp languages there is simply no other option. Even scripting languages like Python, Perl and Ruby have all got fantastic integration, and their modes keep getting better and better because of their open source nature, adding semantic analysis and tools integration.
The package manager makes it really easy to automatise installation and updates.
Sure, its learning curve is unusually high and Elisp knowledge is required for some edge cases, but it's definitely worth in the medium and the long run.
Evolution is pretty much a brute-force solution to a really hard problem (survival over a ever-changing environment), while we humans should be capable to come up with different strategies and optimizations to solve problems, which means that we may just able to get more benefits from a equal and fair society ultimately.
Somewhat relevant, folks here might also be interested in a whitepaper we recently put up on arXiv that describes what we are doing at Pacific Fusion: https://arxiv.org/abs/2504.10680
Section 1 in particular gives some extra high-level context that might be useful to have while reading Sam and Scott's update, and the rest of the paper should also be a good introduction to the various subsystems that make up a high-yield fusion demonstration system (albeit focused on pulser-driven inertial fusion).