Yes, commercial pilots are taught to "fly their instruments". General aviation pilots may enjoy more "seat-of-the-pants" flying, but even they are taught to trust instruments over human perceptions, which are easily fooled, as even simple demos will show.
I used to work for an aircraft instrument maker, and our user interfaces, everything the pilot interacts with, got more care and attention than the rest of the instrument. Of course we had to display nothing but totally accurate data, and do so promptly, but we also had to do so in ways that were obvious and clear, so the pilot can take in the most important information with a quick glance.
The pilot's standard "scan" is perhaps the most-trained skill. To look at everything on the instrument panels and outside the windows often enough to not miss anything, yet slow enough to take in all vital information.
When things get hectic, the pilot still does this scan, interrupting it as needed to deal with situations, but still doing it. Because, as the saying goes, "trouble often comes in threes": Stopping everything to handle an initial situation may mask what's really going on, and lead to a cascade of failures.
With ever more data being aimed at the pilot, there is a distinct risk of information overload, especially when tired, or during tense but otherwise normal situations, such as take-off, landing, or flying through turbulence. This overload often encourages the pilot to rely more on signals from the body, which need less conscious processing, rather than focus on all that data.
Here, again, is where commercial pilots receive extra training, but perhaps not often enough. This is one of the factors that keep commercial pilot mandatory retirement ages so low: The risk of overload increases with age, even when all other factors match those of a younger person.
Plus, staying in peak training for decades is fatiguing, and relatively few can do so "naturally". Which is one of the reasons we're running out of commercial aircraft pilots.
It may seem counter-intuitive, but this overload risk is often handled by adding more automation, more automatic systems to "help" the pilot. So much so that actually manually "driving" a commercial aircraft, with hands on the controls, is an increasingly rare part of a normal flight.
Our instruments also tried to take pilot fatigue into account, saving our brightest and loudest alarms only for the most desperate situations, to punch-through that overload to help ensure prompt and correct reactions.
One product I worked on was a TAWS (Terrain Awareness and Warning System) instrument, which basically stayed quiet unless there was a risk of the pilot flying into the ground, to help prevent "CFIT" accidents (Controlled Flight Into the Ground). It has special modes for take-off and landing, though our instrument was designed to actually *avoid* making the pilot depend on it's display: Useful for information as part of the scan, but not to be used to navigate the aircraft. Our main function was to provide visual and audible alerts only when needed.
I believe 100% of US commercial aircraft (and perhaps now even biz-jets) are required to have TAWS on-board and active. Any TAWS-equipped plane approaching the ground outside of an approved approach path for a know airport will give the pilot "Terrain ahead. Pull up! Pull up!" alerts until the hazard no longer exists.
Unfortunately, if a stall is also immanent, the pilot will simultaneously receive an alert to push the nose down. And increase power. And other things as well. An overload of alerts, which a skilled and calm pilot will respond to with the most correct action. But which can overload a stressed or tired pilot, or one with the beginnings of a cold or flu.
The thing is, every alert can be silenced, to reduce the confusion and distractions. But an overloaded pilot can forget even this simple aid to keeping full awareness and control.
This is a big part of why pilots are so often blamed for crashes:
Much of recent AI progress has come from the awesome amount of cheap computing power available.
That's not going to change! As today's bleeding edge silicon processes evolve, they will get faster and cheaper (both in cost and energy consumption), if not smaller.
Much of AI is inherently parallel: So long as more CPUs and GPUs can be added, larger problems will be solved faster.
We are still in the first two generations of custom hardware for AI. That trend will continue and accelerate as new architectures and algorithms arrive.
I'd say there are at least three full "Moore's Law" generations coming for AI, very likely more. But transistors alone won't be driving it. Fortunately, there are lots of other factors that will.
Fundamentally, a 2-D FFT describes the dynamics present in any image. Sure, you could compare them between a known source displayed via different streaming methods on different screens. However, these numbers are meaningless on their own without taking the context of the viewer into account.
The FFT must include physical dimensions, starting with the screen's PPI value. So a 4K phone screen is inherently "sharper" than a 4K projector on a 20 meter movie screen. But we all know the movie screen offers a far better experience than a phone, more "immersive", independent of the perceived or actual sharpness.
The viewer's perceptions are also key. Starting with their ability to perceive. For the human eye to resolve a 4K image at the pixel level, that is to detect sharpness changes at that level, a person with 20-20 vision would need to sit NO FURTHER than a SINGLE screen diagonals away from the center of the screen. That's 65 inches away from a 65" inch monitor. If you aren't sitting that close, you aren't "seeing in 4K". So you have already started to lose "sharpness" independent of what you're watching.
And if you are sitting that close, you'll want a curved monitor, since the distance from the center pixel to your eye is much closer than the distances to the corner pixels. And you'll be watching alone, since there generally isn't space for two at that ideal viewing spot. So most of us get flat monitors and sit further away. Most of us sit so far from our screens that we aren't even "seeing in 1080p"! You'll notice that most TVs smaller than 32" are only 720p, which is because you really can't see more than that if your sitting at a normal TV viewing distance.
I *DO* sit that close. As I write this I'm sitting 55" away from my curved 65" TV/monitor. For most streaming content I lean back a bit simply because it makes no difference: The media sharpness is generally sloppier than what my eyes can perceive, so sitting back doesn't reduce the quality. That does change for well-rendered 4K content, where the original material is extremely sharp (directors and editors intentionally add blur to remove distracting levels of sharpness). That's when I lean in until my eyes can take in every detail.
If you aren't close enough, the content sharpness simply doesn't matter.
I was in Engineering: I never got to go to the shows and conventions, so I didn't pay much attention to which ones the company attended. However, I did get involved when prospective customers came to visit: I often was one of the ponies in the dog and pony show!
It really doesn't take much effort to make a "good enough" concealment. Basically, the higher off the ground, the easier. Make them look like they're part of the utility infrastructure, and you're home free. The hard part is weatherproofing and hot days in the sun with no wind. For being rain-proof you want no holes, yet to cool down you do, since heat sinks are hard to hide.
We primarily made concealments containing steerable high-zoom video cameras, the same ones used in high-end security systems, mounted to extremely accurate miniature PTZ bases. The cameras had internal image stabilization, but we also added external stabilization. Then we added automatic subject tracking, so no remote operator on a joystick was needed.
They were bought by TLAs (Three Letter Agencies), and generally needed a warrant to be mounted and activated.
When the wars in Afghanistan and Iraq started, we were asked to modify our technology to provide 360-degree surveillance for forward fire bases, who never had enough soldiers to use as sentries 24/7. Our systems turned out so good that we next had to integrate them with C4I systems, just as was done with the video from Predator drones. We initially built the systems into concealments, but soon found that beige paint was good enough, and we simply used sturdy tripods.
When Somali pirates became a problem, we modified our systems so they could be mounted to ships to again provide 360 degree surveillance.
We were riding high, a small company (well under 100 employees) who was by far the largest provider in a specialty market. Then the Budget Sequestration of 2011 hit, and all of our government customers not only became unable to buy our new products, they couldn't even fund support contracts or repairs. The guillotine fell, but fortunately we had already started a pivot toward vertical integration, to provide the communication systems needed to relay the surveillance video.
We entered that market in the right way at the right time, and soon had a long list of prospective customers. But our reduced income caused us to burn through our cash stockpile, and then the banks to stop lending to us: The company folded just as our new products were ready to go into production. That really hurt.
Looking back, my favorite product was the firebase surveillance system. We were told it had helped prevent countless sneak attacks.
Yeah, the ~0.5 degree angular width of the sun is certainly an issue, as is the small target size. Fortunately it's one that can be mitigated by adding complexity and reducing efficiency, such as by using 3 reflective surfaces and/or collimation. The use of a long gravity tether in GEO would permit multiple annular reflectors to be kept in tight alignment. Modeling the positioning stability of such a system is difficult, but it's bounded, so the system should be controllable.
Even with a full Goldberg (ridiculously complex) implementation, there would be significant spill-over, a new star in the sky.
Let's assume, for the moment, that it is a "good idea". How should it be implemented?
If there is to be only one satellite, then there are only two orbits that can work: GEO and a polar Molniya that has the satellite overhead between dusk and dawn. With more satellites more orbits can work, but let's assume one for now.
Let's figure out how big a mirror is needed. First, it will need to have at least some degree of focus to keep the spot size bounded. That is, a flat plane won't do. Let's compute the total light needed over a 10 km x 80 km ellipse, an area of about 2500 km^2. Given that 1 lux = 1 lumen / m^2, the lumens we need will be lux * area. Let's assume a partial moon (0.1 lux) is the minimum needed. Multiply those numbers, and that's 250,000,000 lumens. Let's say naked sunlight (allowing for atmospheric losses) is roughly 100,000 lux. Area = lumens/lux, yielding a mirror area of 2500 m^2.
And that's for a *perfect* mirror: No losses, with perfect focus. Assuming a circular mirror, that's a minimum diameter of about 60 m. That million-to-one illumination ratio really rocks. So, at a first glance, the optics alone says it's doable, at least near the minimums I've used. VERY doable!
A mirror in a Molniya orbit will have to deal with a rapidly/continuously varying sun angle every night, but there may be rotational tricks to deal with that, *if* we can manage to rapidly change the mirror shape. But it would rapidly complicate things, so let's set the Molniya orbit aside.
A mirror in GEO need only cope with seasonal variations. While we're at it, let's increase the mirror area by a factor of 10, so we'll be sure to have abundant margin to play with; let's say a nice, round 200 m diameter.
We already have communication satellites at GEO that stay aimed with precision for 15 years or more. Of course, they're aiming tiny antennas that are a millionth the size of our mirror, so we still must consider the aiming problem.
Satellites use aiming actuators for the antennas, and thrusters and gyros (torquers) for the satellite body, which combined yield good pointing precision. Our reflector won't have that luxury: The antenna will dwarf any satellite body, and will also have minimal rigidity: It really can't be aimed much at all, and even then not quickly.
To get some rigidity we can spin the mirror, which should also help with its shape, though that may not be needed. The total range of motion needed to track the sun matches the 23.5 degree tilt axis over a year, which is roughly 0.1 degree per day. (Well, OK, the total wobble is 23.5 degrees in each direction, but we only need to split the difference to bounce the sun toward the ground, which is 11.75 degrees, doubled, which gets us back to 23.5 degrees).
Next is the issue of aiming/pointing. Using gas or chemical thrusters alone may be a non-starter, including ion thrusters. But with a spinning disk, we really should be able to use precession. But precess against what?
Given the slow rate of angular motion, I suspect a 100-300 km long gravity tether should be able to provide enough restoring force to make the job manageable. The satellite body will then need only to slightly pivot the mirror relative to the tether, an extremely low-energy operation.
The satellite will still need an ion thruster to stay on-station (very gentle thrust). But even with that, our reflector satellite will be vastly simpler than a communications satellite, and perhaps about the same mass for an equivalent mission duration.
Oh, almost forgot: Let's put a small hole in the center of the mirror so light can reach some solar cells to power the satellite! No reactors or RTGs here.
I think that about does it, as an "educated guess". Total mass isn't really an issue: Some member of the Long March family will be able to loft it.
(Yes, yes, I know I haven't calculated either the atmospheric dispersion or the "f-number" of the optics. But I made the mirror 10x larger so I wouldn't have to!)
My debug tools and code comprehension tools for C are nearly identical: 1. An IDE that's smart enough to dim code that's commended or #if'ed out (vscode works OK). 2. A code coverage tool (gcov is fine). 3. An execution trace tool (e.g., rr - https://en.wikipedia.org/wiki/Rr_(debugging)). 4. A "fat" interface to GDB (lots of dynamic content and context display, often a GUI).
The first "rule" is to simply spend NO TIME on code that has nothing to do with the task/problem at hand. Drill down first, then pay attention to the rest only as needed to get the job done. Which means the first step is to determine which code is relevant (vs. proven irrelevant).
I'm getting back into C after first having done 20 years of C then a decade of Python, all in the area of real-time/embedded sensing and control. I'm amazed how little the C environment has changed, and how rarely the newer (and better) C language features are actually being used.
If you really want to make a difference in schools, the first, best way is to get more tech folks to switch careers to teaching STEM subjects!
EnCorps (https://EnCorps.org) is a non-profit committed to precisely this mission. I've been involved with them for a year, and it's been one of the most transformative experiences of my life. So far I've put in over 400 volunteer hours tutoring students in STEM subjects.
I've been an engineer for 30 years. My retirement looks OK, but I can't start taking it for at least another decade. That's enough time for a hell of a teaching career!
I liked this show for the first few seasons. Then it turned into Friends...and I didn't like it so much.
I was also trying to identify why I liked the first few seasons so much, then drifted away, only to occasionally tune in when interesting or notable guests appeared.
Saying it became like "Friends" (or other long-running sitcom) is really saying it found it's formula, then stuck with it. Which isn't a bad thing if you can be entertained by repeated visits to a well-defined thematic box. In essence, the show became it's own trope.
I think that's why I've come to like series with relatively short and well-defined arcs, from the 3-6 episode mini-series, to the 1-3 year series. Beyond 3 years seems to be where my interest fades: Even Amazon's "The Americans" had some weaker seasons during its recently concluded 5-year run.
For a 12-year run, I think I'd prefer to see four separate 3-year projects that connect together.
I first learned to program in high school in 1972 on an old retired-in-place IBM 1440, using FORTRAN IV or punched cards.
Along with our program deck, we also had our "data deck", which was composed of multiple "datum cards".
We even used the term "datum processing" when we processed each card as it was read, and "data processing" when we read everything into an array then processed that. For example, to keep the data array "clean", input verification was done as "datum processing", then the resulting known-good array was done as "data processing".
We'd lose points on exams for missing the distinction and getting it wrong.
Well said! However, please permit me a moment as the Devil's Advocate:
I'm a fan of web comics, and I especially enjoy when a guest strip takes "liberties" with the strip's characters, back-story, pretexts, assumptions, and anything else. I find it always entertaining, and often surprisingly insightful.
Similarly, I view ST:D as not so much as a sin against The "Real" Star Trek Ethos, but more as a jab in the ribs combined with a "Hey! Look over there!" misdirection. A spin, a bit of a twist, some true wit, and some fun action. I believe the Star Trek tent is big enough, and strong enough, to not exclude ST:D on principle.
Hell, even ST:TOS was a mixed bag. Half of the episodes are flawed and forgettable. But the other half contained the real gems we treasure.
I really don't think all the ST spin-offs, including ST:D, have done any damage that wasn't already perpetrated by ST:TOS.
Don't even get me started on the movies. Just let ST-IV:TVH stand as the best ever and let it go.
I won't join CBS All Access for ST:D, but when it eventually does reach other distribution channels I want there to be episodes containing Tig Notaro. I believe she's one of the great comics of our time, and a fine dead-pan actor as well.
I don't care if she brings the entire ST:D franchise down in a smoldering inferno: I'll bring marshmallows.
Teaching any flavor of Ethics in isolation from it's context and conceptual roots is like teaching cake decoration without first understanding cake baking.
Start with the fundamental questions:
- What is it to be human?
- What is the individual?
- How can/do/should individuals interact?
- What is society?
- What is the relationship between the individual and society?
- What must/should the individual reasonably give up or provide to participate in society?
- What must/should society provide to the individual?
- What is law?
- What is a government?
- What is a citizen?
- Why can/should governments exist? Are they necessary?
- Where can/do/should government and society overlap, and where must they not?
- How do governments support society and the individual?
- What can/should a government require from, and provide to, its citizens?
- What is justice?
That's just the start. The terrain covers the general notion of a course sequence I'd call "The Individual and Society". An ideal approach is historical: The development and evolution of thought in this area starts from Plato, Socrates and Aristophanes, through Locke, Mills, Hobbes, Rousseau, and on to Rawls and his successors and critics. And many more I've failed to list.
The basics can be covered in a single year-long sequence that provides the context in which Ethics can then be studied, after which it may then be applied to specific domains. Done with focus and determination, it can all be covered "well enough" in two year-long sequences.
Though my undergrad degree is in Computer Engineering, it was my electives in Philosophy that enabled me to critically reason about some important career preferences. I was working in R&D even before I graduated, and much R&D funding was from the US Government, and the largest share of that was from the US military and DARPA (and its kin).
As a responsible citizen, I first decided I didn't want to work on Weapons of Mass Destruction. Then, given the ever increasing lethality of conventional precision munitions, I decided I didn't really want to work on weapons at all. But as a veteran, I personally knew the value of a strong military. So I found a comfortable middle ground: While I wouldn't work on "Things that Go Boom", I would work on the things that carried them (aircraft, ships, subs, rockets), and the tools needed to safely make them (production line and inspection technology).
But that wasn't enough. I loved developing new technologies, and I knew how easily I could be drawn to "the Dark Side", particularly concerning "dual-use" technologies.. So I made a conscious choice to never pursue a Top Secret (or higher) security clearance, which automatically kept me away from "dark" or "black" projects.
I felt I knew where I had drawn my personal and professional line, and why. If push ever came to shove, I consciously chose to change jobs if needed.
Then the day came when I was asked to present some of my work to a panel of folks with TS clearances who wanted to explore "other" applications. I was contractually bound to present all details of my work to our funding agency. But what, if any, responsibility did I have to in any way guide or help determine or limit it's future use?
I chose to walk a very narrow line, to describe the specifics of the work I had done, both its theoretical development and its application and testing. But do so without any generalization whatsoever. Of course, I was asked many general questions, to which I responded with my lack of experience in highly classified domains, and my lack of the clearances needed to discuss them. I do believe I delivered more than enough detail for others to carry my work forward into other domains, but I did none of that work for them. As I said, a very narrow line. I'm not at all sure I stayed far enough out of the gray area to say I was
I attended UC San Diego from 1981 to 1986, where we used GNU (not Gosling) Emacs and pre-release versions of GCC to hack on BSD 4.1-4.3 in several of my classes. Even then the strain between the many dimensions surrounding software development and use were evident: closed vs. shared source, free vs. commercial distribution, public domain vs. rent vs. own licensing, and so on, most of which persist to this day. Back then, the issues were made evident by the standoff between AT&T (UNIX) and DECUS (DEC (Digital Equipment Corporation) User Society), who distributed BSD via "DECUS tapes" for DEC platforms (especially for the then-new VAX-11 systems).
Many philosophical discussions debated the relative merits of the situation. The problem, for me, was disentangling the conflated issues, which demanded a focus on making words have specific meanings within the software context, rather than the free-for-all of pithy phrases then ruling the interwebs (USENET, at the time).
The commercial software industry had defined itself fairly well, leaving "everything else" as "non-commercial", which, aside from being a vague catch-all, created an artificial boundary that was quite ably crossed by "dual-licensed" software. Within the non-commercial arena, we had GNU at one end, placing a legal/moral/ethical stake in the ground, and those who favored more of a libertarian or laissez-faire approach. And, of course, the many left wandering between those extremes.
My own small contribution to the discussion was an attempt to frame non-commercial software as "Communal Software", where each project was it's own community that would have its own non-commercial rules, much like a housing development would have a homeowner's association (HOA) and a Code of Community Responsibility (CCRs). Software communities could federate when they shared common governance and rules/licensing. My hope was that this would encourage folks to try different things, and see which approaches worked best for which situations.
As a bottom-up approach it received some discussion, but GNU (and later OSI, the Open Source Initiative) had louder voices arguing for a top-down approach. The net result has been those two being the primary non-commercial camps, with BSD/MIT licenses filling many of the gaps between each of them and the commercial community, with more recent contributions from Creative Commons (CC). The top-down approach gained speed as non-commercial distribution shifted from physical media (tapes, floppies) to online (FTP, USENET alt.binaries, Gopher, and later communities such as SourceForge). Mass distribution encouraged reducing the number of licensing strategies.
While much has been done to clarify the terms we use, there still is way too much confusion still present in most discussions, with many folks talking over each other without realizing they are using language differently.
Any lexicographers and philosophers want to take a stab at improving our linguistic landscape?
I've been an OSS user and advocate since, well, RMS's GNU EMACS in the early '80's, when I was booting BSD from floppies (struth!). When the tsunami that was Windows 3.1 arrived and I got my first hard drive, I was multi-booting using LILO. When KVM arrived, I shoved Windows into a VM and ran Linux natively (which made Windows run with much more stability). When I did have to run Windows natively (at work and on hardware lacking Linux drivers), I always had Cygwin installed.
Then Windows 10 arrived, with many significant cleanups and fixes, but also with WSL, the Windows Subsystem for Linux. The initial minimal implementation has expanded to become truly useful. I especially like being able to easily launch Windows and Linux programs from a common desktop. The performance hit was much smaller than I expected.
I removed my unused Linux VMs and Cygwin to free up space when migrating my main home system to SSD.
I haven't abandoned Linux! But it's mainly Raspbian and Ubuntu Core these days.
OK, lets start with a simple question: Why do we build machines?
Let's say you're digging a ditch in your yard. Would you design and build a backhoe to dig just one ditch? Of course not, you'd grab your sho=vel and "git 'er dun". Now let's say thousands of people need to dig ditches, and they need to dig multiple ditches every day. That's when, and why, we make machines: To make tasks that have to be done over and over faster, easier and cheaper to accomplish.
Software is another way to make a "machine" do the same thing over and over again. In this case, the machine is a computer, which is a special kind of machine that can do many things on one set of hardware. Like a Transformer, but made of bits and bytes. Software is a "story" that tells a computer what kind of thing it is supposed to be, such as helping with taxes or playing a game. Just as stories can be written in English, Spanish or other languages, software "stories" are written using words in languages that computers understand.
If you have a display with a touchscreen, then there is a kind of software will even draw things that look like physical buttons and gages, and can make things happen, just like a physical button. This kind of software makes what is called a "user interface", but you can also call it a panel or any other name used for things with buttons and gages.
The coolest thing about software is what the user interface controls: Anything! Long ago, everyone used to do their taxes on paper. But that's quite a lot of paper when millions of people are filling in the same forms. And other people used to have to read all those millions of tax forms that were sent in A computer lets you run software that imitates the forms, and even helps you avoid mistakes while filling them in. When the form is filled out, it can be sent to another piece of software the government uses to read and process the form. This is called "electronic tax filing", and it is the kind of thing that can be done when computers share information with each other.
Software is special in another way: If it is written to run on a "general purpose" computer, then any general purpose computer can run it! If you have a backhoe but need a front-end loader, you have to go get a completely different machine. But if your computer is running tax software and you want it to run a game, you can do that on the same computer you already have: You don't need to go get a different computer!
Stories for computers are very different than the ones you'll read in a book. Stories for computers actually come to life and become "real", in that the computer will then do what the story, the program, tells it to do. It makes a "general purpose" computer do a very specific thing.
First, let's spin the time-o-meter back a bit and remember that Damore's original premise was impaired based on technical factors ALONE. This was a deficit of analysis, nothing psychological. He tried to mis-apply population and sub-group statistics without quantifying any null hypothesis or larger context.
Technical issues aside, the specific wording and tone used in his note is a separate issue. I'm no linguist or lit-crit person, but he seemed to be very abstract, as if he had no direct, personal involvement with the subject aside from investigating it and writing about it. Yet he was clearly trying to write a persuasion piece, which is what made the language disconnect apparent to me in the first place.
I read this as an effort to put forth and justify an opinion clad in flimsy technical garb, without the spine to clearly label it as a personal opinion. Weasel-words in the nether-world between a solid technical discussion and an opinion piece.
Then we get to when, how and why the piece was distributed. He had shared at least one earlier draft with several others within Google, with apparently no significant push-back. I've seen similar things happen in other organizations, when fringe opinions are shared within a small group with minimal reaction. Most often, it's "Oh, there he goes again.", and nobody takes it seriously, and may not even bother to read it. Or it is taken as a thought experiment, with no concerns about wider distribution. I have heard nothing about what any of the folks though about Damore's screed before it was widely shared.
We can see how Damore could have made bad assumptions about his general audience: First, he may have interpreted the earlier lack of push-back as approval. Second, he may have assumed the earlier readers were representative of the wider audience. Neither of these have anything to do with "the Autism Spectrum". These are common mistakes any of us can make with our generalizations and assumptions.
However, claiming involvement of "the Spectrum" in these errors without first showing that other factors weren't involved smells to me like excuse-making rather than a serious explanation, much less a mea culpa.
Anyone who confuses TSA checkpoints with actual security is sadly missing the point.
These checkpoints are truly, in the words of Bruce Schneier, "Security Theater". And I'm not using that in a pejorative manner equivalent to saying they are useless. Far from it!
First, the checkpoints are first aimed at discouraging the stupid, a category that includes most terrorists and mass-murderers. It can't prevent folks smart enough to see behind the curtain, but it can discourage those unable to think at a deeper level. For simple folks intent on disruption, the checkpoints work.
Second, the checkpoints are intended to reassure the public. Even when the public is told how ineffective the checkpoints are against real threats. Even when the actual risks of airborne terrorism in the US are statistically tiny. Again, despite our knowledge to the contrary, the checkpoints work at an emotional level to reassure the public.
The above successes do come at a substantial cost for taxpayers, but we can't say the results are "worthless", even though the checkpoints utterly fail to meet all of their stated purposes.
The best way to put TickBox out of business is to buy their product, then shut down every stream they find. TickBox is doing the studio's work FOR THEM, finding infringing content with no effort from the studios at all.
Really. Only a lawyer would pursue this path. An executive with half a brain would simply starve TickBox of content.
Slashdot Mirror
Yes, commercial pilots are taught to "fly their instruments". General aviation pilots may enjoy more "seat-of-the-pants" flying, but even they are taught to trust instruments over human perceptions, which are easily fooled, as even simple demos will show.
I used to work for an aircraft instrument maker, and our user interfaces, everything the pilot interacts with, got more care and attention than the rest of the instrument. Of course we had to display nothing but totally accurate data, and do so promptly, but we also had to do so in ways that were obvious and clear, so the pilot can take in the most important information with a quick glance.
The pilot's standard "scan" is perhaps the most-trained skill. To look at everything on the instrument panels and outside the windows often enough to not miss anything, yet slow enough to take in all vital information.
When things get hectic, the pilot still does this scan, interrupting it as needed to deal with situations, but still doing it. Because, as the saying goes, "trouble often comes in threes": Stopping everything to handle an initial situation may mask what's really going on, and lead to a cascade of failures.
With ever more data being aimed at the pilot, there is a distinct risk of information overload, especially when tired, or during tense but otherwise normal situations, such as take-off, landing, or flying through turbulence. This overload often encourages the pilot to rely more on signals from the body, which need less conscious processing, rather than focus on all that data.
Here, again, is where commercial pilots receive extra training, but perhaps not often enough. This is one of the factors that keep commercial pilot mandatory retirement ages so low: The risk of overload increases with age, even when all other factors match those of a younger person.
Plus, staying in peak training for decades is fatiguing, and relatively few can do so "naturally". Which is one of the reasons we're running out of commercial aircraft pilots.
It may seem counter-intuitive, but this overload risk is often handled by adding more automation, more automatic systems to "help" the pilot. So much so that actually manually "driving" a commercial aircraft, with hands on the controls, is an increasingly rare part of a normal flight.
Our instruments also tried to take pilot fatigue into account, saving our brightest and loudest alarms only for the most desperate situations, to punch-through that overload to help ensure prompt and correct reactions.
One product I worked on was a TAWS (Terrain Awareness and Warning System) instrument, which basically stayed quiet unless there was a risk of the pilot flying into the ground, to help prevent "CFIT" accidents (Controlled Flight Into the Ground). It has special modes for take-off and landing, though our instrument was designed to actually *avoid* making the pilot depend on it's display: Useful for information as part of the scan, but not to be used to navigate the aircraft. Our main function was to provide visual and audible alerts only when needed.
I believe 100% of US commercial aircraft (and perhaps now even biz-jets) are required to have TAWS on-board and active. Any TAWS-equipped plane approaching the ground outside of an approved approach path for a know airport will give the pilot "Terrain ahead. Pull up! Pull up!" alerts until the hazard no longer exists.
Unfortunately, if a stall is also immanent, the pilot will simultaneously receive an alert to push the nose down. And increase power. And other things as well. An overload of alerts, which a skilled and calm pilot will respond to with the most correct action. But which can overload a stressed or tired pilot, or one with the beginnings of a cold or flu.
The thing is, every alert can be silenced, to reduce the confusion and distractions. But an overloaded pilot can forget even this simple aid to keeping full awareness and control.
This is a big part of why pilots are so often blamed for crashes:
Much of recent AI progress has come from the awesome amount of cheap computing power available.
That's not going to change! As today's bleeding edge silicon processes evolve, they will get faster and cheaper (both in cost and energy consumption), if not smaller.
Much of AI is inherently parallel: So long as more CPUs and GPUs can be added, larger problems will be solved faster.
We are still in the first two generations of custom hardware for AI. That trend will continue and accelerate as new architectures and algorithms arrive.
I'd say there are at least three full "Moore's Law" generations coming for AI, very likely more. But transistors alone won't be driving it. Fortunately, there are lots of other factors that will.
Fundamentally, a 2-D FFT describes the dynamics present in any image. Sure, you could compare them between a known source displayed via different streaming methods on different screens. However, these numbers are meaningless on their own without taking the context of the viewer into account.
The FFT must include physical dimensions, starting with the screen's PPI value. So a 4K phone screen is inherently "sharper" than a 4K projector on a 20 meter movie screen. But we all know the movie screen offers a far better experience than a phone, more "immersive", independent of the perceived or actual sharpness.
The viewer's perceptions are also key. Starting with their ability to perceive. For the human eye to resolve a 4K image at the pixel level, that is to detect sharpness changes at that level, a person with 20-20 vision would need to sit NO FURTHER than a SINGLE screen diagonals away from the center of the screen. That's 65 inches away from a 65" inch monitor. If you aren't sitting that close, you aren't "seeing in 4K". So you have already started to lose "sharpness" independent of what you're watching.
And if you are sitting that close, you'll want a curved monitor, since the distance from the center pixel to your eye is much closer than the distances to the corner pixels. And you'll be watching alone, since there generally isn't space for two at that ideal viewing spot. So most of us get flat monitors and sit further away. Most of us sit so far from our screens that we aren't even "seeing in 1080p"! You'll notice that most TVs smaller than 32" are only 720p, which is because you really can't see more than that if your sitting at a normal TV viewing distance.
I *DO* sit that close. As I write this I'm sitting 55" away from my curved 65" TV/monitor. For most streaming content I lean back a bit simply because it makes no difference: The media sharpness is generally sloppier than what my eyes can perceive, so sitting back doesn't reduce the quality. That does change for well-rendered 4K content, where the original material is extremely sharp (directors and editors intentionally add blur to remove distracting levels of sharpness). That's when I lean in until my eyes can take in every detail.
If you aren't close enough, the content sharpness simply doesn't matter.
'nuf said.
I was in Engineering: I never got to go to the shows and conventions, so I didn't pay much attention to which ones the company attended. However, I did get involved when prospective customers came to visit: I often was one of the ponies in the dog and pony show!
It really doesn't take much effort to make a "good enough" concealment. Basically, the higher off the ground, the easier. Make them look like they're part of the utility infrastructure, and you're home free. The hard part is weatherproofing and hot days in the sun with no wind. For being rain-proof you want no holes, yet to cool down you do, since heat sinks are hard to hide.
We primarily made concealments containing steerable high-zoom video cameras, the same ones used in high-end security systems, mounted to extremely accurate miniature PTZ bases. The cameras had internal image stabilization, but we also added external stabilization. Then we added automatic subject tracking, so no remote operator on a joystick was needed.
They were bought by TLAs (Three Letter Agencies), and generally needed a warrant to be mounted and activated.
When the wars in Afghanistan and Iraq started, we were asked to modify our technology to provide 360-degree surveillance for forward fire bases, who never had enough soldiers to use as sentries 24/7. Our systems turned out so good that we next had to integrate them with C4I systems, just as was done with the video from Predator drones. We initially built the systems into concealments, but soon found that beige paint was good enough, and we simply used sturdy tripods.
When Somali pirates became a problem, we modified our systems so they could be mounted to ships to again provide 360 degree surveillance.
We were riding high, a small company (well under 100 employees) who was by far the largest provider in a specialty market. Then the Budget Sequestration of 2011 hit, and all of our government customers not only became unable to buy our new products, they couldn't even fund support contracts or repairs. The guillotine fell, but fortunately we had already started a pivot toward vertical integration, to provide the communication systems needed to relay the surveillance video.
We entered that market in the right way at the right time, and soon had a long list of prospective customers. But our reduced income caused us to burn through our cash stockpile, and then the banks to stop lending to us: The company folded just as our new products were ready to go into production. That really hurt.
Looking back, my favorite product was the firebase surveillance system. We were told it had helped prevent countless sneak attacks.
How the hell did this story make it onto /.?
Has no one there ever been to Ikea?
Yeah, the ~0.5 degree angular width of the sun is certainly an issue, as is the small target size. Fortunately it's one that can be mitigated by adding complexity and reducing efficiency, such as by using 3 reflective surfaces and/or collimation. The use of a long gravity tether in GEO would permit multiple annular reflectors to be kept in tight alignment. Modeling the positioning stability of such a system is difficult, but it's bounded, so the system should be controllable.
Even with a full Goldberg (ridiculously complex) implementation, there would be significant spill-over, a new star in the sky.
Let's assume, for the moment, that it is a "good idea". How should it be implemented?
If there is to be only one satellite, then there are only two orbits that can work: GEO and a polar Molniya that has the satellite overhead between dusk and dawn. With more satellites more orbits can work, but let's assume one for now.
Let's figure out how big a mirror is needed. First, it will need to have at least some degree of focus to keep the spot size bounded. That is, a flat plane won't do. Let's compute the total light needed over a 10 km x 80 km ellipse, an area of about 2500 km^2. Given that 1 lux = 1 lumen / m^2, the lumens we need will be lux * area. Let's assume a partial moon (0.1 lux) is the minimum needed. Multiply those numbers, and that's 250,000,000 lumens. Let's say naked sunlight (allowing for atmospheric losses) is roughly 100,000 lux. Area = lumens/lux, yielding a mirror area of 2500 m^2.
And that's for a *perfect* mirror: No losses, with perfect focus. Assuming a circular mirror, that's a minimum diameter of about 60 m. That million-to-one illumination ratio really rocks. So, at a first glance, the optics alone says it's doable, at least near the minimums I've used. VERY doable!
A mirror in a Molniya orbit will have to deal with a rapidly/continuously varying sun angle every night, but there may be rotational tricks to deal with that, *if* we can manage to rapidly change the mirror shape. But it would rapidly complicate things, so let's set the Molniya orbit aside.
A mirror in GEO need only cope with seasonal variations. While we're at it, let's increase the mirror area by a factor of 10, so we'll be sure to have abundant margin to play with; let's say a nice, round 200 m diameter.
We already have communication satellites at GEO that stay aimed with precision for 15 years or more. Of course, they're aiming tiny antennas that are a millionth the size of our mirror, so we still must consider the aiming problem.
Satellites use aiming actuators for the antennas, and thrusters and gyros (torquers) for the satellite body, which combined yield good pointing precision. Our reflector won't have that luxury: The antenna will dwarf any satellite body, and will also have minimal rigidity: It really can't be aimed much at all, and even then not quickly.
To get some rigidity we can spin the mirror, which should also help with its shape, though that may not be needed. The total range of motion needed to track the sun matches the 23.5 degree tilt axis over a year, which is roughly 0.1 degree per day. (Well, OK, the total wobble is 23.5 degrees in each direction, but we only need to split the difference to bounce the sun toward the ground, which is 11.75 degrees, doubled, which gets us back to 23.5 degrees).
Next is the issue of aiming/pointing. Using gas or chemical thrusters alone may be a non-starter, including ion thrusters. But with a spinning disk, we really should be able to use precession. But precess against what?
Given the slow rate of angular motion, I suspect a 100-300 km long gravity tether should be able to provide enough restoring force to make the job manageable. The satellite body will then need only to slightly pivot the mirror relative to the tether, an extremely low-energy operation.
The satellite will still need an ion thruster to stay on-station (very gentle thrust). But even with that, our reflector satellite will be vastly simpler than a communications satellite, and perhaps about the same mass for an equivalent mission duration.
Oh, almost forgot: Let's put a small hole in the center of the mirror so light can reach some solar cells to power the satellite! No reactors or RTGs here.
I think that about does it, as an "educated guess". Total mass isn't really an issue: Some member of the Long March family will be able to loft it.
(Yes, yes, I know I haven't calculated either the atmospheric dispersion or the "f-number" of the optics. But I made the mirror 10x larger so I wouldn't have to!)
My debug tools and code comprehension tools for C are nearly identical:
1. An IDE that's smart enough to dim code that's commended or #if'ed out (vscode works OK).
2. A code coverage tool (gcov is fine).
3. An execution trace tool (e.g., rr - https://en.wikipedia.org/wiki/Rr_(debugging)).
4. A "fat" interface to GDB (lots of dynamic content and context display, often a GUI).
The first "rule" is to simply spend NO TIME on code that has nothing to do with the task/problem at hand. Drill down first, then pay attention to the rest only as needed to get the job done. Which means the first step is to determine which code is relevant (vs. proven irrelevant).
I'm getting back into C after first having done 20 years of C then a decade of Python, all in the area of real-time/embedded sensing and control. I'm amazed how little the C environment has changed, and how rarely the newer (and better) C language features are actually being used.
If you really want to make a difference in schools, the first, best way is to get more tech folks to switch careers to teaching STEM subjects!
EnCorps (https://EnCorps.org) is a non-profit committed to precisely this mission. I've been involved with them for a year, and it's been one of the most transformative experiences of my life. So far I've put in over 400 volunteer hours tutoring students in STEM subjects.
I've been an engineer for 30 years. My retirement looks OK, but I can't start taking it for at least another decade. That's enough time for a hell of a teaching career!
I liked this show for the first few seasons. Then it turned into Friends...and I didn't like it so much.
I was also trying to identify why I liked the first few seasons so much, then drifted away, only to occasionally tune in when interesting or notable guests appeared.
Saying it became like "Friends" (or other long-running sitcom) is really saying it found it's formula, then stuck with it. Which isn't a bad thing if you can be entertained by repeated visits to a well-defined thematic box. In essence, the show became it's own trope.
I think that's why I've come to like series with relatively short and well-defined arcs, from the 3-6 episode mini-series, to the 1-3 year series. Beyond 3 years seems to be where my interest fades: Even Amazon's "The Americans" had some weaker seasons during its recently concluded 5-year run.
For a 12-year run, I think I'd prefer to see four separate 3-year projects that connect together.
I first learned to program in high school in 1972 on an old retired-in-place IBM 1440, using FORTRAN IV or punched cards.
Along with our program deck, we also had our "data deck", which was composed of multiple "datum cards".
We even used the term "datum processing" when we processed each card as it was read, and "data processing" when we read everything into an array then processed that. For example, to keep the data array "clean", input verification was done as "datum processing", then the resulting known-good array was done as "data processing".
We'd lose points on exams for missing the distinction and getting it wrong.
Well said! However, please permit me a moment as the Devil's Advocate:
I'm a fan of web comics, and I especially enjoy when a guest strip takes "liberties" with the strip's characters, back-story, pretexts, assumptions, and anything else. I find it always entertaining, and often surprisingly insightful.
Similarly, I view ST:D as not so much as a sin against The "Real" Star Trek Ethos, but more as a jab in the ribs combined with a "Hey! Look over there!" misdirection. A spin, a bit of a twist, some true wit, and some fun action. I believe the Star Trek tent is big enough, and strong enough, to not exclude ST:D on principle.
Hell, even ST:TOS was a mixed bag. Half of the episodes are flawed and forgettable. But the other half contained the real gems we treasure.
I really don't think all the ST spin-offs, including ST:D, have done any damage that wasn't already perpetrated by ST:TOS.
Don't even get me started on the movies. Just let ST-IV:TVH stand as the best ever and let it go.
I won't join CBS All Access for ST:D, but when it eventually does reach other distribution channels I want there to be episodes containing Tig Notaro. I believe she's one of the great comics of our time, and a fine dead-pan actor as well.
I don't care if she brings the entire ST:D franchise down in a smoldering inferno: I'll bring marshmallows.
Teaching any flavor of Ethics in isolation from it's context and conceptual roots is like teaching cake decoration without first understanding cake baking.
Start with the fundamental questions:
- What is it to be human?
- What is the individual?
- How can/do/should individuals interact?
- What is society?
- What is the relationship between the individual and society?
- What must/should the individual reasonably give up or provide to participate in society?
- What must/should society provide to the individual?
- What is law?
- What is a government?
- What is a citizen?
- Why can/should governments exist? Are they necessary?
- Where can/do/should government and society overlap, and where must they not?
- How do governments support society and the individual?
- What can/should a government require from, and provide to, its citizens?
- What is justice?
That's just the start. The terrain covers the general notion of a course sequence I'd call "The Individual and Society". An ideal approach is historical: The development and evolution of thought in this area starts from Plato, Socrates and Aristophanes, through Locke, Mills, Hobbes, Rousseau, and on to Rawls and his successors and critics. And many more I've failed to list.
The basics can be covered in a single year-long sequence that provides the context in which Ethics can then be studied, after which it may then be applied to specific domains. Done with focus and determination, it can all be covered "well enough" in two year-long sequences.
Though my undergrad degree is in Computer Engineering, it was my electives in Philosophy that enabled me to critically reason about some important career preferences. I was working in R&D even before I graduated, and much R&D funding was from the US Government, and the largest share of that was from the US military and DARPA (and its kin).
As a responsible citizen, I first decided I didn't want to work on Weapons of Mass Destruction. Then, given the ever increasing lethality of conventional precision munitions, I decided I didn't really want to work on weapons at all. But as a veteran, I personally knew the value of a strong military. So I found a comfortable middle ground: While I wouldn't work on "Things that Go Boom", I would work on the things that carried them (aircraft, ships, subs, rockets), and the tools needed to safely make them (production line and inspection technology).
But that wasn't enough. I loved developing new technologies, and I knew how easily I could be drawn to "the Dark Side", particularly concerning "dual-use" technologies.. So I made a conscious choice to never pursue a Top Secret (or higher) security clearance, which automatically kept me away from "dark" or "black" projects.
I felt I knew where I had drawn my personal and professional line, and why. If push ever came to shove, I consciously chose to change jobs if needed.
Then the day came when I was asked to present some of my work to a panel of folks with TS clearances who wanted to explore "other" applications. I was contractually bound to present all details of my work to our funding agency. But what, if any, responsibility did I have to in any way guide or help determine or limit it's future use?
I chose to walk a very narrow line, to describe the specifics of the work I had done, both its theoretical development and its application and testing. But do so without any generalization whatsoever. Of course, I was asked many general questions, to which I responded with my lack of experience in highly classified domains, and my lack of the clearances needed to discuss them. I do believe I delivered more than enough detail for others to carry my work forward into other domains, but I did none of that work for them. As I said, a very narrow line. I'm not at all sure I stayed far enough out of the gray area to say I was
I attended UC San Diego from 1981 to 1986, where we used GNU (not Gosling) Emacs and pre-release versions of GCC to hack on BSD 4.1-4.3 in several of my classes. Even then the strain between the many dimensions surrounding software development and use were evident: closed vs. shared source, free vs. commercial distribution, public domain vs. rent vs. own licensing, and so on, most of which persist to this day. Back then, the issues were made evident by the standoff between AT&T (UNIX) and DECUS (DEC (Digital Equipment Corporation) User Society), who distributed BSD via "DECUS tapes" for DEC platforms (especially for the then-new VAX-11 systems).
Many philosophical discussions debated the relative merits of the situation. The problem, for me, was disentangling the conflated issues, which demanded a focus on making words have specific meanings within the software context, rather than the free-for-all of pithy phrases then ruling the interwebs (USENET, at the time).
The commercial software industry had defined itself fairly well, leaving "everything else" as "non-commercial", which, aside from being a vague catch-all, created an artificial boundary that was quite ably crossed by "dual-licensed" software. Within the non-commercial arena, we had GNU at one end, placing a legal/moral/ethical stake in the ground, and those who favored more of a libertarian or laissez-faire approach. And, of course, the many left wandering between those extremes.
My own small contribution to the discussion was an attempt to frame non-commercial software as "Communal Software", where each project was it's own community that would have its own non-commercial rules, much like a housing development would have a homeowner's association (HOA) and a Code of Community Responsibility (CCRs). Software communities could federate when they shared common governance and rules/licensing. My hope was that this would encourage folks to try different things, and see which approaches worked best for which situations.
As a bottom-up approach it received some discussion, but GNU (and later OSI, the Open Source Initiative) had louder voices arguing for a top-down approach. The net result has been those two being the primary non-commercial camps, with BSD/MIT licenses filling many of the gaps between each of them and the commercial community, with more recent contributions from Creative Commons (CC). The top-down approach gained speed as non-commercial distribution shifted from physical media (tapes, floppies) to online (FTP, USENET alt.binaries, Gopher, and later communities such as SourceForge). Mass distribution encouraged reducing the number of licensing strategies.
While much has been done to clarify the terms we use, there still is way too much confusion still present in most discussions, with many folks talking over each other without realizing they are using language differently.
Any lexicographers and philosophers want to take a stab at improving our linguistic landscape?
They're not tractor beams, but pressor beams.
I've been an OSS user and advocate since, well, RMS's GNU EMACS in the early '80's, when I was booting BSD from floppies (struth!). When the tsunami that was Windows 3.1 arrived and I got my first hard drive, I was multi-booting using LILO. When KVM arrived, I shoved Windows into a VM and ran Linux natively (which made Windows run with much more stability). When I did have to run Windows natively (at work and on hardware lacking Linux drivers), I always had Cygwin installed.
Then Windows 10 arrived, with many significant cleanups and fixes, but also with WSL, the Windows Subsystem for Linux. The initial minimal implementation has expanded to become truly useful. I especially like being able to easily launch Windows and Linux programs from a common desktop. The performance hit was much smaller than I expected.
I removed my unused Linux VMs and Cygwin to free up space when migrating my main home system to SSD.
I haven't abandoned Linux! But it's mainly Raspbian and Ubuntu Core these days.
I have a tiny 3D printer (101Hero).
OK, lets start with a simple question: Why do we build machines?
Let's say you're digging a ditch in your yard. Would you design and build a backhoe to dig just one ditch? Of course not, you'd grab your sho=vel and "git 'er dun". Now let's say thousands of people need to dig ditches, and they need to dig multiple ditches every day. That's when, and why, we make machines: To make tasks that have to be done over and over faster, easier and cheaper to accomplish.
Software is another way to make a "machine" do the same thing over and over again. In this case, the machine is a computer, which is a special kind of machine that can do many things on one set of hardware. Like a Transformer, but made of bits and bytes. Software is a "story" that tells a computer what kind of thing it is supposed to be, such as helping with taxes or playing a game. Just as stories can be written in English, Spanish or other languages, software "stories" are written using words in languages that computers understand.
If you have a display with a touchscreen, then there is a kind of software will even draw things that look like physical buttons and gages, and can make things happen, just like a physical button. This kind of software makes what is called a "user interface", but you can also call it a panel or any other name used for things with buttons and gages.
The coolest thing about software is what the user interface controls: Anything! Long ago, everyone used to do their taxes on paper. But that's quite a lot of paper when millions of people are filling in the same forms. And other people used to have to read all those millions of tax forms that were sent in A computer lets you run software that imitates the forms, and even helps you avoid mistakes while filling them in. When the form is filled out, it can be sent to another piece of software the government uses to read and process the form. This is called "electronic tax filing", and it is the kind of thing that can be done when computers share information with each other.
Software is special in another way: If it is written to run on a "general purpose" computer, then any general purpose computer can run it! If you have a backhoe but need a front-end loader, you have to go get a completely different machine. But if your computer is running tax software and you want it to run a game, you can do that on the same computer you already have: You don't need to go get a different computer!
Stories for computers are very different than the ones you'll read in a book. Stories for computers actually come to life and become "real", in that the computer will then do what the story, the program, tells it to do. It makes a "general purpose" computer do a very specific thing.
I write stories for computers.
First, let's spin the time-o-meter back a bit and remember that Damore's original premise was impaired based on technical factors ALONE. This was a deficit of analysis, nothing psychological. He tried to mis-apply population and sub-group statistics without quantifying any null hypothesis or larger context.
Technical issues aside, the specific wording and tone used in his note is a separate issue. I'm no linguist or lit-crit person, but he seemed to be very abstract, as if he had no direct, personal involvement with the subject aside from investigating it and writing about it. Yet he was clearly trying to write a persuasion piece, which is what made the language disconnect apparent to me in the first place.
I read this as an effort to put forth and justify an opinion clad in flimsy technical garb, without the spine to clearly label it as a personal opinion. Weasel-words in the nether-world between a solid technical discussion and an opinion piece.
Then we get to when, how and why the piece was distributed. He had shared at least one earlier draft with several others within Google, with apparently no significant push-back. I've seen similar things happen in other organizations, when fringe opinions are shared within a small group with minimal reaction. Most often, it's "Oh, there he goes again.", and nobody takes it seriously, and may not even bother to read it. Or it is taken as a thought experiment, with no concerns about wider distribution. I have heard nothing about what any of the folks though about Damore's screed before it was widely shared.
We can see how Damore could have made bad assumptions about his general audience: First, he may have interpreted the earlier lack of push-back as approval. Second, he may have assumed the earlier readers were representative of the wider audience. Neither of these have anything to do with "the Autism Spectrum". These are common mistakes any of us can make with our generalizations and assumptions.
However, claiming involvement of "the Spectrum" in these errors without first showing that other factors weren't involved smells to me like excuse-making rather than a serious explanation, much less a mea culpa.
I probably should have said "stupid and/or easily intimidated' above.
Anyone who confuses TSA checkpoints with actual security is sadly missing the point.
These checkpoints are truly, in the words of Bruce Schneier, "Security Theater". And I'm not using that in a pejorative manner equivalent to saying they are useless. Far from it!
First, the checkpoints are first aimed at discouraging the stupid, a category that includes most terrorists and mass-murderers. It can't prevent folks smart enough to see behind the curtain, but it can discourage those unable to think at a deeper level. For simple folks intent on disruption, the checkpoints work.
Second, the checkpoints are intended to reassure the public. Even when the public is told how ineffective the checkpoints are against real threats. Even when the actual risks of airborne terrorism in the US are statistically tiny. Again, despite our knowledge to the contrary, the checkpoints work at an emotional level to reassure the public.
The above successes do come at a substantial cost for taxpayers, but we can't say the results are "worthless", even though the checkpoints utterly fail to meet all of their stated purposes.
The best way to put TickBox out of business is to buy their product, then shut down every stream they find. TickBox is doing the studio's work FOR THEM, finding infringing content with no effort from the studios at all.
Really. Only a lawyer would pursue this path. An executive with half a brain would simply starve TickBox of content.