Fios was until recently not Title II. The FCC classified it as such, potentially not Verizon. Verizon wanted FIOS private. As for the fees on the bills, they haven't been able to keep that. That's a tax collected by the FCC and used as a subsidy for rural access. It was working well until a few years ago and now is starting to fail as the FCC keeps raising the minimum bandwidth.
You aren't contradicting anything I'm saying. You are talking about something entirely irrelevant, the payment model. Big ISPs are not screwing up broadband access in preventing municipalities from offering it, they are screwing up socialized access. Socialized access has had huge problems remaining viable where it has been tried as costs of management and administration explode. Whether one things those viability issues can be overcome or not has nothing to do with whether fiber gets laid. A socialized ISP needs fiber as much as private ones do. Municipalities are just a big customer.
I don't think you mean copper when we are talking internet. In terms of copper though Verizon and AT&T would love to rid themselves of all their copper. Whenever they get the chance they dump it on less regulated providers who bundle it up for PRI or bonded T1s.
As for fiber no generally it hasn't been paid for. The companies are still paying down their investment in residential internet. And this is happening as the number of subscribers is dropping not increasing meaning they might never pay it down interest adjusted.
Oh just realized you were saying big city vs. medium city. That I'm not sure about. It might be cheaper to do smaller buildings than the very high costs in a big city. I'm talking suburbs, and X-burbs vs. big or medium cities.
You have to get the fiber to them. Even if it costs 10x as much to hit 50-150 apartments there is huge savings both in wiring them up and more importantly getting the fiber to them. For example Verizon spent $23b for the FIOS footprint is has. For NYState where the footprint is suburban that works out to $750 per house to get fiber to them and $600 per house for installation. They can do city apartments much cheaper than that.
Netapp provides performance storage. If you don't want performance and only want part of their solution they can virtualize the software and run on anyone's hardware. You can be down around $12k / mo for 300TB duplicated 1x with their software. Nowhere near $3m.
On a SAN the 16tb limit comes generally from 32 bit SANs the 64 bit SANs wouldn't have it. Plenty of SAN solutions can handle 500tb or 10x that much. So just upgrade. If you only want backup there are plenty of hardware backup devices that handle this. For example exagrid scales to I believe 300tb / hr much less 500tb total. This isn't gigantic in today's world. You just need to have a conversation with your vendor, or an agent. You aren't asking for anything abnormal or challenging.
Sweden and Finland are perfect examples where median population density is quite a bit higher than the USA. Both countries have huge spaces which are very sparsely populated. However for both countries the vast majority of their population is concentrated tightly in narrow areas which are very cheap to wire. So the result is almost all Finns and Swedes can get internet more cheaply.
You really won't find anything like America's population distribution anywhere outside Africa, that's the point of comparison in terms of density, though obviously the per capita income disparity makes a comparison lagging i.e. what they are doing now is similar to what was happening in the USA during the 1990s.
I'm not sure where you are getting this. For repetitive math a CPU will be doing something like 4 instructions per clock cycle while a GPU will be in the low thousands. Also AMD tends to have more parallelism running slower than NVidia so for the right kinds of computations it is even better.
European and most Asian countries have much higher average population densities than the USA. Suburban living / a car culture makes lots of services much more expensive to deliver. Internet is one of those services. Put the 130m American homes into apartments concentrated inside cities with limited numbers of suburbs and heck 10g residential internet might well be reasonable.
That's not the world we live in. In the world we live in, the USA is going to lag Hong Kong forever and it should.
How is someone going to track an ISP in someone's head? Townships are not going to allow some ISP to pull out the 15% most profitable customers so that Comcast or Time Warner pull out and 85% of their township has no internet or all. Which means the contract is going to highly regulated and expensive. Someone is going to have to come in with a credible claim. To do that they are often going to need to provide other utility services cable TV and phone being the most common. Those are both regulated industries.
The business internet market is a much less regulated market and while the quality is much higher, the prices are many times higher. Commercial gigabit connections are generally a few thousands not a few hundred dollars a month. Connection charges can range from say $1500 to $11k, they aren't $99-129.
Smart people are doing a very good job weighing the various interests in networking and putting together compromises that meet most of them. Those dinosaurs are doing a very good job of providing tremendous bandwidth at low cost to 99% of America's 130m households. There is no conspiracy and there are no easy fixes. Government is tremendously supportive to increasing bandwidth almost everywhere. I'm sure there is some corruption but corruption is a lazy excuse for people who have no clue about the economics of the industry to pretend that things could be fixed if only the government got out of the way.
Just to correct the above, Qt is not LGPL. GPL was a solution to the KDE problem. GTK was created while Qt had a non-commercial license. The problem was with KDE that the combination of KDE & Qt created a derived product which Debian Legal believed was illegal for anyone other than KDE to distribute i.e. no redistribution. The GPL license for Qt solved the problem with KDE but didn't solve the problem that KDE desktop couldn't support non-GPL software without Trolltech getting a cut.
Anyone who has a legit copy of the source code may distribute binaries (modified or originals) to any third-party they wish, royalty-free.
They don't want this. They might want anyone with the source code to be able to distribute binaries to other license holders who may not redistribute at all.
If you want to charge then pretty much you want no redistribution. That's the default for copyright. By opening source you are just allowing people to create their own derived works. Of course if a license makes a derived work and wishes to assign you copyright they can and you just create a process for this.
The comments about your goals being close to the late early 1970s and earlier licenses are correct. That's what you are aiming for. Those licenses worked well from people who were mainly selling hardware. Just giving the source without the ability to do much won't encourage much of a community, you might as well just manage this all yourself.
There are more recent examples of something like this being used. Many of the early GPL licenses came from dual usage where GPL was unacceptable to most customers but allowed them to go open source. For example Qt's free license (when they were Trolltech) varied overtime but mostly were restrictive enough that anything that linked to Qt free was unsellable so most shops had to buy Qt commercial. But since Qt was part of the Open Source community groups like KDE did submit patches. If you want to do something similar you might assert that any derived work, i.e. the output becomes public domain for the free version but the commercial version allows you to keep your data private. Of course that depends crucially on you being able to tell what came from your application and your questions was so vague...
Anyway I think you need to be a bit clearer from the customer's perspective what they are getting from the source and from contributing.
Well obviously we are talking about an entirely different world. But assuming things are similar enough that we have mostly the same people doing things that are as close as possible while still being sensible.... we have a pretty good idea what would have happened.
Linus had a kernel in Minix which ran fine on x86 hardware but really didn't take advantage / compensate for the peculiarities of x86 hardware. What Linus started doing was making something like the Minix kernel far closer to hardware, far more valuable for a particular platform. That platform was dominant, but nothing much changes if it isn't. The same process happens and you just have something very close to what NeXT did with Mach to make XNU (XNU is the OSX kernel).
We BTW had almost exactly this situation involving this group a few months later with GCC. With GCC they had excellent cross platform support but it was impractical and slow. They took GCC and made it fast and efficient, enough so that GCC also became practical for other platforms (like PPC).
I don't see how much has to fundamentally change in this alternative history. Freeix/Linix/Linux was able to deal with a unified platform and obviously would have evolved differently if there had't been one but I don't see the dependency asserted above regarding a unified platform.
all I see are statements that it is someone else's problem and that X doesn't do remote anymore anyway.* Wayland developers and supporters have even suggested that networking support be moved to the GUI toolkits. Surely that would result in a fractured feature that works differently on some applications than others and probably not at all on some.
Well yes it does result in a fractured feature. They Wayland people see the fracturing as a plus. By fracturing the GUI toolkits are able to make more intelligent decisions about what to do locally and what to remotely. By fracturing more stuff can be done locally with fewer roundtrips. Pro/Con: Network transparency vs. RDP style remoting is a fair conversation about X11 vs. Wayland. Talking about Wayland not having remoting implying that Wayland applications won't remote isn't fair not accurate. I hope the distinction is clear.
Also... on the To Do list? Wayland is already being pushed in production. This should not happen with basic features still on the "To Do" list.
In production means applications should start supporting Wayland. They need to do what Libre Office did and start working through the bugs. Lots of features are on the todo list. Legacy mature software often gets replaced before its full feature set is replaced. You look at the list of the top 100 features say: better at these 40, same on these 50, worse on these 5 and doesn't do these 5 at all: ready to offer as an option.
I'm not sure if there are any desktop distros defaulting to it but there is Tizen.
The ecosystem isn't ready yet. Where we are is getting the ecosystem ready. It wouldn't shock me if say by 2018 25% of Linux applications have better Wayland versions than they do X11 and so distributions want to start defaulting to X-Server on Wayland rather than X11 running directly on hardware. Maybe it is Gnome 4 / KDE 6 that force the change from option to default but I suspect it is before than. But certainly in 2015 there is no good reason to make it the default.
I do not believe that there has been much respect coming from the pro-Wayland side. The attitude from the developers seems to be.. you are a minority.. you don't matter.
I don't think that's true. I think what's true is: a) Supporters of network transparency don't know what network transparency is b) People who want to remote over a LAN are a minority and their use case for the overwhelming majority of applications should be handled similarly to WAN remoting.
Non-developer Wayland supporters are even worse, accusing people who are concerned about remote display of being Neck Beards that are holding them back from getting 3d video acceleration.
The other side gets to present use cases that X11 doesn't do well as well. There are advantages to splitting application and video buffers for network transparency. There are advantages to unifying application and video buffers for performance. You could let the applications decide but that's fracturing the implementation. You have to make choices. Deciding to help you is deciding to harm others. People who want better games (and BTW I don't game) are making the same argument you are in reverse.
. If the anti-Wayland side seems disrespectful perhaps it should be viewed as a natural response by a community under attack.
Attack by whom? This argument should have been about X's strategy for remoting vs. Windows (RDPs) strategy for remoting. A positive case for X's design over Microsoft's. It was never that. It started immediately with absolutely provably false claims about how X works, that haven't been true since the days of NEC dumb X servers. The attacks came in response to the hysteria.
To me it's not the ability to remote those applications that makes X great. It's the ability to remote the ones that most people would never even think of remoting.
Under the Wayland model, once it is fully developed, most all applications will remote well with the RDP type interface. There may be some that won't and there may be a bit of a patch when remoting gets a bit worse. You might move from 100% in 2015 to 70% in 2020 to 90% in 2025 coverage. However the 70 and 90% will be much more practical over a WAN than X is now.
LAN users are potentially getting a downgrade though I don't think it will be anything horrible rather something which does make things a bit worse. X was built for LAN, moving from something built for desktop with good WAN support... Yes there are minus to the design for some people. There are tradeoffs in engineering. Doing something to help X can frequently hurt Y. Right now WAN and desktop users are hurt badly by the LAN centric design of X11. That's something the anti-Wayland people don't take into account.
X works wonderfully over LAN, that sort of middle latency between desktop and WAN was the use case X it was designed for. The problem with X is with higher latency like one experiences on WANs or taking advantage of the very low latency on desktop.
You didn't mention what desktop you are using is. On OSX if you want to see what others are experiencing play with XCode's Network Link Conditioner. On Linux: Netem / MasterShaper, WaNem or similar product to jack up your latency. Set it to say 150ms and you'll see the problem pretty quickly.
Well obviously in an alternative world where there isn't standardization around the x86 platform Linux's origin needs to change. Low level routines for the various platforms would need to exist. So either you would have cross platform kernels or the distributions exist with different kernels and cross platform standards (i.e. extensions to POSIX) become more important.
The solution for bring displays into a single application in practice isn't going to happen at the window manager level under Wayland. What's going to happen is the Graphical display system will handle it. So let's say you are pulling:
A: KDE application from server 1 B: Gnome application from server 2 C: WX application from server 2
Under X things are complicated. Under Wayland they won't be your local KDE/Gnome and WX will handle the details of their respective applications with Wayland's RDP handling the communications. Then they will render. The compositor can handle multiple windows so they can combine onto your one physical desktop and they can talk to each other. So for example via. your local dbus you will be able to drag and drop from A to B.
I think you are wrong there. With X freed from the burden of supporting high speed local applications including modern GPUs... there is a very good chance that X12 as a network display system could be quite a bit better. Go back to the UNIX way. X12 is the display manager for remote, and while usable locally it is designed for remote.
Slashdot Mirror
Fios was until recently not Title II. The FCC classified it as such, potentially not Verizon. Verizon wanted FIOS private. As for the fees on the bills, they haven't been able to keep that. That's a tax collected by the FCC and used as a subsidy for rural access. It was working well until a few years ago and now is starting to fail as the FCC keeps raising the minimum bandwidth.
You aren't contradicting anything I'm saying. You are talking about something entirely irrelevant, the payment model. Big ISPs are not screwing up broadband access in preventing municipalities from offering it, they are screwing up socialized access. Socialized access has had huge problems remaining viable where it has been tried as costs of management and administration explode. Whether one things those viability issues can be overcome or not has nothing to do with whether fiber gets laid. A socialized ISP needs fiber as much as private ones do. Municipalities are just a big customer.
I don't think you mean copper when we are talking internet. In terms of copper though Verizon and AT&T would love to rid themselves of all their copper. Whenever they get the chance they dump it on less regulated providers who bundle it up for PRI or bonded T1s.
As for fiber no generally it hasn't been paid for. The companies are still paying down their investment in residential internet. And this is happening as the number of subscribers is dropping not increasing meaning they might never pay it down interest adjusted.
What does public broadband have to do with the discussion? This was about cost of providing service not how it should be paid for.
Oh just realized you were saying big city vs. medium city. That I'm not sure about. It might be cheaper to do smaller buildings than the very high costs in a big city. I'm talking suburbs, and X-burbs vs. big or medium cities.
You have to get the fiber to them. Even if it costs 10x as much to hit 50-150 apartments there is huge savings both in wiring them up and more importantly getting the fiber to them. For example Verizon spent $23b for the FIOS footprint is has. For NYState where the footprint is suburban that works out to $750 per house to get fiber to them and $600 per house for installation. They can do city apartments much cheaper than that.
Netapp provides performance storage. If you don't want performance and only want part of their solution they can virtualize the software and run on anyone's hardware. You can be down around $12k / mo for 300TB duplicated 1x with their software. Nowhere near $3m.
On a SAN the 16tb limit comes generally from 32 bit SANs the 64 bit SANs wouldn't have it. Plenty of SAN solutions can handle 500tb or 10x that much. So just upgrade. If you only want backup there are plenty of hardware backup devices that handle this. For example exagrid scales to I believe 300tb / hr much less 500tb total. This isn't gigantic in today's world. You just need to have a conversation with your vendor, or an agent. You aren't asking for anything abnormal or challenging.
Sweden and Finland are perfect examples where median population density is quite a bit higher than the USA. Both countries have huge spaces which are very sparsely populated. However for both countries the vast majority of their population is concentrated tightly in narrow areas which are very cheap to wire. So the result is almost all Finns and Swedes can get internet more cheaply.
You really won't find anything like America's population distribution anywhere outside Africa, that's the point of comparison in terms of density, though obviously the per capita income disparity makes a comparison lagging i.e. what they are doing now is similar to what was happening in the USA during the 1990s.
I'm not sure where you are getting this. For repetitive math a CPU will be doing something like 4 instructions per clock cycle while a GPU will be in the low thousands. Also AMD tends to have more parallelism running slower than NVidia so for the right kinds of computations it is even better.
European and most Asian countries have much higher average population densities than the USA. Suburban living / a car culture makes lots of services much more expensive to deliver. Internet is one of those services. Put the 130m American homes into apartments concentrated inside cities with limited numbers of suburbs and heck 10g residential internet might well be reasonable.
That's not the world we live in. In the world we live in, the USA is going to lag Hong Kong forever and it should.
Yes it does. You are case (b).
How is someone going to track an ISP in someone's head? Townships are not going to allow some ISP to pull out the 15% most profitable customers so that Comcast or Time Warner pull out and 85% of their township has no internet or all. Which means the contract is going to highly regulated and expensive. Someone is going to have to come in with a credible claim. To do that they are often going to need to provide other utility services cable TV and phone being the most common. Those are both regulated industries.
The business internet market is a much less regulated market and while the quality is much higher, the prices are many times higher. Commercial gigabit connections are generally a few thousands not a few hundred dollars a month. Connection charges can range from say $1500 to $11k, they aren't $99-129.
Smart people are doing a very good job weighing the various interests in networking and putting together compromises that meet most of them. Those dinosaurs are doing a very good job of providing tremendous bandwidth at low cost to 99% of America's 130m households. There is no conspiracy and there are no easy fixes. Government is tremendously supportive to increasing bandwidth almost everywhere. I'm sure there is some corruption but corruption is a lazy excuse for people who have no clue about the economics of the industry to pretend that things could be fixed if only the government got out of the way.
You are many years out of date. Not remotely true anymore.
The first sentence should read "Qt is not GPL it is LGPL".
Just to correct the above, Qt is not LGPL. GPL was a solution to the KDE problem. GTK was created while Qt had a non-commercial license. The problem was with KDE that the combination of KDE & Qt created a derived product which Debian Legal believed was illegal for anyone other than KDE to distribute i.e. no redistribution. The GPL license for Qt solved the problem with KDE but didn't solve the problem that KDE desktop couldn't support non-GPL software without Trolltech getting a cut.
They don't want this. They might want anyone with the source code to be able to distribute binaries to other license holders who may not redistribute at all.
If you want to charge then pretty much you want no redistribution. That's the default for copyright. By opening source you are just allowing people to create their own derived works. Of course if a license makes a derived work and wishes to assign you copyright they can and you just create a process for this.
The comments about your goals being close to the late early 1970s and earlier licenses are correct. That's what you are aiming for. Those licenses worked well from people who were mainly selling hardware. Just giving the source without the ability to do much won't encourage much of a community, you might as well just manage this all yourself.
There are more recent examples of something like this being used. Many of the early GPL licenses came from dual usage where GPL was unacceptable to most customers but allowed them to go open source. For example Qt's free license (when they were Trolltech) varied overtime but mostly were restrictive enough that anything that linked to Qt free was unsellable so most shops had to buy Qt commercial. But since Qt was part of the Open Source community groups like KDE did submit patches. If you want to do something similar you might assert that any derived work, i.e. the output becomes public domain for the free version but the commercial version allows you to keep your data private. Of course that depends crucially on you being able to tell what came from your application and your questions was so vague...
Anyway I think you need to be a bit clearer from the customer's perspective what they are getting from the source and from contributing.
Well obviously we are talking about an entirely different world. But assuming things are similar enough that we have mostly the same people doing things that are as close as possible while still being sensible .... we have a pretty good idea what would have happened.
Linus had a kernel in Minix which ran fine on x86 hardware but really didn't take advantage / compensate for the peculiarities of x86 hardware. What Linus started doing was making something like the Minix kernel far closer to hardware, far more valuable for a particular platform. That platform was dominant, but nothing much changes if it isn't. The same process happens and you just have something very close to what NeXT did with Mach to make XNU (XNU is the OSX kernel).
We BTW had almost exactly this situation involving this group a few months later with GCC. With GCC they had excellent cross platform support but it was impractical and slow. They took GCC and made it fast and efficient, enough so that GCC also became practical for other platforms (like PPC).
I don't see how much has to fundamentally change in this alternative history. Freeix/Linix/Linux was able to deal with a unified platform and obviously would have evolved differently if there had't been one but I don't see the dependency asserted above regarding a unified platform.
Well yes it does result in a fractured feature. They Wayland people see the fracturing as a plus. By fracturing the GUI toolkits are able to make more intelligent decisions about what to do locally and what to remotely. By fracturing more stuff can be done locally with fewer roundtrips.
Pro/Con: Network transparency vs. RDP style remoting
is a fair conversation about X11 vs. Wayland. Talking about Wayland not having remoting implying that Wayland applications won't remote isn't fair not accurate. I hope the distinction is clear.
In production means applications should start supporting Wayland. They need to do what Libre Office did and start working through the bugs. Lots of features are on the todo list. Legacy mature software often gets replaced before its full feature set is replaced. You look at the list of the top 100 features say: better at these 40, same on these 50, worse on these 5 and doesn't do these 5 at all: ready to offer as an option.
The ecosystem isn't ready yet. Where we are is getting the ecosystem ready. It wouldn't shock me if say by 2018 25% of Linux applications have better Wayland versions than they do X11 and so distributions want to start defaulting to X-Server on Wayland rather than X11 running directly on hardware. Maybe it is Gnome 4 / KDE 6 that force the change from option to default but I suspect it is before than. But certainly in 2015 there is no good reason to make it the default.
I don't think that's true. I think what's true is:
a) Supporters of network transparency don't know what network transparency is
b) People who want to remote over a LAN are a minority and their use case for the overwhelming majority of applications should be handled similarly to WAN remoting.
The other side gets to present use cases that X11 doesn't do well as well. There are advantages to splitting application and video buffers for network transparency. There are advantages to unifying application and video buffers for performance. You could let the applications decide but that's fracturing the implementation. You have to make choices. Deciding to help you is deciding to harm others. People who want better games (and BTW I don't game) are making the same argument you are in reverse.
Attack by whom? This argument should have been about X's strategy for remoting vs. Windows (RDPs) strategy for remoting. A positive case for X's design over Microsoft's. It was never that. It started immediately with absolutely provably false claims about how X works, that haven't been true since the days of NEC dumb X servers. The attacks came in response to the hysteria.
Under the Wayland model, once it is fully developed, most all applications will remote well with the RDP type interface. There may be some that won't and there may be a bit of a patch when remoting gets a bit worse. You might move from 100% in 2015 to 70% in 2020 to 90% in 2025 coverage. However the 70 and 90% will be much more practical over a WAN than X is now.
LAN users are potentially getting a downgrade though I don't think it will be anything horrible rather something which does make things a bit worse. X was built for LAN, moving from something built for desktop with good WAN support ... Yes there are minus to the design for some people. There are tradeoffs in engineering. Doing something to help X can frequently hurt Y. Right now WAN and desktop users are hurt badly by the LAN centric design of X11. That's something the anti-Wayland people don't take into account.
X works wonderfully over LAN, that sort of middle latency between desktop and WAN was the use case X it was designed for. The problem with X is with higher latency like one experiences on WANs or taking advantage of the very low latency on desktop.
You didn't mention what desktop you are using is. On OSX if you want to see what others are experiencing play with XCode's Network Link Conditioner. On Linux: Netem / MasterShaper, WaNem or similar product to jack up your latency. Set it to say 150ms and you'll see the problem pretty quickly.
Well obviously in an alternative world where there isn't standardization around the x86 platform Linux's origin needs to change. Low level routines for the various platforms would need to exist. So either you would have cross platform kernels or the distributions exist with different kernels and cross platform standards (i.e. extensions to POSIX) become more important.
The solution for bring displays into a single application in practice isn't going to happen at the window manager level under Wayland. What's going to happen is the Graphical display system will handle it. So let's say you are pulling:
A: KDE application from server 1
B: Gnome application from server 2
C: WX application from server 2
Under X things are complicated. Under Wayland they won't be your local KDE/Gnome and WX will handle the details of their respective applications with Wayland's RDP handling the communications. Then they will render. The compositor can handle multiple windows so they can combine onto your one physical desktop and they can talk to each other. So for example via. your local dbus you will be able to drag and drop from A to B.
I think you are wrong there. With X freed from the burden of supporting high speed local applications including modern GPUs... there is a very good chance that X12 as a network display system could be quite a bit better. Go back to the UNIX way. X12 is the display manager for remote, and while usable locally it is designed for remote.