On Tuesday, September 24, 2002, at 10:20 PM, Shaun Savage wrote: > I have seen some of the MS support people, and they are worthless. > One person spent two hours trying to hook up a 8 port hub. The docs > stated port 8 was the crossover connection but if you looked at the > hub, port 1 was. We've all seen incompetence, but extrapolating from a few individuals to conclude that Microsoft-trained techs "are worthless" doesn't help the discussion. You will find incompetence on all platforms and in all environments. > my guess is that there are about equal QUALIFIED Linux/unix <-> MS > support people. If you know the protocols, and undrestand what is > really happing, it is easier to migrate from MS to Linux than from > Linux -> MS The ease of migration from one platform to another depends on the applications; it has little to do with Windows vs. Linux. The ongoing attempts to reinvent the Windows desktop applications on Linux demonstrates that at least for those applications the migration is not so easy. For other applications, like web server apps based on ASP, migrating to Linux may cost very little. But if you have big SQL Server databases and thousands of T-SQL stored procedures that's not going to move to MySQL or even Oracle without a big fight. > This is more of procedure than tech. By creating a STD distro for the > enviroment then creating a package database for every machine, then > you will know what you have. That database for each machine is stored > on a central configuration computer. When any update are made to that > machine the changes are made in the DB on the central computer. That plan works for deploying uniform desktop systems, and in fact big companies and government agencies usually have something like that in place. It also works for racks of uniform web servers. But it doesn't really apply to servers running business applications such as Oracle, SAP, or stuff developed in-house. > I wonder what IT support is like in that environment? Having worked in a few of those environments, my experience with IT support from crap to excellent. It comes down more to the individuals running the support operation than any high-level policies or procedures. > I don't understand the question. I thought that open RFC's already > define how developers program. Only in the MS world is SMPT not the > SMTP protocol. MS removes the "<>" in <email@domain> defined by the > SMTP RFC. > > Personally I think programming to and following standards would be > good for the public. Personally I would like peace and an end to world hunger, but in the real world nothing turns out so tidy. I prefer following standards over not following standards, but if there's no standard, or the standards don't apply, you still have to do something. If everyone followed RFCs and nothing else innovation would come to a halt and all problems outside of the domain of standards would go un-done. > Will service contracts work as a business model for SW >> developers? > There would be not much difference in the way it is done now. Open > bids for a application, where the developer gets NRE. Then another > open bid for support. Because the code is released into the public > commons any person can become an expert on it. That should increase > competition and reduce price. Simply releasing source code to the public doesn't guarantee more experts. Developers need incentives beyond the public good to devote their time and energy to studying code they may not care about or ever work with. In the interesting applications--non-trivial software that isn't just off-the-shelf stuff--the problem domain and business rules mean more than understanding how some function works. Anyone can learn accounting on their own right now (the necessary information is publicly and freely available) but that doesn't in and of itself increase the number of qualified accountants. Likewise open-sourcing Smalltalk didn't create a surge in qualified Smalltalk programmers. > It is sort-of a throwback to the old IBM model of sell the >> HW for under cost and then make em pay for the maintenance. > The difference between the IBM model is that the source is open. The > state is NOT locked into one vender. The vendor does NOT have a > monopoly on the code. This is the key idea. When source code is > closed this creates a monopoly on maintaince and upgrades. This > monopoly increases price and reduces quality of both product and > service. > > > The side effect of going to open source it when one state developes a > GREAT DMV system, other states can use it. This will standardize the > DMV system across the states. This is both good and bad, it allows > for a common database format that the feds can search easier;-/ That kind of reusability could be achieved if the specs and requirements were identical, but they rarely are. I'm all for code reuse, but most developers don't have the skills to think through their design well enough to make it reusable. Most shops funding development can't afford to care about reusability beyond their budget cycle. -- Greg Jorgensen PDXperts LLC, Portland, Oregon, USA
This archive was generated by hypermail 2b30 : Tue Sep 24 2002 - 10:31:56 PDT