A rather large number of people would have a problem with that (it isn't just *Linux* users that have been critical of Microsoft in the past -- some of us have been in that position for longer than Linux has even existed), and I suspect the crowd would include Federal regulators since it could result in the elimination by Microsoft of Yet Another Market.
I've been trying to use it for the past six months or so on a Win2k box, but roughly every other time it checks for updates it also tosses out a message saying its installation is corrupted, and I end up having to repair the install using the installation program. What a pain!
The fact that both OS/2 and BeOS are still seeing a certain amount of new software on a regular basis is almost exclusively due to the fact that open source software is available that can be ported to those platforms.
Projects like Mozilla, OpenOffice, slrn, cdrecord, gcc, and others have been critical in keeping those older platforms viable. It isn't just Linux and other free *nix flavors that benefit from them!
One can grab the full SP4 from the Microsoft site beforehand, put it on a secondary partition on the target box, and then install Win2k, apply SP4, and enable networking on the new installation in that order.
I'd say Windows 2000 and mandrake 8.2 are roughly comparable in terms of installation difficulty, though of course Windows tends to make all kinds of stupid assumptions w.r.t. partitions and doesn't provide as many options (either during the install or in terms of the software one can include in the installation).
I don't think most people would have a problem if Microsoft decided to bundled Firefox, OpenOffice, GIMP, and a number of other apps with the base OS, or even commercial apps like PaintShop Pro and StarOffice or the Lotus SmartSuite.
I also suspect the outcry about bundling Office would be a lot less if the file formats it used was released to the public (and didn't cause the type of proprietary vendor lock-in that they do now).
*We* can have our cake and eat it, too. It's Microsoft that can't, legally, mainly due to its already-established monopoly position on the desktop.
Re:A typical pompous "armchair quarterback" respon
on
Johnny Can So Program
·
· Score: 1
You know that building houses pays better than programming in most places... RIGHT?
Really? You say I can make $35-40/hour plus paid vacation and other bennies by building houses even though I have no experience?
I don't believe it for a second.
I see a Construction Supervisor position (which I don't qualify for) in the Minneapolis Startrib right now that offers $40k/year, and that might be enough for me to get by long term, but even that falls far short of my previous or current salary.
How much do you think experienced applications programmers make?
If that supervisor salary ballpark, though, I'm guessing that grunts like me (in that context) would make somewhat less. I can't find hard current numbers, but I do know folks who did that sort of thing as a summer job, and the pay wasn't all that good.
You also know that working at McD's/etc. allows you a flexible schedule such that you can improve your skills and "network" during the day.
How would that be an improvement on UI benefits which I'd already effectively paid for during a decade of working full-time, which gave me almost total flexibility, which probably paid better, and which actually allowed me to spend time with my wife from time to time as well as engage in the whole spectrum of fulltime studying and job-searching activities?
I would have gone that route eventually, certainly, but not until I saw that it actually provided me with some benefit.
FWIW, part-time work while also getting UI is subtracted from your UI benefit, and more than 32 hours/week renders you completely ineligible. If you do part time work, they let you keep something like the first $50 or 25%, but the rest is directly subtracted from your bennies.
That translates to a limited gain in money for a rather large loss in time. Most people choose to get a job fulltime or do UI -- the combination of a part-time job with UI usually isn't worth it, and the part-time jobs that paid well enough to be worthwhile that I felt qualified for (PC support, help desk, and that type of thing) weren't hiring experienced people -- they seemingly want new faces that work for low wages and that won't leave when a real job shows its face.
Actually, any combination of capital O's, zeros, ones, and lower-case L's could be fun.:-)
l0OO1l10:-)
A typical pompous "armchair quarterback" response.
on
Johnny Can So Program
·
· Score: 1
Actually, I *did* work during that time, though not for an employer as such, mainly doing fulltime techical training and bits of coding in an attempt to build up some experience in more marketable areas, as well as spending a lot of time talking to folks on the phone and in person trying to find out where there might be inside connections to positions (in addition to the traditional job search and resume/cover submission activities), and the roughly $10/hour that state unemployment provided plus my wife's salary was enough to keep us afloat (the contract I found in the middle was a tremendous help as well).
That said, it should be obvious that neither the unemployment benefits nor a similar-paying job (which is all I was able to find in spite of your uninformed claims to the contrary -- ask any programmer in the Minneapolis/St. Paul area what the overall job market has been like there) would allow me any room for doing much in the way of saving, and that was the entire point of my post.
Yes, I chose to spend the time trying to advance my skills and network instead of working at McD's or building houses. Perhaps you would make a different choice, but from a financial perspective the two are roughly equivalent, and I think I ended up somewhat ahead given the path I chose for myself. YMMV, obviously -- just knock off the preaching.
I didn't learn to program at first because I thought it would be a good way to make a living -- I simply wanted to know how things worked, and I wanted to be able to create my own stuff.
The mainframes I write software for are 36-bit machines. ASCII bytes are 9-bits and are packed in four per word, and hardware addressing is done on the word level, not the byte level.
Games are what sucked me into CSci 25 years ago...
on
Johnny Can So Program
·
· Score: 1
I started out just wanting to play games on the Apple II and on the timesharing systems we had access to in school, but eventually I started wondering how they worked, and that lead me to BASIC, Fortran (MUMNF), and 6502 assembler programming.
By the time I was a junir in high school I knew I wanted to design and write software for a living.
Someone following the "scientific method" usually acts in the following manner:
1. Observe something happening.
2. Create a hypothesis about that something.
3. Make predictions about the future using that hypothesis.
4. Do testing and further study, and compare the results of those tests and studies to the original hypothesis.
5. If the results of #4 show that the original hypothesis is incorrect, adjust it as necessary to fit the new observations if possible.
6. Keep on doing 3 through 5 indefinitely.
It's always possible that new information will prove an old hypothesis to be incorrect. That is an accepted (and perhaps even expected) result, at least given enough minds and enough time.
There's a lot more to "science" than simply tossing pet theories at a wall and seeing which ones stick -- the process of experimentation and verification is absolutely essential to the integrity of the conclusions that are drawn as a result.
Such tools can make after-the-fact testing quite a bit easier.
We used automated regression testing scripts in the mainframe environment I worked in 12 years ago, and that made some aspects of unit testing relatively easy.
Unisys had a tool (TTS1100) which allowed us to record each online transaction entry and computer response and then play it back later, and that made it possible to perform the exact same tests dozens or hundreds of times if needed. We used to run them after each set of changes was applied to make sure nothing broke.:-)
One could also record a single occurrence of a lengthy interactive sequence and then add things like variables and looping structures into the recorded script to automate the handling of various test cases using different values.
Such a tool makes after-the-fact test design a little bit easier because you can sit down and methodically address each and every variation of each and every input field on a given screen.
Of course, the nature of the software you're using might make that sort of thing more difficult, or perhaps even easier.
I've never been able to do up-front unit test design -- specifications can change rather quickly when doing in-house software development, and the overall environment is a lot more dynamic than a typical "software house" environment would be where one always has formal detailed product specs to code to. We're often writing code based on an e-mail or on a couple of phone conversations.
Yes, some people can pick things up quite quickly.
A case in point: The only work I was able to get (in roughly the middle of my unemployment) was on a platform I'd never even seen before (Unisys A-series mainframe box), but the site was 50-60 miles from the Twin Cities, and the fact that I knew COBOL relatively well on another platform was enough for them to hire me.
That whole situation was an accident, though. I was told by the contracting firm that the client wanted a Unisys 2200 programmer, and as far as I could tell (after the fact) the client was told that I was an A-series programmer.
It was only during the interview that it became apparent that the hiring manager and I were talking completely two different languages when it came to the mainframe environment (A-series boxes use Burroughs MCP, which is VERY different from the OS2200 environment that 2200 boxes use), but on a whim he let me talk to the lead programmer, and it became apparent from looking at the actual code (COBOL 74) that the learning curve wouldn't be very steep.
I was writing code within 3-4 hours of being on site for the first time. COBOL is COBOL even if I dislike the language, and while DMSII was different from SQL or DMS1100, it was similar enough that it didn't take much time to learn enough to be useful.
Most job hunters (at least in the US) are finding themselves excluded well before being contacted by an actual human.
Companies seem to be looking for exact matches, and explicit experience in both a specific tech and a specific line of business is often a hard requirement before they'll even consider talking to you.
(This is based on my recent 32-month-long unemployment stint in the Minneapolis area as well as lengthy conversations with many others who were [or still are] in the same situation).
Perhaps. As I've said, though, the lack of such a source control system really hasn't been an issue with us.
I mean you do back up your code to something off that system right?
I don't make backups explicitly, no. The systems folks to automagic backups of all working files to tape at least once daily (active files are snapped two or three times), and there's at least one offsite backup of that information in addition to the local stuff on the tape silo here.
Short Circuit (52384), I have good news! You have been promoted. Please report to promotion chamber 14 on Level C-H27 immediately. There is absolutely no danger. Failure to report for this scheduled promotion is treason, and is punishable by death.
A former employer of mine hired a contractor to write a small system for them, and when it was done his contract was over so he left.
The software was written in a modern language on a modern platform, but the employer did not have any of its own expertise in that language. Some of the folks there took shots at making small changes, but for the most part the thing was a black box.
Was it a legacy application or not?
My point: there's a HUGE grey area.
Even the data supposedly "locked" on so-called legacy systems is often easily freed, but many times the easiest solution from a technical perspective (i.e., actually buying a license for a relational database on a mainframe) is considered "too expensive" to implement, and the platform is still blamed even though the data being locked away is a financial decision, not a technical one.
Besides, well-designed systems (in my experence) don't require constant attention regardless of age.
The mainframe system I worked on at NWA certainly had its flaws, but most of its limitations were due to the stubbornness of (and misconceptions held by) upper management when it came to the platform in question, not the system itself.
(As an aside, in response to your lecture at the bottom -- I'd love to free my career from the shackles of older technology, but corporate hiring practices over the past decade make that highly impractical. IT software workers are labelled based on their last platform of expertise, not on their knowledge base.
Solve that issue, and you'll see a lot less CYA on the part of legacy programmers...)
Slashdot Mirror
A rather large number of people would have a problem with that (it isn't just *Linux* users that have been critical of Microsoft in the past -- some of us have been in that position for longer than Linux has even existed), and I suspect the crowd would include Federal regulators since it could result in the elimination by Microsoft of Yet Another Market.
I'd say you twisted the argument to the point where it doesn't make much sense.
I've been trying to use it for the past six months or so on a Win2k box, but roughly every other time it checks for updates it also tosses out a message saying its installation is corrupted, and I end up having to repair the install using the installation program. What a pain!
The fact that both OS/2 and BeOS are still seeing a certain amount of new software on a regular basis is almost exclusively due to the fact that open source software is available that can be ported to those platforms.
Projects like Mozilla, OpenOffice, slrn, cdrecord, gcc, and others have been critical in keeping those older platforms viable. It isn't just Linux and other free *nix flavors that benefit from them!
One can grab the full SP4 from the Microsoft site beforehand, put it on a secondary partition on the target box, and then install Win2k, apply SP4, and enable networking on the new installation in that order.
I'd say Windows 2000 and mandrake 8.2 are roughly comparable in terms of installation difficulty, though of course Windows tends to make all kinds of stupid assumptions w.r.t. partitions and doesn't provide as many options (either during the install or in terms of the software one can include in the installation).
I don't think most people would have a problem if Microsoft decided to bundled Firefox, OpenOffice, GIMP, and a number of other apps with the base OS, or even commercial apps like PaintShop Pro and StarOffice or the Lotus SmartSuite.
I also suspect the outcry about bundling Office would be a lot less if the file formats it used was released to the public (and didn't cause the type of proprietary vendor lock-in that they do now).
*We* can have our cake and eat it, too. It's Microsoft that can't, legally, mainly due to its already-established monopoly position on the desktop.
You know that building houses pays better than programming in most places... RIGHT?
Really? You say I can make $35-40/hour plus paid vacation and other bennies by building houses even though I have no experience?
I don't believe it for a second.
I see a Construction Supervisor position (which I don't qualify for) in the Minneapolis Startrib right now that offers $40k/year, and that might be enough for me to get by long term, but even that falls far short of my previous or current salary.
How much do you think experienced applications programmers make?
If that supervisor salary ballpark, though, I'm guessing that grunts like me (in that context) would make somewhat less. I can't find hard current numbers, but I do know folks who did that sort of thing as a summer job, and the pay wasn't all that good.
You also know that working at McD's/etc. allows you a flexible schedule such that you can improve your skills and "network" during the day.
How would that be an improvement on UI benefits which I'd already effectively paid for during a decade of working full-time, which gave me almost total flexibility, which probably paid better, and which actually allowed me to spend time with my wife from time to time as well as engage in the whole spectrum of fulltime studying and job-searching activities?
I would have gone that route eventually, certainly, but not until I saw that it actually provided me with some benefit.
FWIW, part-time work while also getting UI is subtracted from your UI benefit, and more than 32 hours/week renders you completely ineligible. If you do part time work, they let you keep something like the first $50 or 25%, but the rest is directly subtracted from your bennies.
That translates to a limited gain in money for a rather large loss in time. Most people choose to get a job fulltime or do UI -- the combination of a part-time job with UI usually isn't worth it, and the part-time jobs that paid well enough to be worthwhile that I felt qualified for (PC support, help desk, and that type of thing) weren't hiring experienced people -- they seemingly want new faces that work for low wages and that won't leave when a real job shows its face.
Actually, any combination of capital O's, zeros, ones, and lower-case L's could be fun. :-)
:-)
l0OO1l10
Actually, I *did* work during that time, though not for an employer as such, mainly doing fulltime techical training and bits of coding in an attempt to build up some experience in more marketable areas, as well as spending a lot of time talking to folks on the phone and in person trying to find out where there might be inside connections to positions (in addition to the traditional job search and resume/cover submission activities), and the roughly $10/hour that state unemployment provided plus my wife's salary was enough to keep us afloat (the contract I found in the middle was a tremendous help as well).
That said, it should be obvious that neither the unemployment benefits nor a similar-paying job (which is all I was able to find in spite of your uninformed claims to the contrary -- ask any programmer in the Minneapolis/St. Paul area what the overall job market has been like there) would allow me any room for doing much in the way of saving, and that was the entire point of my post.
Yes, I chose to spend the time trying to advance my skills and network instead of working at McD's or building houses. Perhaps you would make a different choice, but from a financial perspective the two are roughly equivalent, and I think I ended up somewhat ahead given the path I chose for myself. YMMV, obviously -- just knock off the preaching.
I didn't learn to program at first because I thought it would be a good way to make a living -- I simply wanted to know how things worked, and I wanted to be able to create my own stuff.
:-)
Life isn't always about money.
I've seen 4-point and 12-point grading systems in the US (the one used at the college I went to was a 4-point system where 4=A, 3=B, 2=C, etc.).
What's 6.0?
I used to routinely put away 10-12% into a 401k, but then I bought a house and was laid off a year later.
I'd love to be able to save again, but I'm too busy paying off the debt that I accumulated during almost three years without work.
I'm hardly alone in this situation, either.
The mainframes I write software for are 36-bit machines. ASCII bytes are 9-bits and are packed in four per word, and hardware addressing is done on the word level, not the byte level.
I started out just wanting to play games on the Apple II and on the timesharing systems we had access to in school, but eventually I started wondering how they worked, and that lead me to BASIC, Fortran (MUMNF), and 6502 assembler programming.
By the time I was a junir in high school I knew I wanted to design and write software for a living.
Locksmith... Nibbles Away... Lockmaster...
Interesting commands from ages past...
:-)
XYZZY
Someone following the "scientific method" usually acts in the following manner:
1. Observe something happening.
2. Create a hypothesis about that something.
3. Make predictions about the future using that hypothesis.
4. Do testing and further study, and compare the results of those tests and studies to the original hypothesis.
5. If the results of #4 show that the original hypothesis is incorrect, adjust it as necessary to fit the new observations if possible.
6. Keep on doing 3 through 5 indefinitely.
It's always possible that new information will prove an old hypothesis to be incorrect. That is an accepted (and perhaps even expected) result, at least given enough minds and enough time.
There's a lot more to "science" than simply tossing pet theories at a wall and seeing which ones stick -- the process of experimentation and verification is absolutely essential to the integrity of the conclusions that are drawn as a result.
Such tools can make after-the-fact testing quite a bit easier.
:-)
We used automated regression testing scripts in the mainframe environment I worked in 12 years ago, and that made some aspects of unit testing relatively easy.
Unisys had a tool (TTS1100) which allowed us to record each online transaction entry and computer response and then play it back later, and that made it possible to perform the exact same tests dozens or hundreds of times if needed. We used to run them after each set of changes was applied to make sure nothing broke.
One could also record a single occurrence of a lengthy interactive sequence and then add things like variables and looping structures into the recorded script to automate the handling of various test cases using different values.
Such a tool makes after-the-fact test design a little bit easier because you can sit down and methodically address each and every variation of each and every input field on a given screen.
Of course, the nature of the software you're using might make that sort of thing more difficult, or perhaps even easier.
I've never been able to do up-front unit test design -- specifications can change rather quickly when doing in-house software development, and the overall environment is a lot more dynamic than a typical "software house" environment would be where one always has formal detailed product specs to code to. We're often writing code based on an e-mail or on a couple of phone conversations.
Yes, some people can pick things up quite quickly.
A case in point: The only work I was able to get (in roughly the middle of my unemployment) was on a platform I'd never even seen before (Unisys A-series mainframe box), but the site was 50-60 miles from the Twin Cities, and the fact that I knew COBOL relatively well on another platform was enough for them to hire me.
That whole situation was an accident, though. I was told by the contracting firm that the client wanted a Unisys 2200 programmer, and as far as I could tell (after the fact) the client was told that I was an A-series programmer.
It was only during the interview that it became apparent that the hiring manager and I were talking completely two different languages when it came to the mainframe environment (A-series boxes use Burroughs MCP, which is VERY different from the OS2200 environment that 2200 boxes use), but on a whim he let me talk to the lead programmer, and it became apparent from looking at the actual code (COBOL 74) that the learning curve wouldn't be very steep.
I was writing code within 3-4 hours of being on site for the first time. COBOL is COBOL even if I dislike the language, and while DMSII was different from SQL or DMS1100, it was similar enough that it didn't take much time to learn enough to be useful.
Most job hunters (at least in the US) are finding themselves excluded well before being contacted by an actual human.
Companies seem to be looking for exact matches, and explicit experience in both a specific tech and a specific line of business is often a hard requirement before they'll even consider talking to you.
(This is based on my recent 32-month-long unemployment stint in the Minneapolis area as well as lengthy conversations with many others who were [or still are] in the same situation).
You can use code in OS2200 and still use cvs.
:-)
Perhaps. As I've said, though, the lack of such a source control system really hasn't been an issue with us.
I mean you do back up your code to something off that system right?
I don't make backups explicitly, no. The systems folks to automagic backups of all working files to tape at least once daily (active files are snapped two or three times), and there's at least one offsite backup of that information in addition to the local stuff on the tape silo here.
This isn't a PC we're talking about, remember.
In the US it varies by state, and in Minnesota it was for six months.
There used to be a 3-month federal extension, but to my knowledge it hasn't been renewed.
Well, it means you registered before me. In your case not much before me. :-) But I read here for a while before deciding to actually register.
Keep that in mind, and all will be fine.
Short Circuit (52384), I have good news! You have been promoted. Please report to promotion chamber 14 on Level C-H27 immediately. There is absolutely no danger. Failure to report for this scheduled promotion is treason, and is punishable by death.
Be happy! The Computer is your friend.
Are you not happy?
A former employer of mine hired a contractor to write a small system for them, and when it was done his contract was over so he left.
The software was written in a modern language on a modern platform, but the employer did not have any of its own expertise in that language. Some of the folks there took shots at making small changes, but for the most part the thing was a black box.
Was it a legacy application or not?
My point: there's a HUGE grey area.
Even the data supposedly "locked" on so-called legacy systems is often easily freed, but many times the easiest solution from a technical perspective (i.e., actually buying a license for a relational database on a mainframe) is considered "too expensive" to implement, and the platform is still blamed even though the data being locked away is a financial decision, not a technical one.
Besides, well-designed systems (in my experence) don't require constant attention regardless of age.
The mainframe system I worked on at NWA certainly had its flaws, but most of its limitations were due to the stubbornness of (and misconceptions held by) upper management when it came to the platform in question, not the system itself.
(As an aside, in response to your lecture at the bottom -- I'd love to free my career from the shackles of older technology, but corporate hiring practices over the past decade make that highly impractical. IT software workers are labelled based on their last platform of expertise, not on their knowledge base.
Solve that issue, and you'll see a lot less CYA on the part of legacy programmers...)