This looks super fun.
Edit: I'm loving the explosion-revenge last-ditch effort to counterstrike when hit. Fantastic concept.
I just noticed there's Orbit Outlaws[2] from the same developer, which builds on the same concept (for better or worse), but is also abandoned.
[1]: https://store.steampowered.com/app/426930/Moonshot/
[2]: https://store.steampowered.com/app/1319100/Orbit_Outlaws/
I see what you did here.
The desktop marketshare of the various platforms hasn’t fundamentally shifted since then. Mobile was all additive, and Microsoft lost it. But Mac and Linux remain roughly where they were.
https://gs.statcounter.com/os-market-share/desktop/worldwide...
Today we see a rise of ARM on desktops, developing for x86 excludes Mac users, but the situation moves in a direction when exclusive x86 software will exclude an assortment of users of different OSes who chose to buy ARM desktop/laptop.
But I completely understand the choice made by the author, to use vector extensions on two (or three? RISC-V?) processors would be a much more additional work. The project is FOSS so anyone can jump in and add support for ARM vector extensions. Hopefully it will be easier then to write it from scratch, because you can compare intermediate results bit to bit, and catch mistakes red handed.
https://github.com/pavelsevecek/OpenSPH
includes an old Debian package you can install (although for Debian 10, and doesn't work on recent Ubuntu/Mint installs either)...
source: https://github.com/pavelsevecek/OpenSPH/graphs/contributors
The graph on the chart I shared suggests that the peak of contributions was a couple of years ago, with occasional changes since then. This doesn’t make much sense to me, as the rendering quality looks great (at least in the videos—I’ll try the software a bit later), and it’s head and shoulders above what the scientific community is currently using.
Based on my experience (both personal and from colleagues), when a project is not in active development, the team starts losing knowledge of the codebase along with its context. For example, something that was at your fingertips while actively working on the project would be much more difficult to recall after a year. The difficulty of maintaining or extending the project grows over time if it is not actively worked on.
‘Stalled’ = contributions become less and less frequent.
If a project has stalled, there isn’t much new happening. For a simulation like this, the sky is the limit—you can make it as accurate as possible (e.g., accounting for light pressure - esp. significant around blackhole acceleration disk, the Yarkovsky effect, etc.)
The first is that different types of rendering have different uses; typically in scientific visualization this is broken down into essentially "viz for self, viz for peers, viz for others" and oftentimes the most well-used rendering engines are targeted squarely at the first and second categories. The visual language in those categories is qualitatively different than that used for more "outward facing" renderings.
The second reason is that I disagree with your assertion about the quality of the visualization techniques in use within science. There are some truly spectacular visualization engines for cosmology and galaxy formation -- just to pick two examples off the top of my head, the work done by Ralf Kaehler or that by Dylan Nelson. (There are many really good examples, however, and I feel guilty not mentioning more.)
As I said in another, rather terse and unelaborated comment, though, this is really, really impressive work. I think it's important that in praising it, however, we don't discount the work that's been done elsewhere. This need not be zero-sum.
Regarding the work of Ralf Kaehler: I have seen his renderings and looked through his articles, but to the best of my knowledge, no source code is publicly available. I don’t consider it fair to count it as something actively used in the field, beyond his lab and affiliated projects.
Disclaimer: that doesn't mean that there are no others, but their availability to researchers is limited to be widely spread.
The bullshit amounts of churn-for-the-sake-of-it in the JavaScript ecosystem aren't normal.
Regarding the JavaScript ecosystem—I never mentioned it. Replacing one tool with another has nothing to do with the evolution of a single project.
Just months? :D Last week, a hobby project took down various unrelated services on my server (like receiving email) by causing disk space to suddenly fill up. The root cause is bad handling of an expired third-party domain. I had last touched that in 2012!
Or the grocery list software I use daily: its main activity period is probably 2015 through 2018, with features/bugfixes being added maybe once every 2-3 years nowadays. Back in September that I added a small feature we now use on most grocery trips, but since it gets daily use by the developer, it's not like it's unsupported
One of my few projects that has regular users besides family is a ~2013 rewrite of a 2011 file uploader. Sometimes there is over a year between any change at all, but whenever someone came along with a bug report I think the fix was never more than a few days away. Come to think of it, it was just today that a friend reported being happy that I still provide it
Although stalled perhaps isn't inaccurate, I would feel that it gives the wrong vibe if someone used that to described these daily-used projects where the bug reporting method pops a silent notification on my phone and I'm acting upon any. No offense to u/apetrov, I get what they meant when reading their subsequent replies elsewhere in the subthread
now i'm waiting for the suggestions to use -rf
N=${N:-} # if you use (-u)
$N rm ./whatever
N=echo ./something-dangerous
Or can anyone on HN give me any hints on a valid flow chart
Although at this point they are more likely to call it science fiction because they all know the earth is flat.