Hacker Newsnew | past | comments | ask | show | jobs | submit | JanKanis's commentslogin

Indeed. The same rocket will give a light probe a much higher velocity than a large probe. The launch vehicle for JUICE is the Ariane 5 ECA which can launch 16 tonnes to low earth orbit[1], while the Titan IIIE that launched the Voyagers had a capability of 15.4 tonnes to a (lower) low earth orbit[2]. So the current launch vehicle is a bit more powerful, but not 8 times as much. There are some more powerful (and more expensive) rockets active at the time, but nothing 8 times as powerful as the Titan IIIE.

So NASA has the choice of 1) launching a lighter/smaller probe with less scientific capabilities and endurance, 2) spend $$$ and time developing a much more powerful launch vehicle, or 3) have a few years of patience waiting for JUICE to get to Jupiter on a slower trajectory.

Jupiter has already been visited by multiple probes so sending a small and not very capable probe would not gain us much scientifically. (But this option was taken with the New Horizons probe to Pluto some years ago.) (2) Wouldn't actually be faster and much much much more expensive (see how long the SLS rocket is taking to get done. But mr. Musk is taking this route too with SpaceX's Starship, so this will be an option in the future if all goes well). So that leaves option 3, which NASA has taken. They could probably have opted for an existing more powerful and expensive launcher to shave some years off the transit, but they preferred to wait a bit longer and not spend that money.

[1]: http://www.astronautix.com/a/ariane5eca.html [2]: http://www.astronautix.com/t/titaniiie.html


> So NASA has the choice of ...

> So that leaves option 3, which NASA has taken.

As far as I'm aware, JUICE is an ESA probe. NASA is providing one of the instruments, but I believe that's it.


I've used the Poly Voyager Focus, Poly Voyager 6200 and Shokz OpenComm (with Avantree DG80 dongle) with good results. They don't require custom software, but they do require using the provided dongle (or 3rd party dongle for the OpenComm) because PulseAudio doesn't support wide band speech. Installing PipeWire is another option (or waiting for your distribution to switch to it).

With a 3rd party dongle like the Avantree DG80 you can use any bluetooth headset and don't need to worry about the Linux support part. The main disadvantage I found is that you have to manually switch between headset mode and HiFi headphones mode.

I also have the Poly Voyager 8200, but I haven't used it as a headset enough to give a definitive assessment, but based on what I've tried and the results from the other Poly products I expect it to be good.

I also tried the Poly Voyager 5200, but I didn't like the speaker sound quality with it being a single ear device.


Thank you for all the suggestions, your answer is exactly what I was hoping for!

It sounds like Avantree DG80 might solve my issues on Linux, I never realized I could outsource the entire Bluetooth audio headache to a generic dongle and get regular audio out of it.


Not as cool a visualization, but https://www.swissgrid.ch/swissgrid/de/home/reliability/wam.h... shows the frequencies and phase differences (in degrees) between a few measuring stations around Europe. The phase difference between Switzerland and Spain is now some 50°, which is actually much larger than I would imagine these differences becoming.


And if you want to work on cBioPortal and make it your job consider joining us at The Hyve (thehyve.nl) (or one of the other institutions if you're not in the Netherlands)


I don't think you're right that interfaces are implemented as a pointer to a struct. The struct is inline like any other struct, and it contains a pointer to a type and a pointer to the value, like `([*Baz], nil)` in your example. The problem is that a nil interface in Go is compiled to `(nil, nil)` which is different.

That still makes this inexcusable of course.


You're right, it was lurking in the back of my mind that it must be on the stack entirely.


But on hardware for which the hash function implementation is optimized, you will be able to crank up the cost factors higher than on comparable hardware for which no optimization was done. So a different hash with an implementation optimized more for ARM could give more protection than Argon2 on ARM because you would be able to use higher cost factors while still using the same amount of wall clock time. But I don't think such a hash function exists, and if not you could as well create a more ARM optimized implementation of Argon2.


Timsort is especially good at reducing the number of comparisons needed by taking advantage of already ordered subsequences in the input. This advantage comes at a cost of more overhead compared to e.g. quicksort. Therefore Timsort is faster if the comparison operations are expensive, quicksort if they are cheap. Java takes advantage of this by using Timsort to sort arrays of objects with a user specified comparison function, and quicksort to sort arrays of primitives. (Or at least it used to.) In Python everything including comparisons is relatively slow so they just use Timsort all the time.


Fish currently does not support executing shell functions or commands in the background with &, only external programs. This is a known omission, but the best way to fix it is to make the shell interpreter code thread safe so we can actually write multithreaded shell code. Currently fish only uses threads for potentially blocking i/o operations. But implementing this is quite a bit of work and has not been done yet.

Having said that, `enc &` erroring is indeed a bug, expected behavior would be to run the `begin ... end &` block in the foreground anyway.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: