One of the problems with treating terminals like other text input contexts is that they're inherently different and you're going to constantly run into issues when the context switches to displayed text.
For example, you could get a terminal that allows selecting text with keyboard but what happens when a user inevitably wants to or accidentally selects text from the non-input part of the terminal? Should the input part of the terminal and the display part of the terminal be treated differently? In Firefox as I type this I get a nice big input box where I can do multi-line paragraphs but if I start clicking and dragging to select the text in the input box it'll never let me select text from your comment, likewise in reverse, but on a terminal this would be undesirable behaviour for the common pattern of selecting text to copy output for documenting or troubleshooting.
Some terminals have plugins or scripts to allow such selection of text but not for input purposes, if you decide to only allow text selection on the input field as a means of improving text input do you just get two such methods of being able to select text? The sane approach might be to allow selecting all text but you'll end up with paper cuts where a user doesn't care about what is going on before the $ but might end up in situations where text is selected far before the $ because of a reverse search gone wrong, etc.
As an aside, terminals/bash do have some form of text-editor like functionality, readline is the usual library involved (man bash, /^readline) and has reasonable support for moving cursor around words, move cursor to character search, deleting/yanking/pasting words, etc. It's not the best text editing interface but for dealing with a single command line it's usually sufficient. There's even a vi-like editing mode (set -o vi) built into bash if you feel like you need a modal editor for a single line but it seems even less intuitive and harder to grok.
In this particular case 'it's' can also be possessive although it's considered non-standard, so to be correct you can always treat it like a contraction of 'it is'.
That's what I was thinking as well, it's not uncommon to find translations of the Icelandic sagas along side original manuscripts or even Beowulf for that matter, but it's understandable if his class was one on Aristotle or politics rather than ancient Greek.
It's important to remember that modern translations exist because language and cultural contexts change over time, this is true for both classical and more recent texts.
A classic example would be Homer and his wine-dark seas or green honey, to change the descriptions of colour would absolutely be introducing a modern bias but it's a necessary one if you're not going to explain why ancient people had less descriptive terms for colour, a failure to introduce that bias would lead to another unintentional bias in the form of thinking along the lines that ancient people (or Homer in particular) were colour blind.
For a more modern example go look at any works on Project Gutenberg that have recently entered the public domain, it won't take long before you'll find language that at the time of being authored was far less culturally charged or sensitive than it is today, if you were to 'translate' those books an immediate and obvious bias would be to change some of those words to more 'politically correct' ones that would better reflect the meaning and intention of the author, to not do so leads to misunderstandings when people read those works with a modern cultural lens. You can also see this sort of thing with the euphemism treadmill, where older terms can either become taboo or lose all meaning (like mad, insane, mental), and where modern terms can become more appropriate or become taboo (e.g., twitch.tv recently renaming the 'blind play-through' category in an attempt to be more inclusive to blind people).
Modern translations introducing bias and changing meanings like this may seem like a problem if you're inclined to take a more scholarly approach to understanding works by reading multiple translations from multiple eras, or better yet reading annotated works (like what is common in theology circles), but all of this is an incredibly laborious approach to reading that most people, even in universities, don't have the chops for. If you want people to actually read more and read ancient works especially it's better to accept that language and meaning is messy to begin with and to not get hung up on issues with particular translations, because after all there's no guarantee that the person reading the works is going to come to the exact same conclusions, that's something scholars who dedicate their lives to works can rarely do even if overall they converge on a much more consistent understanding of said works.
--
I mention this because the video rubbed me the wrong way, the point about how the modern translation 'completely changes the meaning' by using 'human beings' and 'humanity' versus the older translations which use terms like 'men'. It could absolutely be the case that the modern translation is being lazy and substituting mankind/men for the more modern humankind/humanity, where the older translations are specifically using men, as in the male of the species, to better reflect what would originally have been written in ancient Greek. The answer to this isn't something I'm anywhere near qualified to answer (sorry), but what I can say is that men referring specifically to the male of the species rather than mankind is a fairly modern interpretation of the word that's both pushed by people that would consider 'humanity' to be 'hippie cultural marxist bullshit' (as the video puts it) as well the type of people that would prefer 'humanity' as mankind would be seen as a tool of the patriarchy or something along those lines.
If you take the older translations to be more authoritative and correct as the video did you need to understand that to not cloud your judgement with modern definitions and language as the video is doing, humankind only started becoming popular around 40 years ago so if you're taking a translation from Project Gutenberg (at least 75-100 years old) you're simply never going to see such terms and instead it's more likely you'll see 'men' where it's plausible that it could refer to people and not specifically males given the etymology of the word and its historic usage.
A generous interpretation of the video would be that the modern translation is full of such errors and is deserving to be called a 'forgery', but to focus 15 minutes on such a weak example seems so incredibly dishonest and lazy even if the videos interpretation happens to be the correct one. The entire substance of the video is that the older translation is correct because it better suits his particular choice of language, if the translation is so egregious to be called an Orwellian rewriting of history surely there's far more substance that could be packed into 15 minutes.
Nobody is asking that warehouse workers or store clerks be paid ridiculous amounts like $120k/yr, a fair liveable wage will do, failing that a lot of the problems would be resolved if such companies scaled back whatever policies they have that lead to news stories like Amazon workers peeing in bottles because they can't take toilet breaks, but as neither of these things happen you get exploited workers who naturally want to unionise.
It's also not that feasible to pay developers $120k/yr as the rest of the world has found out, America manages it for a number of reasons and because of this you likely won't see developers unionise any time soon even if you guys do have some very questionable contracts.
>Plenty of companies, indeed entire industries, base their business model on being evil. The insurance business, for instance, depends on the fact that insurers charge customers more than their insurance is worth; that’s fair enough, since if they didn’t do that they wouldn’t be viable as businesses. What isn’t fair is the panoply of cynical techniques that many insurers use to avoid, as far as possible, paying out when the insured-against event happens. Just ask anyone who has had a property suffer a major mishap.
The article isn't saying that insurance companies are 'evil' for making a profit but instead for doing everything they can to withhold payment, not every insurance company does this of course but many of them know that customers are more likely to accept 50% blame in a 0% blame car accident or accept a reduced payout over minor technicalities because the alternative is going months without a car and spending a significant amount of time and money in court.
This analogy is entirely applicable to governments too where an 'evil' government might, at great cost, make benefit programs difficult or humiliating to obtain to discourage legitimate claimants from doing so, never mind straight up corruption or cronyism when it comes to allocating public funds.
While that is a problem it's a fairly harmless one to have, the company can't profit any more off of your work than anybody else can and you're not really losing anything by the company doing this. Contrast this to using the GPL where companies can effectively treat your code as proprietary and profit immensely off of it at the expense of everybody else who publicly contribute to your work but don't receive any kickbacks from big companies.
Both are due to the same photoelectric effect according to Wikpedia, however it doesn't seem like xenon flashes are the most suitable thing to erase those chips and I don't think ultraviolet lights would cause the same issues on the Pi that an xenon flash would.
In general try to stick to the larger distributors or suppliers like Mouser, Farnell (or CPC in the UK), RS Components, Digi-Key, etc, or your countries closest equivalent assuming you have good consumer protection laws, if their target market is the business and industrial sector but they still sell to individuals it will likely be a good bet if a little expensive.
Another good choice can be hobbyist or educational sites that have some reputation to uphold, the most talked about online will be US centric like SparkFun or Adafruit but there's many European equivalents for example. One way to find them would be to find an authorised distributor in your country for larger projects like the Raspberry Pi and see if they sell the components you need. Chances are if they're an authorised distributor for a recognisable product then they're probably not going to risk losing their spot on that products website just to sell some fakes or dodgy components.
The key thing is to not buy directly from China or random eBay sellers from abroad if you can help it, return postage to China is prohibitively expensive and Chinese stores or marketplaces like Aliexpress won't always agree that you're entitled to a full refund without returning the item even if that item happens to blown up in your face, and likewise you can't really expect that small random foreign eBay sellers are going to be liable for selling you items that adhere to your countries safety regulations for instance.
A considerable controversy exists over the fact that the IPs were allocated to the global amateur radio community to be self-administered, but due to the sale the 044/8 block is now administered by ARIN. The sale hugely benefits an American company, Amazon, with the profits going to ARDC who will likely be biased in benefiting or providing preferential treatment to the American amateur radio community by virtue of themselves being an American company, and despite claims that the sold IPs were unallocated and unused they were in fact partially allocated and used by Europeans.
There could have been a legitimate discussion on whether the amateur radio community really needed some 16M IP addresses and if a partial sale of the resource could have benefited the community more, but any such discussion was denied when the ARDC decided to do backroom deals with IPs they might not legally have had ownership over.
Still, $108 million is a lot more than the 'couple of million' to $50m rumours that were floating about at the time of sale, hopefully they can do some good with the money and buy back some goodwill. Let's just hope the wholesale of prices of IPv4 addresses doesn't rise too much leading to another /10 sale, or if it does that they sell off their own blocks instead of the blocks allocated to the rest of the world.
For example, you could get a terminal that allows selecting text with keyboard but what happens when a user inevitably wants to or accidentally selects text from the non-input part of the terminal? Should the input part of the terminal and the display part of the terminal be treated differently? In Firefox as I type this I get a nice big input box where I can do multi-line paragraphs but if I start clicking and dragging to select the text in the input box it'll never let me select text from your comment, likewise in reverse, but on a terminal this would be undesirable behaviour for the common pattern of selecting text to copy output for documenting or troubleshooting. Some terminals have plugins or scripts to allow such selection of text but not for input purposes, if you decide to only allow text selection on the input field as a means of improving text input do you just get two such methods of being able to select text? The sane approach might be to allow selecting all text but you'll end up with paper cuts where a user doesn't care about what is going on before the $ but might end up in situations where text is selected far before the $ because of a reverse search gone wrong, etc.
As an aside, terminals/bash do have some form of text-editor like functionality, readline is the usual library involved (man bash, /^readline) and has reasonable support for moving cursor around words, move cursor to character search, deleting/yanking/pasting words, etc. It's not the best text editing interface but for dealing with a single command line it's usually sufficient. There's even a vi-like editing mode (set -o vi) built into bash if you feel like you need a modal editor for a single line but it seems even less intuitive and harder to grok.
https://readline.kablamo.org/emacs.html
https://catonmat.net/bash-emacs-editing-mode-cheat-sheet
https://catonmat.net/bash-vi-editing-mode-cheat-sheet