I think it's more an artefact of centralisation. The MPEG model kind-of makes sense in a world where there are lots of smallish companies that want to use a video CODEC (ideally an interoperable one). MPEG provided a model where they could all pay a small amount and share the R&D costs (not a great model, because only stuff that was both patented and pushed in made it, so Apple stayed there with a patent covering part of the QuickTime.mov file format and nothing else, academics who developed a bunch of the ideas but didn't patent them got nothing, smaller players with better patented ideas were worked around and ignored). The difference now is that there are a number of companies making so much from having a decent video CODEC that they can afford to cover the entire R&D costs themselves (e.g. Google with YouTube, Netflix, Apple with the iTunes store). Any of them working in isolation could produce a decent CODEC and save more in royalties than they'd spend on R&D. A group of them together will pay far less in total R&D and then end up with something that doesn't require any license accounting (saving them more).
AMD doesn't get to escape those costs by outsourcing
AMD doesn't escape them, but they get to share them. The cost of developing a new process tech is huge (on the order of $10bn+). If you're selling ten million chips, then that's $1,000 per chip. You need to get a good hundred million chips out of the fabs before they start to bring the cost per chip down low enough that you can sell them. Even adding a 20% profit margin on for Global Foundaries and others, AMD benefits far more from having to pay less than 40% of the total R&D costs than they lose from those costs increasing. This is why AMD spun out Global Foundaries in the first place: it's a hard sell to get people to make chips in your fabs if you might compete with them, but you need them to if you want to be able to cover the R&D costs. It also freed AMD to use other companies' fabs if theirs were not the best for a particular product, and they've been quite effective so far at doing this.
Even Intel is struggling to get the required economies of scale. They keep trying to get other people to use their fabs, but no one wants to use a fab where they're always going to be lower priority than Intel and where Intel may suddenly decide that they're competitors. They event threw in Atom IP cores basically for free for anyone willing to fab their SoCs with Intel. It didn't work.
Intel makes twice as much profit every quarter as AMD brings in in total sales so that means Intel's costs are lower than AMD's by a lot.
Again, that's a nonsense comparison. It's including Intel NICs, Intel SSDs, and all of the other things where Intel has a huge presence and AMD has none. It's like comparing McAffee to Microsoft in total revenue and profit and claiming that this gives a sensible comparison of their presence in the antivirus market.
They just pay another company to do it for them plus a profit margin too - at the end of the day they pay MORE
You really don't understand how economies of scale work in this market. Let's take that $10bn number (probably a lowball for the next generation). Let's assume that there's a 20% extra markup from getting a third party to do it (probably a bit high, because it's a fairly competitive market and someone like TSMC would happily take AMD's business if GF charges too much). Let's also assume that AMD is 40% of GF's total business (last time I looked, they were less than this). AMD has a choice of either paying $10bn in R&D costs, or paying $4bn plus a 20% markup ($4.8bn). Which do you think is easier to amortise across their production runs? Note: the cost of producing a wafer of chips is effectively noise. This is why you can get chips for close to nothing on an older fab: the operating costs are an almost irrelevant part of the total.
Unicode is arranged in code planes that make it easy to either blacklist the harmful ones or whitelist the normal-text ones. Slashdot doesn't do either. SoylentNews does, using a fork of Slashcode.
Intel is literally over 10X the size of AMD by revenue
That's slightly misleading, because it assumes that all of Intel is competing with all of AMD. They have some competing business units, but they are not entirely direct competitors. For example, Intel has a huge network business unit (NICs, ICs for switches) and a large storage division, one of the two largest FPGA manufacturers, and it owns its own fabs. AMD no longer owns its own fabs, so doesn't require the same economise of scale to get the cost per wafer down (the fabs that make AMD chips also make chips for a load of other companies, so can benefit from large economies of scale).
Just because Intel is ten times the size doesn't mean that Intel's x86 chips are getting ten times (or even double) the investment that AMDs are.
People tend to think of AMD as a close competitor but they aren't. Intel spends over double AMD's total revenue on R&D alone
The vast majority of that is on process technology, which is no longer a business that AMD is in (and where the returns have been very low for the past 5 years).
No other site has this problem. Slashdot advertises UTF-8 support in the meta tags in their HTML, but then doesn't support UTF-8. Other sites either don't advertise UTF-8 support, or actually support unicode (you know, the thing that's been the standard text encoding for 15-20 years).
Even if you do want to run server workloads on macOS, you're far better off installing the relevant packages from Homebrew and configuring them than trying to use the OS X Server GUIs, which make some common things very easy but anything slightly uncommon really hard and came with odd upgrade cycles.
The reason HCI experts oppose customisation is that it makes it difficult to move between computers. It doesn't matter for a single person on a computer that no one else uses, but in a corporate setting when people need to use each others computers, or even in a private setting with someone calling technical support, every customisation is a thing that makes your computer behave differently from what the other user expects. Good UIs are all about consistency: doing action X should cause operation B in all cases. If this changes when I look at a different computer that's running the same software stack, that's a problem. If you need to troubleshoot something on my computer, and none of the UI elements behave as you expect, that's a problem.
There's also a related issue that most people really suck at configuring things to maximise their own productivity. MSR and others did a bunch of research on this in the early '90s. The executive summary is that the configuration choice that people think makes them faster often actually makes them slower, but they don't subjectively count the time that they're sitting and thinking about the UI, because it's not the direct focus of their attention. In most studies, people who configured the UI as they liked ended up performing common tasks more slowly than ones that stayed with the defaults.
If you haven't looked recently, they released an updated version of the installer a couple of years back. I was pleased to discover a couple of years ago that I could enter my CD keys into Blizzard's web site and download an installer that ran D2 + LoD on my Intel Mac on a recent macOS. Unfortunately, it looks as if it's a 32-bit binary, so it may not work for much longer...
Alan Kay has done some work that shows that teaching students the actor model first gives better results (and gives students who can write parallel code as easily as serial code). A language like Erlang, but with syntax that doesn't assume that you're already fluent in Prolog, combined with some graphical tools for setting up communication channels would probably be a good starting point.
it can be done ahead of time by mail, FedEx, or even in person, using any medium, even paper
I'll agree with 'in person', but if you trust the mail or FedEx to be secure, then why not just use these services for the message and not bother with the encryption at all?
They probably do. Mine is now five years old and still works pretty well, but the problem is the software. It runs Android, so I can get third-party updates from LineageOS, but that's done by volunteers. How about taxing companies that stop producing software-updates for network-connected devices based on their sales and support lifetime and using that money to subsidise third-party development that keeps the devices in circulation?
Everything doesn't need to come in a cardboard box from Amazon
Why not? It's cheap cardboard made from recycled paper and it goes back for recycling. Having a single van that delivers things to me and a load of other people nearby is more efficient than all of us driving to the shops and a lot more convenient than all of us walking.
Last time I was in the bay area, most of the 'plastic' disposable things I picked up were compostable biomass. I've not seen them much elsewhere, so I don't know if there's some subsidy or penalty that means that it's only economically feasible in California, but it seemed like a good replacement.
It's worth noting that the failure of the P4 was to do with the fact that Intel (very unusually) mispredicted process improvements. The team running P4 development was expecting 5GHz at launch and 10GHz after a couple of years. Their designs worked at those speeds in the simulators, but the process technology didn't give the faster clocks that they expected. At 5GHz, the P4 would have smoked the Athlon for performance and at 10GHz it would have been incredible, but Intel hit an unexpected brick wall and never made it past 4GHz.
They don't have any sort of a versioned library subsystem where you can state that "I need the 10.6 version of Cocoa" and have the OS provide that to you, which is because OS X as a whole is so tightly coupled together with itself that you literally cannot have multiple versions of Cocoa sitting on the same machine.
This is so laughably untrue that I don't know where to start.
First, the OPENSTEP bundle format that Apple inherited from NeXT includes a concept of versioning in the loader. You can link either to the latest version of a framework, or explicitly to an older one, and you can ship multiple library binaries for different versions in the same framework, with the linker correctly finding the right one.
Second, each Mac application embeds a MacOS deployment target, which will put some APIs into compatibility modes if you invoke them on a newer system.
Third, all of the Apple headers include annotations about which versions of each of their operating systems introduced, deprecated, and removed APIs, so you can explicitly target older versions and get compiler errors if you use a newer API. I'm not sure why you think it's better for them to provide copies of older headers instead of doing this.
Fourth, a bunch of the APIs include constants that tell specific subsystems about the expected version. For example, each time they improve the line-breaking algorithm in the text layout engine, they bump an enum value so that code compiled with an older deployment target, or code that explicitly opts into the older behaviour for compatibility, will get the old behaviour.
I had a look, and there are only 2 32-bit apps on my macOS system currently running. One is the Android File Transfer thing, which can probably work in 64-bit mode without too much effort. The other is WINE, which is likely to be more effort because it will still need to run 32-bit PE/COFF binaries and handle transition to and from 32-bit mode.
I remember realising how much faster the Core 2 Duo was than the G4 when I noticed that VLC was using a little bit more CPU in Activity Monitor on my new MacBook Pro than on my old PowerBook: almost 80% of one core, when it had been closer to 60% (of the only core) on the old machine playing the same video. Then I realised that VLC wasn't a fat binary and I was still running the PowerPC version: even CPU-bound applications running in emulation were only slightly slower in the new machine. Switching to the Intel version of VLC dropped the CPU usage down to 10-20%.
That's true. There are; however, very few examples of perfectly working software. Most software requires ongoing maintenance to keep it working in a changing environment (new hardware, integration with other components and new or changed OS services). This maintenance costs money. Apple can either spend developer resources on maintaining the 32-bit versions of software years after they've stopped selling any 32-bit CPUs, or they can invest that in other things (such as better security audits). Given finite developer resources, I'd prefer that they spent their effort on things that will benefit most users.
A lot of the games (including a lot of the ones bought from GOG) that I run are 32-bit Windows binaries running in WINE. That said, it's not clear that WINE needs to actually be a 32-bit Mach-O binary: it already includes its own PE loader and a bunch of translation layers that turn Windows structures into host system structures. It could probably be a 64-bit binary that would switch to 32-bit mode before jumping into Windows code and back to 64-bit code before switching out.
I doubt that Apple wants to ship x86 chips without 32-bit support, they just don't want to ship 32-bit versions of all of the core libraries and this approach would address that problem.
Why? VMs have been able to do RS-232 pass-through for ages. About 10 years ago, I visited a company that had just moved their old DOS-based control software into a VM for precisely this reason: they could install a USB RS-232 adaptor on their host and expose an emulated RS-232 device to the VM. This was a lot easier than trying to port the software (most of which was 8086 assembly) or get a USB serial interface working with DOS. There was some overhead, but line rate on RS-232 is so slow that you can burn a lot of cycles on emulation without noticing.
Windows 10 uses the same kernel, libc, init system, display server, and core libraries as MS DOS? Microsoft is a lot better at code reuse than I thought!
US embassies use OTPs. I'm not surprised bits of the military use it. It's fine if you have a limited number of communication paths, trustworthy people with big guns who can carry the keys, and the ability to often have the people who are going to communicate in the same room. It would be fairly easy to create a OTP system for a family, for example, where their phones would all share random secrets over local WiFi / Bluetooth overnight, and then use those during the day. It's not so feasible for the relatives that live overseas.
Yup. I've also read some studies showing how non-random coin tosses are. They're fine for a single toss, but with enough data you're going to see patterns. Even without that, each coin toss gives you 1 bit of entropy. An SMS is 140 bytes (1,120 bits), so if you can toss a coin once per second it will take almost 20 minutes to generate the random number that will work as a OTP for a single text message.
Perhaps some dice?
Okay, ignoring the fact that most die are biassed and even ones that start perfect are biassed towards either the 1 or 6 by the act of printing or cutting the numbers, now we get 2.5 bits of entopy from each die roll. Now we're down to just over 7 minutes at one die roll per second to generate a OTP for an SMS. I actually do know of one company that has built an automatic die rolling machine to generate random numbers. It's fine for a 128-bit key (52 rolls), but if you want to use it as a OTP then it's going to be very slow.
I can spend $20 on flash memory. I will give me enough material to communicate with someone as much as I want by voice or text for a lifetime with zero chance of in-flight compromise by anyone ever.
That's true (unless you want to share videos), though that's $20 for every pair of communicating parties, plus the overhead of managing one thumb drive for everyone that you want to communicate with. That doesn't scale well.
Most cryptography in practical use today is dependent on secure random sources for secure operation
It's a question of quantity. Getting 128 bits of cryptographically secure noise is easy. Even if you think the NSA has compromised a bunch of hardware random number generators, it's unlikely that 128 bits will be enough for them to work out where it is in the pattern. 1GB of cryptographically secure noise is much harder to get (not sure if they still do, but US embassies used to use recordings from a radio telescope and the USSR had fun putting satellites above their telescope and injecting non-random patterns into their data).
Slashdot Mirror
I think it's more an artefact of centralisation. The MPEG model kind-of makes sense in a world where there are lots of smallish companies that want to use a video CODEC (ideally an interoperable one). MPEG provided a model where they could all pay a small amount and share the R&D costs (not a great model, because only stuff that was both patented and pushed in made it, so Apple stayed there with a patent covering part of the QuickTime .mov file format and nothing else, academics who developed a bunch of the ideas but didn't patent them got nothing, smaller players with better patented ideas were worked around and ignored). The difference now is that there are a number of companies making so much from having a decent video CODEC that they can afford to cover the entire R&D costs themselves (e.g. Google with YouTube, Netflix, Apple with the iTunes store). Any of them working in isolation could produce a decent CODEC and save more in royalties than they'd spend on R&D. A group of them together will pay far less in total R&D and then end up with something that doesn't require any license accounting (saving them more).
AMD doesn't get to escape those costs by outsourcing
AMD doesn't escape them, but they get to share them. The cost of developing a new process tech is huge (on the order of $10bn+). If you're selling ten million chips, then that's $1,000 per chip. You need to get a good hundred million chips out of the fabs before they start to bring the cost per chip down low enough that you can sell them. Even adding a 20% profit margin on for Global Foundaries and others, AMD benefits far more from having to pay less than 40% of the total R&D costs than they lose from those costs increasing. This is why AMD spun out Global Foundaries in the first place: it's a hard sell to get people to make chips in your fabs if you might compete with them, but you need them to if you want to be able to cover the R&D costs. It also freed AMD to use other companies' fabs if theirs were not the best for a particular product, and they've been quite effective so far at doing this.
Even Intel is struggling to get the required economies of scale. They keep trying to get other people to use their fabs, but no one wants to use a fab where they're always going to be lower priority than Intel and where Intel may suddenly decide that they're competitors. They event threw in Atom IP cores basically for free for anyone willing to fab their SoCs with Intel. It didn't work.
Intel makes twice as much profit every quarter as AMD brings in in total sales so that means Intel's costs are lower than AMD's by a lot.
Again, that's a nonsense comparison. It's including Intel NICs, Intel SSDs, and all of the other things where Intel has a huge presence and AMD has none. It's like comparing McAffee to Microsoft in total revenue and profit and claiming that this gives a sensible comparison of their presence in the antivirus market.
They just pay another company to do it for them plus a profit margin too - at the end of the day they pay MORE
You really don't understand how economies of scale work in this market. Let's take that $10bn number (probably a lowball for the next generation). Let's assume that there's a 20% extra markup from getting a third party to do it (probably a bit high, because it's a fairly competitive market and someone like TSMC would happily take AMD's business if GF charges too much). Let's also assume that AMD is 40% of GF's total business (last time I looked, they were less than this). AMD has a choice of either paying $10bn in R&D costs, or paying $4bn plus a 20% markup ($4.8bn). Which do you think is easier to amortise across their production runs? Note: the cost of producing a wafer of chips is effectively noise. This is why you can get chips for close to nothing on an older fab: the operating costs are an almost irrelevant part of the total.
Unicode is arranged in code planes that make it easy to either blacklist the harmful ones or whitelist the normal-text ones. Slashdot doesn't do either. SoylentNews does, using a fork of Slashcode.
Intel is literally over 10X the size of AMD by revenue
That's slightly misleading, because it assumes that all of Intel is competing with all of AMD. They have some competing business units, but they are not entirely direct competitors. For example, Intel has a huge network business unit (NICs, ICs for switches) and a large storage division, one of the two largest FPGA manufacturers, and it owns its own fabs. AMD no longer owns its own fabs, so doesn't require the same economise of scale to get the cost per wafer down (the fabs that make AMD chips also make chips for a load of other companies, so can benefit from large economies of scale).
Just because Intel is ten times the size doesn't mean that Intel's x86 chips are getting ten times (or even double) the investment that AMDs are.
People tend to think of AMD as a close competitor but they aren't. Intel spends over double AMD's total revenue on R&D alone
The vast majority of that is on process technology, which is no longer a business that AMD is in (and where the returns have been very low for the past 5 years).
No other site has this problem. Slashdot advertises UTF-8 support in the meta tags in their HTML, but then doesn't support UTF-8. Other sites either don't advertise UTF-8 support, or actually support unicode (you know, the thing that's been the standard text encoding for 15-20 years).
Even if you do want to run server workloads on macOS, you're far better off installing the relevant packages from Homebrew and configuring them than trying to use the OS X Server GUIs, which make some common things very easy but anything slightly uncommon really hard and came with odd upgrade cycles.
The reason HCI experts oppose customisation is that it makes it difficult to move between computers. It doesn't matter for a single person on a computer that no one else uses, but in a corporate setting when people need to use each others computers, or even in a private setting with someone calling technical support, every customisation is a thing that makes your computer behave differently from what the other user expects. Good UIs are all about consistency: doing action X should cause operation B in all cases. If this changes when I look at a different computer that's running the same software stack, that's a problem. If you need to troubleshoot something on my computer, and none of the UI elements behave as you expect, that's a problem.
There's also a related issue that most people really suck at configuring things to maximise their own productivity. MSR and others did a bunch of research on this in the early '90s. The executive summary is that the configuration choice that people think makes them faster often actually makes them slower, but they don't subjectively count the time that they're sitting and thinking about the UI, because it's not the direct focus of their attention. In most studies, people who configured the UI as they liked ended up performing common tasks more slowly than ones that stayed with the defaults.
If you haven't looked recently, they released an updated version of the installer a couple of years back. I was pleased to discover a couple of years ago that I could enter my CD keys into Blizzard's web site and download an installer that ran D2 + LoD on my Intel Mac on a recent macOS. Unfortunately, it looks as if it's a 32-bit binary, so it may not work for much longer...
Alan Kay has done some work that shows that teaching students the actor model first gives better results (and gives students who can write parallel code as easily as serial code). A language like Erlang, but with syntax that doesn't assume that you're already fluent in Prolog, combined with some graphical tools for setting up communication channels would probably be a good starting point.
it can be done ahead of time by mail, FedEx, or even in person, using any medium, even paper
I'll agree with 'in person', but if you trust the mail or FedEx to be secure, then why not just use these services for the message and not bother with the encryption at all?
Our cellphones need to last 10 years, not 2.
They probably do. Mine is now five years old and still works pretty well, but the problem is the software. It runs Android, so I can get third-party updates from LineageOS, but that's done by volunteers. How about taxing companies that stop producing software-updates for network-connected devices based on their sales and support lifetime and using that money to subsidise third-party development that keeps the devices in circulation?
Everything doesn't need to come in a cardboard box from Amazon
Why not? It's cheap cardboard made from recycled paper and it goes back for recycling. Having a single van that delivers things to me and a load of other people nearby is more efficient than all of us driving to the shops and a lot more convenient than all of us walking.
I believe the term to use here is "whitewashing".
I think Greenwashing is the term that you're looking for.
Last time I was in the bay area, most of the 'plastic' disposable things I picked up were compostable biomass. I've not seen them much elsewhere, so I don't know if there's some subsidy or penalty that means that it's only economically feasible in California, but it seemed like a good replacement.
It's worth noting that the failure of the P4 was to do with the fact that Intel (very unusually) mispredicted process improvements. The team running P4 development was expecting 5GHz at launch and 10GHz after a couple of years. Their designs worked at those speeds in the simulators, but the process technology didn't give the faster clocks that they expected. At 5GHz, the P4 would have smoked the Athlon for performance and at 10GHz it would have been incredible, but Intel hit an unexpected brick wall and never made it past 4GHz.
The Pentium M was basically the Pentium 3 with the branch predictor from the Pentium 4 and a few refinements.
They don't have any sort of a versioned library subsystem where you can state that "I need the 10.6 version of Cocoa" and have the OS provide that to you, which is because OS X as a whole is so tightly coupled together with itself that you literally cannot have multiple versions of Cocoa sitting on the same machine.
This is so laughably untrue that I don't know where to start.
First, the OPENSTEP bundle format that Apple inherited from NeXT includes a concept of versioning in the loader. You can link either to the latest version of a framework, or explicitly to an older one, and you can ship multiple library binaries for different versions in the same framework, with the linker correctly finding the right one.
Second, each Mac application embeds a MacOS deployment target, which will put some APIs into compatibility modes if you invoke them on a newer system.
Third, all of the Apple headers include annotations about which versions of each of their operating systems introduced, deprecated, and removed APIs, so you can explicitly target older versions and get compiler errors if you use a newer API. I'm not sure why you think it's better for them to provide copies of older headers instead of doing this.
Fourth, a bunch of the APIs include constants that tell specific subsystems about the expected version. For example, each time they improve the line-breaking algorithm in the text layout engine, they bump an enum value so that code compiled with an older deployment target, or code that explicitly opts into the older behaviour for compatibility, will get the old behaviour.
I had a look, and there are only 2 32-bit apps on my macOS system currently running. One is the Android File Transfer thing, which can probably work in 64-bit mode without too much effort. The other is WINE, which is likely to be more effort because it will still need to run 32-bit PE/COFF binaries and handle transition to and from 32-bit mode.
I remember realising how much faster the Core 2 Duo was than the G4 when I noticed that VLC was using a little bit more CPU in Activity Monitor on my new MacBook Pro than on my old PowerBook: almost 80% of one core, when it had been closer to 60% (of the only core) on the old machine playing the same video. Then I realised that VLC wasn't a fat binary and I was still running the PowerPC version: even CPU-bound applications running in emulation were only slightly slower in the new machine. Switching to the Intel version of VLC dropped the CPU usage down to 10-20%.
That's true. There are; however, very few examples of perfectly working software. Most software requires ongoing maintenance to keep it working in a changing environment (new hardware, integration with other components and new or changed OS services). This maintenance costs money. Apple can either spend developer resources on maintaining the 32-bit versions of software years after they've stopped selling any 32-bit CPUs, or they can invest that in other things (such as better security audits). Given finite developer resources, I'd prefer that they spent their effort on things that will benefit most users.
A lot of the games (including a lot of the ones bought from GOG) that I run are 32-bit Windows binaries running in WINE. That said, it's not clear that WINE needs to actually be a 32-bit Mach-O binary: it already includes its own PE loader and a bunch of translation layers that turn Windows structures into host system structures. It could probably be a 64-bit binary that would switch to 32-bit mode before jumping into Windows code and back to 64-bit code before switching out.
I doubt that Apple wants to ship x86 chips without 32-bit support, they just don't want to ship 32-bit versions of all of the core libraries and this approach would address that problem.
Why? VMs have been able to do RS-232 pass-through for ages. About 10 years ago, I visited a company that had just moved their old DOS-based control software into a VM for precisely this reason: they could install a USB RS-232 adaptor on their host and expose an emulated RS-232 device to the VM. This was a lot easier than trying to port the software (most of which was 8086 assembly) or get a USB serial interface working with DOS. There was some overhead, but line rate on RS-232 is so slow that you can burn a lot of cycles on emulation without noticing.
Windows 10 uses the same kernel, libc, init system, display server, and core libraries as MS DOS? Microsoft is a lot better at code reuse than I thought!
US embassies use OTPs. I'm not surprised bits of the military use it. It's fine if you have a limited number of communication paths, trustworthy people with big guns who can carry the keys, and the ability to often have the people who are going to communicate in the same room. It would be fairly easy to create a OTP system for a family, for example, where their phones would all share random secrets over local WiFi / Bluetooth overnight, and then use those during the day. It's not so feasible for the relatives that live overseas.
Have you ever heard of a coin?
Yup. I've also read some studies showing how non-random coin tosses are. They're fine for a single toss, but with enough data you're going to see patterns. Even without that, each coin toss gives you 1 bit of entropy. An SMS is 140 bytes (1,120 bits), so if you can toss a coin once per second it will take almost 20 minutes to generate the random number that will work as a OTP for a single text message.
Perhaps some dice?
Okay, ignoring the fact that most die are biassed and even ones that start perfect are biassed towards either the 1 or 6 by the act of printing or cutting the numbers, now we get 2.5 bits of entopy from each die roll. Now we're down to just over 7 minutes at one die roll per second to generate a OTP for an SMS. I actually do know of one company that has built an automatic die rolling machine to generate random numbers. It's fine for a 128-bit key (52 rolls), but if you want to use it as a OTP then it's going to be very slow.
I can spend $20 on flash memory. I will give me enough material to communicate with someone as much as I want by voice or text for a lifetime with zero chance of in-flight compromise by anyone ever.
That's true (unless you want to share videos), though that's $20 for every pair of communicating parties, plus the overhead of managing one thumb drive for everyone that you want to communicate with. That doesn't scale well.
Most cryptography in practical use today is dependent on secure random sources for secure operation
It's a question of quantity. Getting 128 bits of cryptographically secure noise is easy. Even if you think the NSA has compromised a bunch of hardware random number generators, it's unlikely that 128 bits will be enough for them to work out where it is in the pattern. 1GB of cryptographically secure noise is much harder to get (not sure if they still do, but US embassies used to use recordings from a radio telescope and the USSR had fun putting satellites above their telescope and injecting non-random patterns into their data).