Rather than speculating, you might want to look at what happened with a similar regulation on white goods. For the most part, these are made from components supplied by third parties and so the immediate knock-on effect was that dishwasher makers demanded long-term support for components from their suppliers. The suppliers turned around and said 'sure, but for a limited range'. This meant that almost all models of dishwasher are now built using a few standard components (including the electronics), which are guaranteed to be available for a long period. Because the component suppliers now have better economies of scale, the cost of manufacturing went down. Most manufacturers kept their prices the same, but a few dropped their price a lot to pass this on to consumers. The end result, for the consumer, is that dishwashers are cheaper and if they break down the parts are easier to obtain and cheaper. Sorry if this upsets your 'all regulation is bad' narrative.
They normally don't sue for violations of the GPL for non-GNU software
They don't sue for any software for which they do not own the copyright, because they would not have standing in court and the case would never make it to court.
but they make an exception for Linux
Really? And which court didn't throw this out without a hearing?
The problem is the network effect. The value of Facebook provided by Facebook is negligible, but the value of Facebook provided by your friends is significant. It's hard to be the one person in a social group that doesn't use Facebook. That said, I keep hearing how good Facebook is for organising things, so why not encourage your Facebook-using friends to use it to all agree to quit at the same time: if half of your friends don't quit Facebook, then the value of Facebook is suddenly a lot lower.
Those poor American companies. All they were doing was engaging in unethical behaviour that the weak regulatory culture of the US permits, and now they're not being allowed to do the same thing in Germany, where companies that had to abide by modest standards of acceptable behaviour couldn't compete!
Next thing you know, you'll be saying that Chinese companies can't set up factories in America and employ people for $2/day working 16-hour days and dump their waste products directly in the Mississippi! After all, that's all completely acceptable under the regulatory regime in their own country - it's the fault of American companies if they can't compete in manufacturing with their innovative Chinese competitors.
I'd love to see that IQ study, because it doesn't reflect any results that I've seen. That said, there are a number of studies that show that men (particularly from teenage years to their mid 20s) are more inclined towards risk-taking behaviour (though a more recent study indicates that this is a conditioned behaviour because men are more likely to be rewarded for risk-taking behaviour). This skews a number of common assessment methods, where different preparation strategies can lead either to top scores with a significant risk of low scores, or to mid-range scores with little risk. This doesn't indicate different abilities between men and women, it indicates that the assessment methodology is flawed (unless your exam is explicitly intended to measure risk-taking behaviour or some trait that correlates strongly with risk-taking behaviour).
its naieve[sic] and factually incorrect to suggest that both sexes have identical abilities.
It's naive and factually incorrect to suggest that any pair of individuals have identical abilities. Or are you trying to imply that women are inherently worse at mathematical disciplines than men? Because, if so, there is pretty much no evidence that this is the case when you factor out cultural differences (and if you don't then you can easily find groups where either gender is dominant in the field).
Perhaps we need to get rid of Linux kernel as well.
Well, that would make the BSD advocates happy...
More seriously, the biggest Linux vendor (Google) is currently doing that and moving to their Magenta microkernel, which can run a lot of things in userspace at a lower privilege level. Even within the world of monolithic kernels, a lot of things are moving out of the kernel (ironically, for performance reasons: the same reason that they moved in there in the first place). GPU drivers are now almost entirely userspace: the kernel component maps device registers into a process' address space, manages the IOMMU so that memory is shared between the GPU and the process, and then largely gets out of the way. High-end network cards have done this for a while, but NetMap (in the default kernel on FreeBSD, available as patches for Linux) lets most NICs expose send and receive queues directly to userspace so that you can bypass the kernel network stack for very high performance networking with specialist workloads (there's a good chance that the last time you queried a DNS root server the response came from one of these). FreeBSD and XNU do low-latency sound mixing in the kernel, but most other systems do it in userspace. Most *NIX systems have a ugen device type that makes it easy to implement userspace drivers for USB devices and these are commonly used for MIDI and a number of other device types (for example, webcamd uses this to implement a load of webcam drivers in userspace). FUSE has allowed moving some filesystem drivers out of the kernel.
Some drivers are moved out because they don't care about performance (the computer is so much faster than the device that latency from an extra context switch doesn't matter) and the isolation is a win. Some are moved out because they really care about performance and the extra context switch to the kernel costs too much, and they're typically very complex so moving the untrusted code into userspace makes more sense. In both cases, there's a general trend towards having less stuff in the kernel.
CPython has always been a horrible implementation. It's not even at the standards of a 1980 implementation of Smalltalk in terms of performance and Python is easier to generate efficient code from than Smalltalk. HHVM is just amusing: for Facebook's use case, they could get away with never running the GC for most workloads, which would give them around a 30% performance increase... except that PHP makes it observable in the language whether an array has more than one reference and so they need to pay ref counting overhead on everything.
they made money selling weapons and then made money selling everything needed to rebuild europe/Asia. The USA was able to progress while other countries rebuilt
On top of that, the US and the USSR split the german scientists between them and US universities were in a position to offer top researchers from European cities much more resources if they relocated. Some left when the second world war looked inevitable, a lot more left after it finished when they got much better offers in the US and no longer had a sense of being unpatriotic abandoning their country in a time of war. Throughout the cold war, the US actively pursued a policy of encouraging the best minds from elsewhere to relocate.
On a side note, most clients seem to have way to many dependencies. I found a pure bash one without any dependencies
acme-client has no dependencies and is implemented as a small set of privilege-separated programs, so the thing that handles your private key and the things that makes network connections are entirely separated and the thing that an attacker might compromise runs with very limited privileges.
You can renew a lot more often. Renewals are only limited by the rate limits and these allow renewing even after you've hit the 20-certs-per-week limit for a domain. Acme-client on FreeBSD defaults to renewing every week, so even a few failures will not cause problems.
Self-signed certs aren't technically worse than plaintext, but they're not much better. If I go to example.com and establish a TLS connection, I want to know that I am talking to example.com. With a self-signed cert, I have no such assurance. I have a connection that is encrypted, but I don't know if the endpoint is actually example.com or if it is some malware running on the WiFi access point that I connected to (unless you've somehow obtained the example.com public key out-of-band and know that they're not planning on upgrading the connection). You're safe from passive eavesdropping but not from any kind of active adversary.
Self-signed certs are worse than plaintext from an HCI perspective, because they provide the appearance of security, while providing very little actual security.
In contrast, a cert signed by Let's Encrypt at least tells you that the example.com that you're talking to is the same one that the Let's Encrypt server was talking to. It's a lot easier to compromise a random WiFi AP than it is to compromise the connection in the datacentres that Let's Encrypt uses and a random WiFi AP.
The ACME protocol doesn't ever give Let's Encrypt your private key, so they can't compromise your key. They can issue other certs for your domain (but so can any CA), but if they do then they'll appear in the certificate transparency logs for your domain (if anyone visits them with a client that records things in CT logs, at least), so you'd see.
It demonstrates that the one holding the cert also holds the domain name. Nothing else. And nothing else is implied by the whole deal.
Not quite: the key exchange happens over HTTP and doesn't always use DNSSEC, so all that it actually proves is that the person issuing the certs was able to receive and reply to TCP packets going to the IP address that the Let's Encrypt server's DNS reported was associated with the domain name. That's a somewhat weaker guarantee (though no weaker than most non-EV certs).
Let's Encrypt also logs all certs with certificate transparency and so you can check (by grabbing the CT logs or using a web search) which certs have been issued for your domain and see if any of them don't match the public key that you think that you're using (and you can automate this from another machine). Chrome also reports certificates that it's seen to the CT logs, so you can spot when someone sees a cert that you don't think is yours. For example, I can look at my old university's computer society's CT log and see that they switched from StartCom to Let's Encrypt when everyone stopped trusting StartCom last year and see that their last three certificates all have different public keys, which implies that either someone is rapidly rolling over certs for no reason and is a numpty, or that someone else is playing silly buggers.
He doesn't have a visa, he has a visa waiver (ESTA). Anyone who doesn't need a visa to visit the US needs to pay $14 to fill in a web form that contains the same information that you'll give to the airlines and which the airlines are required by law to provide to the US government. In return, this data is entered into a database. It specifically does not grant you permission to enter the US (though you can't enter the US without paying the $14). This replaces the old green visa waiver form that you used to have to fill in on the plane prior to landing.
Smart phones existed probably a decade before Apple. Did you have one?
Yup, actually I had my second smartphone when the iPhone came out.
Part of the problem was the earliest smart phones did not yet have the technology to be practical (Wifi, powerful yet efficient CPUs, etc).
The WiFi was fine and, unlike the first iPhone, it supported SIP calling out of the box. At the time, I was paying 30p/minute for mobile calls, 1p/minute for SIP calls, so the £50 smartphone paid for itself pretty quickly. The screen, on the other hand, was tiny and crap.
The other problem was that most of the UIs were thinly veiled desktop computer designs
No they weren't. The mostly ran Series 60, which was a direct descendant of Psion's EPOC UI, from early '90s palmtop computers. Windows Mobile's market share was a rounding error. They were a massive pain to program for and the complete lack of uniformity in screen shapes, let alone sizes, made portable UIs basically impossible.
It's worth noting that this only really applies to the US market and US smartphone makers had a tiny share of the market prior to the iPhone. Nokia alone had 76% of the market and did well selling feature phones and a few smartphones via carriers, but most of their smartphones direct to customers.
The big difference between Apple and Nokia's offerings was in the userland programming environment. Nokia started with the best mobile development platform from mobile devices back when 256KB of RAM was a lot, and slowly evolved it to adapt to the world where 4MB was a lot. By the time 64MB was a lot they really had to throw it away and start again, but their internal corporate structure meant that they ended up with half a dozen replacements competing and couldn't get much traction with third-party apps.
In contrast, Apple started with the best workstation programming environment from the early '90s[1] when 8MB of RAM was enough and ripped out some of the optimisations that traded programmer effort for memory efficiency. This put them in a good position to encourage third-party developers and they also set up a better distribution channel.
Nokia smartphones could run third-party apps (they wouldn't be smartphones if they couldn't), but they rarely did. The smartphone app market prior to the iPhone 2 was similar to the mainframe software market prior to System/360: almost every new model from each vendor required you to port, if not completely rewrite, your code. This is the big change that iOS and Android caused, and the LG Prada contributed nothing to this shift.
[1] Seriously. If you haven't read the OpenStep specification, you should. It's a beautiful piece of API design. It's a little bit dated now, but I've not seen anything since that manages to be as concise and clear and uniform. Cocoa has accumulated some cruft since then, but the core ideas are there. Unfortunately, since Steve Naroff retired there's no one in Apple's toolchain group left that actually understands what made Objective-C a good language.
Try visiting Romania, Israel, or South Korea and you'll see something very different. Then go home and wonder what your country is doing to put talented women off pursuing a career in technology.
The device I'd actually recommend is a tablet that comes with an OS that comes with a default security policy that only allows it to run sandboxed apps, that is easy to back up, and that runs the applications that they need to use. Currently, that means a tablet or phone, though the MS Surface laptop thingies would also work.
You can. If you want it, I can put you in touch with a couple of companies that will offer you a fixed FreeBSD version with security backports. One of them was supporting FreeBSD 2.2.x[1] until a couple of years ago (not quite 20 years of support, but close). I know of at least one major US bank that runs FreeBSD 6 internally (and have only just finished their upgrade) and are paying for security backports and the occasional feature backport. The lack of SMP support was what eventually caused the last 2.x users to migrate: there are a bunch of things in new CPUs that required some reworking of kernel internals and it was cheaper to upgrade than try to backport them (and the backport would have looked so much like the new system that it wasn't worth it).
The community doesn't want to support a release for more than 5 years, but with any open source project with a decent-sized userbase you'll find a bunch of third parties that will happily take your money for longer support if you want it. Of course, it gets more expensive if you want other things, such as X11, some GNOME or KDE release, or whatever supported.
The real problem is there isn't a single entity that makes it easy to split the costs of doing so. The UK government could probably afford it quite easily, but most of these procurement decisions are made locally and the Metropolitan Police probably couldn't. You really need a critical mass of people to buy into the idea and split the costs between them: being the first (or only) customer wanting this is expensive!
You're paying anyway. Your choice is either pay Microsoft millions each year to get the bugs that Microsoft thinks are important fixed, have an upgrade cycle defined by Microsoft, and have new features that Microsoft thinks that people will like forced on you, or pay a similar amount to a company to support an open source system with the bugs and features that you care about prioritised and major version upgrades on a schedule that you define. In the former case, if you're unhappy, then sucks to be you. In the latter case, if you're unhappy then there are a dozen other companies begging to take the support contract away from your supplier.
Most tablets support bluetooth keyboards these days, so when you're typing a lot you can use that. Most also support HDMI output, so you can dock them with a monitor if you need a larger display. The iPad Pro and MS Surface tablets offer a keyboard built into the case for when you're mobile, some Android tablets come with dockable keyboards.
Slashdot Mirror
Rather than speculating, you might want to look at what happened with a similar regulation on white goods. For the most part, these are made from components supplied by third parties and so the immediate knock-on effect was that dishwasher makers demanded long-term support for components from their suppliers. The suppliers turned around and said 'sure, but for a limited range'. This meant that almost all models of dishwasher are now built using a few standard components (including the electronics), which are guaranteed to be available for a long period. Because the component suppliers now have better economies of scale, the cost of manufacturing went down. Most manufacturers kept their prices the same, but a few dropped their price a lot to pass this on to consumers. The end result, for the consumer, is that dishwashers are cheaper and if they break down the parts are easier to obtain and cheaper. Sorry if this upsets your 'all regulation is bad' narrative.
noreply@ is probably the least spammed address - I bet most spam lists remove it in an automatic pass. I can see why he wants to keep it...
They normally don't sue for violations of the GPL for non-GNU software
They don't sue for any software for which they do not own the copyright, because they would not have standing in court and the case would never make it to court.
but they make an exception for Linux
Really? And which court didn't throw this out without a hearing?
The problem is the network effect. The value of Facebook provided by Facebook is negligible, but the value of Facebook provided by your friends is significant. It's hard to be the one person in a social group that doesn't use Facebook. That said, I keep hearing how good Facebook is for organising things, so why not encourage your Facebook-using friends to use it to all agree to quit at the same time: if half of your friends don't quit Facebook, then the value of Facebook is suddenly a lot lower.
Those poor American companies. All they were doing was engaging in unethical behaviour that the weak regulatory culture of the US permits, and now they're not being allowed to do the same thing in Germany, where companies that had to abide by modest standards of acceptable behaviour couldn't compete!
Next thing you know, you'll be saying that Chinese companies can't set up factories in America and employ people for $2/day working 16-hour days and dump their waste products directly in the Mississippi! After all, that's all completely acceptable under the regulatory regime in their own country - it's the fault of American companies if they can't compete in manufacturing with their innovative Chinese competitors.
I'd love to see that IQ study, because it doesn't reflect any results that I've seen. That said, there are a number of studies that show that men (particularly from teenage years to their mid 20s) are more inclined towards risk-taking behaviour (though a more recent study indicates that this is a conditioned behaviour because men are more likely to be rewarded for risk-taking behaviour). This skews a number of common assessment methods, where different preparation strategies can lead either to top scores with a significant risk of low scores, or to mid-range scores with little risk. This doesn't indicate different abilities between men and women, it indicates that the assessment methodology is flawed (unless your exam is explicitly intended to measure risk-taking behaviour or some trait that correlates strongly with risk-taking behaviour).
its naieve[sic] and factually incorrect to suggest that both sexes have identical abilities.
It's naive and factually incorrect to suggest that any pair of individuals have identical abilities. Or are you trying to imply that women are inherently worse at mathematical disciplines than men? Because, if so, there is pretty much no evidence that this is the case when you factor out cultural differences (and if you don't then you can easily find groups where either gender is dominant in the field).
Perhaps we need to get rid of Linux kernel as well.
Well, that would make the BSD advocates happy...
More seriously, the biggest Linux vendor (Google) is currently doing that and moving to their Magenta microkernel, which can run a lot of things in userspace at a lower privilege level. Even within the world of monolithic kernels, a lot of things are moving out of the kernel (ironically, for performance reasons: the same reason that they moved in there in the first place). GPU drivers are now almost entirely userspace: the kernel component maps device registers into a process' address space, manages the IOMMU so that memory is shared between the GPU and the process, and then largely gets out of the way. High-end network cards have done this for a while, but NetMap (in the default kernel on FreeBSD, available as patches for Linux) lets most NICs expose send and receive queues directly to userspace so that you can bypass the kernel network stack for very high performance networking with specialist workloads (there's a good chance that the last time you queried a DNS root server the response came from one of these). FreeBSD and XNU do low-latency sound mixing in the kernel, but most other systems do it in userspace. Most *NIX systems have a ugen device type that makes it easy to implement userspace drivers for USB devices and these are commonly used for MIDI and a number of other device types (for example, webcamd uses this to implement a load of webcam drivers in userspace). FUSE has allowed moving some filesystem drivers out of the kernel.
Some drivers are moved out because they don't care about performance (the computer is so much faster than the device that latency from an extra context switch doesn't matter) and the isolation is a win. Some are moved out because they really care about performance and the extra context switch to the kernel costs too much, and they're typically very complex so moving the untrusted code into userspace makes more sense. In both cases, there's a general trend towards having less stuff in the kernel.
CPython has always been a horrible implementation. It's not even at the standards of a 1980 implementation of Smalltalk in terms of performance and Python is easier to generate efficient code from than Smalltalk. HHVM is just amusing: for Facebook's use case, they could get away with never running the GC for most workloads, which would give them around a 30% performance increase... except that PHP makes it observable in the language whether an array has more than one reference and so they need to pay ref counting overhead on everything.
they made money selling weapons and then made money selling everything needed to rebuild europe/Asia. The USA was able to progress while other countries rebuilt
On top of that, the US and the USSR split the german scientists between them and US universities were in a position to offer top researchers from European cities much more resources if they relocated. Some left when the second world war looked inevitable, a lot more left after it finished when they got much better offers in the US and no longer had a sense of being unpatriotic abandoning their country in a time of war. Throughout the cold war, the US actively pursued a policy of encouraging the best minds from elsewhere to relocate.
On a side note, most clients seem to have way to many dependencies. I found a pure bash one without any dependencies
acme-client has no dependencies and is implemented as a small set of privilege-separated programs, so the thing that handles your private key and the things that makes network connections are entirely separated and the thing that an attacker might compromise runs with very limited privileges.
You can renew a lot more often. Renewals are only limited by the rate limits and these allow renewing even after you've hit the 20-certs-per-week limit for a domain. Acme-client on FreeBSD defaults to renewing every week, so even a few failures will not cause problems.
Self-signed certs are worse than plaintext from an HCI perspective, because they provide the appearance of security, while providing very little actual security.
In contrast, a cert signed by Let's Encrypt at least tells you that the example.com that you're talking to is the same one that the Let's Encrypt server was talking to. It's a lot easier to compromise a random WiFi AP than it is to compromise the connection in the datacentres that Let's Encrypt uses and a random WiFi AP.
The ACME protocol doesn't ever give Let's Encrypt your private key, so they can't compromise your key. They can issue other certs for your domain (but so can any CA), but if they do then they'll appear in the certificate transparency logs for your domain (if anyone visits them with a client that records things in CT logs, at least), so you'd see.
It demonstrates that the one holding the cert also holds the domain name. Nothing else. And nothing else is implied by the whole deal.
Not quite: the key exchange happens over HTTP and doesn't always use DNSSEC, so all that it actually proves is that the person issuing the certs was able to receive and reply to TCP packets going to the IP address that the Let's Encrypt server's DNS reported was associated with the domain name. That's a somewhat weaker guarantee (though no weaker than most non-EV certs).
Let's Encrypt also logs all certs with certificate transparency and so you can check (by grabbing the CT logs or using a web search) which certs have been issued for your domain and see if any of them don't match the public key that you think that you're using (and you can automate this from another machine). Chrome also reports certificates that it's seen to the CT logs, so you can spot when someone sees a cert that you don't think is yours. For example, I can look at my old university's computer society's CT log and see that they switched from StartCom to Let's Encrypt when everyone stopped trusting StartCom last year and see that their last three certificates all have different public keys, which implies that either someone is rapidly rolling over certs for no reason and is a numpty, or that someone else is playing silly buggers.
He doesn't have a visa, he has a visa waiver (ESTA). Anyone who doesn't need a visa to visit the US needs to pay $14 to fill in a web form that contains the same information that you'll give to the airlines and which the airlines are required by law to provide to the US government. In return, this data is entered into a database. It specifically does not grant you permission to enter the US (though you can't enter the US without paying the $14). This replaces the old green visa waiver form that you used to have to fill in on the plane prior to landing.
Smart phones existed probably a decade before Apple. Did you have one?
Yup, actually I had my second smartphone when the iPhone came out.
Part of the problem was the earliest smart phones did not yet have the technology to be practical (Wifi, powerful yet efficient CPUs, etc).
The WiFi was fine and, unlike the first iPhone, it supported SIP calling out of the box. At the time, I was paying 30p/minute for mobile calls, 1p/minute for SIP calls, so the £50 smartphone paid for itself pretty quickly. The screen, on the other hand, was tiny and crap.
The other problem was that most of the UIs were thinly veiled desktop computer designs
No they weren't. The mostly ran Series 60, which was a direct descendant of Psion's EPOC UI, from early '90s palmtop computers. Windows Mobile's market share was a rounding error. They were a massive pain to program for and the complete lack of uniformity in screen shapes, let alone sizes, made portable UIs basically impossible.
It's worth noting that this only really applies to the US market and US smartphone makers had a tiny share of the market prior to the iPhone. Nokia alone had 76% of the market and did well selling feature phones and a few smartphones via carriers, but most of their smartphones direct to customers.
The big difference between Apple and Nokia's offerings was in the userland programming environment. Nokia started with the best mobile development platform from mobile devices back when 256KB of RAM was a lot, and slowly evolved it to adapt to the world where 4MB was a lot. By the time 64MB was a lot they really had to throw it away and start again, but their internal corporate structure meant that they ended up with half a dozen replacements competing and couldn't get much traction with third-party apps.
In contrast, Apple started with the best workstation programming environment from the early '90s[1] when 8MB of RAM was enough and ripped out some of the optimisations that traded programmer effort for memory efficiency. This put them in a good position to encourage third-party developers and they also set up a better distribution channel.
Nokia smartphones could run third-party apps (they wouldn't be smartphones if they couldn't), but they rarely did. The smartphone app market prior to the iPhone 2 was similar to the mainframe software market prior to System/360: almost every new model from each vendor required you to port, if not completely rewrite, your code. This is the big change that iOS and Android caused, and the LG Prada contributed nothing to this shift.
[1] Seriously. If you haven't read the OpenStep specification, you should. It's a beautiful piece of API design. It's a little bit dated now, but I've not seen anything since that manages to be as concise and clear and uniform. Cocoa has accumulated some cruft since then, but the core ideas are there. Unfortunately, since Steve Naroff retired there's no one in Apple's toolchain group left that actually understands what made Objective-C a good language.
Try visiting Romania, Israel, or South Korea and you'll see something very different. Then go home and wonder what your country is doing to put talented women off pursuing a career in technology.
The device I'd actually recommend is a tablet that comes with an OS that comes with a default security policy that only allows it to run sandboxed apps, that is easy to back up, and that runs the applications that they need to use. Currently, that means a tablet or phone, though the MS Surface laptop thingies would also work.
You can. If you want it, I can put you in touch with a couple of companies that will offer you a fixed FreeBSD version with security backports. One of them was supporting FreeBSD 2.2.x[1] until a couple of years ago (not quite 20 years of support, but close). I know of at least one major US bank that runs FreeBSD 6 internally (and have only just finished their upgrade) and are paying for security backports and the occasional feature backport. The lack of SMP support was what eventually caused the last 2.x users to migrate: there are a bunch of things in new CPUs that required some reworking of kernel internals and it was cheaper to upgrade than try to backport them (and the backport would have looked so much like the new system that it wasn't worth it).
The community doesn't want to support a release for more than 5 years, but with any open source project with a decent-sized userbase you'll find a bunch of third parties that will happily take your money for longer support if you want it. Of course, it gets more expensive if you want other things, such as X11, some GNOME or KDE release, or whatever supported.
The real problem is there isn't a single entity that makes it easy to split the costs of doing so. The UK government could probably afford it quite easily, but most of these procurement decisions are made locally and the Metropolitan Police probably couldn't. You really need a critical mass of people to buy into the idea and split the costs between them: being the first (or only) customer wanting this is expensive!
[1] 2.x was released in 1994.
[2] 6 was released in 2005
You're paying anyway. Your choice is either pay Microsoft millions each year to get the bugs that Microsoft thinks are important fixed, have an upgrade cycle defined by Microsoft, and have new features that Microsoft thinks that people will like forced on you, or pay a similar amount to a company to support an open source system with the bugs and features that you care about prioritised and major version upgrades on a schedule that you define. In the former case, if you're unhappy, then sucks to be you. In the latter case, if you're unhappy then there are a dozen other companies begging to take the support contract away from your supplier.
Most tablets support bluetooth keyboards these days, so when you're typing a lot you can use that. Most also support HDMI output, so you can dock them with a monitor if you need a larger display. The iPad Pro and MS Surface tablets offer a keyboard built into the case for when you're mobile, some Android tablets come with dockable keyboards.
Do you have a better word to describe this phenomena than “privilege”?
Yes: luck.
Science is a tool. Tools cannot be biased
I present to you the ratchet screwdriver.