AnyOldName3

You’d expect musk of all people to know you need to spend 45 billion to buy the server first.

Like other commenters have said, start by asking the upstream developer (whether that’s by sending a message with a link to the fork or by sending a mega-PR that says you don’t expect it to be merged as-is in the description). They should be the best judge of how they’d prefer to handle it. The thing I’d add is that you should try to avoid taking it personally if their preferred approach isn’t one you think is a good idea. Sometimes good fixes end up never merged because of disagreements becoming too heated even if everyone’s basically on the same page about the fox being good. There’s also a decent chance that your refactors are things the upstream developer explicitly doesn’t want and would otherwise have done them themselves and implemented the same fix, too, or they don’t agree that your fix is good enough. They won’t want to be on the hook for maintaining contributions that use approaches and code style that they don’t like, and that’s okay. They also might know something you don’t about their project that would make something that’s obviously a good idea to you obviously a bad idea to them.

Basically, just try and remember that if it’s a hobby project, it makes progress when the maintainer is having a good time, and gets abandoned when they’re not anymore, so try and avoid making a mess and having arguments when they’re the one that’ll have to deal with any fallout from any mistakes.

A small widget manufacturer attempting that would get bought out by a larger widget manufacturer because anti-trust laws are unenforced. A mid-size or large widget manufacturer would make more money by not doing that and instead forming a widget cartel with the other larger manufacturers because anti-cartel laws are unenforced.

Blaming us would be too close to root-cause analysis for them even to consider. We weren’t normally QA testers, but they’d left it until too late to hire internal QA, so roped in the developers (us) from a SaaS vendor their app replied on as emergency QA.

By the time the app was due to go live, we’d only reported bugs with the signup and login flows. This was misinterpreted as there only being issues with the signup and login flows, and the app launched on time. In reality, it was impossible to get past the login screen.

Once I was tasked with doing QA testing for an app which was planned to initially go live in the states of Georgia and Tenessee. One of the required fields was the user’s legal name. I therefore looked up the laws on baby names in those two states.

Georgia has simple rules where a child’s forename must be a sequence of the 26 regular Latin letters.

Tenessee seemed to only require that a child’s name was writable under some writing system, which would imply any unicode code point is permissible.

At the time, I logged a bug that a hypothetical user born in Tenessee with a name consisting of a single emoji couldn’t enter their legal name. I reckon it would also be legal to call a Tenessee baby 'John '.

Instead of a commit history, you get a commit fairy tale, which is prettier than the truth, but probably less useful. You get something akin to merging the base branch into the feature branch but things look as if they were done in an order they weren’t instead of getting an ‘ugly’ merge commit.

I’m thinking more for the scale of something like OpenMW, as we’ve got more frequently asked questions than we could hope to put on an FAQ page. In the olden days, stuff showed up from our forums when people googled it, and now it doesn’t, so we get loads of questions through Discord, and very rarely one from Matrix.

If past support questions showed up in searches, then more users would be able to help themselves and would never need to ask for support, so it wouldn’t matter as much what platform it happened on.

Personally, I think it would be good if support discords were all bridged to matrix spaces (currently doable, but matrix needs locking down more than discord to stop spam as the tools to prevent and remove it are worse) and the matrix history was archived somewhere search engines could index it like mailing list archives are (currently not doable). That approach would let users use what they want without forcing anyone else to, and keeps self help as easy as it was in the days of forums.

I think you’ve misunderstood my complaint. I know how you go about composing things in a Unix shell. Within your post, you’ve mentioned several distinct languages:

• sh (I don’t see any Bash-specific extensions here)
• Perl-compatible regular expressions, via grep -P
• printf expressions
• GNU ps’s format expressions
• awk

That’s quite a lot of languages for such a simple task, and there’s nothing forcing any consistency between them. Indeed, awk specifically avoids being like sh because it wants to be good at the things you use awk for. I don’t personally consider something to be doing its job well if it’s going to be wildly different from the things it’s supposed to be used with, though (which is where the disagreement comes from - the people designing Unix thought of it as a benefit). It’s important to remember that the people designing Unix were very clever and were designing it for other very clever people, but also under conditions where if they hit a confusing awk script, they could just yell Brian, and have the inventor of awk walk over to their desk and explain it. On the other hand, it’s a lot of stuff for a regular person to have in their head at once, and it’s not particularly easy to discover or learn about in the first place, especially if you’re just reading a script someone else has written that uses utilities you’ve not encountered before. If a general-purpose programming language had completely different conventions in different parts of its standard library, it’d be rightly criticised for it, and the Unix shell experience isn’t a completely un-analogous entity.

