.IMHO Moz is plenty stable...just damn SLOW and it has a clunky 'feel' to it
That has more to do with using Gecko to render the
user interface than it does with anything else.
Go try Galeon and be impressed at how snappy Mozilla can feel. I use it for all my browsing at home currently. It's about as snappy as 4.7x was, but
it handles modern websites much better. Galeon requires a Mozilla installation -- it just supplies a GTK based UI to replace the XUL-based one that comes with Mozilla.
The rate of bug reports doubled around the time Netscape 6 was released, thus opening Mozilla and Mozilla-based browsers to a much wider audience. I do not think this is a coincidence.
Also, the graph is misleading -- it doesn't show the number of outstanding bug reports, only the number of opened bug reports. Duplicate bugs will all be counted in the "new" category. I'd imagine that the actual "defect introduction rate" is much less than this graph would suggest.
Still, the fact that the curve isn't leveling much
means either (a) the new user base is growing faster than the actual defect rate, so the bug database is getting swamped with increasing numbers of nuisance and repeat bugs, (b) or the actual defect introduction rate hasn't leveled out. The article argues (b), but I think the reality is closer to (a), especially when looking
at the graph for "assigned", which I'd guess more accurately represents "bugs that are actually bugs and therefore require attention".
(whatever happened to "baud"? Perfectly good unit of measure)
The short version is that "baud" usually refers to the "symbol rate" (how many "symbols" are sent per second), and "bps" says how many bits are sent per second. In the early days, each "symbol" sent 1 bit's worth of information, so baud rate equalled
bit rate. On modern modems, each "symbol" sends
multiple bits worth of information.
This page has a much more comprehensive discussion on the matter.
Back on-topic: Yes, I have to agree that these bloated pages, esp. the Flash-reliant monstrosities, are atrocious. Where I don't mind Flash is when the site posts a Flash movie that you can specifically click on to see. (AYB comes to mind...) Where I do mind is when the whole site is composed of SWF's.
It's true that RMS isn't requiring "GNU inside" stamped on Linux boxes, but he is rather insistent. He's insistent to the point
that I wager that he'd adopt such a requirement
in a later revision of the GPL if thought it didn't make him so obviously look like a hypocrite.
I respect the GPL, and I even release software
under it. However, RMS has a tendency to be a little too radical at times. The whole GNU/Linux thing strikes me as not practicing what he preaches.
If I were to write an OS kernel and use all the
GNU tools to provide a userland, RMS would like take away my freedom to call the resulting product whatever I like. Quite the freedom fighter, isn't he? It's more like the "freedom fighters" in 3rd world countries -- as soon as they overthrow the old gov't, you get a new gov't that's just as oppressive, they just oppress different things.
That said, I have nothing wrong with RMS trying
to get some press for GNU. Trying to get press by insisting on "GNU/Linux" (and even interrupting and "correcting" people when they say "Linux") makes him look like a big crybaby though.
You can still put your work in the Public Domain by labelling it as such. Something to the effect that "I hereby place this work in the Public Domain, with no restrictions on its subsequent use. I, as the sole copyright holder, relinquish all rights and claims of ownership to this work. This [whatever type of intellectual property] is provided as is without any warranty, and the author shall not be held liable for its use in any capacity."
Or something like that. IANAL, and I would suggest you consult one for more official verbiage. I don't think it's really necessary though -- stamping "This Is Public Domain" on it should be sufficient. The main point remains: You are free to relinquish your rights as a copyright holder at any time to any work for which you hold those rights.
Linus had called it Linux while he was working on it alone. He then went to release it to the world, and was (embarrassed|too shy|whatever) to release it with a name so obviously derived from his own. So, he renamed it Freax and uploaded it. The FTP site admin, who was aware of the original name Linux, didn't like Freax at all, and renamed it back to Linux.
This fledgling system would have been short-lived had Linus not mentioned it in the Minix newsgroup. His early posting prompted an offer of space on an FTP server at the Helsinki University of Technology, letting people download the first public version of Linux. "Linux was my working name," Linus says, "but if I actually used it as the official one, people would think that I was an egomaniac and wouldn't take it seriously. So I chose this very bad name: Freax" - free + freak + x. "Sick, I know." Ari Lemmke, who ran the FTP site, decided he didn't like the Freax label, so he used the working name instead.
And that is, as Paul Harvey would say, the rest of the story.
Speaking of intelligent discourse... Am I the only person who finds it ironic that the primary reason the BSD license was incompatible with the GPL was its advertising clause? (You know, that clause that says that people who derive their work from the BSD-license-covered source must advertise that fact by saying "Contains code developed by so-and-so"...)
And yet, isn't that what RMS is asking of the Linux community? That is, for us to slap "GNU inside" on our Linux boxes?
If I'm in an XTERM window, I like to have some info
in the title bar:
PS1='\[\033]2;(\u) \h: \w^G\](\u) \h:\w\$ '
That ^G is a Control-G (ASCII BEL). This is part of the escape sequence XTERM uses for
setting its title bar. I suppose I could've used \007. Ah well.
--Joe --
Re:What is an ABI? Re:how much stuff with this bre
on
GCC 3.0 Released
·
· Score: 1
Yes, the ABI is the Application Binary Interface.
This describes various aspects of the run time environment, such as how functions call each other (eg. how to place arguments of various types in registers or on the stack, etc), how scalars and aggregates are laid out in memory, how OS and library calls are made, etc. It's essentially a description of how a given function interfaces to the rest of "the machine."
Make sense?
Basically, two object files that are compiled with the same ABI can be linked to each other without any real fuss. If they use different ABIs, they potentially won't agree on even the simplest of assumptions (including, potentially, even what sizeof(int) is).
WTF? Why add features to something you're deprecating?
Hey, the same thing happened in the C standard, where common vendor extensions were explicitly taken into account when ANSI drafted the C standard. Things such as using/**/ in a #define to splice tokens were never defined by K&R, but were available in some compilers. ANSI C deprecated this common practice in favor of the new, well-defined ## operator.
If Standards Committees did not take into account current common practice, that would surely be madness.
TI's C compiler for their DSPs implements restrict, as does recent versions of GNU
C.
The TI compiler uses the guarantees offered
by restrict to do some rather aggressive optimizations to loops, similar to what one finds in a FORTRAN compiler. (When restrict is not present, it also performs global alias analysis to attempt to disambiguate pointer references. That's a much harder problem, particularly in C, which is why restrict is valuable.)
They're probably counting the separate red,
green, and blue elements. These are separate pixels, as they are offset from each
other. A special filter, known as a "demosaicing" filter, is required to correctly merge these offset images into the Y/Cb/Cr planes that are encoded in the final JPEG. The ratio isn't a factor of 3 as you might expect, as mosaic patterns tend to use more green than red or blue. (The patterns I've seen have 5 green to 2 red and 2 blue.)
This page describes mosaicing to some extent, in the context of reverse engineering a Kodak digital camera. This page at the same site offers some other details. And Ron Kimmel's page has some neat pictures showing different artifacts due to poor de-mosaicing.
With ADSL you have a box installed somewhere that has a connections for your DSL equipment and a second connection for your other telephony stuff. This box isolates the telephony stuff
from the actual phone line...
This is the so-called splitter.
...so that they don't change the characteristics of the cable between your house and the exchnage, and thus the line characteristics need only be check when your
equipment is installed.
Untrue. Line characteristics are also affected by weather, temperature, and potentially by changes in service to other people in your area.
G-Lite works by have a DSP in the ADSL gear continuously measure the line characteristics and take action accordingly, this removes the need for a wall box (reducing installation time and
cost) at the expense of needing a bit more computing power in the ADSL modem.
Untrue, at least to the extent that this processing burden is unique to G.lite. "Regular" ADSL also has a DSP that performs the same function. (Hey, I work for a DSP company that sells a ADSL chipset that's used in both....) Now, it's come to my attention that the term "G.lite" is no longer widely used. It's officially known as ITU G.992.2, and most places don't bother to tell you what particular flavor ADSL you're running -- they'll just tell you a bandwidth number. Wheee.... The main point is that it's splitterless at the consumer's end of the line.
The main reason I say G.lite has lower computational requirements (at least, in steady state), is that the data rate is lower. Since at least some portion of the processing cost is proportional to the data rate, this makes sense. Much of the front end work that processes the analog data of the wire stays pretty much the same, though, as I understand it. Those pieces work at symbol rate, which I believe is fixed. The way bandwidth is varied is by varying the number of bits per symbol.
Now as for changing line characteristics: The line characteristics of a full-rate ADSL line and of a G.lite line both drift over time. A DSL modem needs to track these changes and incrementally update its mathematical model of the line. If too large of a change occurs, the DSL modem needs to re-train (just like a voiceband modem does) to get back on track. This is true for both ADSL and G.lite. A G.lite modem is simply much more likely to need to retrain due to wild changes in loading. Because retraining is an "exceptional" event though, and because the whole modem focuses on retraining rather than transmitting data during the training process, this cost is not added on top of your normal
communication processing requirements.
In practice, I understand G.lite and full rate DSL are very similar in processing burden, and that the main difference is in how they're tuned. Full rate DSL is tuned for high speed transmission, at the expense of making retraining more expensive (since it doesn't expect to retrain often, as you mention). G.lite runs somewhat slower, but offers fast retrain to handle interruptions on the line, and also to offer lower-power modes that basically "hang up" the modem. The drawback is that you don't get as much bandwidth to play with.
From what I hear, Canada has the US whipped in many places w/ DSL connectivity. At least here, the excuses you hear are that the telcos only want to put DSLAMs in the COs.:-(
I guess it depends on who your telco is too -- some may be that much cooler than others. The way the US system (doesn't) work, I'm not really surprised...
My understanding is that G.lite is a less computationally intensive version of DSL, and so it can be implemented on lower cost equipment. It also makes some compromises so that you can have a "splitterless" setup (you don't have a voiceband/DSL-band filter where the phoneline enters the house). The result is a lower-bandwidth DSL which is suitable for consumer applications.
G.lite still uses the same frequency bands as normal DSL, though, from what I recall. It may be slightly narrower, but it's still well outside the 300 Hz to 3300 Hz range that voiceband uses, because it's supposed to coexist with the household voiceband service on the same line. It's also supposed to coexist with voiceband modems and FAX machines. (Some of the performance tradeoffs in G.lite apparently have to do with the harmonics coming off of the things it might have to coexist with, including changes in loading due to people picking up handsets, incoming ring signals, and so on... In a non-G.lite setting,
the splitter handles most of this. G.lite is supposed to make this easier on J. Random Consumer, again at the cost of some performance.)
Given all that, I'd be surprised if G.lite was any friendlier to fiber than regular DSL.
My understanding is that DSL is a signalling protocol for copper lines, so they're correct that a hybrid fiber/copper feed won't work unless the copper-to-fiber bridge contains the DSLAM (Digital Subscriber Line Access Multiplexer) front end to convert the analog DSL signals into digital bits to go over the fiber.
Right now, DSLAMs like to live on racks in a CO, not one of those grey boxes by the side of the road where the copper-to-fiber conversion is likely happening.
To run DSL, you need copper from you to the DSLAM. Hence the problem.
Presumably, whatever they use to bridge the copper over to fiber could be adapted for tranceiving high-bandwidth DSL signals as well, but it sounds like right now that's not in the cards.
I think I'll approximate my groan with a low frequency sine wave in either case....
For the non-engineers out there, the typical RMS approximation assumes the input is a sine wave. (At least, as I recall.) That means that the approximation works for measuring things like wall current (aka. "the mains" for you non-'merkins), but not for more complicated signals, such as audio or noise or what-have-you.
It had a 100Mb PCI ethernet card with low latency, and the other had a 10Mb PCI ethernet card with high latency. [...] The acknowledgements got back to the kernel.org server faster, which opened the TCP window. It wasn't just this one
test, either - the computer with the 10Mb card got consistenly slower downloads.
I don't think that's quite the case. Both sides estimate the RTT (Round Trip Time) on the link, and then adjust the window according to the RTT.
The problem you describe comes into play on much higher bandwidth connections with much higher latencies. This page describes the problem reasonably well, although it appears to be a little dated.
By default, TCP offers a maximum window of 64K bytes (which is 512K bits). At 4Mbit/sec, this takes 125ms worth of time to transmit. So, basically, if your RTT is about 125ms or less, you should see 4Mbit/sec transfers. For TCP's maximum window size to limit you to 30KB/sec, your RTT would need to be ~17000ms. I think it's much more likely that your network card's driver is hosed so thqt you're losing ACKs and having to wait for TCP
to retransmit.
So what sort of latency are you seeing to kernel.org? I'm seeing 90-100ms. I doubt you're seeing 17000ms.
Now imagine that the game he was playing was not Quake, but in fact (the hypothetical) 3D photo-realistic 1st person "shooter", "Leisure Suit Larry, Buttman, and Max Hardcore's European
Adventure", Now imagine the range of reactions.
Mine would be along the lines of "Feeling frisky, eh?" if even that.:-) No worries there. I guess I must be a lucky guy?
Memory is cheap now I think most people would be better served maxing out their memory rather than seeking faster CPU's
I beg to differ -- at least once you get into
the 256MB territory. I have 128MB in my machine and my fiancee has 256MB in hers. We spend very little time actually hitting swap. (I spend slightly more, since I have less RAM and I master CD-Rs. I also don't close Moz very often.)
But still, I don't spend much time at all in disk-wait even if there are pages on disk, since
what gets paged out is idle anyway.
And on my fiancee's machine, lessee.... 8K swap used out of 512MB...:-)
Basically, once you get to 256MB or above, unless you're doing some crazy video and image editing,
you quickly get into the domain of diminishing returns. Once your working set fits in RAM, you're CPU bottlenecked again.
Now on a different topic of when to upgrade -- I seem to wait for a factor-of-five to factor-of-ten difference myself for major upgrades. I went from a TI-99/4A to a 4.77MHz Tandy 1000 to a 386SX25. During college, I had a bunch of minor mobo upgrades spanning a 486DX33 through a 5x86-133, but that's not my preferred way of doing things
anymore. I sat with the 5x86-133 for awhile, jumped to a Pentium II-300MHz, and there I stayed until now.
My next system will likely be a dual 1.5GHz Athlon early next year (factor of ten). My present strategy is to buy a computer to keep for ~4 years between upgrades, so I have bragging rights at both ends of the spectrum (start with "ha ha, my computer kicks your computer's ass" and end with "ha ha, I don't run bloated software that needs all those MIPS and all that RAM...."). :-)
The other responder to your post made some good points. The other one I'd like to add is that many PCs (depending on the software you're running) don't do "unaided shutdown" very well.
The only to shut them down cleanly seems to be to close
the applications manually and select "Shut Down."
(Mostly, 'doze boxes with some annoying driver
that doesn't work well with Suspend. I have a
laptop I use (not mine -- it belongs to my employer) that falls in this category.)
Notice I didn't advocate watermarking as the
solution for this, I advocated the very-hard-to-reproduce holograms. As best as
I can tell, all the watermark tells you is
what source they copied from (assuming different
masters have different watermarks) -- pointless,
I heartily agree.
I guess my main problem is that I replied to
the wrong post without fully clarifying my
stance. My point to the poster I was
replying to was not that the watermark was the
right answer (I don't believe that it is), but
that the real pirates do provide all the
trimmings that make the package look legit.
And the answer there is the hologram or some
other object/thing that the pirator cannot copy
easily. A watermark consisting of bits can be
copied just like any of the rest of the bits, which in my mind is not really a watermark. (Think of real watermarks on paper and how they
work -- I can't think of a digital equivalent.)
It stops the real threat, which are pirates which produce packages that look like the real thing and which get sold into stores, etc.
George making a copy for Frank to watch on his
VHS isn't the problem, and even Sally sharing a.VOB with Susan over Gnutella isn't the issue. 100,000 authentic looking DVDs complete in packaging, etc. arriving from offshore and ending
up on the shelf at <insert retail store name here> is the issue.
And for those, the hologram scheme sounds like the
best bet to me.
I've read the FAQ as you suggest, but don't see anything relevant. As to the issues you briefly mention, how does google get away with it?
Probably because Google can claim it hasn't exercised any editorial control over the content that's cached -- it's all automatic and hands-off -- whereas Slashdot is very specifically exercising
editorial control, deciding what articles get published, and usually making some comment about the content itself. Google can be viewed as simply a conduit forwarding the information, whereas Slashdot would be viewed as republishing
the information. A very important distinction.
Slashdot Mirror
That has more to do with using Gecko to render the user interface than it does with anything else. Go try Galeon and be impressed at how snappy Mozilla can feel. I use it for all my browsing at home currently. It's about as snappy as 4.7x was, but it handles modern websites much better. Galeon requires a Mozilla installation -- it just supplies a GTK based UI to replace the XUL-based one that comes with Mozilla.
--JoeThe rate of bug reports doubled around the time Netscape 6 was released, thus opening Mozilla and Mozilla-based browsers to a much wider audience. I do not think this is a coincidence.
Also, the graph is misleading -- it doesn't show the number of outstanding bug reports, only the number of opened bug reports. Duplicate bugs will all be counted in the "new" category. I'd imagine that the actual "defect introduction rate" is much less than this graph would suggest.
Still, the fact that the curve isn't leveling much means either (a) the new user base is growing faster than the actual defect rate, so the bug database is getting swamped with increasing numbers of nuisance and repeat bugs, (b) or the actual defect introduction rate hasn't leveled out. The article argues (b), but I think the reality is closer to (a), especially when looking at the graph for "assigned", which I'd guess more accurately represents "bugs that are actually bugs and therefore require attention".
--JoeThe short version is that "baud" usually refers to the "symbol rate" (how many "symbols" are sent per second), and "bps" says how many bits are sent per second. In the early days, each "symbol" sent 1 bit's worth of information, so baud rate equalled bit rate. On modern modems, each "symbol" sends multiple bits worth of information.
This page has a much more comprehensive discussion on the matter.
Back on-topic: Yes, I have to agree that these bloated pages, esp. the Flash-reliant monstrosities, are atrocious. Where I don't mind Flash is when the site posts a Flash movie that you can specifically click on to see. (AYB comes to mind...) Where I do mind is when the whole site is composed of SWF's.
--JoeIt's true that RMS isn't requiring "GNU inside" stamped on Linux boxes, but he is rather insistent. He's insistent to the point that I wager that he'd adopt such a requirement in a later revision of the GPL if thought it didn't make him so obviously look like a hypocrite.
I respect the GPL, and I even release software under it. However, RMS has a tendency to be a little too radical at times. The whole GNU/Linux thing strikes me as not practicing what he preaches. If I were to write an OS kernel and use all the GNU tools to provide a userland, RMS would like take away my freedom to call the resulting product whatever I like. Quite the freedom fighter, isn't he? It's more like the "freedom fighters" in 3rd world countries -- as soon as they overthrow the old gov't, you get a new gov't that's just as oppressive, they just oppress different things.
That said, I have nothing wrong with RMS trying to get some press for GNU. Trying to get press by insisting on "GNU/Linux" (and even interrupting and "correcting" people when they say "Linux") makes him look like a big crybaby though.
--JoeYou can still put your work in the Public Domain by labelling it as such. Something to the effect that "I hereby place this work in the Public Domain, with no restrictions on its subsequent use. I, as the sole copyright holder, relinquish all rights and claims of ownership to this work. This [whatever type of intellectual property] is provided as is without any warranty, and the author shall not be held liable for its use in any capacity."
Or something like that. IANAL, and I would suggest you consult one for more official verbiage. I don't think it's really necessary though -- stamping "This Is Public Domain" on it should be sufficient. The main point remains: You are free to relinquish your rights as a copyright holder at any time to any work for which you hold those rights.
--JoeLinus had called it Linux while he was working on it alone. He then went to release it to the world, and was (embarrassed|too shy|whatever) to release it with a name so obviously derived from his own. So, he renamed it Freax and uploaded it. The FTP site admin, who was aware of the original name Linux, didn't like Freax at all, and renamed it back to Linux.
This article on Wired tells the story. Specifically:
And that is, as Paul Harvey would say, the rest of the story.
--JoeSpeaking of intelligent discourse... Am I the only person who finds it ironic that the primary reason the BSD license was incompatible with the GPL was its advertising clause? (You know, that clause that says that people who derive their work from the BSD-license-covered source must advertise that fact by saying "Contains code developed by so-and-so"...)
And yet, isn't that what RMS is asking of the Linux community? That is, for us to slap "GNU inside" on our Linux boxes?
Oh, the irony...
--JoeIf I'm on a plain VT100:
If I'm in an XTERM window, I like to have some info in the title bar:
That ^G is a Control-G (ASCII BEL). This is part of the escape sequence XTERM uses for setting its title bar. I suppose I could've used \007. Ah well.
--Joe--
Yes, the ABI is the Application Binary Interface. This describes various aspects of the run time environment, such as how functions call each other (eg. how to place arguments of various types in registers or on the stack, etc), how scalars and aggregates are laid out in memory, how OS and library calls are made, etc. It's essentially a description of how a given function interfaces to the rest of "the machine."
Make sense?
Basically, two object files that are compiled with the same ABI can be linked to each other without any real fuss. If they use different ABIs, they potentially won't agree on even the simplest of assumptions (including, potentially, even what sizeof(int) is).
--Joe--
Hey, the same thing happened in the C standard, where common vendor extensions were explicitly taken into account when ANSI drafted the C standard. Things such as using /**/ in a #define to splice tokens were never defined by K&R, but were available in some compilers. ANSI C deprecated this common practice in favor of the new, well-defined ## operator.
If Standards Committees did not take into account current common practice, that would surely be madness.
--Joe--
TI's C compiler for their DSPs implements restrict, as does recent versions of GNU C.
The TI compiler uses the guarantees offered by restrict to do some rather aggressive optimizations to loops, similar to what one finds in a FORTRAN compiler. (When restrict is not present, it also performs global alias analysis to attempt to disambiguate pointer references. That's a much harder problem, particularly in C, which is why restrict is valuable.)
--Joe--
They're probably counting the separate red, green, and blue elements. These are separate pixels, as they are offset from each other. A special filter, known as a "demosaicing" filter, is required to correctly merge these offset images into the Y/Cb/Cr planes that are encoded in the final JPEG. The ratio isn't a factor of 3 as you might expect, as mosaic patterns tend to use more green than red or blue. (The patterns I've seen have 5 green to 2 red and 2 blue.)
This page describes mosaicing to some extent, in the context of reverse engineering a Kodak digital camera. This page at the same site offers some other details. And Ron Kimmel's page has some neat pictures showing different artifacts due to poor de-mosaicing.
--Joe--
This is the so-called splitter.
Untrue. Line characteristics are also affected by weather, temperature, and potentially by changes in service to other people in your area.
Untrue, at least to the extent that this processing burden is unique to G.lite. "Regular" ADSL also has a DSP that performs the same function. (Hey, I work for a DSP company that sells a ADSL chipset that's used in both....) Now, it's come to my attention that the term "G.lite" is no longer widely used. It's officially known as ITU G.992.2, and most places don't bother to tell you what particular flavor ADSL you're running -- they'll just tell you a bandwidth number. Wheee.... The main point is that it's splitterless at the consumer's end of the line.
The main reason I say G.lite has lower computational requirements (at least, in steady state), is that the data rate is lower. Since at least some portion of the processing cost is proportional to the data rate, this makes sense. Much of the front end work that processes the analog data of the wire stays pretty much the same, though, as I understand it. Those pieces work at symbol rate, which I believe is fixed. The way bandwidth is varied is by varying the number of bits per symbol.
Now as for changing line characteristics: The line characteristics of a full-rate ADSL line and of a G.lite line both drift over time. A DSL modem needs to track these changes and incrementally update its mathematical model of the line. If too large of a change occurs, the DSL modem needs to re-train (just like a voiceband modem does) to get back on track. This is true for both ADSL and G.lite. A G.lite modem is simply much more likely to need to retrain due to wild changes in loading. Because retraining is an "exceptional" event though, and because the whole modem focuses on retraining rather than transmitting data during the training process, this cost is not added on top of your normal communication processing requirements.
In practice, I understand G.lite and full rate DSL are very similar in processing burden, and that the main difference is in how they're tuned. Full rate DSL is tuned for high speed transmission, at the expense of making retraining more expensive (since it doesn't expect to retrain often, as you mention). G.lite runs somewhat slower, but offers fast retrain to handle interruptions on the line, and also to offer lower-power modes that basically "hang up" the modem. The drawback is that you don't get as much bandwidth to play with.
--Joe--
From what I hear, Canada has the US whipped in many places w/ DSL connectivity. At least here, the excuses you hear are that the telcos only want to put DSLAMs in the COs. :-(
I guess it depends on who your telco is too -- some may be that much cooler than others. The way the US system (doesn't) work, I'm not really surprised...
--Joe--
My understanding is that G.lite is a less computationally intensive version of DSL, and so it can be implemented on lower cost equipment. It also makes some compromises so that you can have a "splitterless" setup (you don't have a voiceband/DSL-band filter where the phoneline enters the house). The result is a lower-bandwidth DSL which is suitable for consumer applications.
G.lite still uses the same frequency bands as normal DSL, though, from what I recall. It may be slightly narrower, but it's still well outside the 300 Hz to 3300 Hz range that voiceband uses, because it's supposed to coexist with the household voiceband service on the same line. It's also supposed to coexist with voiceband modems and FAX machines. (Some of the performance tradeoffs in G.lite apparently have to do with the harmonics coming off of the things it might have to coexist with, including changes in loading due to people picking up handsets, incoming ring signals, and so on... In a non-G.lite setting, the splitter handles most of this. G.lite is supposed to make this easier on J. Random Consumer, again at the cost of some performance.)
Given all that, I'd be surprised if G.lite was any friendlier to fiber than regular DSL.
--Joe--
My understanding is that DSL is a signalling protocol for copper lines, so they're correct that a hybrid fiber/copper feed won't work unless the copper-to-fiber bridge contains the DSLAM (Digital Subscriber Line Access Multiplexer) front end to convert the analog DSL signals into digital bits to go over the fiber.
Right now, DSLAMs like to live on racks in a CO, not one of those grey boxes by the side of the road where the copper-to-fiber conversion is likely happening. To run DSL, you need copper from you to the DSLAM. Hence the problem.
Presumably, whatever they use to bridge the copper over to fiber could be adapted for tranceiving high-bandwidth DSL signals as well, but it sounds like right now that's not in the cards.
That's my 0x02 cents...
--Joe--
I think I'll approximate my groan with a low frequency sine wave in either case....
For the non-engineers out there, the typical RMS approximation assumes the input is a sine wave. (At least, as I recall.) That means that the approximation works for measuring things like wall current (aka. "the mains" for you non-'merkins), but not for more complicated signals, such as audio or noise or what-have-you.
--Joe--
Actually, 30 meters is just over 98 feet, 5 3/32 inches. :-)
--Joe--
I don't think that's quite the case. Both sides estimate the RTT (Round Trip Time) on the link, and then adjust the window according to the RTT. The problem you describe comes into play on much higher bandwidth connections with much higher latencies. This page describes the problem reasonably well, although it appears to be a little dated.
By default, TCP offers a maximum window of 64K bytes (which is 512K bits). At 4Mbit/sec, this takes 125ms worth of time to transmit. So, basically, if your RTT is about 125ms or less, you should see 4Mbit/sec transfers. For TCP's maximum window size to limit you to 30KB/sec, your RTT would need to be ~17000ms. I think it's much more likely that your network card's driver is hosed so thqt you're losing ACKs and having to wait for TCP to retransmit.
So what sort of latency are you seeing to kernel.org? I'm seeing 90-100ms. I doubt you're seeing 17000ms.
--Joe--
Mine would be along the lines of "Feeling frisky, eh?" if even that. :-) No worries there. I guess I must be a lucky guy?
--Joe--
I beg to differ -- at least once you get into the 256MB territory. I have 128MB in my machine and my fiancee has 256MB in hers. We spend very little time actually hitting swap. (I spend slightly more, since I have less RAM and I master CD-Rs. I also don't close Moz very often.) But still, I don't spend much time at all in disk-wait even if there are pages on disk, since what gets paged out is idle anyway. And on my fiancee's machine, lessee.... 8K swap used out of 512MB... :-)
Basically, once you get to 256MB or above, unless you're doing some crazy video and image editing, you quickly get into the domain of diminishing returns. Once your working set fits in RAM, you're CPU bottlenecked again.
Now on a different topic of when to upgrade -- I seem to wait for a factor-of-five to factor-of-ten difference myself for major upgrades. I went from a TI-99/4A to a 4.77MHz Tandy 1000 to a 386SX25. During college, I had a bunch of minor mobo upgrades spanning a 486DX33 through a 5x86-133, but that's not my preferred way of doing things anymore. I sat with the 5x86-133 for awhile, jumped to a Pentium II-300MHz, and there I stayed until now. My next system will likely be a dual 1.5GHz Athlon early next year (factor of ten). My present strategy is to buy a computer to keep for ~4 years between upgrades, so I have bragging rights at both ends of the spectrum (start with "ha ha, my computer kicks your computer's ass" and end with "ha ha, I don't run bloated software that needs all those MIPS and all that RAM...."). :-)
--Joe--
The other responder to your post made some good points. The other one I'd like to add is that many PCs (depending on the software you're running) don't do "unaided shutdown" very well. The only to shut them down cleanly seems to be to close the applications manually and select "Shut Down." (Mostly, 'doze boxes with some annoying driver that doesn't work well with Suspend. I have a laptop I use (not mine -- it belongs to my employer) that falls in this category.)
--Joe--
Notice I didn't advocate watermarking as the solution for this, I advocated the very-hard-to-reproduce holograms. As best as I can tell, all the watermark tells you is what source they copied from (assuming different masters have different watermarks) -- pointless, I heartily agree.
I guess my main problem is that I replied to the wrong post without fully clarifying my stance. My point to the poster I was replying to was not that the watermark was the right answer (I don't believe that it is), but that the real pirates do provide all the trimmings that make the package look legit. And the answer there is the hologram or some other object/thing that the pirator cannot copy easily. A watermark consisting of bits can be copied just like any of the rest of the bits, which in my mind is not really a watermark. (Think of real watermarks on paper and how they work -- I can't think of a digital equivalent.)
--Joe--
It stops the real threat, which are pirates which produce packages that look like the real thing and which get sold into stores, etc. George making a copy for Frank to watch on his VHS isn't the problem, and even Sally sharing a .VOB with Susan over Gnutella isn't the issue. 100,000 authentic looking DVDs complete in packaging, etc. arriving from offshore and ending
up on the shelf at <insert retail store name here> is the issue.
And for those, the hologram scheme sounds like the best bet to me.
--Joe--
Probably because Google can claim it hasn't exercised any editorial control over the content that's cached -- it's all automatic and hands-off -- whereas Slashdot is very specifically exercising editorial control, deciding what articles get published, and usually making some comment about the content itself. Google can be viewed as simply a conduit forwarding the information, whereas Slashdot would be viewed as republishing the information. A very important distinction.
--Joe--