It's not just the midwest US, either. Housing in the Atlanta area is considerably less expensive than it was in the Minneapolis/St. Paul area, for example.
While C64's may have outsold Apple II's in the home market, remember that the basic Apple II model predated the C64 by almost five years. I remember seeing Apple II's in the libary and in certain classrooms in both my junior high school and high school in the late 70's/early 80's, and I don't recall ever seeing a C64 in that environment. Apple II's were everywhere, and the C64 was the subsequent wave.
Really. Folks in their 40's are the video game generation and the first microcomputer game generation, so of COURSE we're going to buy games. I'm 44, and I grew up on TRS-80's, Apple II's, and Space Invaders.:-)
No, you wouldn't, since you would be replacing the old desktop with the new one.
I used to do this with Windows 95 -- I replaced the default Explorer shell with a third-party product called QuickMenu 4.
This was helpful when I lent my machines out for LAN parties, as I could password-protect individual icons, I could also create a multi-page desktop and password-protect those pages that I didn't want people to play with.
That let me create a LAN Party Menu (in essence) that folks couldn't easily escape.:-)
Windows 2000 is barely capable of running Firefox on a PPro/200 with 64MB, though it still does so well enough for basic surfing, but OS/2 is relatively fast when running Firefox on the same hardware.
I don't know that Windows XP or Vista (the current incarnations) will even boot on a 64MB PPro, much less load and run Firefox at an acceptable speed.
Linux distros are also able to run Firefox on that hardware, but some of the larger desktops which are becoming the community darlings are quite slow by themselves, making Firefox much less useful on the same limited hardware than it would otherwise be. That's why I tend to use DSL or Puppy in place of PCLinuxOS, Ubuntu, or some of the other large (memory-heavy) distros.
Does that make my comments easier to parse? The phrase "limited hardware" was intended to define the context of my comments; sorry for not make that more obvious.
True. A public FixPak was required to get Mozilla to work back around 2001/2002 or so, and I assume that same FixPak is needed to get Firefox to work. FWIW, though, I've made no TCP/IP updates to my own Warp 4 system, and my copy of Firefox 1.5.11 works just fine on that system. Just base FP15.
Also, I use SCSI drives, so I've not had the large-disk issues that plagued Warp 4 in its early days and I've never needed the newer IDE drivers. FWIW.
Even my 7-year-old Casio 3000EX runs circles around a built-in camera phone in features. How is a phone going to replace that? And my MP3 player (a Mobiblu 1GB cube) take up almost no space, while a camera is huge in comparison and contains a lot of functionality I have absolutely no need for.
Remember also that OS/2 ran Windows 3.1 software almost flawlessly, including software that used the 32-bit extensions found in WIN32S.DLL, and that Microsoft could only stop IBM from continuing to offer that high level of competability by changing the virtual machine size of WIN32S.DLL starting with version 1.30 and making that a default setting.
That's why Adobe Photoshop for Windows 3.04 runs just fine under OS/2 Warp 4's WinOS2 subsystem but Adobe Photoshop 3.05 fails, for example. The only thing which changed between those two releases (besides a few fixes) was the move from WIN32S.DLL 1.25a to WIN32S.DLL 1.30.
The thing most people don't realize is that even the 1996 flavor of OS/2 Warp 4 is capable of running modern software like Firefox and OpenOffice, and it does so rather well on fairly limited hardware.
Windows has a hard time doing that these days, and Linux is travelling in that direction (at least in terms of the mainstream distros, which seem to have abandoned legacy hardware support for eye candy).
We did have a multitasking OS on x86 hardware well before 1995. OS/2 2.0 was released in 1992, and Windows NT 3.1 was released in 1993. Before that, products like PC/GEOS provided preemptive multitasking and multithreading on machines with much lesser hardware (GeoWorks Ensemble 1.0 would run fairly well on an IMB XT with 640k of RAM and a CGA card).
Windows 95 was a hybrid 32-bit product which was heavily based on Windows 3.1's architecture and which was largely targetted at the masses, but its multitasking is actually quite poor compared to the two previously released operating systems from IBM and Microsoft itself.
The only reason OS/2 dies was because IBM was greedy and charged too much for it at the beginning of it's life, hence the beginning became the end.
Wasn't it Microsoft that set the pricing of the SDK for OS/2 1.x, and wasn't OS/2 1.x mainly sold as a Microsoft product? Who set the high prices for OS/2 again?
Remember that IBM, once it got hold of OS/2 and was able to release the 32-bit version as a product independently of Microsoft, was willing to sell OS/2 to Windows users for US$49 and to DOS users for US$99, thus making OS/2 an extremely affordable product at one of the key times in its evolution -- the time when it alone was a Windows-compatible 32-bit operating system that was completely independent from DOS.
Windows NT 3.1 (Microsoft's first 32-bit offering) wasn't released until some time after OS/2 2.0 (July 1993, over a year later than OS/2 2.0).
APIs are surface features which are (usually) made visible for applications to use, and they give very little indication of the nature or structure of the actual kernel code running underneath.
OS/2 supports the POSIX API via EMXRT.DLL, for example, and yet OS/2's kernel has very little in common with, say, Linux or Solaris (which both also support POSIX programs).
The 32-bit OS/2 kernel written by IBM for OS/2 2.0 and later and the Windows NT 4 kernel are quite different. Both Microsoft and IBM completely re-implemented their respective OS's kernels after the 16-bit OS/2 days, and the resulting software has very little relationship to the old 16-bit kernels except for support for the older 16-bit APIs. But as I said, that is simply a surface similarity.
In many cases, especially in large companies, the large majority of candidates are removed from consideration by HR before hiring managers get to see the resumes.
I don't think the problem is stupid managers as much as it is a corporate hiring system which is focused on only hiring specialized personnel. Whether that is a stupid approach or not depends on who you ask.
Back when I was super-active on USENET, Delphi, and various online forums, a couple of days *was* a rather long time.:-) I didn't have a wife, house, and various other domestic-priority interrupts getting in the way of a good technical discussion in those days...
Uh, moderators... This story is about the requirement for verifying identification in an online context, and about the difficulty of sometimes doing so.
How is my posting off topic? Wikipedia isn't the only site that has (or will have) this problem...
...and if you have a account number below 1000 you have to prove to did not buy it, but really were there.
How would one go about doing this?
I'm not under 1000, but I *could* have gotten a lower ID on Slashdot legitimately had I decided to register on this site right away. However, I didn't create an account until I had been reading here for some time. But how would I prove that?:-)
Folks who were active on other contemporary sites at the time might recognize my name (from IWE or from other places), but that would be hearsay, not proof.
I don't recall ever seeing a license bundled with or included as a part of a music LP, tape, or CD that I've purchased, and I have quite a few of all of the above...
Document the system after the fact - that's the funniest post I've seen in weeks. We all know there's no business case for documentation once the system is working and live. =)
Commercial software development for external consumption is VERY different from in-house software development, both in terms of the nature of said development (different lifecycles and methodologies), and in terms of the nature of documentation required.
My Unisys ADSC example was an example of a mainframe software house releasing a product version by version to several concurrent customers on a lengthy release cycle.
However, most of what I've done is in-house development work.
I worked on flight operations systems at Northwest Airlines for ten years, and we generally created two types of formal documentation, both of them after the fact:
(1) End-user documentation. This was created by the business analysts and end user reps, not by the programming staff. Screenshots, error messages, common "user manual" stuff.
(2) Programmer documentation. Every program module, subroutine, and file was documented in great detail for the programming staff.
The latter set of documentation was *important* -- the system was started in 1966 at another airline and grew as a living system over 20 years before we got our hands on it, and we were just starting to learn about it (through the very extensive technical documentation we were provided by the other airline) and had just started doing our own development and support work in 1988. The system is still running today, and will likely be running in another ten years (my guess).
Because of very complex nature of the software and its lengthy past and (assumed) future history, we fully appreciated the need for having complete technical documentation available for all of the changes we made to the system. If it wasn't for the fact that UAL had such a culture with their UNIMATIC system to begin with, our own cutover would have been a real PITA...
Nonsense. America already *has* plenty of smart citizens.
The problem with America is that many of its very smart/skilled citizens are currently unemployed or underemployed, but a very small investment of time could make those people productive again. A few hours of time in some cases, or even no training at all in some cases.
When I was unemployed a few years ago, I was turned down for literally *dozens* of positions that I could have easily stepped into with a few hours or days of training, and hundreds more that I could have been fully prepared for in a month or two, but that is too much investment these days for most companies. They're too busy thinking about short-term goals to concentrate on long-term development...
Are there actually companies that write proper specs? I've only been doing IT for 19 years and I have yet to find any place where it actually happens.
At most of the places I've worked, the creation of specs is an interactive iterative process between us (the developers) and the users. Sometimes it starts with an idea, sometimes with a detail write-up, but most of the time the gory details take a little while to mail down and will usually get implemented in code first and then changed over time based on user feedback.
When I worked at the Unisys Airline Center, they had a fairly good process in place to meet with the customers and draw up a series of general and detailed specification documents based on those meetings, but that was a place that released software on a roughly 18-month cycle between versions, not a live shop with a constantly shifting set of applications.
I think it's harder to write project specs for a living system -- it's a lot easier to document the system in detail after the fact. If one has the time.:-)
Slashdot Mirror
It's not just the midwest US, either. Housing in the Atlanta area is considerably less expensive than it was in the Minneapolis/St. Paul area, for example.
While C64's may have outsold Apple II's in the home market, remember that the basic Apple II model predated the C64 by almost five years. I remember seeing Apple II's in the libary and in certain classrooms in both my junior high school and high school in the late 70's/early 80's, and I don't recall ever seeing a C64 in that environment. Apple II's were everywhere, and the C64 was the subsequent wave.
Really. Folks in their 40's are the video game generation and the first microcomputer game generation, so of COURSE we're going to buy games. I'm 44, and I grew up on TRS-80's, Apple II's, and Space Invaders. :-)
No, you wouldn't, since you would be replacing the old desktop with the new one.
:-)
I used to do this with Windows 95 -- I replaced the default Explorer shell with a third-party product called QuickMenu 4.
This was helpful when I lent my machines out for LAN parties, as I could password-protect individual icons, I could also create a multi-page desktop and password-protect those pages that I didn't want people to play with.
That let me create a LAN Party Menu (in essence) that folks couldn't easily escape.
Windows 2000 is barely capable of running Firefox on a PPro/200 with 64MB, though it still does so well enough for basic surfing, but OS/2 is relatively fast when running Firefox on the same hardware.
I don't know that Windows XP or Vista (the current incarnations) will even boot on a 64MB PPro, much less load and run Firefox at an acceptable speed.
Linux distros are also able to run Firefox on that hardware, but some of the larger desktops which are becoming the community darlings are quite slow by themselves, making Firefox much less useful on the same limited hardware than it would otherwise be. That's why I tend to use DSL or Puppy in place of PCLinuxOS, Ubuntu, or some of the other large (memory-heavy) distros.
Does that make my comments easier to parse? The phrase "limited hardware" was intended to define the context of my comments; sorry for not make that more obvious.
True. A public FixPak was required to get Mozilla to work back around 2001/2002 or so, and I assume that same FixPak is needed to get Firefox to work. FWIW, though, I've made no TCP/IP updates to my own Warp 4 system, and my copy of Firefox 1.5.11 works just fine on that system. Just base FP15.
Also, I use SCSI drives, so I've not had the large-disk issues that plagued Warp 4 in its early days and I've never needed the newer IDE drivers. FWIW.
Even my 7-year-old Casio 3000EX runs circles around a built-in camera phone in features. How is a phone going to replace that? And my MP3 player (a Mobiblu 1GB cube) take up almost no space, while a camera is huge in comparison and contains a lot of functionality I have absolutely no need for.
Convergence? I don't think so...
Remember also that OS/2 ran Windows 3.1 software almost flawlessly, including software that used the 32-bit extensions found in WIN32S.DLL, and that Microsoft could only stop IBM from continuing to offer that high level of competability by changing the virtual machine size of WIN32S.DLL starting with version 1.30 and making that a default setting.
That's why Adobe Photoshop for Windows 3.04 runs just fine under OS/2 Warp 4's WinOS2 subsystem but Adobe Photoshop 3.05 fails, for example. The only thing which changed between those two releases (besides a few fixes) was the move from WIN32S.DLL 1.25a to WIN32S.DLL 1.30.
The thing most people don't realize is that even the 1996 flavor of OS/2 Warp 4 is capable of running modern software like Firefox and OpenOffice, and it does so rather well on fairly limited hardware.
Windows has a hard time doing that these days, and Linux is travelling in that direction (at least in terms of the mainstream distros, which seem to have abandoned legacy hardware support for eye candy).
We did have a multitasking OS on x86 hardware well before 1995. OS/2 2.0 was released in 1992, and Windows NT 3.1 was released in 1993. Before that, products like PC/GEOS provided preemptive multitasking and multithreading on machines with much lesser hardware (GeoWorks Ensemble 1.0 would run fairly well on an IMB XT with 640k of RAM and a CGA card).
Windows 95 was a hybrid 32-bit product which was heavily based on Windows 3.1's architecture and which was largely targetted at the masses, but its multitasking is actually quite poor compared to the two previously released operating systems from IBM and Microsoft itself.
Wasn't it Microsoft that set the pricing of the SDK for OS/2 1.x, and wasn't OS/2 1.x mainly sold as a Microsoft product? Who set the high prices for OS/2 again?
Remember that IBM, once it got hold of OS/2 and was able to release the 32-bit version as a product independently of Microsoft, was willing to sell OS/2 to Windows users for US$49 and to DOS users for US$99, thus making OS/2 an extremely affordable product at one of the key times in its evolution -- the time when it alone was a Windows-compatible 32-bit operating system that was completely independent from DOS.
Windows NT 3.1 (Microsoft's first 32-bit offering) wasn't released until some time after OS/2 2.0 (July 1993, over a year later than OS/2 2.0 ).
APIs are surface features which are (usually) made visible for applications to use, and they give very little indication of the nature or structure of the actual kernel code running underneath.
OS/2 supports the POSIX API via EMXRT.DLL, for example, and yet OS/2's kernel has very little in common with, say, Linux or Solaris (which both also support POSIX programs).
The 32-bit OS/2 kernel written by IBM for OS/2 2.0 and later and the Windows NT 4 kernel are quite different. Both Microsoft and IBM completely re-implemented their respective OS's kernels after the 16-bit OS/2 days, and the resulting software has very little relationship to the old 16-bit kernels except for support for the older 16-bit APIs. But as I said, that is simply a surface similarity.
In many cases, especially in large companies, the large majority of candidates are removed from consideration by HR before hiring managers get to see the resumes.
I don't think the problem is stupid managers as much as it is a corporate hiring system which is focused on only hiring specialized personnel. Whether that is a stupid approach or not depends on who you ask.
Back when I was super-active on USENET, Delphi, and various online forums, a couple of days *was* a rather long time. :-) I didn't have a wife, house, and various other domestic-priority interrupts getting in the way of a good technical discussion in those days...
Heh. Point made. :-)
Some folks still do... :-)
The Buffalo LinkStation line of storage devices are the same way. Embedded Linux and Samba.
Uh, moderators... This story is about the requirement for verifying identification in an online context, and about the difficulty of sometimes doing so.
How is my posting off topic? Wikipedia isn't the only site that has (or will have) this problem...
It's not a recent gimmick at all, as your experience seems to demonstrate. :-)
How would one go about doing this?
I'm not under 1000, but I *could* have gotten a lower ID on Slashdot legitimately had I decided to register on this site right away. However, I didn't create an account until I had been reading here for some time. But how would I prove that? :-)
Folks who were active on other contemporary sites at the time might recognize my name (from IWE or from other places), but that would be hearsay, not proof.
Okay. That makes more sense. Thanks...
I don't recall ever seeing a license bundled with or included as a part of a music LP, tape, or CD that I've purchased, and I have quite a few of all of the above...
A simply copyright is not a license.
Commercial software development for external consumption is VERY different from in-house software development, both in terms of the nature of said development (different lifecycles and methodologies), and in terms of the nature of documentation required.
My Unisys ADSC example was an example of a mainframe software house releasing a product version by version to several concurrent customers on a lengthy release cycle.
However, most of what I've done is in-house development work.
I worked on flight operations systems at Northwest Airlines for ten years, and we generally created two types of formal documentation, both of them after the fact:
(1) End-user documentation. This was created by the business analysts and end user reps, not by the programming staff. Screenshots, error messages, common "user manual" stuff.
(2) Programmer documentation. Every program module, subroutine, and file was documented in great detail for the programming staff.
The latter set of documentation was *important* -- the system was started in 1966 at another airline and grew as a living system over 20 years before we got our hands on it, and we were just starting to learn about it (through the very extensive technical documentation we were provided by the other airline) and had just started doing our own development and support work in 1988. The system is still running today, and will likely be running in another ten years (my guess).
Because of very complex nature of the software and its lengthy past and (assumed) future history, we fully appreciated the need for having complete technical documentation available for all of the changes we made to the system. If it wasn't for the fact that UAL had such a culture with their UNIMATIC system to begin with, our own cutover would have been a real PITA...
Nonsense. America already *has* plenty of smart citizens.
The problem with America is that many of its very smart/skilled citizens are currently unemployed or underemployed, but a very small investment of time could make those people productive again. A few hours of time in some cases, or even no training at all in some cases.
When I was unemployed a few years ago, I was turned down for literally *dozens* of positions that I could have easily stepped into with a few hours or days of training, and hundreds more that I could have been fully prepared for in a month or two, but that is too much investment these days for most companies. They're too busy thinking about short-term goals to concentrate on long-term development...
At most of the places I've worked, the creation of specs is an interactive iterative process between us (the developers) and the users. Sometimes it starts with an idea, sometimes with a detail write-up, but most of the time the gory details take a little while to mail down and will usually get implemented in code first and then changed over time based on user feedback.
When I worked at the Unisys Airline Center, they had a fairly good process in place to meet with the customers and draw up a series of general and detailed specification documents based on those meetings, but that was a place that released software on a roughly 18-month cycle between versions, not a live shop with a constantly shifting set of applications.
I think it's harder to write project specs for a living system -- it's a lot easier to document the system in detail after the fact. If one has the time. :-)