Oh yea, that takes me back. I checked off all of the boxes as you went down the list. Controllers separate from the drives... replaced the controller and the drive was hosed. The whole debug to format was a joy. You were really cooking if you had RLL or ESDI. You were somehow "overclocking" your drive if it could take a 1:1 interlace (or non-interlaced in this case). You'd have to experiment with 2:1 or 3:1 to find out which worked best. You felt cheated if you couldn't get at least 2:1 working. It took hours between tests because you forked over big bucks for a 20 MB Seagate! Lest we not forget the two cables with those marvelous tab connectors.
Holy Sh!t. Reading your comment just may just explain the strange phenomena I felt when I was a kid. A few days before Mount St. Helens blew we experienced eerie weather conditions. I have told this story to a number of people over the years, how there was a really strange shift in conditions. I lived near Battle Ground, WA, which is 50mi. SSW of St. Helens. It was 8pm or so in the evening and time to suit up and head down to the barn to feed the horses. Two steps out the door and WHAM - warm, dead air. So warm it gave me the creeps! So strange that to this day I can remember vividly where I stood and my surroundings well past dusk. I went back in and shed my jacket and told my brother to come outside and check it out and then proceeded to check the news to see if she finally blew, not yet, but days laters.
So perhaps this radon precedes volcanic eruptions too?
(Hmm, your message was posted exactly 31 years and 6 hours after the eruption.)
This "focal point" issue is similar to the problems I have with the multi-speaker audio formats like 5.1, 7.1, etc. which are all really an attempt to create 3D sounds. Over 15 years ago I bought a high-end Yamaha sound field processor (A2070) that could mimic live venues to recreate 3D sound environments. It did a stunning job, hands down! It drove the L/R main, front effects, rear effects, center channel (or two!) and the sub making it the original form of 7.1 although there were not 8 separate recorded channels, it just used the 2CH Pro Logic decoding. Years later the idea of recording a track for each channel evolved, 5.1 then 7.1, which I thought would be cool and ideal, but that is where it all went wrong.
The studios do such a poor job of simulation when recording the separate channels, it becomes a huge distraction. First, most people are less affected by audio than visual effects, but it is a HUGE distraction to hear a sound behind you. Your focal point is watching a 2D image that sits in "stage" in front of you and yet you can hear sound from behind you? Your mind will immediately tells you this is wrong. The stage is in front of you and this fantasy world starts at the stage and goes forward, not behind you.
Second, this positional sound became a gimmick and abused by studios. These almost random and poorly timed effects are the bane of movie watching. I don't know which is more distracting, an entirely discrete sound effect (not at all blended with the other channels) going off behind my head, or someone's cell phone ringing. They both have the same annoying effect, although I don't think it will give you a headache like the 3D video will.
Like I said, most people are not as affected by audio artifacts, as much as visual ones, but I was amused watching the Super Bowl in HD at a friends house. Every so often they would attempt to immerse the home audience in the game by cutting off the color commentators and taking a live shot from the stands, meanwhile saturating all 5.1 channels with sounds from the arena, basically a bunch of clapping and cheers. Each time they did this, my host would look up annoyed at his speakers and queried me about their placement. He even declared that he used the microphone to balance the channel volumes, but complained that often times too much sound would come from the effect speakers. I felt better knowing that I was not the only one.
Overall, I think this article is far too premature. The last paragraph says it all "The great thing about both suites, however, is that your decision need not be set in stone." In other words, there was nothing really to compare nor contrast. With the lead of "side by side" comparison, one would at least expect some form of tabular results. I got the feeling the author wanted to make the case for OO by mentioning the Win7 install issues and "hopefully this is a bug that will be resolved soon", and that paid support would be a requirement for larger installations which LO does not have (officially). But after running the cost figures for 100 users, dropping $9,000 for OO in the cited example would set a fair amount of stone.
The aerial nature of the ropeway system has the advantage over rough terrain, where roads and rail would have to zig zag through energy robbing country. But because we have already adapted our transportation systems to relatively flat areas, especially long haul expressways, I agree that railroads are better. Really, they are just opposite of one another; trains have wheels on the cars which run on the fixed rail, and the ropeway is a moving "rail" on a fixed set of wheels.
An advantage of the ropeway over the railway is the size of unit transferred; aka packet size and frequency. Railway systems don't adapt well to all the potential uses, the exchange points are extremely inefficient and the rigid one-size-fits-all packet that usually requires a very large often heavy cargo to justify the choice. Ropeway systems offer a smaller, more manageable packet size combined with a higher frequency to achieve a higher throughput. In the ropeway system, new shipping containers are available with high frequency and their delivery time is constant but not all loads can be divided into smaller units.
Why not build a flatbed light rail system? Electric driven, computer routed, flatbeds on rail that could haul individual cars, trucks, delivery trucks or even full size tractor-trailers. Drive into the station, drive on to your individual flatbed cart, use your id and set your destination (cell phone app?). The cart then autonomously pulls into the main line, speeds you to your destination and exits, and you drive off. All that is required is different staging areas to support different vehicle sizes. Carts could be designed to connect and cooperate in such a way where perhaps four smaller car platforms could join to make a truck platform.
For the most part, the freeway system would only need three tracks, one in each direction and a bypass rail for emergencies or high traffic. As mentioned by another poster, it is usually the exchange points that are inefficient; eg. loading/unloading of rail cars, or passengers parking at a metro station and boarding light rail. In this case, you drive on the next available cart and go. Currently, trains as a whole must stop and start to pickup cargo/passengers along the way. The energy loss is tremendous and the patience of the passengers taxed having to stop at every station.
With the flatbed rail system, you get the smaller packet size, higher frequency and constant delivery times afforded by the ropeway system, plus you get the long haul, larger load capability of rail.
It seems this comparison would be much more interesting if it were based on dollars and not units. This article makes as much sense as saying "the sale of toothpicks is outpacing chopsticks". BTW, I don't plan on doing any of my software development on my Android phone since my current seven virtual desktops is hardly enough real estate to do my work.
Normally the migration from optional to required is much more gradual, methodic and covert; more like behavioral modification. We all knew that when the stories of these first came out and they were sold as optional, but you knew the plan. I am just amazed at the speed and blatant progression.
Here is a solution I have not heard yet: quid pro quo. A passenger (victim) should be able to choose their TSA pat-down agent (assailant) and the passenger should be able to pat-down the TSA agent to the same extent. I am sure the agent selection would be just as random as the TSA passenger selection, with absolutely no profiling.
Can you imagine the liability the city has opened themselves up to? This would be an entirely different story if there was a clerical mistake. If he really wanted to get the fire put out, he should have called and said he paid the bill. At that moment, they couldn't dispute it, no matter how good they thought their accounting was, they would have had no choice but to show up and put it out. If there was a check postmarked the day prior that appeared in their mailbox, they would be screwed! "I paid that on Monday!"
...it would be like buying auto insurance after you've had a wreck and expecting the insurance company to cover you for that wreck.
Yes, what do people think the word insurance means? It is like getting a health insurance policy after you are already sick, with like a pre-existing condition, and still expecting to get coverage... oh wait... nevermind
From experience, the steeper the ridges the greater the impact. My old partner picked me up at my local airstrip in a Piper Tri Pacer (a lighter, tube and fabric airplane). We had to climb and then cross perpendicular to the ridge line, the least you can do to avoid the well known affects of a hill that rises 1000' in less than a mile. Even though we had at least 500' above the ridge, it was a bumpy ride. And when we were well past ridge face, it tipped us really hard and really fast! Thank god for padded radio headsets! It tipped us past 45 degrees in a fraction of second, with the window hitting my head and rang my bell some.
Very cool device! It does lack in accuracy. Pitted dice are off balance and the 1 will land on the bottom more often than not. That is why Vegas does not use that type of die. There is error in the machine; look closely at the video where the dice get stuck at the top.
Ah. But they were. The list was meant to highlight the milestones in the historical pendulum swing. The first web browsers were definitely dumb terminals. Dumb terminals, in the before time, used special characters in the data stream, often called Field Attribute Characters or FACs, that would signal whether or not the following characters were a data entry field, or highlighted and/or blinking text (showing my age here). The browser protocol just replaced these with verbose HTML tags (which provided only slightly more flexibility).
Add-ons are just hacks. I know that sounds bad or derogatory, but it is true. They are features the original browser designers had never imagined. Browsers are evolving, which is good, but they are way beyond their original intent and struggle to find common ground. But this goes to my case in point. As they evolve, with add-ons, to make up for what the core lacks, you are moving the pendulum back to client-side processing. You are migrating activities from the server to the client. Your client is getting fatter (richer). Why? Is the server overloaded? Bandwidth? More likely, it is to fill the gap in usefulness, by reducing the server round-trip response times.
Browser applications with add-ons are evolving to replicate the same immediacy and usefulness that we had 20 years ago with LAN-based enterprise applications. We grew fat and happy with 10Mbps of bandwidth on the LAN. And of course, eventually 10Mbps wasn't enough, many applications grew to need 100Mbps to handle client traffic. Gigabit anyone? We had to retreat to dumb terminals (browsers) to deal with the limited Internet bandwidth, which is exactly why terminals were dumb years ago, when the LAN cabling was coaxial (or twin-axial).
Remember, at the dawn of the Internet era, most people had only a 23Kbps modem. Most pages were sparse and you had to click on a link to a picture if you wanted to view it,...and wait. Therefore, the concept of HTML was nothing new, it was just a luxury that we had enough bandwidth that we could send verbose formatting, whereas before we used terminal protocols to format text responses. But of course now we have so much bandwidth, we can assemble fancy pages with ample pictures and even video content (with required add-on of course).
Why struggle with a browser to build an add-on to do your client work? Why not just build a rich client that communicates directly with the server and does exactly what you need? Lean and mean custom protocol for massive speed! It will do whatever you want and not contend with browser deficiencies and incompatibilities? Of course, this is in the context of an effective enterprise application and NOT a public portal, which is best suited for browsers.
It sounds as though you are championing the thin-client-server model with a browser. You are the "boots on the ground" that must take care of the systems. You can conveniently fix the user's computer, fire up a browser and off they go. And of course, since you know which browser works best for the application, you install the right one.
Our application is also client-server model but with a custom rich interface. It is written in Java, and in the last 8 years we've only had one incompatibility issue across operating systems. We may be the guys in the White Towers developing the software, but with our framework, we developed a deployment utility, aptly name Connex. It is a 256K program that you download to their desktop. You run it, enter your credentials, pick your app (optional), pick your server (optional) and the software installs all by itself. If the user is having a problem, even perhaps corrupt files, they can press one key (F5) before they login, and the utility will inspect each file (checksum) and replace any that are missing or invalid. What is not to love about that.
We have never encountered a cross platform incompatibility or collided with other software. If we do encounter an error, we can retrieve the Java stack traces from the user with a simple download through our user administration utility.
Since we control the whole tool chain, from client to server, including the UI, we don't spend ages getting the various browsers to behave, act consistently and suffer through the browser wars version after version.
Therefore, the browser is convenient for you, saving you time and headaches. I admit it saves time, and as a tech, it saves expensive time. But what about the user? Assuming you only need to correct such problems occasionally, the user must deal with the browser interface for hours on end. What about their convenience, time and headaches?
We've seen all of this before and we will see it again... (I've heard that line somewhere before)
The pendulum swinging...
Mainframe Era - dumb terminal + big iron server
PC Era - user independence with client side, single-user apps
PC Server Era - single-user apps hacked into multi-user apps with server file sharing/locking
SQL Era - stored procedures required to do heavy data work for clients
Internet Era - browser (dumb terminal again)
AJAX Era - swinging back to client side processing to relieve server of mundane tasks and reduce the dialog latency that breaks the user's train of thought
So where do rich clients apps fit in the pendulum swing? I think rich client apps give developers absolute control over where a process runs. They take more planning and deliberate server communications, but I believe the payoff is huge. We developed a Java rich client framework for our applications development. We develop under Linux and test and deploy to Windows users. We never tested it on Mac, yet we just had a Mac savvy user install it and run without issue!
Don't buy the argument that rich clients apps are too hard to distribute. We built our own tool that will reconcile the installed Java class files at user login. TALK ABOUT A MASSIVE TIME SAVINGS in both support and debug! It ensures all users are running the same version, all files are checksum validated, and since we deploy files at the.class level (not by the jar), it is like an rsync, often requiring less than 10KB transfers to perform an upgrade. All of this was developed before things like Sun's Webstart, except we have extended features like user authentication, and server, application and service selection all before they even start the application. These features have made managing rich client apps a breeze!
As for performance, we run rings around browsers! Our framework implements both in-memory and persistent object caching. It is a true n-tier architecture where a hierarchy of caching servers receive and broadcast updates which optimizes slower connections. For high volume customers we install a caching server behind their firewall to consolidate traffic over the net to the server.
The payoff? Users can view large sets of data, change sort orders and instantly change their view on the data, all of which occur solely on the client side. It happens quickly, without breaking the users train of thought. Our framework regularly can easily deliver 50,000 objects to a client application for them to view and manipulate, and should any one of those objects change, they will see that change immediately. Not going to happen with a browser any time soon.
We have customers running our software as a service using only a cellular connection for an office of four users. The framework is completely optimized for slow connections; once I gave a 30 minute demonstration of our inventory software using a laptop and cell connection. Afterwards, I showed them the connection stats; the total download was 4MB and the upload was 750KB. For contrast, I then spent less than five minutes browsing their current website which quickly racked up over 15MB of bandwidth.
The web has it's place. We would not expect any anonymous visitor to download and install an application. It is the right solution for the broader market, but I refused to roll back the user interface and usability 20 years and abandon the power of the desktop computer to use a web browser for enterprise solution. The web is convenient for everyone, optimal for no one.
This announcement has had an immediate impact on my use of the service. I got notice this morning that they received my returns and that I could rate the returned selections. I cringed (in anger) and figured rating them would be completely pointless. There is no way their suggestion feature will even come close with three profiles rolled into one. The signal-to-noise ratio will be pathetic with the induced noise from my wife and kids profiles.
"Fix" one part of the service and break another. Oh, and piss off your customers too.
Perhaps some miracle movie selection algorithm has evolved from their netflix prize contest, requiring all movie ratings be rolled into one profile. (Yeah, right.)
Motivated by money? Surely. Careless with greed? Likely.
Ever hear of ALR? Advanced Logic Research. I still use one of their RT-101 keyboards to this date. As a programmer I have typed over 25 million keystrokes on it over the past 19 years. It is so old, it actually has the XT-AT switch on the bottom and requires a AT-PS2 adapter. It has tactile click for great keystroke response. Above all, no @#$%ing Windoze keys!
I just literally yanked all the keys off last week for a another through cleaning, snapped it back together and it works great. In a less than civil moment during a game, I slammed the keyboard so hard I separated the bottom of the assembly and it snapped back in place.
They really don't make them like they used to.
I did not realize that many ISPs block 25. It seems rather a short sighted solution. A finger in the dike really. When will a lot of ISPs start blocking port 587? What then?
My point was when the "man in the middle" alters the behavior or conditions of the connection, the interference generates tech support time. The end user is no longer capable of configuring their own email. Even if the end user is savvy enough to debug their own connection, they will likely contact tech support to diagnose the problem. Sounds like another punish-the-innocent solution. I guess this is all part of the costly collateral damage caused by spam.
I can confirm that this is correct. We recently set out to install a new email account for a cable customer hosted on our server. They could not use us as their outbound (SMTP) server because port 25 was being blocked! I cannot believe they would have the gnads to do that. Where do I send the bill? It took us a good half hour to debug with traffic monitoring and determined no packets were making it to us.
We also have a hosted application that we discovered has issues with cable users, forcing us to send keep alive packets to avoid dropped connections. Talk about shooting themselves in the foot. Now we must send extra NO OP packets to keep the connection alive which only serves to use more of the precious bandwidth they are trying to save. Oh, get this, the connection is a premium business connection too.
I would add to this notion of diminishing impact. What about the value of time? If a quad core will run 4x but costs 7x the cost impact will diminish within two weeks of use! The 7x cost is a one time cost; say for example $500 more. The 4x impact on performance and time is forever. For an exaggerated point, if I can get four times the work done, every hour saves me three. If my time were a paltry $10 per hour, I would pay for the CPU cost difference in less than a week. Anything after that it gravy!
You might say that the article it is relates to the impact on gaming and not real work (I see encoding as real work) but quality has a cost associated with it too. Entertainment can be largely impacted by quality. It used to be said, that you are not having fun until you spend $20 per hour (circa. 2000). Heck, one might even say that bragging rights have a certain value.
Slashdot Mirror
Oh yea, that takes me back. I checked off all of the boxes as you went down the list. Controllers separate from the drives... replaced the controller and the drive was hosed. The whole debug to format was a joy. You were really cooking if you had RLL or ESDI. You were somehow "overclocking" your drive if it could take a 1:1 interlace (or non-interlaced in this case). You'd have to experiment with 2:1 or 3:1 to find out which worked best. You felt cheated if you couldn't get at least 2:1 working. It took hours between tests because you forked over big bucks for a 20 MB Seagate! Lest we not forget the two cables with those marvelous tab connectors.
Holy Sh!t. Reading your comment just may just explain the strange phenomena I felt when I was a kid. A few days before Mount St. Helens blew we experienced eerie weather conditions. I have told this story to a number of people over the years, how there was a really strange shift in conditions. I lived near Battle Ground, WA, which is 50mi. SSW of St. Helens. It was 8pm or so in the evening and time to suit up and head down to the barn to feed the horses. Two steps out the door and WHAM - warm, dead air. So warm it gave me the creeps! So strange that to this day I can remember vividly where I stood and my surroundings well past dusk. I went back in and shed my jacket and told my brother to come outside and check it out and then proceeded to check the news to see if she finally blew, not yet, but days laters.
So perhaps this radon precedes volcanic eruptions too?
(Hmm, your message was posted exactly 31 years and 6 hours after the eruption.)
This "focal point" issue is similar to the problems I have with the multi-speaker audio formats like 5.1, 7.1, etc. which are all really an attempt to create 3D sounds. Over 15 years ago I bought a high-end Yamaha sound field processor (A2070) that could mimic live venues to recreate 3D sound environments. It did a stunning job, hands down! It drove the L/R main, front effects, rear effects, center channel (or two!) and the sub making it the original form of 7.1 although there were not 8 separate recorded channels, it just used the 2CH Pro Logic decoding. Years later the idea of recording a track for each channel evolved, 5.1 then 7.1, which I thought would be cool and ideal, but that is where it all went wrong.
The studios do such a poor job of simulation when recording the separate channels, it becomes a huge distraction. First, most people are less affected by audio than visual effects, but it is a HUGE distraction to hear a sound behind you. Your focal point is watching a 2D image that sits in "stage" in front of you and yet you can hear sound from behind you? Your mind will immediately tells you this is wrong. The stage is in front of you and this fantasy world starts at the stage and goes forward, not behind you.
Second, this positional sound became a gimmick and abused by studios. These almost random and poorly timed effects are the bane of movie watching. I don't know which is more distracting, an entirely discrete sound effect (not at all blended with the other channels) going off behind my head, or someone's cell phone ringing. They both have the same annoying effect, although I don't think it will give you a headache like the 3D video will.
Like I said, most people are not as affected by audio artifacts, as much as visual ones, but I was amused watching the Super Bowl in HD at a friends house. Every so often they would attempt to immerse the home audience in the game by cutting off the color commentators and taking a live shot from the stands, meanwhile saturating all 5.1 channels with sounds from the arena, basically a bunch of clapping and cheers. Each time they did this, my host would look up annoyed at his speakers and queried me about their placement. He even declared that he used the microphone to balance the channel volumes, but complained that often times too much sound would come from the effect speakers. I felt better knowing that I was not the only one.
That would be considered a design patent, so it really doesn't count for much.
Overall, I think this article is far too premature. The last paragraph says it all "The great thing about both suites, however, is that your decision need not be set in stone." In other words, there was nothing really to compare nor contrast. With the lead of "side by side" comparison, one would at least expect some form of tabular results. I got the feeling the author wanted to make the case for OO by mentioning the Win7 install issues and "hopefully this is a bug that will be resolved soon", and that paid support would be a requirement for larger installations which LO does not have (officially). But after running the cost figures for 100 users, dropping $9,000 for OO in the cited example would set a fair amount of stone.
Same issue with Firefox 3.6.13 under Linux 2.6.26. Speed is fine at 25Mbps.
The aerial nature of the ropeway system has the advantage over rough terrain, where roads and rail would have to zig zag through energy robbing country. But because we have already adapted our transportation systems to relatively flat areas, especially long haul expressways, I agree that railroads are better. Really, they are just opposite of one another; trains have wheels on the cars which run on the fixed rail, and the ropeway is a moving "rail" on a fixed set of wheels.
An advantage of the ropeway over the railway is the size of unit transferred; aka packet size and frequency. Railway systems don't adapt well to all the potential uses, the exchange points are extremely inefficient and the rigid one-size-fits-all packet that usually requires a very large often heavy cargo to justify the choice. Ropeway systems offer a smaller, more manageable packet size combined with a higher frequency to achieve a higher throughput. In the ropeway system, new shipping containers are available with high frequency and their delivery time is constant but not all loads can be divided into smaller units.
Why not build a flatbed light rail system? Electric driven, computer routed, flatbeds on rail that could haul individual cars, trucks, delivery trucks or even full size tractor-trailers. Drive into the station, drive on to your individual flatbed cart, use your id and set your destination (cell phone app?). The cart then autonomously pulls into the main line, speeds you to your destination and exits, and you drive off. All that is required is different staging areas to support different vehicle sizes. Carts could be designed to connect and cooperate in such a way where perhaps four smaller car platforms could join to make a truck platform.
For the most part, the freeway system would only need three tracks, one in each direction and a bypass rail for emergencies or high traffic. As mentioned by another poster, it is usually the exchange points that are inefficient; eg. loading/unloading of rail cars, or passengers parking at a metro station and boarding light rail. In this case, you drive on the next available cart and go. Currently, trains as a whole must stop and start to pickup cargo/passengers along the way. The energy loss is tremendous and the patience of the passengers taxed having to stop at every station.
With the flatbed rail system, you get the smaller packet size, higher frequency and constant delivery times afforded by the ropeway system, plus you get the long haul, larger load capability of rail.
It seems this comparison would be much more interesting if it were based on dollars and not units. This article makes as much sense as saying "the sale of toothpicks is outpacing chopsticks". BTW, I don't plan on doing any of my software development on my Android phone since my current seven virtual desktops is hardly enough real estate to do my work.
Here is a solution I have not heard yet: quid pro quo. A passenger (victim) should be able to choose their TSA pat-down agent (assailant) and the passenger should be able to pat-down the TSA agent to the same extent. I am sure the agent selection would be just as random as the TSA passenger selection, with absolutely no profiling.
Can you imagine the liability the city has opened themselves up to? This would be an entirely different story if there was a clerical mistake. If he really wanted to get the fire put out, he should have called and said he paid the bill. At that moment, they couldn't dispute it, no matter how good they thought their accounting was, they would have had no choice but to show up and put it out. If there was a check postmarked the day prior that appeared in their mailbox, they would be screwed! "I paid that on Monday!"
...it would be like buying auto insurance after you've had a wreck and expecting the insurance company to cover you for that wreck.
Yes, what do people think the word insurance means? It is like getting a health insurance policy after you are already sick, with like a pre-existing condition, and still expecting to get coverage... oh wait... nevermind
So, I suspect that Christians would dearly hope that God's FB account is not limited to 5,000 friends....
Duh! Just ask any Johovah's Witness and they will tell that it is 144,000. If you want it in writing, see the Bible verse Revelation 14:1.
Look. I had problems reading his 3D message too, but all I had to do was cover one eye.
From experience, the steeper the ridges the greater the impact. My old partner picked me up at my local airstrip in a Piper Tri Pacer (a lighter, tube and fabric airplane). We had to climb and then cross perpendicular to the ridge line, the least you can do to avoid the well known affects of a hill that rises 1000' in less than a mile. Even though we had at least 500' above the ridge, it was a bumpy ride. And when we were well past ridge face, it tipped us really hard and really fast! Thank god for padded radio headsets! It tipped us past 45 degrees in a fraction of second, with the window hitting my head and rang my bell some.
Very cool device! It does lack in accuracy. Pitted dice are off balance and the 1 will land on the bottom more often than not. That is why Vegas does not use that type of die. There is error in the machine; look closely at the video where the dice get stuck at the top.
Ah. But they were. The list was meant to highlight the milestones in the historical pendulum swing. The first web browsers were definitely dumb terminals. Dumb terminals, in the before time, used special characters in the data stream, often called Field Attribute Characters or FACs, that would signal whether or not the following characters were a data entry field, or highlighted and/or blinking text (showing my age here). The browser protocol just replaced these with verbose HTML tags (which provided only slightly more flexibility).
Add-ons are just hacks. I know that sounds bad or derogatory, but it is true. They are features the original browser designers had never imagined. Browsers are evolving, which is good, but they are way beyond their original intent and struggle to find common ground. But this goes to my case in point. As they evolve, with add-ons, to make up for what the core lacks, you are moving the pendulum back to client-side processing. You are migrating activities from the server to the client. Your client is getting fatter (richer). Why? Is the server overloaded? Bandwidth? More likely, it is to fill the gap in usefulness, by reducing the server round-trip response times.
Browser applications with add-ons are evolving to replicate the same immediacy and usefulness that we had 20 years ago with LAN-based enterprise applications. We grew fat and happy with 10Mbps of bandwidth on the LAN. And of course, eventually 10Mbps wasn't enough, many applications grew to need 100Mbps to handle client traffic. Gigabit anyone? We had to retreat to dumb terminals (browsers) to deal with the limited Internet bandwidth, which is exactly why terminals were dumb years ago, when the LAN cabling was coaxial (or twin-axial).
Remember, at the dawn of the Internet era, most people had only a 23Kbps modem. Most pages were sparse and you had to click on a link to a picture if you wanted to view it, ...and wait. Therefore, the concept of HTML was nothing new, it was just a luxury that we had enough bandwidth that we could send verbose formatting, whereas before we used terminal protocols to format text responses. But of course now we have so much bandwidth, we can assemble fancy pages with ample pictures and even video content (with required add-on of course).
Why struggle with a browser to build an add-on to do your client work? Why not just build a rich client that communicates directly with the server and does exactly what you need? Lean and mean custom protocol for massive speed! It will do whatever you want and not contend with browser deficiencies and incompatibilities? Of course, this is in the context of an effective enterprise application and NOT a public portal, which is best suited for browsers.
It sounds as though you are championing the thin-client-server model with a browser. You are the "boots on the ground" that must take care of the systems. You can conveniently fix the user's computer, fire up a browser and off they go. And of course, since you know which browser works best for the application, you install the right one.
Our application is also client-server model but with a custom rich interface. It is written in Java, and in the last 8 years we've only had one incompatibility issue across operating systems. We may be the guys in the White Towers developing the software, but with our framework, we developed a deployment utility, aptly name Connex. It is a 256K program that you download to their desktop. You run it, enter your credentials, pick your app (optional), pick your server (optional) and the software installs all by itself. If the user is having a problem, even perhaps corrupt files, they can press one key (F5) before they login, and the utility will inspect each file (checksum) and replace any that are missing or invalid. What is not to love about that.
We have never encountered a cross platform incompatibility or collided with other software. If we do encounter an error, we can retrieve the Java stack traces from the user with a simple download through our user administration utility.
Since we control the whole tool chain, from client to server, including the UI, we don't spend ages getting the various browsers to behave, act consistently and suffer through the browser wars version after version.
Therefore, the browser is convenient for you, saving you time and headaches. I admit it saves time, and as a tech, it saves expensive time. But what about the user? Assuming you only need to correct such problems occasionally, the user must deal with the browser interface for hours on end. What about their convenience, time and headaches?
We've seen all of this before and we will see it again... (I've heard that line somewhere before)
So where do rich clients apps fit in the pendulum swing? I think rich client apps give developers absolute control over where a process runs. They take more planning and deliberate server communications, but I believe the payoff is huge. We developed a Java rich client framework for our applications development. We develop under Linux and test and deploy to Windows users. We never tested it on Mac, yet we just had a Mac savvy user install it and run without issue!
Don't buy the argument that rich clients apps are too hard to distribute. We built our own tool that will reconcile the installed Java class files at user login. TALK ABOUT A MASSIVE TIME SAVINGS in both support and debug! It ensures all users are running the same version, all files are checksum validated, and since we deploy files at the .class level (not by the jar), it is like an rsync, often requiring less than 10KB transfers to perform an upgrade. All of this was developed before things like Sun's Webstart, except we have extended features like user authentication, and server, application and service selection all before they even start the application. These features have made managing rich client apps a breeze!
As for performance, we run rings around browsers! Our framework implements both in-memory and persistent object caching. It is a true n-tier architecture where a hierarchy of caching servers receive and broadcast updates which optimizes slower connections. For high volume customers we install a caching server behind their firewall to consolidate traffic over the net to the server.
The payoff? Users can view large sets of data, change sort orders and instantly change their view on the data, all of which occur solely on the client side. It happens quickly, without breaking the users train of thought. Our framework regularly can easily deliver 50,000 objects to a client application for them to view and manipulate, and should any one of those objects change, they will see that change immediately. Not going to happen with a browser any time soon.
We have customers running our software as a service using only a cellular connection for an office of four users. The framework is completely optimized for slow connections; once I gave a 30 minute demonstration of our inventory software using a laptop and cell connection. Afterwards, I showed them the connection stats; the total download was 4MB and the upload was 750KB. For contrast, I then spent less than five minutes browsing their current website which quickly racked up over 15MB of bandwidth.
The web has it's place. We would not expect any anonymous visitor to download and install an application. It is the right solution for the broader market, but I refused to roll back the user interface and usability 20 years and abandon the power of the desktop computer to use a web browser for enterprise solution. The web is convenient for everyone, optimal for no one.
This announcement has had an immediate impact on my use of the service. I got notice this morning that they received my returns and that I could rate the returned selections. I cringed (in anger) and figured rating them would be completely pointless. There is no way their suggestion feature will even come close with three profiles rolled into one. The signal-to-noise ratio will be pathetic with the induced noise from my wife and kids profiles.
"Fix" one part of the service and break another. Oh, and piss off your customers too.
Perhaps some miracle movie selection algorithm has evolved from their netflix prize contest, requiring all movie ratings be rolled into one profile. (Yeah, right.)
Motivated by money? Surely. Careless with greed? Likely.
Ever hear of ALR? Advanced Logic Research. I still use one of their RT-101 keyboards to this date. As a programmer I have typed over 25 million keystrokes on it over the past 19 years. It is so old, it actually has the XT-AT switch on the bottom and requires a AT-PS2 adapter. It has tactile click for great keystroke response. Above all, no @#$%ing Windoze keys! I just literally yanked all the keys off last week for a another through cleaning, snapped it back together and it works great. In a less than civil moment during a game, I slammed the keyboard so hard I separated the bottom of the assembly and it snapped back in place. They really don't make them like they used to.
I did not realize that many ISPs block 25. It seems rather a short sighted solution. A finger in the dike really. When will a lot of ISPs start blocking port 587? What then? My point was when the "man in the middle" alters the behavior or conditions of the connection, the interference generates tech support time. The end user is no longer capable of configuring their own email. Even if the end user is savvy enough to debug their own connection, they will likely contact tech support to diagnose the problem. Sounds like another punish-the-innocent solution. I guess this is all part of the costly collateral damage caused by spam.
I can confirm that this is correct. We recently set out to install a new email account for a cable customer hosted on our server. They could not use us as their outbound (SMTP) server because port 25 was being blocked! I cannot believe they would have the gnads to do that. Where do I send the bill? It took us a good half hour to debug with traffic monitoring and determined no packets were making it to us.
We also have a hosted application that we discovered has issues with cable users, forcing us to send keep alive packets to avoid dropped connections. Talk about shooting themselves in the foot. Now we must send extra NO OP packets to keep the connection alive which only serves to use more of the precious bandwidth they are trying to save. Oh, get this, the connection is a premium business connection too.
I would add to this notion of diminishing impact. What about the value of time? If a quad core will run 4x but costs 7x the cost impact will diminish within two weeks of use! The 7x cost is a one time cost; say for example $500 more. The 4x impact on performance and time is forever. For an exaggerated point, if I can get four times the work done, every hour saves me three. If my time were a paltry $10 per hour, I would pay for the CPU cost difference in less than a week. Anything after that it gravy! You might say that the article it is relates to the impact on gaming and not real work (I see encoding as real work) but quality has a cost associated with it too. Entertainment can be largely impacted by quality. It used to be said, that you are not having fun until you spend $20 per hour (circa. 2000). Heck, one might even say that bragging rights have a certain value.