Modern x86 processors decode instructions before they are cached. i.e. the ICache holds fixed-width instructions like a RISC processor.
I'll give you the storage benefit on disk and in RAM but, as the meme goes, memory is now very cheap so the compression is unnecessary.
You are talking about a micro-op cache, and not all x86 processors have one. Sandy Bridge does, but it *also* has a regular old ICache which holds raw instruction bytes. And I'm not talking about disk or RAM, I'm talking about the on chip L1 SRAM. Bigger effective ICache == fewer cache misses == better performance.
This isn't a justification, just stating a feature. The all powerful "add eax, [mem_addr]" is a 2-clock instruction that executes as a "mov secret_reg, [mem_addr]; add eax, secret_reg" anyway. There is no benefit to this beyond the previously mentioned "compression". BTW, those directly-from-memory instructions are only important because the x86 has so few registers and, worst of all, those registers are not truly general purpose (look at mul, div, movsb).
Sandy Bridge and AMD processors since K7 have done it with one micro-op. With renamed registers it's not that difficult to do. And load-op is more useful than just for compensating for lack of GPRs. For example, matrix-multiplication, SHA hashing, basically anything that does processing of a huge stream of data.
This works against you since Atom processors tend to cut back on the big stuff to reduce the die-size. What exactly are you going to do about all the existing software? Or is there a transcoder?
You're basically saying x86 is superior because Intel is desperately trying to get rid of x86 and replace it with a RISC recoding from the inside out. An efficient RISC architecture which can emulate x86 efficiently would work just as well (IA-64 was both crap and had poor emulation).
I was listing reasons that x86 was superior, *or at least on par with*, any given RISC ISA. AVX gives you the same instructions for fewer prefix bytes, and adds an additional register field to allow for 3 opera d encoding (2-src, 1 dest). It's not a wholesale replacement of x86.
I won't argue the concept but I will point out that SP/ESP/RSP is NOT special. The call/push/pop/leave/ret instructions implicitly reference it, yes, but you can emulate the behavior with other instructions to use any register. That's basically calling convention standardization, unless you're referring to the hardware call rewind stack?
That is exactly the problem I'm talking about. When you emulate your stack with a GPR, it looks like you have a long, serial chain of function calls, parameter passing, returns, another call following the first call/ret, etc. x86 processors, by virtue of their dedicated stack pointer register, have had optimizations for years (since the Pentium M) which track the call/ret/push/pop increment and decrements in a sideband structure and don't actually touch the stack pointer register itself. That allows independent, out-of-order execution of independent code sequences that GPR-based stack architectures don't have.
True. Except layering all that crap on top of the existing crap is a problem because Atom (due to the size-proportional-to-power-used problem) inherently makes it uncompetitive, most Atoms don't even have the 64bit mode at all for this reason. If you are suggesting that the Atom chips should just boot straight into EM64T and remove the 16bit instruction set then I'll buy into that.
The die size penalty for supporting the legacy modes and instructions is so minimal compared to the cache sizes and queue sizes of modern processors that it's not worth basing an argument on it.
This is an argument about ARM, not RISC in general. ARM is an architecture that is customised by many licensors, x86 is Intel/AMD. Also, ARM is mostly embedded where 64bit memory addressing is unn
1. Having variable length instructions complicates instruction decoding, which cost die space and cycles (once for actual decoding and once for instructions spanning fetch boundaries). Also several processor architectures save 16-bit instructions (ARM, SH, MIPS, TI C6x off the top of my head), still having access to 16 general purpose registers as x86-64 with its up to 16 byte insns.
Yes, those are the standard arguments against variable length instructions. But both Intel and AMD use extra marker bits to mark the instruction boundaries, which removes the extra-cycles penalty. I'd argue that the extra area with the marker bits is *still* smaller than wasting area on non-compressed instructions. With the cycle penalty gone, now you're just left with a die size argument for the initial decode hardware and the cross-fetch-boundary hardware. I'll argue that that area cost is absolutely minimal. I also named an advantage: increased performance due to higher ICache hit rate for the same ICache size. I'll take that advantage over the die size disadvantage every time.
2. Load-op insns and many others are split up internally in smaller micro-ops. They are about as useful as assembler macros. Load-op insns are also hurting performance - for example on Intel processors load-op are split on two mops, one of which is dispatched to port 2, which means that two load-ops cannot by dispatched on the same cycle, whereas up to three simple ops can can be dispatched in one cycle.
Sandy Bridge and all AMD processors since K7 do it with a single micro-op.
3. AVX is good, having the same style for general purpose insns is better.
Good thing AVX is extensible.
4. Dedicated SP engine is a solution to a problem, which does not exist on common RISC architectures anyway. The dependency, which is eliminated by the stack pointer tracker is the dependency of a push/pop insn on that value of SP, which is a result of a previous push/pop. There's no such dependency if simple moves to/from memory (e.g. `movq %rbx, 10(%rsp)') are used as in typical RISC (or in x86 too). Also ARM (and THUMB) can save/restore multiple registers on stack with a single insn, so no dependency there either.
RISC still needs to maintain a stack pointer/frame pointer register for function calls. This maintenance, which requires using general purpose instructions like add/sub/mov, is what causes the false dependence. You haven't addressed how to remove this dependence in RISC.
5. The advantage of 64-bit address space for an architecture, traditionally targeted at embedded and mobile applications is quite dubious.
ARM has been making a lot of noise about getting into servers. Servers as I understand them today really do want true 64-bit addressing.
Make no mistake, x86-64 CPUs are good because the manufacturing process is good and not because, but despite the ISA.
x86 has no merits, but just age old quirks, which are solved by throwing in a ton of additional logic and gigahertz. x86-64 CPUs are good because x86 CPU designers are pretty smart. I would say that x86 ISA has little impact on the quality of the CPU. Likewise, RISC ISA has little to no impact on the quality of the CPU. See this paper for an example.
I scoured your post for one actual reason why you think x86 is an inferior ISA, but I couldn't find any. I'll give you a couple reasons why it is superior, or at least on par with, any given RISC ISA, on its own merits, not taking into account any backwards compatibility issues:
Variable length instruction encoding makes more efficient use of the instruction cache. It is basically code compression, and as such it gives a larger effective ICache size than a fixed length instruction encoding. Even if you have to add marker bits to determine instruction boundaries, it's still a win or at least a wash.
x86 has load-op instructions. Load-op is a very, very common programming idiom both for hand written assembly and for compiler generated code. ARM and other RISC ISAs require two instructions to accomplish the same thing.
AVX, the new encoding from Intel and AMD, gives you true RISC-like two source, one non-destructive dest instructions.
Dedicated stack pointer register allows for push/pop/call/return optimizations to unlink dependence chains from unrelated functions. With a GPR-based stack, RISC has false dependence problems for similar code sequences that they can't really optimize,
AMD64 got rid of cruft, added more GPRs, and added modern features like PC-relative addressing modes, removing that advantage from RISC too.
ARM's 64 bit extensions were just announced and won't be shipping until 2014. x86 has been 64 bit for 8 years.
x86 should be able to compete quite well with any RISC ISA on its own merits today.
You do realize that people had personal transport before automobiles, right? They had these things called "horses" and "horse-drawn carriages" which they used when they a) wanted to go somewhere that a train didn't run, or b) wanted to go somewhere and 200 other people didn't also want to go to the same place at the same time, or c) wanted to carry more items than a person can realistically carry/wheel. You can also take a cross product of c with a and/or b.
Mass transit can somewhat solve b if you run it frequently enough (but that can be un-economical), but it will never solve a, and it has trouble with c too. Mass transit is good for certain use cases like commuting to work in a dense urban area. It's terrible for errands: dropping one kid off at soccer practice and another kid off at orchestra rehearsal, and then stopping at the pharmacy. I'm sure in a utopian dense VMU urban world, the kid's soccer practice field would be right next to the orchestra rehearsal hall, and across the street would be a CVS or Walgreens, but that's not the world we live in today. And even despite all the yammering about VMU and urban renewal and density and the evils of suburbia and single-use zoning, I argue that there will *still* be a large market for personal transport that mass transit cannot solve.
Oh wow, you want raise an exceedingly pedantic argument. Okay. Specifically for the United States, that legal requirement ensures that two (2) copies are deposited at the LoC for works not printed by the Government Printing Office. With over 300 million residents in the U.S., I would argue that two copies is insufficient to serve the population. Given that, I don't think I need to change my argument in any meaningful way to counter yours.
Also, some libraries have a lot of buying power, and can negotiate for much lower, much more reasonable prices.
Certainly. There is no reason to not pool demand and use that as leverage on price negotiation. Note that in a previous response on this thread, I agreed with another poster than there's no need for one-sale/one-use, and that some degree of one-sale/many-use (with the restrictions akin to what a public library impose) is a good way to go.
The library only has a limited number of copies of the item (remember that they paid for them all and didn't just copy the item). If someone else is using the item when I want to use it, I have to wait. There are other restrictions too, like you must be a resident of the city or surrounding area in order to use that library. I agree that one sale, one user isn't necessary, but maybe one sale, 500 users is reasonable. I bet that is still higher than the ratios when material is pirated. (I just made that number up, so don't ask for a citation, but I think that's a reasonable guess),
You do understand how libraries work, right? Tax dollars are used to *pay* for the items that the library makes available to you. You pay taxes. Thus by the transitive property, you pay for (or helped pay for) the items. It's just a couple of levels of indirection from you directly paying for it yourself.
It's insane to justify not paying for music by using an "RIAA/MPAA rip off artists" argument without some other counterbalancing payment. You do understand math, right? If you pay $0 for your music, even less money goes to the artist.
Maybe you should try to get the artists themselves to not sign a bad deal with the RIAA in the first place, because that's the place where your argument works - not on the consumer side.
and their right to get paid for producing the software.
How does that work? They still very much have that right. You haven't taken it from them. Someone else can still buy the software.
If you obtained the software from someone other than the copyright holder (who presumably would have charged you for it), whomever you obtained it from deprived the copyright holder of their exclusive distribution right. It's not depriving the copyright holder of a "right to get paid" per se, but it's only one step away from that.
I took the original to mean that 80-90% of the cover price of a book has nothing to do with printing OR distribution, not just printing itself.
But even if you disagree with me there, distributing an e-book is not zero cost either. Digital distribution on the scale of what Amazon does requires datacenters, bandwidth, maintenance/operational costs, software devs to continue to write/maintain/enhance the software stacks that manage databases of books, handle payments, etc. Sure, if you want to slop your e-book on your personal webserver and manage that all yourself, go ahead. Or you can hire Amazon to do it for you, for a non-zero cost. Lower than printing? Sure. Zero? Absolutely not.
Please address the following problem that I raised in the initial post:
but it basically requires socializing or communizing (what a dirty word nowadays!!!) the ownership of the automation/technology for everyone to benefit, and I don't see that happening without a revolution of some sort.
Did you forget to read the rest of the post? A revolution is only a party once its over and you have achieved the desired outcome; during it, you might die. I'd rather avoid that.
A rising tide lifts all boats, but only if there are enough boats. What happens when automation removes all the jobs?
We know technology and efficiency remove the need for some jobs, and some people are out of work and have to do something else, but it's improving the standard of living, it's a good thing for society, Luddite fallacy, etc. all that. The thing is, history has shown than up till now, automation and technology may have eliminated some jobs but have created a roughly equal number of other jobs, such that people can still make enough money to support themselves and their families and enjoy this higher standard of living. What happens if automation removes jobs faster than it creates them? Or removes too many jobs all at once? I've read some stuff on post-labor economics, but it basically requires socializing or communizing (what a dirty word nowadays!!!) the ownership of the automation/technology for everyone to benefit, and I don't see that happening without a revolution of some sort.
*The* killer app for super high bandwidth connections is streaming HD video, i.e. live television + on-demand shows/movies. Until people can get all their TV needs met over a dumb, high-bandwidth pipe, they won't bother with it and 8Mbps will be enough.
And the entrenched players (cable/sat companies, studios, networks) aren't doing it. Why should Comcast sell you a dumb 100Mbps pipe for $40/mo? If they did that, they you would watch all live TV and get all channels/shows on-demand via a la carte third parties like Netflix, ESPN, and studios directly, cutting them out of the profit loop. Instead of that, they charge you $150/mo for a "triple play" that includes their own live+on-demand TV service and remain a middleman.
This is why we need to get rid of private ownership of broadband infrastructure and treat it like a utility. The actual content providers then would vie directly for consumer money, or maybe new distributor middlemen would pop up, but either way, prices would go down.
and the money and investors move to banks that will take the risk
Why should money move to another *bank*? If all banks and financial instruments *themselves* started yielding only meager returns, capital will move to more productive economic areas, instead of funding yet-more-exotic derivatives and investment vehicles. This would be a good thing for society. Financial products should only be a second-order service, to allocate risk-willing capital to other productive industries, not to be an investment in and of itself.
No person is a party to an agreement made by his or her ancestors.
This is very true. By default this agreement assumes you are, but it's not written in stone. You are certainly welcome to leave the government if you don't like it.
I believe in universal morality. If murder is wrong for one person then it's wrong for everyone. If theft is wrong for one person then it's wrong for everyone.
Okay. How about contracts? Because that's all the government is. It's a contract, created by the people, of their own free will (by virtue of them staying in the government, not overthrowing it, and not leaving it for a different government, as I said you were free to do above). The contract provides services in exchange for money, like a lot of other things. It's just not between an individual and another individual, or even between and individual and a collective. It's between one collective and another collective.
If you can make up some kind of organization that does not violate the very same moral principles that it claims to enforce upon everybody else then go for it.
Yeah, you're conflating a primary act and a recourse. The government does not murder or steal anything as a primary act. (At least it's not supposed to, I'm not saying any government is perfect). It only does those things as a recourse to a violation of the contract. In your morality, if someone violates the terms of a contract, what do you do about it? Our contract has recourse terms spelled out pretty clearly. Violence is pretty far down the list of recourses, btw.
why it's moral and ethical for one group of people to use violence to enforce their will on another group of people
A group of people established the government of their own will at some point in history. You are either a) a descendant of that very group of people, b) a descendant of someone else who, again of their own will joined that group of people, or c) you yourself, of your own will joined that group of people. It's ethical for that group to enforce their will because they were given that authority by the people themselves.
In fact I just gave you the definition of government. Do you not agree with having a government?
When Verizon markets their network as "4G", I expect it to blow away other 3G networks. It's good that it does, and it's also good for PCMag to verify that it does. As a counterexample, Sprint's 4G network wasn't really much faster than AT&T's 3G network.
If there were such separate legal frameworks, then it would be consistent. But the framework that prevents sharing (copyright) is the same one that enforces sharing (the GPL, or, copyright). You can't argue for relaxed copyright when it comes to music and movies, but strong copyright when it comes to software. Many people on Slashdot argue for the elimination of copyrights for the former. Maybe those aren't the same people that argue for strong copyright for software, or maybe the pro-software-copyright people are for a reduction in length of copyright term (which is certainly reasonable), or some other non-extreme/moderate position. But please read my original post again.
Slashdot Mirror
Modern x86 processors decode instructions before they are cached. i.e. the ICache holds fixed-width instructions like a RISC processor. I'll give you the storage benefit on disk and in RAM but, as the meme goes, memory is now very cheap so the compression is unnecessary.
You are talking about a micro-op cache, and not all x86 processors have one. Sandy Bridge does, but it *also* has a regular old ICache which holds raw instruction bytes. And I'm not talking about disk or RAM, I'm talking about the on chip L1 SRAM. Bigger effective ICache == fewer cache misses == better performance.
This isn't a justification, just stating a feature. The all powerful "add eax, [mem_addr]" is a 2-clock instruction that executes as a "mov secret_reg, [mem_addr]; add eax, secret_reg" anyway. There is no benefit to this beyond the previously mentioned "compression". BTW, those directly-from-memory instructions are only important because the x86 has so few registers and, worst of all, those registers are not truly general purpose (look at mul, div, movsb).
Sandy Bridge and AMD processors since K7 have done it with one micro-op. With renamed registers it's not that difficult to do. And load-op is more useful than just for compensating for lack of GPRs. For example, matrix-multiplication, SHA hashing, basically anything that does processing of a huge stream of data.
This works against you since Atom processors tend to cut back on the big stuff to reduce the die-size. What exactly are you going to do about all the existing software? Or is there a transcoder? You're basically saying x86 is superior because Intel is desperately trying to get rid of x86 and replace it with a RISC recoding from the inside out. An efficient RISC architecture which can emulate x86 efficiently would work just as well (IA-64 was both crap and had poor emulation).
I was listing reasons that x86 was superior, *or at least on par with*, any given RISC ISA. AVX gives you the same instructions for fewer prefix bytes, and adds an additional register field to allow for 3 opera d encoding (2-src, 1 dest). It's not a wholesale replacement of x86.
I won't argue the concept but I will point out that SP/ESP/RSP is NOT special. The call/push/pop/leave/ret instructions implicitly reference it, yes, but you can emulate the behavior with other instructions to use any register. That's basically calling convention standardization, unless you're referring to the hardware call rewind stack?
That is exactly the problem I'm talking about. When you emulate your stack with a GPR, it looks like you have a long, serial chain of function calls, parameter passing, returns, another call following the first call/ret, etc. x86 processors, by virtue of their dedicated stack pointer register, have had optimizations for years (since the Pentium M) which track the call/ret/push/pop increment and decrements in a sideband structure and don't actually touch the stack pointer register itself. That allows independent, out-of-order execution of independent code sequences that GPR-based stack architectures don't have.
True. Except layering all that crap on top of the existing crap is a problem because Atom (due to the size-proportional-to-power-used problem) inherently makes it uncompetitive, most Atoms don't even have the 64bit mode at all for this reason. If you are suggesting that the Atom chips should just boot straight into EM64T and remove the 16bit instruction set then I'll buy into that.
The die size penalty for supporting the legacy modes and instructions is so minimal compared to the cache sizes and queue sizes of modern processors that it's not worth basing an argument on it.
This is an argument about ARM, not RISC in general. ARM is an architecture that is customised by many licensors, x86 is Intel/AMD. Also, ARM is mostly embedded where 64bit memory addressing is unn
1. Having variable length instructions complicates instruction decoding, which cost die space and cycles (once for actual decoding and once for instructions spanning fetch boundaries). Also several processor architectures save 16-bit instructions (ARM, SH, MIPS, TI C6x off the top of my head), still having access to 16 general purpose registers as x86-64 with its up to 16 byte insns.
Yes, those are the standard arguments against variable length instructions. But both Intel and AMD use extra marker bits to mark the instruction boundaries, which removes the extra-cycles penalty. I'd argue that the extra area with the marker bits is *still* smaller than wasting area on non-compressed instructions. With the cycle penalty gone, now you're just left with a die size argument for the initial decode hardware and the cross-fetch-boundary hardware. I'll argue that that area cost is absolutely minimal. I also named an advantage: increased performance due to higher ICache hit rate for the same ICache size. I'll take that advantage over the die size disadvantage every time.
2. Load-op insns and many others are split up internally in smaller micro-ops. They are about as useful as assembler macros. Load-op insns are also hurting performance - for example on Intel processors load-op are split on two mops, one of which is dispatched to port 2, which means that two load-ops cannot by dispatched on the same cycle, whereas up to three simple ops can can be dispatched in one cycle.
Sandy Bridge and all AMD processors since K7 do it with a single micro-op.
3. AVX is good, having the same style for general purpose insns is better.
Good thing AVX is extensible.
4. Dedicated SP engine is a solution to a problem, which does not exist on common RISC architectures anyway. The dependency, which is eliminated by the stack pointer tracker is the dependency of a push/pop insn on that value of SP, which is a result of a previous push/pop. There's no such dependency if simple moves to/from memory (e.g. `movq %rbx, 10(%rsp)') are used as in typical RISC (or in x86 too). Also ARM (and THUMB) can save/restore multiple registers on stack with a single insn, so no dependency there either.
RISC still needs to maintain a stack pointer/frame pointer register for function calls. This maintenance, which requires using general purpose instructions like add/sub/mov, is what causes the false dependence. You haven't addressed how to remove this dependence in RISC.
5. The advantage of 64-bit address space for an architecture, traditionally targeted at embedded and mobile applications is quite dubious.
ARM has been making a lot of noise about getting into servers. Servers as I understand them today really do want true 64-bit addressing.
Make no mistake, x86-64 CPUs are good because the manufacturing process is good and not because, but despite the ISA.
x86 has no merits, but just age old quirks, which are solved by throwing in a ton of additional logic and gigahertz. x86-64 CPUs are good because x86 CPU designers are pretty smart. I would say that x86 ISA has little impact on the quality of the CPU. Likewise, RISC ISA has little to no impact on the quality of the CPU. See this paper for an example.
I scoured your post for one actual reason why you think x86 is an inferior ISA, but I couldn't find any. I'll give you a couple reasons why it is superior, or at least on par with, any given RISC ISA, on its own merits, not taking into account any backwards compatibility issues:
x86 should be able to compete quite well with any RISC ISA on its own merits today.
You do realize that people had personal transport before automobiles, right? They had these things called "horses" and "horse-drawn carriages" which they used when they a) wanted to go somewhere that a train didn't run, or b) wanted to go somewhere and 200 other people didn't also want to go to the same place at the same time, or c) wanted to carry more items than a person can realistically carry/wheel. You can also take a cross product of c with a and/or b.
Mass transit can somewhat solve b if you run it frequently enough (but that can be un-economical), but it will never solve a, and it has trouble with c too. Mass transit is good for certain use cases like commuting to work in a dense urban area. It's terrible for errands: dropping one kid off at soccer practice and another kid off at orchestra rehearsal, and then stopping at the pharmacy. I'm sure in a utopian dense VMU urban world, the kid's soccer practice field would be right next to the orchestra rehearsal hall, and across the street would be a CVS or Walgreens, but that's not the world we live in today. And even despite all the yammering about VMU and urban renewal and density and the evils of suburbia and single-use zoning, I argue that there will *still* be a large market for personal transport that mass transit cannot solve.
http://en.wikipedia.org/wiki/Legal_deposit
Oh wow, you want raise an exceedingly pedantic argument. Okay. Specifically for the United States, that legal requirement ensures that two (2) copies are deposited at the LoC for works not printed by the Government Printing Office. With over 300 million residents in the U.S., I would argue that two copies is insufficient to serve the population. Given that, I don't think I need to change my argument in any meaningful way to counter yours.
Also, some libraries have a lot of buying power, and can negotiate for much lower, much more reasonable prices.
Certainly. There is no reason to not pool demand and use that as leverage on price negotiation. Note that in a previous response on this thread, I agreed with another poster than there's no need for one-sale/one-use, and that some degree of one-sale/many-use (with the restrictions akin to what a public library impose) is a good way to go.
The library only has a limited number of copies of the item (remember that they paid for them all and didn't just copy the item). If someone else is using the item when I want to use it, I have to wait. There are other restrictions too, like you must be a resident of the city or surrounding area in order to use that library. I agree that one sale, one user isn't necessary, but maybe one sale, 500 users is reasonable. I bet that is still higher than the ratios when material is pirated. (I just made that number up, so don't ask for a citation, but I think that's a reasonable guess),
You do understand how libraries work, right? Tax dollars are used to *pay* for the items that the library makes available to you. You pay taxes. Thus by the transitive property, you pay for (or helped pay for) the items. It's just a couple of levels of indirection from you directly paying for it yourself.
So do libel laws. Did you read the article?
Hey mods/metamods, Flamebait is not a disagree mod. This is a statement of fact, thus I fail to see why it would deserve a Flamebait mod.
It's insane to justify not paying for music by using an "RIAA/MPAA rip off artists" argument without some other counterbalancing payment. You do understand math, right? If you pay $0 for your music, even less money goes to the artist.
Maybe you should try to get the artists themselves to not sign a bad deal with the RIAA in the first place, because that's the place where your argument works - not on the consumer side.
So what you're saying is, if enough Swiss people stop paying artists, they will stop producing music?
and their right to get paid for producing the software.
How does that work? They still very much have that right. You haven't taken it from them. Someone else can still buy the software.
If you obtained the software from someone other than the copyright holder (who presumably would have charged you for it), whomever you obtained it from deprived the copyright holder of their exclusive distribution right. It's not depriving the copyright holder of a "right to get paid" per se, but it's only one step away from that.
I took the original to mean that 80-90% of the cover price of a book has nothing to do with printing OR distribution, not just printing itself.
But even if you disagree with me there, distributing an e-book is not zero cost either. Digital distribution on the scale of what Amazon does requires datacenters, bandwidth, maintenance/operational costs, software devs to continue to write/maintain/enhance the software stacks that manage databases of books, handle payments, etc. Sure, if you want to slop your e-book on your personal webserver and manage that all yourself, go ahead. Or you can hire Amazon to do it for you, for a non-zero cost. Lower than printing? Sure. Zero? Absolutely not.
Please address the following problem that I raised in the initial post:
but it basically requires socializing or communizing (what a dirty word nowadays!!!) the ownership of the automation/technology for everyone to benefit, and I don't see that happening without a revolution of some sort.
Did you forget to read the rest of the post? A revolution is only a party once its over and you have achieved the desired outcome; during it, you might die. I'd rather avoid that.
A rising tide lifts all boats, but only if there are enough boats. What happens when automation removes all the jobs?
We know technology and efficiency remove the need for some jobs, and some people are out of work and have to do something else, but it's improving the standard of living, it's a good thing for society, Luddite fallacy, etc. all that. The thing is, history has shown than up till now, automation and technology may have eliminated some jobs but have created a roughly equal number of other jobs, such that people can still make enough money to support themselves and their families and enjoy this higher standard of living. What happens if automation removes jobs faster than it creates them? Or removes too many jobs all at once? I've read some stuff on post-labor economics, but it basically requires socializing or communizing (what a dirty word nowadays!!!) the ownership of the automation/technology for everyone to benefit, and I don't see that happening without a revolution of some sort.
*The* killer app for super high bandwidth connections is streaming HD video, i.e. live television + on-demand shows/movies. Until people can get all their TV needs met over a dumb, high-bandwidth pipe, they won't bother with it and 8Mbps will be enough.
And the entrenched players (cable/sat companies, studios, networks) aren't doing it. Why should Comcast sell you a dumb 100Mbps pipe for $40/mo? If they did that, they you would watch all live TV and get all channels/shows on-demand via a la carte third parties like Netflix, ESPN, and studios directly, cutting them out of the profit loop. Instead of that, they charge you $150/mo for a "triple play" that includes their own live+on-demand TV service and remain a middleman.
This is why we need to get rid of private ownership of broadband infrastructure and treat it like a utility. The actual content providers then would vie directly for consumer money, or maybe new distributor middlemen would pop up, but either way, prices would go down.
and the money and investors move to banks that will take the risk
Why should money move to another *bank*? If all banks and financial instruments *themselves* started yielding only meager returns, capital will move to more productive economic areas, instead of funding yet-more-exotic derivatives and investment vehicles. This would be a good thing for society. Financial products should only be a second-order service, to allocate risk-willing capital to other productive industries, not to be an investment in and of itself.
How would you actually go about recovering your property? What if I won't give it back to you? In other words, what if I stole your property?
You failed to answer what I consider a crucial question about your ideology, so I'll paste it again for reference:
In your morality, if someone violates the terms of a contract, what do you do about it?
No person is a party to an agreement made by his or her ancestors.
This is very true. By default this agreement assumes you are, but it's not written in stone. You are certainly welcome to leave the government if you don't like it.
I believe in universal morality. If murder is wrong for one person then it's wrong for everyone. If theft is wrong for one person then it's wrong for everyone.
Okay. How about contracts? Because that's all the government is. It's a contract, created by the people, of their own free will (by virtue of them staying in the government, not overthrowing it, and not leaving it for a different government, as I said you were free to do above). The contract provides services in exchange for money, like a lot of other things. It's just not between an individual and another individual, or even between and individual and a collective. It's between one collective and another collective.
If you can make up some kind of organization that does not violate the very same moral principles that it claims to enforce upon everybody else then go for it.
Yeah, you're conflating a primary act and a recourse. The government does not murder or steal anything as a primary act. (At least it's not supposed to, I'm not saying any government is perfect). It only does those things as a recourse to a violation of the contract. In your morality, if someone violates the terms of a contract, what do you do about it? Our contract has recourse terms spelled out pretty clearly. Violence is pretty far down the list of recourses, btw.
Seriously?
why it's moral and ethical for one group of people to use violence to enforce their will on another group of people
A group of people established the government of their own will at some point in history. You are either a) a descendant of that very group of people, b) a descendant of someone else who, again of their own will joined that group of people, or c) you yourself, of your own will joined that group of people. It's ethical for that group to enforce their will because they were given that authority by the people themselves.
In fact I just gave you the definition of government. Do you not agree with having a government?
When Verizon markets their network as "4G", I expect it to blow away other 3G networks. It's good that it does, and it's also good for PCMag to verify that it does. As a counterexample, Sprint's 4G network wasn't really much faster than AT&T's 3G network.
This story is precisely what I'm talking about.
If there were such separate legal frameworks, then it would be consistent. But the framework that prevents sharing (copyright) is the same one that enforces sharing (the GPL, or, copyright). You can't argue for relaxed copyright when it comes to music and movies, but strong copyright when it comes to software. Many people on Slashdot argue for the elimination of copyrights for the former. Maybe those aren't the same people that argue for strong copyright for software, or maybe the pro-software-copyright people are for a reduction in length of copyright term (which is certainly reasonable), or some other non-extreme/moderate position. But please read my original post again.