Full Width [alt+shift+f] Shortcuts [alt+shift+k]
Sign Up [alt+shift+s] Log In [alt+shift+l]

New here?

Welcome! BoredReading is a fresh way to read high quality articles (updated every hour). Our goal is to curate (with your help) Michelin star quality articles (stuff that's really worth reading). We currently have articles in 0 categories from architecture, history, design, technology, and more. Grab a cup of freshly brewed coffee and start reading. This is the best way to increase your attention span, grow as a person, and get a better understanding of the world (or atleast that's why we built it).

45
While building Pika’s Stream of posts layout, we had need to add the capability to manage excerpts in the Pika editor. These excerpts would be used to show a small portion of your post in a post stream while offering a “continue reading” link for readers to click to read the rest of your post. To add this capability we had to dig into extending the base open source library for our editor, Tiptap. First the Tiptap part Below is the full code of the extension. Primarily the extension detects if the user types {{ excerpt }}, {{ more }}, or WordPress’s <!--more--> and replaces that text with: <div data-type="excerpt" class="post-excerpt" contenteditable="false" draggable="true">↑ Excerpt ↑</div> With that HTML, we use CSS to style things like so: This extension is smart enough to know if an excerpt already exists in the editor, in that case disallowing another excerpt being created. The extension: import { Node, InputRule, nodeInputRule, mergeAttributes } from '@tiptap/core' /** * Look...
2 months ago

Improve your reading experience

Logged in users get linked directly to articles resulting in a better reading experience. Please login for free, it takes less than 1 minute.

More from Good Enough

There's no “A” or “I” in “Jelly”

The second half of 2024 was definitely an inflection point in the world of software. Large Language Models (LLMs) and generative AI started to permeate products everywhere, from chatbots to operating systems, and at times it felt like everyone was taking part in a race to integrate some AI feature or other into their product. This seems to have been particularly true in the world of customer support. Whole businesses seem to have pivoted, turning AI into their central feature as if their very lives depended on it. Some taglines from well-known companies leave no doubt: The best AI Agent and AI-first Customer Service Platform Try our new AI integration! AI-first service. ... and I can see the appeal for some businesses. But personally, I hate talking to bot or AI customer service tools. Is there anything more frustrating than carefully explaining your issue, then inexplicably being railroaded through some set of pointless questions or regurgitated knowledge-base articles, desperately hoping that if you can only jump through all these hoops like a good little boy, you might be able to eventually get in touch with an actual person who can actually read and understand your question and actually help you at the end of the tortuous process? It makes my blood boil! And as these big players double down on AI, it feels clearer than ever that they are really only focussed on customers who are so big that they don’t need to care how frustrating their support processes are. Companies for whom support is a cost centre they are trying to minimise. Jelly takes a different position. Jelly is about connecting actual people having actual conversations — support requests, questions, and all other kinds of collaboration. We're a small company, too. We know that the communication between us and our customers, existing or potential, will be one of the biggest factors in our success. There's no way we want an AI agent representing us in those vital conversations. Our bet is that there are thousands of other small companies and groups who neither need nor want an AI agent sitting between them and the people they want to communicate with. If you've been looking for a way for your team to share an inbox and work together to talk to your users, customers, clients, collaborators, and anyone else -- try Jelly. It's the simplest, most elegant, most humane way to work on email as a team.

2 months ago 38 votes
You Complete Me

When Good Enough was in its infancy as a truly American LLC (formed in Delaware and representing one or two people who were only semi-serious about a business), it was fun to play around with building websites. Shawn and I were truly just playing and exploring, more than anything reminding ourselves that building software could be a satisfying activity. After a year of goofing around we were still enjoying it, but we were also running up against our limitations. Some things we were okay at, but many of our skills just weren’t that impressive. So began the journey to Good Enough’s next phase: a collective of Good Enough people. We could make some cool, if janky, web toys alone, but with a few more people to play with… Along came Lettini and Patrick and James and Cade. Each of us with a different set of skills and a different set of weaknesses. Things definitely did become a lot more interesting once we teamed up! When my weaknesses got in the way, there was someone else to step into that gap and show me how it’s done. Hopefully others agree that I’m able to help them in some of the areas where I have a little more experience. 🤞 That’s enough reading for you; now it’s time to listen. Lettini, James, and I were recently asked to have a conversation on the IndieRails podcast. We are very thankful to Jeremy and Jess for this opportunity to talk about some of Good Enough’s short history. And luckily for you, we hardly talk about Rails at all! Throughout our lovely discussion, the power of a team filled with complimentary skills kept resurfacing in my head. This experience cannot be recreated as a solo dev or by working on some project in my garage. The times where our skills don’t overlap makes this whole Good Enough experiment lovely and worthwhile. To my teammates, I thank you. You complete me!

4 months ago 29 votes
Jelly was #1 on Hacker News

Yesterday, Lettini took a chance and posted about Jelly on Hacker News, a discussion site notorious for it's mercurial population of tech-maybe-too-saavy experts. Jelly is a tough sell for some of them, those with the technical skill to pipe email at a low level through custom-built filters running on their own cloud servers. I'm not going to lie to you. I was pretty nervous. And yet... Jelly at the top of Hacker News last night. At the time of writing, we've had over 100 comments and 281 "points" We got a really lovely response! It was also a great opportunity for us to practice talking about Jelly, about why we built it, what it stands for, and why people should consider it over other tools or workflows. It gave us an opportunity to talk about our philosophy on pricing: For us, affordability is part of the product itself. We’re specifically building this not to hoover up every dollar on the table, but to serve smaller groups that have been left out in the cold by "bigger" tools, and who get screwed by per-seat pricing. We believe there are enough teams who fit this profile to be profitable. There’s a difference between making profit and maximizing profit. the capitalists will call us crazy, but we're not here to maximize profit. This really resonated: I love this. Seriously. This is such a refreshing perspective! I've always wondered if there's room for craftsmen to build quality products for smaller groups. Your focus on simple, well-designed software really resonates with me. Thanks for showing us a viable path. A lot of people really got the product and the design choices we've been making: I'm really liking the UX there! In sports-speak there's the "Whose got the ball" method to identify who is managing a topic...and the way this is executed - from what i saw in the video - seems really straight-forward to help answer that. I really like the way this landing page is designed. And I think it really highlights one of the sales points, which is that you are decent and reasonable. Good stuff. I'm going to send this around to some people. Of course, there were plenty of people offering their home-brewed alternatives that cover some of what Jelly does, setting up filters and forwarding and even using labels to "claim" messages. It's fascinating to see how other people have approached this, and the existence of so many different "solutions" demonstrates, to me, that this is a problem that really exists in the world, and that really needs a Good Enough solution that works for people whether they are tech-saavy or not. Anyway. Go try Jelly. It's approved by the smart folks at Hacker News. What are you waiting for?

4 months ago 27 votes
TIL: Fixing Broken Social Share Images in Twitter/X

I have an admission to make. Social share images for Pika were broken on Twitter/X, LinkedIn, and Apple Messages for months. And it made me sad. But in the past few months we got it fixed. And that made me very happy! We really love our Pika social share images. They are pretty. They are readable. They reflect the theme chosen by the blogger. They're great! When they work. One day we went to share one of our blog posts and noticed that Twitter/X wasn’t playing nicely with Pika. At the time that service had been repeatedly mucking with how it displayed links. Seemingly every week there was a new change. So we sat on it for a bit, but eventually we decided it was probably us, not them. Especially since a couple other services were also having issues. We tried many and various things to fix it. I’ll share those below so we can get to the point… The fix in our case was to make sure our server was returning the correct headers: Content-Type: text/html; charset=utf-8 We arrived at this fix when a customer pointed out that our Content-Type differed from other working services. Using the service HTTP Header Check, they shared output from our server that showed: Content-Type: */*; charset=utf-8 Most services were fine figuring this out. Twitter/X, LinkedIn, and Apple Messages were not fine figuring this out. Naturally I introduced this bug when fixing another bug. 🤦 What other things did we try? Our twenty-nine-comment thread on Basecamp proves we tried just about everything. We compared line-by-line our META tags between Pika and various other blogs (including this one right here) We tweaked those META tags about fifteen different ways for each little discrepancy that we detected We read all the documents We tried the card validator We tried LinkedIn's post inspector We tried LinkedIn's support (they sent us to their developer forums who in turn said “not our problem” and sent us to an abandoned area of Stack Overflow 🙄) We tweaked our robots.txt We played with charset=uft-8 vs charset=us-ascii

