Personally, I use they in many contexts, because it saves thinking. Leaving aside "they" where a gender could not be inferred (OED, they pron. 1.2.a & 1.2.b, e.g. If ou sall lofe, e person fyrste, I rede, ou proue Whether at thay be fals or lele. c1450 and onwards), you can still see Merriam-Webster cite both Shakespeare and Shaw examples of they as a pronoun where gender could definitely be inferred. Not new, not an issue, no downside to discuss. Plenty of other examples available.

Re. the post above about whether historical examples were simply using poor grammar, and so irrelevant, even if we suppose that were the case, there is an interesting OED comparison with "you" - by the same logic, it would not then be suitable for use as a singular second person pronoun even now, as was taught to be bad grammar (until more recently than many "they" examples), when it got normalized by use and now no-one posts complaints. Maybe in the other reply, thou (sg) could improve thy (sg) consistency, or you (pl) could all carry on without worrying about it in the first place.

When I started as a freelancer, I had several painful experiences with (a) using dualboot laptops that nearly worked but missing drivers or borked hardware was a you problem, and (b) Kickstarted Linux laptops and hardware failing. At 3am in a hackerspace, ahead of a deadline, someone pointing out wasting time on half-working drivers or failed motherboards was going to cost me my business.

Then, after sending the same laptop to the manufacturer a continent away three times, I spotted the XPS 13 Linux. Frankly, Dell's Next Day Support with the XPS 13 was what let us standardize our company on Linux for several years - if it wasn't around right then, I would've had to switch. With the Premium Support, it was actually a great option. Pick up the phone if there was a failed motherboard, and there would be a professional in the office the next day. The poor Premium Support people would get out their Linux manual and run through appropriate BIOS updates with you and did successfully fix things. One guy even fixed a second XPS since it was lying there.

Then we noticed things go wonky. More driver issues going unfixed, fewer updates, orders evaporating ("I can't explain why your order was cancelled, but I can transfer you to sales") and the range gradually dwindling. Harder to get countries with Next Day and eventually we gave up entirely trying to get a laptop and Next Day for a team member in California. We ended up going with a small independent Linux supplier, ironically. We even tried to convince a local shop to give us a Next Day commitment but nada. And then had hardware issues that took months to fix posting back and forward to the manufacturer.

We are now using Frameworks - on the basis that hardware can (theoretically) be replaced piecemeal with less drama - and, while I love the product, we had canonically the worst business customer experience I have ever seen with a failed component, over weeks, so gave up and now have a £2k laptop propping up books. It is consequently a company policy to keep a spare Framework to avoid customer impacts when something fundamental fails.

TL;DR - people will point out that many suppliers now provide Linux laptops, but the XPS 13 remains in my heart as the only Linux laptop with an (international) SLA that I could trust to build a business on. One lost billable day for a senior engineer already costs as much as a new laptop. For anyone wondering why more companies do not hand out Linux laptops, it says something when Dell is held up as the paragon of support contracts.

PS: strangely, we have never tried System76, for no better reason than there has always been something else in front of us, but if someone knows how we can get international business Next Day support, reply below.

The Company _is_ the people in it. No external shareholders here. Maybe the first question is "what is the AI achieving", and if the Company - the people who make it up, and the customers who we rely on - is not benefiting, then it's optimizing for the wrong goal.

As a CEO, this sounds like what I've always wanted - I could finally do coding, teamwork and (interesting) work travel I want to without all the CEO stress, responsibility and workload (and I could even contribute to the billable work and finally justify a proper salary and pension!). Might have to go back in as a junior/mid though, but at least I've got the institutional knowledge bit and hopefully the AI isn't too ageist, so I've got reasonable prospects.

Can I feature-request a "director" mode too?

Around the time of Horizon Online appearing in 2010 (not original pre-2k Horizon), the UK government, also the sole shareholder of the Post Office, was at the cutting edge of bringing open source into public procurement and increasing technical transparency.

What surprises me is that, at this point, there is very little questioning of whether single-purpose government contract closed source is automatically the right choice - there's a case for open and for closed, but Github is a lot easier to access for an expert witness. While there were also issues with the reference data, it is hard to think of a starker example of why having access for third-parties, even just to the code, matters (yes ironic, but did a Medium article few days back if anyone wants some more context links for this point).

This has become my go-to answer to "whether government money means public code only impacts technical people".

A few years back, I created a set of libs to provide this in Gnome Terminal. Not the most elegant solution but it allowed SVG to be rendered into the terminal and so, once the custom libvte was installed then gnome-terminal would support overlays like a miniview for vim (only requiring a vim plugin), ability to print image files to the terminal, matplotlib graphs for system monitoring, etc. I even had partial tmux multiplexing support and passthrough for SSH.

Naturally, there was a lot of work to do going forward to make a stable production tool - for example, if a program can write arbitrary images to your terminal it can mislead you in ways a normal console program couldn't, but equally usage/security issues like that were not necessarily _that_ far from what you could already do, and these were not unsolvable problems. Compatibility-wise, anything that could output SVG as text could manage the simple protocol, and I'd client libs for Python so it was a little like ncurses usage (in fact, one example uses ncurses and gasket).

After a while I realised that the general response was "Nice novelty - shrug" so rather than keeping maintaining or improving a fork of libvte, I stopped. That was 8 years ago - now I still miss my miniview in vim :/

Re-reading the article, I now think it's just a handy definition of what an API is, not specific to the case. Think that is effectively what the ACs who disagreed above are saying too.

I've tweeted Bloomberg Technology to suggest it's clarified, especially as it sounds a bit like Google have stolen a big, functioning bit of software and for some reason they're refusing to pay up (maybe that was debated in an earlier component of the case, IIRC, but not the current issue). In particular, that's the only bit of the article I can see with any technical explanation of what happened, so it's hard to come away thinking "yes, I can see Google's point", which is unlike most write-ups I've seen to date.

Have I completely misunderstood this case or has Bloomberg?

Agreed - developers conflating Open Source (OSI compliant) and proprietary licenses, including "non-commercial", causes wide-ranging problems. Not suggesting CopperheadOS do this, only a number of previous commenters

1. Developers including open source code, to later find out that they have just sunk their company's product. Even with GPL, you can look at becoming compliant. Here, that means winding up your company
   • My Github code is MIT licensed, use for your project! (By the way, I built it on another MIT licensed project - turns out it wasn't, sorry, but a random third-party developer now wants damages from your employer). Lot less likely when upstream doesn't stick source-available non-OSS project on Github with an MIT license. Looking at you, HoverCSS.
2. It's anticompetitive, which is fine, but pretends to be collaborative, which isn't. Open source works because it's a clear concept, with interpretations all following some basic principles. NC doesn't. If Android was source-available there would be no CopperheadOS.
3. It feeds FUD. Building on open source doesn't automatically destroy your business. But using this would.
4. It perpetuates the "Open Source is anti-commercial" myth. Not convinced? Read the comments above. That makes it far harder for those of us running businesses making (and selling) commercial open source products to challenge those assumptions (and so survive commercially).
5. It's far harder to prove non-derivation of your own code from source-available than closed source you haven't had access to.

Summary order of preference:

1. Open source
2. Source-available proprietary
3. Closed proprietary
4. Being delivered a trained parrot and monkey who alone may interact with the software on my behalf
5. Either 2 or 3 pretending to be 1.

First was Howl's moving castle: http://www.onlineghibli.com/howls_castle/. Finding out later that Howl was from Wales was a bit of a surprise, but I guess they have the world's most castles per capita, so if there's a moving one anywhere...

Although Spirited Away had the edge, for me.