For example, I switched from Windows 3.1 to OS/2 2.0 back in 1992 because of the fact that it provided a better multitasking environment than DOS+Windows did -- but I used the same exact set of DOS and Windows programs on the OS/2 system that I used under Windows 3.1.
In that instance, the applications were a nonissue since I could use the same programs (and often even the same *installation* of those programs) in each environment -- I simply wanted a better platform on which to run them, and in that case the OS made a huge difference.
I also tend to use Linux rather than Windows on my fileservers at home. Why? Because I find that Linux is more flexible in terms of the options it presents for filesharing (NFS + CIFS instead of just CIFS), which makes it more compatible with the other boxes on the LAN, and I love working with things like Webmin on headless boxes.
Again, the OS is making the difference, not the applications.
You might be right for the general case these days, but that doesn't justify making such a sweeping generalization (IMO)...
The old water-cooled systems that sprawled all over the place and took several very large cabinets have been replaced over the past decade or so with CMOS boxes roughly the size of a fridge or three.
You still might need several cabinets depending on the type of peripherals attached (and automated tape silos are not small), but while the hardware is still related in terms of basic architecture, instruction set, and operating system, basic mainframe technology has come a long way in the past 10-20 years.
The Unisys Clearpath mainframes I've worked on use either MCP (for those descended from the Burroughs A-series line) or OS2200 (for those descended from the Sperry 1100-series), and IBM mainframes typically run Z/OS (descended from OS/390). You can get some idea of the size of these boxes by reading the specsheets for some of them
does an INI file system handle multiple apps concurrently writing to the same file?
A simple spin-lock mechanism on file writes should suffice.
are your INI files indexed by key name for performance?
If each application has its own INI file, it already knows the name and location of its own file, and it has very little need to know the names/locations of other INI files.
Since real filesystems store items in some sort of BTree structure, locating a file should not be that much of an issue on those few occasions where such is required.
do they easily store hierarchical data efficiently?
Most INI files store data of the form
KEYWORD = DATA
or variations thereof. With XML, for example, a data hierarchy would be easy to implement, even in a "text" file.
do they have support for per-key permissions?
???
are they easily backed-up and versioned by the operating system?
Wouldn't that be the application's job? The OS is supposed to act as a gateway between userland and system resources, not be a universal hand-holder.
Hey, I think the mechanics take enough crap in the media without folks slamming them here on Slashdot. Coleman probably thinks a "spanner" is someone who watches the US Senate all the time on cable TV and a "D check" is what Clinton let Monica do...
One of my younger brothers played sweeper in back high school (which got me interested in the sport initially -- well that, and watching the Minnesota Kicks playing at the old Met Stadium when the NASL was still around), and as I said before there are lots of things that I do appreciate in the game itself, but it's hard for me to maintain much interest in it due to a lack of presence/coverage here in the states.
You might be onto something, though. Maybe something like a two point shot from way outside the box, or three-point shots from the corners.:-)
That is a very isolated view of the process. Security is a different problem entirely.
I agree. For well-designed computer systems, some elements commonly thought of as security issues (such as buffer overflows) do not really fall into the domain of the applications programmer as you say, but application security as a whole should still be a consideration.
I've been fortunate enough to work in multiple environments where the proramming staff had the authority to trump things like "scheduled release/cutover" dates if things were not deemed ready, but I also realize that many folks don't have that luxury.
In fact, it's precisely such a "tyranny of the majority" that the US system of government was specifically designed and intended to avoid cowtowing to.
If I knew that the UN would do a better job of handling things, and if there was enough transparency and accountability in the UN and in the process of transfer, then I might support a voluntary transfer of control from the US to the UN.
However, the current attempts by the UN to wrest control through coercion are a far cry from the above.
Just because the UN happens to be an international body doesn't make it the best solution in this partiucular instance, and their Modus Operandi seems to prove that.
Speaking as a former resident of Minnesota and a former NWA employee, and with all due respect to Mr. Coleman, I hardly think he could fill the shoes of a scab at NWA, much less the shoes of one of the AMFA mechanics that used to work there.
I do think AMFA's leadership is a bunch of idiots for the way they've handled things with NWA management, but I respect the hell out of the hundreds of talented folks who kept NWA's aging aircraft flying safely for the decade or so that I worked there.
Even an accurate media portrayal of a given country presents a far less complete picture of that country than actually living in that country would present.
If you really think we don't have access to Michael Moor's documentaries here in the US, than you seem understand the US a lot less than you thought...
It's true that soccer is not yet a very popular men's sport in the US, at least above the college level, and despite multiple attempts to create and publicize professional leagues.
Since international "football" doesn't have the level of intense strategy found in American football, the speed of hockey or lacrosse, the level of athleticism found in basketball, or the intense one-on-one element of tennis or even baseball, I really don't see its status in the US changing any time soon.
I do like watching it at times, and the positional play is interesting to me, but that is not enough. It simply doesn't have much of a history here...
Heh. I'm in Atlanta now, which is pretty far south, but even we aren't within 100 miles of a coast. 200, maybe, or 250.
Chicago is over 1000 miles away from any coast, and there are at least a dozen fairly large metropolitan areas in the midwest, west, and south (Detroit, Dallas/Fort Worth, Kansas City, St. Louis, Indianapolis, Pittsburgh, Minneapolis/St. Paul, Phoenix, Denver, Las Vegas, etc.) which are 300 miles from an ocean or further.
I'd guess half the population is at least 250 miles from a coastline, though I guess it would only take 51% within 100 miles of a coast for you to be technically correct.:-)
More to the point, supercomputers are not mainframes, which were (and still are, at least in most circles) the only systems that were traditionally associated with that term, and most of the folks who assert that mainframes are dead are not working for (and have never worked for) the companies who have traditionally used Big Iron in the first place.
Those of us who still work in the airline, banking, or insurance industries know that most of the current mainframe systems aren't going anywhere. They run on Big Iron for a reason.
Eventually they will be replaced, as everything is, but IMO their eventual replacements will be mainframes in everything but name -- ultra-secure, reliable, recoverable systems acting as large-scale corporate data servers.
By having many different INI files, the loss of one file isn't going take the whole frigging system out.
I guess convenience is more important than resiliency to some, but since that's been Microsoft's approach to damn near everything for the past 20 years it doesn't surprise me in the least...
We spend way too much time bashing Microsoft and Windows. For all of their flaws (and I'll admit, there are quite a few), Microsoft has done a lot to advance personal computing.
Besides providing a common platform that folks could standardize on (something any OS vendor would have done by default were they in the same dominant position), what has Microsoft done?
The combination of Microsoft's operating system and Intel's chips have consistantly driven down the price of PC hardware to a point where many people that once could never think about affording a computer can now own one relatively easily.
I think this would have happened anyway. If Windows wasn't there, some other platform would be acting as the unifying factor, and the commoditization of PC hardware would still be occurring.
Factors like the Internet are playing a large part, also, since a connected PC is a more useful general tool.
No reason to care about details such as race, religion, etc. On the net, I'm just interested in opinions and code, but people posting here (or on USENET, or on blog sites, or on any other online forum I can think of) could have three arms and a prehensile forehead for all I care...
Oh -- I do hate militant Packers fans, though. And Braves fans, but they got theirs (again) so it doesn't matter.:-)
I'm sorry, but your machines are yesterdays hardware. You should not try to run today's software on yesterdays hardware. Like you said, your hardware runs bunch of obsolete OS'es just fine. I bet it would run DOS REALLY well. And your point is?
If those "obsolete OSes" are able to connect to modern networks and run modern applications, then perhaps they aren't so obsolete after all. DOS doesn't run Firefox, Seamonkey, or Open Office, while OS/2 and Windows 95 OSR2 do.
So, because it runs a web-browser well, you then expect it to run a full-blown modern desktop-environment with all the bells and whistles? Uh, OK....
Here's a little homework for ya: try comparing the feature lists of the WorkPlace Shell and the KDE desktop, and then get back to me about KDE being a "full-blown" version of anything.
Yeah, it's better than Windows, but so was PC/GEOS back in 1989. Bee Eff Dee.
Of course old OS'es require less resources! Hell, I bet that back in OS/2-times, 16MB was A LOT! You simply can't compare an ancient OS to something as modern as KDE, and then proclaim that KDE "wastes resources". Is OS X a pig, because the original Mac OS worked in machines that had only tiny fraction of modern Macs performance?
How do you explain the fact that OS/2 is able to do far more in that space than KDE?
The fact that OS/2 is an old system chronologically (a fallacy, BTW, as eComStation 1.2 is less than a year old and still flies on a 32MB machine) has nothing at all to do with the fact that its desktop is able to do more functionally at the same resolutions than KDE.
To me, less functionality in more space equals coade bloat regardless of the age of the software being discussed. The fact that the two systems are of roughly the same vintage makes the situation even MORE unacceptable.
What consumes performance? Well, resolutions have increased, widgets have gotten better-looking, systems have more functionality built-in (KDE for example has a system-wide spell-checker), color-depths have increased, icons looks better etc. etc. Systems have simply progressed. It is absolutely pointless to compare some obsolete OS to modern system and proclaim "this system ran just fine on 16MB of RAM, the modern system is bloated!".
I was talking about performance in 64MB, not 16MB. Video resolutions, icons, and anti-aliasing simply do not explain that kind of resource usage (OS/2 will run in 2048x1536 @ 32-bit color if you have a card that supports it, BTW, and anti-aliasing is available and works just fine on much smaller machines).
While some of your reasons are valid, my entire fscking point is that no regard is being given to folks who might not give a rats ass about transparent windows or anti-aliased fonts and would rather have a WORKING BOX that can use KDE's basic desktop without the extraneous eye candy.
I could point out that I'm aware of several businesses who are happily using hardware of the same vintage as my current LAN setup, and that the KDE folks are effectively alienating them as well, but your solution seems to be to upgrade the hardware for no other reason than to support prettier folders.
Isn't that Microsoft's message, too?
What ever happened to Linux as a small/flexible/lightweight platform??
Oops -- I had made the comment about commercial development being a possible exception in another part of the thread. Sorry for assuming that you had seen that.
Keep in mind also that I was responding to a comment about *all* software development being too complex for one person, and I know from experience that such a comment is inaccurate at best and perhaps even flat-out wrong. Sorry if you disagree, but I have enough firsthand experience on this one to have a fairly well-entrenched opinion.:-)
Sometimes a solution can cover less than 100% of all cases and still be viable.
In fact, I'd bet that very few solutions are able to cover "all" cases.
While I agree that commercial software development for external customers might actually require more (as I had explicitly noted in my original comment), that represents a fairly small minority of the entire software development universe.
(Most programmers write in-house code, not retail applications).
Producing good code is a complicated process, not something one person can do.
There are dozens (if not hundreds) of examples out there of high-quality code being produced by a single standalone programmer, some of them fairly complex applications/utilities, and that is true not only in the DOS/Windows shareware and open source software environments but also in the corporate mainframe environments where I've worked.
Yes, such folks will generally have other folks to testing over time, but often the concept, design, coding, and initial testing stages are all handled by a single person who has the technical skill, vision, and determination to create the initial solution and whip it into workable shape. Once that basic foundation is in place, feedback from others is solicited.
A person who doesn't care about quality or who isn't technically adept enough to avoid problems is probably going to produce a bad piece of software in the end regardless of the processes in place unless everyone else in the development chain holds his/her hand.
A person who is obsessed with clean code and who has a clear vision, on the other hand, can often perform amazing feats with little more than a single PC or terminal, a pizza delivery service, and a few hundred gallons of coffee (or Mountain Dew) at his or her disposal.:-)
The mainframe environment where I work does not easily allow things like buffer overruns or the executing of data to happen -- data areas are marked non-executable, memory is assigned to applications in discrete blocks and managed by the system (not the applications programmer), and the system generates a hard error whenever the IP walks outside the predefined memory area initially granted to a given process.
In an environment like that, many of the errors we hear about in a typical UNIX/C environment (e.g., buffer overflows causing input data to be executed, etc.) simply do not exist.
Good practices are a good start, of course, but there will still be the potential for serious problems as long as the platforms we use allow for an applications programmer to step on other programs and/or execute areas of memory which were not explicitly marked for execution at process start time.
Processes can aid in ensuring consistency, but they aren't strictly necessary.
I worked as a development/support programmer in a fairly critical application area for a major airline for over ten years, and we had a small tight team of a dozen fairly experienced developers and only a few formal processes in place. The software that was written and loaded in production was generally of very high quality, mainly due to a good culture of informal peer review, testing (involving users and programmers alike), heavy use of a test system to let changes simmer a bit before release, etc., but there really wasn't a formal "metholodogy" in place, just common sense practices that everyone there had agreed to follow.
For larger groups or in development environmments where software is released in bursts (e.g., a new version is released to external customers every few months) it might make more sense to put more formal processes in place, but when working on a living system that has to change from time to time in a few days (or even hours) I'd rather put my faith in a couple of experienced programmers who know the system and the expectations of the end users.
Slashdot Mirror
For example, I switched from Windows 3.1 to OS/2 2.0 back in 1992 because of the fact that it provided a better multitasking environment than DOS+Windows did -- but I used the same exact set of DOS and Windows programs on the OS/2 system that I used under Windows 3.1.
In that instance, the applications were a nonissue since I could use the same programs (and often even the same *installation* of those programs) in each environment -- I simply wanted a better platform on which to run them, and in that case the OS made a huge difference.
I also tend to use Linux rather than Windows on my fileservers at home. Why? Because I find that Linux is more flexible in terms of the options it presents for filesharing (NFS + CIFS instead of just CIFS), which makes it more compatible with the other boxes on the LAN, and I love working with things like Webmin on headless boxes.
Again, the OS is making the difference, not the applications.
You might be right for the general case these days, but that doesn't justify making such a sweeping generalization (IMO)...
It's been a lot longer than 20 years for some of us. :-)
The old water-cooled systems that sprawled all over the place and took several very large cabinets have been replaced over the past decade or so with CMOS boxes roughly the size of a fridge or three.
You still might need several cabinets depending on the type of peripherals attached (and automated tape silos are not small), but while the hardware is still related in terms of basic architecture, instruction set, and operating system, basic mainframe technology has come a long way in the past 10-20 years.
The Unisys Clearpath mainframes I've worked on use either MCP (for those descended from the Burroughs A-series line) or OS2200 (for those descended from the Sperry 1100-series), and IBM mainframes typically run Z/OS (descended from OS/390). You can get some idea of the size of these boxes by reading the spec sheets for some of them
does an INI file system handle multiple apps concurrently writing to the same file?
:-)
A simple spin-lock mechanism on file writes should suffice.
are your INI files indexed by key name for performance?
If each application has its own INI file, it already knows the name and location of its own file, and it has very little need to know the names/locations of other INI files.
Since real filesystems store items in some sort of BTree structure, locating a file should not be that much of an issue on those few occasions where such is required.
do they easily store hierarchical data efficiently?
Most INI files store data of the form
KEYWORD = DATA
or variations thereof. With XML, for example, a data hierarchy would be easy to implement, even in a "text" file.
do they have support for per-key permissions?
???
are they easily backed-up and versioned by the operating system?
Wouldn't that be the application's job? The OS is supposed to act as a gateway between userland and system resources, not be a universal hand-holder.
the windows registry does all of these.
That might explain some of its problems.
Hey, I think the mechanics take enough crap in the media without folks slamming them here on Slashdot. Coleman probably thinks a "spanner" is someone who watches the US Senate all the time on cable TV and a "D check" is what Clinton let Monica do...
One of my younger brothers played sweeper in back high school (which got me interested in the sport initially -- well that, and watching the Minnesota Kicks playing at the old Met Stadium when the NASL was still around), and as I said before there are lots of things that I do appreciate in the game itself, but it's hard for me to maintain much interest in it due to a lack of presence/coverage here in the states.
:-)
You might be onto something, though. Maybe something like a two point shot from way outside the box, or three-point shots from the corners.
That is a very isolated view of the process. Security is a different problem entirely.
I agree. For well-designed computer systems, some elements commonly thought of as security issues (such as buffer overflows) do not really fall into the domain of the applications programmer as you say, but application security as a whole should still be a consideration.
I've been fortunate enough to work in multiple environments where the proramming staff had the authority to trump things like "scheduled release/cutover" dates if things were not deemed ready, but I also realize that many folks don't have that luxury.
Hey, man, I'm not going barefoot... They've got SCORPIONS down here in Atlanta! :-)
(Okay, just little dinky ones, but still...)
In fact, it's precisely such a "tyranny of the majority" that the US system of government was specifically designed and intended to avoid cowtowing to.
If I knew that the UN would do a better job of handling things, and if there was enough transparency and accountability in the UN and in the process of transfer, then I might support a voluntary transfer of control from the US to the UN.
However, the current attempts by the UN to wrest control through coercion are a far cry from the above.
Just because the UN happens to be an international body doesn't make it the best solution in this partiucular instance, and their Modus Operandi seems to prove that.
Speaking as a former resident of Minnesota and a former NWA employee, and with all due respect to Mr. Coleman, I hardly think he could fill the shoes of a scab at NWA, much less the shoes of one of the AMFA mechanics that used to work there.
I do think AMFA's leadership is a bunch of idiots for the way they've handled things with NWA management, but I respect the hell out of the hundreds of talented folks who kept NWA's aging aircraft flying safely for the decade or so that I worked there.
Even an accurate media portrayal of a given country presents a far less complete picture of that country than actually living in that country would present.
If you really think we don't have access to Michael Moor's documentaries here in the US, than you seem understand the US a lot less than you thought...
It's true that soccer is not yet a very popular men's sport in the US, at least above the college level, and despite multiple attempts to create and publicize professional leagues.
Since international "football" doesn't have the level of intense strategy found in American football, the speed of hockey or lacrosse, the level of athleticism found in basketball, or the intense one-on-one element of tennis or even baseball, I really don't see its status in the US changing any time soon.
I do like watching it at times, and the positional play is interesting to me, but that is not enough. It simply doesn't have much of a history here...
Heh. I'm in Atlanta now, which is pretty far south, but even we aren't within 100 miles of a coast. 200, maybe, or 250.
:-)
Chicago is over 1000 miles away from any coast, and there are at least a dozen fairly large metropolitan areas in the midwest, west, and south (Detroit, Dallas/Fort Worth, Kansas City, St. Louis, Indianapolis, Pittsburgh, Minneapolis/St. Paul, Phoenix, Denver, Las Vegas, etc.) which are 300 miles from an ocean or further.
I'd guess half the population is at least 250 miles from a coastline, though I guess it would only take 51% within 100 miles of a coast for you to be technically correct.
US Law used to give them that right. That law was changed recently.
More to the point, supercomputers are not mainframes, which were (and still are, at least in most circles) the only systems that were traditionally associated with that term, and most of the folks who assert that mainframes are dead are not working for (and have never worked for) the companies who have traditionally used Big Iron in the first place.
Those of us who still work in the airline, banking, or insurance industries know that most of the current mainframe systems aren't going anywhere. They run on Big Iron for a reason.
Eventually they will be replaced, as everything is, but IMO their eventual replacements will be mainframes in everything but name -- ultra-secure, reliable, recoverable systems acting as large-scale corporate data servers.
A classic example of poor design.
By having many different INI files, the loss of one file isn't going take the whole frigging system out.
I guess convenience is more important than resiliency to some, but since that's been Microsoft's approach to damn near everything for the past 20 years it doesn't surprise me in the least...
We spend way too much time bashing Microsoft and Windows. For all of their flaws (and I'll admit, there are quite a few), Microsoft has done a lot to advance personal computing.
Besides providing a common platform that folks could standardize on (something any OS vendor would have done by default were they in the same dominant position), what has Microsoft done?
The combination of Microsoft's operating system and Intel's chips have consistantly driven down the price of PC hardware to a point where many people that once could never think about affording a computer can now own one relatively easily.
I think this would have happened anyway. If Windows wasn't there, some other platform would be acting as the unifying factor, and the commoditization of PC hardware would still be occurring.
Factors like the Internet are playing a large part, also, since a connected PC is a more useful general tool.
No reason to care about details such as race, religion, etc. On the net, I'm just interested in opinions and code, but people posting here (or on USENET, or on blog sites, or on any other online forum I can think of) could have three arms and a prehensile forehead for all I care...
:-)
Oh -- I do hate militant Packers fans, though. And Braves fans, but they got theirs (again) so it doesn't matter.
I'm sorry, but your machines are yesterdays hardware. You should not try to run today's software on yesterdays hardware. Like you said, your hardware runs bunch of obsolete OS'es just fine. I bet it would run DOS REALLY well. And your point is?
If those "obsolete OSes" are able to connect to modern networks and run modern applications, then perhaps they aren't so obsolete after all. DOS doesn't run Firefox, Seamonkey, or Open Office, while OS/2 and Windows 95 OSR2 do.
So, because it runs a web-browser well, you then expect it to run a full-blown modern desktop-environment with all the bells and whistles? Uh, OK....
Here's a little homework for ya: try comparing the feature lists of the WorkPlace Shell and the KDE desktop, and then get back to me about KDE being a "full-blown" version of anything.
Yeah, it's better than Windows, but so was PC/GEOS back in 1989. Bee Eff Dee.
Of course old OS'es require less resources! Hell, I bet that back in OS/2-times, 16MB was A LOT! You simply can't compare an ancient OS to something as modern as KDE, and then proclaim that KDE "wastes resources". Is OS X a pig, because the original Mac OS worked in machines that had only tiny fraction of modern Macs performance?
How do you explain the fact that OS/2 is able to do far more in that space than KDE?
The fact that OS/2 is an old system chronologically (a fallacy, BTW, as eComStation 1.2 is less than a year old and still flies on a 32MB machine) has nothing at all to do with the fact that its desktop is able to do more functionally at the same resolutions than KDE.
To me, less functionality in more space equals coade bloat regardless of the age of the software being discussed. The fact that the two systems are of roughly the same vintage makes the situation even MORE unacceptable.
What consumes performance? Well, resolutions have increased, widgets have gotten better-looking, systems have more functionality built-in (KDE for example has a system-wide spell-checker), color-depths have increased, icons looks better etc. etc. Systems have simply progressed. It is absolutely pointless to compare some obsolete OS to modern system and proclaim "this system ran just fine on 16MB of RAM, the modern system is bloated!".
I was talking about performance in 64MB, not 16MB. Video resolutions, icons, and anti-aliasing simply do not explain that kind of resource usage (OS/2 will run in 2048x1536 @ 32-bit color if you have a card that supports it, BTW, and anti-aliasing is available and works just fine on much smaller machines).
While some of your reasons are valid, my entire fscking point is that no regard is being given to folks who might not give a rats ass about transparent windows or anti-aliased fonts and would rather have a WORKING BOX that can use KDE's basic desktop without the extraneous eye candy.
I could point out that I'm aware of several businesses who are happily using hardware of the same vintage as my current LAN setup, and that the KDE folks are effectively alienating them as well, but your solution seems to be to upgrade the hardware for no other reason than to support prettier folders.
Isn't that Microsoft's message, too?
What ever happened to Linux as a small/flexible/lightweight platform??
Folks like you make me ill...
Oops -- I had made the comment about commercial development being a possible exception in another part of the thread. Sorry for assuming that you had seen that.
:-)
Keep in mind also that I was responding to a comment about *all* software development being too complex for one person, and I know from experience that such a comment is inaccurate at best and perhaps even flat-out wrong. Sorry if you disagree, but I have enough firsthand experience on this one to have a fairly well-entrenched opinion.
Sometimes a solution can cover less than 100% of all cases and still be viable.
In fact, I'd bet that very few solutions are able to cover "all" cases.
While I agree that commercial software development for external customers might actually require more (as I had explicitly noted in my original comment), that represents a fairly small minority of the entire software development universe.
(Most programmers write in-house code, not retail applications).
Producing good code is a complicated process, not something one person can do.
:-)
There are dozens (if not hundreds) of examples out there of high-quality code being produced by a single standalone programmer, some of them fairly complex applications/utilities, and that is true not only in the DOS/Windows shareware and open source software environments but also in the corporate mainframe environments where I've worked.
Yes, such folks will generally have other folks to testing over time, but often the concept, design, coding, and initial testing stages are all handled by a single person who has the technical skill, vision, and determination to create the initial solution and whip it into workable shape. Once that basic foundation is in place, feedback from others is solicited.
A person who doesn't care about quality or who isn't technically adept enough to avoid problems is probably going to produce a bad piece of software in the end regardless of the processes in place unless everyone else in the development chain holds his/her hand.
A person who is obsessed with clean code and who has a clear vision, on the other hand, can often perform amazing feats with little more than a single PC or terminal, a pizza delivery service, and a few hundred gallons of coffee (or Mountain Dew) at his or her disposal.
The mainframe environment where I work does not easily allow things like buffer overruns or the executing of data to happen -- data areas are marked non-executable, memory is assigned to applications in discrete blocks and managed by the system (not the applications programmer), and the system generates a hard error whenever the IP walks outside the predefined memory area initially granted to a given process.
In an environment like that, many of the errors we hear about in a typical UNIX/C environment (e.g., buffer overflows causing input data to be executed, etc.) simply do not exist.
Good practices are a good start, of course, but there will still be the potential for serious problems as long as the platforms we use allow for an applications programmer to step on other programs and/or execute areas of memory which were not explicitly marked for execution at process start time.
Processes can aid in ensuring consistency, but they aren't strictly necessary.
I worked as a development/support programmer in a fairly critical application area for a major airline for over ten years, and we had a small tight team of a dozen fairly experienced developers and only a few formal processes in place. The software that was written and loaded in production was generally of very high quality, mainly due to a good culture of informal peer review, testing (involving users and programmers alike), heavy use of a test system to let changes simmer a bit before release, etc., but there really wasn't a formal "metholodogy" in place, just common sense practices that everyone there had agreed to follow.
For larger groups or in development environmments where software is released in bursts (e.g., a new version is released to external customers every few months) it might make more sense to put more formal processes in place, but when working on a living system that has to change from time to time in a few days (or even hours) I'd rather put my faith in a couple of experienced programmers who know the system and the expectations of the end users.
However, the browser I happen to use the most (Links, a test-based browser) isn't all that good at displaying graphics when used in text mode.