4 months ago 28 votes

More in technology

Intel: Winning and Losing

Idling at a Zenith

6 hours ago 2 votes
MacLynx beta 6: back to the Power Mac

prior articles for more of the history, but MacLynx is a throwback port of the venerable Lynx 2.7.1 to the classic Mac OS last updated in 1997 which I picked up again in 2020. Rather than try to replicate its patches against a more current Lynx which may not even build, I've been improving its interface and Mac integration along with the browser core, incorporating later code and patching the old stuff. However, beta 6 is not a fat binary — the two builds are intentionally separate. One reason is so I can use a later CodeWarrior for better code that didn't have to support 68K, but the main one is to consider different code on Power Macs which may be expensive or infeasible on 68K Macs. The primary use case for this — which may occur as soon as the next beta — is adding a built-in vendored copy of Crypto Ancienne for onboard TLS without a proxy. On all but upper-tier 68040s, setting up the TLS connection takes longer than many servers will wait, but even the lowliest Performa 6100 with a barrel-bottom 60MHz 601 can do so reasonably quickly. The port did not go altogether smoothly. While Olivier Gutknecht's original fat binary worked fine on Power Macs, it took quite a while to get all the pieces reassembled on a later CodeWarrior with a later version of GUSI, the Mac POSIX glue layer which is a critical component (the Power Mac version uses 2.2.3, the 68K version uses 1.8.0). Some functions had changed and others were missing and had to be rewritten with later alternatives. One particularly obnoxious glitch was due to a conflict between the later GUSI's time.h and Apple Universal Interfaces' Time.h (remember, HFS+ is case-insensitive) which could not be solved by changing the search order in the project due to other conflicting headers. The simplest solution was to copy Time.h into the project and name it something else! Even after that, though, basic Mac GUI operations like popping open the URL dialogue would cause it to crash. Can you figure out why? Here's a hint: application: your application itself was almost certainly fully native. However, a certain amount of the Toolbox and the Mac OS retained 68K code, even in the days of Classic under Mac OS X, and your PowerPC application would invariably hit one of these routines eventually. The component responsible for switching between ISAs is the Mixed Mode Manager, which is tightly integrated with the 68K emulator and bridges the two architectures' different calling conventions, marshalling their parameters (PowerPC in registers, 68K on the stack) and managing return addresses. I'm serious when I say the normal state is to run 68K code: 68K code is necessarily the first-class citizen in Mac OS, even in PowerPC-only versions, because to run 68K apps seamlessly they must be able to call any 68K routine directly. All the traps that 68K apps use must also look like 68K code to them — and PowerPC apps often use those traps, too, because they're fundamental to the operating system. 68K apps can and do call code fragments in either ISA using the Code Fragment Manager (and PowerPC apps are obliged to), but the system must still be able to run non-CFM apps that are unaware of its existence. To jump to native execution thus requires an additional step. Say a 68K app running in emulation calls a function in the Toolbox which used to be 68K, but is now PowerPC. On a 68K MacOS, this is just 68K code. In later versions, this is replaced by a routine descriptor with a special trap meaningful only to the 68K emulator. This descriptor contains the destination calling convention and a pointer to the PowerPC function's transition vector, which has both the starting address of the code fragment and the initial value for the TOC environment register. The MMM converts the parameters to a PowerOpen ABI call according to the specified convention and moves the return address into the PowerPC link register, and upon conclusion converts the result back and unwinds the stack. The same basic idea works for 68K code calling a PowerPC routine. Unfortunately, we forgot to make a descriptor for this and other routines the Toolbox modal dialogue routine expected to call, so the nanokernel remains in 68K mode trying to execute them and makes a big mess. (It's really hard to debug it when this happens, too; the backtrace is usually totally thrashed.) the last time that my idea with MacLynx is to surround the text core with the Mac interface. Lynx keys should still work and it should still act like Lynx, but once you move to a GUI task you should stay in the GUI until that task is completed. In beta 5, I added support for the Standard File package so you get a requester instead of entering a filename, but once you do this you still need to manually select "Save to disk" inside Lynx. That changes in beta 6: :: which in MacOS is treated as the parent folder. Resizing, scrolling and repainting are also improved. The position of the thumb in MacLynx's scrollbar is now implemented using a more complex but yet more dynamic algorithm which should also more properly respond to resize events. A similar change fixes scroll wheels with USB Overdrive. When MacLynx's default window opens, a scrollbar control is artificially added to it. USB Overdrive implements its scrollwheel support by finding the current window's scrollbar, if any, and emulating clicks on its up and down (or left and right) buttons as the wheel is moved. This works fine in MacLynx, at least initially. When the window is resized, however, USB Overdrive seems to lose track of the scrollbar, which causes its scrollwheel functionality to stop working. The solution was to destroy and rebuild the scrollbar after the window takes its new dimensions, like what happens on start up when the window first opens. This little song and dance may also fix other scrollwheel extensions. Always keep in mind that the scrollbar is actually used as a means to send commands to Lynx to change its window on the document; it isn't scrolling, say, a pre-rendered GWorld. This causes the screen to be redrawn quite frequently, and big window sizes tend to chug. You can also outright crash the browser with large window widths: this is difficult to do on a 68K Mac with on-board video where the maximum screen size isn't that large, but on my 1920x1080 G4 I can do so reliably. lynx.cfg a no-op. However, if you are intentionally using another character set and this will break you, please feel free to plead your use case to me and I will consider it. Another bug fixed was an infinite loop that could trigger during UTF-8 conversion of certain text strings. These sorts of bugs are also a big pain to puzzle out because all you can do from CodeWarrior is force a trap with an NMI, leaving the debugger's view of the program counter likely near but probably not at the scene of the foul. Eventually I single-stepped from a point near the actual bug and was able to see what was happening, and it turned out to be a very stupid bug on my part, and that's all I'm going to say about that. SameSite and HttpOnly (irrelevant on Lynx but supported for completeness) attributes are, the next problem was that any cookie with an expiration value — which nowadays is nearly any login cookie — wouldn't stick. The problem turned out to be the difference in how the classic MacOS handles time values. In 32-bit Un*xy things, including Mac OS X, time_t is a signed 32-bit integer with an epoch starting on Thursday, January 1, 1970. In the classic MacOS, time_t is an unsigned 32-bit integer with an epoch starting on Friday, January 1, 1904. (This is also true for timestamps in HFS+ filesystems, even in Mac OS X and modern macOS, but not APFS.) Lynx has a utility function that can convert a ASCII date string into a seconds-past-the-epoch count, but in case you haven't guessed, this function defaults to the Unix epoch. In fact, the version previously in MacLynx only supports the Unix epoch. That means when converted into seconds after the epoch, the cookie expiration value would always appear to be in the past compared to the MacOS time value which, being based on a much earlier epoch, will always be much larger — and thus MacLynx would conclude the cookie was actually expired and politely clear it. I reimplemented this function based on the MacOS epoch, and now login cookies actually let you log in! Unfortunately other cookies like trackers can be set too, and this is why we can't have nice things. Sorry. At least they don't persist between runs of the browser. Even then, though, there's still some additional time fudging because time(NULL) on my Quadra 800 running 8.1 and time(NULL) on my G4 MDD running 9.2.2, despite their clocks being synchronized to the same NTP source down to the second, yielded substantially different values. Both of these calls should go to the operating system and use the standard Mac epoch, and not through GUSI, so GUSI can't be why. For the time being I use a second fudge factor if we get an outlandish result before giving up. I'm still trying to figure out why this is necessary. ogle). This didn't work for PNG images before because it was using the wrong internal MIME type, which is now fixed. (Ignore the MIME types in the debug window because that's actually a problem I noticed with my Internet Config settings, not MacLynx. Fortunately Picture Viewer will content-sniff, so it figures it out.) Finally, there is also miscellaneous better status code and redirect handling (again not a problem with mainline Lynx, just our older fork here), which makes login and browsing sites more streamlined, and you can finally press Shift-Tab to cycle backwards through forms and links. If you want to build MacLynx from source, building beta 6 is largely the same on 68K with the same compiler and prerequisites except that builds are now segregated to their own folders and you will need to put a copy of lynx.cfg in with them (the StuffIt source archive does not have aliases predone for you). For the PowerPC version, you'll need the same set up but substituting CodeWarrior Pro 7.1, and, like CWGUSI, GUSI 2.2.3 should be in the same folder or volume that contains the MacLynx source tree. There are debug and optimized builds for each architecture. Pre-built binaries and source are available from the main MacLynx page. MacLynx, like Lynx, is released under the GNU General Public License v2.