So, I wouldn’t consider the various tools you used that don’t behave like the other tools you used to be doing their job well, as I’d say that’s a reasonable requirement for something to be doing its job well.

On the other hand, PowerShell can do all of this without needing to call into any external tools while using a single language designed to be consistent with itself. You’ve actually managed to land on what I’d consider a pretty bad case for PowerShell as instead of using an obvious command like Get-ComputerInfo, you need:

(Get-WmiObject Win32_ComputerSystem).FreePhysicalMemory / 1024

Even so, you can tell at a glance that it’s getting the computer system, accessing it’s free physical memory, and dividing the number by 1024.

To get the process ID with the largest working set, you’d use something like

(Get-Process | Sort-Object WorkingSet | Select-Object -Last 1).Id
# or
(Get-Process | Sort-Object WorkingSet)[-1].Id

I’m assuming either your ps is different to mine, or you’ve got a typo, as mine gives the parent process ID as the second column, not the process’ own ID, which is a good demonstration of the benefits of structured data in a shell - you don’t need sed/awk/grep incantations to extract the data you need, and don’t need to learn the right output flag for each program to get JSON output and pipe it to jq.

There’s not a PowerShell builtin that does the same job as watch, but it’s not a standard POSIX tool, so I’m not going to consider it cheating if I don’t bother implementing it for this post.

So overall, there’s still the same concept of composing something to do a specific task out of parts, and the way you need to think about it isn’t wildly different, but:

• PowerShell sees its jurisdiction as being much larger than Bash does, so a lot of ancillary tools are unnecessary as they’re part of the one thing it aims to do well.
• Because PowerShell is one thing, it’s got a pretty consistent design between different functions, so each one’s better at its job as you don’t need to know as much about it the first time you see it in order to make it work.
• The verbosity of naming means you can understand what something is at first glace, and can discover it easily if you need it but don’t know what it’s called - Select-String does what it says on the tin. grep only does what it says on the tin if you already know it’s global regular expression print.
• Structured data is easier to move between commands and extract information from.

Specifically regarding the Unix philosophy, it’s really just the first two bullet points that are relevant - a different definition of thing is used, and consistency is a part of doing a job well.

Powershell isn’t perfect, but I like it a lot more than anything that takes sh as a major influence or thing to maintain backwards compatibility with. I don’t think the Unix philosophy of having lots of small tools that do one thing and do it well that you compose together has ever been achieved as I think being consistent with other tools you use at the same time should be part of doing your thing well, and things like sed, grep and perl all having different regular expression syntax demonstrate inconsistency and are easy to find. I also like that powershell is so verbose as it makes it much easier to read someone else’s script without knowing much powershell, and doesn’t end up getting in the way of actually writing powershell as the autocomplete is really good. I like having a type system and structured data, too.

Some of these things are brought to a unixier shell with nushell, but I’m not convinced it’ll take off. Even if people use it, it’ll be a long while before you Google a problem and the solution also includes a nushell snippet, whereas for any Windows problem, you’ll typically get a GUI solution and a powershell solution, and only a maniac would give a CMD solution.

Commands and flags (for native powershell commands) are case insensitive, but the autocomplete both in the shell and text editors is really good, so people typically use it and have it tidy up whatever they’ve written to match the canonical case.

You want to have commit history, not a commit fairy tale. Once you start rewriting history, it’s not really history any more. The stuff people want to hide tends to be some of the most useful to someone looking through the history to find out how things became the way they are and what was going through the author’s mind when it was written. If things are messy and crappy, it’s better to know that rather than have it covered up.

There are kinds of analytics that are incompatible with the GPL, as you can’t restrict what users do with GPL software, and that includes asking children not to submit analytics containing information you’re not allowed to know about children under COPPA. The only options are to hope your software is only used by adults, or not implement any kinds of analytics that collect the relevant kinds of personal information.

We only reimplemented the engine, not the game. You still need to own a copy of Morrowind so there’s something for the new engine to actually run. That said, it is possible for it to run other potentially-open-source games, such as OpenMW’s example suite (which isn’t finished enough to even call a game yet) or the Robowind demo (which I can’t remember the licencing details of) .

I’m okay with squashing consecutive silly commits before a merge, but having worked on a codebase that used the policy described above for a decade before I got there, I really, really hate it. Git blame and other history inspection tools are nearly totally useless. I’ll have access to commit messages, but when things have been shuffled around feature branches for a while, they end up concatenated into mega commits with little hope of figuring out why anyone did anything or what they were thinking when they did it. Some of this might be mitigated if stale branches weren’t deleted, but people don’t like stale branches.

If there are genuinely Git tools that can’t handle merge commits in <current year>, I’d be surprised if they didn’t have Fisher Price or Hasbro written on the side.