I do believe those were around in Mosaic - version 1.0 circa April 1993...at least that's what I was clicking in X on my Sun Sparcstation pizzabox at that time. Actually there were other browsers available that implimented an http client - Cello for Windows 3.1 in 1993, and WWWVoila - initially an X hypercard link implimentation in 1991, and an http implimentation in 1992 (upon which Mosaic was based).
...without some thorough thought and some way to indicate those conflicts to the OS, its not going to work.
I think the solution for an OS level concurrency model with ostensibly single threaded applications is to read all of the instructions in one pass, building a matrix that identifies which instructions touch which memory locations. Where there is no conflict, you can safely partition those parts of the code at the low level out of hand. Of course, the algorithm to handle this would be far more complex to get more efficiency out of it - perhaps identifying portions of code that could be handled via resource locking etc. These bundles of instructions would be wrapped by the OS to perform as individual threads within the framework of the modified executable in memory to get the most benefit from this approach. As I've stated before (and Amdahl's law implies), some things are just serial - you can't chop them into pieces - those parts of the program would remain serial; beyond a certain percentage of these serial elements, and the OS would simply run it as a single thread - diminishing returns...
As for developers 'looking for another job' - the sad truth is they would not look for a new job, they would remain, and cause pain and suffering for the rest of us who had to clean up behind them - or deal with the deterioration of applications as an end user.
For a single application that is a one time process, as opposed to running said application.
- agreed. My interpretation of the original comment I was responding to was that the writer implied you only had to do it once, then it would be automatic for every application after that. I think we both can agree that is incorrect.
An application that makes good use of concurrancy works better from almost any perspective I can think of. Its more difficult to make, sure.
The point I was trying to make is it is more difficult to make and it is a far more complex application - therefore more opportunity exists in such a model for the introduction of bugs. I am not arguing that a concurrent application doesn't outperform a single threaded application - what I am saying is the odds of the average programmer creating a successful concurrent program are lower than if they simply stuck to a single threaded solution. Given the advancements in hardware and operating systems, there are only a few areas where I can see the absolute need for concurrent programming in the application layer: video games and high performance computing (computationally intensive data analysis). I would certainly not want multithreaded avionics, or a multithreaded nuclear power reactor control software. Where life and limb are concerned, absolute quality assurance is necessary. As a developer you should understand the KISS principle!
Furthermore, for the more mundane software I just want it to work consistently. A word processor should not be a million lines of code - combine code bloat with concurrency, and you are asking for a serious problem. I'm pretty happy with my hardware and software solutions (Apple OSX, Linux - and various open source tools). These come closest to that ideal - and more importantly to me are rock solid when compared to the alternatives I've used over the years.
the benefit from proper use of concurency is huge...
I agree that the benefit is huge, but the abuse of it has the potential to be even greater - particularly if you advocate forcing everyone to get on board the concurrency band wagon. Most developers have a hard enough time wraping their mind around pointers and memory management in C; throw concurrency into the mix, and you have a disaster waiting to happen.
My message is simple: concurrency where it makes sense, and single threads of execution where it doesn't. It doesn't have to be all or nothing.
Dual core alone makes a difference for the average user.... yes web browsing is single threaded but you aren't. If they are doing anything CPU intensive (media encoding/ITunes... what have you:) it can render a single core system unresponsive where with a dual core system you don't even really notice.
You get the benefits of that regardless of whether your application has a single thread of execution or concurrent (multi-threaded execution) because most modern OSes can assign applications to multiple CPUs. You don't have to make all applications concurrent to get benefit from a multiprocessor system.
My point is: this argument about 'having' to build concurrent applications is hogwash.
Concurrent programming today will be the 'Assembly Language' of tomorrow. Everyone knows about it, but rarely if ever use it.
Developers should be focusing on makeing an application that works well; concurrency makes that much more difficult.
At some point we'll reach a cut off where the added instability of the code will not justify concurrency inside of an application (and I know I don't want every application built to have to conform to concurrency - because the skills to do that consistently well are not consistently in the marketplace). I see two things happening: we'll continue happily along using interprocess communication with multiple applications - letting the OS assign processes to individual CPUs, or the OS will become smart enough to multithread the application at a lower level of abstraction (or both).
And by the way, concurrency is not a 'one time process'. Every new application will have to be sliced up logically - which data is global and requires locking? Which data is local to the thread? Is it even feasible to parallelize the application? That is not a cookie cutter process, except for the most trivial applications (which few will use anyway). Then there is Amdahl's Law, which essentially states that the more serialized a process is, the less benefit you get from a concurrent approach.
It is not easy, or simple - so get that right out of your head. Developers, as a group, can't do the simple stuff well, and you want them to abandon everything that works now in the name of concurrency? Insanity!
As an aside, it still amazes me how people latch on the latest pronouncements of doom. There is a reason people are coming forward with 'we must have concurrency or everything will fall apart!' - it is to make money. We don't have to change (although they would have you believe it), they just want you to change so they can continue to sell upgrades (software, hardware and peripherals) so their revenue stream will continue unabated. If you want even more buggy code than you have now, force programmers to make every application concurrent. Otherwise, leave well enough alone and let wiser heads make those decisions.
The key issue with MMOs vs. single player RPGs is that the players in an MMO can not divorce themselves entirely from reality. This is when out of character chat detracts from the experience.
On the other hand, single player RPGs are pretty much a 'one shot' afair, since the puzzles don't change between instances, and the characters don't learn anything new. Talking to an AI MOB can be pretty boring after the first few times.
The ideal situation would be a spontaneous world where everyone is in character all the time. In most MMORPGs there are 'roleplaying' servers that cater to this desire, with admins that address these issues when OOC situations occur.
What would be even better would be a less structured AI MOB functionality that would allow random events to happen within the boundaries of the story line for even more emersion. Anything to elimenate having to camp MOBs incessantly to level (I am sick of the level treadmill - and the major reason I stopped playing MMORPGs). BETTER YET - give the AI intention (as opposed to direction), the ability to interact with other AI, and the opportunity to drive the story in new unforseen directions. I would buy that game - MMO or RPG.
"There are so many ways of doing it improperly, and only one way of doing it right."
That is a fallacy - you can not know that there is 'only one way of doing it right', if you don't know what that 'right' way is to begin with - you are dealing with unknowns. In truth there are very few systems that collapse to a solution set of one. The phrase 'there is more than one way to skin a cat' comes to mind. This one statement tells me the person making the statement is more interested in controlling the method, rather than pursuing investigation for the sake of advancing our fundamental understanding. Every problem is not a nail, and every tool is not a hammer.
Given the variations evident (particularly when trying to propogate the 'one true' ontology), I see the semantic web as a utopia that is unapproachable. The reality will be some hybrid of the best ideas to come out of this research, coupled with (or layered above/below) the practicalities inherent with multiple ontologies/tagging systems, human interpretations and how to resolve/share those differences for each person. That is where the real solution set lays.
The need for parallel applications is overblown, particularly when modern OSs can manage single threaded applications across multiple CPUs and you can use interprocess communication to communicate between parent and child processes. For the uninitiated, a parent application forks (creates a copy of itself) child processes (which themselves can fork child processes - ad infinitum) all of which can run on seperate CPUs and communication with each other. Modern OSes manage the distribution of processes across multiple CPUs.
This is a model that has been around a long time, is easy to program, and just works. Whatever efficiency is lost in interprocess communication between single threaded applications is made up for in dealing with mutex issues in parallel programs. (From Wikipedia) "The programmer needs to be careful to avoid race conditions, and other non-intuitive behaviors. In order for data to be correctly manipulated, threads will often need to rendezvous in time in order to process the data in the correct order. Threads may also require atomic operations (often implemented using semaphores) in order to prevent common data from being simultaneously modified, or read while in the process of being modified. Careless use of such primitives can lead to deadlocks."
I don't see the benefit of doing concurrent programming in all cases, and see many problems that increase the complexity beyond what is reasonable to manage from a QA standpoint in most (in most applications data must be atomically modified - obviating the need to multithread, since all other threads will be busy-waiting for the data to be freed up anyway before they can work on it).
For computational research, I could see the usefulness of multithreading inside of an application. For practical applications it is too complicated, and the cost of time spent building and debugging a multithreaded system does not balance out against the return on the investment. Computer systems are complex enough as it is; lets work smart and not latch onto the latest buzz word/tool at the expense of all others. It might be cheaper to wait 6 months, and the percieved bottleneck may have been cleared up by the application of new hardware anyway (Beowulf cluster, or faster/more capable processors etc).
I view parallel programming much as I do assembly language: it is a tool that is useful for a specific problem domain - but I wouldn't want to do all of my programming in it.
I use OO (Open Office) on my Sun workstation and MS Office on my desktop machine at work, as well as OO on my Linux workstation and NeoOffice on my Macbook Pro at home.
To compare MS Office and OO/NeoOffice and say MS Office has no problems would be stretching the truth. I've had to deal with some show stoppers on MS Office - particularly its inconsistent spreadsheet support for.csv formatting, and lack of scalability with its Access database. I have yet to run into similar issues, or any issues for that matter, running OO or NeoOffice.
Aside from work (where we are mandated to use email), I stay away from email.
Most of my communications is via forums that I am a member of - most of which have an 'PM' (personal message) capability - which works much like email, but is specific to the members only.
Additionally other mediums, IRC chat, voice (Team Speak, Roger Wilco and the like) fill in for more immediate needs.
Email is not a priority, and the few accounts I still keep, I don't check.
On my Macbook Pro - I can't tell the difference between the built-in and piping it off to a stand-alone monitor. The display is certainly better than the old Acer 486-66 machine with 256 color LCD it replaced.
Of course, I'm not a professional photographer, videographer/film maker, graphic artist, or the like, and my eyesight is beginning to go (over 40).
Take reading and writing a file to disk, for example. There are pretty well established ways of doing this at a low level that are about as efficient as can be; there is no reason to rewrite that code.
On the other hand there are other things layered on top of that basic code (encryption, file system formats, etc) that encode new capabilities, that still utilize the low level code to access the disk. The new stuff leverages the existing capabilities to 'stand on the shoulders of giants' - quite literally.
That is not 'sad but true' - that is as it should be, because building upon existing code allows all of us who do software development to raise the bar without having to spend time reinventing the wheel. This is why computers and networks operate as consistently as they do with trillions of operations every day.
I shudder to think of a day when interoperability becomes legally hamstrung by patents - and systems fragment into a hodgepodge of competing protocols. As anyone who was alive in the early days of computers will tell you, passing information between systems was a very difficult proposition, with various numbering schemes, memory word sizes, and other variables that did not make sharing information a straight forward operation at all. The abstractions provided by the internet and associated tools fixed that problem. Do we really want a world like that again?
The author of the article might not like the lights, but they serve important purposes:
1. Motherboard LED displays failure of POST via blink pattern. 2. HD lights indicate the platter is spinning and heads are seeking (whether it is reading or writing is another thing). 3. DSL modem lights indicate connection status (DSL physical layer, IP layer, etc...) 4. Router and NIC lights indicate physical layer connection (ping-able), IP layer connection and activity (ssh/telnet-able) 5. LEDs on flightstick indicate it is connected and functional. 6. Temperature LCD display on fan controller blinks to indicate temperature thresholds. 7. Lava lamp light accents the gaming/coding session.
I've used the blinkin' lights to troubleshoot more than one problem in my network, quicker than the alternative.
He can't be a techno-geek, because no self respecting geek would rage against blinking lights.:0
That may be true, but I would think Zombies (and their extreme cousins those infected with the 28-days-later virus) would be far more effective at finding prey if they only were able to utilize the computer more effectively in their search (their hyperactive blood-scent ability notwithstanding).
I still don't get why people keep using ksh (or derivatives).
BASH gives you everything -- backwards compatibility with all those dusty (and perfectly serviceable) sh scripts, history support that works like csh (history functionality in csh is superior to ksh's imho), and nice things like arrays etc that you would expect to find in a regular programming language.
I agree wholeheartedly - you've taken the discussion from the university logically to the correct end (or beginning): treat CS just as other 'required' courses in Highschool and College.
This reminds me of my own experience - I learned Basic and Fortran in my Highschool's first computer science course -- in 1981. Back then it was all about understanding the computer and how to build applications to make it work.
Today the focus has shifted - few Highschools provide programming courses anymore. Everything is 'computer literacy' - which equates to learning how to use office tools (spreadsheets, word processors, etc). That is the wrong approach - because more and more interfaces are being designed with embedded programability if for nothing else. It is imperative that we give kids the lingua franca - how to understand consistent constructs of a turing complete language enough to build useful applications, which could then be used as a springboard for further development at the university.
Moving emphasis away from programming proficiency was a key to the success of programs...
This is the problem - not the solution.
I have to deal with too many CS graduates today that have no concept of computer architecture or software development because the emphasis of the courses is dumbed down.
At some point the theoretical has to be usefully applied where the rubber meets the road. The majority of students need to understand this because the vast majority of them are not going to be employed as researchers and theorists, but instead as architects and developers - in roles that lean heavily on engineering. We are not hiring MIS graduates for these positions - precisely because they do not have a firm grasp of the theoretical aspects that are also important to grasp in the applied realm. This is the biggest problem in this field I perceive today.
I think the whole problem came about when we split MIS and CS into 'applied' and 'theoretical/math centric' spheres. MIS programs suffered because they produced developers who don't have a firm grasp of computer architecture and theory - focusing exclusively on business processes instead. CS suffered because it has moved more toward the theoretical at the expense of application. Both groups are missing key ingredients to be useful outside of their limited spheres.
We need 'jacks-of-all-trades' that can effectively be architects and developers, or pursue the higher branches of the theoretical computer science world as they desire. I would suggest the following changes in the university to make this happen:
1. Merge the MIS and CS undergraduate programs. There is no good reason to keep them seperate, and many reasons why this has been bad for all areas of computing.
2. Define the minimal requirements to make the new degree a true prerequisite for CS graduate work or professional employment as an architect or developer. The goal is to raise the bar so that it is truely seen as a benefit to employment and employers - much as Engineers, Lawyers and Doctors are seen today.
3. Allow minors/emphasis areas in the degree for business/application, architecture/engineering (software and hardware), and theoretics/art.
4. Define a code of ethics for the field. Just as the Physician has the physician's oath, and Engineers and Lawyers have professional societies and liscensing - computer system architects and developers must be held to a higher standard.
If this means there are less CS graduates - so be it. There are too many non-starters in the business as it is today - people who saw the CS degree as a quick ride to fortune who have been behind much of the system failures and ugliness we've seen over the past decade. Additionally, I think the degree would become more valuable to women if it was seen as a pathway to success, rather than something anyone can easily accomplish.
Pacman's desk is completely empty - except for his trusty monitor and scanner. A shredder sits next to the trash can. He's managed to convince many of his coworkers to put information onto the web in a CMS instead of killing large numbers of trees, so he doesn't have to use the scanner or shredder as much as he used to.
Slashdot Mirror
You are talking about this link?
I do believe those were around in Mosaic - version 1.0 circa April 1993...at least that's what I was clicking in X on my Sun Sparcstation pizzabox at that time. Actually there were other browsers available that implimented an http client - Cello for Windows 3.1 in 1993, and WWWVoila - initially an X hypercard link implimentation in 1991, and an http implimentation in 1992 (upon which Mosaic was based).
I think the solution for an OS level concurrency model with ostensibly single threaded applications is to read all of the instructions in one pass, building a matrix that identifies which instructions touch which memory locations. Where there is no conflict, you can safely partition those parts of the code at the low level out of hand. Of course, the algorithm to handle this would be far more complex to get more efficiency out of it - perhaps identifying portions of code that could be handled via resource locking etc. These bundles of instructions would be wrapped by the OS to perform as individual threads within the framework of the modified executable in memory to get the most benefit from this approach. As I've stated before (and Amdahl's law implies), some things are just serial - you can't chop them into pieces - those parts of the program would remain serial; beyond a certain percentage of these serial elements, and the OS would simply run it as a single thread - diminishing returns...
As for developers 'looking for another job' - the sad truth is they would not look for a new job, they would remain, and cause pain and suffering for the rest of us who had to clean up behind them - or deal with the deterioration of applications as an end user. - agreed. My interpretation of the original comment I was responding to was that the writer implied you only had to do it once, then it would be automatic for every application after that. I think we both can agree that is incorrect.
The point I was trying to make is it is more difficult to make and it is a far more complex application - therefore more opportunity exists in such a model for the introduction of bugs. I am not arguing that a concurrent application doesn't outperform a single threaded application - what I am saying is the odds of the average programmer creating a successful concurrent program are lower than if they simply stuck to a single threaded solution. Given the advancements in hardware and operating systems, there are only a few areas where I can see the absolute need for concurrent programming in the application layer: video games and high performance computing (computationally intensive data analysis). I would certainly not want multithreaded avionics, or a multithreaded nuclear power reactor control software. Where life and limb are concerned, absolute quality assurance is necessary. As a developer you should understand the KISS principle!
Furthermore, for the more mundane software I just want it to work consistently. A word processor should not be a million lines of code - combine code bloat with concurrency, and you are asking for a serious problem. I'm pretty happy with my hardware and software solutions (Apple OSX, Linux - and various open source tools). These come closest to that ideal - and more importantly to me are rock solid when compared to the alternatives I've used over the years. I agree that the benefit is huge, but the abuse of it has the potential to be even greater - particularly if you advocate forcing everyone to get on board the concurrency band wagon. Most developers have a hard enough time wraping their mind around pointers and memory management in C; throw concurrency into the mix, and you have a disaster waiting to happen.
My message is simple: concurrency where it makes sense, and single threads of execution where it doesn't. It doesn't have to be all or nothing.
You get the benefits of that regardless of whether your application has a single thread of execution or concurrent (multi-threaded execution) because most modern OSes can assign applications to multiple CPUs. You don't have to make all applications concurrent to get benefit from a multiprocessor system.
My point is: this argument about 'having' to build concurrent applications is hogwash.
Check out Amdahl's Law. Some things are not parallizeable, and attempting to do so will provide diminishing returns.
Concurrent programming today will be the 'Assembly Language' of tomorrow. Everyone knows about it, but rarely if ever use it.
Developers should be focusing on makeing an application that works well; concurrency makes that much more difficult.
At some point we'll reach a cut off where the added instability of the code will not justify concurrency inside of an application (and I know I don't want every application built to have to conform to concurrency - because the skills to do that consistently well are not consistently in the marketplace). I see two things happening: we'll continue happily along using interprocess communication with multiple applications - letting the OS assign processes to individual CPUs, or the OS will become smart enough to multithread the application at a lower level of abstraction (or both).
And by the way, concurrency is not a 'one time process'. Every new application will have to be sliced up logically - which data is global and requires locking? Which data is local to the thread? Is it even feasible to parallelize the application? That is not a cookie cutter process, except for the most trivial applications (which few will use anyway). Then there is Amdahl's Law, which essentially states that the more serialized a process is, the less benefit you get from a concurrent approach.
It is not easy, or simple - so get that right out of your head. Developers, as a group, can't do the simple stuff well, and you want them to abandon everything that works now in the name of concurrency? Insanity!
As an aside, it still amazes me how people latch on the latest pronouncements of doom. There is a reason people are coming forward with 'we must have concurrency or everything will fall apart!' - it is to make money. We don't have to change (although they would have you believe it), they just want you to change so they can continue to sell upgrades (software, hardware and peripherals) so their revenue stream will continue unabated. If you want even more buggy code than you have now, force programmers to make every application concurrent. Otherwise, leave well enough alone and let wiser heads make those decisions.
The key issue with MMOs vs. single player RPGs is that the players in an MMO can not divorce themselves entirely from reality. This is when out of character chat detracts from the experience.
On the other hand, single player RPGs are pretty much a 'one shot' afair, since the puzzles don't change between instances, and the characters don't learn anything new. Talking to an AI MOB can be pretty boring after the first few times.
The ideal situation would be a spontaneous world where everyone is in character all the time. In most MMORPGs there are 'roleplaying' servers that cater to this desire, with admins that address these issues when OOC situations occur.
What would be even better would be a less structured AI MOB functionality that would allow random events to happen within the boundaries of the story line for even more emersion. Anything to elimenate having to camp MOBs incessantly to level (I am sick of the level treadmill - and the major reason I stopped playing MMORPGs). BETTER YET - give the AI intention (as opposed to direction), the ability to interact with other AI, and the opportunity to drive the story in new unforseen directions. I would buy that game - MMO or RPG.
"There are so many ways of doing it improperly, and only one way of doing it right."
That is a fallacy - you can not know that there is 'only one way of doing it right', if you don't know what that 'right' way is to begin with - you are dealing with unknowns. In truth there are very few systems that collapse to a solution set of one. The phrase 'there is more than one way to skin a cat' comes to mind. This one statement tells me the person making the statement is more interested in controlling the method, rather than pursuing investigation for the sake of advancing our fundamental understanding. Every problem is not a nail, and every tool is not a hammer.
Given the variations evident (particularly when trying to propogate the 'one true' ontology), I see the semantic web as a utopia that is unapproachable. The reality will be some hybrid of the best ideas to come out of this research, coupled with (or layered above/below) the practicalities inherent with multiple ontologies/tagging systems, human interpretations and how to resolve/share those differences for each person. That is where the real solution set lays.
The need for parallel applications is overblown, particularly when modern OSs can manage single threaded applications across multiple CPUs and you can use interprocess communication to communicate between parent and child processes. For the uninitiated, a parent application forks (creates a copy of itself) child processes (which themselves can fork child processes - ad infinitum) all of which can run on seperate CPUs and communication with each other. Modern OSes manage the distribution of processes across multiple CPUs.
This is a model that has been around a long time, is easy to program, and just works. Whatever efficiency is lost in interprocess communication between single threaded applications is made up for in dealing with mutex issues in parallel programs. (From Wikipedia) "The programmer needs to be careful to avoid race conditions, and other non-intuitive behaviors. In order for data to be correctly manipulated, threads will often need to rendezvous in time in order to process the data in the correct order. Threads may also require atomic operations (often implemented using semaphores) in order to prevent common data from being simultaneously modified, or read while in the process of being modified. Careless use of such primitives can lead to deadlocks."
I don't see the benefit of doing concurrent programming in all cases, and see many problems that increase the complexity beyond what is reasonable to manage from a QA standpoint in most (in most applications data must be atomically modified - obviating the need to multithread, since all other threads will be busy-waiting for the data to be freed up anyway before they can work on it).
For computational research, I could see the usefulness of multithreading inside of an application. For practical applications it is too complicated, and the cost of time spent building and debugging a multithreaded system does not balance out against the return on the investment. Computer systems are complex enough as it is; lets work smart and not latch onto the latest buzz word/tool at the expense of all others. It might be cheaper to wait 6 months, and the percieved bottleneck may have been cleared up by the application of new hardware anyway (Beowulf cluster, or faster/more capable processors etc).
I view parallel programming much as I do assembly language: it is a tool that is useful for a specific problem domain - but I wouldn't want to do all of my programming in it.
I use OO (Open Office) on my Sun workstation and MS Office on my desktop machine at work, as well as OO on my Linux workstation and NeoOffice on my Macbook Pro at home.
.csv formatting, and lack of scalability with its Access database. I have yet to run into similar issues, or any issues for that matter, running OO or NeoOffice.
To compare MS Office and OO/NeoOffice and say MS Office has no problems would be stretching the truth. I've had to deal with some show stoppers on MS Office - particularly its inconsistent spreadsheet support for
Aside from work (where we are mandated to use email), I stay away from email.
Most of my communications is via forums that I am a member of - most of which have an 'PM' (personal message) capability - which works much like email, but is specific to the members only.
Additionally other mediums, IRC chat, voice (Team Speak, Roger Wilco and the like) fill in for more immediate needs.
Email is not a priority, and the few accounts I still keep, I don't check.
On my Macbook Pro - I can't tell the difference between the built-in and piping it off to a stand-alone monitor. The display is certainly better than the old Acer 486-66 machine with 256 color LCD it replaced.
Of course, I'm not a professional photographer, videographer/film maker, graphic artist, or the like, and my eyesight is beginning to go (over 40).
Take reading and writing a file to disk, for example. There are pretty well established ways of doing this at a low level that are about as efficient as can be; there is no reason to rewrite that code.
On the other hand there are other things layered on top of that basic code (encryption, file system formats, etc) that encode new capabilities, that still utilize the low level code to access the disk. The new stuff leverages the existing capabilities to 'stand on the shoulders of giants' - quite literally.
That is not 'sad but true' - that is as it should be, because building upon existing code allows all of us who do software development to raise the bar without having to spend time reinventing the wheel. This is why computers and networks operate as consistently as they do with trillions of operations every day.
I shudder to think of a day when interoperability becomes legally hamstrung by patents - and systems fragment into a hodgepodge of competing protocols. As anyone who was alive in the early days of computers will tell you, passing information between systems was a very difficult proposition, with various numbering schemes, memory word sizes, and other variables that did not make sharing information a straight forward operation at all. The abstractions provided by the internet and associated tools fixed that problem. Do we really want a world like that again?
Windows is better funded than any OS on the planet, therefore they are practically invisible...?
I like the cut of his jib.
The author of the article might not like the lights, but they serve important purposes:
:0
1. Motherboard LED displays failure of POST via blink pattern.
2. HD lights indicate the platter is spinning and heads are seeking (whether it is reading or writing is another thing).
3. DSL modem lights indicate connection status (DSL physical layer, IP layer, etc...)
4. Router and NIC lights indicate physical layer connection (ping-able), IP layer connection and activity (ssh/telnet-able)
5. LEDs on flightstick indicate it is connected and functional.
6. Temperature LCD display on fan controller blinks to indicate temperature thresholds.
7. Lava lamp light accents the gaming/coding session.
I've used the blinkin' lights to troubleshoot more than one problem in my network, quicker than the alternative.
He can't be a techno-geek, because no self respecting geek would rage against blinking lights.
That may be true, but I would think Zombies (and their extreme cousins those infected with the 28-days-later virus) would be far more effective at finding prey if they only were able to utilize the computer more effectively in their search (their hyperactive blood-scent ability notwithstanding).
All joking aside, you make a good point. I welcome a time when people actually think before engaging their mouths (or keyboard, as the case may be).
I would think Libertarians would not want anything state controlled - since they believe in limited government and all.
You are thinking of Facists (state controlled corporatism).
Bollocks... I can't tell the difference in speed between NeoOffice under OSX, and Open Office under Darwin(X11).
;)
Of course, I am running a MacBook Pro with an Intel Core 2 Duo at 2+GHZ...
If you are trying to run it on an Apple ][ - well, then that is another story...
I still don't get why people keep using ksh (or derivatives).
BASH gives you everything -- backwards compatibility with all those dusty (and perfectly serviceable) sh scripts, history support that works like csh (history functionality in csh is superior to ksh's imho), and nice things like arrays etc that you would expect to find in a regular programming language.
Your's are the most insightful comments I've heard in this discussion. If I had any mod points, I'd bump this up a notch.
I agree wholeheartedly - you've taken the discussion from the university logically to the correct end (or beginning): treat CS just as other 'required' courses in Highschool and College.
This reminds me of my own experience - I learned Basic and Fortran in my Highschool's first computer science course -- in 1981. Back then it was all about understanding the computer and how to build applications to make it work.
Today the focus has shifted - few Highschools provide programming courses anymore. Everything is 'computer literacy' - which equates to learning how to use office tools (spreadsheets, word processors, etc). That is the wrong approach - because more and more interfaces are being designed with embedded programability if for nothing else. It is imperative that we give kids the lingua franca - how to understand consistent constructs of a turing complete language enough to build useful applications, which could then be used as a springboard for further development at the university.
This is the problem - not the solution.
I have to deal with too many CS graduates today that have no concept of computer architecture or software development because the emphasis of the courses is dumbed down.
At some point the theoretical has to be usefully applied where the rubber meets the road. The majority of students need to understand this because the vast majority of them are not going to be employed as researchers and theorists, but instead as architects and developers - in roles that lean heavily on engineering. We are not hiring MIS graduates for these positions - precisely because they do not have a firm grasp of the theoretical aspects that are also important to grasp in the applied realm. This is the biggest problem in this field I perceive today.
I think the whole problem came about when we split MIS and CS into 'applied' and 'theoretical/math centric' spheres. MIS programs suffered because they produced developers who don't have a firm grasp of computer architecture and theory - focusing exclusively on business processes instead. CS suffered because it has moved more toward the theoretical at the expense of application. Both groups are missing key ingredients to be useful outside of their limited spheres.
We need 'jacks-of-all-trades' that can effectively be architects and developers, or pursue the higher branches of the theoretical computer science world as they desire. I would suggest the following changes in the university to make this happen:
1. Merge the MIS and CS undergraduate programs. There is no good reason to keep them seperate, and many reasons why this has been bad for all areas of computing.
2. Define the minimal requirements to make the new degree a true prerequisite for CS graduate work or professional employment as an architect or developer. The goal is to raise the bar so that it is truely seen as a benefit to employment and employers - much as Engineers, Lawyers and Doctors are seen today.
3. Allow minors/emphasis areas in the degree for business/application, architecture/engineering (software and hardware), and theoretics/art.
4. Define a code of ethics for the field. Just as the Physician has the physician's oath, and Engineers and Lawyers have professional societies and liscensing - computer system architects and developers must be held to a higher standard.
If this means there are less CS graduates - so be it. There are too many non-starters in the business as it is today - people who saw the CS degree as a quick ride to fortune who have been behind much of the system failures and ugliness we've seen over the past decade. Additionally, I think the degree would become more valuable to women if it was seen as a pathway to success, rather than something anyone can easily accomplish.
You can buy WOW for the MAC: store.apple.com
All this 'I can't play games on the MAC' talk sounds like FUD to me.
I say 'H323' or 'SIP', depending on the circumstances.
Pacman's desk is completely empty - except for his trusty monitor and scanner. A shredder sits next to the trash can. He's managed to convince many of his coworkers to put information onto the web in a CMS instead of killing large numbers of trees, so he doesn't have to use the scanner or shredder as much as he used to.