22 hours ago 2 votes
Humanities Crash Course Week 14: Roman Decadence

During week 14 of the humanities crash course, I explored foundational myths of Western Culture — written during the Roman Empire when decadence was setting in. I paired them with a classic film about social decadence set in mid-20th century Rome. Readings Gioa’s recommendations were a bit more open-ended this week: books 1 and 2 of the Aeneid, book 1 of Ovid’s Metamorphoses, and “selected Roman poems and aphorisms.” Rather than read a whole book, I sought out some of these latter shorter works online. I also read the most famous section of the Satyricon. The Aeneid is one of the classic epic poems of antiquity. Written by Virgil between 29 and 19 BCE, it aimed to formalize founding myths for the Roman Empire. It’s a sort of sequel to the Iliad and explicitly echoes the Odyssey’s structure. Fortunately, I only had read the first two books: Book 1: As Aeneas sails toward Italy after the events of the Trojan war; the gods conjure a storm that scatters the fleet. Aeneas and his crew are shipwrecked on the coast of Libya. The goddess Venus guides them to nearby Carthage, where Queen Dido is building a new city. She asks Aeneas to tell his story. Book 2: Aeneas recounts the fall of Troy, focusing on the Trojan horse episode. Despite warnings, the Trojans bring the gift horse into the city, only to be overwhelmed by the Greek soldiers hiding inside. King Priam is killed in the ensuing fight; Aeneas is about to kill himself in despair but the ghost of Hector urges him to flee instead. I said “fortunately” because these poems were the least pleasant reading I’ve done so far in the course. Perhaps it’s due to the translation I used, but it might also be because this work was created to glorify the Roman emperor. Like most ideological art, I found it pompous and tedious. In many ways, Metamorphoses was its opposite. Written later, (2-8 CE,) its focus is mythology drawn from the classic Greek pantheon, but parsed through Roman sensibilities. The theme is transformation: gods, demigods, and humans shapeshift, becoming plants, animals, constellations, etc. to change the trajectory of events or escape suffering Like the Aeneid, Metamorphoses also explores the foundations of Roman imperial rule, but it comes to the subject from a more ironic and irreverent POV. By focusing on change, the poem has interesting parallels with Buddhist teachings and the I Ching. Given its tone, cadence, and subject matter, I enjoyed it more than the Aeneid. The third major work this week was Petronius’s Satyricon, arguably the first Western novel. It was written during the reign of emperor Nero (mid 1st-century CE,) and only fragments survive. They present the misadventures of Encolpius and his companions Giton (a former slave and teenage lover) and Ascyltus, a friend, antagonist, and former lover. The novel portrays a morally chaotic and decadent society reveling in excess, deception, and sensuous pleasures. I read the most famous section, Trimalchio’s feast, which provides vivid descriptions of Roman excesses during this time. Characters come across as tone-deaf — especially the nouveau riche, whose vulgarity and self-importance must have seemed outrageous even to people with moral standards very different from ours. I was surprised at how richly these characters were portrayed — and how little people have changed in two millennia. Audiovisual Music: Arias by Puccini and Verdi. This is the second time during the course I’ve listened to opera: a medium I love but don’t include much in my regular rotation. This was a good opportunity to revisit some of these magnificent works. Art: Gioia recommended looking at cave paintings. I punted. Several years ago, I saw Werner Herzog’s CAVE OF FORGOTTEN DREAMS, and had my fill for cave paintings. Cinema: I read the Satyricon this week because I saw Fellini’s adaptation in college. At the time, I also saw his LA DOLCE VITA. Even though LDV is the more famous of the two, my memory of it was fuzzier, so I chose to revisit it now. Marcello Mastroianni plays Marcello, a womanizing gossip journalist drifting through postwar Rome. He has serious aspirations as a novelist, but allows himself to be swept along by the seductive currents of Roman nightlife and celebrity culture. Like the Satyricon, we get story fragments rather than a unified plot. The fragments loosely echo the seven deadly sins and seven sacraments of the Catholic Church, framing the film as a kind of spiritual inventory of modern life. I was surprised this classic film was only available to stream through Plex. It was a poor experience, riddled with ads and useless subtitles. My Italian is rusty, but I got most of the film anyway. (I may start seeing other Italian and French movies without subtitles as practice.) Reflections The common thread this week was social decadence — especially the kind that takes hold when a society grows too wealthy and powerful for its own good. I read the Aeneid as a puff piece intended to instill a false sense of pride through a constructed continuity with the Greek civilization Romans admired — and supplanted. Metamorphoses took a more lighthearted approach, suggesting all things pass and that change is the only constant. Both the Satyricon and LA DOLCE VITA illuminated the vulgarity and moral emptiness at the core of decadence, turning it into ironic — and sometimes painful — entertainment. Can we see our own time with such detachment? Can we recognize the Virgils trying to enshrine the inexcusable? The Ovids who myth-make more lightly and playfully? Or the Petroniuses and Fellinis who nudge us to laugh — and maybe cry — at the foolishness and pain of living adrift in a sensuous world? Notes on Note-taking Given my difficulties with the Aeneid, I found its Wikipedia page insightful. The summary of books 1 and 2 gave me an outline to better understand the work. As with previous weeks, I also bounced reflections off ChatGPT and summarized using the Obsidian Text Generator plugin. Both helped me grok the readings and how they relate to each other. A realization on process: writing these posts helps me focus and power through even when readings get tedious. If I hadn’t committed to sharing publicly, I likely would’ve bailed on the Aeneid. I read with more focus and attention when knowing I’ll publish these little “book reports” at the end of the week. Up Next From Gioia’s description, I expect next week’s reading — Boethius’s On the Consolation of Philosophy — will be highly relevant to our current predicament. Again, there’s a YouTube playlist for the videos I’m sharing here. I’m also sharing these posts via Substack if you’d like to subscribe and comment. See you next week!

