> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Marius > Sundbakken > Sent: Sunday, February 06, 2005 1:53 PM > To: [email protected] > Subject: RE: [inbox] Re: EOS The word from Sigma! > > > > > > >Compatibility issues hobble innovation. > > > > > > Yes, indeed. I'm a software engineer and backwards compatibility > > > is a major pain as the software gets older and there are more > versions to > > > support. It hobbles innovation for sure, and will eventually > cripple it. > > > >Well we certainly have proof of that, just look at the size of XP! IMO > >there is no real reason for being crippled by the need to support the old > >software or to hobble creativity or innovation. > > And size has to do with what I wrote, exactly?
Processor and RAM overhead, speed of execution, disc and memory throughput and space requirements keep growing as you try to retain backward compatibility. This makes for slower systems even thought the boxes are so much faster than they used to be. > > >If you were really innovative you would find a way to eliminate > the issues > >of compatibility with old software by changing the way you > interface your > >applications to the O/S. Just because Microsoft keeps increasing the > >number of O/S interface options doesn't mean you have to use them all. > > Hilarious. By definition innovation means change. You might have had an > awfully innovative, say, serialization engine 10 years ago. Today > it's not > going to be innovative. That means you have to stick to your old > "innovative" engine and maintain compatibility with it. Why keep compatibility with the old stuff that nobody uses. Add tags to define what an app needs to operate and only load or bind them at compile or kernel relink. This is what I do with UNIX, only link the parts you need to run. Set dates as to when obsolete software components will be phased out and provide a migration path to the replacement interfaces at the time that these new tools are created. This should be SOP but nobody is willing to start throwing out the old crap because they didn't document what they did 10-15 years ago or even lat year and they have no idea what will break if they do turn off the old baggage code. Compile to native executable code, almost nobody knows how to do this any more because everyone wants to use easier to use visual tools. I can't disagree with using visual object tools but the compiled program should result in native code, not some kind of pcode that needs even more software to run. > I don't know which fairy tale world you live in, but there's a reason why > those APIs are put there. And if you are to be competetive you often have > to use these things whether you want it or not because if you > don't support > these new things, your competetor will. And supporting every possible API help's you how? So what if your competition needs fat runtimes, make yours lean and fast and teach your marketing people the difference. > > >The core UNIX O/S remains a pretty small package even after 34+ years of > >development and lacks the API weaknesses that Windows has. Because of > >this UNIX also lacks the virtually unlimited number security issues that > >Windows has and as such enjoys very high in-core execution > efficiency and > >a very low level of security risks. > > This is funny. I've used UNIX for a long time, but UNIX is more or less > stale. Virtually nothing has happened to UNIX for a very long time. Linux > you say? I've used that too since Red Hat 3.x or earlier, and it's still > UNIX. My co-worker used to work on the VMS team. Yeah, the VMS API hasn't > changed much but nothing happens there either. Oooh, everyone, > switch to VMS. > I've used UNIX for a long time also. Most of my clients run UNIX on their internal servers. I have a commercial site that has over 90 terminals at 9 different locations in So. Cal. up and running on a 90MHz. Pentium with 64MB of RAM and 400GB of striped and mirrored SCSI HD. It has not crashed in over 5 years and has only been downed to switch over to the identical back-up system so the primary box can be cleaned and inspected once a year. This level of reliability is not unusual for the UNIX boxes I support and maintain. Lean and efficient, you can't even install XP on a system this small and yet here we have over 90 people all banging away on a small UNIX box day in day out 24/7. Now THAT'S hilarious! > That's not to say the Windows API is all that great. It isn't. > Hopefully it > will be a lot better with WinFX. > > UNIX security is somewhat of a myth, it's just the problems that are > discovered there tends to avoid the popular media attention. And > of course > there are a lot less UNIX systems than Windows systems so there's > obviously > less gain for virus, adware, and spyware writers to target it. > UNIX is not nearly as wide open as Windows is, there just are not as many security issues with UNIX as there are with Windows and when they are found they are patched. Many of the updates to UNIX are related to improving UNIX networking security and kernel stability. There are also fundamental difference in the way the UNIX O/S works and is used compared with Windows. There has been PLENTY written up and spread all over about UNIX security issues when they popup. Look at the UNIX worm that crippled the internet, unless you were not around then this was a very big deal. I think the guy that released the worm recently(?) got out of prison. > Now, the average UNIX system is configured more securly than the average > Windows is and the average UNIX user knows a hell of a lot more about > computers than the average Windows user so these two things > greatly impact > the overall secureness of the two so to speak. > Hmm, like I said, all I do is turn off everything that is not needed in the kernel for the apps and hardware to work well. I think most sites rely on hardware firewalls using NAT and SPI and turn on their routers network management to control port access, some sites also use cascading firewalls and subnet their networks controlling access through their firewalls and routers. I also do this for the Windows based networks. > -- > - Marius > * **** ******* *********************************************************** * For list instructions, including unsubscribe, see: * http://www.a1.nl/phomepag/markerink/eos_list.htm ***********************************************************
