First one, for those of you who've been lambasted by maintainers/etc when submitting Linux/whatever patches because your code had extra whitespace at the end of the line. This highlights such whitespace by turning the background color red on those characters:
function WhitespaceHighlight(syn)
if a:syn =~ 'diff'
" diff syntax should trailing whitespace on non-addition lines
syn match diffAdded "^+.*" contains=WhiteSpaceEOL
syn match WhitespaceEOL display/\s\+$/ contained
elseif a:syn =~ '^\v(asm|c|config|cpp|ia64|crontab|fortran|html|man|pascal|perl|postscript|procmail|python|sh|csh|tcsh|zsh|spec|tcl|vim)$'
" bug: Innards of C comments aren't highlighted
syn match WhitespaceEOL display/\s\+$/
endif endfunction
The next one is for those of you who've edited read-only files, only to realize at the end of the editing session that you can't write to it. This set of entries makes read-only buffers non-modifiable (i.e. editing commands don't work), and selects different colorschemes based on whether the current buffer is modifiable or not (a visual trigger -- in my case a black background means not editable, dark blue means I can edit it).
" Color schemes let rwcolor="darkblue" let rocolor="elflord"
" Make sure automatic color schemes always know they have dark backgrounds " ColorScheme event appeared no later than version 7.1. Probably 7.0 if (v:version >= 700)
autocmd ColorScheme * set background=dark endif
" Change modifiability and color scheme based on read-only status of " current buffer function Modifiable()
" Make readonly files non-modifiable, so we don't make a
" bunch of changes only to realize we can't save them
if &readonly
set nomodifiable
else
set modifiable
endif
" Set the colorscheme based on the readonly/modifiable
" status of the file. This gives a visual cue as to
" when modifying is disallowed.
if has("gui_running")
if &modifiable
let g:colors_name=g:rwcolor
else
let g:colors_name=g:rocolor
endif
if (v:version >= 700)
doautocmd ColorScheme
else
" This has the same effect, but is kludgy
" and may miss some of the side-effects.
" It does the job for our purposes.
set background=dark
endif
endif endfunction
Sounds pretty much like a GM's recollection of a (sloppily run?) role-playing adventure. The internal inconsistencies and fanciful but less than coherently planned characters and plot would be par for the course in many RPG sessions.
Exactly. Too many people assume that any given programmer can write any given program. What isn't generally realized (at least by the masses) is that programming really is about acquiring expertise in a particular domain and then solving problems in that domain through the use of computer programs. Generally some of the most effective programs I've seen have been written, on their first pass, by a person with intimate domain knowledge, and mediocre programming/computer knowledge. The program then becomes a standout when someone with intense programming and computer architecture knowledge improves the code from there (they need not be a subject domain expert, but it helps).
I do take issue with sexconker assuming that I "just don't get it". Heh. If s/he only knew. Whatever, no biggie. I do agree that distributed algorithms are generally more difficult to implement/design than non-distributed, but that's not exactly the same thing as serial versus parallel algorithms (non-distributed generally involves access to data through a common address space, distributed doesn't, though even those pseudo-definitions come up a bit short).
Again and again I read in industry rags and on various web sites that multi-threaded programming is hard, and nobody knows how to do it, and that it's difficult to debug, and all that. I believe what they're really saying is "The set of programmers who are accustomed to multi-threaded programming/debugging is (relatively) small, and thus applications aren't going to make good use of the shift to multicore CPU packages." Familiarity with a skill, and the supply of labor familiar with said skill, is distinct from it being easy or hard.
Anyway, I stand by my belief that parallel programming is not as difficult as most people are led to believe. Some problems don't lend themselves well to parallel solutions, or don't merit the added complexity, but many many of them do. In ten years time I predict that most computer programming education will assume the use of threading, and that anyone who isn't competent with threading will severely limit their own job prospects.
I'm still not sure where this idea that "multi-threaded programming is hard" comes from. It's not. It seems that most people are just afraid of it because they're not familiar with it.
Or perhaps I just overestimate the mental capacity of most programmers? Having looked at a lot of code, there may be merit to that theory.
What I don't see mentioned very often, if at all, is the implicit assumption in distributed systems such as git, that a single person has ultimate integration responsibility and authority in order to form the official/mainline release. That is, given a single tree that is considered the main one from which all others ultimately derive (Linus' tree in the Linux case), there is absolutely no way for tools such as git to allow collaborative maintenance of that tree. In the end, the owner of that tree must perform all checkins to the tree, and must resolve all merge conflicts themself. This is a dual problem in that it wastes the time of a potentially talented developer (e.g. Linus) doing the mundane work of merging and integration, and the additional problem that if this mainline tree owner is not an expert in some particular area of the code, they are likely to make mistakes when resolving conflicts or performing other integration tasks.
Contrast this with a centralized source model where all developers have the ability to check in to the tree, optionally coupled with a peer review process, enforced either through convention or through mechanisms in the tools. Under this model each developer is responsible for their own integration and merging efforts, not wasting the time of a centralized authority. Not only is the central authority freed from routine tree maintenance work, but each developer can make the best and wisest decisions regarding the particular area of the codebase in which they are an expert, and not have to become involved in areas they have little experience with. Granted, for larger projects there is still a need for some management of checkin authorization, particularly to avoid conflicts during large tree merge operations and the like, but it's more of a coordination role than an authorization role.
This second model is what my employer uses, and our homegrown source control system is well-tailored to it (it actually has capabilities for more centralized control, but they are by and large unused). Perhaps this is unusual, as my experience with other employers is minimal, and mostly took the form of "copy your code into this directory once in a while" (i.e. "Source control? Why would we need that?"). However, given adequately diligent and intelligent developers, I have to say it works marvelously.
It can't run without Linux, so that makes it a derived work.
That is simply incorrect.
By your statement any userland program that made use of Linux-only interfaces (e.g. hugetlbfs, most anything in/proc or/sys, video4linux devices, etc) would also be a derived work, which is obviously not the case. Even within the realm of kernel-internal interfaces, it is difficult to argue that a derived work is created by using interfaces whose function and calling requirements you understand without needing to know the specifics of the implementation (though this seems to be the thrust of the thinking behind EXPORT_SYMBOL_GPL).
Personally I would argue that nothing short of code-copying creates a derived work, but other intelligent people hold contrary views. I'm waiting for the day that someone wakes up to the fact that the whole EXPORT_SYMBOL* nonsense is at its heart a form of Digital Restrictions Management. Not that closed-source modules haven't caused me rare moments of headache, but in this case the cure seems more repugnant than the ailment.
I agree with your comments for most trackballs -- click-and-drag is a contortionist-level problem. I have to think the people who design these trackballs never actually use them. They should make the engineers use their device for a month before releasing it to manufacturing -- eat your own dogfood if you will.
The only trackball I've used that "got it right" was the Microsoft Trackball Explorer. The trackball is moved with your forefingers, and buttons 1-3 and the scrollwheel are manipulated with your thumb on the left side of the enclosure. The only difficulty I can envision is some odd application that requires you to depress multiple mouse buttons at once. Even then, you may be able to edit your X configuration to map buttons 4 and 5 on the device to be duplicates of 1-3, and thereby enable your pinky as an extra button-pressing digit.
Take a look at the (out of production) Microsoft Trackball Explorer. The trackball movement is sensed optically, just like an optical mouse. Other than dimension and shape of the device, it's pretty much exactly the same set of components as an optical mouse (but with three bearings instead of a few Teflon glide strips).
This is also one of the only two MS products I can bring myself to buy (the other being the Natural Keyboard). In fact, I own two TrackBall Explorers, one of which I use at work and the other at home. I love how the thumb is used for the normal three buttons plus the scrollwheel. I vastly prefer using my fingers instead of my thumb for manipulating the pointer itself, and this fits the bill perfectly. In fact so much so, that I instigated the effort to support this and similar devices under IRIX.:)
Additionally, if you get the fourth and fifth buttons working, they can come in handy in various programs. I used to use them as alternates for the scroll wheel up-and-down movement, but I can think of an application I wrote many years ago that would have benefited greatly from two more pointer buttons.
I do find it to be somewhat tiring to use for image editing (i.e. Gimp), and would like to try a tablet someday. But for my day-to-day "A mouse is simply a device used to select between xterms" usage, it's darn-near perfect.
Now, don't get me wrong -- I'm a big fan of sci-fi in a number of different media, and I've come to have a healthy disgust for Lucas, but he's not the problem.
The predominant problem I see with sci-fi films which aren't space operas is that they are by and large boring. Yes, they have a cerebral point to make, but the plot unwinds itself very slowly, and rely on sweeping visuals of planets/landscapes and ethereal music to try to envelop you. There are very few such films which cause me to care about the characters or events. Case in point: Solaris. These films suffer from poor storytelling and/or pacing, even if the original source material is outstanding.
I've watched 2001: A Space Odyssey multiple times, and enjoy it. However, if you want to lay blame somewhere then point your finger at that film. It was remarkable for its time, both in the visuals and in the use of science fiction to make a point, but it (to my mind) was the film which set up the prototype for all sci-fi films which are not space operas. 2001 endures because it set the standard, but it's imitators quite literally lull me to sleep.
A secondary consideration is the visual style of these types of films. They almost always present space or the future as very sterile visual environments, and my brain gets incredibly bored. 2001. Solaris. THX 1138 (though that did have an interesting story that compensated). Minority Report. Aeon Flux. They all have this problem. The exceptions stand out, and keep my visual cortex engaged. Blade Runner. The Fifth Element. Robocop. Demolition Man (though the cheese factor is hard to ignore). Firefly. V. Dune.
Given the choice, I'll take the "space opera with a message" over the predominant sci-fi alternative any day.
So you'll have to learn an architecture. Intel 386 is a great place to start...
Choke. Cough. Laugh. Thanks a lot, now I have to clean soda off my keyboard.
While the rest of your comment is pretty much spot on, this advice is, frankly, absurd. x86 has one of the most convoluted, non-orthogonal, legacy-laden instruction sets and list of constraints of any architecture, ever. Introducing someone to assembly programming via x86 is sure to warp their brain, and will certainly send the vast majority of people running away, never to revisit the idea. You might as well recommend Malbolge, Intercal, Brainf*ck, or Befunge to them -- it'll result in the same reaction.
If you want to introduce yourself to assembly language programming, start with something sane and simple. To that end, you can't get much simpler than the Motorola 6800 family of processors. Then, step up to something with a richer instruction set, such as the Motorola 68000 family. After having a good grasp of those a person will have correctly oriented their brain to take on more complex but sane architectures, such as MIPS or Alpha. For a challenge after that point, I'd highly recommend IA64 (i.e. Itanium) -- which introduces some really complex ideas, but implements those ideas in a sane and consistent manner. It might be worth learning a DSP processor assembly language (such as the TI TMS320 series) before IA64, to get a handle on concerns regarding explicit parallelism.
Only after learning a number of well-designed instruction sets and architectures such as those should you even consider exposing yourself to x86 and (most likely) the PC architecture. At that point you'll have built up enough intellectual rigor in your approach to assembly programming to survive in the Lovecraftian realm of programming for this architecture. If you're lucky, you'll realize just how truly terrible the instruction set and system architecture are, and avoid programming in x86 assembly whenever possible.
Seriously, I'd even recommend IBM 360 mainframe assembly ahead of x86 for an initial learning experience. Please don't start with x86, it will rot your brain.
Brent
P.S. Yes. I have programmed and/or debugged programs in every assembly language mentioned above. x86 rates dead last.
I saw this episode of the Charlie Rose Show as it was aired. While I did notice the comment that is the subject of this article, there was much more disturbing content in the episode.
Not that Charlie Rose is known as a hard-hitting interviewer, but the soft ball questions he pitched up to Mr. Gates were disappointing, if not somewhat sickening. Mr. Rose let Gates gloss over EU and other anticompetitive issues, the rising pressures open source presents to Microsoft, and much much more.
Frankly I expected a lot more, but in the end the entire episode came off as a Microsoft PR segment.
I've often wondered how much energy could be conserved if municipalities re-examined the overuse of streetlights. It seems that many streetlights are used to illuminate sections of road that don't need such illumination. I can understand the benefits at intersections and crosswalks, however I know of stretches of urban highway between intersections that are fully lit, with no benefit that I can imagine. Automobiles have headlights for a good reason. The occasional vehicle driving along without its headlights on (I know I've done this myself accidentally) is probably ample testimony that there is too much illumination of many urban roadways.
Furthermore, what effect would it have if a municipality required all outdoor lighting to illuminate only the area of interest? That is, mandate that parking lot lights, lights above entrances, along sidewalks, streetlights, and such use reflectors/shields to ensure that only the parking lot/entrance/sidewalk/intersection is illuminated, and nothing else. It seems if this was required they could get by with lower-power lights, and as a beneficial side-effect reduce the light polution in urban areas.
Personally I'd also like to see some measure to reduce business signage illumination, however I doubt that's a realistic hope.
It's hard not to agree wholeheartedly, as I've disliked America's most popular variety, the Red Delicious, for about a decade. Apparently I'm not the only one.
However, I think it is a mistake to dismiss all commercially grown apples due to a problem with a particular variety. A few years ago I had the pleasure of trying the Fireside and Connell Red (the latter apparently a mutation of the former), which I picked from a local commercial orchard. I always knew there were many varieties of apples in the world, but tasting these two opened my eyes to the rich variety to be experienced.
Truth told, all of my favorite video games have been "in the room" multiplayer forms.
As a kid, Contra and Super-Contra -- there's nothing like having played a game for so many hours together that you and your partner know which weapons each prefers, you both know exactly which part of the screen the other will cover while on the jumping levels, and who is the best at fighting each particular boss. You reach a Zen-like period of silence and mayhem, both acting as one.
My freshman year in college yielded two more excellent multiplayer games. The first was Nibbles -- yes, the BASIC program that shipped with DOS at that time. We got tired of it asking "Do you want to play again?", and simply changed the message to "Of course you want to play again!", a small delay, and a restart of the game. We even had Nibbles tournaments in the dorm. The second such game was of course Star Control's melee battle. The intricacies of piloting the individual ships, and taking advantage of the other ship's weaknesses and the other player's weaknesses were fantastic and rich.
Wait, there was a third that year -- Scorched Earth (which doesn't appear to have been mentioned yet). Yes, a 10 player game. The carnage and mayhem made us giddy, and we didn't even mind when we figured out how to cheat the game or came up with frightfully destructive tactics (my favorite: Horizontal Guidance and the Leapfrog bomb).
Doom came and went, as did a few others over the next few years. Then my friends introduced me to the modernized 3D BattleZone played over a network in their office. Wow! Again, this game caused each of us to explore the strengths and weaknesses of the other's tanks, and the strengths and weaknesses of the players themselves. Pure magic.
Finally there was the Soul Calibur series. I agree with the prior post -- newbie button-mashers (which is mostly the category I fall into) can have a tremendous amount of fun, and skilled combo-masters can be fearsome. Couple that with all the methods of handicapping to even out the skill differences between players, and it's more fun than most people should be allowed.
You demonstrate a fundamental lack of undertanding of the business SGI was/is in, and what makes it operate. Distributing toys and clothing to employees and fans, and building the sexiest machines does not, in the long view, cause or ensure business success. Hype and excitement are poor substitutes for strong corporate leadership and industry leading innovation. In SGI's case, it never did have strong corporate leadership, but during its glory days it was so far ahead of the rest of the industry in its particular categories that such a fault could easily be overlooked.
A later poster was more on target -- SGI has failed in large part due to being unwilling to recognize the direction of the future. Graphics leadership was ceded to nVidia and ATI due to not understanding the concept of "good enough" and the future of PCs. Network serving leadership was entirely ceded to Sun. Investment in MIPS computing horsepower was sabotaged by the belief that IA-64 would be on-time and meet early performance expectations. SGI also failed entirely to capitalize on the movement of companies to databases and other such "mundane" enterprise applications, choosing rather to focus on HPC (and yes, this trend was already underway before the purchase of Cray, which merely jumped SGI ahead and accelerated the effect).
So, while trinkets and T-shirts are certainly enjoyable, the real reason that SGI experienced massive outmigration of engineering talent (but not complete -- the people left really are outstanding in the areas of their work) is that SGI failed to move into areas that were obviously ripe for the picking, and which these engineers realized would be terrific directions and interests to pursue. Can you fault a graphics engineer for deciding that nVidia/ATI/Matrox/etc were a better and more exciting fit for their interests? Or a CPU engineer for deciding that spinning clock rates on R10000 was less a use of their talent than working on custom ASICs at some small firm? Those trends, my friend, are much more important to engineering talent than baubles and doodads.
At one point in my undergraduate career I was considering switching from electrical/computer engineering to computer science. A wise professor told me "Career-wise, a EE can almost always take a job which requires a CS background. The other way around rarely works."
Ten or so years later, this advice seems meritous as evidenced by the occupants of the offices and cubes near me.
However, I mostly agree with the prior poster: Do what you enjoy -- there's too many money-hungry know-nothings in the industry as-is. Don't add to the problem by doing something you don't thoroughly enjoy.
For the first time on a product carrying the SGI brand, the new Altix system also can be installed with an optional water-cooled door, which provides system cooling capabilities in addition to the Altix system's existing air-cooled architecture. Already in use at NASA, the water-cooled door option is ideal for environments in which high-density systems are deployed in close proximity to other large-scale equipment.
Anecdotal stories from onsite indicate that the cooling is so good that users/admins want to wear warm clothing if they are in the server room for extended periods.
Want aliens? Got it. Want adventure? Got it.
Want a plot line? Got it. Want big weapons?
Got it. Want multiplayer melee? Got it. Want
source code? Got it.
Head on over to http://sc2.sourceforge.net/
and download.
Slashdot Mirror
Here's a few good ones from my .vimrc file.
First one, for those of you who've been lambasted by maintainers/etc when submitting Linux/whatever patches because your code had extra whitespace at the end of the line. This highlights such whitespace by turning the background color red on those characters:
" Highlight trailing whitespace
highlight WhitespaceEOL ctermbg=red guibg=red
function WhitespaceHighlight(syn) /\s\+$/ contained /\s\+$/
if a:syn =~ 'diff'
" diff syntax should trailing whitespace on non-addition lines
syn match diffAdded "^+.*" contains=WhiteSpaceEOL
syn match WhitespaceEOL display
elseif a:syn =~ '^\v(asm|c|config|cpp|ia64|crontab|fortran|html|man|pascal|perl|postscript|procmail|python|sh|csh|tcsh|zsh|spec|tcl|vim)$'
" bug: Innards of C comments aren't highlighted
syn match WhitespaceEOL display
endif
endfunction
autocmd Syntax * call WhitespaceHighlight(expand(""))
The next one is for those of you who've edited read-only files, only to realize at the end of the editing session that you can't write to it. This set of entries makes read-only buffers non-modifiable (i.e. editing commands don't work), and selects different colorschemes based on whether the current buffer is modifiable or not (a visual trigger -- in my case a black background means not editable, dark blue means I can edit it).
" Color schemes
let rwcolor="darkblue"
let rocolor="elflord"
" Make sure automatic color schemes always know they have dark backgrounds
" ColorScheme event appeared no later than version 7.1. Probably 7.0
if (v:version >= 700)
autocmd ColorScheme * set background=dark
endif
" Change modifiability and color scheme based on read-only status of
" current buffer
function Modifiable()
" Make readonly files non-modifiable, so we don't make a
" bunch of changes only to realize we can't save them
if &readonly
set nomodifiable
else
set modifiable
endif
" Set the colorscheme based on the readonly/modifiable
" status of the file. This gives a visual cue as to
" when modifying is disallowed.
if has("gui_running")
if &modifiable
let g:colors_name=g:rwcolor
else
let g:colors_name=g:rocolor
endif
if (v:version >= 700)
doautocmd ColorScheme
else
" This has the same effect, but is kludgy
" and may miss some of the side-effects.
" It does the job for our purposes.
set background=dark
endif
endif
endfunction
autocmd BufEnter * call Modifiable()
Sounds pretty much like a GM's recollection of a (sloppily run?) role-playing adventure. The internal inconsistencies and fanciful but less than coherently planned characters and plot would be par for the course in many RPG sessions.
Real geeks whistle V.42bis into the handset.
Exactly. Too many people assume that any given programmer can write any given program. What isn't generally realized (at least by the masses) is that programming really is about acquiring expertise in a particular domain and then solving problems in that domain through the use of computer programs. Generally some of the most effective programs I've seen have been written, on their first pass, by a person with intimate domain knowledge, and mediocre programming/computer knowledge. The program then becomes a standout when someone with intense programming and computer architecture knowledge improves the code from there (they need not be a subject domain expert, but it helps).
I do take issue with sexconker assuming that I "just don't get it". Heh. If s/he only knew. Whatever, no biggie. I do agree that distributed algorithms are generally more difficult to implement/design than non-distributed, but that's not exactly the same thing as serial versus parallel algorithms (non-distributed generally involves access to data through a common address space, distributed doesn't, though even those pseudo-definitions come up a bit short).
Again and again I read in industry rags and on various web sites that multi-threaded programming is hard, and nobody knows how to do it, and that it's difficult to debug, and all that. I believe what they're really saying is "The set of programmers who are accustomed to multi-threaded programming/debugging is (relatively) small, and thus applications aren't going to make good use of the shift to multicore CPU packages." Familiarity with a skill, and the supply of labor familiar with said skill, is distinct from it being easy or hard.
Anyway, I stand by my belief that parallel programming is not as difficult as most people are led to believe. Some problems don't lend themselves well to parallel solutions, or don't merit the added complexity, but many many of them do. In ten years time I predict that most computer programming education will assume the use of threading, and that anyone who isn't competent with threading will severely limit their own job prospects.
I'm still not sure where this idea that "multi-threaded programming is hard" comes from. It's not. It seems that most people are just afraid of it because they're not familiar with it.
Or perhaps I just overestimate the mental capacity of most programmers? Having looked at a lot of code, there may be merit to that theory.
And if I was a resident of a mental health institution, I want x86 assembly.
What I don't see mentioned very often, if at all, is the implicit assumption in distributed systems such as git, that a single person has ultimate integration responsibility and authority in order to form the official/mainline release. That is, given a single tree that is considered the main one from which all others ultimately derive (Linus' tree in the Linux case), there is absolutely no way for tools such as git to allow collaborative maintenance of that tree. In the end, the owner of that tree must perform all checkins to the tree, and must resolve all merge conflicts themself. This is a dual problem in that it wastes the time of a potentially talented developer (e.g. Linus) doing the mundane work of merging and integration, and the additional problem that if this mainline tree owner is not an expert in some particular area of the code, they are likely to make mistakes when resolving conflicts or performing other integration tasks.
Contrast this with a centralized source model where all developers have the ability to check in to the tree, optionally coupled with a peer review process, enforced either through convention or through mechanisms in the tools. Under this model each developer is responsible for their own integration and merging efforts, not wasting the time of a centralized authority. Not only is the central authority freed from routine tree maintenance work, but each developer can make the best and wisest decisions regarding the particular area of the codebase in which they are an expert, and not have to become involved in areas they have little experience with. Granted, for larger projects there is still a need for some management of checkin authorization, particularly to avoid conflicts during large tree merge operations and the like, but it's more of a coordination role than an authorization role.
This second model is what my employer uses, and our homegrown source control system is well-tailored to it (it actually has capabilities for more centralized control, but they are by and large unused). Perhaps this is unusual, as my experience with other employers is minimal, and mostly took the form of "copy your code into this directory once in a while" (i.e. "Source control? Why would we need that?"). However, given adequately diligent and intelligent developers, I have to say it works marvelously.
Not quite a classic like the Apple material, but the Motif style guide is likely to be helpful: http://www.opengroup.org/pubs/catalog/t254.htm
:1,$ !lpr
That is simply incorrect.
By your statement any userland program that made use of Linux-only interfaces (e.g. hugetlbfs, most anything in /proc or /sys, video4linux devices, etc) would also be a derived work, which is obviously not the case. Even within the realm of kernel-internal interfaces, it is difficult to argue that a derived work is created by using interfaces whose function and calling requirements you understand without needing to know the specifics of the implementation (though this seems to be the thrust of the thinking behind EXPORT_SYMBOL_GPL).
Personally I would argue that nothing short of code-copying creates a derived work, but other intelligent people hold contrary views. I'm waiting for the day that someone wakes up to the fact that the whole EXPORT_SYMBOL* nonsense is at its heart a form of Digital Restrictions Management. Not that closed-source modules haven't caused me rare moments of headache, but in this case the cure seems more repugnant than the ailment.
I agree with your comments for most trackballs -- click-and-drag is a contortionist-level problem. I have to think the people who design these trackballs never actually use them. They should make the engineers use their device for a month before releasing it to manufacturing -- eat your own dogfood if you will.
The only trackball I've used that "got it right" was the Microsoft Trackball Explorer. The trackball is moved with your forefingers, and buttons 1-3 and the scrollwheel are manipulated with your thumb on the left side of the enclosure. The only difficulty I can envision is some odd application that requires you to depress multiple mouse buttons at once. Even then, you may be able to edit your X configuration to map buttons 4 and 5 on the device to be duplicates of 1-3, and thereby enable your pinky as an extra button-pressing digit.
Simply wrong.
Take a look at the (out of production) Microsoft Trackball Explorer. The trackball movement is sensed optically, just like an optical mouse. Other than dimension and shape of the device, it's pretty much exactly the same set of components as an optical mouse (but with three bearings instead of a few Teflon glide strips).
This is also one of the only two MS products I can bring myself to buy (the other being the Natural Keyboard). In fact, I own two TrackBall Explorers, one of which I use at work and the other at home. I love how the thumb is used for the normal three buttons plus the scrollwheel. I vastly prefer using my fingers instead of my thumb for manipulating the pointer itself, and this fits the bill perfectly. In fact so much so, that I instigated the effort to support this and similar devices under IRIX. :)
Additionally, if you get the fourth and fifth buttons working, they can come in handy in various programs. I used to use them as alternates for the scroll wheel up-and-down movement, but I can think of an application I wrote many years ago that would have benefited greatly from two more pointer buttons.
I do find it to be somewhat tiring to use for image editing (i.e. Gimp), and would like to try a tablet someday. But for my day-to-day "A mouse is simply a device used to select between xterms" usage, it's darn-near perfect.
That's where you insert the Allen wrench to wind up the solar system!
Geez folks. Do you have to be told everything?
Now, don't get me wrong -- I'm a big fan of sci-fi in a number of different media, and I've come to have a healthy disgust for Lucas, but he's not the problem.
The predominant problem I see with sci-fi films which aren't space operas is that they are by and large boring. Yes, they have a cerebral point to make, but the plot unwinds itself very slowly, and rely on sweeping visuals of planets/landscapes and ethereal music to try to envelop you. There are very few such films which cause me to care about the characters or events. Case in point: Solaris. These films suffer from poor storytelling and/or pacing, even if the original source material is outstanding.
I've watched 2001: A Space Odyssey multiple times, and enjoy it. However, if you want to lay blame somewhere then point your finger at that film. It was remarkable for its time, both in the visuals and in the use of science fiction to make a point, but it (to my mind) was the film which set up the prototype for all sci-fi films which are not space operas. 2001 endures because it set the standard, but it's imitators quite literally lull me to sleep.
A secondary consideration is the visual style of these types of films. They almost always present space or the future as very sterile visual environments, and my brain gets incredibly bored. 2001. Solaris. THX 1138 (though that did have an interesting story that compensated). Minority Report. Aeon Flux. They all have this problem. The exceptions stand out, and keep my visual cortex engaged. Blade Runner. The Fifth Element. Robocop. Demolition Man (though the cheese factor is hard to ignore). Firefly. V. Dune.
Given the choice, I'll take the "space opera with a message" over the predominant sci-fi alternative any day.
Brent
So you'll have to learn an architecture. Intel 386 is a great place to start...
Choke. Cough. Laugh. Thanks a lot, now I have to clean soda off my keyboard.
While the rest of your comment is pretty much spot on, this advice is, frankly, absurd. x86 has one of the most convoluted, non-orthogonal, legacy-laden instruction sets and list of constraints of any architecture, ever. Introducing someone to assembly programming via x86 is sure to warp their brain, and will certainly send the vast majority of people running away, never to revisit the idea. You might as well recommend Malbolge, Intercal, Brainf*ck, or Befunge to them -- it'll result in the same reaction.
If you want to introduce yourself to assembly language programming, start with something sane and simple. To that end, you can't get much simpler than the Motorola 6800 family of processors. Then, step up to something with a richer instruction set, such as the Motorola 68000 family. After having a good grasp of those a person will have correctly oriented their brain to take on more complex but sane architectures, such as MIPS or Alpha. For a challenge after that point, I'd highly recommend IA64 (i.e. Itanium) -- which introduces some really complex ideas, but implements those ideas in a sane and consistent manner. It might be worth learning a DSP processor assembly language (such as the TI TMS320 series) before IA64, to get a handle on concerns regarding explicit parallelism.
Only after learning a number of well-designed instruction sets and architectures such as those should you even consider exposing yourself to x86 and (most likely) the PC architecture. At that point you'll have built up enough intellectual rigor in your approach to assembly programming to survive in the Lovecraftian realm of programming for this architecture. If you're lucky, you'll realize just how truly terrible the instruction set and system architecture are, and avoid programming in x86 assembly whenever possible.
Seriously, I'd even recommend IBM 360 mainframe assembly ahead of x86 for an initial learning experience. Please don't start with x86, it will rot your brain.
Brent
P.S. Yes. I have programmed and/or debugged programs in every assembly language mentioned above. x86 rates dead last.
I saw this episode of the Charlie Rose Show as it was aired. While I did notice the comment that is the subject of this article, there was much more disturbing content in the episode.
Not that Charlie Rose is known as a hard-hitting interviewer, but the soft ball questions he pitched up to Mr. Gates were disappointing, if not somewhat sickening. Mr. Rose let Gates gloss over EU and other anticompetitive issues, the rising pressures open source presents to Microsoft, and much much more.
Frankly I expected a lot more, but in the end the entire episode came off as a Microsoft PR segment.
I've often wondered how much energy could be conserved if municipalities re-examined the overuse of streetlights. It seems that many streetlights are used to illuminate sections of road that don't need such illumination. I can understand the benefits at intersections and crosswalks, however I know of stretches of urban highway between intersections that are fully lit, with no benefit that I can imagine. Automobiles have headlights for a good reason. The occasional vehicle driving along without its headlights on (I know I've done this myself accidentally) is probably ample testimony that there is too much illumination of many urban roadways.
Furthermore, what effect would it have if a municipality required all outdoor lighting to illuminate only the area of interest? That is, mandate that parking lot lights, lights above entrances, along sidewalks, streetlights, and such use reflectors/shields to ensure that only the parking lot/entrance/sidewalk/intersection is illuminated, and nothing else. It seems if this was required they could get by with lower-power lights, and as a beneficial side-effect reduce the light polution in urban areas.
Personally I'd also like to see some measure to reduce business signage illumination, however I doubt that's a realistic hope.
It's hard not to agree wholeheartedly, as I've disliked America's most popular variety, the Red Delicious, for about a decade. Apparently I'm not the only one.
However, I think it is a mistake to dismiss all commercially grown apples due to a problem with a particular variety. A few years ago I had the pleasure of trying the Fireside and Connell Red (the latter apparently a mutation of the former), which I picked from a local commercial orchard. I always knew there were many varieties of apples in the world, but tasting these two opened my eyes to the rich variety to be experienced.
Truth told, all of my favorite video games have been "in the room" multiplayer forms.
As a kid, Contra and Super-Contra -- there's nothing like having played a game for so many hours together that you and your partner know which weapons each prefers, you both know exactly which part of the screen the other will cover while on the jumping levels, and who is the best at fighting each particular boss. You reach a Zen-like period of silence and mayhem, both acting as one.
My freshman year in college yielded two more excellent multiplayer games. The first was Nibbles -- yes, the BASIC program that shipped with DOS at that time. We got tired of it asking "Do you want to play again?", and simply changed the message to "Of course you want to play again!", a small delay, and a restart of the game. We even had Nibbles tournaments in the dorm. The second such game was of course Star Control's melee battle. The intricacies of piloting the individual ships, and taking advantage of the other ship's weaknesses and
the other player's weaknesses were fantastic and rich.
Wait, there was a third that year -- Scorched Earth (which doesn't appear to have been mentioned yet). Yes, a 10 player game. The carnage and mayhem made us giddy, and we didn't even mind when we figured out how to cheat the game or came up with frightfully destructive tactics (my favorite: Horizontal Guidance and the Leapfrog bomb).
Doom came and went, as did a few others over the next few years. Then my friends introduced me to the modernized 3D BattleZone played over a network in their office. Wow! Again, this game caused each of us to explore the strengths and weaknesses of the other's tanks, and the strengths and weaknesses of the players themselves. Pure magic.
Finally there was the Soul Calibur series. I agree with the prior post -- newbie button-mashers (which is mostly the category I fall into) can have a tremendous amount of fun, and skilled combo-masters can be fearsome. Couple that with all the methods of handicapping to even out the skill differences between players, and it's more fun than most people should be allowed.
For seven years I've felt a great disturbance in the franchise. As if millions of voices cried out with disgust. Then were suddenly silenced.
You demonstrate a fundamental lack of undertanding of the business SGI was/is in, and what makes it operate. Distributing toys and clothing to employees and fans, and building the sexiest machines does not, in the long view, cause or ensure business success. Hype and excitement are poor substitutes for strong corporate leadership and industry leading innovation. In SGI's case, it never did have strong corporate leadership, but during its glory days it was so far ahead of the rest of the industry in its particular categories that such a fault could easily be overlooked.
A later poster was more on target -- SGI has failed in large part due to being unwilling to recognize the direction of the future. Graphics leadership was ceded to nVidia and ATI due to not understanding the concept of "good enough" and the future of PCs. Network serving leadership was entirely ceded to Sun. Investment in MIPS computing horsepower was sabotaged by the belief that IA-64 would be on-time and meet early performance expectations. SGI also failed entirely to capitalize on the movement of companies to databases and other such "mundane" enterprise applications, choosing rather to focus on HPC (and yes, this trend was already underway before the purchase of Cray, which merely jumped SGI ahead and accelerated the effect).
So, while trinkets and T-shirts are certainly enjoyable, the real reason that SGI experienced massive outmigration of engineering talent (but not complete -- the people left really are outstanding in the areas of their work) is that SGI failed to move into areas that were obviously ripe for the picking, and which these engineers realized would be terrific directions and interests to pursue. Can you fault a graphics engineer for deciding that nVidia/ATI/Matrox/etc were a better and more exciting fit for their interests? Or a CPU engineer for deciding that spinning clock rates on R10000 was less a use of their talent than working on custom ASICs at some small firm? Those trends, my friend, are much more important to engineering talent than baubles and doodads.
At one point in my undergraduate career I was considering switching from electrical/computer engineering to computer science. A wise professor told me "Career-wise, a EE can almost always take a job which requires a CS background. The other way around rarely works."
Ten or so years later, this advice seems meritous as evidenced by the occupants of the offices and cubes near me.
However, I mostly agree with the prior poster: Do what you enjoy -- there's too many money-hungry know-nothings in the industry as-is. Don't add to the problem by doing something you don't thoroughly enjoy.
Anecdotal stories from onsite indicate that the cooling is so good that users/admins want to wear warm clothing if they are in the server room for extended periods.
An open source port of this classic PC game.
Want aliens? Got it. Want adventure? Got it. Want a plot line? Got it. Want big weapons? Got it. Want multiplayer melee? Got it. Want source code? Got it.
Head on over to http://sc2.sourceforge.net/ and download.
Best of all, it also runs on FreeBSD!