We're saying the same thing -- one radioastron satellite isn't enough, you'd need a constellation of them.
HN user
privong
How about putting our astronomy experiments into space as well? There'd be no light / em pollution there, as well as no atmospheric interference etc.
One would need to put the telescopes into fairly high orbits in order to avoid the interference. I think that even images made with the Hubble space telescope have sometimes seen the impact of satellite constellations.
In space there are no limits, see Radioastron for example, and that was decades ago.
Radioastron required cross-correlating the signal with ground-based radio teleacopes in order to do science. The collecting area, dish distributons, etc. would need to be fully replicated in space if one wanted to avoid using ground-based facilities entirely.
There's at least two issues with this line of thinking:
1. many astronomical observations are long integrations (many minutes of open shutter) and you often cannot read out the pixels during the exposure. So you can't selectively ignore pixels on a "by moment" basis. And with enough satellites, enough pixels could be affected to render an entire image effectively unusable
2. It seems you're thinking only about optical astronomy. There's also a ton of radio/millimeter wave astronomy that's done from the ground. Satellites have radio-wave downlinks that can be powerful enough to destroy the electronics used in radio astronomy receivers. The US's National Radio Astronomy Observatory has been working on data sharing with Starlink to mitigate this, but it's basically up to companies to agree to work together. Other satellites / companies don't engage in this coordination and so some radio telescopes need to go to a "safe"/stow position to protect the electronics. This costs valuable observing time.
Can you elaborate on how this is doable (in, say, Racket) and what tooling is needed? I'm afraid your reply doesn't add much information beyond the same assertion that I quoted that was in the article posted to HN. And I haven't been able to find information on this with Racket.
That could very well be it. I guess I had gotten my hopes up, seeing the statement in a piece that purported to be specifically about Scheme .
You can pause, inspect objects, change values, and even redefine a broken function on the fly to test a fix in any environment (yes even in production, while running).
I see this mentioned often, and it sounds amazingly useful (especially the part about fixing in production!). But how truly widespread is it among the Lisp dialects to be able to connect to a running program, debug, and hotfix it? I understand Common Lisp has it, but I struggled to figure out how to do it in, say, Racket. Admittedly I'm am relatively inexperienced Lisp programmer, so maybe I wasn't looking in the right place or for the right words. Which Lisp dialects do indeed support the extreme version of this capability to inspect and edit running programs?
In fact, relativity was only recently fully backed up with experimental data.
Can you elaborate on the assertion you made here? In addition to the important points @elbasti made about tests performed approximately a century ago, what does it even mean for a scientific theory to be "fully backed up"? Such theories can be tested and the tests either passed or the theory disproven but it's not possible to _prove_ such a theory. And to some extent we already know that relativity cannot be the final answer because it doesn't mesh well with quantum mechanics (which has been experimentally tested substantially, arguably even more than relativity has).
There is a mission concept for a far-infrared interferometer: https://asd.gsfc.nasa.gov/spice/
One would need to go to space for that of course.
I don't use it often, but have you tried the Wikipedia current events portal? A reading of their brief daily summaries from the past week might be close to what you're looking for.
Why copy and paste text from the article without adding any commentary?
Open access publishing is the new business model that is more lucrative for publishing industry and it is basically a tax on research activities but paid to private entities and mostly paid by taxpayer money
In addition to what @tokai said, I think it's also important to keep in mind that before Open Access the journal publishers charged subscription fees. The subscription fees were paid by universities and that was also likely largely taxpayer funded (e.g., using money from overheads charged to grants).
To save folks a search:
github repo: https://github.com/lexi-lambda/hackett
Documentation: https://lexi-lambda.github.io/hackett/
I thought the same thing too, when it was announced. But I suspect, in addition to the price, that not being able to buy a medium or long bed version also harmed fleet sales. The short bed being the only option is probably a pretty big limitation for groups who are buying them as fleet vehicles.
I was thinking about employee-facing tools, but I agree that TUIs present an even bigger challenge for casual users / customers.
An interesting theme here in the comments (that I am sympathetic to) is "TUIs have steep learning curves but are fast/efficient for people with proficiency". I wonder if a small part of the modern preference for GUIs is related to a lack of employee retention. If companies aren't necessarily interested in working hard to keep employees then training new hires needs to be faster/easier and that could work against TUI and keyboard-based tools.
Of course, if that's a factor I'm guessing it's a small one in comparison to expectations about what "modern" software should look like.
@sharweek said > Some of his writing often covered what just a slight altering of our societal moral compass might look like.
@JKCalhoun > in my world-view most humans want to be kind.
These two views aren't necessarily in conflict. Individuals can overwhelmingly want to be kind but still be in a system where society pushes them to behave to the contrary.
Oops, thanks. Too late to edit, unfortunately.
It could partly be that, but I've generally read that the default inks are not waterproof.
I was curious about this so I just did a quick non-scientific perusal of one fountain pen enthusiast shop's offerings. It shows 118 of the ink bottles they sell are water-resistant ink while 935 are not (looking at the Yes/No filter counts for "Water-resistant" at https://www.gouletpens.com/collections/bottled-ink). There's a lot of duplicate inks that can be purchased in multiple bottle sizes, but picking the three most represented bottle volumes (20ml, 30ml, and 50ml) it drops to 24 water-resistant inks and 578 inks that are not water-resistant.
The above includes a lot of "interesting" colors; further restricting to black ink only ends up with 3 that are water-resistant and 26 that are not.
Left-to-right writing as a left-handed person involves a lot of pen(cil) pushing, which is a big no-go for fountain pens.
If it works for you, I'm willing to bet you're twisting your hand in a D position (going over and around the cursor), which I sometimes see left-handed people do. I have cramps just watching that.
I see comments like this occasionally and find it mildly amusing as a lefty who has been writing with a fountain pen for over a decade and doesn't have noticeably different hand position (either compared to righties or compared to my use of a pencil or ballpoint pen). Yes, some lefties do have hand positions that look incredibly uncomfortable and some lefties have trouble with fountain pens, but that doesn't mean it's a general/total non-starter for lefties to successfully/comfortably use a fountain pen.
Pen pushing is a problem if a writer used to a ballpoint pen or a hard pencil and needing to apply pressure to get ink to flow and applies that much pressure to a fountain pen. But once one makes the adjustment to a fountain pen's (low) pressure style, pushing is only a minor annoyance for fountain pen writing until the nib is broken in (at least that was my experience).
As others have said, it's also important to pick the right ink/pen/paper combination so that you're not laying down too much ink and so that it dries reasonably quickly.
If you turned in an assignment written in pencil, it was legit for the teacher to use their eraser and give you an F for turning in empty paper. (They never did this but threatened it a lot).
I find this slightly amusing/ironic because many (most?) fountain pen inks are not waterproof. I had a sheet of paper that was full of (fountain pen written) writing on my desk when I spilled a glass of water -- after the paper dried there was hardly any evidence that there had been writing on the paper. I know that's not the parent's point, but something turned in that was written with a fountain pen would be easier to remove: a teacher would just need to dunk the paper in water!
Radio astronomy was an accidental offshoot of this project: they noticed the reflected microwave signals from space came back with some extra noise...
Perhaps you're conflating Project Echo with Karl Janksy's Bell Labs research in the 1930s? Radio astronomy's "birth" is probably best set to when Jansky detected radio emission from the Milky Way in 1932-1933 while trying to identify the source of noise in wireless telephone transmissions.
Grote Reber picked up radio astronomy in the pre-war (WWII) years and then the advancement of RF technology for radar during WWII led to some further discoveries (e.g., radio emission from the Sun). After WWII, radio astronomy initially had good participation from radar folks.
Many national radio observatories were already in existence before Project Echo. Jodrell Bank Observatory (UK) was established in 1945. ASTRON (Netherlands Institute for Radio Astronomy) was founded in 1949. The US's Green Bank Observatory was created in 1956 and this led to the creation of the National Radio Astronomy Observatory in 1959. Parkes, in Australia, was completed by 1961.
Radio astronomy was well under way before Project Echo.
Active discussion here: https://news.ycombinator.com/item?id=44702782
Does this project have some relation to LFE?
Can you clarify what "LFE" stands for? Do you mean "Lisp Flavored Erlang" or something else?
Indeed; Yggdrasil is also the name of a set of models of the emission from stellar populations:
Unfortunately that comes with the baggage of terrible memory safety.
Isn't this unrelated to the parent post's thoughts about the benefit's of the C/C++ ecosystem (or lack thereof) for dependency management? I.e., a Rust-like language could still exist with a dependency management system similar to what C/C++ have now -- that isn't predicated on how the language handles memory.
"Hieroglyph" [0] was an attempt to address this and write positive science fiction. It was a project at ASU and a book[1] of short stories accompanied by a webpage with essays describing the genesis of the stories and responses to the stories. The book included pieces by Doctorow, Neal Stephenson, Bruce Sterling, and others.
I heard about it late last year and picked up a used copy. I ended up reading about 2/3 of the stories and, 10 years after the book's publication, my general feeling was:
1. The stories are overwhelmingly positive and sometimes compelling. But a decade later, the real-life uses of most of the technologies used a plot devices has fallen short of the aspirations in the stories. Reading the stories left me with a feeling of disappointment, seeing that we as a society opted to use most of the technologies in more negative ways (mass surveillance, continued indifference to the amount of carbon we are dumping into the atmosphere, etc.). As a result the stories also felt very naive.
2. The book contains copious links to essays that are hosted on the webpage [0]. They are all gone now; from what I can tell, none of the essays are available at the original URLs. There are also no redirects. The essays have disappeared.
I suppose point 2 is perhaps simply ironic and not much more. I am not sure how to take point 1 though; maybe it is just difficult to read positive predictions that turned out to not happen. Maybe they had an impact though, and things could've been worse in the absence of the books? I am not sure.
they can probably measure continental drift (only joking)
They can! Continental drift measurements have been done using radio interfometry since at least the 1980s: https://www.nytimes.com/1983/07/05/science/science-using-new... (Though that 1983 article does suggest they were still working on the accuracy). Certainly radio interferometers can measure displacement of dishes after earthquakes.
Magazines can make a similar comeback for niches like fashion and arts. But they will probably be funded rather differently from the ad-filled old media products.
This has been attempted in the outdoors world for 20+ years. E.g., Alpinist[0] and The Surfers Journal[1]. It works, kinda. Alpinist now has more ads and is a smaller physical size and lower-quality paper than it was at the start. I think it's also had a couple close calls with bankruptcy. I wasn't reading TSJ over a long enough time span to tell if they had similar issues.
[0] http://www.alpinist.com/ [1] https://www.surfersjournal.com/
What I find scary is that developers see web apps (and hence the open web platform) as no longer fashionable, and instead focus on developing mobile apps (iOS and Android).
Based on my reading of the original article, I think your response here might be a bit tangential to the point about offline work? Web apps and mobile apps are both in practice largely the same in terms of who controls the computing resources -- they generally only work by speaking to the remote servers of the company.
But in detail, mobile apps seem like they would have a slight edge for promoting offline work. While they in practice "phone home" (or even store data remotely), they could in principle be written without needing to contact external servers and in a way that all data is stored locally.
I do agree that apps often attempt to silo users and can do this more effectively than webapps, but as used now, both are mostly online tools and so don't really address the question of tools that are usable offline.