Remember X3D? Didn't think so. X3D is VRML in XML syntax. It was supposed to put "3D on the web about a decade ago". There's also "Quicktime VR", which lets sites display a panorama, which can be either a move around the object or a view around the camera. A few real estate sites tried it. Didn't help much.
The real "3D on the Web" is in the industrial area. Companies from Asea Brown Boveri to Zummer are putting solid models of their products on the web. Not to look at, though. The models are for use with 3D CAD programs, so you can import the model for an off-the shelf gear or shaft extender and make sure it will fit before you buy. This makes mechanical design much easier, and tends to push buyers towards the sites with 3D models.
Parts Community hosts many such catalogs. Gears, gear motors, inductive proximity sensors, bearings, pneumatic cylinders, springs, robot parts, pipe fittings... The stuff you need to get work done.
For less prestigious universities, "the inclusion of mathematical requirements can reduce the number of applicants to unsustainably low levels"
The owner of the DNA Lounge in San Francisco once noted this conversation with some construction people:
Noewell: Hey, do you have a calculator?
Barry: (Hands over his Palm Pilot.)
Noewell: (Looks...) No, I need one that can do square roots.
Barry: Huh??
Noewell: You know, Pythagorean Theorem?
Barry: Uhhhhh...
Noewell: A^2 + B^2 = C^2?
(Waits...)
I'm hanging a diagonal cable, and I know the width and height and need to know how long to cut it?
Barry: So this is that actual real world use of geometry that they told us about! I didn't believe it! I never expected to see this happen!
All NSA is doing here is trying to get secure voice over IP on a smart phone. They're not trying to secure the phone for non-voice data or support secure applications. The smart phone isn't helping; if they could get people to carry a second voice-only device, it would be far easier. A voice-only phone with all the firmware in ROM would be a much more secure device.
A better approach is to break down your engine into a large number of small more or less self contained tasks, then implement a jobs system that takes those tasks and runs them on whatever processor is free at that moment.
That works fine on a shared-memory multiprocessor. On a Cell processor with 256K, switching a processor from one task to another requires moving in new code and data, not just CPU dispatching. That's not something you can do many times per frame cycle.
The trouble with the Cell processor is that there's not enough memory per processor. Each of the little processors (the "SPE" units) in the PS3 only has 256KB of RAM. That's not enough to store a frame. It's not enough to store a game level, or a significant amount of geometry. It's more like having a number of DSPs available.
This forces redesigning the program to work in batch mode. A batch job is one frame, but it's still a batch job. Data for one frame cycle is sequentially pumped through one or more SPEs. There's not much random access, because access to main memory from an SPE is in big blocks, transferred in the background.
This is both limiting and a huge pain. Especially when the competition is selling shared-memory multiprocessors. I used to do game physics engines, and when the PS3 came out, my reaction was "I'm glad I sold off that technology and got out of the business." I knew some people at Sony's SCEA R&D center, and they basically threw all their smart people at trying to figure out how to use the Cell effectively. Many of the early games really ran in the main CPU, with the SPEs managing things that didn't affect gameplay, like particles for fire, explosions, smoke, and such.
If each SPE came with a few megabytes of RAM, instead of only 256K, it wouldn't be so bad. Then you could probably have the physics engine in one CPU, the AI in another, the background object management in a third, and so on. But each of those things needs more state than whatever fraction of 256K is left over after the code is loaded.
There's a long history of Cell-like architectures in the supercomputer field. The BBN Butterfly, the NCube Hypercube, and the Connection Machine also consisted of a large number of processors, each with a small memory. None were successful. One of the lessons of multiprocessing computer architecture to date is that the two extremes - shared memory multiprocessors and networked clusters of separate computers - are useful. None of the partially-shared machines have been successful. The Cell is the only one ever to be mass-produced.
Great for audio, though. The audio guys like having their own processor, and audio processing really is a streaming process of tight loops without much state.
Hearing your own voice with a slight delay won't confuse people any more. Bad cell phone interconnects and VoIP with failed echo suppressors produce that effect all the time. Today it just makes people talk louder.
(Sometimes I think ISDN did telephony right. Rigid timing, no compression, full duplex, digital end to end. ISDN voice never caught on in the US, but it's widely deployed in parts of Europe.)
The real question is, why are printer drivers so privileged that "root" access is required? I assume they're no longer in the kernel; that's so last-cen. So why aren't they just applications in some directory owned by the "printer" user and managed by some utility that runs as that user?
It should be required first for poor-visibility vehicles. Ones where the back is high, or opaque, like SUVs, vans, trucks, and RVs. Ones where the C pillar is unusually large, creating a big blind spot. Ones where there's some other visibility issue, like a big spoiler.
If visibility is reasonable, a close-range obstacle detection system should be provided to cover the remaining low blind spot. Many vehicles already have that for parking assistance, so that's not a big problem.
Most back-over accidents involve either poor-visibility vehicles or very small (1-2 years) children.
There's a whole industry out there spamming Google+. There's "googleplus1supply.com", ("total +1s sent to our clients: 25,364,921"), "plus1sem.com" ("Buy 2000
Google Plus Ones and SKYROCKET your
rankings") "buyplus1fans.com" ("Our service
helps boost your Google +1 presence which
will convert into higher rankings equaling
more customers!"), and "buyrealplusone.com"
("Crush your competition!"). A sizable fraction of Google+ accounts are probably from spammers.
We have a paper on this: "Social is bad for search, and search is bad for social", which is a tour of the social spam ecosystem. At the top are advertising agencies, which hire SEO firms to boost their rankings and don't ask too many questions. The SEO firms buy those fake "+1"s, "Likes", and, until Google stopped counting them, "tweets". The businesses which sell the +1s and "likes" deal with firms that create and sell fake Google and Facebook accounts. Further down into the slime are the businesses that sell short-term IP addresses and phone numbers for verification of the fake accounts. Down at the bottom are the botnets that host much of this.
Social networking is the web spammer's dream. No expensive link farm sites to host and fill with fresh content. The social networks host your spam for you, for free.
The "optionally manned" bomber sounds like one of those transition craft that appears as a new technology is replacing an old one. A classic example were steamships of the 19th century. Various combinations of paddle wheels, screws, and sails were tried. None of the hybrids were very successful.
In bombers, the classic example is the B-36, with four jet engines and six propeller engines. The B-36 was a stopgap measure until the all-jet bombers were ready, and was quickly replaced by the B-47 and B-52.
ICBMs and cruise missiles already are unmanned. The US hasn't had a strategic aircraft nuclear bombing force since SAC was disbanded in 1992. There are still many US aircraft which could carry nuclear weapons if necessary, but that's a secondary capability now. It's been over 20 years since there were US nuclear-armed bombers in the air at all times, and others parked near the end of runways ready to go.
What killed Kodak was the demise of the photographic consumables business. They had a 70% margin on film. The margin on photographic paper was probably even higher. And the developing business was profitable, too. All the consumables products had strong repeat business. Digital cameras offered none of that.
Kodak kept trying to somehow attach a consumable to digital photography. They tried PhotoCD, printer paper, and ink. They even tried selling flash memory cards. They bought Ofoto, an early picture-sharing site, and tried to make it a pay service.
None of those offered the margins or market presence that film did, and none were notably successful.
Without a consumables business, Kodak had no competitive edge.
The end came when cameras became a component of phones. There was no longer a defined low-end photography business at all.
The article skips over the issue of how many bits they can store. It does indicate that numbers > 1 have been achieved, but RAM in megabit, let alone gigabit size, seems to be a long way off.
There have been a few optical switches with fiber optic delay loops. If a packet comes in and the outgoing link is busy, the packet is shunted to a delay loop for one packet time. This works best if the packets are all the same size, like ATM, but it's been made to work with variable sized packets. So far, there's not much commercial technology in the area. Lots of papers, though. People have been working on this problem for over a decade, and there's a little progress each year.
A few bits of pure optical storage and logic will help. If there's enough to handle packet routing and tags, a useful switch can be all-optical, even if storing the data packets themselves in "optical RAM" isn't feasible.
Read the timeline of events. Dharun Ravi was kicked out of his own room for the night so that Clementi could have gay sex with an older guy from off campus. Ravi then went to a female friend's room, Molly Wei, connected to his own laptop back in his room over iChat, and watched what was going on. Ravi posts the following message to his Twitter account: "Roommate asked for the room till midnight. I went into molly's room and turned on my webcam. I saw him making out with a dude. Yay." Molly has some of her female friends over to watch briefly.
Soon after, Wei IMs her boyfriend, Austin Chung, regarding Clementi: "He's NICE but he's kissing a guy right now / like THEY WERE GROPING EACH OTHER EWWW."
Then Clementi does the whole thing again, two days later, with the same guy, again throwing his roommate out so he can have sex. Some of this gets seen on iChat, too. Clementi is already aware he was seen on iChat last time.
Where's the expectation of privacy here? Clementi made no effort to conceal what he was doing. Ravi, on the other hand, has a First Amendment right to comment on the situation.
Of course they should pay a dividend. That's what companies are for. The value of a stock is the present value of all future dividends. That's classic Graham and Dodd, and Warren Buffet. Stock buybacks mostly benefit executives with stock options. Most stock option / stock buyback programs don't reduce the net amount of stock outstanding. Yes, dividends are taxed. So?
The trouble with acquisitions is that buying a company with lower margins devalues the stock. Apple has incredibly high margins for a manufacturer, and they will have a tough time finding someone to acquire with better margins. Of course, Apple really isn't a manufacturer; that's all outsourced. Apple's "manufacturing" acquisitions in semiconductors, Anobit, Intrinsity, and PA Semi were all "fabless" companies. They did design, not manufacturing.
Google has a worse problem. Google stock peaked in 2007, so they're no longer a growth company and should be paying a dividend. Instead, they keep trying to expand into new areas, and not making money in them. 96% of revenue is still from ads.
So what's the actual audio quality? It's probably inferior to uncompressed 16-bit 48KHz CD audio. I've been trying to find an audio sample on line, but haven't found one yet.
It's actually a variant of H.264/MPEG-4 AVC, which is the codec on Blu-Ray audio. But not at a high bit rate, as on Blu-Ray discs. It's AAC/ELD v2, at 24Kb/s.
We'll probably see a generation of remotes that look more like a e-reader, with a nonvolatile display. Most tablet devices require charging daily, if not more often. TV remotes today only need batteries once every few years.
The genre was killed off by a gag book in 2003, "Escape from Fire Island. It's a gay zombie hyperlink novel: "If you run toward the nearest ferry terminal, turn to page 44. If you flirt with the cute twink, turn to page 55. If you throw caution to the wind and join the nearest circuit party, turn to page 80." It was published as a paper book, and was badly timed -- the gay novel boom was over, and the zombie novel boom was years in the future.
The new version of C++ is a decade behind schedule, and consists mostly of marginal features. Memory safety hasn't improved. Concurrency isn't really supported in the language; all that's really been done is to nail down some of the semantic issues that matter when multiple threads are executing on superscalar processors. There are lots of new features only useful to people writing templates, which are a terrible programming environment. "auto" is useful (I wanted to call it "let", but there was objection to a new short keyword), mainly because the type definitions of iterators are so bulky. The main purpose of "auto" is to allow
for (auto p = arr.begin(); p != arr.end(); p++) {... } without worrying about the type of arr. As long as arr is an iterable collection, that should work.
This still doesn't prevent buffer overflows, but at least the most concise way to iterate over an array is reasonably safe. (Not totally safe; modifying a collection over which you are iterating breaks the memory model.) Over the next few decades, the number of buffer overflow bugs might decrease slightly.
It's an improvement, but not one that was worth waiting a decade for.
The real beginning of email, in the sense of fully automatic message switching, was "Western Union Plan 55-A", introduced in 1948 and shut down in 1976. Imagine Sendmail, with paper tape punches and readers with bins between them as the buffers. Such systems handled most telegrams in the US for over 25 years.
There were message switching systems before that, but Plan 55-A was the first one that could forward a message from source to destination without human intervention at the switching points. It could even handle messages with multiple destination addresses.
Before that, there were teletypewriter exchanges, but they involved dialing up a connection directly between sender and receiver. They were basically telephone switches repurposed for teletypes. That's what TWX and Telex were. Those were automatic dial back to the early 1930s.
The latest trend seems to be to abandon the desktop metaphor and make everything look like an iPhone. Big graphical buttons arranged in a grid, easy scrolling, no overlapping windows.
Superficial article about Mountain Pass. The big problem they have is finding a place to dump the tailings. A rare earth mine needs big settling ponds. The Mountain Pass solution is that they've built a pipeline to Ivanpah Dry Lake on the Nevada border.
The mine tailings are slightly radioactive, because the dirt in the area being mined has some uranium and thorium in it. This isn't a big deal once the water has evaporated and it's solid material again, but the water in the tailings ponds has to be kept from leaching into a water supply.
Slashdot Mirror
Remember X3D? Didn't think so. X3D is VRML in XML syntax. It was supposed to put "3D on the web about a decade ago". There's also "Quicktime VR", which lets sites display a panorama, which can be either a move around the object or a view around the camera. A few real estate sites tried it. Didn't help much.
The real "3D on the Web" is in the industrial area. Companies from Asea Brown Boveri to Zummer are putting solid models of their products on the web. Not to look at, though. The models are for use with 3D CAD programs, so you can import the model for an off-the shelf gear or shaft extender and make sure it will fit before you buy. This makes mechanical design much easier, and tends to push buyers towards the sites with 3D models.
Parts Community hosts many such catalogs. Gears, gear motors, inductive proximity sensors, bearings, pneumatic cylinders, springs, robot parts, pipe fittings... The stuff you need to get work done.
Somehow, building a giant broadcasting tower in a city seems a dated idea. Supposedly Tokyo Tower was being blocked by new tall buildings.
The problem is the $40K price. We're still in a major recession.
From the article:
For less prestigious universities, "the inclusion of mathematical requirements can reduce the number of applicants to unsustainably low levels"
The owner of the DNA Lounge in San Francisco once noted this conversation with some construction people:
Noewell: Hey, do you have a calculator?
Barry: (Hands over his Palm Pilot.)
Noewell: (Looks...) No, I need one that can do square roots.
Barry: Huh??
Noewell: You know, Pythagorean Theorem?
Barry: Uhhhhh...
Noewell: A^2 + B^2 = C^2?
(Waits...)
I'm hanging a diagonal cable, and I know the width and height and need to know how long to cut it?
Barry: So this is that actual real world use of geometry that they told us about! I didn't believe it! I never expected to see this happen!
All NSA is doing here is trying to get secure voice over IP on a smart phone. They're not trying to secure the phone for non-voice data or support secure applications. The smart phone isn't helping; if they could get people to carry a second voice-only device, it would be far easier. A voice-only phone with all the firmware in ROM would be a much more secure device.
A better approach is to break down your engine into a large number of small more or less self contained tasks, then implement a jobs system that takes those tasks and runs them on whatever processor is free at that moment.
That works fine on a shared-memory multiprocessor. On a Cell processor with 256K, switching a processor from one task to another requires moving in new code and data, not just CPU dispatching. That's not something you can do many times per frame cycle.
The trouble with the Cell processor is that there's not enough memory per processor. Each of the little processors (the "SPE" units) in the PS3 only has 256KB of RAM. That's not enough to store a frame. It's not enough to store a game level, or a significant amount of geometry. It's more like having a number of DSPs available.
This forces redesigning the program to work in batch mode. A batch job is one frame, but it's still a batch job. Data for one frame cycle is sequentially pumped through one or more SPEs. There's not much random access, because access to main memory from an SPE is in big blocks, transferred in the background.
This is both limiting and a huge pain. Especially when the competition is selling shared-memory multiprocessors. I used to do game physics engines, and when the PS3 came out, my reaction was "I'm glad I sold off that technology and got out of the business." I knew some people at Sony's SCEA R&D center, and they basically threw all their smart people at trying to figure out how to use the Cell effectively. Many of the early games really ran in the main CPU, with the SPEs managing things that didn't affect gameplay, like particles for fire, explosions, smoke, and such.
If each SPE came with a few megabytes of RAM, instead of only 256K, it wouldn't be so bad. Then you could probably have the physics engine in one CPU, the AI in another, the background object management in a third, and so on. But each of those things needs more state than whatever fraction of 256K is left over after the code is loaded.
There's a long history of Cell-like architectures in the supercomputer field. The BBN Butterfly, the NCube Hypercube, and the Connection Machine also consisted of a large number of processors, each with a small memory. None were successful. One of the lessons of multiprocessing computer architecture to date is that the two extremes - shared memory multiprocessors and networked clusters of separate computers - are useful. None of the partially-shared machines have been successful. The Cell is the only one ever to be mass-produced.
Great for audio, though. The audio guys like having their own processor, and audio processing really is a streaming process of tight loops without much state.
Hearing your own voice with a slight delay won't confuse people any more. Bad cell phone interconnects and VoIP with failed echo suppressors produce that effect all the time. Today it just makes people talk louder.
(Sometimes I think ISDN did telephony right. Rigid timing, no compression, full duplex, digital end to end. ISDN voice never caught on in the US, but it's widely deployed in parts of Europe.)
The real question is, why are printer drivers so privileged that "root" access is required? I assume they're no longer in the kernel; that's so last-cen. So why aren't they just applications in some directory owned by the "printer" user and managed by some utility that runs as that user?
It should be required first for poor-visibility vehicles. Ones where the back is high, or opaque, like SUVs, vans, trucks, and RVs. Ones where the C pillar is unusually large, creating a big blind spot. Ones where there's some other visibility issue, like a big spoiler.
If visibility is reasonable, a close-range obstacle detection system should be provided to cover the remaining low blind spot. Many vehicles already have that for parking assistance, so that's not a big problem.
Most back-over accidents involve either poor-visibility vehicles or very small (1-2 years) children.
There's a whole industry out there spamming Google+. There's "googleplus1supply.com", ("total +1s sent to our clients: 25,364,921"), "plus1sem.com" ("Buy 2000 Google Plus Ones and SKYROCKET your rankings") "buyplus1fans.com" ("Our service helps boost your Google +1 presence which will convert into higher rankings equaling more customers!"), and "buyrealplusone.com" ("Crush your competition!"). A sizable fraction of Google+ accounts are probably from spammers.
We have a paper on this: "Social is bad for search, and search is bad for social", which is a tour of the social spam ecosystem. At the top are advertising agencies, which hire SEO firms to boost their rankings and don't ask too many questions. The SEO firms buy those fake "+1"s, "Likes", and, until Google stopped counting them, "tweets". The businesses which sell the +1s and "likes" deal with firms that create and sell fake Google and Facebook accounts. Further down into the slime are the businesses that sell short-term IP addresses and phone numbers for verification of the fake accounts. Down at the bottom are the botnets that host much of this.
Social networking is the web spammer's dream. No expensive link farm sites to host and fill with fresh content. The social networks host your spam for you, for free.
Narrowing the reach of "social" signals with "circles" and friend lists helps a little, but not all that much. That's why there are programs which generate accounts which appear to be from young women.
The "optionally manned" bomber sounds like one of those transition craft that appears as a new technology is replacing an old one. A classic example were steamships of the 19th century. Various combinations of paddle wheels, screws, and sails were tried. None of the hybrids were very successful.
In bombers, the classic example is the B-36, with four jet engines and six propeller engines. The B-36 was a stopgap measure until the all-jet bombers were ready, and was quickly replaced by the B-47 and B-52.
ICBMs and cruise missiles already are unmanned. The US hasn't had a strategic aircraft nuclear bombing force since SAC was disbanded in 1992. There are still many US aircraft which could carry nuclear weapons if necessary, but that's a secondary capability now. It's been over 20 years since there were US nuclear-armed bombers in the air at all times, and others parked near the end of runways ready to go.
What killed Kodak was the demise of the photographic consumables business. They had a 70% margin on film. The margin on photographic paper was probably even higher. And the developing business was profitable, too. All the consumables products had strong repeat business. Digital cameras offered none of that.
Kodak kept trying to somehow attach a consumable to digital photography. They tried PhotoCD, printer paper, and ink. They even tried selling flash memory cards. They bought Ofoto, an early picture-sharing site, and tried to make it a pay service. None of those offered the margins or market presence that film did, and none were notably successful.
Without a consumables business, Kodak had no competitive edge.
The end came when cameras became a component of phones. There was no longer a defined low-end photography business at all.
The article skips over the issue of how many bits they can store. It does indicate that numbers > 1 have been achieved, but RAM in megabit, let alone gigabit size, seems to be a long way off.
There have been a few optical switches with fiber optic delay loops. If a packet comes in and the outgoing link is busy, the packet is shunted to a delay loop for one packet time. This works best if the packets are all the same size, like ATM, but it's been made to work with variable sized packets. So far, there's not much commercial technology in the area. Lots of papers, though. People have been working on this problem for over a decade, and there's a little progress each year.
A few bits of pure optical storage and logic will help. If there's enough to handle packet routing and tags, a useful switch can be all-optical, even if storing the data packets themselves in "optical RAM" isn't feasible.
Read the timeline of events. Dharun Ravi was kicked out of his own room for the night so that Clementi could have gay sex with an older guy from off campus. Ravi then went to a female friend's room, Molly Wei, connected to his own laptop back in his room over iChat, and watched what was going on. Ravi posts the following message to his Twitter account: "Roommate asked for the room till midnight. I went into molly's room and turned on my webcam. I saw him making out with a dude. Yay." Molly has some of her female friends over to watch briefly. Soon after, Wei IMs her boyfriend, Austin Chung, regarding Clementi: "He's NICE but he's kissing a guy right now / like THEY WERE GROPING EACH OTHER EWWW."
Then Clementi does the whole thing again, two days later, with the same guy, again throwing his roommate out so he can have sex. Some of this gets seen on iChat, too. Clementi is already aware he was seen on iChat last time.
Where's the expectation of privacy here? Clementi made no effort to conceal what he was doing. Ravi, on the other hand, has a First Amendment right to comment on the situation.
Of course they should pay a dividend. That's what companies are for. The value of a stock is the present value of all future dividends. That's classic Graham and Dodd, and Warren Buffet. Stock buybacks mostly benefit executives with stock options. Most stock option / stock buyback programs don't reduce the net amount of stock outstanding. Yes, dividends are taxed. So?
The trouble with acquisitions is that buying a company with lower margins devalues the stock. Apple has incredibly high margins for a manufacturer, and they will have a tough time finding someone to acquire with better margins. Of course, Apple really isn't a manufacturer; that's all outsourced. Apple's "manufacturing" acquisitions in semiconductors, Anobit, Intrinsity, and PA Semi were all "fabless" companies. They did design, not manufacturing.
Google has a worse problem. Google stock peaked in 2007, so they're no longer a growth company and should be paying a dividend. Instead, they keep trying to expand into new areas, and not making money in them. 96% of revenue is still from ads.
So what's the actual audio quality? It's probably inferior to uncompressed 16-bit 48KHz CD audio. I've been trying to find an audio sample on line, but haven't found one yet.
It's actually a variant of H.264/MPEG-4 AVC, which is the codec on Blu-Ray audio. But not at a high bit rate, as on Blu-Ray discs. It's AAC/ELD v2, at 24Kb/s.
It's already in IOS Facetime, anyway.
We'll probably see a generation of remotes that look more like a e-reader, with a nonvolatile display. Most tablet devices require charging daily, if not more often. TV remotes today only need batteries once every few years.
The genre was killed off by a gag book in 2003, "Escape from Fire Island. It's a gay zombie hyperlink novel: "If you run toward the nearest ferry terminal, turn to page 44. If you flirt with the cute twink, turn to page 55. If you throw caution to the wind and join the nearest circuit party, turn to page 80." It was published as a paper book, and was badly timed -- the gay novel boom was over, and the zombie novel boom was years in the future.
The new version of C++ is a decade behind schedule, and consists mostly of marginal features. Memory safety hasn't improved. Concurrency isn't really supported in the language; all that's really been done is to nail down some of the semantic issues that matter when multiple threads are executing on superscalar processors. There are lots of new features only useful to people writing templates, which are a terrible programming environment. "auto" is useful (I wanted to call it "let", but there was objection to a new short keyword), mainly because the type definitions of iterators are so bulky. The main purpose of "auto" is to allow for (auto p = arr.begin(); p != arr.end(); p++) {... } without worrying about the type of arr. As long as arr is an iterable collection, that should work.
This still doesn't prevent buffer overflows, but at least the most concise way to iterate over an array is reasonably safe. (Not totally safe; modifying a collection over which you are iterating breaks the memory model.) Over the next few decades, the number of buffer overflow bugs might decrease slightly.
It's an improvement, but not one that was worth waiting a decade for.
Rating teachers based on student performance is probably more accurate than rating students. The statistical base is larger.
The real beginning of email, in the sense of fully automatic message switching, was "Western Union Plan 55-A", introduced in 1948 and shut down in 1976. Imagine Sendmail, with paper tape punches and readers with bins between them as the buffers. Such systems handled most telegrams in the US for over 25 years.
There were message switching systems before that, but Plan 55-A was the first one that could forward a message from source to destination without human intervention at the switching points. It could even handle messages with multiple destination addresses.
Before that, there were teletypewriter exchanges, but they involved dialing up a connection directly between sender and receiver. They were basically telephone switches repurposed for teletypes. That's what TWX and Telex were. Those were automatic dial back to the early 1930s.
The latest trend seems to be to abandon the desktop metaphor and make everything look like an iPhone. Big graphical buttons arranged in a grid, easy scrolling, no overlapping windows.
Superficial article about Mountain Pass. The big problem they have is finding a place to dump the tailings. A rare earth mine needs big settling ponds. The Mountain Pass solution is that they've built a pipeline to Ivanpah Dry Lake on the Nevada border.
The mine tailings are slightly radioactive, because the dirt in the area being mined has some uranium and thorium in it. This isn't a big deal once the water has evaporated and it's solid material again, but the water in the tailings ponds has to be kept from leaching into a water supply.