Actually, U.S. copyright was originally 14 years with the option to renew for an additional 14 years. We copied our copyright act from the Statute of Anne in the UK, which also was 14 + 14. The duration of copyright was never just 14 years unless the author failed to renew the copyright or died before he or she could renew it. You're advocating reducing the duration of copyright to almost 30% less than the shortest it ever was in the entire history of copyright as we know it.
That's the other reason I suggested 30 years. 28 years is a weird number.
If you look at Power or Sparc instead of x86, you'll find similar results. If anything, those RISC chips are probably even more power inefficient, as they were designed for customers who demanded top of the line performance and were willing to pay a lot for it.
I would argue that PowerPC itself is a counterexample. It's very close to being Power (and the 601 and 970 are Power, for all intents and purposes, IIRC), and they definitely produced amazing amounts of horsepower per watt relative to other hardware available at the time. The biggest problem there, IMO, was that they optimized for floating point performance, which turned out to make for amazing graphics and audio crunching, but a very sluggish UI.
1. Photos of art can't be copyrighted, the art itself may be subject to copyright.
As a rule, that is already the case. Photos of art generally can't be copyrighted, assuming the intent of the photo is to reproduce the art. It is possible to create a copyrightable work by incorporating a piece of art into a photo in some interesting way (e.g. putting it on an easel and standing a mime next to it in the same pose as the painting's subject), but such a copyright does not affect the copyright of the original art, nor the lack of copyright for any photos that are just reproductions.
That's a very bad idea. Some works take more than 14 years to author, and you'd have the copyright expiring on the first parts before the work is even finished.
Copyright should be 30 years from the date of publication; the date of creation is irrelevant. For unpublished works, the copyright countdown should toll until the end of a five year grace period after the author's death, to allow the heirs time to publish them. At the end of that grace period, the 30-year copyright period should start even if the work has not been published.
For works of corporate authorship, it should be 30 years from publication or 45 years from creation, whichever is shorter, i.e. there should be a maximum of fifteen years from the date of creation to the date of publication during which the copyright countdown is tolled, after which it starts to count down whether the work is published or not.
Here's the logic behind a thirty-year period: The purpose of copyright is to promote the creation of new works. For works of corporate authorship, the copyright duration is completely irrelevant; all the money gets made in the first two or three years anyway, after which it is generally a paperweight. But for works of individual authorship by people who aren't incredibly famous already, it can take many years to start bringing in any real income from your early works. And although the argument could be made that this forces authors to write more works because the old works become worthless, the reality is that knowing you won't ever make money from your first several works would likely mean that many fewer authors would bother to start writing in the first place.
Also, I would suggest that the copyright period be split in half, with a renewal requirement at the midpoint. The cost of renewal should be proportional to the income that the creator has received from the work—say 5% of gross revenue to date, or perhaps 10%. Continuing to keep a popular work under copyright clearly diminishes the public domain considerably, so it should cost considerably more to continue to protect such a work than a work that nobody has ever heard of. The revenue from the popular works copyright tax should fund federal and state grants for creative and arts education in our public schools — music, art, dance, theater, creative writing, etc.
RISC is a solution looking for a problem at this point. While you dont need a complicated decoder on RISC, If you want to perform as well as x86 while being RISCy then you need more instruction fetch bandwidth going into the decoder than x86 needs. Its a tradeoff that does not favor RISC, which is why it lost. RISC was winning up until the moment that CPU's went super-scaler, at which point the instruction fetch shortcoming becomes a losing burden.
Not at all true. RISC didn't lose. PowerPC lost because Apple didn't have the marketshare to be worth IBM's time. IBM wanted to focus on building hardware for gaming consoles where they thought they could get better volume, and didn't want to spend the R&D effort to build a version of the G5 that could thermally survive in a laptop. The gaming console designs mostly paired lots of DSP hardware with a really minimal (603e-quality) main core, so those designs were unsuitable for Apple's needs.
But RISC itself has basically won at this point. The most popular CPU architecture on the planet, by a large margin, is ARM, which is RISC. There are on the order of 250 times as many ARM chips built every year as x86/x86-64 chips from AMD and Intel combined. Pretty much every cell phone out there uses the ARM ISA, and more and more tablets are switching to ARM every year. Why? Because CISC doesn't scale nearly as well as RISC in terms of CPU horsepower per unit heat/power, which is the most critical thing for mobile devices, laptops, etc.
I expect CISC to be basically dead in twenty years, and possibly sooner.
They would still have to invest in an Android and Windows Client, at the very least, and the traffic would have to traverse their network and servers, even from the Android and Windows Clients.
Only if they were going between an iOS user and an Android or Windows user. Android-to-Android would hit Google's server exclusively. And if it is going between an iOS user and a non-iOS user, Apple's systems *should* be involved.
And we aren't talking about SMS/MMS messages. This is streaming audio/video at at least 100 kbps. Not insignificant when multiplied by a zillion Android/Windows users.
As I understand it, Facetime does not usually use a relay server. They redesigned the peer-to-peer system in iOS 7 to work around that patent. When it does, it goes through Akamai's servers, not Apple's servers, and presumably the bandwidth bill for that service could be paid proportionally based on the platform of the endpoints (iOS to iOS = Apple, Android to iOS = 50/50, etc.). Or they could choose which company's Akamai server to hit based on the platform of the originator and assume that it will all average out.
Facetime as it currently stands, is of little use non-Apple users as there are plenty of similar alternatives.
It is of little use to most Apple users, too, because it requires both parties to have an iPhone. Statistically, only a little less than half of an iOS user's calls can use Facetime, and on average, less than one fifth of all possible calls have that option (43% * 43%). By contrast, everybody can download Facebook, sign up for a free account, so 100% of all possible calls have that option (ignoring government blocking or whatever).
Yeah. At least in the U.S., Liqued-fuel rockets mostly use Hydrazine (N2H4) for fuel these days, and SRBs mostly use ammonium perchlorate, aluminum powder, and iron oxide. There's a little bit of a carbon-based polymer used as a binder, and it does burn and release a little bit of energy, but it isn't the primary fuel by any means.
The second law of thermodynamics applies to closed systems. The sun exists: Earth is NOT a closed system. I can't speak to the paper's analysis of power sources, but solar and similar sources can provide for recapturing the carbon involved.
It still wouldn't be producing energy, just capturing it and storing it. That said, if we run out of oil before we fully switch to electric cars, this could be one way to turn solar power into gasoline to run all the old cars. As an electric car owner, I'm not really convinced that doing so is necessary, nor convinced that we'll run out of oil before all but a handful of classic cars are long since dead and rusted, but still....
The dollar price is a poor metric. We should really be looking at energy requirements, especially the ratio between energy produced per ton of CO2, and the energy required to pull it back from the air.
This. Without violating one or both of the laws of thermodynamics, it seems almost certain that any sort of sequestration cannot produce more energy in the form of fuel than it uses as input. After all, you're going from a state that has already reacted with oxygen to a state that will release energy when it burns in oxygen, which means that you have to add energy to get it back to such a high-energy state.
So where is all of that energy going to come from? My best guess would be burning fossil fuels. And thus, the cycle of infeasibility is complete. Either that or this sequestration will consume something else that is in a high-energy state and produce something else in a low-energy state, in which case we can do this, but only until we run out of the required reactant. I'm not holding my breath on that one, though.
Of course, if we somehow manage to get to a point where we can produce all of our energy needs without burning fossil fuels, then I suppose sequestering CO2 into gasoline might become feasible. Then again, if we get to that point, we won't need this technique, because plants will take care of reducing the CO2 for us, and we won't need the fuel that results from it. So I'm failing to see how such a solution could ever be practical or economically viable in any sane universe.
Then again, the theory that CO2 isn't a problem seems to be supported by the U.S. right-wing political establishment, and they have given us a President who seems to think that he is above the law, so maybe he's above the laws of thermodynamics, too.
*shrugs*
Skims paper
Holy crap. I was right. They are talking about burning fossil fuels to make fossil fuels. *sobs uncontrollably* But I don't see anything about producing fuel in the actual article, beyond a passing mention that if someone wanted to come up with a way to create fossil fuels in a carbon-neutral way, they would need to start with carbon. As far as this paper is concerned, they're sticking it in a tank, which is a lot more plausible than doing something useful with it.
The big problem, then, is that there's not likely to ever be any monetary upside to capturing the carbon, and if you do it with natural gas, you only capture about twice as much CO2 as you put out. About 56.1 kg of CO2 are emitted for every gigajoule of CO2 that you burn. If powered by natural gas, this design burns 8.81 GJ of nat gas per metric ton sequestered. That's almost half a metric ton of CO2 emitted per ton of CO2 sequestered, plus about 202 kg of H2O, for a grand total of 696 kg of greenhouse gases for every 1000 sequestered, or only about 44% more sequestration by mass than you emit to produce the power.
And in the end, you have a bunch of tanks of CO2 that nobody wants. Also, this is a net consumer of water (because some of it evaporates). Want to know what's even more precious than energy these days? Fresh water.
I just don't see it, unless they can find a way to turn it into carbon credits or something.
AFAIK, part of it is cost, and part of it is load balancing.
Cost-wise, an entire neighborhood gets only one or two phases, which reduces the number of wires running through the entire neighborhood from four to two or three. Halving the number of wires represents a decent savings. And also, the transformers are much cheaper, because the building transformers only have to provide one phase at 240VAC instead of three.
As for load-balancing, most houses really only need one phase, and would end up unevenly using the various phases if they had access to them. By giving houses only a single phase, you can keep the usage roughly balanced (over a sufficiently large area) by putting one-third of the homes on each phase. Similarly, most businesses and apartment complexes really can get by with two phases, so they do the same thing there. I'm not sure how much this matters in the grand scheme of things, but at least it gives the illusion of control.
I would have expected it to oxidize the iron on the planet's surface (and everything else) until after billions of years, there wouldn't be much free oxygen left, but apparently, if a planet has enough titanium oxide, that might not be the case.
It seems like 'forget the credential and prompt the user to re-enter it' is the right thing to do. Repeating the request to the server with the same credential would just be a DOS.
Prompt the user to re-enter the credential, but leave the username (which is always hard to type) there so that the user can change change it if it is wrong, or can click the "Next" button if it isn't. Similarly, Fill the password field with a series of dots, and clear the dots when you tap on it (or even better, actually populate it with the password so that if the user just typed an extra character at the end, he/she can delete it). Again, the user can just tap the "next" button to resend the same credential if the user is certain that the password is correct.
Forcing the user to re-enter anything by hand on a phone is a bad bug.
Netflix is far from alone in this design defect, though; the Tesla app also apparently has this problem, forcing you to type your password every so often for no obvious reason (which in the case of random, machine-generated passwords means switching to Settings, digging into the passwords, copying it to your clipboard, and pasting it into the app — not a very user-friendly workflow).
We tried to hang one in a time cube once, but it turned out that the day really is split into four days, and the guy just ended up in one of the other three.
Yeah, if this is the best feature of the new OS, then they really have run out of ideas.
That said, I'll be happy when Netflix fixes the bug in their iOS app where, when their servers cough up a hairball and start rejecting all logins, the app promptly forgets your username and your password, forcing you to key it all in by hand again. Not that this feature will help with that at all, of course.
Holy crap! I just looked at GNU tar's version history. The docs have said that it skips ".." members since IIRC the late 1990s, but apparently it never actually worked, and they just fixed it in 2016!
GNU tar rejects '..' path parts automatically, as does FreeBSD's tar. Does anybody actually still use cpio, other than for extracting the guts of really old OS X installer packages (pre-xar)?
Either way, I can't quite decide who to blame:
App developers for rolling their own code when existing libraries exist.
Sun/Oracle for not making it so trivial to integrate C code that nobody would try to write their own implementation for something as ugly as ZIP.
Open source and free software advocates for license terms that make people afraid to reuse code that works.
Lawyers, because.
In any case, I don't allow any.Net or Java code anywhere near my computers, so I don't care even slightly. All the C implementations have been secure for decades.
The article mentioned that the patient happened to have enough of the T cells that could go into her breast cell tumors/metastases (most can't), so they could extract those cells, tweak and amplify them. (again, another tumor type factor).
There are a lot of factors at play there, including how far gone your immune system is when you start the immune therapy (chemo tends to seriously weaken it) and whether there are bacterial colonies masking the tumor from your immune system (e.g. Fusobacterium nucleatum).
Slashdot Mirror
Actually, U.S. copyright was originally 14 years with the option to renew for an additional 14 years. We copied our copyright act from the Statute of Anne in the UK, which also was 14 + 14. The duration of copyright was never just 14 years unless the author failed to renew the copyright or died before he or she could renew it. You're advocating reducing the duration of copyright to almost 30% less than the shortest it ever was in the entire history of copyright as we know it.
That's the other reason I suggested 30 years. 28 years is a weird number.
I would argue that PowerPC itself is a counterexample. It's very close to being Power (and the 601 and 970 are Power, for all intents and purposes, IIRC), and they definitely produced amazing amounts of horsepower per watt relative to other hardware available at the time. The biggest problem there, IMO, was that they optimized for floating point performance, which turned out to make for amazing graphics and audio crunching, but a very sluggish UI.
As a rule, that is already the case. Photos of art generally can't be copyrighted, assuming the intent of the photo is to reproduce the art. It is possible to create a copyrightable work by incorporating a piece of art into a photo in some interesting way (e.g. putting it on an easel and standing a mime next to it in the same pose as the painting's subject), but such a copyright does not affect the copyright of the original art, nor the lack of copyright for any photos that are just reproductions.
That's a very bad idea. Some works take more than 14 years to author, and you'd have the copyright expiring on the first parts before the work is even finished.
Copyright should be 30 years from the date of publication; the date of creation is irrelevant. For unpublished works, the copyright countdown should toll until the end of a five year grace period after the author's death, to allow the heirs time to publish them. At the end of that grace period, the 30-year copyright period should start even if the work has not been published.
For works of corporate authorship, it should be 30 years from publication or 45 years from creation, whichever is shorter, i.e. there should be a maximum of fifteen years from the date of creation to the date of publication during which the copyright countdown is tolled, after which it starts to count down whether the work is published or not.
Here's the logic behind a thirty-year period: The purpose of copyright is to promote the creation of new works. For works of corporate authorship, the copyright duration is completely irrelevant; all the money gets made in the first two or three years anyway, after which it is generally a paperweight. But for works of individual authorship by people who aren't incredibly famous already, it can take many years to start bringing in any real income from your early works. And although the argument could be made that this forces authors to write more works because the old works become worthless, the reality is that knowing you won't ever make money from your first several works would likely mean that many fewer authors would bother to start writing in the first place.
Also, I would suggest that the copyright period be split in half, with a renewal requirement at the midpoint. The cost of renewal should be proportional to the income that the creator has received from the work—say 5% of gross revenue to date, or perhaps 10%. Continuing to keep a popular work under copyright clearly diminishes the public domain considerably, so it should cost considerably more to continue to protect such a work than a work that nobody has ever heard of. The revenue from the popular works copyright tax should fund federal and state grants for creative and arts education in our public schools — music, art, dance, theater, creative writing, etc.
Not at all true. RISC didn't lose. PowerPC lost because Apple didn't have the marketshare to be worth IBM's time. IBM wanted to focus on building hardware for gaming consoles where they thought they could get better volume, and didn't want to spend the R&D effort to build a version of the G5 that could thermally survive in a laptop. The gaming console designs mostly paired lots of DSP hardware with a really minimal (603e-quality) main core, so those designs were unsuitable for Apple's needs.
But RISC itself has basically won at this point. The most popular CPU architecture on the planet, by a large margin, is ARM, which is RISC. There are on the order of 250 times as many ARM chips built every year as x86/x86-64 chips from AMD and Intel combined. Pretty much every cell phone out there uses the ARM ISA, and more and more tablets are switching to ARM every year. Why? Because CISC doesn't scale nearly as well as RISC in terms of CPU horsepower per unit heat/power, which is the most critical thing for mobile devices, laptops, etc.
I expect CISC to be basically dead in twenty years, and possibly sooner.
No, but all those NOx emissions could one day be sequestered to provide nitrogen to make hydrazine. :-D
Only if they were going between an iOS user and an Android or Windows user. Android-to-Android would hit Google's server exclusively. And if it is going between an iOS user and a non-iOS user, Apple's systems *should* be involved.
As I understand it, Facetime does not usually use a relay server. They redesigned the peer-to-peer system in iOS 7 to work around that patent. When it does, it goes through Akamai's servers, not Apple's servers, and presumably the bandwidth bill for that service could be paid proportionally based on the platform of the endpoints (iOS to iOS = Apple, Android to iOS = 50/50, etc.). Or they could choose which company's Akamai server to hit based on the platform of the originator and assume that it will all average out.
It is of little use to most Apple users, too, because it requires both parties to have an iPhone. Statistically, only a little less than half of an iOS user's calls can use Facetime, and on average, less than one fifth of all possible calls have that option (43% * 43%). By contrast, everybody can download Facebook, sign up for a free account, so 100% of all possible calls have that option (ignoring government blocking or whatever).
And it will let you talk to an entire 43% of the people you want to invite into the chat. Yay!
Err... Android users.
They could certainly set up a federated system so that Apple users use their servers and Android servers use Google's servers.
Yeah. At least in the U.S., Liqued-fuel rockets mostly use Hydrazine (N2H4) for fuel these days, and SRBs mostly use ammonium perchlorate, aluminum powder, and iron oxide. There's a little bit of a carbon-based polymer used as a binder, and it does burn and release a little bit of energy, but it isn't the primary fuel by any means.
It still wouldn't be producing energy, just capturing it and storing it. That said, if we run out of oil before we fully switch to electric cars, this could be one way to turn solar power into gasoline to run all the old cars. As an electric car owner, I'm not really convinced that doing so is necessary, nor convinced that we'll run out of oil before all but a handful of classic cars are long since dead and rusted, but still....
You can do that with dual 110VAC connections, too.
This. Without violating one or both of the laws of thermodynamics, it seems almost certain that any sort of sequestration cannot produce more energy in the form of fuel than it uses as input. After all, you're going from a state that has already reacted with oxygen to a state that will release energy when it burns in oxygen, which means that you have to add energy to get it back to such a high-energy state.
So where is all of that energy going to come from? My best guess would be burning fossil fuels. And thus, the cycle of infeasibility is complete. Either that or this sequestration will consume something else that is in a high-energy state and produce something else in a low-energy state, in which case we can do this, but only until we run out of the required reactant. I'm not holding my breath on that one, though.
Of course, if we somehow manage to get to a point where we can produce all of our energy needs without burning fossil fuels, then I suppose sequestering CO2 into gasoline might become feasible. Then again, if we get to that point, we won't need this technique, because plants will take care of reducing the CO2 for us, and we won't need the fuel that results from it. So I'm failing to see how such a solution could ever be practical or economically viable in any sane universe.
Then again, the theory that CO2 isn't a problem seems to be supported by the U.S. right-wing political establishment, and they have given us a President who seems to think that he is above the law, so maybe he's above the laws of thermodynamics, too.
*shrugs*
Skims paper
Holy crap. I was right. They are talking about burning fossil fuels to make fossil fuels. *sobs uncontrollably* But I don't see anything about producing fuel in the actual article, beyond a passing mention that if someone wanted to come up with a way to create fossil fuels in a carbon-neutral way, they would need to start with carbon. As far as this paper is concerned, they're sticking it in a tank, which is a lot more plausible than doing something useful with it.
The big problem, then, is that there's not likely to ever be any monetary upside to capturing the carbon, and if you do it with natural gas, you only capture about twice as much CO2 as you put out. About 56.1 kg of CO2 are emitted for every gigajoule of CO2 that you burn. If powered by natural gas, this design burns 8.81 GJ of nat gas per metric ton sequestered. That's almost half a metric ton of CO2 emitted per ton of CO2 sequestered, plus about 202 kg of H2O, for a grand total of 696 kg of greenhouse gases for every 1000 sequestered, or only about 44% more sequestration by mass than you emit to produce the power.
And in the end, you have a bunch of tanks of CO2 that nobody wants. Also, this is a net consumer of water (because some of it evaporates). Want to know what's even more precious than energy these days? Fresh water.
I just don't see it, unless they can find a way to turn it into carbon credits or something.
AFAIK, part of it is cost, and part of it is load balancing.
Cost-wise, an entire neighborhood gets only one or two phases, which reduces the number of wires running through the entire neighborhood from four to two or three. Halving the number of wires represents a decent savings. And also, the transformers are much cheaper, because the building transformers only have to provide one phase at 240VAC instead of three.
As for load-balancing, most houses really only need one phase, and would end up unevenly using the various phases if they had access to them. By giving houses only a single phase, you can keep the usage roughly balanced (over a sufficiently large area) by putting one-third of the homes on each phase. Similarly, most businesses and apartment complexes really can get by with two phases, so they do the same thing there. I'm not sure how much this matters in the grand scheme of things, but at least it gives the illusion of control.
I would have expected it to oxidize the iron on the planet's surface (and everything else) until after billions of years, there wouldn't be much free oxygen left, but apparently, if a planet has enough titanium oxide, that might not be the case.
That's the power of groupthink. None of us is as dumb as all of us.
Prompt the user to re-enter the credential, but leave the username (which is always hard to type) there so that the user can change change it if it is wrong, or can click the "Next" button if it isn't. Similarly, Fill the password field with a series of dots, and clear the dots when you tap on it (or even better, actually populate it with the password so that if the user just typed an extra character at the end, he/she can delete it). Again, the user can just tap the "next" button to resend the same credential if the user is certain that the password is correct.
Forcing the user to re-enter anything by hand on a phone is a bad bug.
Netflix is far from alone in this design defect, though; the Tesla app also apparently has this problem, forcing you to type your password every so often for no obvious reason (which in the case of random, machine-generated passwords means switching to Settings, digging into the passwords, copying it to your clipboard, and pasting it into the app — not a very user-friendly workflow).
We tried to hang one in a time cube once, but it turned out that the day really is split into four days, and the guy just ended up in one of the other three.
Yeah, if this is the best feature of the new OS, then they really have run out of ideas.
That said, I'll be happy when Netflix fixes the bug in their iOS app where, when their servers cough up a hairball and start rejecting all logins, the app promptly forgets your username and your password, forcing you to key it all in by hand again. Not that this feature will help with that at all, of course.
Holy crap! I just looked at GNU tar's version history. The docs have said that it skips ".." members since IIRC the late 1990s, but apparently it never actually worked, and they just fixed it in 2016!
*redacted swearing*
GNU tar rejects '..' path parts automatically, as does FreeBSD's tar. Does anybody actually still use cpio, other than for extracting the guts of really old OS X installer packages (pre-xar)?
Either way, I can't quite decide who to blame:
In any case, I don't allow any .Net or Java code anywhere near my computers, so I don't care even slightly. All the C implementations have been secure for decades.
There are a lot of factors at play there, including how far gone your immune system is when you start the immune therapy (chemo tends to seriously weaken it) and whether there are bacterial colonies masking the tumor from your immune system (e.g. Fusobacterium nucleatum).
Great for a media center PC, though I'd imagine most folks have moved on to Apple TV by now.