Huge Generic ACME Computer Company doesn't care if I work for them or not.
They may care if you possess some skill that they can not easily find among the unemployed. In which case, particularly if it is a key skill they want/need, they will certainly negotiate with you - and perhaps provide a lucrative contract for permanent work.
Your example does not take into account the fact that many people make poor choices when it comes to their skills and experiences during their life. Should society suffer because you screwed the pooch?
I guess you can probably tell most people don't live up to my expectations.
Courtney points to the situation at Cingular, where 20,000 employees recently organized under the Communications Workers of America after management agreed not to involve itself in the workers' choice of unionization.
"This is a young work force," Courtney said. "If it was anti-union no one would have joined."
So, will we ever see a unionized Microsoft? With his own union working on the Redmond behemoth, Courtney certainly won't rule it out.
The folks organized at Cingular were certainly not your top level software developers/engineers/architects -- these folks were your cable splicers, CO techs, outside plant, and call-center employees. Hardly jobs I would classify as 'IT' in the traditional sense. That was a very bad example, a misrepresentation that doesn't come close to what the average/. reader considers 'IT' jobs.
I do agree there are jobs where unions are absolutely necessary. True IT jobs (not technician helper jobs as in the Cingular example) are not the place to do it. You must have a layer of workers who have the flexibility to get unusual jobs in emerging technologies done quickly and effectively; the union will not provide that workforce (as I have seen from my own experience - with their departmental and job description limitations - creaking buraucracy and frivilous grievances - they don't do 'new' well without it being handed to them on a platter, and then you better have the paperwork done in triplicate, and clear instructions for how to accomplish the new job that conforms to their contractual agreement).
Making the jump from unionizing a call-center to unionizing your software developers is a questionable jump in logic. In the article Tony Long mentions 'smart' people he knows who lost their 'tech' job - and were not able to find another comparable. Nonetheless he doesn't elaborate on the circumstances - could it be the friend was not willing or able to change - learn new techniques or increase their education to enable them to remain viable inside the organization or in the workforce as a whole as the world economy changes? How would being in a union be beneficial - other than to keep someone in a job they are not suited for - to the detriment of the business. Does the person who allows themselves to get into that position sound 'smart' to you? Perhaps his friends' evaluation of their own skills was skewed by their overinflated sense of worth (I know folks who think they are smarter than they really are - and open their mouths to prove on numerous occaisions).
The future of IT is the future of small, highly capable teams that outperform traditional IT monoliths using advanced processes and tools. Contrary to the trend in other industries, the opportunities for striking out on your own are only growing: The outsourcing experiment is being seen as largely a failure because of cost overruns and shoddy workmanship, that needs to be identified and fixed by native engineers and developers locally anyway. The influx of poorly trained and motivated developers during the dot-com bubble is reversing - the pendulum swings back into balance; differentiate yourself now, or lose. If you don't care about being the best IT developer/integrator/engineer you can be - then maybe you don't deserve to be in the field at all.
Leave the computer science to the computer scientists (or people who have the drive to gain equivalent knowledge and apply it consistently). There is no room for a union in this world - and I can't see how you would circumscribe a union job in such an open-ended field.
/Flame On/ There are a metric-crap-ton of so-called 'developers' in my company who:
a) Have no love of the work.
b) Do not take the time to learn their craft inside and out.
c) Do not understand basic computer science.
d) Are a drag on the rest of us who do (because we have to take up the slack).
e) Make projects overrun time and cost and when they do arrive not perform as requested.
f) Are not willing to change (particularly the ones trained in the 1960's/70's who think every project must conform to the waterfall development lifecycle - and these guys are invariably in charge - and cliques of brown-nosers flock to them).
I will not shed a tear when these guys get shit-canned. Most came into the job during the dot-com bubble with dollar signs shining in their eyes. The times they are a changin'
I have kept my job because these guys can't perform; I deliver the goods to my subsidiary and change as the needs of my business changes. The large majority of developers are a lead anchor - and is a major reason we are stuck using outside vendors to build critical infrastructure. Furthermore, the leadership in the IT department has fostered a culture of protecting and expanding their 'turf' (bugetary and manpower) - at the expense of their internal customers and ultimately the business as a whole (even going so far as to prevent me from using an outside vendor or building an application myself on a project that then goes millions of dollars over budget and years late as a result - that is then abandoned, forcing us to resolve internally ourselves anyway!).
I get paid very well for what I do. Unionizing would not help me at all, and would definitely worsen the situation as described above. Given the way my industry is going - we will have to be agile in order to compete with our nimble competitors. Unionizing these slackers would not help us at all.
If I were in control, I would interview all the developers and determine who is dead weight and who is not (not only am I a developer, but I have also been a project manager and a key stakeholder in various projects over the years where the IT department was involved). If they will help the company compete flexibly and put internal and external customers first - then they can stay. If they want to keep the status-quo - then they can go. All the top 'empire builders' would be out on the street - for no other reason than the damage they have already done to my business.
Sadly, I am not in control - so I will probably have to continue to carry these folks on my back./Flame Off/
I've been doing this for over 10 years - and have experienced the limitations I've listed over and over again, project after project. It should be noted that one of the signs of mental illness is performing the same process over and over again expecting a different outcome. It is time for change within IT - and it involves building small effective teams - instead of outsourcing (because our experience has also shown that outsourced work is just as bad as poorly motivated internal development), or conversely clinging to a crumbling IT empire. The business must survive! Eventually the business will determine what is a drain on it and remove the problem. Your mission as an IT person is to be part of the solution, rather than part of the problem.
The refinery cartel could have done something about this long ago. Only one oil company, that I am aware of, has retooled their refineries to allow them to switch to generating alternative fuels - Shell.
It is now the 11th hour, and they are grabbing at straws to keep their bloated profits.
I wonder how many jobs would really be created if we opened up this so-called 'H' prize to all forms of alternative energy. My guess is it would create even more jobs than are employed at refineries today; of course the profits would be distributed among a larger number of small players - not good for the money bags.
If you really don't like what is (and has always been) going on - build it yourself, or if you can't gain the skills or know someone who has them, buy a bicycle and/or use public transportation. We can think and act for ourselves - if we let others do the thinking we only have ourselves to blame.
a) I would always want to be able to disable the transponder on such a device myself - no feasible with subdermal implant.
b) If the database gets corrupted for a given application I would want to be able to reprogram the device -- again not feasible with subdermal implant.
c) As mentioned elsewhere - RFIDs in their current incarnation are nothing more than identification beacons. I would prefer a device that was smart enought to know when to respond and when not to respond, and furthermore encrypt the data it was sending across the ether (much as it is advisable today to have a VPN server behind every non-trusted gateway to authenticate and encrypt traffic from an unsecure network into a secure network).
In the context of a proprietary project, it might be the case that having neophytes mess about in production projects might be beyond the ability of a development shop to manage - provided they are not willing to share the responsiblity of reviewing code with the community surrounding the project.
We are, however, talking about FOSS projects - where the price of admission is free and very community oriented. If such a project is big enough to attract a large audience - it will invariably have a good size subset of eyeballs that have the skills necessary to find the bugs easily (while you may scoff at 'The Cathedral and the Bazaar', the truths contained are borne out time and again). As the person in the article says, the would-be developer would have his halfbaked idea flamed off of the release list if it did not fly.
On the other hand, small projects will implode if there are not enough eyeballs --- they will be the Frankenstein monstrocities that no one will use. Good riddance - and I can't see accelleration of this process as a bad thing because it makes it easier to seperate the chaff from the wheat - so to speak - for potential users of the applications produced.
As a result, the cream will rise to the top - for no other reason than it works best for a given problem domain. There are plenty of examples that prove this out (Firefox, Linux kernel, Apache, Python, Debian, etc...) - and the marginalized misanthropic and micro-niche projects are too many to count - neutral really (as I have found niche software that was perfectly suitable for my own purposes, that would not stand the test of the masses - right and good as far as I am concerned).
Nevertheless most development shops must justify their own existence, and thus can not tollerate the potential of having the project direction and development subjugated (even though that might be best for the community surrounding the application). So, I don't expect to see this evolve in any significant way in the proprietary software arena. Once again, FOSS will lead where others fear to tread.
I recently picked up a perfectly functional 486-dx 66mhz Cyrix clone cpu laptop (circa 1993 - made by AST - Canadian company which no longer exists) for $45 from my local Goodwill computer store. It came with 20 MB ram, a 500 MB hard drive, two pcmcia ports, and the usual mix of parallel, serial and keyboard ports. The LCD monitor on it works perfectly, all of the keyboard functions work, and it has a built-in trackball that also is in working order. The outer case is in nearly immaculate condition - only a few scratches here and there. The battery needs to be refurbished or replaced - that is true of any 13 year old laptop.
It was running DOS 4.1 when I got it (I assume this is what it was originally loaded with). I decided to improve its utility by loading Slackware 10.2 on it (You can see the full blown procedure I used here). I did not want to use the Zipslack install method (as mentioned in the article, you have some performance issues I could not afford on such old equipment). Without a CDROM, I would need to furthermore modify the installation process. I happen to have a Iomega parallel port zip drive, so I used the boot disk for the zipslack installation to access this drive. The boot disk assumes your root disk(s) will be on the parallel port device. The problem with that is that while the zipslack install disk can recognize and use the zip drive for installation, the regular installation root disks do not (have to talk to Patrick about that). Luckily, you can specify another mount location (just not the parallel port drive) - so I set aside a 100MB partition on the hard drive, and used that for the installation.
I booted the system from floppy using the zipslack root disk and the standard installation floppies. Then I mounted the parallel port zip drive, and partitioned, formated and mounted the 'source' partition on the hard drive. After that it was a simple matter to copy over the slackware packages I had earlier copied onto a zip disk from my workstation. Finally I kicked off the setup utility after partitioning the hard drive's remaining space. After that, the install was normal. Starting with a 350 MB root partition (used 50MB for swap, and the 100MB source) - I ended up with 25% free space (used about 225 MB for the packages I loaded). I was also able to free up the 100MB source partition afterwards - so I have a whopping 175MB to play with.
Note that I did not load all the packages available from the Slackware distro - most of the A and AP packages, the key network packages, and some development packages (python). So, no X-windows. However, I found an application called 'twin' (Textmode WINdow environment) that emulated an X server, providing multiple text-based windows that have all the usual controls (resizing, scrollbars, window shade, minimize etc). Twin runs very fast on the 486, and provides the multiple window capability (including copy/paste between windows) that you would need for most jobs. Twin is an older program - last updated in 2003, which I had to build on my workstation, then move over to the laptop via the zipdrive.
Without a graphics capability, most of the modern tools available in KDE or GNOME are out of reach - but that is okay. I use 'jed' editor (emulates emacs commands - but smaller footprint), and am writing my own tools in python - basically to capture thoughts, and provide automation for uploading my field-notes onto my server when connected to my home network (saving my pennies to get a pcmcia NIC soon).
Extending the life of the laptop was well worth the trouble. While it may not be cutting edge in terms of looks - for what I do it gets the job done.
You hit upon a key point there. Vocabulary, grammar and spelling are not improved significantly through writing; they are improved by reading well written works that challenge your current knowledge.
The larger your vocabulary, the more accurately you can describe the world. The better your grammar, the more likely you will be to keep your readers interested in the subject matter. The more accurate your spelling the less confusion you will sow among your readers.
The key value-add for Apple has always been the tight integration of software and hardware within their product line.
They had that to a lesser degree with the Apple ][, tightened it up with Macintosh, and continue that tradition to this day (with the added benefit of extensibility afforded by X and BSD compatibility).
They are not going to throw that away.
On a side note, if I were to buy an Apple that would be the key reason - and no other. When I spend the $$$ on Apple, the expectation is it will just 'work' right out of the box, and that the interface will be a natural one. In fact I am considering getting my wife a Mac Mini to replace her Windows machine so I can finally rid my network of Microsoft (she is already using %100 FOSS applications on that box) and avoid having to troubleshoot heisenbugs in Windows.
I must be addicted to work by the same reasoning. It's this damnable free market economy I live in - the government should pay for my therapy to free me from this addiction...:P
To amplify your thoughts -- the most successful FOSS projects have one thing in common: a strong leader in the form of a 'benevolent dictator' (Linux's Linus Torvald and Python's Guido van Rossum come to mind), or a team that serves the same purpose (Netscape's Mozilla team and Debian's technical commitee for example).
So the most successful projects have hac4ers on the back-end driving change, with a filter on the front-end controlling what gets into the releases after careful consideration over time. Ideas that are well developed and proven over time make it; 'flashes in the pan' that aren't well developed or proven useful don't make it.
Anyone who thinks their project could be generally useful to a large number of people should probably think about making sure such a structure exists, even if you serve as your own 'benevolent dictator' to start out with. Another thing that might help, is creating an interface (a la Firefox plug-ins or Linux dynamic driver modules etc.) that allow you to extend your application without the need to tightly couple the application code base and the extension - that is always a winner.
I got the Texas Instruments TI99A when I was 16 in 1980. I quickly learned how to program it using the built-in basic interpreter. It had some neat features; you could intercept key presses from within your application, and also manipulate screen sprites to build some interesting interfaces/games. I saved my programs to cassette tapes on the boom-box next to my desk - when it wasn't being used for blasting music (they actually used to make boom-boxes with a line-in back then...thank the RIAA for that, I suppose). I took my highschool's first computer science class that year - and spent less time waiting in the lab for console time as a result (I would debug programs at home, then transcribe them into a notebook, and only have to do data entry, then run them on the teleprinter to get credit).
I credit this machine with planting the seed that would become my career later on. I looked up the price of that machine one time -- it was somewhere in the region of $1500-$2000 in 1980 dollars! I don't know how my parents aforded it; I can't aford a $500 machine today...
Looks like it is time for you to find a new employer.
If they are completely clueless (believing everything your read or see on TV probably fits the bill), you are jeopardizing your long-term financial security by staying on with a company that is obviously moving towards bankruptcy.
With larger and larger storage needs (for such things as DVR, centralized content management systems, music siloing etc...) and for interactivity between more and more devices on the network, I can certainly see a point at which 100mbs will not suffice for most users.
Over the next 5 to 10 years we will see an explosion of applications, and NAS (network attached storage) devices and multiple computers and computerized devices will enter the home network and become the norm.
It is coming; lead, follow, or get out of the way...:P
The moment the arpanet backbone was commercialized we ran the risk of filtration of access.
Personally I think it would be suicide to not maintain your network as a universal interconnection point - since the value of any intranet increases with the increase in the number of nodes (Metcalf's Law). As mentioned perviously, AOL is a prime example of how its percieved value was lower than their competitors - and it ended up having to open up its network.
The folks at Google are smart. I don't see them making the same mistakes.
Game consoles are effectively closed to hobbyists and despite the degree of amateur work...
A special purpose game console is not the same thing as a general purpose computer. Computer architecture was opened up to allow unforseen uses/programming, and devices to be produced after the fact to increase its overall value and usefulness.
Moving a general purpose open architecture, to a closed proprietary one will limit its usefulness - and will certainly boost the sales of manufacturers who refuse to go this route.
I am a software developer and hardware tinkerer; they can have my computer when they pry my cold dead hands off of it.
The pre-internet days of clearly delineated 'producers' and 'consumers' is an artifact of a bygone era.
Microsoft and other large corporations (MPAA, RIAA etc..) want to turn back the clock, and force us to become 'good consumers'. Why build when you can buy? Of course what you buy will be a tasteless vanilla mush - and you can buy versions with any color - provided that color is blue (with a Windows logo of course).
This is initially why we see independents gain ground in music and computing - and it will only continue to increase as Gen Y makes its presence felt -- particularly given the large amounts of their income that will be needed to support the Boomers (who will be mostly retired and a powerful lobby to lock-in their retirement benefits in Congress). Their decisions will be motivated by monetary pressures that will not support traditional 'producer'/'consumer' corporations. They will expect high value for nominal prices - and if you can't compete in that space, you will see your revenue and thus stock value plummet.
Non-open DRM schemes are just a means to the end of staving off this change - securing a steady flow of income from a flawed and outdated business plan. This will not work, because Gen Y - who outnumber both Gen X and the Boomers - will not be able to sustain it, feed themselves and save for their own retirement. The wave of change is already in motion. You can choose to ride the wave, or be smothered by it.
While you may have a hard time believing it, I too experienced the same thing at the university.
Several courses I took, (interestingly most were from the humanities department --- don't know if that has any meaning) had a requirement of a book - invariably written by the professor - that were not cracked during the whole course.
While I was able to resell the books after the classes, I lost out on the deal. After serveral of these situations, I made a point of holding off on buying thin volumes that did not appear to be core texts, and was mostly right.
Slashdot Mirror
They may care if you possess some skill that they can not easily find among the unemployed. In which case, particularly if it is a key skill they want/need, they will certainly negotiate with you - and perhaps provide a lucrative contract for permanent work.
Your example does not take into account the fact that many people make poor choices when it comes to their skills and experiences during their life. Should society suffer because you screwed the pooch?
I guess you can probably tell most people don't live up to my expectations.
The folks organized at Cingular were certainly not your top level software developers/engineers/architects -- these folks were your cable splicers, CO techs, outside plant, and call-center employees. Hardly jobs I would classify as 'IT' in the traditional sense. That was a very bad example, a misrepresentation that doesn't come close to what the average
I do agree there are jobs where unions are absolutely necessary. True IT jobs (not technician helper jobs as in the Cingular example) are not the place to do it. You must have a layer of workers who have the flexibility to get unusual jobs in emerging technologies done quickly and effectively; the union will not provide that workforce (as I have seen from my own experience - with their departmental and job description limitations - creaking buraucracy and frivilous grievances - they don't do 'new' well without it being handed to them on a platter, and then you better have the paperwork done in triplicate, and clear instructions for how to accomplish the new job that conforms to their contractual agreement).
Making the jump from unionizing a call-center to unionizing your software developers is a questionable jump in logic. In the article Tony Long mentions 'smart' people he knows who lost their 'tech' job - and were not able to find another comparable. Nonetheless he doesn't elaborate on the circumstances - could it be the friend was not willing or able to change - learn new techniques or increase their education to enable them to remain viable inside the organization or in the workforce as a whole as the world economy changes? How would being in a union be beneficial - other than to keep someone in a job they are not suited for - to the detriment of the business. Does the person who allows themselves to get into that position sound 'smart' to you? Perhaps his friends' evaluation of their own skills was skewed by their overinflated sense of worth (I know folks who think they are smarter than they really are - and open their mouths to prove on numerous occaisions).
The future of IT is the future of small, highly capable teams that outperform traditional IT monoliths using advanced processes and tools. Contrary to the trend in other industries, the opportunities for striking out on your own are only growing: The outsourcing experiment is being seen as largely a failure because of cost overruns and shoddy workmanship, that needs to be identified and fixed by native engineers and developers locally anyway. The influx of poorly trained and motivated developers during the dot-com bubble is reversing - the pendulum swings back into balance; differentiate yourself now, or lose. If you don't care about being the best IT developer/integrator/engineer you can be - then maybe you don't deserve to be in the field at all.
Leave the computer science to the computer scientists (or people who have the drive to gain equivalent knowledge and apply it consistently). There is no room for a union in this world - and I can't see how you would circumscribe a union job in such an open-ended field.
/Flame On/
/Flame Off/
There are a metric-crap-ton of so-called 'developers' in my company who:
a) Have no love of the work.
b) Do not take the time to learn their craft inside and out.
c) Do not understand basic computer science.
d) Are a drag on the rest of us who do (because we have to take up the slack).
e) Make projects overrun time and cost and when they do arrive not perform as requested.
f) Are not willing to change (particularly the ones trained in the 1960's/70's who think every project must conform to the waterfall development lifecycle - and these guys are invariably in charge - and cliques of brown-nosers flock to them).
I will not shed a tear when these guys get shit-canned. Most came into the job during the dot-com bubble with dollar signs shining in their eyes. The times they are a changin'
I have kept my job because these guys can't perform; I deliver the goods to my subsidiary and change as the needs of my business changes. The large majority of developers are a lead anchor - and is a major reason we are stuck using outside vendors to build critical infrastructure. Furthermore, the leadership in the IT department has fostered a culture of protecting and expanding their 'turf' (bugetary and manpower) - at the expense of their internal customers and ultimately the business as a whole (even going so far as to prevent me from using an outside vendor or building an application myself on a project that then goes millions of dollars over budget and years late as a result - that is then abandoned, forcing us to resolve internally ourselves anyway!).
I get paid very well for what I do. Unionizing would not help me at all, and would definitely worsen the situation as described above. Given the way my industry is going - we will have to be agile in order to compete with our nimble competitors. Unionizing these slackers would not help us at all.
If I were in control, I would interview all the developers and determine who is dead weight and who is not (not only am I a developer, but I have also been a project manager and a key stakeholder in various projects over the years where the IT department was involved). If they will help the company compete flexibly and put internal and external customers first - then they can stay. If they want to keep the status-quo - then they can go. All the top 'empire builders' would be out on the street - for no other reason than the damage they have already done to my business.
Sadly, I am not in control - so I will probably have to continue to carry these folks on my back.
I've been doing this for over 10 years - and have experienced the limitations I've listed over and over again, project after project. It should be noted that one of the signs of mental illness is performing the same process over and over again expecting a different outcome. It is time for change within IT - and it involves building small effective teams - instead of outsourcing (because our experience has also shown that outsourced work is just as bad as poorly motivated internal development), or conversely clinging to a crumbling IT empire. The business must survive! Eventually the business will determine what is a drain on it and remove the problem. Your mission as an IT person is to be part of the solution, rather than part of the problem.
The refinery cartel could have done something about this long ago. Only one oil company, that I am aware of, has retooled their refineries to allow them to switch to generating alternative fuels - Shell.
It is now the 11th hour, and they are grabbing at straws to keep their bloated profits.
I wonder how many jobs would really be created if we opened up this so-called 'H' prize to all forms of alternative energy. My guess is it would create even more jobs than are employed at refineries today; of course the profits would be distributed among a larger number of small players - not good for the money bags.
If you really don't like what is (and has always been) going on - build it yourself, or if you can't gain the skills or know someone who has them, buy a bicycle and/or use public transportation. We can think and act for ourselves - if we let others do the thinking we only have ourselves to blame.
a) I would always want to be able to disable the transponder on such a device myself - no feasible with subdermal implant.
b) If the database gets corrupted for a given application I would want to be able to reprogram the device -- again not feasible with subdermal implant.
c) As mentioned elsewhere - RFIDs in their current incarnation are nothing more than identification beacons. I would prefer a device that was smart enought to know when to respond and when not to respond, and furthermore encrypt the data it was sending across the ether (much as it is advisable today to have a VPN server behind every non-trusted gateway to authenticate and encrypt traffic from an unsecure network into a secure network).
'Infestation' is probably more accurate...
There is a Springfield Virginia.
In the context of a proprietary project, it might be the case that having neophytes mess about in production projects might be beyond the ability of a development shop to manage - provided they are not willing to share the responsiblity of reviewing code with the community surrounding the project.
We are, however, talking about FOSS projects - where the price of admission is free and very community oriented. If such a project is big enough to attract a large audience - it will invariably have a good size subset of eyeballs that have the skills necessary to find the bugs easily (while you may scoff at 'The Cathedral and the Bazaar', the truths contained are borne out time and again). As the person in the article says, the would-be developer would have his halfbaked idea flamed off of the release list if it did not fly.
On the other hand, small projects will implode if there are not enough eyeballs --- they will be the Frankenstein monstrocities that no one will use. Good riddance - and I can't see accelleration of this process as a bad thing because it makes it easier to seperate the chaff from the wheat - so to speak - for potential users of the applications produced.
As a result, the cream will rise to the top - for no other reason than it works best for a given problem domain.
There are plenty of examples that prove this out (Firefox, Linux kernel, Apache, Python, Debian, etc...) - and the marginalized misanthropic and micro-niche projects are too many to count - neutral really (as I have found niche software that was perfectly suitable for my own purposes, that would not stand the test of the masses - right and good as far as I am concerned).
Nevertheless most development shops must justify their own existence, and thus can not tollerate the potential of having the project direction and development subjugated (even though that might be best for the community surrounding the application). So, I don't expect to see this evolve in any significant way in the proprietary software arena. Once again, FOSS will lead where others fear to tread.
I recently picked up a perfectly functional 486-dx 66mhz Cyrix clone cpu laptop (circa 1993 - made by AST - Canadian company which no longer exists) for $45 from my local Goodwill computer store. It came with 20 MB ram, a 500 MB hard drive, two pcmcia ports, and the usual mix of parallel, serial and keyboard ports. The LCD monitor on it works perfectly, all of the keyboard functions work, and it has a built-in trackball that also is in working order. The outer case is in nearly immaculate condition - only a few scratches here and there. The battery needs to be refurbished or replaced - that is true of any 13 year old laptop.
It was running DOS 4.1 when I got it (I assume this is what it was originally loaded with). I decided to improve its utility by loading Slackware 10.2 on it (You can see the full blown procedure I used here). I did not want to use the Zipslack install method (as mentioned in the article, you have some performance issues I could not afford on such old equipment). Without a CDROM, I would need to furthermore modify the installation process. I happen to have a Iomega parallel port zip drive, so I used the boot disk for the zipslack installation to access this drive. The boot disk assumes your root disk(s) will be on the parallel port device. The problem with that is that while the zipslack install disk can recognize and use the zip drive for installation, the regular installation root disks do not (have to talk to Patrick about that). Luckily, you can specify another mount location (just not the parallel port drive) - so I set aside a 100MB partition on the hard drive, and used that for the installation.
I booted the system from floppy using the zipslack root disk and the standard installation floppies. Then I mounted the parallel port zip drive, and partitioned, formated and mounted the 'source' partition on the hard drive. After that it was a simple matter to copy over the slackware packages I had earlier copied onto a zip disk from my workstation. Finally I kicked off the setup utility after partitioning the hard drive's remaining space. After that, the install was normal. Starting with a 350 MB root partition (used 50MB for swap, and the 100MB source) - I ended up with 25% free space (used about 225 MB for the packages I loaded). I was also able to free up the 100MB source partition afterwards - so I have a whopping 175MB to play with.
Note that I did not load all the packages available from the Slackware distro - most of the A and AP packages, the key network packages, and some development packages (python). So, no X-windows. However, I found an application called 'twin' (Textmode WINdow environment) that emulated an X server, providing multiple text-based windows that have all the usual controls (resizing, scrollbars, window shade, minimize etc). Twin runs very fast on the 486, and provides the multiple window capability (including copy/paste between windows) that you would need for most jobs. Twin is an older program - last updated in 2003, which I had to build on my workstation, then move over to the laptop via the zipdrive.
Without a graphics capability, most of the modern tools available in KDE or GNOME are out of reach - but that is okay. I use 'jed' editor (emulates emacs commands - but smaller footprint), and am writing my own tools in python - basically to capture thoughts, and provide automation for uploading my field-notes onto my server when connected to my home network (saving my pennies to get a pcmcia NIC soon).
Extending the life of the laptop was well worth the trouble. While it may not be cutting edge in terms of looks - for what I do it gets the job done.
You hit upon a key point there. Vocabulary, grammar and spelling are not improved significantly through writing; they are improved by reading well written works that challenge your current knowledge.
The larger your vocabulary, the more accurately you can describe the world. The better your grammar, the more likely you will be to keep your readers interested in the subject matter. The more accurate your spelling the less confusion you will sow among your readers.
The key value-add for Apple has always been the tight integration of software and hardware within their product line.
They had that to a lesser degree with the Apple ][, tightened it up with Macintosh, and continue that tradition to this day (with the added benefit of extensibility afforded by X and BSD compatibility).
They are not going to throw that away.
On a side note, if I were to buy an Apple that would be the key reason - and no other. When I spend the $$$ on Apple, the expectation is it will just 'work' right out of the box, and that the interface will be a natural one. In fact I am considering getting my wife a Mac Mini to replace her Windows machine so I can finally rid my network of Microsoft (she is already using %100 FOSS applications on that box) and avoid having to troubleshoot heisenbugs in Windows.
I must be addicted to work by the same reasoning. It's this damnable free market economy I live in - the government should pay for my therapy to free me from this addiction... :P
To amplify your thoughts -- the most successful FOSS projects have one thing in common: a strong leader in the form of a 'benevolent dictator' (Linux's Linus Torvald and Python's Guido van Rossum come to mind), or a team that serves the same purpose (Netscape's Mozilla team and Debian's technical commitee for example).
So the most successful projects have hac4ers on the back-end driving change, with a filter on the front-end controlling what gets into the releases after careful consideration over time. Ideas that are well developed and proven over time make it; 'flashes in the pan' that aren't well developed or proven useful don't make it.
Anyone who thinks their project could be generally useful to a large number of people should probably think about making sure such a structure exists, even if you serve as your own 'benevolent dictator' to start out with. Another thing that might help, is creating an interface (a la Firefox plug-ins or Linux dynamic driver modules etc.) that allow you to extend your application without the need to tightly couple the application code base and the extension - that is always a winner.
Intel and Skype are now at the top of my 'do not buy' list.
Anticompetitive activities should not be rewarded.
I played the original 'Dungeon' in my highschool's computer lab on CRT terminals connected to the school's minicomputer.
Zork I, II and III followed later on --- on my Atari 800XL. Those where the days when men were men and the CLI ruled...
Amazingly the titles of the golden age of text adventures are still alive via emulators you can run on your Linux/Windows box.
I got the Texas Instruments TI99A when I was 16 in 1980. I quickly learned how to program it using the built-in basic interpreter. It had some neat features; you could intercept key presses from within your application, and also manipulate screen sprites to build some interesting interfaces/games. I saved my programs to cassette tapes on the boom-box next to my desk - when it wasn't being used for blasting music (they actually used to make boom-boxes with a line-in back then...thank the RIAA for that, I suppose). I took my highschool's first computer science class that year - and spent less time waiting in the lab for console time as a result (I would debug programs at home, then transcribe them into a notebook, and only have to do data entry, then run them on the teleprinter to get credit).
I credit this machine with planting the seed that would become my career later on. I looked up the price of that machine one time -- it was somewhere in the region of $1500-$2000 in 1980 dollars! I don't know how my parents aforded it; I can't aford a $500 machine today...
Looks like it is time for you to find a new employer.
If they are completely clueless (believing everything your read or see on TV probably fits the bill), you are jeopardizing your long-term financial security by staying on with a company that is obviously moving towards bankruptcy.
With larger and larger storage needs (for such things as DVR, centralized content management systems, music siloing etc...) and for interactivity between more and more devices on the network, I can certainly see a point at which 100mbs will not suffice for most users.
:P
Over the next 5 to 10 years we will see an explosion of applications, and NAS (network attached storage) devices and multiple computers and computerized devices will enter the home network and become the norm.
It is coming; lead, follow, or get out of the way...
Inconceivable!
The moment the arpanet backbone was commercialized we ran the risk of filtration of access.
Personally I think it would be suicide to not maintain your network as a universal interconnection point - since the value of any intranet increases with the increase in the number of nodes (Metcalf's Law). As mentioned perviously, AOL is a prime example of how its percieved value was lower than their competitors - and it ended up having to open up its network.
The folks at Google are smart. I don't see them making the same mistakes.
If there is a log in the road, you go around it. That presumes you have the skills to do so - otherwise you are stuck.
The robot holding the gun kills people...
A special purpose game console is not the same thing as a general purpose computer. Computer architecture was opened up to allow unforseen uses/programming, and devices to be produced after the fact to increase its overall value and usefulness.
Moving a general purpose open architecture, to a closed proprietary one will limit its usefulness - and will certainly boost the sales of manufacturers who refuse to go this route.
I am a software developer and hardware tinkerer; they can have my computer when they pry my cold dead hands off of it.
The pre-internet days of clearly delineated 'producers' and 'consumers' is an artifact of a bygone era.
Microsoft and other large corporations (MPAA, RIAA etc..) want to turn back the clock, and force us to become 'good consumers'. Why build when you can buy? Of course what you buy will be a tasteless vanilla mush - and you can buy versions with any color - provided that color is blue (with a Windows logo of course).
This is initially why we see independents gain ground in music and computing - and it will only continue to increase as Gen Y makes its presence felt -- particularly given the large amounts of their income that will be needed to support the Boomers (who will be mostly retired and a powerful lobby to lock-in their retirement benefits in Congress). Their decisions will be motivated by monetary pressures that will not support traditional 'producer'/'consumer' corporations. They will expect high value for nominal prices - and if you can't compete in that space, you will see your revenue and thus stock value plummet.
Non-open DRM schemes are just a means to the end of staving off this change - securing a steady flow of income from a flawed and outdated business plan. This will not work, because Gen Y - who outnumber both Gen X and the Boomers - will not be able to sustain it, feed themselves and save for their own retirement. The wave of change is already in motion. You can choose to ride the wave, or be smothered by it.
While you may have a hard time believing it, I too experienced the same thing at the university.
Several courses I took, (interestingly most were from the humanities department --- don't know if that has any meaning) had a requirement of a book - invariably written by the professor - that were not cracked during the whole course.
While I was able to resell the books after the classes, I lost out on the deal. After serveral of these situations, I made a point of holding off on buying thin volumes that did not appear to be core texts, and was mostly right.