I don't have much experience with cable modems, but what I've seen is that latencies can be highly variable. This is really bad for VoIP.
I have two high-speed circuits and I am a Vonage subscriber. My main router box is configured to use the DSL route for voice; the wireless link gave me too much drop-out.
Is my experience with Cable circuits atypical, or have others experienced the same thing. And is anybody using a VoIP service over cable who can report?
I've owned about 7 mini-ITX boxes, and 3 of them have had motherboard flaws when I unpacked them (2 had bad network ports, and one had no USB). Another one worked for a month or so before the network port went bad. Still another only boots about 2 out of every three times I push the power button on. I end up having to use the one PCI slot for an extra network card just to get the network to work. Has anyone else experienced issues like this?
I am not one to give up easily on something like this. The form factor and lower power consumption of these boards is very cool. But I've given up on Via's EPIA and EPIA-M.
Instead of the EPIA platform, I'm now deploying servers based on the Total Impact BriQ. And I'm much happier. I didn't need Firewire, USB (except for keyboard, and the BriQ has a serial port instead), or fancy graphics (BriQ has none, unless you count the VFD, heh). But they make slick servers.
And they run Debian/PPC nicely, but you have to use a network install to get it software on there.
While searching for a new diaper bag (the cheap ones only seem to last through 1 kid), I was amazed at how many Google search hits pointed back to eBags. You wouldn't always know it from the URLs, though. Some of the URLs were things like ebags-discount.com, bagsdirect.com, handbags.com, etc., making you think that there were several big bag retailers out there. Others were just plain insane; I remember one that was something like "best-basketball-bags-for-women-athletes.com".
Effectively, they circumvented Google's "site grouping" wherein all hits from one site get clustered under a smaller group. I got fed up with it and resolved not to buy anything from eBags.
But I thought to myself, "maybe they're Scientologists..."
I see your point, but it's also important to remember that an immediate jump to CSS2-based (i.e., non-tabular) layouts would create more usability problems than it would solve, in the short term. That's because people using non-Mozilla browsers wouldn't be able to read the pages.
When you're dealing with millions of users and millions of pages, transitions take time. The move away from tabular layouts is a good idea. New sites should try to minimize their use of tabular layouts -- better yet, use a simple layout that maximizes content area. But the move away from tables as a whole will take time.
Others have already pitched the positives, so here are a few of the negatives. There are a couple of things that I see as real problems with the STL. Having just gone through a small-scale STL development project, I've come away with a really bad taste in my mouth. Here's why.
With the STL, C++ has finally aquired a part of what Smalltalk and Java have always had: a library of base classes. With these sorts of capabilities, you tend to start thinking about your system in more object-oriented terms. This is a good thing in itself, but C++ just doesn't go there with the ease that other languages do.
For example, the OO notion of polymorphism goes completely against C++'s strong typing (and C++ is even more finicky in its type checking than C is). In a true OO system, I don't care what kind of object I have in my hands, I just care that it does a certain thing. This is where late-bound OO languages like Smalltalk and Objective C shine.
Also, as your project progresses and you factor your code into neat little objects, file-based source code navigation becomes a real bear. IDEs like Source Navigator can help with this, but you still have to do double-entry bookkeeping for your prototypes and function declarations.
Why didn't we see these problems before the STL? Because we never tried to use C++ as much more than a superset of C. With the STL, we had the opportunity to build things that were more like our other OO systems, so we did. And that's where we started to get bogged down.
One other thing: We had more discussions about coding style in a few weeks of STL coding than we ever had in our non-STL C++ coding. Perhaps that was because more of us were involved in the project. But I think that, at the heart of it, the STL gives some people a feeling that C++ code can has a chance of being "elegant", and there is a real tendency to push yourself to try to achieve it. Without the STL, we all just knew that C++ was bubble gum and bailing wire. It happened to get the job done for us, and we didn't bicker about style.
Perhaps your situation is different, but if I had to make the call, I'd say your time might be better spent learning something else.
You'd be hard pressed to find a much more portable GUI building toolkit than VisualWorks Smalltalk from Cincom. At my company, we have developed an extremely rich touchscreen GUI for machine control (in the food processing industry), and we have beed very satisfied with VisualWorks. A non-commercial version is available for download (and you're free to use it for development up until you deploy). Features include:
True Object-Orientation: Smalltalk-80 was developed at Xerox PARC under the leadership of Alan Kay, who coined the term "Object-Oriented". In Smalltalk, everything is an object -- there are no primitive types. Simpler is better.
Elegant Syntax: it's not like C, C++, or Java -- and why would you want it to be? OO is a new paradigm, and we can all use some help thinking in new ways
Bit-compatible across platforms: All that's needed to switch platforms is a new virtual machine. Think Java+Swing on steroids (after 20 years of smoothing wrinkles out). VisualWorks runs on Linux, Windows, Mac, Solaris, HP-UX, and more -- and it's done these things for years.
Fast Object Engine (Virtual Machine)
Refactoring Browser: effortlessly refactor your code with this powerful tool
Needless to say, I'm sold -- and I'm never going back to a C-style OO language.
There are at least 2, maybe 3 Smalltalk flavors that would allow cross-platform development with less pain than Java:
Squeak (www.squeak.org) is bit-compatible across several platforms -- just ftp your image over and run it. Open-source under a liberal license.
VisualWorks (www.cincom.com/visualworks/) also runs bit-identical across Linux, Solaris, Windows 95/98/NT, PowerMac, HP-UX, etc. My personal favorite, though it's not truly open source. You can see all of the source to the class libraries, you just have to pay the vendor when you want to deploy
Smalltalk X (www.exept.de) has recently been ported to NT.
We have a large machine control system written in VisualWorks that we ported to Linux one afternoon (in about 45 minutes) -- the only difficulties were external Windows DLL calls that we were making (e.g., bring up the native windows file dialog).
Slashdot Mirror
I don't have much experience with cable modems, but what I've seen is that latencies can be highly variable. This is really bad for VoIP.
I have two high-speed circuits and I am a Vonage subscriber. My main router box is configured to use the DSL route for voice; the wireless link gave me too much drop-out.
Is my experience with Cable circuits atypical, or have others experienced the same thing. And is anybody using a VoIP service over cable who can report?
I've owned about 7 mini-ITX boxes, and 3 of them have had motherboard flaws when I unpacked them (2 had bad network ports, and one had no USB). Another one worked for a month or so before the network port went bad. Still another only boots about 2 out of every three times I push the power button on. I end up having to use the one PCI slot for an extra network card just to get the network to work. Has anyone else experienced issues like this?
I am not one to give up easily on something like this. The form factor and lower power consumption of these boards is very cool. But I've given up on Via's EPIA and EPIA-M.
Instead of the EPIA platform, I'm now deploying servers based on the Total Impact BriQ. And I'm much happier. I didn't need Firewire, USB (except for keyboard, and the BriQ has a serial port instead), or fancy graphics (BriQ has none, unless you count the VFD, heh). But they make slick servers.
And they run Debian/PPC nicely, but you have to use a network install to get it software on there.
While searching for a new diaper bag (the cheap ones only seem to last through 1 kid), I was amazed at how many Google search hits pointed back to eBags. You wouldn't always know it from the URLs, though. Some of the URLs were things like ebags-discount.com, bagsdirect.com, handbags.com, etc., making you think that there were several big bag retailers out there. Others were just plain insane; I remember one that was something like "best-basketball-bags-for-women-athletes.com".
Effectively, they circumvented Google's "site grouping" wherein all hits from one site get clustered under a smaller group. I got fed up with it and resolved not to buy anything from eBags.
But I thought to myself, "maybe they're Scientologists..."
When you're dealing with millions of users and millions of pages, transitions take time. The move away from tabular layouts is a good idea. New sites should try to minimize their use of tabular layouts -- better yet, use a simple layout that maximizes content area. But the move away from tables as a whole will take time.
Others have already pitched the positives, so here are a few of the negatives. There are a couple of things that I see as real problems with the STL. Having just gone through a small-scale STL development project, I've come away with a really bad taste in my mouth. Here's why.
With the STL, C++ has finally aquired a part of what Smalltalk and Java have always had: a library of base classes. With these sorts of capabilities, you tend to start thinking about your system in more object-oriented terms. This is a good thing in itself, but C++ just doesn't go there with the ease that other languages do.
For example, the OO notion of polymorphism goes completely against C++'s strong typing (and C++ is even more finicky in its type checking than C is). In a true OO system, I don't care what kind of object I have in my hands, I just care that it does a certain thing. This is where late-bound OO languages like Smalltalk and Objective C shine.
Also, as your project progresses and you factor your code into neat little objects, file-based source code navigation becomes a real bear. IDEs like Source Navigator can help with this, but you still have to do double-entry bookkeeping for your prototypes and function declarations.
Why didn't we see these problems before the STL? Because we never tried to use C++ as much more than a superset of C. With the STL, we had the opportunity to build things that were more like our other OO systems, so we did. And that's where we started to get bogged down.
One other thing: We had more discussions about coding style in a few weeks of STL coding than we ever had in our non-STL C++ coding. Perhaps that was because more of us were involved in the project. But I think that, at the heart of it, the STL gives some people a feeling that C++ code can has a chance of being "elegant", and there is a real tendency to push yourself to try to achieve it. Without the STL, we all just knew that C++ was bubble gum and bailing wire. It happened to get the job done for us, and we didn't bicker about style.
Perhaps your situation is different, but if I had to make the call, I'd say your time might be better spent learning something else.
- True Object-Orientation: Smalltalk-80 was developed at Xerox PARC under the leadership of Alan Kay, who coined the term "Object-Oriented". In Smalltalk, everything is an object -- there are no primitive types. Simpler is better.
- Elegant Syntax: it's not like C, C++, or Java -- and why would you want it to be? OO is a new paradigm, and we can all use some help thinking in new ways
- Bit-compatible across platforms: All that's needed to switch platforms is a new virtual machine. Think Java+Swing on steroids (after 20 years of smoothing wrinkles out). VisualWorks runs on Linux, Windows, Mac, Solaris, HP-UX, and more -- and it's done these things for years.
- Fast Object Engine (Virtual Machine)
- Refactoring Browser: effortlessly refactor your code with this powerful tool
Needless to say, I'm sold -- and I'm never going back to a C-style OO language.--
Signal Ground: Linux Hardware news and reviews
We have a large machine control system written in VisualWorks that we ported to Linux one afternoon (in about 45 minutes) -- the only difficulties were external Windows DLL calls that we were making (e.g., bring up the native windows file dialog).
See also: www.whysmalltalk.com