fbender

Starship alone (the orbiter) is 50m. The truss of the ISS is 109m[1] long. While massive, Starship will still be dwarfed by the station (other than planned habitable volume or individual modules/elements).

[1] https://www.nasa.gov/feature/facts-and-figures

I would say there is no simple answer to your question. However, I am not able to give you an authoritative answer to your question anyway. If you are interested, you can start here[1] or try and ping the moz-security people

[1] https://wiki.mozilla.org/Security/Sandbox

Annoyingly Firefox is lagging behind in that regard.

This has not been true since quite a while. Firefox has employed sandboxing even before the multi-process work (which culminated in the Quantum branches of Fx releases that added more and more sandboxing with each release). Before that, Moz went a different way than OS level sandboxing by principal containerization (I forgot the correct term, sorry), which worked in terms of separation of execution contexts (of Web JS and other parts like the styling system, plus the browser internals). Elements of that implementation have been removed by now (iirc) since the multi-process split required different communication paths anyway (which also enabled per-origin/-tab/-window OS-Level sandboxing), so that code was no longer needed.

I found this gem: https://www.xltrail.com/ – I have not used it yet but from the looks it‘s a great solution to our vicious circle of (no) maintenance at work :D

Sorry, I had it partially wrong. There‘s the C++ Interpreter and the baseline interpreter (that one was added only recently[1]), and then the two JITs (BaselineJIT and IonMonkey). I understand that IonMonkey itself has two levels chosen depending on code hotness.

I.e. these settings will kill all JITs (so the highest 2-3 tiers) and leave the two interpreters.

[1] https://hacks.mozilla.org/2019/08/the-baseline-interpreter-a...

If you talk space, the difference is that all relevant people were and are aware of the risks and do their job despite them. And they do their job in such a way that the risk is always minimized (through extensive preparation, Monitoring, …), you can handle a situation immediately or even recover from it (e.g. redundancy; failure detection, isolation, & recovery mechanisms; etc) and learn from it (post-mortem processes). Everything and everyone breathes risk awareness.

If you are talking aeronautics, the situation is fundamentally similar but also the scales are very different (also in terms of operating personnel vs. throughput). But more importantly, society in the majority seemed to have accepted a level of risk even though we know for sure that the next catastrophic event could happen any moment.

Germany swapped nuclear (and coal) for renewables. While I wholeheartedly agree that it would have been better to extend nuclear in favor of decommissioning coal earlier, that‘ll still not make your argument valid.

Take a look at history if you need more evidence. At some point, someone always said „now we know better and we can build XXXX to be perfect“, and now we are laughing about them (to give a bad but simple example: Titanic). You are naïve if you think today is any different than yesterday, even with all that superior technology and knowledge that we have – but that was also true for any other point in time.

And your „waste solution“ will not help one bit with the waste we already have. Hence my argument remains.

I don‘t get why you‘d bring up any other means of power generation while my reply solely discussed nuclear, but I‘ll take the bait …

substantially less damaging than business as usual in coal.

Never doubted that and never will. Though here we are talking two different scenarios (as you said): Accident vs. nominal operations. Strictly statistically speaking, nuclear „wins“ because of that, I‘ll gladly agree to that. That still does not mean nuclear is to be preferred, it‘s just the less worse option of the two in terms of one (of many) measure.

Nothing done at industrial scales doesn't produce a lot of waste and environmental damage.

While I agree to that statement, there is more to be considered than just waste and environmental damage, e.g. for nuclear (and fossil power) esp. health risks.

nuclear is still safer and more environmentally friendly than the renewables.

Source? Can you at least state how you would define „safer and more environmentally friendly“? That‘s a bold statement you make …

Nuclear is safer than a hydroelectric dam

In what measure? Maybe if you look at Risk * probability (I‘d need a source, though) but unlikely if you look at Risk * probability * cost (except maybe the 3-gorges-dam but that‘s due to a number of unique factors).

These risks are so firmly within the tolerable zone

Maybe for you but not the next person. Or insurer. Or government.

negative exampels are all talking about 50 year old technology which is obsolete

Power generation from water is much older, even thousands of years (if you are willing to accept a slight redefinition). Saying the technology is obsolete doesn‘t fly if said technology is still heavily used every day and not being replaced (i.e. decommissioning of all old nuclear plants).

Japan is re-opening their nuclear plants, presumably bowing to the reality that their Fukushima response was overly paranoid

It‘s a political decision by the Abe government. They were always very pro-nuclear.

be serious. We have waste that lasts forever and we have plans to store it for 30 years.

