The other day a Google tech recruiter (not a headhunter) contacted me about an interview at Google. This after I turned down a second interview with them seven years ago.
Weird. I had almost an identical experience last week. A Google tech recruiter sent me messages via both email and LinkedIn. He'd been looking at my technical web sites. I'm not interested; it's been years since I had to work for someone else. But I called the guy. It really was a Google recruiter. I hadn't heard from Google in about five years. They must be going through their back files.
The largest issue I have with the hyperloop proposal is its rather pitiful capacity. At the highest rate proposed, with one cart every 30 seconds it still only transports ~3600 PAX/hr, which is about on par with a 3 lane highway and that is before mixing in the car carriers.
Musk writes in his proposal: "Assuming an average
departure time of 2 minutes between capsules, a
minimum of 28 passengers per capsule are required
to meet 840 passengers per hour." So it's even worse than 3600PAX/hr.
Compare current flight capacity. At peak, there are 5 flights an hour from SF to LA. The most common plane on that run is a Boeing 737 with 137 seats, for 685 seats/hour. So the Hyperloop has more capacity than the current aircraft. Comparing with other tunnel systems, Eurotunnel moves about 30 trains per hour, and their trains are 400 meters long with a seating capacity of 750 on the passenger-only Eurostar trains. Hyperloop is way below those levels.
Overcapacity is a big issue for US high speed rail. It's not clear there's a market for far more passenger transport between LA and SF than is currently available.
Even at the low rate, there's a Hyperloop capsule every 2 minutes. It's not clear you could reduce that interval by much. The capsules to be at least one emergency stop distance apart, plus a safety margin. Also, the stations will need multiple tracks and airlocks, so that loading and airlock pump-down time can be
overlapped for multiple trains. The system will definitely need low-speed switches (not too hard) and maybe high-speed switches (big, but buildable). Musk oversimplifies those issues.
It's amusing that the proposed location of the "San Francisco" station (p. 51) is not in or near San Francisco. It's near Musk's Tesla plant in the East Bay.
The "fix" for this problem is no good. Look at the code.
DataOutputStream seedBufferOut =
new DataOutputStream(seedBuffer);
seedBufferOut.writeLong(System.currentTimeMillis());
seedBufferOut.writeLong(System.nanoTime());
seedBufferOut.writeInt(Process.myPid());
seedBufferOut.writeInt(Process.myUid());
seedBufferOut.write(BUILD_FINGERPRINT_AND_DEVICE_SERIAL);
seedBufferOut.close();
How well can we predict those values?
For a program which is initialized when the machine starts, quite well.
BUILD_FINGERPRINT_AND_DEVICE_SERIAL is a commonly used device identifier, and is probably being sent in by some apps that "phone home". No entropy there. CurrentTimeMillis is the time and date the machine was powered up. If you guess that was in the last day or so, you'll get a reasonable number of phones. The same is true of nanoTime(), which only has a resolution of milliseconds on Android. Worse, if the crypto library is always initialized shortly after boot, that will always be a small number.
MyUID? Probably not too many of those on a phone. MyPid? This is being captured once at startup, so it's probably one of a small number of values.
The easiest attack would be to look for new connections coming from people in airports or leaving movie theaters. They're likely to have just powered up their phone, so nanoTime and myUID are small numbers, and you know roughly what the time was when they powered up. They won't have made many connections yet, so they're near the beginning of the PNG's stream. So the keyspace you have to search isn't that large.
That code almost looks like it was designed to be cryptographically weak. There's not a single source of real randomness there.
The Bitcoin protocol allows irrevocable one-way transfers between anonymous parties. This is the scammer's dream. Now you can scam people for big bucks remotely, without worrying that they'll come after you with cops or a baseball bat.
Bitcoin was supposed to be a petty-cash system for small online payments. It's turned into a speculative commodity. This hasn't gone well. Several "online wallet" companies turned out to be "take the money and run" operations. Most of the exchanges are flaky. Right now, Mt. Gox, which used to be the biggest exchange, is two months behind on paying out US dollar balances owed to their customers. (It's not yet clear whether they're broke or merely incompetent.)
The Bitcoin world has, in its short life, seen almost every known financial scam. Bucket shops, blind pools, front running, broker embezzlement, Ponzi schemes - it's all there in the tiny Bitcoin world.
Russia Today has an edge simply because it has a big reporting staff. This is unusual in the US today. Only the New York Times, the Wall Street Journal, and the Washington Post have serious world reporting staffs any more.
RT is biased, but it's no worse than Fox News. The embarrassing thing for Americans is that RT doesn't have to make up bad stuff about the US. They just put the bad stuff at the top of their pages.
Blocking third-party cookies, which I've done for years, isn't enough. You also need something like Abine's DoNotTrackMe, which blocks most of the known tracking sites. And you may have to go to the Flash preferences page and turn off some things there.
The BlockSite add-on for Firefox might seem useful, but it's spyware - it reports all your browsing activity to a site in the Czech Republic ("api.wips.com") If you don't "opt in", it won't let you visit major sites like Hotmail. That's acceptable to Mozilla's "Developer Relations Lead". Mozilla isn't as tough on privacy as their PR people say they are.
The whole x86/64 architecture is a mess when you get deep enough. It suffers severely from a commitment to backwards compatibility - your shiny new i7 is still code-compatible with an 80386, you could install DOS on it quite happily.
Not really. X86 turned out to be an OK instruction set for superscalar processors. The RISC "lots of registers. pad instructions to a long length" approach turned out to be a lose. RISC allowed a simple CPU at one instruction per clock. But if you have to make a RISC CPU superscalar, you get all the complexity of a modern x86 CPU, plus about 2x code bloat.
AMD64 is cleaner. I kind of liked the 32-bit segmented hardware, but it was never used much.
Regarding C/C++, Those languages are optimized to be close to the hardware; that's their forte: they are semi-assembler-language. If you optimize the language for software engineering improvements (code design & reliability), then you likely de-optimize it for hardware.
This is a common, and dangerous, misconception. It's quite possible to have efficient languages that are close to the hardware without having buffer overflows all over the place. Pascal did it. The various Modulas did it. Ada does it. Go is getting close. Subscript checking is really cheap, and often free, if the compiler understands how to optimize it. Hoisting subscript checks out of loops is important. The current Go compiler gets the easy cases (FOR loops), which is enough to keep the overhead down for inner math loops. (Math inner loops in Go would optimize better if it had real multidimensional arrays. That may happen.)
We don't have many good alternatives. Hard-compiling Java to machine code (which GCC can do) never caught on. The Modula family died with DEC. Ada was just too wordy. C is fixable, as I point out occasionally, but that's never going to happen short of a 9/11 sized event caused by insecure software. Garbage collected languages are unsuited for low-level programming, although they can go fast.
C++ was supposed to fix C, but the C++ committee went off into template la-la land, and overcomplicated the language.
A major problem we have in computing is the Mess at the Bottom. Some of the basic components of computing aren't very good, but are too deeply embedded to change.
C/C++ This is the big one. There are three basic issues in memory safety - "how big is it", "who can delete it", and "who has it locked". C helps with none of these. C++ tries to paper over the problem with templates, but the mold always comes through the wallpaper, in the form of raw pointers. This is why buffer overflow errors, and the security holes that come with them are still a problem.
The Pascal/Modula/Ada family of languages tried to address this. All the original Macintosh applications were in Pascal. Pascal was difficult to use as a systems programming language, and Modula didn't get it right until Modula 3, by which time it was too late.
UNIX and Linux. UNIX was designed for little machines. MULTICS was the big-machine OS, with hardware-supported security that actually worked. But it couldn't be crammed into a PDP-11. Worse, UNIX did not originally have much in the way of interprocess communication (pipes were originally files, not in-memory objects). Anything which needed multiple intercommunicating processes worked badly. (Sendmail is a legacy of that era.) The UNIX crowd didn't get locking right, and the Berkeley crowd was worse. (Did you know that lock files are not atomic on an NFS file system?) Threads came later, as an afterthought. Signals never worked very well. As a result, putting together a system of multiple programs still sucks.
DMA devices Mainframes had "channels". The end at the CPU talked to memory in a standard way, and devices at the other end talked to the channel. In the IBM world, channels worked with hardware memory protection, so devices couldn't blither all over memory. In the minicomputer and microcomputer world, there were "buses", with memory and devices on the same bus. Devices could write anywhere in memory. Devices and their drivers had to be trusted. So device drivers were usually put in the operating system kernel, where they could break the whole OS, blither all over memory, and open security holes. Most OS crashes stem from this problem. Amusingly, it's been a long time since memory and devices were on the same bus on anything bigger than an ARM CPU. But we still have a hardware architecture that allows devices to write anywhere in memory. This is a legacy from the PDP-11 and the original IBM PC.
Academic microkernel failure Microkernels appeared to be the right approach for security. But the big microkernel project of the 1980s, Mach, at CMU, started with BSD. Their approach was too slow, took too much code, and tried to get cute about avoiding copying by messing with the MMU. This gave microkernels a bad reputation. So now we have kernels with 15,000,000 lines of code. That's never going to stabilize. QNX gets this right, with a modest microkernel that does only message passing, CPU dispatching, and memory management. There's a modest performance penalty for extra copying. You usually get that back because the system overall is simpler. Linux still doesn't have a first-class interprocess communication system. (Attempts include System V IPC, CORBA, and D-bus. Plus various JSON hacks.)
Too much trusted software Application programs often run with all the privileges of the user running them, and more if they can get it. Most applications need far fewer privileges than they have. (But then they wouldn't be able to phone home to get new ads.) This results in a huge attackable surface. The phone people are trying to deal with this, but it's an uphill battle against "apps" which want too much power.
Lack of liability Software has become a huge industry without taking on the liability obligations of one. If software companies were held to the standards of auto companies, software would work a lot better. There are a few areas where software companies do take on liability. Avionics, of course. But an
The author is assuming that the opposition is dumb. It used to be, back when it was a kid in their parents' basement. Now the serious opposition is the Russian Business Network and the People's Liberation Army.
Detected breaches tend to come from the dumb opposition. Those are the ones that put fake login sites on Wordpress blogs.
As a weapon, this thing is overly complex. As a tool, it has potential. Nail guns for construction have to accelerate a nail. This is hard to do electrically. Most nail guns require a hose to an external air compressor. This is a drag, especially if you're on a ladder or roof.
There are "cordless" nail guns. Some use a small propane cylinder for power. (Use only in well ventilated area.) There's a DeWalt unit which uses a battery to spin up a flywheel to get enough power to fire a nail. (Heavy, and has trouble driving a nail into hardwood.) The "cordless" technologies are mostly for small finishing nail jobs.
A magnetic drive nail gun could be a useful alternative, if you could get the weight down below the existing alternatives.
The description is confusing, but the picture is clear - it's a split-transformer system. It's not clear whether it's a continuous one for vehicles in motion or one that just recharges a bus at bus stops. Berkeley, California had one of those in the 1980s, built as a CALTRANS R&D project. That system had energy transfer efficiency of about 65%. They tried 400Hz (which induced annoying hum in metal objects) and 8500Hz (which didn't.) "Pedestrians who walk across the powered roadway
inductor are exposed to 10,000 milligauss (10 gauss) at a height of 1 ft and about 1,000 milligauss (1 gauss) at a height of 4 ft above the center of the inductor's conductor slot."
ACGIH TLVs 2008 safety guidelines: "From 300 Hz to 30 kHz the ceiling whole or partial body exposure should not exceed 0.2 mT" (2 gauss). So the CALTRANS system did not meet current safety standards. Does anyone have the numbers for the Korean system?
Text-oriented CAPTCHA schemes are obsolete, especially as a way to get humans to help with book OCR jobs. If the OCR program can't read it with context, humans probably can't read it out of context. A sizable fraction of book-scan CAPTCHA images aren't even text, let alone words. I've seen ink blots, mathematical formulas, and Cyrillic in what were supposed to be English-language CAPTCHAs.
Reality check - the price of a generic tablet is under $100. You don't even have to get low-priced tablets direct from Shenzhen via Alibaba any more. They're on Amazon now. Many below-$100 tablets are available. Some are quite good.
Microsoft would like to think they can price their device much higher than that. But they can't. Google's own Android tablets are down to $229 and falling. Microsoft tried to price theirs over $1000, and even now they're only down to $350.
From the site, there's not enough info to tell what security properties this proposal has. Mostly, they're just begging for money.
It might not be that hard to do privacy-enhanced mail today. Both browsers and some mail clients (i.e. Thunderbird) accept plug-ins, so doing encryption and decryption on the client side is possible even for web mail. You could still use Gmail, but all Google would see are big strings of random-looking text. Your browser plug-in would decrypt that when displaying Gmail output. Of course, Google's indexing and ad matching wouldn't work.
The big problem is publishing and finding the recipient's public key. The 1993 PEM scheme wanted to do this with SSL-type certs, but that never caught on. Self-signed certs are vulnerable to man-in-the-middle attacks. But suppose that you published your public key on some social network (Twitter, Flickr, Facebook...) and your mail client checked your own key at random times. Then you'd detect if someone was messing with your public key. It's not airtight, but it's better than nothing, and any widespread tampering with public keys would be noticed.
None of this requires any cooperation from, or trust in, mail servers. It's entirely client-side, where it should be.
Imagine meat that can stay vacuum sealed on the shelf with no refrigeration for months and still taste fresh!
That's available now. Irradiated meat is available, but not widely sold. There are some tricks to preserving taste, one being to vacuum-pack and freeze to -30C before irradiation.
Slashdot Mirror
The other day a Google tech recruiter (not a headhunter) contacted me about an interview at Google. This after I turned down a second interview with them seven years ago.
Weird. I had almost an identical experience last week. A Google tech recruiter sent me messages via both email and LinkedIn. He'd been looking at my technical web sites. I'm not interested; it's been years since I had to work for someone else. But I called the guy. It really was a Google recruiter. I hadn't heard from Google in about five years. They must be going through their back files.
The largest issue I have with the hyperloop proposal is its rather pitiful capacity. At the highest rate proposed, with one cart every 30 seconds it still only transports ~3600 PAX/hr, which is about on par with a 3 lane highway and that is before mixing in the car carriers.
Musk writes in his proposal: "Assuming an average departure time of 2 minutes between capsules, a minimum of 28 passengers per capsule are required to meet 840 passengers per hour." So it's even worse than 3600PAX/hr.
Compare current flight capacity. At peak, there are 5 flights an hour from SF to LA. The most common plane on that run is a Boeing 737 with 137 seats, for 685 seats/hour. So the Hyperloop has more capacity than the current aircraft. Comparing with other tunnel systems, Eurotunnel moves about 30 trains per hour, and their trains are 400 meters long with a seating capacity of 750 on the passenger-only Eurostar trains. Hyperloop is way below those levels.
Overcapacity is a big issue for US high speed rail. It's not clear there's a market for far more passenger transport between LA and SF than is currently available.
Even at the low rate, there's a Hyperloop capsule every 2 minutes. It's not clear you could reduce that interval by much. The capsules to be at least one emergency stop distance apart, plus a safety margin. Also, the stations will need multiple tracks and airlocks, so that loading and airlock pump-down time can be overlapped for multiple trains. The system will definitely need low-speed switches (not too hard) and maybe high-speed switches (big, but buildable). Musk oversimplifies those issues.
It's amusing that the proposed location of the "San Francisco" station (p. 51) is not in or near San Francisco. It's near Musk's Tesla plant in the East Bay.
If your customers hate you, you probably have a problem with your product. Deal with it.
The "fix" for this problem is no good. Look at the code.
DataOutputStream seedBufferOut = new DataOutputStream(seedBuffer);
seedBufferOut.writeLong(System.currentTimeMillis());
seedBufferOut.writeLong(System.nanoTime());
seedBufferOut.writeInt(Process.myPid());
seedBufferOut.writeInt(Process.myUid());
seedBufferOut.write(BUILD_FINGERPRINT_AND_DEVICE_SERIAL);
seedBufferOut.close();
How well can we predict those values?
For a program which is initialized when the machine starts, quite well. BUILD_FINGERPRINT_AND_DEVICE_SERIAL is a commonly used device identifier, and is probably being sent in by some apps that "phone home". No entropy there. CurrentTimeMillis is the time and date the machine was powered up. If you guess that was in the last day or so, you'll get a reasonable number of phones. The same is true of nanoTime(), which only has a resolution of milliseconds on Android. Worse, if the crypto library is always initialized shortly after boot, that will always be a small number. MyUID? Probably not too many of those on a phone. MyPid? This is being captured once at startup, so it's probably one of a small number of values.
The easiest attack would be to look for new connections coming from people in airports or leaving movie theaters. They're likely to have just powered up their phone, so nanoTime and myUID are small numbers, and you know roughly what the time was when they powered up. They won't have made many connections yet, so they're near the beginning of the PNG's stream. So the keyspace you have to search isn't that large.
That code almost looks like it was designed to be cryptographically weak. There's not a single source of real randomness there.
Of course Twitter is a spam magnet. Twitter won't let people write Twitter clients with spam filters.
Google has to ferry their people. Mountain View voted down Google's plan to build a 1000-unit dorm complex.
Bear in mind that most Google employees are not "techies". They're sales reps selling ads. When you think Google, think "Mad Men", not rocket science.
The Bitcoin protocol allows irrevocable one-way transfers between anonymous parties. This is the scammer's dream. Now you can scam people for big bucks remotely, without worrying that they'll come after you with cops or a baseball bat.
Bitcoin was supposed to be a petty-cash system for small online payments. It's turned into a speculative commodity. This hasn't gone well. Several "online wallet" companies turned out to be "take the money and run" operations. Most of the exchanges are flaky. Right now, Mt. Gox, which used to be the biggest exchange, is two months behind on paying out US dollar balances owed to their customers. (It's not yet clear whether they're broke or merely incompetent.)
The Bitcoin world has, in its short life, seen almost every known financial scam. Bucket shops, blind pools, front running, broker embezzlement, Ponzi schemes - it's all there in the tiny Bitcoin world.
This thing is heavier than some ultralight helicopters.
If you want an ultralight helicopter, they're available for as little as $6,000.
Russia Today has an edge simply because it has a big reporting staff. This is unusual in the US today. Only the New York Times, the Wall Street Journal, and the Washington Post have serious world reporting staffs any more.
RT is biased, but it's no worse than Fox News. The embarrassing thing for Americans is that RT doesn't have to make up bad stuff about the US. They just put the bad stuff at the top of their pages.
Blocking third-party cookies, which I've done for years, isn't enough. You also need something like Abine's DoNotTrackMe, which blocks most of the known tracking sites. And you may have to go to the Flash preferences page and turn off some things there.
The BlockSite add-on for Firefox might seem useful, but it's spyware - it reports all your browsing activity to a site in the Czech Republic ("api.wips.com") If you don't "opt in", it won't let you visit major sites like Hotmail. That's acceptable to Mozilla's "Developer Relations Lead". Mozilla isn't as tough on privacy as their PR people say they are.
At some point the US and the world lost its "will" in developing space technology.
It's not a "will" problem. It's that there are limits on what you can do with chemical fuels, and they were reached 40 years ago.
The vast majority of attempts didn't even get as far as the log-in screen, which requires signing into a Google account to connect.
That's Google. "Public" WiFi with data mining.
The whole x86/64 architecture is a mess when you get deep enough. It suffers severely from a commitment to backwards compatibility - your shiny new i7 is still code-compatible with an 80386, you could install DOS on it quite happily.
Not really. X86 turned out to be an OK instruction set for superscalar processors. The RISC "lots of registers. pad instructions to a long length" approach turned out to be a lose. RISC allowed a simple CPU at one instruction per clock. But if you have to make a RISC CPU superscalar, you get all the complexity of a modern x86 CPU, plus about 2x code bloat.
AMD64 is cleaner. I kind of liked the 32-bit segmented hardware, but it was never used much.
Regarding C/C++, Those languages are optimized to be close to the hardware; that's their forte: they are semi-assembler-language. If you optimize the language for software engineering improvements (code design & reliability), then you likely de-optimize it for hardware.
This is a common, and dangerous, misconception. It's quite possible to have efficient languages that are close to the hardware without having buffer overflows all over the place. Pascal did it. The various Modulas did it. Ada does it. Go is getting close. Subscript checking is really cheap, and often free, if the compiler understands how to optimize it. Hoisting subscript checks out of loops is important. The current Go compiler gets the easy cases (FOR loops), which is enough to keep the overhead down for inner math loops. (Math inner loops in Go would optimize better if it had real multidimensional arrays. That may happen.)
We don't have many good alternatives. Hard-compiling Java to machine code (which GCC can do) never caught on. The Modula family died with DEC. Ada was just too wordy. C is fixable, as I point out occasionally, but that's never going to happen short of a 9/11 sized event caused by insecure software. Garbage collected languages are unsuited for low-level programming, although they can go fast.
C++ was supposed to fix C, but the C++ committee went off into template la-la land, and overcomplicated the language.
A major problem we have in computing is the Mess at the Bottom. Some of the basic components of computing aren't very good, but are too deeply embedded to change.
The Pascal/Modula/Ada family of languages tried to address this. All the original Macintosh applications were in Pascal. Pascal was difficult to use as a systems programming language, and Modula didn't get it right until Modula 3, by which time it was too late.
Items we can expect to see on the next Xbox, the Xbox Infinity:
The author is assuming that the opposition is dumb. It used to be, back when it was a kid in their parents' basement. Now the serious opposition is the Russian Business Network and the People's Liberation Army.
Detected breaches tend to come from the dumb opposition. Those are the ones that put fake login sites on Wordpress blogs.
As a weapon, this thing is overly complex. As a tool, it has potential. Nail guns for construction have to accelerate a nail. This is hard to do electrically. Most nail guns require a hose to an external air compressor. This is a drag, especially if you're on a ladder or roof.
There are "cordless" nail guns. Some use a small propane cylinder for power. (Use only in well ventilated area.) There's a DeWalt unit which uses a battery to spin up a flywheel to get enough power to fire a nail. (Heavy, and has trouble driving a nail into hardwood.) The "cordless" technologies are mostly for small finishing nail jobs.
A magnetic drive nail gun could be a useful alternative, if you could get the weight down below the existing alternatives.
The description is confusing, but the picture is clear - it's a split-transformer system. It's not clear whether it's a continuous one for vehicles in motion or one that just recharges a bus at bus stops. Berkeley, California had one of those in the 1980s, built as a CALTRANS R&D project. That system had energy transfer efficiency of about 65%. They tried 400Hz (which induced annoying hum in metal objects) and 8500Hz (which didn't.) "Pedestrians who walk across the powered roadway inductor are exposed to 10,000 milligauss (10 gauss) at a height of 1 ft and about 1,000 milligauss (1 gauss) at a height of 4 ft above the center of the inductor's conductor slot."
ACGIH TLVs 2008 safety guidelines: "From 300 Hz to 30 kHz the ceiling whole or partial body exposure should not exceed 0.2 mT" (2 gauss). So the CALTRANS system did not meet current safety standards. Does anyone have the numbers for the Korean system?
Yes, there's a way to turn it off. Go to "about:config" and set "social.enabled" to False. This was previously the default.
Text-oriented CAPTCHA schemes are obsolete, especially as a way to get humans to help with book OCR jobs. If the OCR program can't read it with context, humans probably can't read it out of context. A sizable fraction of book-scan CAPTCHA images aren't even text, let alone words. I've seen ink blots, mathematical formulas, and Cyrillic in what were supposed to be English-language CAPTCHAs.
The generic business plan of Google Ventures companies, based on their privacy policies, seems to be
Even their thermostat phones home and sends data about when you're home to a server.
Reality check - the price of a generic tablet is under $100. You don't even have to get low-priced tablets direct from Shenzhen via Alibaba any more. They're on Amazon now. Many below-$100 tablets are available. Some are quite good.
Microsoft would like to think they can price their device much higher than that. But they can't. Google's own Android tablets are down to $229 and falling. Microsoft tried to price theirs over $1000, and even now they're only down to $350.
From the site, there's not enough info to tell what security properties this proposal has. Mostly, they're just begging for money.
It might not be that hard to do privacy-enhanced mail today. Both browsers and some mail clients (i.e. Thunderbird) accept plug-ins, so doing encryption and decryption on the client side is possible even for web mail. You could still use Gmail, but all Google would see are big strings of random-looking text. Your browser plug-in would decrypt that when displaying Gmail output. Of course, Google's indexing and ad matching wouldn't work.
The big problem is publishing and finding the recipient's public key. The 1993 PEM scheme wanted to do this with SSL-type certs, but that never caught on. Self-signed certs are vulnerable to man-in-the-middle attacks. But suppose that you published your public key on some social network (Twitter, Flickr, Facebook...) and your mail client checked your own key at random times. Then you'd detect if someone was messing with your public key. It's not airtight, but it's better than nothing, and any widespread tampering with public keys would be noticed.
None of this requires any cooperation from, or trust in, mail servers. It's entirely client-side, where it should be.
Imagine meat that can stay vacuum sealed on the shelf with no refrigeration for months and still taste fresh!
That's available now. Irradiated meat is available, but not widely sold. There are some tricks to preserving taste, one being to vacuum-pack and freeze to -30C before irradiation.