typing in 'rm' in any script I write scares the bejeebus out of me. I tend to write 'echo rm' so I get a chance to review while testing to catch this specific type of issue.
Instead of deleting anything, my scripts usually mv files to a timestamped folder under /tmp. In practical terms, it’s rarely a noticeable difference in performance or disk usage. Also makes scripts easier to debug when you can inspect transient artifacts.
I manage large video/audio assets, so disk usage is very noticeable. I've done the mv to a designated trash folder with another script that finds files in that folder older than designated time to live and then -exec rm -f {} \; type of stuff. Even typing that out still gives me pause. Nobody ever needs a file with such urgency as just 24 hours after it was deleted, but not in the designated time out window.
My workstation machines take hourly(+at boot+on demand) snapshots of the filesystem. Doing it on the system level is a lot simpler than repeating the logic over and over, and /tmp is often a different mount then where the files first resided so moving things over there is a copy+delete.
In case you're interested, I have adopted a pattern that works for me in bash (I don't use zsh so caveat shellator)
N=${N:-} # if you use (-u)
$N rm ./whatever
and then you can exercise the script via
N=echo ./something-dangerous
but without the N defined it will run it as expected. More nuanced commands (e.g. rsync --delete --dry-run which will provide a lot more detail about what it thinks it is going to do) could be written as `rsync --delete ${N:+--dry-run}` type deal
Can use -i to confirm deletions also, to not have to edit and re-do the command. The downside is being asked for everything individually rather than confirming one (big) list, so not sure if this fits your use-case
It would be fun if we could define planets with our own materials, like bananas (influenced by xkcd), diamonds or whatever other silly substance we like :-)
very very cool, its also so rare these days to see the scientific crowd bother building windows installers, now people whose only skillset is using microsoft word and cheating in games can get a glimpse of what modern compute is capable of, hopefully inspire some of them to think beyond badly formatted text documents.
Although at this point they are more likely to call it science fiction because they all know the earth is flat.
Looks great, but GitHub metrics indicate that, unfortunately, the project has stalled. The last commit was six months ago on master and two months ago on develop.
Yes, I don’t question the usefulness of the project by any means. To be frank, I’m personally very interested in it—I studied celestial mechanics at university many years ago and am still curious about simulations.
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.
I don't think that it's fair to compare the rendering to what is currently in use in the scientific community, for two main reasons:
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.
I don’t mean to discount any other work. I have already disclaimed that I don’t work in academia and rely on second-hand feedback from my classmates (in Europe)—for example, the Fortran implementation of Yoshida’s method from N years ago that nobody could modify, or the pressure for publication. Building (or learning) a new rendering engine would be a losing strategy in an academic career, as it is a much more difficult path to getting published. There are far fewer postdoc positions than PhD positions, and rendering skills won’t help in this competition.
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.
You can't imagine that someone working on something like this would slow down as the work neared completion? Why must a piece of software / code constantly be changing? What's your specific concern? You're making a very strong claim that the "project has stalled" without any real evidence. Furthermore, the project "stalling" makes it less... what, exactly?
Yes, I can imagine multiple reasons why an author might decide to change their pace for whatever reason. my observation was that it changed.
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.)
I dunno, I have active hobby projects that go weeks to months without commits. Sometimes you need to experiment with things for a while to get a feel for whether or not it should be committed. Sometimes you need to take a break.
The bullshit amounts of churn-for-the-sake-of-it in the JavaScript ecosystem aren't normal.
It depends on the complexity of the project. I assumed something nontrivial, like this project. I outlined some thoughts on the effects of consistent development and what the project might become in a comment above (current state vs. becoming a go-to visualization tool in the field for years to come).
Regarding the JavaScript ecosystem—I never mentioned it. Replacing one tool with another has nothing to do with the evolution of a single project.
> hobby projects that go weeks to months without commits
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
Developing for a single platform in 2025 is like developing for a single platform in 2005, if you don’t care about mobile.
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.
I believe, that the GP comment is too dismissive, but it is true. In 2005 when the dominance of IE started to dissolve it was not the best move to develop for a single browser. Though people still did it.
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.
reply