Your economics are false because they work if you only count the return on excess solar power production, rather than replacement of grid power. In general a solar system will reduce your daytime power cost. They do this at the full retail price the power company charges. If you can't sell power back to the grid AND you can't store power for night-time use economically, then you lose out on your night-time power costs. But not day-time.
Solar lease has poor economics where it is not possible to sell power to the grid, but that's because solar lease is an expensive way to get solar power. Ownership is better.
I am> promoting Free Software. Just not to the community to whom the words Free Software
are resonant. And any use of Open Source to deprecate Free Software was not done with my countenance and is no longer relevant in any case.
You'll notice that even Bradley Kuhn of the Software Freedom Conservancy, a FSF-aligned organization, uses "FLOSS", which I find grating. But the reasons for not simply using "Free Software" in English are well known.
I hope you're doing well and that this recent spate of nasty fires didn't harm you. My 17-year-old FIRE/EMS student fought the fire in Napa. Lots of smoke at my home.
It's ironic that you want to credit SCO for a cut-down definition of Open Source at the same time you criticize the legitimacy of the Open Source I announced to the world. That's what Caldera became, of course, and we are clear that they bore ill will for our community and are now a bankrupt failure. More interestingly, their attorneys, who took stock in SCO exchange for pursuing their lawsuit against IBM to the final breath, are still pursuing it under that obligation, even though this can bear no fruit other than bankrupting their practices. The IBM lawyers want to make sure that nobody else ever takes the same bargain.
Despite some infrequent use of the two words together before my announcement, "Open Source" is the proper name for a campaign that I first announced to the world and started with the same ESR who is under discussion in this article. And it has a definition that very many people follow.
It would make no sense for me to challenge your use of Martin Espinoza because there were earlier Martin Espinozas and there are more famous ones now.
You can put your configuration under a compilation copyright. It can be argued, however, that most of what they do to enhance security is functional, and thus not subject to copyright under 17 USC 102(b). The copyrighted matter in your program is the artistic choices you make when you have more than one way of doing things. Not every line of your code. Not function definitions and returns, data structures, and anything required for compatibility with something else. Read up on CAI v. Altai to get more of an idea of how this works.
There are several legal issues here. You can't brick the phone preventing installation of a replacement for your software, and you can't prevent 911 calls. Other than that, you could indeed deny access to features by license violators or those who got their phones from license violators.
That said, it bothers me that they misrepresent their system as Open Source (wrong license to be Open Source) and it sounds like they have less than a full understanding of what pieces their license applies to (only the ones they wrote).
CopperheadOS uses the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license as its compilation copyright and as the copyright on their new work. That isn't an Open Source license. It violates rule #6 of the Open Source Definition.
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
CopperheadOS use the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license as their compilation copyright. This is not an Open Source license, thus CopperheadOS is not Open Source.
You are correct that it's not an Open Source license. I do not, however, believe that a binary blob for an android install is a derivative work of the kernel in its entirety. It's an aggregation, like a Linux distribution CD. You can take it back apart. The GPL can be enforced on the GPL components in it and anything that is directly combined with the GPL program. But not just anything on the filesystem.
I'm not so sure. I think the binary blob is an aggregation of multiple works rather than a derivative work of the GPL kernel in its entirety. You can install it and extract the pieces separately.
You can enforce the GPL on the pieces within the blob that are under GPL, and the pieces that are combined to make a single program with the kernel. But not the whole of user-mode, etc.
Only the copyright holder can relicense the software, even if it's under the Apache license. While others can put their license on a work, it is not valid for pieces that they do not own. They can't go to court and enforce rights on the software as if it was under their license and they owned it. They can only enforce their own license terms on the pieces that they actually own.
Anyone with a gate-array development board can design a CPU these days, and there are Open Source designs with Open Microcode. Here is the microcode source for RISC-V.
But just for the the record, Assembler gives you better performance than C and C++.
It hurts me that most programmers will go through their entire career without being able to learn or write microcode.
Obviously, that gets you much closer to what the CPU actually does, and all of the details of its various units, the instruction pipeline and its stages and timing, and the I/O pipeline and its timing.
Writing bit-slice microcode for the old Pixar image computer, I once a whole day to get the last tick out of a loop. All of the code fit on the termial screen, but there was a lot of parallel timing going on. I did that for one relatively general loop, and someone else at Pixar wrote an entire compositing system out of versions of that loop.
Hopefully you can resolve some of the complaints about Go in the next version. But I'm afraid you're going to have to call it something else. Because Edsger Dijkstra says Go 2 Considered Harmful.
This has the potential for a SpaceX engineering project to become a NASA engineering project, and to lose both cost-effectiveness *and* safety.
This is why NASA is paying SpaceX significantly more than SpaceX gets on its cargo missions. There's a pretty big markup for dealing with all of the extra process that comes with NASA manned projects. I can't say this particular one is wrong, though. Having lost its share of astronauts, NASA would like to make sure that the next ones are not victims of a process failure. Every US astronaut who died on a mission, that's Apollo 1 and the two Shuttle accidents, died as a result of process failures.
If the OS were GPL'ed, then the source code would have to be made available upon request. Making the source code available would mitigate much of the concern that the OS is not trustworthy, as in principle third parties could look for flaws and undocumented features.
Sure, the GPL would be better than what there is now. But I think even that would not be good enough. GPL source code would be the start of making a system that users could trust. Besides that, there would have to be an explicit way to turn it off that could be confirmed to work reliably, and I would prefer a way to permanently remove it from the system with confirmation that worked too.
There would be a lot of concern related to the overall security of that system (researchers tell us there are Minix bugs they will be reporting) and what that system is capable of doing for anyone but its owner.
I am not sure I would want anything other than a very minimal system written in some sort of functional language that could be proven correct (and we know how expensive that is to write).
Overall, I think I'd rather just have it out of my system.
First, not all Intel systems that are capable of it actually have the management engine software. Second, the Intel PC motherboard probably does not hold the "largest number of systems" title, that might belong to Android phones. And anyway isn't the fact that MINIX with its BSD/MIT style licensing was used for the most user-hostile system in recent time an indictment of that license? You would not see GPL software used for this, for obvious reasons, and people who use GPL should be proud of that.
Because the next mission will probably feature the 20th first-stage recovery. Which is totally in-f**king-credible if you ask me. And it's really hard to find anything to take them down with at the moment, even though there are folks who seem determined to do so.
There is probably a nitrogen test before the LOX is let in to the engine. But remember that LOX is its oxidizer, and it has to be run with it eventually because the engine can't work without it. And you don't want to test more than one variable at once if you don't have to, so the LOX gets let in without the fuel first. So, this test is essential.
LOX is very nasty stuff and it is prudent to test with it. Suppose you had a vendor issue and you got an organic rubber O-ring in the system rather than one that can deal with LOX? You would find out, destructively, when the LOX came in.
We should also remember that SpaceX had an engine fail destructively on the CRS-1 mission. The design of the rocket contains such a failure in one engine without damaging the others. The rocket had an engine-out capability that can cope with one or more failures. It compensated and completed the mission, achieving all expected parameters on the remaining 8 first-stage engines.
Also, this was a block 5 engine. There are newly designed un-flown parts in that engine, ironically because NASA asked for higher reliability for human missions. For example no more turbopump impeller cracks, which SpaceX had characterized and was tolerating on cargo missions using the older impellers. For something to go wrong during a test of new designs is to be expected.
Slashdot Mirror
Your economics are false because they work if you only count the return on excess solar power production, rather than replacement of grid power. In general a solar system will reduce your daytime power cost. They do this at the full retail price the power company charges. If you can't sell power back to the grid AND you can't store power for night-time use economically, then you lose out on your night-time power costs. But not day-time.
Solar lease has poor economics where it is not possible to sell power to the grid, but that's because solar lease is an expensive way to get solar power. Ownership is better.
I am> promoting Free Software. Just not to the community to whom the words Free Software are resonant. And any use of Open Source to deprecate Free Software was not done with my countenance and is no longer relevant in any case.
You'll notice that even Bradley Kuhn of the Software Freedom Conservancy, a FSF-aligned organization, uses "FLOSS", which I find grating. But the reasons for not simply using "Free Software" in English are well known.
Hi Martin,
I hope you're doing well and that this recent spate of nasty fires didn't harm you. My 17-year-old FIRE/EMS student fought the fire in Napa. Lots of smoke at my home.
It's ironic that you want to credit SCO for a cut-down definition of Open Source at the same time you criticize the legitimacy of the Open Source I announced to the world. That's what Caldera became, of course, and we are clear that they bore ill will for our community and are now a bankrupt failure. More interestingly, their attorneys, who took stock in SCO exchange for pursuing their lawsuit against IBM to the final breath, are still pursuing it under that obligation, even though this can bear no fruit other than bankrupting their practices. The IBM lawyers want to make sure that nobody else ever takes the same bargain.
Despite some infrequent use of the two words together before my announcement, "Open Source" is the proper name for a campaign that I first announced to the world and started with the same ESR who is under discussion in this article. And it has a definition that very many people follow.
It would make no sense for me to challenge your use of Martin Espinoza because there were earlier Martin Espinozas and there are more famous ones now.
That's TLB flushing, not TBL.
You can put your configuration under a compilation copyright. It can be argued, however, that most of what they do to enhance security is functional, and thus not subject to copyright under 17 USC 102(b). The copyrighted matter in your program is the artistic choices you make when you have more than one way of doing things. Not every line of your code. Not function definitions and returns, data structures, and anything required for compatibility with something else. Read up on CAI v. Altai to get more of an idea of how this works.
There are several legal issues here. You can't brick the phone preventing installation of a replacement for your software, and you can't prevent 911 calls. Other than that, you could indeed deny access to features by license violators or those who got their phones from license violators.
That said, it bothers me that they misrepresent their system as Open Source (wrong license to be Open Source) and it sounds like they have less than a full understanding of what pieces their license applies to (only the ones they wrote).
CopperheadOS uses the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license as its compilation copyright and as the copyright on their new work. That isn't an Open Source license. It violates rule #6 of the Open Source Definition.
Commercial use is obviously a field of endeavor.
CopperheadOS use the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license as their compilation copyright. This is not an Open Source license, thus CopperheadOS is not Open Source.
Open Source doesn't allow "no commercial use" terms.
You are correct that it's not an Open Source license. I do not, however, believe that a binary blob for an android install is a derivative work of the kernel in its entirety. It's an aggregation, like a Linux distribution CD. You can take it back apart. The GPL can be enforced on the GPL components in it and anything that is directly combined with the GPL program. But not just anything on the filesystem.
I'm not so sure. I think the binary blob is an aggregation of multiple works rather than a derivative work of the GPL kernel in its entirety. You can install it and extract the pieces separately.
You can enforce the GPL on the pieces within the blob that are under GPL, and the pieces that are combined to make a single program with the kernel. But not the whole of user-mode, etc.
Also, if you sublicense the Apache software, you still only get to enforce the license on the pieces that you own, not the Apache pieces.
Only the copyright holder can relicense the software, even if it's under the Apache license. While others can put their license on a work, it is not valid for pieces that they do not own. They can't go to court and enforce rights on the software as if it was under their license and they owned it. They can only enforce their own license terms on the pieces that they actually own.
Anyone with a gate-array development board can design a CPU these days, and there are Open Source designs with Open Microcode. Here is the microcode source for RISC-V.
It hurts me that most programmers will go through their entire career without being able to learn or write microcode.
Obviously, that gets you much closer to what the CPU actually does, and all of the details of its various units, the instruction pipeline and its stages and timing, and the I/O pipeline and its timing.
Writing bit-slice microcode for the old Pixar image computer, I once a whole day to get the last tick out of a loop. All of the code fit on the termial screen, but there was a lot of parallel timing going on. I did that for one relatively general loop, and someone else at Pixar wrote an entire compositing system out of versions of that loop.
Duff's device. Always my favorite for explaining how broken C was. And I got to work with Duff at Pixar.
Hopefully you can resolve some of the complaints about Go in the next version. But I'm afraid you're going to have to call it something else. Because Edsger Dijkstra says Go 2 Considered Harmful.
This is why NASA is paying SpaceX significantly more than SpaceX gets on its cargo missions. There's a pretty big markup for dealing with all of the extra process that comes with NASA manned projects. I can't say this particular one is wrong, though. Having lost its share of astronauts, NASA would like to make sure that the next ones are not victims of a process failure. Every US astronaut who died on a mission, that's Apollo 1 and the two Shuttle accidents, died as a result of process failures.
Yes. We should put Andy in the hall of fame with the guy who invented stock derivatives. He wasn't responsible for the way others used it, either. :-)
Insert your story of unwitting engineers facilitating people who do really bad stuff here.
Sure, the GPL would be better than what there is now. But I think even that would not be good enough. GPL source code would be the start of making a system that users could trust. Besides that, there would have to be an explicit way to turn it off that could be confirmed to work reliably, and I would prefer a way to permanently remove it from the system with confirmation that worked too.
There would be a lot of concern related to the overall security of that system (researchers tell us there are Minix bugs they will be reporting) and what that system is capable of doing for anyone but its owner.
I am not sure I would want anything other than a very minimal system written in some sort of functional language that could be proven correct (and we know how expensive that is to write).
Overall, I think I'd rather just have it out of my system.
First, not all Intel systems that are capable of it actually have the management engine software. Second, the Intel PC motherboard probably does not hold the "largest number of systems" title, that might belong to Android phones. And anyway isn't the fact that MINIX with its BSD/MIT style licensing was used for the most user-hostile system in recent time an indictment of that license? You would not see GPL software used for this, for obvious reasons, and people who use GPL should be proud of that.
Because the next mission will probably feature the 20th first-stage recovery. Which is totally in-f**king-credible if you ask me. And it's really hard to find anything to take them down with at the moment, even though there are folks who seem determined to do so.
There is probably a nitrogen test before the LOX is let in to the engine. But remember that LOX is its oxidizer, and it has to be run with it eventually because the engine can't work without it. And you don't want to test more than one variable at once if you don't have to, so the LOX gets let in without the fuel first. So, this test is essential.
LOX is very nasty stuff and it is prudent to test with it. Suppose you had a vendor issue and you got an organic rubber O-ring in the system rather than one that can deal with LOX? You would find out, destructively, when the LOX came in.
We should also remember that SpaceX had an engine fail destructively on the CRS-1 mission. The design of the rocket contains such a failure in one engine without damaging the others. The rocket had an engine-out capability that can cope with one or more failures. It compensated and completed the mission, achieving all expected parameters on the remaining 8 first-stage engines.
Also, this was a block 5 engine. There are newly designed un-flown parts in that engine, ironically because NASA asked for higher reliability for human missions. For example no more turbopump impeller cracks, which SpaceX had characterized and was tolerating on cargo missions using the older impellers. For something to go wrong during a test of new designs is to be expected.