The way I understand is that they would use a sun-synchronous orbit, more specifically a dawn/dusk orbit, which places the satellite over the terminator between day and night meaning it always directly sees the sun. But yes, it would need an insane number of solar panels. What's more, data centers don't just need power, they also need cooling. So there would also need to be an insane amount of radiators (in space it's very hard to get rid of heat).

All in all the only advantage I can see is not much of an advantage, if at all, especially compared to all the drawbacks.

Up there the sun always shines (assuming a convenient sun synchronous orbit), so you have access to uninterrupted solar power. That's the only advantage I can think of. You're going to need a lot of solar panels though, and even more radiators to radiate all the heat away. And a number of other disadvantages.

Yes, I was wrong, I'm sorry for it, and I already acknowledged I was wrong. No, I wasn't drunk; mistakes happen.

It's not the same video indeed, so I was wrong. Plus your video comes from SpaceX itself, so that should be legit.

In my mind the booster flipped around much faster after staging (though the live stream wasn't really detailed enough to show that).

Very spectacular, but unfortunately a render rather than real footage.

Is created by Alexander Svan / @AlexSvanArt, see:

• https://twitter.com/AlexSvanArt/status/1725550279871942852
• https://www.youtube.com/watch?v=XXTMJ4PWt_Y

Both posted on friday, a day before the actual event, with description "20 seconds from a parallel universe where Starship's OFT-2 and hot staging happened today. Best wishes to SpaceX for the upcoming Orbital Flight Test 2!".

EDIT: I was wrong, the link points to a video posted by SpaceX themselves; it's real footage, not a render, after all.

GNU wants people to believe that Linux distros took the GNU project, replaced the unfinished GNU Hurd kernel with Linux, and called it a day. But distros collected a lot of other stuff too.

XFree86 and various window managers (back in the early 90s there were no free/open source desktop environments yet; KDE (1996) was the first I think, or at the very least earlier than Gnome. I don't know what you mean by "And I’m not even getting into desktop environments.": the way I see it, the topic X and everything running on it doesn't exactly support your point.

Editors vi and vim are not from GNU, and neither are mail clients Pine and Mutt, and the popular pager less.

There was probably quite a lot of BSD code in Linux distributions too.

So, I agree that calling a Linux distribution Linux is perhaps not entirely correct, but calling it GNU/Linux gives too much credit to GNU and too little to all the other people who wrote software that got included in Linux distros. GNU thinks their collection of software is essential enough to be included in the name, exclusively, and I don't agree. Don't get me wrong, GNU does deserve respect, and a lot of it, for all their accomplishments and contributions to the free source world in general and Linux distributions more specifically. But their insistence on the name GNU/Linux doesn't seem the best way to get that respect. It has always felt somewhat childish to me.

At the same time, no one is stopping the GNU project from creating their own operating system distribution using their userland tools and the Linux kernel, and calling it whatever they want, including GNU or GNU/Linux or GNU Guix System or whatever, I don't care. It would be quite hypocrytical if they wouldn't include Linux in the name though, since including Linux is equivalent to how they're asking others to include GNU.

Arguably yes, but none of that is a good reason to put GNU in the name. I don't think even Stallman argued that Linux distributions should use the name GNU to give credit to GNU's influence.

The reason always given is a different one: it's because distros traditionally took a lot of code from the GNU project, which is a different matter. That reasoning does make some kind of sense, even though I don't fully agree.

I do that all the time.

POSIX specifies the API available to programs, and also shell and commands and stuff available to users. It does not specify which functions should be available from the standard C library, and which should be available from the kernel: from the standpoint of POSIX, it's all the same. POSIX doesn't care how the API is implemented, just that it is implemented correctly.

-X is already included in -a, so no need to specify expliticly. Doesn't hurt either.

Nope, I was wrong, -X is not included in -a. Sorry!

-x (alias --one-file-system) means "don't cross filesystem boundaries"; is that what you meant? Or did you mean -X | --xattrs?

Edited because I wrote some things before that were incorrect.

I agree we should use operator overloading only when it really fits the use case. Especially the function call operator is easily misused.

I don’t completely agree with Raymond Chen here though. Firstly I don’t think providing both an explicit Load() function and the function call operator is the solution. Just keep things simple and obvious: provide Load() and remove the function call operator.

Secondly, why is StorageLoader even a class (or actually a struct here, but we know that’s the same thing in C++)? Unless Raymond is leaving out something essential, there is no state. Just make a function:

template<typename DataType>
LoadFromStorage(StorageOptions<DataType> const* options) {
    // ...
}

This solves all the problems: you can simply call it, even without operator overloading (because it's already a function), and doesn't make it awkward to specify the data type we need. We're writing C++ here, not Java where everything has to be a class even if it doesn't have any reason to be.

I agree we should use operator overloading only when it really fits the use case. Especially the function call operator is easily misused.

I don’t completely agree with Raymond Chen here though. Firstly I don’t think providing both an explicit Load() function and the function call operator is the solution. Just keep things simple and obvious: provide Load() and remove the function call operator.

Secondly, why is StorageLoader even a class (or actually a struct here, but we know that’s the same thing in C++)? Unless Raymond is leaving out something essential, there is no state. Just make a function:

template<typename DataType> LoadFromStorage(StorageOptions<DataType> const* options) { // ... }

I agree we should use operator overloading only when it really fits the use case. Especially the function call operator is easily misused.

I don't completely agree with Raymond Chen here though. Firstly I don't think providing both an explicit Load() function and the function call operator is the solution. Just keep things simple and obvious: provide Load() and remove the function call operator.

Secondly, why is StorageLoader even a class (or actually a struct here, but we know that's the same thing in C++)? Unless Raymond is leaving out something essential, there is no state. Just make a function:

template<typename DataType>
LoadFromStorage(StorageOptions<DataType> const* options) {
    // ...
}