On real computers, fonts can be changed from system defaults, overridden on websites, etc. if the user so desires. Does iOS support just changing to the font of your choice and calling it a day?
Why do that when you can demand that Unicode version N+1 include new codepoints for each of those; or even go all the way and define some new "emoji modifiers" so that the user can specify water pistol + fluid it is filled with for hundreds of distinct combinations!
This has been the source of much confusion and irksome emoji-controversy:
Unicode itself does not define the rendering of any of its glyphs. For convenience, they provide example documentation on their site; but that is just convenience, it is not normative. This is most obvious with fonts and normal letters: whether it's Times New Roman or Comic Sans is not Unicode's problem; just that it's a "Latin Capital A".
Emoji fuck this up because they are shoehorned into the same glyph/rendering model; but unlike oddball fonts, which tend to just head toward being illegible or unpleasant, you change the meaning of a pictograph pretty quickly if you deviate too far.
In this case, if you sent a text containing the pistol emoji it will now, forever, and across platforms; be internally represented as U+1F52B, the codepoint for 'Pistol' in the miscellaneous symbols and pictographs block. What will appear on your screen depends entirely on what font is used; apparently Apple is changing their system default font so that it will now appear as a water pistol. If the same text is viewed on an Android device, apparently it will still show up as a pistol-y looking pistol.
It's bullshit like this that makes the continued drive to shovel emoji into Unicode such a clusterfuck. Yeah, it was a necessary evil when cleaning up the Japanese legacy handset market(just like a lot of other weird stuff that has been included over the years in the attempt to hasten the demise of horrid legacy encodings); but Unicode is not an image format, nor is it intended to be, so it's not a very good fit for situations where details of rendering matter; and when the glyphs involved also push various buttons (as in this case with guns; or the last Apple/emoji/Unicode controversy over the racism of the default 'smiley face' being a yellow color on iphone) it just leads to a lot of deeply unproductive shouting.
If people really want to send goofy little pictures to one another; and emoticons aren't good enough, we already have good mechanism for doing that: We call them "image formats". They are these crazy standards that allow you to fairly precisely define exactly what you want the picture you are sending to look like, it's pretty cutting edge.
One Mr. Kalashnikov would like to remind you that he has (often literally) revolutionized substantially more territory than Apple has; and he only had to sell ~100 million units to do it!
The problem is with the bacteria. We fungi have been locked in constant war with those prokaryote bastards for the better part of a billion years, so the grudges run pretty deep.
At present, I probably wouldn't eat cultured tissue just because it's wildly expensive and only available in teeny little bits because the cardiovascular system is there for a reason in mammals; but if the tech were worked out what possible objection would there be to it?
Cruelty-free, so long as you don't grow the brain; and quite probably a lot cleaner than the authentically-butchered-in-its-own-entrails-and-hopefully-not-too-feces-smeared natural stuff. Less chance to pick up cool parasites and stuff in the field as well.
Yes, it is definitely true that digital forensics requires care to not munge the evidence and preserve its integrity; and that gets a lot harder if you are actively attacking a remote host that multiple other people have access to and can potentially also be altering, rather than just shoving an HDD into a write blocker and reading it back; but I'm unclear on why that relates to encryption.
Basically nothing you 'find' on a computer is actually meaningful without a layer of software interpretation(or, for simple formats, one skilled in the art running the algorithm in their head). Why is applying a decryption algorithm to an encrypted file different than, say, trusting an NTFS implementation to accurately take a partition full of meaningless garbage and present you with a filesystem; or a JPEG implementation to tell you whether a given sequence of bits is kiddie porn or not?
It is true that if encryption happens to be what turns a 'seize the server, grab images of the drives' investigation into a 'hack the server in an unknown location, malware the data out on the fly' investigation then, in a weak sense, I suppose that 'encryption' has complicated the investigation; but aside from that it doesn't seem any different than the usual problems with attribution of files, interpretation of formats, and so on.
PCs also benefit from the fact that 'pay a subscription fee for multiplayer' never caught on; and unless you insist on pre-order or day 1 purchasing everything(in which case the prices are usually the same), PC game prices seem to fall faster than console game prices do.
Plus, you don't need to build your l33t rig just because you intend to do some gaming. If you don't want to build it yourself there are plenty of companies who will shove a tested combination of off the shelf components into a box for you, for a pretty modest premium over doing it yourself; and even a random Dell or the like probably just needs a better graphics card to be more than adequate for most games, since CPUs are mostly absurdly powerful.
Sure, the agony of trying to figure out why $1500 worth of parts won't POST after accidentally slicing your hand open on case sheet metal and without sufficient test equipment or spare components sucks; but that's largely irrelevant because it's totally optional.
Even among people who can afford hardware, there is a lot of effective consolidation because of 'pools'. These aren't irrational behavior: if you have a small amount of hashing capacity going it alone might pay off handsomely but will probably pay nothing, while pooling more or less guarantees a return proportional to your hashing capacity; but also leaves you largely at the mercy of the infrastructure.
I'm not anything approaching a cryptoanalyst; but my understanding is that TLS has been 'broken' at various times because of either implementation flaws or legacy-compatibility stuff not being dropped fast enough(and there's the minor problem of CAs being a total clusterfuck); but that these breaks were of the somewhat less scary kind that can be fixed by deprecating a specific cipher, or increasing a key length, or patching/replacing a specific flawed implementation.
A development of the 'hahaha, prime factorization is now trivial!' flavor would be the sort of ugly break where fundamental underlying assumptions are no longer correct and there no amount of incremental fixing will work.
It's really worth keeping a precise distinction in mind when talking about Google and privacy:
Google is clearly hell-bent on being as much of an Orwellian data overlord as possible; so trusting them to design products in such a way that they don't tend to leak data to Google during the course of routine use is foolish.
However, Google's approach to gathering alarming amounts of data is usually to make themselves attractive enough that they get invited in to the system(eg. gmail, google voice, 'free' google analytics for website operators, 'benevolently' hosting common javascript libraries so that you can save yourself bandwidth at the minor cost of inserting Google into every page load, that sort of thing.) They get the target to 'agree'(certainly they'll exploit ignorance and product tie-ins to do this, they are hardly committed to some idealistic vision of contracts between fully informed equals); rather than compromising the target's security and malwareing the data out. Presumably this is both because that would probably open them to legal exposure; and because an "insecurity and hacks" data collection mechanism would open the field to Google competitors who would do none of the work but get the same data just by compromising the system.
Because of this; Google actually tends to be pretty respectable in terms of design and implementation; sometimes even notably superior, in terms of quality of implementation and resistance to unauthorized 3rd parties. Chrome routinely scores very well in browser security comparisons, ChromeOS is also quite solid; Android usually doesn't turn into a dumpster fire until 3rd parties get involved, Gmail is better than an alarming number of sites about support for 2 factor authentication, and so on. It's just that all their products and services are designed to put them 'in the loop' by default and if you want everything to work smoothly, so that they have no need to compromise the system; because they are a trusted part of it.
If given the choice between a design where there is no need for anything to talk to the mothership and a design that relies on a Google account and being logged into Chrome and so on; they'll choose the latter every time; but when they set out to keep unauthorized parties out; they usually mean it, though they work to ensure that they are not 'unauthorized parties' in as many real world use cases as they can.
There's also the matter of which vendors have enough market power to push designs that enhance their bottom line; vs. vendors who pretty much have to throw in anything the customer might want because they are nearly interchangeable.
Omitting microSD is very attractive to handset vendors because the premium they charge for moving between storage 'tiers' tends to be exceedingly profitable. With Apple's current lineup, 16GB to 64GB or 64GB to 128GB are $100 bumps. I don't doubt that Apple is using nicer NAND than the people slapping together atrocious unbranded fleabay tablets or impulse-buy USB sticks; but that cost/GB($1.56/GB or $2.08/GB) is roughly what you'd see in an 'enterprise' PCIe NVME SSD(something like an Intel P3700) ; with consumer/enthusiast cost/GB more in the $.50/GB range from respectable brands. And that includes the price of the controller and packaging.
If you have market power(as Apple does, since if you want an iDevice they are the only option; and as some Android vendors do to lesser degrees, thanks to having the must-have flagship of the moment, or strong brand awareness, or a telco deal or the like); margins like that make cutting the microSD slot very, very tempting; not because it's expensive to implement; but because offering it will eat into sales of your higher margin models.
If you are basically interchangeable with your multiple competitors, it's a much more sensible thing to include: microSD connectors are under a dollar in quantity one; substantially cheaper in volume, basically all common ARM SoCs have at least one SD or SDIO controller available; and the pin count and frequency aren't that heroic so it's not a terribly ugly thing to route from the SoC to the connector.
And, for backup(as well as ease of access across multiple devices) it is a fairly compelling offering; particularly for people who lack the skill, resources, or interest to handle administering a file server and supporting infrastructure themselves.
That, though, doesn't replace having a bunch of local storage for caching and offline use; it complements it. Even if cost is no object network latency makes grabbing something from a remote host slightly slower than pulling it from a local cache(unless your storage system is truly atrocious); locally cached data also allow you to make any intermittent connectivity losses(fairly common on wireless networks) invisible to the user; and allow you to do things(like video recording or taking a bunch of photos in quick succession) that produce markedly more data than you can safely assume your network connection can handle for a short period of time.
The 'cloud' certainly needs some improvements in terms of security and privacy; but being able to back up the contents of a client device that may be lost, stolen, broken, etc. and make them available to you on other devices is a pretty compelling set of features. It's just a quite different set of features from what a nice chunk of local storage offers: local storage isn't a backup, isn't conveniently accessible from other devices; but costs nothing to read/write to no matter where you are, is usually capable of higher speeds than your network interface is(unless it is egregiously lousy or you have a really, really, classy network; but cellphones aren't usually connected by 10GbE iSCSI HBAs or anything).
The point isn't that "I want an SD card because I'm a luddite who hates all networked filesystems or network file transfer mechanisms"; but "cache crops up in all sorts of areas of computer design where a bit of storage allows you to compensate for the deficiencies, in bandwidth, latency, reliability, or all of the above, of a bus; and given how little an adequate-but-not-thrilling SD card costs; having a generous chunk of cache to improve the apparent performance of a device that relies largely on wireless connections is an obvious win.
The trouble is that one of the things malware can do is clean up after itself: exfiltration is much harder to hide from network logs(if the target actually has any); but unless you are hoping to remain undiscovered indefinitely, why wouldn't your exfiltration agent delete itself after its job is done?
There was a brief burst of enthusiasm back in 2003 because the original 'support' for ipods on PCs was 'Musicmatch Jukebox'; a program so terrible that it made iTunes look like a blessing.
I can't really think of any situations since then when iTunes has looked like the better option; but there was that one.
From the looks of the PR renderings, they seem to be getting dangerously impractical in the pursuit of everything-will-be-white-and-curved-in-the-future aesthetics as it is. Yeah, futuristic and stuff; but ports are not going to be amused by anything that makes loading and unloading containers slower or more expensive.
I doubt that the customers would want poison gas seeping into their products during shipping, even if Loyd's was up for the idea; but it wouldn't be a complete surprise to hear of an unmanned bulk carrier of some sort being flushed with dry nitrogen as a preservative; and some idiots encountering inert gas asphyxiation.
That's what makes Civ ultimately a 'god game', though less overtly than something like Populous. Not only are all possible concepts(with gameplay implications, you can roleplay in your head if it amuses you) fixed from the beginning of time; the player is always a dispassionate but all-powerful observer: The 'capitalist' player still decides each and every construction project in their entire empire just as the 'communist' one does; and the 'fundamentalist' gets certain bonuses and drawbacks; but no divine command to fulfill.
Civ would probably actually be vastly more educational if it had less historical 'flavor' rather than more: Since basically all the civs, government types, religions, etc. have to be reasonably balanced for gameplay purposes, they all end up being more or less interchangeable and the only connection to the things that they are named after is in the flavor text, city styles, and maybe a unique unit.
The use of historical flavor helps keep things from feeling like you are just playing a spreadsheet(at least for me, Alpha Centauri's unit design mechanics suffered a bit from that: there's no "ah, a swordsman!" it's all "Hmm, is 'plasma steel impact speeder' better than 'synthmetal particle impactor speeder'? let's check the numbers..."); but they are both limited to fairly minor differences, since otherwise civs that mostly lost in real life would be effectively unplayable and they don't respond much to what you do.
If, say, you play as the Romans; hooray, your special unit is the legion. But what if you play as Buddhist Romans dedicated to peaceful persuit of trade and culture? Well, you still get a slightly better iron-age infantry shock unit; because you're the Romans. It would be less flavorful; but more 'realistic' if instead of having historically-based flavor units, your play style influenced the shape of your civilization over time: the aggressive expansionists develop the militaristic culture and units based on specialized tactical doctrines; the culture types get extra soft-power options associated with the fact that even their enemies watch their TV shows, etc.
That would be substantially harder to do right, both in terms of the computer making decisions about your 'style' that lead to 'WTF? The computer thinks I was playing a merchant-prince? I was just funding my giant army!' and in terms of game balance; but it would more accurately capture the fact that what 'civilization' you are isn't just a veneer chosen at the beginning and static throughout history: it's what you do; and what options your choices open or close for you and how you respond to that, and so on.
I'm not terribly convinced that Civilization(for all its virtues as a game; though IV was better than V unless recent expansions have fixed it) is a particularly good choice: it is 'history themed'; but fundamentally designed around being a fun game; and basically a god game: everything your civilization does is under your direct control, and aside from some minor background noise random events, you are basically the only thing driving your entire civilization. Every tech you research, every building you commission, every unit you muster and personally move around. There's really no emergent behavior, no 'society' that you have to deal with, even the constraints on what is logistically and socially possible are pretty light(compare to, say, Europa Universalis, where 'just send in the troops and conquer them, idiot.' tends to lead to decades or centuries of heightened rebellion risks and uprisings, even more so if you have ethnic and religious differences to deal with).
That said, while Civ seems like a poor candidate, "computer games" are really just the fun-optimized end of 'simulations' and 'models'; and those are clearly useful tools, for education and elsewhere.
Directly, they probably won't. Indirectly, how much money he is making is going to show up in his prices relatively quickly unless he somehow convinces people that approximately-adequate pizza isn't pretty close to commodified in most markets large enough to have overlapping take-out joints.
It's also amusing that he wants to "be the Amazon of food" and thinks that what he is doing will be incredibly profitable: Amazon is practically iconic for their absolutely tiny margins across most of their history and most of their business.
Slashdot Mirror
On real computers, fonts can be changed from system defaults, overridden on websites, etc. if the user so desires. Does iOS support just changing to the font of your choice and calling it a day?
Why do that when you can demand that Unicode version N+1 include new codepoints for each of those; or even go all the way and define some new "emoji modifiers" so that the user can specify water pistol + fluid it is filled with for hundreds of distinct combinations!
This has been the source of much confusion and irksome emoji-controversy:
Unicode itself does not define the rendering of any of its glyphs. For convenience, they provide example documentation on their site; but that is just convenience, it is not normative. This is most obvious with fonts and normal letters: whether it's Times New Roman or Comic Sans is not Unicode's problem; just that it's a "Latin Capital A".
Emoji fuck this up because they are shoehorned into the same glyph/rendering model; but unlike oddball fonts, which tend to just head toward being illegible or unpleasant, you change the meaning of a pictograph pretty quickly if you deviate too far.
In this case, if you sent a text containing the pistol emoji it will now, forever, and across platforms; be internally represented as U+1F52B, the codepoint for 'Pistol' in the miscellaneous symbols and pictographs block. What will appear on your screen depends entirely on what font is used; apparently Apple is changing their system default font so that it will now appear as a water pistol. If the same text is viewed on an Android device, apparently it will still show up as a pistol-y looking pistol.
It's bullshit like this that makes the continued drive to shovel emoji into Unicode such a clusterfuck. Yeah, it was a necessary evil when cleaning up the Japanese legacy handset market(just like a lot of other weird stuff that has been included over the years in the attempt to hasten the demise of horrid legacy encodings); but Unicode is not an image format, nor is it intended to be, so it's not a very good fit for situations where details of rendering matter; and when the glyphs involved also push various buttons (as in this case with guns; or the last Apple/emoji/Unicode controversy over the racism of the default 'smiley face' being a yellow color on iphone) it just leads to a lot of deeply unproductive shouting.
If people really want to send goofy little pictures to one another; and emoticons aren't good enough, we already have good mechanism for doing that: We call them "image formats". They are these crazy standards that allow you to fairly precisely define exactly what you want the picture you are sending to look like, it's pretty cutting edge.
What could be more suitable to guard your drone aircraft's landing field and associated infrastructure than drone vehicles?
One Mr. Kalashnikov would like to remind you that he has (often literally) revolutionized substantially more territory than Apple has; and he only had to sell ~100 million units to do it!
The problem is with the bacteria. We fungi have been locked in constant war with those prokaryote bastards for the better part of a billion years, so the grudges run pretty deep.
At present, I probably wouldn't eat cultured tissue just because it's wildly expensive and only available in teeny little bits because the cardiovascular system is there for a reason in mammals; but if the tech were worked out what possible objection would there be to it?
Cruelty-free, so long as you don't grow the brain; and quite probably a lot cleaner than the authentically-butchered-in-its-own-entrails-and-hopefully-not-too-feces-smeared natural stuff. Less chance to pick up cool parasites and stuff in the field as well.
I'm confused by the issue here:
Yes, it is definitely true that digital forensics requires care to not munge the evidence and preserve its integrity; and that gets a lot harder if you are actively attacking a remote host that multiple other people have access to and can potentially also be altering, rather than just shoving an HDD into a write blocker and reading it back; but I'm unclear on why that relates to encryption.
Basically nothing you 'find' on a computer is actually meaningful without a layer of software interpretation(or, for simple formats, one skilled in the art running the algorithm in their head). Why is applying a decryption algorithm to an encrypted file different than, say, trusting an NTFS implementation to accurately take a partition full of meaningless garbage and present you with a filesystem; or a JPEG implementation to tell you whether a given sequence of bits is kiddie porn or not?
It is true that if encryption happens to be what turns a 'seize the server, grab images of the drives' investigation into a 'hack the server in an unknown location, malware the data out on the fly' investigation then, in a weak sense, I suppose that 'encryption' has complicated the investigation; but aside from that it doesn't seem any different than the usual problems with attribution of files, interpretation of formats, and so on.
PCs also benefit from the fact that 'pay a subscription fee for multiplayer' never caught on; and unless you insist on pre-order or day 1 purchasing everything(in which case the prices are usually the same), PC game prices seem to fall faster than console game prices do.
Plus, you don't need to build your l33t rig just because you intend to do some gaming. If you don't want to build it yourself there are plenty of companies who will shove a tested combination of off the shelf components into a box for you, for a pretty modest premium over doing it yourself; and even a random Dell or the like probably just needs a better graphics card to be more than adequate for most games, since CPUs are mostly absurdly powerful.
Sure, the agony of trying to figure out why $1500 worth of parts won't POST after accidentally slicing your hand open on case sheet metal and without sufficient test equipment or spare components sucks; but that's largely irrelevant because it's totally optional.
Even among people who can afford hardware, there is a lot of effective consolidation because of 'pools'. These aren't irrational behavior: if you have a small amount of hashing capacity going it alone might pay off handsomely but will probably pay nothing, while pooling more or less guarantees a return proportional to your hashing capacity; but also leaves you largely at the mercy of the infrastructure.
Given the acceptance of terminating and laying off employees without notice; why exactly would you expect them to be more courteous to you?
I'm not anything approaching a cryptoanalyst; but my understanding is that TLS has been 'broken' at various times because of either implementation flaws or legacy-compatibility stuff not being dropped fast enough(and there's the minor problem of CAs being a total clusterfuck); but that these breaks were of the somewhat less scary kind that can be fixed by deprecating a specific cipher, or increasing a key length, or patching/replacing a specific flawed implementation.
A development of the 'hahaha, prime factorization is now trivial!' flavor would be the sort of ugly break where fundamental underlying assumptions are no longer correct and there no amount of incremental fixing will work.
It's really worth keeping a precise distinction in mind when talking about Google and privacy:
Google is clearly hell-bent on being as much of an Orwellian data overlord as possible; so trusting them to design products in such a way that they don't tend to leak data to Google during the course of routine use is foolish.
However, Google's approach to gathering alarming amounts of data is usually to make themselves attractive enough that they get invited in to the system(eg. gmail, google voice, 'free' google analytics for website operators, 'benevolently' hosting common javascript libraries so that you can save yourself bandwidth at the minor cost of inserting Google into every page load, that sort of thing.) They get the target to 'agree'(certainly they'll exploit ignorance and product tie-ins to do this, they are hardly committed to some idealistic vision of contracts between fully informed equals); rather than compromising the target's security and malwareing the data out. Presumably this is both because that would probably open them to legal exposure; and because an "insecurity and hacks" data collection mechanism would open the field to Google competitors who would do none of the work but get the same data just by compromising the system.
Because of this; Google actually tends to be pretty respectable in terms of design and implementation; sometimes even notably superior, in terms of quality of implementation and resistance to unauthorized 3rd parties. Chrome routinely scores very well in browser security comparisons, ChromeOS is also quite solid; Android usually doesn't turn into a dumpster fire until 3rd parties get involved, Gmail is better than an alarming number of sites about support for 2 factor authentication, and so on. It's just that all their products and services are designed to put them 'in the loop' by default and if you want everything to work smoothly, so that they have no need to compromise the system; because they are a trusted part of it.
If given the choice between a design where there is no need for anything to talk to the mothership and a design that relies on a Google account and being logged into Chrome and so on; they'll choose the latter every time; but when they set out to keep unauthorized parties out; they usually mean it, though they work to ensure that they are not 'unauthorized parties' in as many real world use cases as they can.
There's also the matter of which vendors have enough market power to push designs that enhance their bottom line; vs. vendors who pretty much have to throw in anything the customer might want because they are nearly interchangeable.
Omitting microSD is very attractive to handset vendors because the premium they charge for moving between storage 'tiers' tends to be exceedingly profitable. With Apple's current lineup, 16GB to 64GB or 64GB to 128GB are $100 bumps. I don't doubt that Apple is using nicer NAND than the people slapping together atrocious unbranded fleabay tablets or impulse-buy USB sticks; but that cost/GB($1.56/GB or $2.08/GB) is roughly what you'd see in an 'enterprise' PCIe NVME SSD(something like an Intel P3700) ; with consumer/enthusiast cost/GB more in the $.50/GB range from respectable brands. And that includes the price of the controller and packaging. If you have market power(as Apple does, since if you want an iDevice they are the only option; and as some Android vendors do to lesser degrees, thanks to having the must-have flagship of the moment, or strong brand awareness, or a telco deal or the like); margins like that make cutting the microSD slot very, very tempting; not because it's expensive to implement; but because offering it will eat into sales of your higher margin models.
If you are basically interchangeable with your multiple competitors, it's a much more sensible thing to include: microSD connectors are under a dollar in quantity one; substantially cheaper in volume, basically all common ARM SoCs have at least one SD or SDIO controller available; and the pin count and frequency aren't that heroic so it's not a terribly ugly thing to route from the SoC to the connector.
And, for backup(as well as ease of access across multiple devices) it is a fairly compelling offering; particularly for people who lack the skill, resources, or interest to handle administering a file server and supporting infrastructure themselves.
That, though, doesn't replace having a bunch of local storage for caching and offline use; it complements it. Even if cost is no object network latency makes grabbing something from a remote host slightly slower than pulling it from a local cache(unless your storage system is truly atrocious); locally cached data also allow you to make any intermittent connectivity losses(fairly common on wireless networks) invisible to the user; and allow you to do things(like video recording or taking a bunch of photos in quick succession) that produce markedly more data than you can safely assume your network connection can handle for a short period of time.
The 'cloud' certainly needs some improvements in terms of security and privacy; but being able to back up the contents of a client device that may be lost, stolen, broken, etc. and make them available to you on other devices is a pretty compelling set of features. It's just a quite different set of features from what a nice chunk of local storage offers: local storage isn't a backup, isn't conveniently accessible from other devices; but costs nothing to read/write to no matter where you are, is usually capable of higher speeds than your network interface is(unless it is egregiously lousy or you have a really, really, classy network; but cellphones aren't usually connected by 10GbE iSCSI HBAs or anything).
The point isn't that "I want an SD card because I'm a luddite who hates all networked filesystems or network file transfer mechanisms"; but "cache crops up in all sorts of areas of computer design where a bit of storage allows you to compensate for the deficiencies, in bandwidth, latency, reliability, or all of the above, of a bus; and given how little an adequate-but-not-thrilling SD card costs; having a generous chunk of cache to improve the apparent performance of a device that relies largely on wireless connections is an obvious win.
The trouble is that one of the things malware can do is clean up after itself: exfiltration is much harder to hide from network logs(if the target actually has any); but unless you are hoping to remain undiscovered indefinitely, why wouldn't your exfiltration agent delete itself after its job is done?
There was a brief burst of enthusiasm back in 2003 because the original 'support' for ipods on PCs was 'Musicmatch Jukebox'; a program so terrible that it made iTunes look like a blessing.
I can't really think of any situations since then when iTunes has looked like the better option; but there was that one.
From the looks of the PR renderings, they seem to be getting dangerously impractical in the pursuit of everything-will-be-white-and-curved-in-the-future aesthetics as it is. Yeah, futuristic and stuff; but ports are not going to be amused by anything that makes loading and unloading containers slower or more expensive.
I doubt that the customers would want poison gas seeping into their products during shipping, even if Loyd's was up for the idea; but it wouldn't be a complete surprise to hear of an unmanned bulk carrier of some sort being flushed with dry nitrogen as a preservative; and some idiots encountering inert gas asphyxiation.
A 'pardon' suggests that you've done something wrong but are being let of lightly because we are just that nice. Give the guy a damn medal.
That's what makes Civ ultimately a 'god game', though less overtly than something like Populous. Not only are all possible concepts(with gameplay implications, you can roleplay in your head if it amuses you) fixed from the beginning of time; the player is always a dispassionate but all-powerful observer: The 'capitalist' player still decides each and every construction project in their entire empire just as the 'communist' one does; and the 'fundamentalist' gets certain bonuses and drawbacks; but no divine command to fulfill.
Civ would probably actually be vastly more educational if it had less historical 'flavor' rather than more: Since basically all the civs, government types, religions, etc. have to be reasonably balanced for gameplay purposes, they all end up being more or less interchangeable and the only connection to the things that they are named after is in the flavor text, city styles, and maybe a unique unit.
The use of historical flavor helps keep things from feeling like you are just playing a spreadsheet(at least for me, Alpha Centauri's unit design mechanics suffered a bit from that: there's no "ah, a swordsman!" it's all "Hmm, is 'plasma steel impact speeder' better than 'synthmetal particle impactor speeder'? let's check the numbers..."); but they are both limited to fairly minor differences, since otherwise civs that mostly lost in real life would be effectively unplayable and they don't respond much to what you do.
If, say, you play as the Romans; hooray, your special unit is the legion. But what if you play as Buddhist Romans dedicated to peaceful persuit of trade and culture? Well, you still get a slightly better iron-age infantry shock unit; because you're the Romans. It would be less flavorful; but more 'realistic' if instead of having historically-based flavor units, your play style influenced the shape of your civilization over time: the aggressive expansionists develop the militaristic culture and units based on specialized tactical doctrines; the culture types get extra soft-power options associated with the fact that even their enemies watch their TV shows, etc.
That would be substantially harder to do right, both in terms of the computer making decisions about your 'style' that lead to 'WTF? The computer thinks I was playing a merchant-prince? I was just funding my giant army!' and in terms of game balance; but it would more accurately capture the fact that what 'civilization' you are isn't just a veneer chosen at the beginning and static throughout history: it's what you do; and what options your choices open or close for you and how you respond to that, and so on.
I'm not terribly convinced that Civilization(for all its virtues as a game; though IV was better than V unless recent expansions have fixed it) is a particularly good choice: it is 'history themed'; but fundamentally designed around being a fun game; and basically a god game: everything your civilization does is under your direct control, and aside from some minor background noise random events, you are basically the only thing driving your entire civilization. Every tech you research, every building you commission, every unit you muster and personally move around. There's really no emergent behavior, no 'society' that you have to deal with, even the constraints on what is logistically and socially possible are pretty light(compare to, say, Europa Universalis, where 'just send in the troops and conquer them, idiot.' tends to lead to decades or centuries of heightened rebellion risks and uprisings, even more so if you have ethnic and religious differences to deal with).
That said, while Civ seems like a poor candidate, "computer games" are really just the fun-optimized end of 'simulations' and 'models'; and those are clearly useful tools, for education and elsewhere.
Directly, they probably won't. Indirectly, how much money he is making is going to show up in his prices relatively quickly unless he somehow convinces people that approximately-adequate pizza isn't pretty close to commodified in most markets large enough to have overlapping take-out joints.
It's also amusing that he wants to "be the Amazon of food" and thinks that what he is doing will be incredibly profitable: Amazon is practically iconic for their absolutely tiny margins across most of their history and most of their business.