Which is bad enough. (BTW: This is handled much better in the better part of Europe / Germany than the USA.) The unique problem with nuclear waste is that it requires special handling for 10k-100k years unless you want to die. While this may be true for other, highly toxic waste, this does not apply to the vast majority of waste.

We have the potential to manage waste from an industrial nuclear process. That makes it unique, most other processes we dump dangerous waste, forget & hope.

Having the potential does not equal using it, rendering your argument void. (BTW: While I agree we should be doing this for all nuclear waste no matter the cost, reprocessing nuclear waste (like burnt fuel) consumes a significant amount of the energy that has been produced by the plant, rendering the process uneconomical.) Even then, it‘s not unique, for most other waste we know how to manage it but it‘s too often not done due to economic reasoning. (BTW: This is also an issue of externalized cost that we‘d have to solve. And again: This is handled much better in the better part of Europe / Germany than the USA.)

the volumes involved are tiny

… but very deadly and toxic, rendering it a much bigger problem than most other waste. And we‘re not yet talking decommissioning a nuclear …

Very nice feature set! I especially like the referencing functionality and ToC. Though I wasn't able to test it out (stuck with Windows at work), here's some feedback:

In the example images, you write that you eliminated all toolbars - this is arguably false since I see a vertical one on the very left ;-). I would even get rid of this one and move the ToC to the left edge of the window. You can keep the help button (move it next to the MacOS window controls) and maybe even the export button (also next to window controls) but I'd rather make use of the system UX and use the MacOS toolbar instead (same for the preferences button, it's useless if you make use of the OS functionality).

I'd love to give this to my coworkers for their Wiki drafting, right now I have too many issues with people copying from Word and the system trying to do ... something with that input. Unfortunately, only Windows flies here ...

Be aware that this will disable two tiers of JS acceleration (JITting): The lowest level (BaselineJIT, introduced only recently) and the highest level (IonJIT for very hot code).

But this is exactly the point. Catastrophes like Fukushima are practically always a combination of individual deficiencies in design, process, and operator errors. Designs can be improved, processes adapted, and people trained better, but that will not prevent accidents from happening. This is mostly because human imagination is limited and humans are fallible, and what‘s not covered by the previous two is lack of knowledge & understanding.

Said in other words, if you wait long enough, a catastrophe is inevitable. And history, both old and recent, has told us that the time you‘ll have to wait is much shorter that you‘d think.

I work in aerospace operations and every freakin‘ day things go different than planned and anomalies happen. In „my“ „industry“, we try to prepare for off-nominal situations and that buffers the effects, but you can only do so much and you end up in contingencies very often. You can also easily see when a new player enters the stage as they very quickly (should) learn that you‘ll have to react and adapt your plans very often and tone down any promises …

Long story short, whatever means you put up to prevent catastrophic events, they will never be enough. Then the question of cost arises, which is undoubtedly extremely high for nuclear events, especially in such a densely populated and small country like Germany, and you’ll quickly realise that you probably do not want to take that risk even if probability is very low.

And finally, we have yet to find a working way to handle our nuclear waste for the next 10k-100k years. (I am aware of the options but obviously we are not there yet and it‘s unclear if we ever reach the state of „acceptable solution“ instead of pushing the issue to generations to come.)

I see a huge risk for manipulation and spoofing. You‘ll have to establish some kind of trust if you want to rely on beacon data (from whatever source) for navigation and safety. Just imagine that someone spoofs a signal that triggers autonomous cars to emergency break – depending on road conditions and/or if there are non-autonomous cars as well, an attacker can create some serious damage, injury, and even death.

Given the existence of spoofed base stations (stingrays) among other reasons, a PKI-based solution may not be sufficiently safe. So you‘d have to overlay beacon data with sensors, at which point it’s questionable if there‘s a significant added benefit.

Can you run the baseline interpreter with the costly parts disabled? Even if the code then runs approx. the same speed (and at same cost) of the C++ interpreter, you‘d save maintaining a bunch of code. I assume implementing the missing backends offsets maintenance costs in the long term.

Because hardly any modern plants are operating, by far most are 70-80ies era. On top of that, consider the cost of currently planned or built plants and their schedule overruns: They may be less terrifying (if you manage to cancel out the psychological effect) but then they are often not considered „worth it“.

WxWidgets is now available & stable(!) for Py3 and available on PyPI for easy installation & distribution. Moreso, the dev pipeline has been streamlined and they are now able to follow upstream much more closely! Maybe this is sth for you.

If the new API get's ported (which is likely to happen), it does not mean the existing API will get crippled. After all, they are different implementations and it's Mozilla who's behind that. I trust them to not deprecate the old API until all use cases, especially concerning privacy, are taken care of in the appropriate way.

