That's a claim that... at best it seems that hasn't yet gathered behind it enough motivation to clarify anything, and at worst is just a plain malicious FUD. It doesn't even matter, when you think about it. Even if we'd assume a legal accusation of leaked-resembling code in all that pile of modules, all that ReactOS team needs to do is to formally contract reimplementations by independent teams for any of those allegedly guilty modules. In this light, such an accusation is very unlikely to happen, and probably there won't be even a half-baked effort to officially demand clarifying and putting any potential issues to rest. So, about those people out there with an interest in painting ReactOS as plagued by leaked code, entertaining this uncertainty is all they'll do, nothing more.

"You can look up the «history» of it and how it has symbol names for companies with whom Microsoft worked to solve specific application issues."

I assume you aren't going yourself to provide a reference to what you're alluding to in that public repository?

The most appropriate behavior for a portable application is for it to stay clean by default and only offer the user to explicitly enable persistency-dependent functionality. When the application starts, it checks if there's any previous trace of itself and depending on that it either keeps its portable-like clean behavior or switches to installed-like one.

Same goes for post install - not too hard to arrange to auto delete the old copy.

So, please do continue to criticize, continue to raise awareness. That's useful.

That's the thing, that it is quite difficult to vote with your feet. You can't remove systemd from your distribution in favor of separate independent facilities: The combination of its design, its gradual expansion, and the way some higher-level packages depend on it (especially GNOME) - typically prevent its removal.

So, you would need to switch distributions, which most users are not very inclined to do. And - even then, you look around, and you see that the big basic distros: RedHat/Fedora, Debian (and Ubuntu), Arch - use systemd. So almost all of the distributions based on them are also not an option if you want to avoid systemd.

... and the bottom line is that users will effectively not vote with their feet. And neither will system administrators, or whoever maintains OS images at organizations, because it's difficult for them to tell their superiors they want to switch everyone to, say, Slackware, or Devuan.

That is already a desirable place to be, where you managed to get a working implementation ready to evolve. My issue with opinionated languages like Rust is that they make development more expensive. I then afford to pay the necessary work-effort for fewer projects than I otherwise could if I was to focus more on the problem(s) at hand instead of that and other mandatory constraints forced upon me by the compiler. I very much want my development tools to limit themselves on being tools, to assist me on the part of the problem I chose to focus on with little to no cost paid for their usage. I want to be able to focus on prototyping some working solution first, and only then, if the project's needs really warrant it, to switch on paying the development cost for other aspects, be it safety or whatnot.

My sense was that the customers would have been pretty unhappy about that setup. Like, a common question was, "I plugged in my device, but I don't see it on the network. What do I do?" They'd be pretty annoyed if I had just said, "I'll help you if you pay me $99 for customer support."

I think in practice, if I tried to pull that, the customers would just say, "Okay, then I'm sending it back for a refund," or, "Okay, then I'm calling my credit card company for a chargeback," both of which are costly for the vendor.

Plus, I personally don't like the dynamic of customer-paid support. If customers have to pay for support, it incentivizes the vendor to make the product difficult to use so that customers need support.

I always want my products to work so well that customers don't have to contact support. So, if a customer has an issue, I want to feel the cost of that as the vendor so I'm pressured to fix it.

>Or tariffs - is it bad to let the customers know that there are cost differences in the product offered to them due to their request coming from different tariff-impacted markets?

For tariffs, I actually meant tariffs that I pay as the manufacturer. For most of the time I was running the company, we were sourcing most components from overseas and doing final assembly in-house, so we paid tariffs on components as they came in. That's a huge headache, especially when we have distributors in other countries, and we're paying tariffs multiple times for multiple border crossings. And tariffs seemed to change per shipment by 2-3x for reasons that were never clear to me.

Tariffs that the end user pays are a whole other headache. We didn't have a way of predicting what tariffs the customer would pay, so customers would sometimes be upset that we didn't warn them, especially in countries when they receive the tariff bill after they've already received the item. At one point, we tried to use DDP, which is supposed to let us pay the tariff on the customer's behalf, but we tried it a few times and the customer was charged a tariff anyway, so it seemed like it was just a huge expense that did nothing.

I just presume that such observation spacecraft makes sense to be made as a rather long term investment than some one-time fly-by thing like New Horizons, so the sensible thing to do is to have it in an orbit around the Sun at that (≥650AU) distance and to take multiple observations. Of course, the easiest solution may be for the orbit to be elliptical one, with the useful position only around its aphelion, in which case it will be able to observe only a single target indeed. But, I also presume that past the first few such elliptical orbit experiments the aim will shift to have the spacecrafts set on distant (and most likely circular) orbits that make possible observations at any time and thus its target would be something akin to a horizon rather than a single point, wouldn't it?

The other nice thing about being on an escape trajectory is that because of how gravitational lensing works, rather than a focal point you get a focal line. So as the probe continues moving away from the sun, it can continue imaging its target (and the image quality may get better as it gets further out, since the ring gains more separation from the surface of the Sun.)