The M$ solution represents licence fees for the OS, licence fees for the office suits, licence fees for the servers to connect them, licence fees for communications both email and web server.
I'm with you on the OS licensing issue, but not on any of the others. You don't have to buy MS Office if you run Windows, just run OpenOffice. You don't need to buy licenses for Microsoft server operating systems or client access licenses if you don't manage one of those. For a typical home user, they will never need to pay a dime for a server. For a typical office user, they will only pay for a server if they choose to run a Windows server. I don't know what you are even talking about with the email and web thing. A web server comes with many editions of Windows Vista and Windows 7, and if your edition does not, just download Apache and go. Same with email services. No sane private user would ever consider running Microsoft Exchange for themselves, it is a product aimed at businesses. There is no need for a non-geek to run a mail server and a geek knows where to get an open source mail server if he/she wants one. Most mail clients are free, including Outlook Express from Microsoft. Thunderbird and a billion other free alternatives run just fine on Windows if you don't like Outlook Express.
At the end of the day, the MS tax is about 50 bucks. MS has been creating special reduced cost versions for countries where $50 is too much, I'm sure they will continue. Much credit goes to the open source community for putting the pressure on Microsoft to do this.
So, there goes the theory that K-12 teachers are more intelligent than the average high school graduate, let's work on the salary theory. The average teacher salary in New York is almost $60,000. Not too bad. Teachers rank just behind computer scientists and dentists in average hourly pay. They also have great benefits and are some of the few people left in the US who can retire with a full pension while still of working age.
Summary: decent pay, great benefits, job security, dumb people.
Teaching is a two-tiered system. The ones that make $34,000 are not the problem. They get all the hard work and they are first to be fired if there is a cutback. Their lives resemble the lives of other hard working people outside of the school system.
The ones making $75,000 a year and up are the problems. They are on all of the boards and they are insulated from ever losing their jobs. In most systems, after the administration goes through all of the hoops that are necessary to try to terminate the employment of a tenured teacher, a review board composed of tenured teachers has to approve the termination. This is supposed to compensate for the fact that teaching is hard to evaluate. In reality, this allows the tenured teachers to create an environment where they can collectively keep their jobs in the face of almost any situation.
I'm not suggesting that the shortcut would be to "Setup.exe". That would do a download, setup, then run. I'm suggesting a shortcut to "http://apps.corp.yourcompany.com/timesheets.exe". It runs directly from the URL. I know the.Net Framework supports it, I think Java does too. Security policies are totally customizable. For example, you can allow all apps from "http://apps.corp.yourcompany.com" to execute, allow them access to corporate database servers, but deny them access to local files. The default seeting in.Net is that apps cannot be run this way.
I'm not being overly technical. A desktop app can be just as seemless is a web app in this manner. It is trivial to create a shortcut to a URL and double click it. If that URL refers to a web page, it opens in a browser. If that URL refers to an application (and your computer's security policies allow it), it runs the application. No explicit downloading or executing necessary.
The way the web works is that the website delivers content in the form of HTML, and the user agent renders it in a way specific to the device and preferences of the user. That is the reason behind the success and reach of the web. None of us feel any more entitled to read web page content without ads than we do to get up and go into the kitchen during a commercial on TV. Many of us do both without remorse.
A website operator is no more entitled to display ads on my browser than I NBC is the force me to watch commercials. Why would anyone put themselves in a position of making a living depending on revenue gained from people doing things they don't want to do? Also, if you do make a living forcing people to look at things, at least make it a point to be good at it.
1) you have a broad platform that doesn't require a separate compile for each architecture it operates on. this results in lower maintenance and support costs
Bytecode base platforms solved this problem at about the same time the web became popular. See Java and.Net. If the world would stop trying to make the web everything to everybody instead of leaving it a really good hypertext platform, then we could get back to the business of solving the application distribution problem properly.
2) there's no "downloading" and "executing". this is seamless to the end-user.
This is an illusion. There certainly is "downloading", the only difference is that the app is downloaded incrementally. Most modern websites use a lot of javascript, so there is a lot of "executing".
3) if you update the application on the web server (a single point of maintenance) it's immediately updated for every instance, unlike a download-and-run application (including those that have a "check for updates" feature)
There are alot of download-and-run applications that do a pretty good job at this. Any application as trivial as the majority of websites would have no problem doing this well. But, I'll conceded this point based on a dearth of real world application that self update well. If the web was never invented, we would likely all be running Java applications from URLs. Sprinkle in some caching and this would give the same single point of maintenance experience to desktop apps.
4) processing is shared between client and server, allowing for lower operation costs (at least from a hardware perspective)
Welcome to the 1990s. Client server computing was not invented on the web. In many cases, web apps cause far more traffic and client processing than should be necessary, making them less efficient than well-designed desktop applications. Look at the javascript in a browser based drag and drop library some day, that's far too much code for a fairly simple effect.
5) there's a perceived "speedyness". ajax requests don't require transition to a new web page. to the end user this is a powerful and positive step forward from the forms and web page-based stuff you saw back in the 90s.
There is a real "speedyness" to desktop apps. AJAX simply put web apps into the same ballpark. BTW, how many AJAX apps discard all of your current data when you hit the "back" button. Real speedy when you have to do it twice. Related anecdote: Our timesheet software at work is web based. If you fill out a time sheet on a computer you haven't used before, as you get near the bottom, the default IE 7 popup blocker kills one of the key AJAX interactions. When you disable the popup blocker, IE is nice enough to reload the page, erasing the entire 90% filled out form.
6) yes, JAVA offered much this in the early 90s, but it was slow and it took (and still takes) forever for the browser's JAVA plugin to load the first time a JAVA application is accessed. thus if feels laggy and slow, which the ajax app doesn't.
Java is quite snappy nowadays. Not Java applets, Java applications. There is a big difference. Real desktop developers don't embed their applications in web pages if they can avoid it.
People still aren't used to the fact that their apps can be de-skinned and re-skinned. Too many web developers think they are developing a pretty GUI when they are really creating hypertext. If you "think HTML", you will end up fully describing the page and adding tweaks for browser quirks after the fact. If you "think presentation", then you will hack away at a page until it looks good on the platforms you choose to test it on, but few others. Accessibility, mobile browsers, and security add-ons are just skinning techniques.
So -- yes, it is fair to blame people who hack together AJAX apps that barely work on the tested platforms and lack accessibility. Most web development I have seen resembles programming by permutation (http://en.wikipedia.org/wiki/Programming_by_permutation).
I'm not suggesting that adhering to some "one true way" of web development is a magic bullet to solve anyone's problems. But I am saying that if you take the shortcut to get to a high-level goal you are bound to create an end product that is difficult to maintain and/or has some deficiencies that are hard to diagnose or address, like accessibility. If a desktop application developer delivered a perfectly functional application that had no separation of code into layers of responsibility, it would be seen as amateur work. Web development has a different set of technologies and a different set of rules. A web page needs to be well though out at the markup layer because that is one of its integration points. Imposing presumed control over the browser agent with statements like "best viewed with Flash 9", or "please enable javascript to experience this site" simply create friction between the user and service provider. People use the web because it works for everyone. If I have to install a specific piece of software to visit a specific website, I may as well download a desktop app.
They make modular ends for solid wire, but you have to make sure that you actually buy and use them. I was suprised when I found out that all of the RJ45 modular plugs at Home Depot are of the solid/stranded type. The difference is that the stranded only ones are pointy and pierce the insultation and embed in the strands. The solid type have split taps that pinch the wire instead of piercing the center.
I've seen articles which claim the crosstalk from mixing A and B only sometimes cause link problems, but I've seen it often enough to make it a blanket rule to always, always, always go 568B. 568B is supposedly deprecated but every cable I've ever bought off the shelf, aside from crossover cable, has been wired 568B so I always stick with B.
You do realize that the only difference between A and B is the colors, don't you? If you plug a B wired patch cable into an A wired wall jack, then the orange electron jump over to the green wire and the green electrons jump over to the orange wire. However, they (the electrons, not the colored wires) stay in the same position in the connectors and the wires are twisted the same. You can literally change a 568B wired patch cable to 568A wired cable with two magic markers, a steady hand, and a lot of spare time -- without taking the ends off.
568A is recommended for wall wiring because if you plug a two pair telephone jack into a 568A wired RJ45, the wiring color scheme comes out correct at the other end. An example of this actually happening is when you go from traditional phones to voice over IP and reuse the wiring in the wall. You can often replace the 110 blocks in the communications room with patch panels.
Hmmmmm. In mid 1993, Windows NT 3.1 could give any application 2GB of virtual memory regardless of the amount of installed RAM. As long as you have a 32-bit compiler, you can create a 4MB array no problem. With Win32s ( http://en.wikipedia.org/wiki/Win32s ), you could even do it on Windows 3.11.
There was a very narrow window of time where Linux existed and 32-bit Windows wasn't yet out. It would have to be a 0.x version of Linux.
The third party virtualization platforms may be free, but Microsoft will probably require a license to run XP on it. Microsoft's solution includes the XP license. There is also the unanswered question of support. Microsoft will stop supporting XP some day. Most likely, that will include a licensed instance of XP on a third party virtualization platform. However, they are likely to support XP on Windows 7 since it comes included with Windows 7, which will be still under support.
Fiber, really? So he should upgrade his relatively inexpensive and easy to maintain copper wiring plant to fiber that is at least ten times as expensive, requires special training and tools (that you don't have) to troubleshoot and repair, and is comparatively very fragile. All so he can purchase NICs that cost 50 times as much and at the end of the day, he gets................ zero speed improvement. The going attainable state of the art in fiber is 1GB/s, same as copper. If you want to splurge, 10Gb/s is available, but it costs $2,000 per device. Funny thing, there are 10Gb/s copper solutions available at the same price. The only real advantages of fiber are superior distance capability and the fact that fiber is non-conductive.
A salesman came into my office in 1995, offering to install fiber-to-the-desktop to "future proof" me. Had I taken him up, I'd be here fourteen years later buying a crapload of SC to LC adapters, and spending hundreds per desktop to get 1Gb/s to the desktop. Had I ignored the nice gentleman, then I would simply use the embedded NICs in the new computers I buy and upgrade the wiring for the power users to Cat5e or Cat6. The wiring upgrade would cost less per desktop than the original fiber investment, even ignoring the fact that I would have had to spend 1995 money on the fiber. All this is ignoring the fact that fiber ports on switches are about $300 per port, while copper ports are closer to $100 per port.
Fiber to the desktop is the same waste of money today that it was in 1995. The only exceptions are those places where fiber is necessary. Extra security, running wires between buildings (grounding issues), going very long distances; these are some valid reasons for running fiber to specific workstations.
I see it as big company politics as usual. I now work at a big company, the small company I worked at was newly acquired a short time ago. My first big project after the acquisition went through all of the corporate eyeballs for standards compliance. My $150,000 fully-redundant, major vendor hardware, 3-hour on-site support VMware cluster design (ground-up, including network infrastructure) got corporate standardized to a $500,000 fully-redundant, major vendor hardware (much of it Cisco this time), 3-hour on-site support design. The explanation given was "We save time and money by not having to learn how to support a second vendor's hardware". There was no allowance for discussion on the fact that we have a bunch of their hardware here already and we are already effectively supporting it, or that outsourcing support to someone who is trained and capable would cost one tenth of the $350,000 difference over the life of the hardware.
At the end of the day, it turned out exactly like the US broadband situation, we paid three and a half times as much to get one-tenth of the capabilities. The bandwidth killer was that we spec'd dual 10G copper directly to a blade chassis, but the corporate standard was 1GB fiber between switches and 100M copper to nodes, including servers.
You hit the nail on the head - it isn't being used properly. My main point was that Microsoft has provided all of the tools and education to make this problem go away. The problem lies 100% in the hands of the application developers. 99.9% of the things that make Windows suck were caused by programmers writing Windows applications that broke some important rules and caused the system to be less secure or less stable.
In you original post, you assigned blame to Microsoft for "DLL hell". My response was intended to redirect the blame to application vendors who aren't doing what they have been told to do a million times. It is worth noting that the most egregious violators of application design practices do so intentionally either as a way to get their software in places it doesn't belong (I'm looking at you Adobe), or to enforce some draconian form of licensing or activation. The deviation from the design standard almost always hurts the user and benefits the vendor.
Any chance you didn't watch the four hour mini-series that preceeded season 1? If you have seen it and you still have those questions, then you won't really get any good examples of pre-war life on Caprica until the last few episodes of the last season. There will be a lot of scenes on post-war Caprica in season two.
Applications don't need to supply depedencies, they simply install the compatible version of the DLL and use it. The DLL publisher can then assign "upgrade policies" to direct all or specific applications to use a newer version when it gets installed. Applications can override those policies with their own policies. None of this is typically done by the user, it is usually done by the application maintainers and the DLL maintainers. However, the policies are text files and are completely accessible to the power user for troubleshooting and experimentation. The whole process is complicated and error-prone, just like Linux package management.
For portable applications, it depends on the type of portability. For example, if you have a CD-based application and the goal is to have a no-install application, but it is intended to be used on the user's own computer, then the same rules that are followed for permanently installed applications should work great. However, if it is a "nomadic application", then the only reasonably secure solution I can think of is to store the user preferences on the portable media, but in a distinct folder. There are also other variations on this theme. For example, if the nomadic user travels around a sigle subset of computers, like all workstation on a college campus, then Windows roaming profiles would carry the preferences from computer to computer and the configuration data would reside in the normal locations.
As for shared components, simply install them as if they were a separate application. Windows has several location technologies to find shared components, so it is actually trivial to implement. There is the 1980s solutions of including the location of the shared component in the PATH environment variable. In the 1990s, COM made it possible to put the location of the shared component in the registry and reference it using a GUID. And in the 21st century,.Net added the "Global Assembly Cache", a location where all versions of all shared components could be stored.
The registry isn't for storing files. The app should expect them to be put in the "All Users" profile if they are to be available to all users.
HKLM, the windows directory, the all users profile, and the app directory are all places the are available to everyone, but they are not interchangeable.
HKLM is for setting relevant that are not user specific
The all users profile is for files that should be used by all users. Looking on my computer in "C:\Documents and Settings\All Users\Application Data", I see a ton of files but there by at least ten applications, so it is actually used in the real world.
The application directory is for the application. If you work on the team that develops the application, feel free to put stuff there. If you don't, stay out of it.
The Windows directory is for the files that comprise Windows. If you work on the team that develops Windows, feel free to put stuff there. If you don't, stay out of it.
You mean like providing the capability to install any and all versions of a DLL simultaneously and providing various runtime policies to decide which version an app actually loads or even to globally redirect version x to version y if you choose to do so? They invented that eight years ago with the.Net Framework and it's called "Side by Sidee Assemblies". It's not Microsoft's fault that it's not being used properly.
I just looked on Dell's website and M600 blade servers cost about the same as HP BL460 servers, so at least a $50,000 chunk of the solution is very close in price between HP and Dell. Dell would have to give away a free loaded chassis to have more than a 5% edge in price. If you have better information, please share.
Also, I happen to know HP's blade system well enough to know its benefits and to know that there are HP blade system components available today that would allow one to build a system very similar to the California idea from the OP. I don't know enough about Dell's blade system to make the same comparison intelligently, and I couldn't find a SAN blade on Dell's website. Therefore, I compared the GGP's proposal of 10 PE1950s to an HP blade solution to show that blades are actually reasonably priced, as long as you buy a crapload of them at the same time.
Besides, my example made my point that 1U servers weren't necessarily the cheapest way to go about making an 80 core farm. It doesn't matter that I compared a Dell solution to an HP solution. The GGP brought up Dell and I happen to know HP blades.
With an HP c-class chassis, you can get 80 cores, 320GB of RAM, and 5TB of iSCSI storage in one package for about $70,000 retail. Ten HP BL460s plus the chassis costs about the same as ten PE1950s, saves 6U, uses less power, fewer cables to manage, fewer network ports needed (you can get away with as little as one trunk and one management port). For a fully redundant configuration, you can use two trunks and two management ports instead of 20 server ports and 10 management ports for the 1U servers. That saves a few thousand in networking alone. The 5TB SAN fits in the same chassis and uses no additional space or wiring.
The most interesting part is that you can buy all Cisco networking gear for the chassis if you choose, making it functionally identical to the California concept.
Authorized user attacks are among the most common and often the most dangerous. Here is a simple way that one happens:
Developer writes a back-end service that modifies data. Developer then creates a front-end web app that calls the service. Developer codes security by coding the server-side code of the web app to refuse to call the back end if a user doesn't have sufficient authority to perform the target action. This scheme works fine as long as the back-end service is only accessible from the front-end. As the app is "upgraded" to an AJAX app, the back-end is made directly callable via http from the client. Oops, a security hole has been created that the QA department will likely not find.
If QA uses a fuzz tool, and the back-end has an authentication scheme that is shared with the front-end (like cookies), the tool will not find the hole. We have just created a security flaw where any valid user can access any application functionality.
A lot of people have been doing security in the presentation layer for years and some of them don't realize that AJAX gives clients an easy way to bypass the presentation layer. It doesn't matter how well designed the authentication system is if the attacker is a valid user.
Most of my servers are at under 5% utilization because they were purchased for a specific project and whatever crackpot software we are running on them requires a dedicated server. This is the problem that virtualization is supposed to solve, but the same crackpot software vendor refuses to support it if we virtualize the server. Server consolidation is out of the question for me most of the time.
BTW, I've never seen MS recommend a specific workload for a server. They'll gladly support a tiny overloaded box with way too many clients on it. I've got a 900GB "dumping ground" shared folder accessed all day long by 100 people on a 7 year old single processor Xeon server with 512MB of RAM. The server has no processor or memory problems, the bottleneck is all IO.
I've got problems with a lot of software vendors. Microsoft is not anywhere near the top of the list of vendors I would like to see go away.
Slashdot Mirror
The M$ solution represents licence fees for the OS, licence fees for the office suits, licence fees for the servers to connect them, licence fees for communications both email and web server.
I'm with you on the OS licensing issue, but not on any of the others. You don't have to buy MS Office if you run Windows, just run OpenOffice. You don't need to buy licenses for Microsoft server operating systems or client access licenses if you don't manage one of those. For a typical home user, they will never need to pay a dime for a server. For a typical office user, they will only pay for a server if they choose to run a Windows server. I don't know what you are even talking about with the email and web thing. A web server comes with many editions of Windows Vista and Windows 7, and if your edition does not, just download Apache and go. Same with email services. No sane private user would ever consider running Microsoft Exchange for themselves, it is a product aimed at businesses. There is no need for a non-geek to run a mail server and a geek knows where to get an open source mail server if he/she wants one. Most mail clients are free, including Outlook Express from Microsoft. Thunderbird and a billion other free alternatives run just fine on Windows if you don't like Outlook Express.
At the end of the day, the MS tax is about 50 bucks. MS has been creating special reduced cost versions for countries where $50 is too much, I'm sure they will continue. Much credit goes to the open source community for putting the pressure on Microsoft to do this.
Paid a salary that is pathetically poor for people of high intelligence and education.
For as long as I can remember, college students declaring their major as teaching have had horrible SAT scores. Here is a recent example: http://blogs.tampabay.com/schools/2008/09/sat-scores-of-t.html
So, there goes the theory that K-12 teachers are more intelligent than the average high school graduate, let's work on the salary theory. The average teacher salary in New York is almost $60,000. Not too bad. Teachers rank just behind computer scientists and dentists in average hourly pay. They also have great benefits and are some of the few people left in the US who can retire with a full pension while still of working age.
Summary: decent pay, great benefits, job security, dumb people.
Teaching is a two-tiered system. The ones that make $34,000 are not the problem. They get all the hard work and they are first to be fired if there is a cutback. Their lives resemble the lives of other hard working people outside of the school system.
The ones making $75,000 a year and up are the problems. They are on all of the boards and they are insulated from ever losing their jobs. In most systems, after the administration goes through all of the hoops that are necessary to try to terminate the employment of a tenured teacher, a review board composed of tenured teachers has to approve the termination. This is supposed to compensate for the fact that teaching is hard to evaluate. In reality, this allows the tenured teachers to create an environment where they can collectively keep their jobs in the face of almost any situation.
I'm not suggesting that the shortcut would be to "Setup.exe". That would do a download, setup, then run. I'm suggesting a shortcut to "http://apps.corp.yourcompany.com/timesheets.exe". It runs directly from the URL. I know the .Net Framework supports it, I think Java does too. Security policies are totally customizable. For example, you can allow all apps from "http://apps.corp.yourcompany.com" to execute, allow them access to corporate database servers, but deny them access to local files. The default seeting in .Net is that apps cannot be run this way.
I'm not being overly technical. A desktop app can be just as seemless is a web app in this manner. It is trivial to create a shortcut to a URL and double click it. If that URL refers to a web page, it opens in a browser. If that URL refers to an application (and your computer's security policies allow it), it runs the application. No explicit downloading or executing necessary.
The way the web works is that the website delivers content in the form of HTML, and the user agent renders it in a way specific to the device and preferences of the user. That is the reason behind the success and reach of the web. None of us feel any more entitled to read web page content without ads than we do to get up and go into the kitchen during a commercial on TV. Many of us do both without remorse.
A website operator is no more entitled to display ads on my browser than I NBC is the force me to watch commercials. Why would anyone put themselves in a position of making a living depending on revenue gained from people doing things they don't want to do? Also, if you do make a living forcing people to look at things, at least make it a point to be good at it.
1) you have a broad platform that doesn't require a separate compile for each architecture it operates on. this results in lower maintenance and support costs
Bytecode base platforms solved this problem at about the same time the web became popular. See Java and .Net. If the world would stop trying to make the web everything to everybody instead of leaving it a really good hypertext platform, then we could get back to the business of solving the application distribution problem properly.
2) there's no "downloading" and "executing". this is seamless to the end-user.
This is an illusion. There certainly is "downloading", the only difference is that the app is downloaded incrementally. Most modern websites use a lot of javascript, so there is a lot of "executing".
3) if you update the application on the web server (a single point of maintenance) it's immediately updated for every instance, unlike a download-and-run application (including those that have a "check for updates" feature)
There are alot of download-and-run applications that do a pretty good job at this. Any application as trivial as the majority of websites would have no problem doing this well. But, I'll conceded this point based on a dearth of real world application that self update well. If the web was never invented, we would likely all be running Java applications from URLs. Sprinkle in some caching and this would give the same single point of maintenance experience to desktop apps.
4) processing is shared between client and server, allowing for lower operation costs (at least from a hardware perspective)
Welcome to the 1990s. Client server computing was not invented on the web. In many cases, web apps cause far more traffic and client processing than should be necessary, making them less efficient than well-designed desktop applications. Look at the javascript in a browser based drag and drop library some day, that's far too much code for a fairly simple effect.
5) there's a perceived "speedyness". ajax requests don't require transition to a new web page. to the end user this is a powerful and positive step forward from the forms and web page-based stuff you saw back in the 90s.
There is a real "speedyness" to desktop apps. AJAX simply put web apps into the same ballpark. BTW, how many AJAX apps discard all of your current data when you hit the "back" button. Real speedy when you have to do it twice. Related anecdote: Our timesheet software at work is web based. If you fill out a time sheet on a computer you haven't used before, as you get near the bottom, the default IE 7 popup blocker kills one of the key AJAX interactions. When you disable the popup blocker, IE is nice enough to reload the page, erasing the entire 90% filled out form.
6) yes, JAVA offered much this in the early 90s, but it was slow and it took (and still takes) forever for the browser's JAVA plugin to load the first time a JAVA application is accessed. thus if feels laggy and slow, which the ajax app doesn't.
Java is quite snappy nowadays. Not Java applets, Java applications. There is a big difference. Real desktop developers don't embed their applications in web pages if they can avoid it.
People still aren't used to the fact that their apps can be de-skinned and re-skinned. Too many web developers think they are developing a pretty GUI when they are really creating hypertext. If you "think HTML", you will end up fully describing the page and adding tweaks for browser quirks after the fact. If you "think presentation", then you will hack away at a page until it looks good on the platforms you choose to test it on, but few others. Accessibility, mobile browsers, and security add-ons are just skinning techniques.
So -- yes, it is fair to blame people who hack together AJAX apps that barely work on the tested platforms and lack accessibility. Most web development I have seen resembles programming by permutation (http://en.wikipedia.org/wiki/Programming_by_permutation).
I'm not suggesting that adhering to some "one true way" of web development is a magic bullet to solve anyone's problems. But I am saying that if you take the shortcut to get to a high-level goal you are bound to create an end product that is difficult to maintain and/or has some deficiencies that are hard to diagnose or address, like accessibility. If a desktop application developer delivered a perfectly functional application that had no separation of code into layers of responsibility, it would be seen as amateur work. Web development has a different set of technologies and a different set of rules. A web page needs to be well though out at the markup layer because that is one of its integration points. Imposing presumed control over the browser agent with statements like "best viewed with Flash 9", or "please enable javascript to experience this site" simply create friction between the user and service provider. People use the web because it works for everyone. If I have to install a specific piece of software to visit a specific website, I may as well download a desktop app.
They make modular ends for solid wire, but you have to make sure that you actually buy and use them. I was suprised when I found out that all of the RJ45 modular plugs at Home Depot are of the solid/stranded type. The difference is that the stranded only ones are pointy and pierce the insultation and embed in the strands. The solid type have split taps that pinch the wire instead of piercing the center.
I've seen articles which claim the crosstalk from mixing A and B only sometimes cause link problems, but I've seen it often enough to make it a blanket rule to always, always, always go 568B. 568B is supposedly deprecated but every cable I've ever bought off the shelf, aside from crossover cable, has been wired 568B so I always stick with B.
You do realize that the only difference between A and B is the colors, don't you? If you plug a B wired patch cable into an A wired wall jack, then the orange electron jump over to the green wire and the green electrons jump over to the orange wire. However, they (the electrons, not the colored wires) stay in the same position in the connectors and the wires are twisted the same. You can literally change a 568B wired patch cable to 568A wired cable with two magic markers, a steady hand, and a lot of spare time -- without taking the ends off.
568A is recommended for wall wiring because if you plug a two pair telephone jack into a 568A wired RJ45, the wiring color scheme comes out correct at the other end. An example of this actually happening is when you go from traditional phones to voice over IP and reuse the wiring in the wall. You can often replace the 110 blocks in the communications room with patch panels.
Hmmmmm. In mid 1993, Windows NT 3.1 could give any application 2GB of virtual memory regardless of the amount of installed RAM. As long as you have a 32-bit compiler, you can create a 4MB array no problem. With Win32s ( http://en.wikipedia.org/wiki/Win32s ), you could even do it on Windows 3.11.
There was a very narrow window of time where Linux existed and 32-bit Windows wasn't yet out. It would have to be a 0.x version of Linux.
The third party virtualization platforms may be free, but Microsoft will probably require a license to run XP on it. Microsoft's solution includes the XP license. There is also the unanswered question of support. Microsoft will stop supporting XP some day. Most likely, that will include a licensed instance of XP on a third party virtualization platform. However, they are likely to support XP on Windows 7 since it comes included with Windows 7, which will be still under support.
Fiber, really? So he should upgrade his relatively inexpensive and easy to maintain copper wiring plant to fiber that is at least ten times as expensive, requires special training and tools (that you don't have) to troubleshoot and repair, and is comparatively very fragile. All so he can purchase NICs that cost 50 times as much and at the end of the day, he gets................ zero speed improvement. The going attainable state of the art in fiber is 1GB/s, same as copper. If you want to splurge, 10Gb/s is available, but it costs $2,000 per device. Funny thing, there are 10Gb/s copper solutions available at the same price. The only real advantages of fiber are superior distance capability and the fact that fiber is non-conductive.
A salesman came into my office in 1995, offering to install fiber-to-the-desktop to "future proof" me. Had I taken him up, I'd be here fourteen years later buying a crapload of SC to LC adapters, and spending hundreds per desktop to get 1Gb/s to the desktop. Had I ignored the nice gentleman, then I would simply use the embedded NICs in the new computers I buy and upgrade the wiring for the power users to Cat5e or Cat6. The wiring upgrade would cost less per desktop than the original fiber investment, even ignoring the fact that I would have had to spend 1995 money on the fiber. All this is ignoring the fact that fiber ports on switches are about $300 per port, while copper ports are closer to $100 per port.
Fiber to the desktop is the same waste of money today that it was in 1995. The only exceptions are those places where fiber is necessary. Extra security, running wires between buildings (grounding issues), going very long distances; these are some valid reasons for running fiber to specific workstations.
I see it as big company politics as usual. I now work at a big company, the small company I worked at was newly acquired a short time ago. My first big project after the acquisition went through all of the corporate eyeballs for standards compliance. My $150,000 fully-redundant, major vendor hardware, 3-hour on-site support VMware cluster design (ground-up, including network infrastructure) got corporate standardized to a $500,000 fully-redundant, major vendor hardware (much of it Cisco this time), 3-hour on-site support design. The explanation given was "We save time and money by not having to learn how to support a second vendor's hardware". There was no allowance for discussion on the fact that we have a bunch of their hardware here already and we are already effectively supporting it, or that outsourcing support to someone who is trained and capable would cost one tenth of the $350,000 difference over the life of the hardware.
At the end of the day, it turned out exactly like the US broadband situation, we paid three and a half times as much to get one-tenth of the capabilities. The bandwidth killer was that we spec'd dual 10G copper directly to a blade chassis, but the corporate standard was 1GB fiber between switches and 100M copper to nodes, including servers.
You hit the nail on the head - it isn't being used properly. My main point was that Microsoft has provided all of the tools and education to make this problem go away. The problem lies 100% in the hands of the application developers. 99.9% of the things that make Windows suck were caused by programmers writing Windows applications that broke some important rules and caused the system to be less secure or less stable.
In you original post, you assigned blame to Microsoft for "DLL hell". My response was intended to redirect the blame to application vendors who aren't doing what they have been told to do a million times. It is worth noting that the most egregious violators of application design practices do so intentionally either as a way to get their software in places it doesn't belong (I'm looking at you Adobe), or to enforce some draconian form of licensing or activation. The deviation from the design standard almost always hurts the user and benefits the vendor.
Any chance you didn't watch the four hour mini-series that preceeded season 1? If you have seen it and you still have those questions, then you won't really get any good examples of pre-war life on Caprica until the last few episodes of the last season. There will be a lot of scenes on post-war Caprica in season two.
It seems as if you didn't even read my post. Side by Side assemblies solve all of those problems.
http://msdn.microsoft.com/en-us/library/aa376307.aspx
http://msdn.microsoft.com/en-us/library/aa375680(VS.85).aspx
Applications don't need to supply depedencies, they simply install the compatible version of the DLL and use it. The DLL publisher can then assign "upgrade policies" to direct all or specific applications to use a newer version when it gets installed. Applications can override those policies with their own policies. None of this is typically done by the user, it is usually done by the application maintainers and the DLL maintainers. However, the policies are text files and are completely accessible to the power user for troubleshooting and experimentation. The whole process is complicated and error-prone, just like Linux package management.
For portable applications, it depends on the type of portability. For example, if you have a CD-based application and the goal is to have a no-install application, but it is intended to be used on the user's own computer, then the same rules that are followed for permanently installed applications should work great. However, if it is a "nomadic application", then the only reasonably secure solution I can think of is to store the user preferences on the portable media, but in a distinct folder. There are also other variations on this theme. For example, if the nomadic user travels around a sigle subset of computers, like all workstation on a college campus, then Windows roaming profiles would carry the preferences from computer to computer and the configuration data would reside in the normal locations.
.Net added the "Global Assembly Cache", a location where all versions of all shared components could be stored.
As for shared components, simply install them as if they were a separate application. Windows has several location technologies to find shared components, so it is actually trivial to implement. There is the 1980s solutions of including the location of the shared component in the PATH environment variable. In the 1990s, COM made it possible to put the location of the shared component in the registry and reference it using a GUID. And in the 21st century,
The registry isn't for storing files. The app should expect them to be put in the "All Users" profile if they are to be available to all users.
HKLM, the windows directory, the all users profile, and the app directory are all places the are available to everyone, but they are not interchangeable.
HKLM is for setting relevant that are not user specific
The all users profile is for files that should be used by all users. Looking on my computer in "C:\Documents and Settings\All Users\Application Data", I see a ton of files but there by at least ten applications, so it is actually used in the real world.
The application directory is for the application. If you work on the team that develops the application, feel free to put stuff there. If you don't, stay out of it.
The Windows directory is for the files that comprise Windows. If you work on the team that develops Windows, feel free to put stuff there. If you don't, stay out of it.
You mean like providing the capability to install any and all versions of a DLL simultaneously and providing various runtime policies to decide which version an app actually loads or even to globally redirect version x to version y if you choose to do so? They invented that eight years ago with the .Net Framework and it's called "Side by Sidee Assemblies". It's not Microsoft's fault that it's not being used properly.
I just looked on Dell's website and M600 blade servers cost about the same as HP BL460 servers, so at least a $50,000 chunk of the solution is very close in price between HP and Dell. Dell would have to give away a free loaded chassis to have more than a 5% edge in price. If you have better information, please share.
Also, I happen to know HP's blade system well enough to know its benefits and to know that there are HP blade system components available today that would allow one to build a system very similar to the California idea from the OP. I don't know enough about Dell's blade system to make the same comparison intelligently, and I couldn't find a SAN blade on Dell's website. Therefore, I compared the GGP's proposal of 10 PE1950s to an HP blade solution to show that blades are actually reasonably priced, as long as you buy a crapload of them at the same time.
Besides, my example made my point that 1U servers weren't necessarily the cheapest way to go about making an 80 core farm. It doesn't matter that I compared a Dell solution to an HP solution. The GGP brought up Dell and I happen to know HP blades.
With an HP c-class chassis, you can get 80 cores, 320GB of RAM, and 5TB of iSCSI storage in one package for about $70,000 retail. Ten HP BL460s plus the chassis costs about the same as ten PE1950s, saves 6U, uses less power, fewer cables to manage, fewer network ports needed (you can get away with as little as one trunk and one management port). For a fully redundant configuration, you can use two trunks and two management ports instead of 20 server ports and 10 management ports for the 1U servers. That saves a few thousand in networking alone. The 5TB SAN fits in the same chassis and uses no additional space or wiring.
The most interesting part is that you can buy all Cisco networking gear for the chassis if you choose, making it functionally identical to the California concept.
Authorized user attacks are among the most common and often the most dangerous. Here is a simple way that one happens:
Developer writes a back-end service that modifies data. Developer then creates a front-end web app that calls the service. Developer codes security by coding the server-side code of the web app to refuse to call the back end if a user doesn't have sufficient authority to perform the target action. This scheme works fine as long as the back-end service is only accessible from the front-end. As the app is "upgraded" to an AJAX app, the back-end is made directly callable via http from the client. Oops, a security hole has been created that the QA department will likely not find.
If QA uses a fuzz tool, and the back-end has an authentication scheme that is shared with the front-end (like cookies), the tool will not find the hole. We have just created a security flaw where any valid user can access any application functionality.
A lot of people have been doing security in the presentation layer for years and some of them don't realize that AJAX gives clients an easy way to bypass the presentation layer. It doesn't matter how well designed the authentication system is if the attacker is a valid user.
Most of my servers are at under 5% utilization because they were purchased for a specific project and whatever crackpot software we are running on them requires a dedicated server. This is the problem that virtualization is supposed to solve, but the same crackpot software vendor refuses to support it if we virtualize the server. Server consolidation is out of the question for me most of the time.
BTW, I've never seen MS recommend a specific workload for a server. They'll gladly support a tiny overloaded box with way too many clients on it. I've got a 900GB "dumping ground" shared folder accessed all day long by 100 people on a 7 year old single processor Xeon server with 512MB of RAM. The server has no processor or memory problems, the bottleneck is all IO.
I've got problems with a lot of software vendors. Microsoft is not anywhere near the top of the list of vendors I would like to see go away.