20 hours ago 1 votes
2025-04-06 Airfone

We've talked before about carphones, and certainly one of the only ways to make phones even more interesting is to put them in modes of transportation. Installing telephones in cars made a lot of sense when radiotelephones were big and required a lot of power; and they faded away as cellphones became small enough to have a carphone even outside of your car. There is one mode of transportation where the personal cellphone is pretty useless, though: air travel. Most readers are probably well aware that the use of cellular networks while aboard an airliner is prohibited by FCC regulations. There are a lot of urban legends and popular misconceptions about this rule, and fully explaining it would probably require its own article. The short version is that it has to do with the way cellular devices are certified and cellular networks are planned. The technical problems are not impossible to overcome, but honestly, there hasn't been a lot of pressure to make changes. One line of argument that used to make an appearance in cellphones-on-airplanes discourse is the idea that airlines or the telecom industry supported the cellphone ban because it created a captive market for in-flight telephone services. Wait, in-flight telephone services? That theory has never had much to back it up, but with the benefit of hindsight we can soundly rule it out: not only has the rule persisted well past the decline and disappearance of in-flight telephones, in-flight telephones were never commercially successful to begin with. Let's start with John Goeken. A 1984 Washington Post article tells us that "Goeken is what is called, predictably enough, an 'idea man.'" Being the "idea person" must not have had quite the same connotations back then, it was a good time for Goeken. In the 1960s, conversations with customers at his two-way radio shop near Chicago gave him an idea for a repeater network to allow truckers to reach their company offices via CB radio. This was the first falling domino in a series that lead to the founding of MCI and the end of AT&T's long-distance monopoly. Goeken seems to have been the type who grew bored with success, and he left MCI to take on a series of new ventures. These included an emergency medicine messaging service, electrically illuminated high-viz clothing, and a system called the Mercury Network that built much of the inertia behind the surprisingly advanced computerization of florists [1]. "Goeken's ideas have a way of turning into dollars, millions of them," the Washington Post continued. That was certainly true of MCI, but every ideas guy had their misses. One of the impressive things about Goeken was his ability to execute with speed and determination, though, so even his failures left their mark. This was especially true of one of his ideas that, in the abstract, seemed so solid: what if there were payphones on commercial flights? Goeken's experience with MCI and two-way radios proved valuable, and starting in the mid-1970s he developed prototype air-ground radiotelephones. In its first iteration, "Airfone" consisted of a base unit installed on an aircraft bulkhead that accepted a credit card and released a cordless phone. When the phone was returned to the base station, the credit card was returned to the customer. This equipment was simple enough, but it would require an extensive ground network to connect callers to the telephone system. The infrastructure part of the scheme fell into place when long-distance communications giant Western Union signed on with Goeken Communications to launch a 50/50 joint venture under the name Airfone, Inc. Airfone was not the first to attempt air-ground telephony---AT&T had pursued the same concept in the 1970s, but abandoned it after resistance from the FCC (unconvinced the need was great enough to justify frequency allocations) and the airline industry (which had formed a pact, blessed by the government, that prohibited the installation of telephones on aircraft until such time as a mature technology was available to all airlines). Goeken's hard-headed attitude, exemplified in the six-year legal battle he fought against AT&T to create MCI, must have helped to defeat this resistance. Goeken brought technical advances, as well. By 1980, there actually was an air-ground radiotelephone service in general use. The "General Aviation Air-Ground Radiotelephone Service" allocated 12 channels (of duplex pairs) for radiotelephony from general aviation aircraft to the ground, and a company called Wulfsberg had found great success selling equipment for this service under the FliteFone name. Wulfsberg FliteFones were common equipment on business aircraft, where they let executives shout "buy" and "sell" from the air. Goeken referred to this service as evidence of the concept's appeal, but it was inherently limited by the 12 allocated channels. General Aviation Air-Ground Radiotelephone Service, which I will call AGRAS (this is confusing in a way I will discuss shortly), operated at about 450MHz. This UHF band is decidedly line-of-sight, but airplanes are very high up and thus can see a very long ways. The reception radius of an AGRAS transmission, used by the FCC for planning purposes, was 220 miles. This required assigning specific channels to specific cities, and there the limits became quite severe. Albuquerque had exactly one AGRAS channel available. New York City got three. Miami, a busy aviation area but no doubt benefiting from its relative geographical isolation, scored a record-setting four AGRAS channels. That meant AGRAS could only handle four simultaneous calls within a large region... if you were lucky enough for that to be the Miami region; otherwise capacity was even more limited. Back in the 1970s, AT&T had figured that in-flight telephones would be very popular. In a somewhat hand-wavy economic analysis, they figured that about a million people flew in the air on a given day, and about a third of them would want to make telephone calls. That's over 300,000 calls a day, clearly more than the limited AGRAS channels could handle... leading to the FCC's objection that a great deal of spectrum would have to be allocated to make in-flight telephony work. Goeken had a better idea: single-sideband. SSB is a radio modulation technique that allows a radio transmission to fit within a very narrow bandwidth (basically by suppressing half of the signal envelope), at the cost of a somewhat more fiddly tuning process for reception. SSB was mostly used down in the HF bands, where the low frequencies meant that bandwidth was acutely limited. Up in the UHF world, bandwidth seemed so plentiful that there was little need for careful modulation techniques... until Goeken found himself asking the FCC for 10 blocks of 29 channels each, a lavish request that wouldn't really fit anywhere in the popular UHF spectrum. The use of UHF SSB, pioneered by Airfone, allowed far more efficient use of the allocation. In 1983, the FCC held hearings on Airfone's request for an experimental license to operate their SSB air-ground radiotelephone system in two allocations (separate air-ground and ground-air ranges) around 850MHz and 895MHz. The total spectrum allocated was about 1.5MHz in each of the two directions. The FCC assented and issued the experimental license in 1984, and Airfone was in business. Airfone initially planned 52 ground stations for the system, although I'm not sure how many were ultimately built---certainly 37 were in progress in 1984, at a cost of about $50 million. By 1987, the network had reportedly grown to 68. Airfone launched on six national airlines (a true sign of how much airline consolidation has happened in recent decades---there were six national airlines?), typically with four cordless payphones on a 727 or similar aircraft. The airlines received a commission on the calling rates, and Airfone installed the equipment at their own expense. Still, it was expected to be profitable... Airfone projected that 20-30% of passengers would have calls to make. I wish I could share more detail on these ground stations, in part because I assume there was at least some reuse of existing Western Union facilities (WU operated a microwave network at the time and had even dabbled in cellular service in the 1980s). I can't find much info, though. The antennas for the 800MHz band would have been quite small, but the 1980s multiplexing and control equipment probably took a fare share of floorspace. Airfone was off to a strong start, at least in terms of installation base and press coverage. I can't say now how many users it actually had, but things looked good enough that in 1986 Western Union sold their share of the company to GTE. Within a couple of years, Goeken sold his share to GTE as well, reportedly as a result of disagreements with GTE's business strategy. Airfone's SSB innovation was actually quite significant. At the same time, in the 1980s, a competitor called Skytel was trying to get a similar idea off the ground with the existing AGRAS allocation. It doesn't seem to have gone anywhere, I don't think the FCC ever approved it. Despite an obvious concept, Airfone pretty much launched as a monopoly, operating under an experimental license that named them alone. Unsurprisingly there was some upset over this apparent show of favoritism by the FCC, including from AT&T, which vigorously opposed the experimental license. As it happened, the situation would be resolved by going the other way: in 1990, the FCC established the "commercial aviation air-ground service" which normalized the 800 MHz spectrum and made licenses available to other operators. That was six years after Airfone started their build-out, though, giving them a head start that severely limited competition. Still, AT&T was back. AT&T introduced a competing service called AirOne. AirOne was never as widely installed as Airfone but did score some customers including Southwest Airlines, which only briefly installed AirOne handsets on their fleet. "Only briefly" describes most aspects of AirOne, but we'll get to that in a moment. The suddenly competitive market probably gave GTE Airfone reason to innovate, and besides, a lot had changed in communications technology since Airfone was designed. One of Airfone's biggest limitations was its lack of true roaming: an Airfone call could only last as long as the aircraft was within range of the same ground station. Airfone called this "30 minutes," but you can imagine that people sometimes started their call near the end of this window, and the problem was reportedly much worse. Dropped calls were common, adding insult to the injury that Airfone was decidedly expensive. GTE moved towards digital technology and automation. 1991 saw the launch of Airfone GenStar, which used QAM digital modulation to achieve better call quality and tighter utilization within the existing bandwidth. Further, a new computerized network allowed calls to be handed off from one ground station to another. Capitalizing on the new capacity and reliability, the aircraft equipment was upgraded as well. The payphone like cordless stations were gone, replaced by handsets installed in seatbacks. First class cabins often got a dedicated handset for every seat, economy might have one handset on each side of a row. The new handsets offered RJ11 jacks, allowing the use of laptop modems while in-flight. Truly, it was the future. During the 1990s, satellites were added to the Airfone network as well, improving coverage generally and making telephone calls possible on overseas flights. Of course, the rise of satellite communications also sowed the seeds of Airfone's demise. A company called Aircell, which started out using the cellular network to connect calls to aircraft, rebranded to Gogo and pivoted to satellite-based telephone services. By the late '90s, they were taking market share from Airfone, a trend that would only continue. Besides, for all of its fanfare, Airfone was not exactly a smash hit. Rates were very high, $5 a minute in the late '90s, giving Airfone a reputation as a ripoff that must have cut a great deal into that "20-30% of fliers" they hoped to serve. With the rise of cellphones, many preferred to wait until the aircraft was on the ground to use their own cellphone at a much lower rate. GTE does not seem to have released much in the way of numbers for Airfone, but it probably wasn't making them rich. Goeken, returning to the industry, inadvertently proved this point. He aggressively lobbied the FCC to issue competitive licenses, and ultimately succeeded. His second company in the space, In-Flight Phone Inc., became one of the new competitors to his old company. In-Flight Phone did not last for long. Neither did AT&T AirOne. A 2005 FCC ruling paints a grim picture: Current 800 MHz Air-Ground Radiotelephone Service rules contemplate six competing licensees providing voice and low-speed data services. Six entities were originally licensed under these rules, which required all systems to conform to detailed technical specifications to enable shared use of the air-ground channels. Only three of the six licensees built systems and provided service, and two of those failed for business reasons. In 2002, AT&T pulled out, and Airfone was the only in-flight phone left. By then, GTE had become Verizon, and GTE Airfone was Verizon Airfone. Far from a third of passengers, the CEO of Airfone admitted in an interview that a typical flight only saw 2-3 phone calls. Considering the minimum five-figure capital investment in each aircraft, it's hard to imagine that Airfone was profitable---even at $5 minute. Airfone more or less faded into obscurity, but not without a detour into the press via the events of 9/11. Flight 93, which crashed in Pennsylvania, was equipped with Airfone and passengers made numerous calls. Many of the events on board this aircraft were reconstructed with the assistance of Airfone records, and Claircom (the name of the operator of AT&T AirOne, which never seems to have been well marketed) also produced records related to other aircraft involved in the attacks. Most notably, flight 93 passenger Todd Beamer had a series of lengthy calls with Airfone operator Lisa Jefferson, through which he relayed many of the events taking place on the plane in real time. During these calls, Beamer seems to have coordinated the effort by passengers to retake control of the plane. The significance of Airfone and Claircom records to 9/11 investigations is such that 9/11 conspiracy theories may be one of the most enduring legacies of Claircom especially. In an odd acknowledgment of their aggressive pricing, Airfone decided not to bill for any calls made on 9/11, and temporarily introduced steep discounts (to $0.99 a minute) in the weeks after. This rather meager show of generosity did little to reverse the company's fortunes, though, and it was already well into a backslide. In 2006, the FCC auctioned the majority of Airfone's spectrum to new users. The poor utilization of Airfone was a factor in the decision, as well as Airfone's relative lack of innovation compared to newer cellular and satellite systems. In fact, a large portion of the bandwidth was purchased by Gogo, who years later would use to to deliver in-flight WiFi. Another portion went to a subsidiary of JetBlue that provided in-flight television. Verizon announced the end of Airfone in 2006, pending an acquisition by JetBlue, and while the acquisition did complete JetBlue does not seem to have continued Airfone's passenger airline service. A few years later, Gogo bought out JetBlue's communications branch, making them the new monopoly in 800MHz air ground radiotelephony. Gogo only offered telephone service for general aviation aircraft; passenger aircraft telephones had gone the way of the carphone. It's interesting to contrast the fate of Airfone to to its sibling, AGRAS. Depending on who you ask, AGRAS refers to the radio service or to the Air Ground Radiotelephone Automated Service operated by Mid-America Computer Corporation. What an incredible set of names. This was a situation a bit like ARINC, the semi-private company that for some time held a monopoly on aviation radio services. MACC had a practical monopoly on general aviation telephone service throughout the US, by operating the billing system for calls. MACC still exists today as a vendor of telecom billing software and this always seems to have been their focus---while I'm not sure, I don't believe that MACC ever operated ground stations, instead distributing rate payments to private companies that operated a handful of ground stations each. Unfortunately the history of this service is quite obscure and I'm not sure how MACC came to operate the system, but I couldn't resist the urge to mention the Mid-America Computer Corporation. AGRAS probably didn't make anyone rich, but it seems to have been generally successful. Wulfsberg FliteFones operating on the AGRAS network gave way to Gogo's business aviation phone service, itself a direct descendent of Airfone technology. The former AGRAS allocation at 450MHz somehow came under the control of a company called AURA Network Systems, which for some years has used a temporary FCC waiver of AGRAS rules to operate data services. This year, the FCC began rulemaking to formally reallocate the 450MHz air ground allocation to data services for Advanced Air Mobility, a catch-all term for UAS and air taxi services that everyone expects to radically change the airspace system in coming years. New uses of the band will include command and control for long-range UAS, clearance and collision avoidance for air taxis, and ground and air-based "see and avoid" communications for UAS. This pattern, of issuing a temporary authority to one company and later performing rulemaking to allow other companies to enter, is not unusual for the FCC but does make an interesting recurring theme in aviation radio. It's typical for no real competition to occur, the incumbent provider having been given such a big advantage. When reading about these legacy services, it's always interesting to look at the licenses. ULS has only nine licenses on record for the original 800 MHz air ground service, all expired and originally issued to Airfone (under both GTE and Verizon names), Claircom (operating company for AT&T AirOne), and Skyway Aircraft---this one an oddity, a Florida-based company that seems to have planned to introduce in-flight WiFi but not gotten all the way there. Later rulemaking to open up the 800MHz allocation to more users created a technically separate radio service with two active licenses, both held by AC BidCo. This is an intriguing mystery until you discover that AC BidCo is obviously a front company for Gogo, something they make no effort to hide---the legalities of FCC bidding processes are such that it's very common to use shell companies to hold FCC licenses, and we could speculate that AC BidCo is the Aircraft Communications Bidding Company, created by Gogo for the purpose of the 2006-2008 auctions. These two licenses are active for the former Airfone band, and Gogo reportedly continues to use some of the original Airfone ground stations. Gogo's air-ground network, which operates at 800MHz as well as in a 3GHz band allocated specifically to Gogo, was originally based on CDMA cellular technology. The ground stations were essentially cellular stations pointed upwards. It's not clear to me if this CDMA-derived system is still in use, but Gogo relies much more heavily on their Ku-band satellite network today. The 450MHz licenses are fascinating. AURA is the only company to hold current licenses, but the 246 reveal the scale of the AGRAS business. Airground of Idaho, Inc., until 1999 held a license for an AGRAS ground station on Brundage Mountain McCall, Idaho. The Arlington Telephone Company, until a 2004 cancellation, held a license for an AGRAS ground station atop their small telephone exchange in Arlington, Nebraska. AGRAS ground stations seem to have been a cottage industry, with multiple licenses to small rural telephone companies and even sole proprietorships. Some of the ground stations appear to have been the roofs of strip mall two-way radio installers. In another life, maybe I would be putting a 450MHz antenna on my roof to make a few dollars. Still, there were incumbents: numerous licenses belonged to SkyTel, which after the decline of AGRAS seems to have refocused on paging and, then, gone the same direction as most paging companies: an eternal twilight as American Messaging ("The Dependable Choice"), promoting innovation in the form of longer-range restaurant coaster pagers. In another life, I'd probably be doing that too. [1] This is probably a topic for a future article, but the Mercury Network was a computerized system that Goeken built for a company called Florist's Telegraph Delivery (FTD). It was an evolution of FTD's telegraph system that allowed a florist in one city to place an order to be delivered by by a florist in another city, thus enabling the long-distance gifting of flowers. There were multiple such networks and they had an enduring influence on the florist industry and broader business telecommunications.

yesterday 2 votes
Why do lemon batteries work?

And chemistry, I guess

2 days ago 2 votes