You should be able to run xcompmgr -a (or just xcompmgr -- two different routes to the same effect) and get smooth window drag today on nvidia. EXA will let us do this for open-source drivers as well.
Here's a contradictory example. As a user of MIT and 2-clause BSD binaries, I can redistribute them as I like, and frequently do as part of X/DRI work. However, the FreeBSD is a user and redistributor of RedHat RPMs as part of our linux compatibility, though we don't modify them other than wrapping in our own packaging. But we can't just distribute the binaries, because of the restriction in the GPL that if we do that, we must also guarantee that we can supply the corresponding source. That means that we have to host the SRPMs on our mirrors (though nobody will ever use them -- they'd use current RH sources) or otherwise store them, so that just in case someone demands the source (even after RedHat has stopped distributing htat particular source RPM), we can fulfill the demands of the GPL.
What a waste of time. We have to build infrastructure in our ports system to maintain and populate mirror space for no reason other than GPL restrictions.
1) Rendering to texture at worst consists of manually syncing the accelerator and flushing caches between using something as dst and using it as src. I do that in Xati. I don't see any issues with it.
2) Alpha blending is really cheap. On keith's laptop we just did about a 640x480 movie, semi-transparent, with his little window thumnail program, "uncover," running and displaying that movie transparently over the desktop. CPU usage was at about 40% IIRC, but that's my fault for not implementing some basic hardware suppport (hostdata uploads).
I've also done this on my R128 laptop. Still smooth.
X does not need an "overhaul" in the way the parent is saying, if I am understanding correctly (Xaw is absolutely unrelated, so I'm a bit confused). X.Org just needs real Render acceleration, which means a new acceleration architecture like KAA, but it wouldn't take that long. And when it's done, all these operations become really cheap as someone someone writes the hardware code (~ 1000 lines for all of R100 and R200 in Xati), even on your rage 128, voodoo 3, g400, tnt2, etc. class hardware.
Incidentally, jeffr just came back and applied a couple of significant fixes to ULE, notably the KSE+ULE+PREEMPTION that was the primary reason it was disabled. Now let's hope its speed can be brought up to 4BSD levels for server tasks (assuming that it hasn't got better since the last benchmarking was done, which may not be true), so it can be turned back on and give us back that desktop-interactivity love.
(Parent post was definitely accurate on the reasoning)
Desktop sluggishness is something that gets complained about a lot, and I know I hate the feel we have on the desktop right now. Currently, scheduler work has been focused on 4BSD with server loads, notably mysql. SMP performance with supersmack (mysql test) has gone up something like 50% in the last few months, thanks to netperf and 4BSD scheduler improvements. What would be nice to see is somebody fixing ULE (the new scheduler) both in terms of server performance and fixing those remaining bugs, since it is known to be significantly better in terms of desktop interactivity. However, its author only has sporadic FreeBSD time and others find ULE to be very scary, so it's not getting fixed currently.
However, I do think that we'll see interactivity continually improve at this point, as Giant keeps getting pushed out of more subsystems.
Part of it was that there were problems with ULE and PREEMPTION, which we really hope to have working for the release if possible. But it was also not performing well for some specific tests that are being done (supersmack on mysql, among others). That combined with a few little bugs (load avg reporting) and the author not really being available to work on it, meant that it was decided to move back to 4BSD for the release (and possibly -STABLE), while hopefully getting ULE going well on -CURRENT. ULE has its own set of features -- better interactivity on heavily loaded machines (so nice for your desktop while compiling!) and, as I remember, better algorithms for machines with tons of processes, but its youth menas it's not well-tuned yet for general server use, which is what FreeBSD focuses on.
Integration of the Savage (and Mach64, and VIA) DRI as on-by-default requires that they get fixed for the security requirements that we have accepted for the DRI. All of those drivers currently let any user authorized for DRI read/write arbitrary memory. Meeting those requirements is a lot of work, but it would be great to see someone working on those.
Now, one option, and one I want to look into for the next release, is some "InsecureIsOK" "YES" for those drivers, so we can build and install them by default and users make the choice at runtime. This is slightly different meaning than the Section "DRI" because Section "DRI" authorizes users for the DRI security model, which only allows users to hang the machine. (due to the complexity of hardware, the checking required to avoid hanging is simply too difficult to do for direct rendering, and that's why you have to turn it on for non-root)
Well, I'm working on the hardware acceleration for current hardware that will support *all* the operations currently done by the compositing manager (the program responsible for those shadows). Radeon will do it fine. I'm hoping I'll be able to do it with SiS300. If SiS300 works, it will be worth experimenting with other hardware to see if the tradeoffs in card memory use are worth getting the acceleration (I suspect the answer is "yes").
What keithp is talking about for "things that won't be fast enough with 2d/3d hardware as it exists today," these are experiments for things like correct shadowing underneath translucent windows, which are interesting but not necessary and not likely to be seen in a standard desktop before hardware accelerates it.
Let me say that, as a FreeBSD user, I wish I had the fd.o xserver ported to FreeBSD so I could use it on my desktop, even without acceleration of compositing. I hate the feel of using XFree86 now that I've used the compositing manager even as little as I have for testing drivers. No more delay refreshing windows when dragging them around would be great.
Don't like shadows? Well, you could just axe all that code out of the compositing manager. But I do see cases where translucency will improve the visual experience. It will also force us to implement acceleration we should have been working on doing right long ago in order to speed up antialiased text. I look forward to no longer seeing 30% CPU times in my X server when compiling software.
The kernel sources were updated on 2003-03-09, two days before 4.3.0 hit the ports tree.
I'm not updating drm-kmod because it's annoying to have these open-source, mit-licensed kernel modules outside of the tree. It means that as the port maintainer I have to apply patches to it every time someone changes the kernel API and all the users have to manually update it. If it's in the tree, there's no synchronization problem (except in DRI CVS).
I was a student sysadmin/techie for four years at Franklin High Schoolin Portland, OR, along with a few other students and one hired admin. I also was involved in a student union, and we knew about the funding problems: $20 million in the hole in this budget, if I remember correctly. Another $500,000 will mean even fewer teachers, when we have been losing teachers already.
However, to those of you saying "Just use Linux," I tried. You know what, administering classroom Linux systems is hard. I was working on a X terminal Linux (then FreeBSD) network at Da Vinci middle school for over a year. It had to be X terminals because the little machines couldn't handle it. The staple computer at FHS is the P166 with 16MB RAM from CTL ("Crap Technology for Losers," as it was called), the middle school had some machines even worse. These machines can handle Office or IE on win95. They couldn't handle X with Netscape/Mozilla or StarOffice. With a server running the programs it was almost usable. However, we didn't have automounted floppy drives working, sometimes samba was flakey, sometimes people would have troubles opening netscape (it was _slow_) or something else happened. The teacher I was working with was really interested and excited, but didn't have the proficiency to be a sysadmin. I didn't have the time to be it, after spending my days at Franklin.
A number of teachers at a school can do basic Windows repair, but paid admins rarely stay at a school for more than a couple of years. The warm fuzzies of working for the public schools did not make up for the lack of pay or the crap they had to put up with ("I need you/now/!" or little help messages from teachers like "the box is missing, come fix it [ed. note: that's the computer!]"). Making our computers use Linux would have been with quite a bit of dissatisfaction on the part of the teachers. Existing operating systems needed to be reinstalled about once a year depending on their use, but other than that didn't require much adminning or much knowledge on the part of the users. We few Linux/BSD users didn't have time to teach about CAB to kill frozen X or training people to log out or train other techies to handle linux troubles (we had about 8 mac/windows techies at FHS, with maybe two really proficient in linux/bsd). It really requires a full-time sysadmin, at least for every couple of schools. This does not exist. We used to be special at Franklin because we had a part-time admin. We don't have a dedicated admin at Franklin any more. We were already just scraping by on Mac/Windows maintenance, and I think a Linux or BSD network would be impossible now.
Yes, a lot of people are starving out there, but GM foods are not going to save them, or at least not the ones developed so far. The crop modifications so far have been mostly related to pesticides, either adding pesticides (such as Bt) or adding resistence to pesticides. According to the companies, this will be cheaper for the farmer. However, in a survey of Ohio farmers, those that used GM soybeans instead of unmodified soybeans used less pesticide, but had to pay much more for seeds. Their net cost was almost equal ($144.50/acre instead of $145.75/acre).
The crushing of the small farmer is due to mechanization and competition from big growers. It happened in the US from the 1850s to early 1900s. Farmers without machinery couldn't compete with those with the machines that were ten times as labor-efficient or more. They had to buy the new equipment on credit. When they couldn't pay for the machines, the farms were lost to the bank, then sold off to the big growers, and the process continued.
And of course we do not say that the problem is too many people out there. World Hunger deals with that question. The world produes enough grain alone to provide every person with 3,500 calories a day, far more than any recommended amount. The problem is that people can't buy the products that are available.
For the future, non-GM processes are improving the efficiency of fields all the time, in the case of wheat by using traditional breeding methods to reduce stalk length so that more energy is spent on grain production. As long as the results aren't patented the way GM products have been so far, that would be a far better improvement in the poor farmer's problem, along with world hunger in the future as population increases.
"you don't eat genes." I guess you meant that we don't incorporate genes consumed wholesale into our bodies (eating bread doesn't turn us into wheat).
However, the genes spliced into biotech products can unintentionally create chemicals that are harmful to people. A company (don't have the name stored nearby) spliced some Brazil nut genes into soybeans to increase protein content. It was successful, except that people who have allergies to Brazil nuts were allergic to the new soybeans. It was caught during testing, but many anti-GMO folks fear that the testing is insufficient. The testing required by the FDA is no more rigorous for GMO foods than for other food products.
It is a terribly imperfect science. Many more genes are required to splice than just the one desired trait. In a test on mice, potatoes GMed to produce a protein somehow tended to stunt growth in mice, while potatoes with the protein injected straight into them did not. The results were in doubt, but that is not the only case. Researchers in Germany GMed petunias to be red and have antibiotic resistence, but they ended up also having more shoots and leaves, more resistence to fungi, and reduced fertility.
So, think about the "pleiotropy", that tendency to get more effects than those that were intended. We are genetically modifying our foods and getting these unexpected side effects, most of which are probably not discovered in testing. After the short testing, they are placed in the public food supply without even labeling for those who don't want to participate in the experiment.
Did you read it? Bold added for me here. >There's no invasion of privacy worth caring about here. >I'm glad they're grabbing the vidcard info. Are they collecting >usernames? IP addresses? Vital personal info? No. They aren't making a big database of people. Just a few little percentages on what vidcards people are using. If you can't handle that, then don't play the game, turn off your computer, web browser, email, registration forms, chat rooms, realaudio, unplug the telephone, close your bank account, cable tv account, get rid of your credit cards (with airmiles!) and unsubscribe from every service you are currently on. Any of those are (probably) giving a lot more personal info away to other companies for worse uses. Pick your battles, and this little thing with id shouldn't ever one.
There's no invasion of privacy worth caring about here. I'm glad they're grabbing the vidcard info. Are they collecting usernames? IP addresses? Vital personal info? No. Just your vidcard and OS (anything else?). All it can do is help you be supported in the future. Isn't support what we need so much? I would certainly like support for my TNT2.
Really, John Carmack has been doing an incredible amount of work for 3d support on Linux. I see as many glx (for xf3.3 matrox/nvidia) commits from him as from anyone else, and his explanations of current problems/fixes on glx related stuff is always great. He doesn't need to do this. He doesn't really need to put all this work into Linux Q3 (another 5% of market for probably 2x work? pfff.). Quit whining about little stuff and thank him for all the work he does.
Well, I'm on SE 87th, between Powell and Division. Let me tell you, internet *sucks* right here. My friends on 39th, 92nd, or anywhere else I've heard from all open to ADSL but get 46,000+ modem speeds or so anyway. I get 28,800 tops (2.2k/s stable download when very lucky), and sometimes lower. ADSL isn't available. Cable isn't available. Frame relay is not within my home budget. Is there any other way to get decent net access? This is why I was looking for *any* way to increase my chance of ADSL. I was just looking for how to get the phone co. to swap me to the straight (or straighter) copper loop that was mentioned in the article, in case it would help either modem or ADSL. I figure it couldn't hurt even if it doesn't help.
Well, I have been having troubles getting ADSL too. I live in Portland, OR with USWest as our wonderful and helpful phone service . I can't connect higher than 26400, and they say ADSL isn't available. On my 3rd call to them asking "Is it here yet?" I got a guy with a little more of a clue, and he said that since I had 2 phone lines I wouldn't show up as ADSL-available anyway, even if I was in range, because there's a doohickey that runs those 2 lines from a single drop to the house. But my close neighbors aren't available either, though my friend *farther* from the station has it.
I am guessing it is all this conversion that is screwing me over as far as connect speed and ADSL. How would you get the phone company to actually switch you over to the old copper needed for ADSL? Anyone have any good ideas?
Slashdot Mirror
You should be able to run xcompmgr -a (or just xcompmgr -- two different routes to the same effect) and get smooth window drag today on nvidia. EXA will let us do this for open-source drivers as well.
Here's a contradictory example. As a user of MIT and 2-clause BSD binaries, I can redistribute them as I like, and frequently do as part of X/DRI work. However, the FreeBSD is a user and redistributor of RedHat RPMs as part of our linux compatibility, though we don't modify them other than wrapping in our own packaging. But we can't just distribute the binaries, because of the restriction in the GPL that if we do that, we must also guarantee that we can supply the corresponding source. That means that we have to host the SRPMs on our mirrors (though nobody will ever use them -- they'd use current RH sources) or otherwise store them, so that just in case someone demands the source (even after RedHat has stopped distributing htat particular source RPM), we can fulfill the demands of the GPL.
What a waste of time. We have to build infrastructure in our ports system to maintain and populate mirror space for no reason other than GPL restrictions.
1) Rendering to texture at worst consists of manually syncing the accelerator and flushing caches between using something as dst and using it as src. I do that in Xati. I don't see any issues with it.
2) Alpha blending is really cheap. On keith's laptop we just did about a 640x480 movie, semi-transparent, with his little window thumnail program, "uncover," running and displaying that movie transparently over the desktop. CPU usage was at about 40% IIRC, but that's my fault for not implementing some basic hardware suppport (hostdata uploads).
I've also done this on my R128 laptop. Still smooth.
X does not need an "overhaul" in the way the parent is saying, if I am understanding correctly (Xaw is absolutely unrelated, so I'm a bit confused). X.Org just needs real Render acceleration, which means a new acceleration architecture like KAA, but it wouldn't take that long. And when it's done, all these operations become really cheap as someone someone writes the hardware code (~ 1000 lines for all of R100 and R200 in Xati), even on your rage 128, voodoo 3, g400, tnt2, etc. class hardware.
Incidentally, jeffr just came back and applied a couple of significant fixes to ULE, notably the KSE+ULE+PREEMPTION that was the primary reason it was disabled. Now let's hope its speed can be brought up to 4BSD levels for server tasks (assuming that it hasn't got better since the last benchmarking was done, which may not be true), so it can be turned back on and give us back that desktop-interactivity love.
(Parent post was definitely accurate on the reasoning)
Desktop sluggishness is something that gets complained about a lot, and I know I hate the feel we have on the desktop right now. Currently, scheduler work has been focused on 4BSD with server loads, notably mysql. SMP performance with supersmack (mysql test) has gone up something like 50% in the last few months, thanks to netperf and 4BSD scheduler improvements. What would be nice to see is somebody fixing ULE (the new scheduler) both in terms of server performance and fixing those remaining bugs, since it is known to be significantly better in terms of desktop interactivity. However, its author only has sporadic FreeBSD time and others find ULE to be very scary, so it's not getting fixed currently.
However, I do think that we'll see interactivity continually improve at this point, as Giant keeps getting pushed out of more subsystems.
Part of it was that there were problems with ULE and PREEMPTION, which we really hope to have working for the release if possible. But it was also not performing well for some specific tests that are being done (supersmack on mysql, among others). That combined with a few little bugs (load avg reporting) and the author not really being available to work on it, meant that it was decided to move back to 4BSD for the release (and possibly -STABLE), while hopefully getting ULE going well on -CURRENT. ULE has its own set of features -- better interactivity on heavily loaded machines (so nice for your desktop while compiling!) and, as I remember, better algorithms for machines with tons of processes, but its youth menas it's not well-tuned yet for general server use, which is what FreeBSD focuses on.
Integration of the Savage (and Mach64, and VIA) DRI as on-by-default requires that they get fixed for the security requirements that we have accepted for the DRI. All of those drivers currently let any user authorized for DRI read/write arbitrary memory. Meeting those requirements is a lot of work, but it would be great to see someone working on those.
Now, one option, and one I want to look into for the next release, is some "InsecureIsOK" "YES" for those drivers, so we can build and install them by default and users make the choice at runtime. This is slightly different meaning than the Section "DRI" because Section "DRI" authorizes users for the DRI security model, which only allows users to hang the machine. (due to the complexity of hardware, the checking required to avoid hanging is simply too difficult to do for direct rendering, and that's why you have to turn it on for non-root)
Well, I'm working on the hardware acceleration for current hardware that will support *all* the operations currently done by the compositing manager (the program responsible for those shadows). Radeon will do it fine. I'm hoping I'll be able to do it with SiS300. If SiS300 works, it will be worth experimenting with other hardware to see if the tradeoffs in card memory use are worth getting the acceleration (I suspect the answer is "yes").
What keithp is talking about for "things that won't be fast enough with 2d/3d hardware as it exists today," these are experiments for things like correct shadowing underneath translucent windows, which are interesting but not necessary and not likely to be seen in a standard desktop before hardware accelerates it.
Let me say that, as a FreeBSD user, I wish I had the fd.o xserver ported to FreeBSD so I could use it on my desktop, even without acceleration of compositing. I hate the feel of using XFree86 now that I've used the compositing manager even as little as I have for testing drivers. No more delay refreshing windows when dragging them around would be great.
Don't like shadows? Well, you could just axe all that code out of the compositing manager. But I do see cases where translucency will improve the visual experience. It will also force us to implement acceleration we should have been working on doing right long ago in order to speed up antialiased text. I look forward to no longer seeing 30% CPU times in my X server when compiling software.
The kernel sources were updated on 2003-03-09, two days before 4.3.0 hit the ports tree.
I'm not updating drm-kmod because it's annoying to have these open-source, mit-licensed kernel modules outside of the tree. It means that as the port maintainer I have to apply patches to it every time someone changes the kernel API and all the users have to manually update it. If it's in the tree, there's no synchronization problem (except in DRI CVS).
I was a student sysadmin/techie for four years at Franklin High Schoolin Portland, OR, along with a few other students and one hired admin. I also was involved in a student union, and we knew about the funding problems: $20 million in the hole in this budget, if I remember correctly. Another $500,000 will mean even fewer teachers, when we have been losing teachers already.
/now/!" or little help messages from teachers like "the box is missing, come fix it [ed. note: that's the computer!]"). Making our computers use Linux would have been with quite a bit of dissatisfaction on the part of the teachers. Existing operating systems needed to be reinstalled about once a year depending on their use, but other than that didn't require much adminning or much knowledge on the part of the users. We few Linux/BSD users didn't have time to teach about CAB to kill frozen X or training people to log out or train other techies to handle linux troubles (we had about 8 mac/windows techies at FHS, with maybe two really proficient in linux/bsd). It really requires a full-time sysadmin, at least for every couple of schools. This does not exist. We used to be special at Franklin because we had a part-time admin. We don't have a dedicated admin at Franklin any more. We were already just scraping by on Mac/Windows maintenance, and I think a Linux or BSD network would be impossible now.
However, to those of you saying "Just use Linux," I tried. You know what, administering classroom Linux systems is hard. I was working on a X terminal Linux (then FreeBSD) network at Da Vinci middle school for over a year. It had to be X terminals because the little machines couldn't handle it. The staple computer at FHS is the P166 with 16MB RAM from CTL ("Crap Technology for Losers," as it was called), the middle school had some machines even worse. These machines can handle Office or IE on win95. They couldn't handle X with Netscape/Mozilla or StarOffice. With a server running the programs it was almost usable. However, we didn't have automounted floppy drives working, sometimes samba was flakey, sometimes people would have troubles opening netscape (it was _slow_) or something else happened. The teacher I was working with was really interested and excited, but didn't have the proficiency to be a sysadmin. I didn't have the time to be it, after spending my days at Franklin.
A number of teachers at a school can do basic Windows repair, but paid admins rarely stay at a school for more than a couple of years. The warm fuzzies of working for the public schools did not make up for the lack of pay or the crap they had to put up with ("I need you
Yes, a lot of people are starving out there, but GM foods are not going to save them, or at least not the ones developed so far. The crop modifications so far have been mostly related to pesticides, either adding pesticides (such as Bt) or adding resistence to pesticides. According to the companies, this will be cheaper for the farmer. However, in a survey of Ohio farmers, those that used GM soybeans instead of unmodified soybeans used less pesticide, but had to pay much more for seeds. Their net cost was almost equal ($144.50/acre instead of $145.75/acre).
The crushing of the small farmer is due to mechanization and competition from big growers. It happened in the US from the 1850s to early 1900s. Farmers without machinery couldn't compete with those with the machines that were ten times as labor-efficient or more. They had to buy the new equipment on credit. When they couldn't pay for the machines, the farms were lost to the bank, then sold off to the big growers, and the process continued.
And of course we do not say that the problem is too many people out there. World Hunger deals with that question. The world produes enough grain alone to provide every person with 3,500 calories a day, far more than any recommended amount. The problem is that people can't buy the products that are available.
For the future, non-GM processes are improving the efficiency of fields all the time, in the case of wheat by using traditional breeding methods to reduce stalk length so that more energy is spent on grain production. As long as the results aren't patented the way GM products have been so far, that would be a far better improvement in the poor farmer's problem, along with world hunger in the future as population increases.
"you don't eat genes." I guess you meant that we don't incorporate genes consumed wholesale into our bodies (eating bread doesn't turn us into wheat).
However, the genes spliced into biotech products can unintentionally create chemicals that are harmful to people. A company (don't have the name stored nearby) spliced some Brazil nut genes into soybeans to increase protein content. It was successful, except that people who have allergies to Brazil nuts were allergic to the new soybeans. It was caught during testing, but many anti-GMO folks fear that the testing is insufficient. The testing required by the FDA is no more rigorous for GMO foods than for other food products.
It is a terribly imperfect science. Many more genes are required to splice than just the one desired trait. In a test on mice, potatoes GMed to produce a protein somehow tended to stunt growth in mice, while potatoes with the protein injected straight into them did not. The results were in doubt, but that is not the only case. Researchers in Germany GMed petunias to be red and have antibiotic resistence, but they ended up also having more shoots and leaves, more resistence to fungi, and reduced fertility.
So, think about the "pleiotropy", that tendency to get more effects than those that were intended. We are genetically modifying our foods and getting these unexpected side effects, most of which are probably not discovered in testing. After the short testing, they are placed in the public food supply without even labeling for those who don't want to participate in the experiment.
Did you read it? Bold added for me here.
>There's no invasion of privacy worth caring about here.
>I'm glad they're grabbing the vidcard info. Are they collecting
>usernames? IP addresses? Vital personal info? No.
They aren't making a big database of people. Just a few little percentages on what vidcards people are using. If you can't handle that, then don't play the game, turn off your computer, web browser, email, registration forms, chat rooms, realaudio, unplug the telephone, close your bank account, cable tv account, get rid of your credit cards (with airmiles!) and unsubscribe from every service you are currently on. Any of those are (probably) giving a lot more personal info away to other companies for worse uses. Pick your battles, and this little thing with id shouldn't ever one.
There's no invasion of privacy worth caring about here. I'm glad they're grabbing the vidcard info. Are they collecting usernames? IP addresses? Vital personal info? No. Just your vidcard and OS (anything else?). All it can do is help you be supported in the future. Isn't support what we need so much? I would certainly like support for my TNT2.
Really, John Carmack has been doing an incredible amount of work for 3d support on Linux. I see as many glx (for xf3.3 matrox/nvidia) commits from him as from anyone else, and his explanations of current problems/fixes on glx related stuff is always great. He doesn't need to do this. He doesn't really need to put all this work into Linux Q3 (another 5% of market for probably 2x work? pfff.). Quit whining about little stuff and thank him for all the work he does.
Well, I'm on SE 87th, between Powell and Division. Let me tell you, internet *sucks* right here. My friends on 39th, 92nd, or anywhere else I've heard from all open to ADSL but get 46,000+ modem speeds or so anyway. I get 28,800 tops (2.2k/s stable download when very lucky), and sometimes lower. ADSL isn't available. Cable isn't available. Frame relay is not within my home budget. Is there any other way to get decent net access? This is why I was looking for *any* way to increase my chance of ADSL. I was just looking for how to get the phone co. to swap me to the straight (or straighter) copper loop that was mentioned in the article, in case it would help either modem or ADSL. I figure it couldn't hurt even if it doesn't help.
Well, I have been having troubles getting ADSL too. I live in Portland, OR with USWest as our wonderful and helpful phone service . I can't connect higher than 26400, and they say ADSL isn't available. On my 3rd call to them asking "Is it here yet?" I got a guy with a little more of a clue, and he said that since I had 2 phone lines I wouldn't show up as ADSL-available anyway, even if I was in range, because there's a doohickey that runs those 2 lines from a single drop to the house. But my close neighbors aren't available either, though my friend *farther* from the station has it.
I am guessing it is all this conversion that is screwing me over as far as connect speed and ADSL. How would you get the phone company to actually switch you over to the old copper needed for ADSL? Anyone have any good ideas?
TIA.
Eric Anholt
anholt@teleport.com