I visited my mother (in rural France) over Christmas, where she gets about 10/1. I'd agree that 10Mb/s down is pretty reasonable as an absolute minimum, but 1Mb/s up is quite painful.
In 2002, I was in a shared house where we decided to pay extra to get the 1Mb/s service from the cable company (their default was 512Kb/s). I stayed on their top tier until it got to 10Mb/s. At that point, I stayed on the 10Mb/s service until it was the cheapest that they offered, then it became 20Mb/s and then 30Mb/s. My most recent move was to a house without cable service, but with FTTH. I'm on their slowest service, which is 54Mb/s down, 9.5Mb/s up. I don't notice much difference between 10 and 54Mb/s downstream, but the difference between 1 and 9.5Mb/s upstream is enormous.
You might want to look up the term 'natural monopoly'. Even in places where there is no legally enforced local monopoly, you almost always see a monopoly or, at best, a duopoly. Laying cable to houses is expensive. You typically only see a return on investment after 5-10 years. That's fine for a telecoms or cable monopoly, because they know that in 10 years they'll still be the default choice for you (or, at worst, they have a 50-50 chance of being your first choice, so if they install 100 lines they'll expect at least 50 customers). It's not a great business model for anyone else.
In the UK, the places where we have a duopoly exist because the government prevented our national telco monopoly from offering TV services, which allowed a bunch of regional monopoly cable companies to start up. We only saw two trying to compete in a handful of places, because it's very hard to compete with an incumbent and much cheaper to start a new company somewhere where there isn't competition. These local monopolies gradually merged and now we have precisely one cable company for the entire country.
The biggest improvement to competition for our ISPs came from two things. The first was splitting the telco monopoly into wholesale and retail arms, with a requirement that the wholesale arm offers other ISPs access to their products at the same rate that they offer them to their retail arm (this at least gives us the illusion of competition, though you really have lots of companies offering basically the same thing for basically the same price, with the price set by a third party).
The other thing was the legal enforcement of local loop unbundling, where third parties were allowed to install their own equipment to terminate the last mile connections at exchanges. This has allowed some companies to offer a competing service, run over the same last mile as the incumbent telco, but with their own back-haul and so on. It's fairly limited though, because it requires quite a large investment at the exchange and is only worth doing if you have a lot of customers wanting to switch in an area. It's completely unavailable in the rural areas with the worst service.
If you think you can make money as an ISP laying your own network, then you're very welcome to come to the UK and try it. The government won't get in your way, and may even pay you to connect up people in certain areas. You might find it difficult to get investors though, because aside from a few small companies in very dense areas (there's one FTTP company in the middle of London with a few thousand customers, which currently offers the fastest speeds of any UK ISP), everyone else who has tried has failed.
I don't know how much a difference it makes, but you do absorb a lot more radiation in a plane than on the ground, and I fly enough that I'd prefer to minimise this.
Telegram still requires a centralised server, which is proprietary. I'm keeping an eye on both GNU Ring and Tox. Of the two, Tox is a lot more polished, but is still not yet able to support multiple client devices with the same account (it's nontrivial to do in a system with end-to-end security), but that's not an issue for people who use these things exclusively on their mobile phones.
I think it would be premature at this point to start buying new processors. I believe that there are a number of related vulnerabilities that will emerge over the next year and I wouldn't want to guess which processors are vulnerable (well, anything in-order, with no branch predictor is probably fine).
This has been concerning me for a little while. CPUs have come with a lot of performance improvements over the last 20-30 years that have introduced nondeterminism into execution timings and have regarded side channels as a software problem. It now appears that, as with memory protection, software solutions are largely inadequate and it's going to be a big challenge to retain the CPU performance that we're accustomed to.
AMD people shouldn't be too gleeful. They're happy because their processors don't speculate across protection level crossings. If you don't think about timing attacks, then that's not such a good thing: it means that every system call is a pipeline stall, whereas the Intel chip will keep executing into the system call without a stall. All of the fixes for the next few years are likely to be like that: lose something that gives a performance increase to get back some security.
You're assuming that the attacker has no control over their placement. The only person who is going to see leaks from these vulnerabilities is someone who is actively running the exploit (you don't just get someone else's memory in your address space, you have to scan it one bit at a time). If I wanted to exploit this, I'd spin up a bunch of VMs in Amazon, Google, and Microsoft's clouds and start scanning. I would not be actively targeting your company, but if I saw anything confidential and valuable then I'd be able to tie it back to your company and either sell it to someone who wanted to take advantage of it or use it directly. I'm not planning on doing this, but the people who are will probably be in Russia, China, North Korea, or other places where it's really hard to get any legal recourse.
In contrast, if someone within your own company is attempting to access data that they shouldn't, then you can terminate their employment and you may even be able to prosecute them.
If you want to see a really stupid protectionist law, take a look at the Fly America Act. Anyone being paid by the US government must fly on a US flag carrier, unless it would add 3 stops or 6 hours to the trip. This means that you typically end up paying more, and often still fly on a plan operated by a non-US carrier due to code shares. Great use of taxpayers' money...
I've only flown one a 787 once (United, Economy Plus), but it was far nicer than economy class on any other aircraft I've flown in, by any operator. The air pressure and oxygen content was noticeably higher, so I didn't get dry eyes or skin at the end, I got a few hours of deep, restful, sleep, and I even managed a few hours of productive work. The seat recline was more sensible, sliding forwards at the bottom so you increased the legroom of the person behind when you went forward. In-seat power worked well and meant that I landed with my laptop fully charged, even after a few hours of work. The ceiling was higher, making the plane feel spacious.
Given the option, I'd still rather teleport, but if I have to fly then I'd prefer a 787 to anything else I've flown in.
Except at takeoff and landing, mostly you can see clouds through the window. And the reflected sunlight is so bright (white clouds, thinner atmosphere) that you're better off not looking at it for too long if you don't want to damage your eyes.
If I want to get up, I don't have to climb over someone (and getting up periodically and stretching your legs on a long flight is a good idea for avoiding DVT).
Most of the time, I can stretch my legs out into the aisle.
I can get up and go as soon as the fasten seatbelts sign goes off, usually getting near the front of the queue for immigration / customs.
It's easier to flag down a flight attendant.
The person between me and the sun gets to act as a radiation shield (thanks!).
Pay cash for things, donâ(TM)t finance them (and leasing is financing, do not assume it is advantageous to you). You will quickly find that your relationship with money and your overall financial status with both get better.
Financing isn't always bad. In particular, it's fine when either the thing that you're financing is an appreciating asset that will appreciate at a higher rate than the interest, when the cost of owning including interest is significantly lower than the cost of not owning, or when you can afford to pay cash and the interest is lower than you can get on savings / investments minus tax. Some concrete examples:
When I bought my first new laptop, the manufacturer was offering 10 months interest free financing. At the time, I was getting around 4.5% tax free on savings. This meant that, for the 10 months, I had an average of £1000 (around £2000 total cost) more in savings. At the end, I was about £35 better off than if I'd paid cash up front (which I could have afforded to do). Often, this kind of financing is available to let the company either increase sales or spread their costs and income around between cash years (or move them to different subsidiaries entirely). They're a bad deal for you if you can't afford to pay cash, but if you can then they're basically free money.
When I bought my first house, I was spending £350/month renting (and had high utility bills because the place had terrible insulation). After I bought, I was spending £100/month on interest, and another £50-70 or so on maintenance. My heating costs dropped by about 50%. I ended up about £200/month better off (which mostly went into paying back the mortgage early, and that £100/month dropped quite quickly as a result).
Only the most recent version of the CAMBUS standard has client authentication. Until then, a lot of cars shipped with entertainment systems and engine management systems connected to the same unauthenticated bus, so a compromise in your entertainment system could, for example, control your brakes. Oh, and a bunch of those entertainment systems run old and unpatched versions of Android...
And there's absolutely no way in which an attacker with the ability to exfiltrate SSH private keys, root passwords, and so on could possibly corrupt, modify, or delete data.
That's the overhead for a getpid benchmark. The overhead comes on context switch to the kernel. For anything where the kernel actually does a lot of work on behalf of userspace, the overhead will be less.
JavaScript can allocate an 8MB typed array object. It can then poke addresses in it to guarantee eviction of certain cache lines. To perform this kind of attack, it then needs only to jump to a vulnerable address, which is almost certainly possible via the DOM (many DOM actions will trigger system calls on behalf of JavaScript).
The problems with advertising started after the second world war, when advertisers started adopting techniques developed for propaganda. Lots of people will tell you that adverts have no effect on them, but ask them to name three brands of toothpaste and I can guarantee that they'll all be ones that they've seen adverts for, that they'll buy one of the first three that pops into their heads, and that they won't be able to cite a single clinical study that tells them that it's better than (or even as good as) any other one.
This got far worse with modern Internet advertising. Broadcast adverts (billboards, TV, Radio, and so on) had to work with an average psychological profile, but companies like Google, Facebook and Amazon can collect enough information about individuals to put them into one of a hundred or a thousand far more accurate buckets so that adverts can be tailored directly to manipulate them.
These days, advertising is basically evil. The days when an advert was telling you about a product and giving you information to make an informed decision are long gone.
Do you still have that opinion after the more recent disclosure from Google's Project Zero that at least some AMD chips are vulnerable? What would your opinion have been if Intel had only submitted patches enabling the fix for Intel's chips and it had turned out that at least some AMD chips are vulnerable?
Having looked at the attack now that it's public, I'd be quite surprised if most superscalar chips weren't vulnerable.
Not using REP MOVESB is actually a good thing even on some Intel microarchitectures. The cost of that relative to a loop is very variable. Centaur x86 chips will recognise the copy-a-byte-at-a-time loop in microcode and replace it entirely with their own faster memcpy microcode (unless you have breakpoint or watchpoint registers set). The SIMD versions are also not always best. They are on Intel, though the exact set of SSE / AVX instructions that runs fastest varies between microarchitectures (the AVX version is slower on some, even when they support SIMD). A few non-Intel chips have advertised SSE instructions, but cracked them down to a sequence of scalar ops that end up being slower than the equivalent scalar code (early Intel Atoms also cracked 128-bit SSE operations into pairs of 64-bit micro-ops, though these were generally still faster than the scalar equivalents).
SIP is basically the flags part of BSD securelevel 1. At securelevel 1 you can set the user and system immutable flags, but you can't remove them. If you want to, you need to reboot at securelevel 0 (or -1), use chflags to remove the relevant flags, and then delete the files (you can always increase the securelevel, you can't lower it without a reboot). On most BSD systems, securelevel 1 comes with some other restrictions related to opening certain devices, which are not enforced by XNU for SIP. This functionality dates back to 4.4BSD.
And, immediately after posting that, I discovered the pkgutil tool, so you should replace the lsbom command with 'pkgutil --files {bundle identifier}'. It still doesn't include an uninstall command (though it does allow you to repair and verify installed packages).
Apple has a standard.pkg format and a standard tool for installing, but no standard way of uninstalling. Most apps are just bundles (folders that appear to be single files in the GUI unless you right-click and say 'show contents') and so are uninstalled by simply deleting them (and are installed by just dragging them to where you want them to live), so this isn't a problem for most things. It is annoying for other things though, and sufficiently annoying that there are third-party tools that will read the manifest from a.pkg file and delete everything for you (.pkg files install a plist containing all of the things that they've installed in/Library/Receipts).
Most things installed from.pkg files can be uninstalled by running 'lsbom -pf/Library/Receipts/{installer name} | xargs rm -rf ', but that doesn't help you if it ran some post-install script that put files elsewhere.
SIP can be disabled. Generally, you don't want to, because it does what it says: protects the integrity of the system, by preventing the user from modifying system files. If you really want to, then reboot into recovery mode, disable SIP, and then reboot into normal mode. This is no different from the procedure for lowering the default securelevel on a BSD system (reboot to single-user mode, tweak the config file, boot to multiuser), does that mean that when you use FreeBSD then the FreeBSD project owns your computer?
Or copies that ended up in backups, or copies that were on engineers machines that were lost, and so on. It's nice of them to try, but the general rule of data is that the only way you can guarantee that something is completely deleted is to make sure that something important depends on it and rely on Murphy's Law.
It will incur overhead, because you'll still use two TLB entries for every address that's accessed by both kernel and userspace. I believe (though I'm not 100% sure) that a cr3 modification involves a complete pipeline flush on AMD, so will have a high overhead for cheap system calls. The GrSecurity benchmarks had very high overhead on AMD, but I don't know what the root cause was.
I visited my mother (in rural France) over Christmas, where she gets about 10/1. I'd agree that 10Mb/s down is pretty reasonable as an absolute minimum, but 1Mb/s up is quite painful.
In 2002, I was in a shared house where we decided to pay extra to get the 1Mb/s service from the cable company (their default was 512Kb/s). I stayed on their top tier until it got to 10Mb/s. At that point, I stayed on the 10Mb/s service until it was the cheapest that they offered, then it became 20Mb/s and then 30Mb/s. My most recent move was to a house without cable service, but with FTTH. I'm on their slowest service, which is 54Mb/s down, 9.5Mb/s up. I don't notice much difference between 10 and 54Mb/s downstream, but the difference between 1 and 9.5Mb/s upstream is enormous.
You might want to look up the term 'natural monopoly'. Even in places where there is no legally enforced local monopoly, you almost always see a monopoly or, at best, a duopoly. Laying cable to houses is expensive. You typically only see a return on investment after 5-10 years. That's fine for a telecoms or cable monopoly, because they know that in 10 years they'll still be the default choice for you (or, at worst, they have a 50-50 chance of being your first choice, so if they install 100 lines they'll expect at least 50 customers). It's not a great business model for anyone else.
In the UK, the places where we have a duopoly exist because the government prevented our national telco monopoly from offering TV services, which allowed a bunch of regional monopoly cable companies to start up. We only saw two trying to compete in a handful of places, because it's very hard to compete with an incumbent and much cheaper to start a new company somewhere where there isn't competition. These local monopolies gradually merged and now we have precisely one cable company for the entire country.
The biggest improvement to competition for our ISPs came from two things. The first was splitting the telco monopoly into wholesale and retail arms, with a requirement that the wholesale arm offers other ISPs access to their products at the same rate that they offer them to their retail arm (this at least gives us the illusion of competition, though you really have lots of companies offering basically the same thing for basically the same price, with the price set by a third party).
The other thing was the legal enforcement of local loop unbundling, where third parties were allowed to install their own equipment to terminate the last mile connections at exchanges. This has allowed some companies to offer a competing service, run over the same last mile as the incumbent telco, but with their own back-haul and so on. It's fairly limited though, because it requires quite a large investment at the exchange and is only worth doing if you have a lot of customers wanting to switch in an area. It's completely unavailable in the rural areas with the worst service.
If you think you can make money as an ISP laying your own network, then you're very welcome to come to the UK and try it. The government won't get in your way, and may even pay you to connect up people in certain areas. You might find it difficult to get investors though, because aside from a few small companies in very dense areas (there's one FTTP company in the middle of London with a few thousand customers, which currently offers the fastest speeds of any UK ISP), everyone else who has tried has failed.
I don't know how much a difference it makes, but you do absorb a lot more radiation in a plane than on the ground, and I fly enough that I'd prefer to minimise this.
Telegram still requires a centralised server, which is proprietary. I'm keeping an eye on both GNU Ring and Tox. Of the two, Tox is a lot more polished, but is still not yet able to support multiple client devices with the same account (it's nontrivial to do in a system with end-to-end security), but that's not an issue for people who use these things exclusively on their mobile phones.
I think it would be premature at this point to start buying new processors. I believe that there are a number of related vulnerabilities that will emerge over the next year and I wouldn't want to guess which processors are vulnerable (well, anything in-order, with no branch predictor is probably fine).
This has been concerning me for a little while. CPUs have come with a lot of performance improvements over the last 20-30 years that have introduced nondeterminism into execution timings and have regarded side channels as a software problem. It now appears that, as with memory protection, software solutions are largely inadequate and it's going to be a big challenge to retain the CPU performance that we're accustomed to.
AMD people shouldn't be too gleeful. They're happy because their processors don't speculate across protection level crossings. If you don't think about timing attacks, then that's not such a good thing: it means that every system call is a pipeline stall, whereas the Intel chip will keep executing into the system call without a stall. All of the fixes for the next few years are likely to be like that: lose something that gives a performance increase to get back some security.
You're assuming that the attacker has no control over their placement. The only person who is going to see leaks from these vulnerabilities is someone who is actively running the exploit (you don't just get someone else's memory in your address space, you have to scan it one bit at a time). If I wanted to exploit this, I'd spin up a bunch of VMs in Amazon, Google, and Microsoft's clouds and start scanning. I would not be actively targeting your company, but if I saw anything confidential and valuable then I'd be able to tie it back to your company and either sell it to someone who wanted to take advantage of it or use it directly. I'm not planning on doing this, but the people who are will probably be in Russia, China, North Korea, or other places where it's really hard to get any legal recourse.
In contrast, if someone within your own company is attempting to access data that they shouldn't, then you can terminate their employment and you may even be able to prosecute them.
If you want to see a really stupid protectionist law, take a look at the Fly America Act. Anyone being paid by the US government must fly on a US flag carrier, unless it would add 3 stops or 6 hours to the trip. This means that you typically end up paying more, and often still fly on a plan operated by a non-US carrier due to code shares. Great use of taxpayers' money...
I've only flown one a 787 once (United, Economy Plus), but it was far nicer than economy class on any other aircraft I've flown in, by any operator. The air pressure and oxygen content was noticeably higher, so I didn't get dry eyes or skin at the end, I got a few hours of deep, restful, sleep, and I even managed a few hours of productive work. The seat recline was more sensible, sliding forwards at the bottom so you increased the legroom of the person behind when you went forward. In-seat power worked well and meant that I landed with my laptop fully charged, even after a few hours of work. The ceiling was higher, making the plane feel spacious.
Given the option, I'd still rather teleport, but if I have to fly then I'd prefer a 787 to anything else I've flown in.
Except at takeoff and landing, mostly you can see clouds through the window. And the reflected sunlight is so bright (white clouds, thinner atmosphere) that you're better off not looking at it for too long if you don't want to damage your eyes.
Pay cash for things, donâ(TM)t finance them (and leasing is financing, do not assume it is advantageous to you). You will quickly find that your relationship with money and your overall financial status with both get better.
Financing isn't always bad. In particular, it's fine when either the thing that you're financing is an appreciating asset that will appreciate at a higher rate than the interest, when the cost of owning including interest is significantly lower than the cost of not owning, or when you can afford to pay cash and the interest is lower than you can get on savings / investments minus tax. Some concrete examples:
When I bought my first new laptop, the manufacturer was offering 10 months interest free financing. At the time, I was getting around 4.5% tax free on savings. This meant that, for the 10 months, I had an average of £1000 (around £2000 total cost) more in savings. At the end, I was about £35 better off than if I'd paid cash up front (which I could have afforded to do). Often, this kind of financing is available to let the company either increase sales or spread their costs and income around between cash years (or move them to different subsidiaries entirely). They're a bad deal for you if you can't afford to pay cash, but if you can then they're basically free money.
When I bought my first house, I was spending £350/month renting (and had high utility bills because the place had terrible insulation). After I bought, I was spending £100/month on interest, and another £50-70 or so on maintenance. My heating costs dropped by about 50%. I ended up about £200/month better off (which mostly went into paying back the mortgage early, and that £100/month dropped quite quickly as a result).
Only the most recent version of the CAMBUS standard has client authentication. Until then, a lot of cars shipped with entertainment systems and engine management systems connected to the same unauthenticated bus, so a compromise in your entertainment system could, for example, control your brakes. Oh, and a bunch of those entertainment systems run old and unpatched versions of Android...
And there's absolutely no way in which an attacker with the ability to exfiltrate SSH private keys, root passwords, and so on could possibly corrupt, modify, or delete data.
That's the overhead for a getpid benchmark. The overhead comes on context switch to the kernel. For anything where the kernel actually does a lot of work on behalf of userspace, the overhead will be less.
JavaScript can allocate an 8MB typed array object. It can then poke addresses in it to guarantee eviction of certain cache lines. To perform this kind of attack, it then needs only to jump to a vulnerable address, which is almost certainly possible via the DOM (many DOM actions will trigger system calls on behalf of JavaScript).
I used to have a housemate who particularly enjoyed drinking his Pepsi from a Coke-branded glass.
The problems with advertising started after the second world war, when advertisers started adopting techniques developed for propaganda. Lots of people will tell you that adverts have no effect on them, but ask them to name three brands of toothpaste and I can guarantee that they'll all be ones that they've seen adverts for, that they'll buy one of the first three that pops into their heads, and that they won't be able to cite a single clinical study that tells them that it's better than (or even as good as) any other one.
This got far worse with modern Internet advertising. Broadcast adverts (billboards, TV, Radio, and so on) had to work with an average psychological profile, but companies like Google, Facebook and Amazon can collect enough information about individuals to put them into one of a hundred or a thousand far more accurate buckets so that adverts can be tailored directly to manipulate them.
These days, advertising is basically evil. The days when an advert was telling you about a product and giving you information to make an informed decision are long gone.
Do you still have that opinion after the more recent disclosure from Google's Project Zero that at least some AMD chips are vulnerable? What would your opinion have been if Intel had only submitted patches enabling the fix for Intel's chips and it had turned out that at least some AMD chips are vulnerable?
Having looked at the attack now that it's public, I'd be quite surprised if most superscalar chips weren't vulnerable.
Not using REP MOVESB is actually a good thing even on some Intel microarchitectures. The cost of that relative to a loop is very variable. Centaur x86 chips will recognise the copy-a-byte-at-a-time loop in microcode and replace it entirely with their own faster memcpy microcode (unless you have breakpoint or watchpoint registers set). The SIMD versions are also not always best. They are on Intel, though the exact set of SSE / AVX instructions that runs fastest varies between microarchitectures (the AVX version is slower on some, even when they support SIMD). A few non-Intel chips have advertised SSE instructions, but cracked them down to a sequence of scalar ops that end up being slower than the equivalent scalar code (early Intel Atoms also cracked 128-bit SSE operations into pairs of 64-bit micro-ops, though these were generally still faster than the scalar equivalents).
SIP is basically the flags part of BSD securelevel 1. At securelevel 1 you can set the user and system immutable flags, but you can't remove them. If you want to, you need to reboot at securelevel 0 (or -1), use chflags to remove the relevant flags, and then delete the files (you can always increase the securelevel, you can't lower it without a reboot). On most BSD systems, securelevel 1 comes with some other restrictions related to opening certain devices, which are not enforced by XNU for SIP. This functionality dates back to 4.4BSD.
And, immediately after posting that, I discovered the pkgutil tool, so you should replace the lsbom command with 'pkgutil --files {bundle identifier}'. It still doesn't include an uninstall command (though it does allow you to repair and verify installed packages).
Apple has a standard .pkg format and a standard tool for installing, but no standard way of uninstalling. Most apps are just bundles (folders that appear to be single files in the GUI unless you right-click and say 'show contents') and so are uninstalled by simply deleting them (and are installed by just dragging them to where you want them to live), so this isn't a problem for most things. It is annoying for other things though, and sufficiently annoying that there are third-party tools that will read the manifest from a .pkg file and delete everything for you (.pkg files install a plist containing all of the things that they've installed in /Library/Receipts).
Most things installed from .pkg files can be uninstalled by running 'lsbom -pf /Library/Receipts/{installer name} | xargs rm -rf ', but that doesn't help you if it ran some post-install script that put files elsewhere.
SIP can be disabled. Generally, you don't want to, because it does what it says: protects the integrity of the system, by preventing the user from modifying system files. If you really want to, then reboot into recovery mode, disable SIP, and then reboot into normal mode. This is no different from the procedure for lowering the default securelevel on a BSD system (reboot to single-user mode, tweak the config file, boot to multiuser), does that mean that when you use FreeBSD then the FreeBSD project owns your computer?
Or copies that ended up in backups, or copies that were on engineers machines that were lost, and so on. It's nice of them to try, but the general rule of data is that the only way you can guarantee that something is completely deleted is to make sure that something important depends on it and rely on Murphy's Law.
It will incur overhead, because you'll still use two TLB entries for every address that's accessed by both kernel and userspace. I believe (though I'm not 100% sure) that a cr3 modification involves a complete pipeline flush on AMD, so will have a high overhead for cheap system calls. The GrSecurity benchmarks had very high overhead on AMD, but I don't know what the root cause was.