They're only required to burn low-sulfur fuel while docked, plus in the last hour before docking and the first hour after leaving (source: Sydney Morning Herald). And even then, their standards for "low" are nowhere near as strong as those in the U.S. (3.5% sulfur in Australia vs. 0.1% in the U.S., and.05% by 2020).
Not just when they're at port. Any time a ship is within a couple hundred miles of the U.S., Canada, or Europe, they have to burn cleaner diesel fuel. That's not so great either, but it is better than bunker fuel. But yes, when they're out in the open ocean, or when they're coming into ports in South America, Africa, Asia, or Australia, they're likely to be burning the dirty stuff, as I understand it.
TL:DR nobody would book onto a nuclear cruise ship. It would be commercially nonviable.
Very true. That's why the cruise industry is moving to LNG (liquefied natural gas) on new ships going forward. Unfortunately, for the next decade or two, we'll still have plenty of old ones burning whatever fuel is cheap (typically bunker fuel).
The Stanford Prison Experiment put people in an irrevocable situation. This is not the case.
Maybe, maybe not. In the tech industry, a lot of us are lucky enough to be in a financial position where we could give notice and not worry about whether we'd be able to pay our electric bill, but most people aren't in that position. For most people, though, not having a job would be a major problem. Therefore, most employees are in a position of near-absolute subservience to their employer, much like the Stanford Prisoner Experiment. That puts them in a unique position to be victims of any arbitrary abuse that an employer might dole out.
... just because I don't trust you doesn't magically mean you're in the irrevocable situation that will degenerate to the state that the Stanford Prison Experiment did.
To be clear, I did not mean to imply that a workplace doing drug testing is inherently going to degrade until the police are called after employees are found unconscious, having been beaten to within an inch of their lives by management. It's a continuum, not a binary switch. The point is that every study I've seen that has ever looked at this subject, without fail, has found that trust breeds trustworthiness, and distrust breeds bad behavior. Treating people as if they're better than they actually are tends to cause those people to step up and do better. Treating someone as if they're worse than they actually are tends to have the opposite effect.
In my experience, employers that do routine drug tests also treat employees with distrust in many other ways, and unsurprisingly, lots of people betray that trust with regularity. Drug testing is almost invariably a symptom of a much bigger trust problem, and most of those companies become progressively worse places to work until the surly employees drive all the customers away, at which point the businesses fail and the problem is "solved".
If my employer told me to take a drug test, I would not only refuse, but also give notice on the spot. Just so we're clear, I've never used drugs in my entire life (except legal stuff like antihistamines, decongestants, and antibiotics). So why would I quit over such an employer action? To me, the very fact that an employer is asking me to prove that I'm not guilty tells me that the employer has reason to distrust me. If I've done nothing wrong, then I really don't like to be implicitly accused of doing something wrong. I shouldn't have to jump through arbitrary hoops to prove that I'm trustworthy. My job performance should be proof of that. And if it isn't, then I'm working for the wrong company.
And more than that, I also believe very strongly that what people do outside of work, so long as it does not impact their job performance, is none of an employer's business. If I completely snapped and decided to spend my weekends marching in Donald Trump rallies and picketing military funerals with Westboro Baptist Church, came home from work and drank a gallon of vodka, spent my evenings dancing in drag at a gay strip club, and voted for the National Socialist Party, my employer would have no legal right to fire me for doing any of those things. So why, then, should an employer have the right to fire someone over drugs used outside of work? Because it is illegal? For many people, sitting in the wrong section of the bus used to be illegal. Just because something is illegal doesn't make it wrong, and even if it is wrong, that still doesn't make it a cause for dismissing an employee.
And I would strongly disagree. API design is one of the hardest and most valuable things software engineers do: determining the best places and ways to expose appropriate functionality so that it is most useful to others (including yourself).
Just to be clear, I'm not saying it isn't valuable. I'm saying that the API has almost no impact on the design of the software that implements that API, and that its only impact is on other people's code. That makes it not part of the fundamental design of the software (unless the software is relatively simple), but rather a thin veneer on top of the design that acts as a gatekeeper for the machinery below it. It is a really important thing for developers to do, don't get me wrong, but it isn't a fundamental part of the design of that software.
To use a car analogy, an API is like a car stereo. A car stereo needs to meet a certain threshold of usability or else people might consider other options, but it is rare that anybody decides to not buy a car because the stereo is the wrong color. And like a car stereo, a good API is relatively easy to retrofit, assuming what's under the hood works well. If it doesn't, you can put any API on top of it that you want, and the software is still going to suck.
And in much the same way that nobody (sane) replaces an entire car just to get a stereo upgrade, almost nobody ever replaces a working chunk of code just to get a cleaner API. It is far easier to wrap an ugly-but-functional API with a thin shim that makes it more suitable for your needs. Developers do that frequently, at least for nontrivial APIs.
Thus, I would argue that the most important thing about an API (by far) is whether the code underneath it works, and that what the API looks like is much less important. And I say this even as somebody who has spent a lot of time over the years pushing engineers to develop good APIs. It is important, but if I had to choose between "works but ugly" and "broken but pretty", I'd choose the first any day of the week. You can always wrap a bad API to make it pretty. You can't usually wrap a broken API to make it work.
Look at the design of C++'s standard library APIs (part of it being the former STL). Then compare that to some half-ass collections interface (e.g. - early versions of collections in Java). You are claiming that there is nothing worthy of legal protection in the design of those far superior C++ interfaces. That they are merely some necessary functional bits to invoke the (truly valuable) code that sits behind them.
IMO, both look like pretty straightforward C++/Java ports of the Objective-C collection classes plus NSEnumerator to me, and I'm pretty sure those predate Java and STL (and are based loosely on classes that go back even further). Given that Sun worked with NeXT on OpenStep for two years before Java came out, I have no way to know whether Sun copied NeXT's design or played some role in both designs. Either way, though you can reasonably argue that C++ and Java collection classes are prime examples of why the entire industry is better off when we have more copying of well-designed APIs, rather than less.
As for the collection classes being thin veneer over truly valuable code, no, in the case of collection classes, they're mostly thin veneer over the kinds of code that every beginning computer programmer implements as part of an Intro to Data Structures class in college. The only reason collection classes even exist is to save people a few extra hours writing a bunch of boilerplate code that everybody knows how to write. They are quite literally the bricks of the software world—very useful, but about as interesting as a rock....
This kind of argues that the way you organize your code has no value. Or, that extracting a main design component of your code -- its organization -- renders that design no longer protectable (but it would have been if you didn't create a header?).
I would argue that an API itself is not a main design component of well-written code, but rather a formal specification for how that code interacts with other code. I can take that same API and implement it in an infinite number of ways, each with fundamentally architectures underneath. The whole point of an API is to separate the interface from the implementation so that you can change the implementation without breaking compatibility, which means it tells you almost nothing about the actual organization of the code, per se (assuming the API isn't too leaky, that is).
An API contract is basically the equivalent of a feature list for a piece of software. It tells what the software does. It doesn't tell how the software does it. The best real-world analog would be the index in a science textbook. It tells what the book teaches. It doesn't provide the actual details. And because someone else writing a science textbook has to use exactly the same terms (to allow mutual communication), every science book that covers similar topics will invariably have many identical names in their indices.
The counter-argument you should have used was to say that although mere collections of facts (e.g. libfoo contains a function x that takes parameters a, b, and c) aren't necessarily copyrightable, the specific organization of those facts is potentially copyrightable if there is artistic expression in its design. Then, you could argue that the choosing which classes/functions/data types to include in the public headers constitutes artistic expression. At that point, we would then have to debate whether that decision represents a functional aspect or not, to what degree you can change that without breaking the functionality, whether the organization of headers is inherently rigid based on functional area or has some degree of flexibility, whether the fact that reorganizing the contents of headers would result in compilation errors would force things back into purely functional territory (much like reordering a phone book would render it useless), etc.
So yeah, in truth, it isn't clear-cut. Nothing in law is, particularly when the Supreme Court rejects certiorari on cases that contradict everyone's general understanding of prior case law, as established by the ninth circuit in Sega v. Accolade (1992). And in the twenty-plus years since then, we've built the entire computer industry on the assumption that APIs are not protectable by copyright. So frankly, it's downright terrifying to see the courts leaning the other direction. The flood of lawsuits that are sure to result in the coming years could very easily destabilize the entire computer industry, and nothing short of an act of Congress can prevent the coming chaos at this point. As it stands right now, we're all pretty much screwed, which is bad for everybody... except the lawyers. But that's just my opinion.
To put that in perspective, assuming the clocks are in sync:
11:48Z last voice contact
00:26Z 3044 ANTI ICE R WINDOW
00:26Z 561200 R SLIDING WINDOW SENSOR
00:26Z 2600 SMOKE LAVATORY SMOKE
00:27Z 2600 AVIONICS SMOKE 00:27Z ATC attempts to contact plane. Avionics is already on fire, pilots already have plane diving towards emergency water landing
00:28Z 561100 R FIXED WINDOW SENSOR
00:29Z 2200 AUTO FLT FCU 2 FAULT
00:29Z 2700 F/CTL SEC 3 FAULT Aircraft lost from passive radar as avionics succumbs to fire and VHF radio/transponders stop transmitting
From what I see here, it looks like there was a fire in the cockpit, with the first failure involving whatever circuit powers the cockpit window defroster. This is far more likely to have been an electrical malfunction than terrorism, given that the aircraft continued flying for at least three full minutes (i.e. not a mid-air breakup) and that the failures began in or around the cockpit.
Of course, ACARS can reorder messages based on priority, so if it thinks that the cockpit window is more important than the smoke detector in the lavatory detecting smoke, it might have sent the messages out of order. If so, this could have been caused by a fire or explosion in the lavatory that blew out the side of the plane and started a major fire in avionics.
On the other hand, I'd expect an explosion to not result in an ongoing fire under those conditions. If an explosion actually resulted in the sliding cockpit window shattering, there should be so much wind that a fire would be unsustainable, which means avionics shouldn't have burned. That suggests a much slower progression of fire, which is why I have my doubts about terrorism being involved in any way.
Of course, I read an comment from a pilot that this could be caused by breakers in the right wing tripping, in which case all bets are off.
Either way, IANAPilot, and IANAA(viation)E(ngineer), so take that with a grain of salt. It's just a gut feeling.
In general, the fact that something is a creative work or takes time to create doesn't necessarily make it copyrightable. For a creative work, any functional aspects of that design are supposed to be protected by patents, not copyright. And an insufficiently creative work isn't protected at all, no matter how much time it took to create it.
For example, the courts long ago ruled in Feist Publications, Inc., v. Rural Telephone Service Co. that the difficulty of creating something is not sufficient to make it copyrightable when they declared that a phone book is a non-creative collection of facts. One could reasonably argue that a header file collects the declarations from source code, and that the real creative work is the source code itself. After all, the sole reason for a header file is to consolidate a bunch of declarations into a form that that makes it easier for a compiler to digest. This arguably makes a header no more a creative work than the phone book. That's not arguing that an API shouldn't be copyrightable per se, so much as that a header shouldn't be unless it contains other creative works beyond the declarations.
Also, per 17 U.S.C. section 1302, anything that is "dictated solely by a utilitarian function of the article that embodies it" is not eligible for copyright. The intent of copyright law is to shift responsibility for protecting such creative works into the domain of patent law. So given that there's a strong utilitarian aspect to APIs (because any function has basically exactly one valid declaration, or else your code won't link correctly), if you want to argue that an API should be protected by copyright, you have to come up with a concrete argument of why that API's design is more than just utilitarian in nature. So any creative effort that was focused on making an API easier to use doesn't count towards the creativity requirement for copyright purposes.
I have long thought that it would be a bad idea to eliminate the last samples, even thought exposure to it would be devastating to anyone getting infected from one of them. The bug is indeed very dangerous, but I harbor no illusions that by destroying the last two attested samples (one at the CDC in Atlanta, one in Russia) we could be truly sure we got them all. There is an unknown--and unknowable--number of other samples of the bug in the world. If we had no known samples available, we'd surely have even greater problems getting a cure if we had destroyed the attested samples.
The thing is, the existing vaccines aren't even derived from smallpox. They're derived from a related virus that isn't fatal. We don't need smallpox to exist just to produce vaccines unless somebody genetically engineers a modified smallpox virus that doesn't contain any of the same markers as cowpox, monkeypox, or vaccinia. And if somebody does that, the odds are very high that A. having a sample of smallpox won't help in creating the vaccine either, and B. the organization that someday creates that modified virus wouldn't have been able to get their hands on it if we had destroyed all the samples in a timely manner instead of keeping it around just in case we need to engage in biowarfare....
Agreed. In practice, viruses have a tendency to never go away. Just take a look at the people who have been "cured" of ebola. Months or years later, some of them start showing symptoms again, because the virus found a reservoir inside an eyeball or some other random part of the body where the immune system is not as effective.
Also, the claim that smallpox can only infect humans is naïve. It can, in fact, infect other primates. So the fact that it is no longer found in humans does not mean that it can't come back on its own. It is unlikely, but not impossible. In fact, it is highly likely that the initial smallpox epidemics were caused by the virus making its way into humans from some other animal species. If it happened once, it could happen twice....
So the assertions upon which the author built the argument against smallpox are somewhat dubious, IMO. With that said, that doesn't mean that the conclusions are wrong. The important question is whether we can continue to manufacture smallpox vaccines indefinitely without the actual virus. If the answer is yes (and I believe that it is), then destroying the most likely way for the virus to end up spreading among the population does make sense.
Any recurrence of the virus, whether natural or artificial, would either be different from the known smallpox strains in meaningful ways or it wouldn't. If it is different, then the current smallpox virus probably won't be of any real benefit in developing a vaccine for the new variant; they would need samples of the new virus instead. If it isn't different, then the existing vaccine will "just work", and we don't need the current smallpox virus.
Either way, the only plausible future use for smallpox would be as a biological weapon, and IMO, we owe it to future generations to destroy it.
And as I post this, I'm struggling to avoid laughing. Because of a bit of over-editing, that last sentence almost ended with "... and IMO, we owe it to future generations to do so." Yikes!
A mixture? Horrified. An ionically bonded molecule? Not so much.
But thiomersal breaks down into inorganic mercury in the bloodstream, and inorganic mercury exhibits neurotoxicity. Just because a dangerous substance is bound into a compound doesn't mean it isn't dangerous.
Exactly. More to the point, the more configurations (where the definition of "configurations" includes even subtle things like what apps are installed or what preferences somebody has chosen), the greater the odds of at least one person hitting any given serious bug, and the greater the number of people affected by such an unusual bug.
For example, in the early part of the 2000s, Apple made single-digit millions of Macs, and there were probably low double-digit millions in active use. There are now over a billion iOS devices in active use. So if there were a serious bug in both OS X v10.2 (in 2003) and iOS 9.x (today) with identical probabilities of occurring, you'd have seen a hundred affected users of the latter for every one affected user of the former. Something that affects 30 people on iOS today probably wouldn't have even been detected in OS X v10.2 thirteen years ago, because more likely than not, no OS X user would have gone down the affected code path.
You're just a person. There's zero reason to trust you.
Actually, there's one very big reason to trust you: psychology.
As anybody who has ever read about the Stanford Prison Experiment should understand, when you treat people like criminals, they tend to fall into those roles, and when you tell group A to assume that other group B are criminals, group A tend to treat group B as less than human, and vice versa.
The best way to have a work environment where people behave in respectful ways is to treat the employees with respect until they prove that they can't be trusted on an individual basis, and then fire them. The best way to end up with a bunch of sullen workers who have no qualms about stealing office supplies/food/* is to treat them like criminals.
The more complex the system, and the more users a system has, the more critical bugs will escape unnoticed. With that said, this means that there is at least one hardware configuration that they don't have as part of their automated testing pool (I assume that they do have at least "does it boot" automated testing and aren't relying 100% on dogfooding to catch these issues).
On the flip side, it could be that their testing fleet is busy doing tests for the upcoming major release, and that they don't have one for minor software updates like this one, in which case it's the fault of the people who came up with the idiotic "no downgrading" policy. Personally, I blame Scott Forstall.:-D
How would you feel if doctors were legally required to tell parents that the vaccine they were about to give their child had mercury in it?
Actually, those vaccines are required by law to identify whether they contain Thiomersal/thimerosal, though there are some sticky edge cases. And if you ask the doctor and the doctor lies to you, that's probably legally actionable.
Given that we've practiced some form of artificial selection for centuries, it is pretty much safe to say that crossing two organisms that produce edible food will almost invariably result in a new organism that produces edible food. Most of the things that we don't know are ecological, e.g. the risks of creating a monoculture that is susceptible to a specific disease that doesn't exist yet. Those issues are certainly cause for concern, but they're unlikely to be a health issue.
By contrast, when manually editing genes, it wouldn't be entirely implausible for someone to accidentally slip a recessive gene sequence into an apple tree seed that, when present in both chromosomes, would cause the production of cyanide. And then in the second generation that isn't supposed to exist, suddenly you have fruit that look normal, but kill people....
Look, I'm not saying that GMO foods are bad, or that they don't provide significant benefits for humanity, particularly when it comes to creating drought-resistant crops that can survive in areas affected by famine, etc. What I'm saying is that no one has the right to force someone else to take unknown risks without that person's knowledge or consent, and deliberately unlabeled GMO foods do just that.
Humans selecting for specific genes through breeding is not the same thing as genetic modification any more than predators putting selective pressure on a population is—unless, of course, you can show me how I would naturally cause a frog to mate with a corn stalk and produce interesting results.
The thing is, saying that GMO foods are "safe" is nonsensical. That's like saying that cars are safe. That can be true for every car built today, and then someone can resurrect the Pinto design or whatever. The problem with GMO foods is not that they aren't safe, but rather that companies are arbitrarily mucking with genes in ways that we don't fully understand, with results that we don't fully understand, then unleashing them on an unsuspecting public with little or no scientific testing. So the products today might be safe, but the next product might be a disaster waiting to happen, and we might not even know about the damage until suddenly there's a huge uptick in colon cancer rates or heart disease or breast cancer after thirty years that correlates with areas where they consumed a particular GMO crop.
IMO, the public has a right to know when they're part of a giant science experiment, and that's what this is. Any claims to the contrary are disingenuous at best. People have a right to obtain the information required to judge the risks themselves, and to make decisions based on that judgment. Hiding that information prevents them from making an informed decision.
I don't remember any pranks that were mean-spirited...
I don't know. The bathroom switching prank, if repeated today, would probably have resulted in jail time for conspiracy to commit lewd and indecent acts.
Not necessarily. Every year, it seems like somebody in the U.S. decides to do the old "Santa dangling precariously from the chimney" gag. To my knowledge, nobody has ever gone to jail for it, though in some cases, after about the twentieth 911 call, they've asked them to take it down. And in the U.K., there was this gag, where folks staged a fake murder for the Google Street View cameras. The police thought it was funny.
Low-speed consumer rail, for sure. High-speed... probably not. That's why we need high-speed rail sooner rather than later. Otherwise, it will never get built, and we'll continue wasting huge amounts of energy unnecessarily sending passengers 30,000 feet up into the air until we run out of fossil fuels to power them.
Slashdot Mirror
They're only required to burn low-sulfur fuel while docked, plus in the last hour before docking and the first hour after leaving (source: Sydney Morning Herald). And even then, their standards for "low" are nowhere near as strong as those in the U.S. (3.5% sulfur in Australia vs. 0.1% in the U.S., and .05% by 2020).
Not just when they're at port. Any time a ship is within a couple hundred miles of the U.S., Canada, or Europe, they have to burn cleaner diesel fuel. That's not so great either, but it is better than bunker fuel. But yes, when they're out in the open ocean, or when they're coming into ports in South America, Africa, Asia, or Australia, they're likely to be burning the dirty stuff, as I understand it.
Very true. That's why the cruise industry is moving to LNG (liquefied natural gas) on new ships going forward. Unfortunately, for the next decade or two, we'll still have plenty of old ones burning whatever fuel is cheap (typically bunker fuel).
Maybe, maybe not. In the tech industry, a lot of us are lucky enough to be in a financial position where we could give notice and not worry about whether we'd be able to pay our electric bill, but most people aren't in that position. For most people, though, not having a job would be a major problem. Therefore, most employees are in a position of near-absolute subservience to their employer, much like the Stanford Prisoner Experiment. That puts them in a unique position to be victims of any arbitrary abuse that an employer might dole out.
To be clear, I did not mean to imply that a workplace doing drug testing is inherently going to degrade until the police are called after employees are found unconscious, having been beaten to within an inch of their lives by management. It's a continuum, not a binary switch. The point is that every study I've seen that has ever looked at this subject, without fail, has found that trust breeds trustworthiness, and distrust breeds bad behavior. Treating people as if they're better than they actually are tends to cause those people to step up and do better. Treating someone as if they're worse than they actually are tends to have the opposite effect.
In my experience, employers that do routine drug tests also treat employees with distrust in many other ways, and unsurprisingly, lots of people betray that trust with regularity. Drug testing is almost invariably a symptom of a much bigger trust problem, and most of those companies become progressively worse places to work until the surly employees drive all the customers away, at which point the businesses fail and the problem is "solved".
If my employer told me to take a drug test, I would not only refuse, but also give notice on the spot. Just so we're clear, I've never used drugs in my entire life (except legal stuff like antihistamines, decongestants, and antibiotics). So why would I quit over such an employer action? To me, the very fact that an employer is asking me to prove that I'm not guilty tells me that the employer has reason to distrust me. If I've done nothing wrong, then I really don't like to be implicitly accused of doing something wrong. I shouldn't have to jump through arbitrary hoops to prove that I'm trustworthy. My job performance should be proof of that. And if it isn't, then I'm working for the wrong company.
And more than that, I also believe very strongly that what people do outside of work, so long as it does not impact their job performance, is none of an employer's business. If I completely snapped and decided to spend my weekends marching in Donald Trump rallies and picketing military funerals with Westboro Baptist Church, came home from work and drank a gallon of vodka, spent my evenings dancing in drag at a gay strip club, and voted for the National Socialist Party, my employer would have no legal right to fire me for doing any of those things. So why, then, should an employer have the right to fire someone over drugs used outside of work? Because it is illegal? For many people, sitting in the wrong section of the bus used to be illegal. Just because something is illegal doesn't make it wrong, and even if it is wrong, that still doesn't make it a cause for dismissing an employee.
In my mind, it's a matter of principle.
Just to be clear, I'm not saying it isn't valuable. I'm saying that the API has almost no impact on the design of the software that implements that API, and that its only impact is on other people's code. That makes it not part of the fundamental design of the software (unless the software is relatively simple), but rather a thin veneer on top of the design that acts as a gatekeeper for the machinery below it. It is a really important thing for developers to do, don't get me wrong, but it isn't a fundamental part of the design of that software.
To use a car analogy, an API is like a car stereo. A car stereo needs to meet a certain threshold of usability or else people might consider other options, but it is rare that anybody decides to not buy a car because the stereo is the wrong color. And like a car stereo, a good API is relatively easy to retrofit, assuming what's under the hood works well. If it doesn't, you can put any API on top of it that you want, and the software is still going to suck.
And in much the same way that nobody (sane) replaces an entire car just to get a stereo upgrade, almost nobody ever replaces a working chunk of code just to get a cleaner API. It is far easier to wrap an ugly-but-functional API with a thin shim that makes it more suitable for your needs. Developers do that frequently, at least for nontrivial APIs.
Thus, I would argue that the most important thing about an API (by far) is whether the code underneath it works, and that what the API looks like is much less important. And I say this even as somebody who has spent a lot of time over the years pushing engineers to develop good APIs. It is important, but if I had to choose between "works but ugly" and "broken but pretty", I'd choose the first any day of the week. You can always wrap a bad API to make it pretty. You can't usually wrap a broken API to make it work.
IMO, both look like pretty straightforward C++/Java ports of the Objective-C collection classes plus NSEnumerator to me, and I'm pretty sure those predate Java and STL (and are based loosely on classes that go back even further). Given that Sun worked with NeXT on OpenStep for two years before Java came out, I have no way to know whether Sun copied NeXT's design or played some role in both designs. Either way, though you can reasonably argue that C++ and Java collection classes are prime examples of why the entire industry is better off when we have more copying of well-designed APIs, rather than less.
As for the collection classes being thin veneer over truly valuable code, no, in the case of collection classes, they're mostly thin veneer over the kinds of code that every beginning computer programmer implements as part of an Intro to Data Structures class in college. The only reason collection classes even exist is to save people a few extra hours writing a bunch of boilerplate code that everybody knows how to write. They are quite literally the bricks of the software world—very useful, but about as interesting as a rock....
I would argue that an API itself is not a main design component of well-written code, but rather a formal specification for how that code interacts with other code. I can take that same API and implement it in an infinite number of ways, each with fundamentally architectures underneath. The whole point of an API is to separate the interface from the implementation so that you can change the implementation without breaking compatibility, which means it tells you almost nothing about the actual organization of the code, per se (assuming the API isn't too leaky, that is).
An API contract is basically the equivalent of a feature list for a piece of software. It tells what the software does. It doesn't tell how the software does it. The best real-world analog would be the index in a science textbook. It tells what the book teaches. It doesn't provide the actual details. And because someone else writing a science textbook has to use exactly the same terms (to allow mutual communication), every science book that covers similar topics will invariably have many identical names in their indices.
The counter-argument you should have used was to say that although mere collections of facts (e.g. libfoo contains a function x that takes parameters a, b, and c) aren't necessarily copyrightable, the specific organization of those facts is potentially copyrightable if there is artistic expression in its design. Then, you could argue that the choosing which classes/functions/data types to include in the public headers constitutes artistic expression. At that point, we would then have to debate whether that decision represents a functional aspect or not, to what degree you can change that without breaking the functionality, whether the organization of headers is inherently rigid based on functional area or has some degree of flexibility, whether the fact that reorganizing the contents of headers would result in compilation errors would force things back into purely functional territory (much like reordering a phone book would render it useless), etc.
So yeah, in truth, it isn't clear-cut. Nothing in law is, particularly when the Supreme Court rejects certiorari on cases that contradict everyone's general understanding of prior case law, as established by the ninth circuit in Sega v. Accolade (1992). And in the twenty-plus years since then, we've built the entire computer industry on the assumption that APIs are not protectable by copyright. So frankly, it's downright terrifying to see the courts leaning the other direction. The flood of lawsuits that are sure to result in the coming years could very easily destabilize the entire computer industry, and nothing short of an act of Congress can prevent the coming chaos at this point. As it stands right now, we're all pretty much screwed, which is bad for everybody... except the lawyers. But that's just my opinion.
To put that in perspective, assuming the clocks are in sync:
11:48Z last voice contact
00:26Z 3044 ANTI ICE R WINDOW
00:26Z 561200 R SLIDING WINDOW SENSOR
00:26Z 2600 SMOKE LAVATORY SMOKE
00:27Z 2600 AVIONICS SMOKE
00:27Z ATC attempts to contact plane. Avionics is already on fire, pilots already have plane diving towards emergency water landing
00:28Z 561100 R FIXED WINDOW SENSOR
00:29Z 2200 AUTO FLT FCU 2 FAULT
00:29Z 2700 F/CTL SEC 3 FAULT
Aircraft lost from passive radar as avionics succumbs to fire and VHF radio/transponders stop transmitting
From what I see here, it looks like there was a fire in the cockpit, with the first failure involving whatever circuit powers the cockpit window defroster. This is far more likely to have been an electrical malfunction than terrorism, given that the aircraft continued flying for at least three full minutes (i.e. not a mid-air breakup) and that the failures began in or around the cockpit.
Of course, ACARS can reorder messages based on priority, so if it thinks that the cockpit window is more important than the smoke detector in the lavatory detecting smoke, it might have sent the messages out of order. If so, this could have been caused by a fire or explosion in the lavatory that blew out the side of the plane and started a major fire in avionics.
On the other hand, I'd expect an explosion to not result in an ongoing fire under those conditions. If an explosion actually resulted in the sliding cockpit window shattering, there should be so much wind that a fire would be unsustainable, which means avionics shouldn't have burned. That suggests a much slower progression of fire, which is why I have my doubts about terrorism being involved in any way.
Of course, I read an comment from a pilot that this could be caused by breakers in the right wing tripping, in which case all bets are off.
Either way, IANAPilot, and IANAA(viation)E(ngineer), so take that with a grain of salt. It's just a gut feeling.
Not necessarily on a fly-by-wire bird. If a fire takes out power to enough of avionics, you might as well be in a flying bathtub.
Per CNN, here's the ACARS data:
21:13Z 341234 FWC2 :NO DATA FROM ADC1 (This is "02 ENG START" phase)
21:13Z 3100 QAR (also engine start phase)
21:13Z 313352 QAR MEDIA LOW(3TU) (also engine start phase)
21:14Z 231100 ICAO ADDRESS/HF2(3RE2) (also engine start phase)
Long period of no messages during otherwise normal flight
00:26Z 3044 ANTI ICE R WINDOW
00:26Z 561200 R SLIDING WINDOW SENSOR
00:26Z 2600 SMOKE LAVATORY SMOKE
00:27Z 2600 AVIONICS SMOKE
00:28Z 561100 R FIXED WINDOW SENSOR
00:29Z 2200 AUTO FLT FCU 2 FAULT
00:29Z 2700 F/CTL SEC 3 FAULT
In general, the fact that something is a creative work or takes time to create doesn't necessarily make it copyrightable. For a creative work, any functional aspects of that design are supposed to be protected by patents, not copyright. And an insufficiently creative work isn't protected at all, no matter how much time it took to create it.
For example, the courts long ago ruled in Feist Publications, Inc., v. Rural Telephone Service Co. that the difficulty of creating something is not sufficient to make it copyrightable when they declared that a phone book is a non-creative collection of facts. One could reasonably argue that a header file collects the declarations from source code, and that the real creative work is the source code itself. After all, the sole reason for a header file is to consolidate a bunch of declarations into a form that that makes it easier for a compiler to digest. This arguably makes a header no more a creative work than the phone book. That's not arguing that an API shouldn't be copyrightable per se, so much as that a header shouldn't be unless it contains other creative works beyond the declarations.
Also, per 17 U.S.C. section 1302, anything that is "dictated solely by a utilitarian function of the article that embodies it" is not eligible for copyright. The intent of copyright law is to shift responsibility for protecting such creative works into the domain of patent law. So given that there's a strong utilitarian aspect to APIs (because any function has basically exactly one valid declaration, or else your code won't link correctly), if you want to argue that an API should be protected by copyright, you have to come up with a concrete argument of why that API's design is more than just utilitarian in nature. So any creative effort that was focused on making an API easier to use doesn't count towards the creativity requirement for copyright purposes.
The thing is, the existing vaccines aren't even derived from smallpox. They're derived from a related virus that isn't fatal. We don't need smallpox to exist just to produce vaccines unless somebody genetically engineers a modified smallpox virus that doesn't contain any of the same markers as cowpox, monkeypox, or vaccinia. And if somebody does that, the odds are very high that A. having a sample of smallpox won't help in creating the vaccine either, and B. the organization that someday creates that modified virus wouldn't have been able to get their hands on it if we had destroyed all the samples in a timely manner instead of keeping it around just in case we need to engage in biowarfare....
Agreed. In practice, viruses have a tendency to never go away. Just take a look at the people who have been "cured" of ebola. Months or years later, some of them start showing symptoms again, because the virus found a reservoir inside an eyeball or some other random part of the body where the immune system is not as effective.
Also, the claim that smallpox can only infect humans is naïve. It can, in fact, infect other primates. So the fact that it is no longer found in humans does not mean that it can't come back on its own. It is unlikely, but not impossible. In fact, it is highly likely that the initial smallpox epidemics were caused by the virus making its way into humans from some other animal species. If it happened once, it could happen twice....
So the assertions upon which the author built the argument against smallpox are somewhat dubious, IMO. With that said, that doesn't mean that the conclusions are wrong. The important question is whether we can continue to manufacture smallpox vaccines indefinitely without the actual virus. If the answer is yes (and I believe that it is), then destroying the most likely way for the virus to end up spreading among the population does make sense.
Any recurrence of the virus, whether natural or artificial, would either be different from the known smallpox strains in meaningful ways or it wouldn't. If it is different, then the current smallpox virus probably won't be of any real benefit in developing a vaccine for the new variant; they would need samples of the new virus instead. If it isn't different, then the existing vaccine will "just work", and we don't need the current smallpox virus.
Either way, the only plausible future use for smallpox would be as a biological weapon, and IMO, we owe it to future generations to destroy it.
And as I post this, I'm struggling to avoid laughing. Because of a bit of over-editing, that last sentence almost ended with "... and IMO, we owe it to future generations to do so." Yikes!
I can see the job application now:
A mixture? Horrified. An ionically bonded molecule? Not so much.
But thiomersal breaks down into inorganic mercury in the bloodstream, and inorganic mercury exhibits neurotoxicity. Just because a dangerous substance is bound into a compound doesn't mean it isn't dangerous.
Exactly. More to the point, the more configurations (where the definition of "configurations" includes even subtle things like what apps are installed or what preferences somebody has chosen), the greater the odds of at least one person hitting any given serious bug, and the greater the number of people affected by such an unusual bug.
For example, in the early part of the 2000s, Apple made single-digit millions of Macs, and there were probably low double-digit millions in active use. There are now over a billion iOS devices in active use. So if there were a serious bug in both OS X v10.2 (in 2003) and iOS 9.x (today) with identical probabilities of occurring, you'd have seen a hundred affected users of the latter for every one affected user of the former. Something that affects 30 people on iOS today probably wouldn't have even been detected in OS X v10.2 thirteen years ago, because more likely than not, no OS X user would have gone down the affected code path.
Actually, there's one very big reason to trust you: psychology.
As anybody who has ever read about the Stanford Prison Experiment should understand, when you treat people like criminals, they tend to fall into those roles, and when you tell group A to assume that other group B are criminals, group A tend to treat group B as less than human, and vice versa.
The best way to have a work environment where people behave in respectful ways is to treat the employees with respect until they prove that they can't be trusted on an individual basis, and then fire them. The best way to end up with a bunch of sullen workers who have no qualms about stealing office supplies/food/* is to treat them like criminals.
The more complex the system, and the more users a system has, the more critical bugs will escape unnoticed. With that said, this means that there is at least one hardware configuration that they don't have as part of their automated testing pool (I assume that they do have at least "does it boot" automated testing and aren't relying 100% on dogfooding to catch these issues).
On the flip side, it could be that their testing fleet is busy doing tests for the upcoming major release, and that they don't have one for minor software updates like this one, in which case it's the fault of the people who came up with the idiotic "no downgrading" policy. Personally, I blame Scott Forstall. :-D
Actually, those vaccines are required by law to identify whether they contain Thiomersal/thimerosal, though there are some sticky edge cases. And if you ask the doctor and the doctor lies to you, that's probably legally actionable.
Given that we've practiced some form of artificial selection for centuries, it is pretty much safe to say that crossing two organisms that produce edible food will almost invariably result in a new organism that produces edible food. Most of the things that we don't know are ecological, e.g. the risks of creating a monoculture that is susceptible to a specific disease that doesn't exist yet. Those issues are certainly cause for concern, but they're unlikely to be a health issue.
By contrast, when manually editing genes, it wouldn't be entirely implausible for someone to accidentally slip a recessive gene sequence into an apple tree seed that, when present in both chromosomes, would cause the production of cyanide. And then in the second generation that isn't supposed to exist, suddenly you have fruit that look normal, but kill people....
Look, I'm not saying that GMO foods are bad, or that they don't provide significant benefits for humanity, particularly when it comes to creating drought-resistant crops that can survive in areas affected by famine, etc. What I'm saying is that no one has the right to force someone else to take unknown risks without that person's knowledge or consent, and deliberately unlabeled GMO foods do just that.
Humans selecting for specific genes through breeding is not the same thing as genetic modification any more than predators putting selective pressure on a population is—unless, of course, you can show me how I would naturally cause a frog to mate with a corn stalk and produce interesting results.
The thing is, saying that GMO foods are "safe" is nonsensical. That's like saying that cars are safe. That can be true for every car built today, and then someone can resurrect the Pinto design or whatever. The problem with GMO foods is not that they aren't safe, but rather that companies are arbitrarily mucking with genes in ways that we don't fully understand, with results that we don't fully understand, then unleashing them on an unsuspecting public with little or no scientific testing. So the products today might be safe, but the next product might be a disaster waiting to happen, and we might not even know about the damage until suddenly there's a huge uptick in colon cancer rates or heart disease or breast cancer after thirty years that correlates with areas where they consumed a particular GMO crop.
IMO, the public has a right to know when they're part of a giant science experiment, and that's what this is. Any claims to the contrary are disingenuous at best. People have a right to obtain the information required to judge the risks themselves, and to make decisions based on that judgment. Hiding that information prevents them from making an informed decision.
My point is that people have actually mistaken the good pranks for real people and called 911.
I don't know. The bathroom switching prank, if repeated today, would probably have resulted in jail time for conspiracy to commit lewd and indecent acts.
Nor is it illegal to shout "fire" as part of a play. Otherwise, (among others) every firing squad scene would result in criminal prosecution.
Not necessarily. Every year, it seems like somebody in the U.S. decides to do the old "Santa dangling precariously from the chimney" gag. To my knowledge, nobody has ever gone to jail for it, though in some cases, after about the twentieth 911 call, they've asked them to take it down. And in the U.K., there was this gag, where folks staged a fake murder for the Google Street View cameras. The police thought it was funny.
Low-speed consumer rail, for sure. High-speed... probably not. That's why we need high-speed rail sooner rather than later. Otherwise, it will never get built, and we'll continue wasting huge amounts of energy unnecessarily sending passengers 30,000 feet up into the air until we run out of fossil fuels to power them.