Let's hope I'm right. :)

Apparently not since they resisted implementing WebSQL.

I've never had any issues on my Mac. Then again, I'm using an MBA 2012 sans Retina. If you are using displays with "non-standard" resolution (including Retina), even external ones, then you can refer to my other post[1] for background.

[1] https://news.ycombinator.com/item?id=18599707

There is a well-known bug[1] with non-standard resolutions. Try changing the resolution and see if it makes any difference. If not, please file a new bug :). Otherwise you can see if you can help fixing the issue. Unfortunately, it requires some re-engineering of core graphics processing and they are working on it, but it'll likely take a few more months to fix completely.

[1] I think this was the bug I thought about: https://bugzilla.mozilla.org/show_bug.cgi?id=1404042, see also https://bugzilla.mozilla.org/show_bug.cgi?id=1422090

I‘m pretty sure there is an un-branded release version of Fx on the Mozilla website that allows side-loading and allows disabling the signature verification. I don‘t have a link ready and on mobile so I cannot easily check.

Their addon tool includes a well documented facility to sign an extension without listing it in the addon store so you can host it somewhere else. This can e.g. be used for company-internal extensions.

„This cool trick gives your Firefix super powers“ articles will appear instantly. This happened before with noobs following instructions to copy & paste code into the developer console(!), which pwned quite a few Facebook (and other) accounts. Same for banking websites, intranets, … social engineering works well on the unsuspecting. This is btw why browser vendors implemented measurements to make it harder to copy & paste into the dev console, as well as disallowed pasting „javascript:“ URLs to the address bar.

It‘s the injection vector. People used to sideload malicious addons a lot by „accident“ when a rogue website told them to („You must install X player to see this video. Click here …“).

Aurora is no more because it was not necessary for stability (when nightly merges to beta it is already very stable, this improved a lot over time) and incurred a cost on speed of development (one less stop for the train to ride). DevEdition is now based on Beta and extremely stable. I use it alongside the stable version on both of my main computers in an equal way and I have max. 1-2 issues in DevEdition in a year (and those issues do not even prevent me from doing my work).

The topic here is phasing. The two orbit approach requires exact alignment of orbital path and correct phasing, which both translate to an exact point in time when you need to launch the rocket (instantaneous launch window, i.e. when you delay by a second you need to scrub the launch). That window does not repeat every ~90 minutes (i.e. orbital period), since the ground track of the ISS moves West (relative to Earth‘s surface). It does repeat roughly every ~24hrs (not quite true and hence you cannot launch every day of the year), so you can re-attempt the next day only.

For the longer approaches, the rocket launches with an offset of several (tens of) minutes of that instantaneous launch window (that mostly means you have a launch window of several minutes, i.e. short delays do not abort your launch), so the spacecraft comes up significantly „in front of“ or „behind“ the ISS. As with the fast approach, the spacecraft will still not launch into the same orbit (i.e. mostly lower and more elliptical than the ISS orbit). But this is more important for the slow approach: Due to orbit dynamics, the difference in orbit will make you „catch“ up with the other space vehicle over time – this is what is called „phasing“. When you’ve aligned the phases, you raise/align the spacecraft’s orbit to the ISS and are thus very close and in final approach.

If your phase is not well aligned at orbit insertion (i.e. just after the launch), you need to do more and thus longer phasing. I.e. the bottom line is that you need a high precision launch, precise navigation sensors & enough computational power on the rocket and spacecraft to be able to do a fast approach in 2-3 orbits, plus the ISS orbit must align very well with your launch site at launch time. It is simply more complex and thus more risky as the slow approach, but then again you are faster if everything works out perfectly. The safer bet is the slow approach, though, as it gives you more margin and more time to fix any issues that arise.

Previous link: https://news.ycombinator.com/item?id=18498121

Check out the AstroPi challenge [1] for a similar idea on the ISS. Including support for multiple sensor and cameras.

[1] https://astro-pi.org/

How about providing a WebExtension that exposes the bits that require a binary (e.g. P2P and possibly proof-of-work part if WASM does not work for you) or are provided by the platform, then you can waive the Electron requirement for those who do not want it, plus your web interface potentially works the same for read-only visitors and users (who have the web extension installed). You can also include the frontend bits in the WebExtension so no one relies on the website working anymore.

There‘s still a huge difference between „certain people are not allowed to live“ vs. „I want to be allowed to love whomever I chose“. That former group should still not be excluded from certain basic „rights“, at least until they act on their beliefs (but that‘s up to the courts to decide). But again, you are comparing apples to oranges and questioning the moral principles the (at least Western) society is built on.