A lot of what has been said about IT vs CS is true, but the spectrum of computing is larger than just what those two cover.
Like others have said, the main question is "what do you want to do?", not "what tools do you want to use?". Then choose a degree on point.
IT for sysadmin, etc
CS for computing systems (compilers, RDBMS, schedulers, etc)
Traditional engineering degrees for engineering research or problem solving (like where I work which prefers EEs, AEs, MEs over CSs or ITs).
A math major is probably the best jack-of-all-trades degree for the person who just does not know yet what they want to do.
To abstract a bit, I'd break down the most used basics into the triumvirate of problem-solving, math, and tools. Engineering formally covers problem-solving and pre-reqs the math, and tools are easy (relatively) to pick up. This is why we prefer to hire engineers. In this view, CS is applied math, like engineering, but without the formal problem-solving. However, the CS applied math subset is often more on-point for lots of things computing. Math covers the largest subset of math, and can be very powerful in the long run due to that.
problem-solving math tools engineering primary applied secondary CS secondary applied applied IT secondary secondary primary math secondary primary secondary
My bias is clearly not towards IT since I have engineering, CS, and math degrees, but no IT degree. If I had to choose only one of those degrees to build a career upon it would be the engineering degree...but that suits my taste.
Vinge is generally superb, but Rainbows End (the book with the book shredding) is not his best. It is still good enough to read, but not representative of Vinge.
All the bobbles stuff or the Tines are much better.
I know he has played with the 'singularity' a bunch, but I think there is still more exploration to be had there. Other ways it could go down. I would not mind if he went back to the singularity well one more time.
To take this even further, scripting language lists are almost always non-intrusive. Therefore, most python, ruby, or whatever scripts are also likely in violation.
If you put an object into more than one list in a python script, you've violated.
Linux certainly is in violation, almost in any way one could define 'linux'.
I have a Macbook Pro that had a faulty fan. I did the HW diagnosis myself and
figured it out, then called Apple, and they told me to go to the Genius bar before
sending it in. I did. They diagnosed the same thing after going through their
pre-prescribed routine, and they promptly had it fixed. (They also noted how cool
it was that I had it set up to triple boot...and did not even come close to trying
to blame the fan problem on the triple boot like a discount store dimwit might).
Apple is just like Quiznos or Subway. They figure out a procedure that works 95% of the time
and train their employees to follow it. That is the best way to make your service
repeatable on a national or worldwide scale. My stepson has a Dell E1505, and had a similar
phone experience...a bit drawn out due to procedure, but useful and did address his issue.
This Best Buy program seems to be more about image (uniforms, cars, commercials, etc)
than providing a consistent service. I stopped buying from Best Buy ages ago due to
a completely different swindle of theirs, so this does not surprise me one bit.
The real difference to me between compiled and interpreted is not the
speed. It never really has been. It is the typing. There are areas
where I want static typing, such as large architectures with many
developers touching related code. Compiler type checking can be very
valuable in such cases.
On the other hand in projects with more isolated nodules, lots of shallow
glue, or quick turnaround prototyping, I like the freedom of dynamic
typing.
Note that languages like haskell, Java, and C# really fit into the compiled
camp, not the interpreted camp...and they are all static typed. JIT is
still compiled. True interpreted languages are more like python, perl, lua, and
sh.
I think compiled and interpreted are very complementary, and I personally
like stack of python/C++/lua. Extend python with C++ which in turn embeds
lua. lua is easier and faster than python for script embedding, while python
is easier to extend and has more libraries for the orchestration/glue role.
Have you read the article? Tanenbaum basicly starts out by saying this is not a 'fight', but a technical discussion. Communication and debate is an important part of research and development. That's what is
being attempted here, at least at face by Tanenbaum. There may be antagonism behind the scenes, or bias in presentation, but that is just human. The primary intent is to advance the state of the art, not fight.
All this 'what's the point' or 'we have this now' type of talk really bugs me. Everything can always be improved, or at least that is the attitude I'd like to stick with.
> When did we collectively forget that everything has its place
Another key component of research and development is to question everything. Not throw everything away and always start over, but to at least question it. Just because monolithic kernels rule the desktop now does does prove that monolithic kernels are inherently the best desktop solution.
In effect it is sometimes good to not even recognize a notion of 'everything has its place'.
Just to add another testamonial on this, I have a triple boot (OS X, gentoo, XP) Macbook Pro (w/ Radeon x1600) and an old dual boot P3/933 + Radeon 8500 desktop.
I play rfactor a lot (a 3D intensive racing simulation game), and thought I'd really be making use of the x1600 in the Macbook. However, as it turns out, the old box with the 8500 is just as fun with its weaker graphics, so I still game mostly on the old box and develop (C++ 3D code) mostly on my linux partition of the Macbook. The compile times on the core duo (parallel of course) completely obliterate the P3/933 compile times.
So a 4-5 year old video card is still good enough for at least some modern 3D games...enough so that even with
a better option available the simple inconvienience of a reboot into XP and hooking up a controller outweighs the
gain an x1600 has over an 8500.
Physics processing needs a standard interface, and precise specs on what the output should be. If there is only going to be one vendor, and one proprietary interface, this market will fail.
I could not agree more. Competitive multiplayer games in particular would depend on this, and even more specificly, simulation centric games. The biggest case being racing simulation games where differences in 0.01s in laptimes are significant.
So what this requires is something as specified as IEEE floating point, but for a physics enabling coprocessor. Honestly, I think this really just means a generalized vector matrix coprocessor specification. Higher level physics simulation tradeoffs are just too varied (time integration scheme, collision detection and response, etc) for a 'physics' coprocessor. Just give us packed sparse matrix formats with vector matrix multiplies, vector SIMD stuff, etc, all
conforming to IEEE floating point.
So much of the heavy lifting of physics processing boils down to solving linear systems, and much of that
often boils down to sparse or dense matrix vector multiplies.
With that kind of configuration, we will be going back to the 1990s. It is not worth 150 bucks. If you pay 200 dollars more, you could get a emachines desktop computer with the latest technology.
Stupid reply. The whole point of the cheap entry computer is because of low incomes. I could just pay 20k more than 15k and get a BMW instead of a Hundai, but maybe I don't have that extra 20k.
I can't believe someone serious asserts something based on "you could just pay 133% more..."
>> So for now its Word and Photoshop on my computer, Safari or Firefox for web surfing and OS X Mail or webbased interfaces for e-mails. For the time being I don't see any other way around it.
> Question is, why do you want to get "around" it? Is it really an obstacle?
Bingo. Best comment I've read so far.
That is why google probably has no real immediate interest is a 'WebOS'. Even TFA asserts it is
really about data. I'd guess seamless data hosting is where someone could really make a killing.
Basicly a personal networked fs/db that automaticly gets mounted/connected on all personal
devices. A filesystem (vs. database) approach would probably be best due to legacy app support.
So as an example, for a Windows user, they would download and install 'gDrive', and drive G: (this is a
pre vista example) shows up on their 'My Computer'. This drive acts just like any other drive, although
slower, but is identical and the same on every device they install gDrive onto. The data on that drive
is guarunteed to be backed up, secure, etc, etc.
A linux user would probably just install a kernel module and mount the gDrive.
Many of us cobble something like this together for ourselves and host it ourselves, but for the general public
I can see deferring the setup, admin, data integrity (backups), etc to google at the expense of
not having the magnetic bits in their own house (which could burn down anyway) would be very attractive.
The privacy concerns can be mitigated with encryption, much like DIBS. The data goes over the wire
and sits on google's drives encrypted. The only major problem I see is how does google (or whoever)
derive value from this themselves? I would not be surprised if they have a solid business model
wrapped around this already, but I don't know what it is.
Umm, Alienware does not make their own. They 'theme' ODM laptops, typically Clevos.
Actually, Dell contracts Dell-specific designs from their ODMs. Alienware simply uses commonly available ODM models, that you can get cheaper as a Sager (also repackages Clevos) or even directly as a Clevo.
Voodoo does the same as Alienware but uses ASUS and others.
I'd never seen that before, but I have evolved to basicly the same thing, w/o the clip (so just step
1). My pocket binds them just fine without the clip. Otherwise they sit on my desk; usually spread
out; like a bunch of windows on top of my desk. I also prefer a 0.5mm pencil instead of that pen.
Ultra high resolution
Screen space infinitely expandable
Wonderfully tactile interaction methods
Infinite battery life
Immune to EMP
Most replies to your question tend to be of the "because we can" variety.
However, there are real practical reasons. First, the development environment on Linux
is different ranging from the UI (I like a very custom fvwm + vim setup) to software architecture
issues (linking dynamic libraries, particularly with visibility nuances, differs
between the two...or three throwing in win32).
Second, many of us can only afford so much hardware AND we work on cross-platform
packages (C++ plugin framework in my case). In addition to this, living in a location such
as the Bay area or SoCal with a family severely limits computer space. Triple booting
a laptop for development is very attractive.
Third, OSX is a better casual end-user (like for my wife) desktop than Windows, gnome, kde,
fvwm, etc. Windows has the games I need (like rfactor), and some applications (like
the MyChron telemetry software for my kart racing). Linux supports my favored development
environment best. Again, we have a HW budget limit.
In summary, one broken assumption you have is that one home computer supports one end-user
(a MAC supports a MAC person). The other related assumption is that one home computer supports
predominately one usage pattern.
And to naysayers for implicit typing, it is used all the time under different looks in real heavyweight production code (C++ templates ala STL style, the multitude of runtime aggregate type systems out there, very late bound dispatching, etc, etc). Note that in some cases (like STL), the 'is_suchandsuch' is not necessary, since C++ templates are a compile-time thing so you get compile time type checking and binding.
If long term efficiency (productivity) is the thing to be compared, then I'd assert more than just Gnome or KDE should be on the table. After all, they both represent implementations of very similar metaphors and workflows.
I'd like to see alternatives such as a ultra-lean-configuration fvwm/twm class desktop (representing thinner organizational and interactive metaphors upon a shell-centric workflow), an ion desktop (completely different desktop metaphor), Mac OS X's desktop, and maybe just a straight linux console (for comparison purposes as I do not think a single shell w/o access to graphical apps would be competitive).
Personally, I've refined over the years an fvwm configuration w/o borders, w/o icons, w/o title bars, lots of keybindings...efficient for high shell and vim counts...but difficult for one handed (like with the other hand holding a phone or food) usage. Basicly, ion made sense to me in a lot of ways, but is difficult with apps and application workflows that assume 'normal' windowing, so I went pretty far down the minimalist road with fvwm. (Note that FvwmProxy is indespensible for such a desktop, and I'd say it is superior to Apple's expose in usefulness)
There are 11 types of people in the world: those who can count in binary, and those who can't.
So you'd be in the 10th group? Or did you forget to tell us about the 11th group, which would logically be the empty set given the definition of the first 10 sets?:)
Re:4 way battle now. 360 v PS3 v Revolution v Mini
on
Mac mini, Apple DVR?
·
· Score: 1
Oops, the 'good enough on PAL/NTSC' was meant for casual, not hardcore, gamers. I did not write that clear enough.
4 way battle now. 360 v PS3 v Revolution v Mini
on
Mac mini, Apple DVR?
·
· Score: 1
I'd favor the Mini in the long haul. Hardware is not a single locked spec, but important APIs are (roughly). The HD is not 'optional'. The dev environment is no additional charge (XCode), so a true indy game/app ecosystem can thrive.
Sure, the 'consoles' will initially be superior in graphics muscle, but that will wane. By 2009 the Settop Minis will eclipse the locked-hw-spec aging consoles in power. The underfunded hardcore gamers can justify a 360 or PS3, but not many others. Well funded hardcore gamers are already on PCs, and will remain there. Even the Radeon 9200 of the current Mini can deliver for them just fine at PAL/NTSC resolutions. By the time casuals are moving wholesale to HD, the Minis will have GPUs to match.
And as a state-of-games data point: Civ 4 will be out on OSX before the PS3 is even out.
The real killer is, duh, the iPod. Look around at the gym or mall...those are almost all iPods around people's waists and necks. Teen comes home. Plops down in front of TV with bag of chips. Opens MTV, iTunes, and an IM client (and the bag of chips). Nirvana.
Keys to settop mini success vs. the consoles:
Price Point -- comparable to 360 and PS3
Wireless Keyboard with integrated mouse (to support that teen workflow).
iPod dock (not so much for practicality as for advertising 'hey look, this is what this new mini is for')
Just another stimuli to induce transient overwork
on
Microsoft Lauds Scrum
·
· Score: 1
First, software development, engineering, applied math, is basicly organized problem solving. The core primitive is the technical analysis and design (software implementation is just fine grained design). Any wrapper (organization/management) around these primitives is theoretically just glue to get the primitives to mesh and go in the 'right' direction. Necessary glue, but just glue.
Development processes do not amplify the inherent problem solving capabilities of your workforce. They can
just minimize organizational and communication overhead. You need training and education to raise the inherent problem solving capacity...or hire more smart people. The work environment itself can raise effiency some by reducing burnout and increasing motivation. This includes free lunch (google, dreamworks, etc), frequent (rare is just insulting) company sponsored activities (camping, skiing, etc), and good benefits.
All of these processes, from old-school top-down waterfall, to spiral, to peer-oriented agile/XP, to bottom-up bazaar, impose overhead to the core problem-solving in order to achieve higher level objectives.
Different processes are more efficient for particular types of objectives and different workforce cultures. Some scale better than others. Some are more nimble than others. However, a 'new' approach is rarely any better than its almost certainly pre-existing relatives.
A 'new' approach often does carry one short term advantage though. It can create a temporary excitement that can result in extracting more productive problem-solving hours out of employees (like the cited Scrum-month, or a game company's 'crunch' with late night pizza, etc, etc). This wears thin and eventually reduces to just more hours without increased problem solving. New processes can't make people better problem solvers. Bad ones just suppress and oppress them.
But gravity is predicted to be quantum in nature as well
String theory predicts the massless spin-2 'graviton', not quantum theory.
Quantum theory predicts nothing about gravity. Gravity is not included in quantum theory.
Relativity handles that for us now. Quantum scientists 'predict' the graviton, more by
similarity/analogy with existing theory than by any mathematical consequence.
This is a big upside to string theory...that gravity is postdicted by it and therefore that relativity
and quantum are unified by it.
However, 'strings' are themselves 'quanta' within the theory, so you could say that gravity
is predicted to be quantum in nature...but by string theory...it is just slightly misleading in this (slashdot)
context where most readers will equate the term 'quantum' with quantum theory.
However, I have to agree that Linux has not yet provided a decent development environment.... IDE vs. shells.. etc
I have worked in several places where both Win32 and POSIX had to be supported by middleware we were developing. This means that we all had both VS IDE (on win32 boxen) and X11+shell toolchains (on unix boxen). We had to use both, but most developers could settle into a particular environment of their choice for daily work and verify their work on all platforms about once per week. This also means most people were fluent in both workflows and tools.
About 3/4 of us settled into X11 desktops+shells+X11 editors (vim, xemacs, nedit, etc)+gdb/ddd. The funny observation was that the VS IDE guys were so impressive to watch over their shoulder...them seemed so productive, doing 'stuff' so fast. But then you realize a lot of the slickness is to smooth over the less efficient model of working in the first place.
A note on X11 desktops...most people eventually dropped the pretty iconish desktops (gnome, kde) for
streamlined customized setups well suited to very high editor and shell counts (ion, fvwm+clever windowlist
setup, custom ctwm, etc). In effect, the desktop became a big chunk of an IDE.
Having said that, even the hardcore unix guys went to the MS debugger itself from time to time. That particular tool _IS_ superior to anything gdb based, but that tool alone is not enough to push most of us into the MS IDE development workflow. Most bugs in quality code seems to fall easily to fprintf and a stack dump just as fast as to any interactive debugger. The really bad memory ones need purify, valgrind, etc. The really
bad concurrency ones (race conditions, etc) fall back to fprintf style debugging. So the MS debugger sweet spot is not really as big
in practice as one might think.
Very simple...
My teenage daughter paid her own money for an iPod and can use it easily. She walked into the Mac store (Glendale Galleria), played with one for three minutes, and could use it. No problem. She bought it.
She now wants a Mac Mini.
She tried to use a PDA, with guidance, and still lost interest almost immediately. She said it was like trying to use a PC with ten foot chopsticks.
Apple == Ease of use. Zero learning curve to start. Like a toaster.
Note that this does not exclude a learning curve and more sophistication _after_ entry. Entry must be immediate and rewarding.
Slashdot Mirror
A lot of what has been said about IT vs CS is true, but the spectrum of computing
is larger than just what those two cover.
Like others have said, the main question is "what do you want to do?", not "what tools
do you want to use?". Then choose a degree on point.
IT for sysadmin, etc
CS for computing systems (compilers, RDBMS, schedulers, etc)
Traditional engineering degrees for engineering research or problem solving (like where
I work which prefers EEs, AEs, MEs over CSs or ITs).
A math major is probably the best jack-of-all-trades degree for the person who just
does not know yet what they want to do.
To abstract a bit, I'd break down the most used basics into the triumvirate of
problem-solving, math, and tools. Engineering formally covers problem-solving and
pre-reqs the math, and tools are easy (relatively) to pick up. This is why we prefer
to hire engineers. In this view, CS is applied math, like engineering, but without
the formal problem-solving. However, the CS applied math subset is often more on-point
for lots of things computing. Math covers the largest subset of math, and can be very
powerful in the long run due to that.
problem-solving math tools
engineering primary applied secondary
CS secondary applied applied
IT secondary secondary primary
math secondary primary secondary
My bias is clearly not towards IT since I have engineering, CS, and math degrees, but no
IT degree. If I had to choose only one of those degrees to build a career upon
it would be the engineering degree...but that suits my taste.
Vinge is generally superb, but Rainbows End (the book with the book shredding)
is not his best. It is still good enough to read, but not representative of
Vinge.
All the bobbles stuff or the Tines are much better.
I know he has played with the 'singularity' a bunch, but I think there is
still more exploration to be had there. Other ways it could go down. I
would not mind if he went back to the singularity well one more time.
I care when I'm looking for a job. In a Windows dominant world the Windows dominated jobs dominate the market.
I enjoy my work better in a Linux environment. In a balanced world I would have more opportunities that I'd like.
This is why the desktop matters.
BTW, I'm appreciative in that I do have a Linux dominated job, and I hope I keep it for a while.
> whats next.. ubercapacitors? ubersuperultracapacitors?
Flux Capacitors
To take this even further, scripting language lists
are almost always non-intrusive. Therefore, most
python, ruby, or whatever scripts are also likely in
violation.
If you put an object into more than one list in a
python script, you've violated.
Linux certainly is in violation, almost in any way one
could define 'linux'.
This patent is beyond absurd.
I have a Macbook Pro that had a faulty fan. I did the HW diagnosis myself and figured it out, then called Apple, and they told me to go to the Genius bar before sending it in. I did. They diagnosed the same thing after going through their pre-prescribed routine, and they promptly had it fixed. (They also noted how cool it was that I had it set up to triple boot...and did not even come close to trying to blame the fan problem on the triple boot like a discount store dimwit might).
Apple is just like Quiznos or Subway. They figure out a procedure that works 95% of the time and train their employees to follow it. That is the best way to make your service repeatable on a national or worldwide scale. My stepson has a Dell E1505, and had a similar phone experience...a bit drawn out due to procedure, but useful and did address his issue.
This Best Buy program seems to be more about image (uniforms, cars, commercials, etc) than providing a consistent service. I stopped buying from Best Buy ages ago due to a completely different swindle of theirs, so this does not surprise me one bit.
> ... Microsoft already has compatibility improvements planned through Windows Vista Service Pack 1.
Reminds me of tribbles. Born pregnant.
The real difference to me between compiled and interpreted is not the speed. It never really has been. It is the typing. There are areas where I want static typing, such as large architectures with many developers touching related code. Compiler type checking can be very valuable in such cases.
On the other hand in projects with more isolated nodules, lots of shallow glue, or quick turnaround prototyping, I like the freedom of dynamic typing.
Note that languages like haskell, Java, and C# really fit into the compiled camp, not the interpreted camp...and they are all static typed. JIT is still compiled. True interpreted languages are more like python, perl, lua, and sh.
I think compiled and interpreted are very complementary, and I personally like stack of python/C++/lua. Extend python with C++ which in turn embeds lua. lua is easier and faster than python for script embedding, while python is easier to extend and has more libraries for the orchestration/glue role.
> Why can't we just all get along?
Have you read the article? Tanenbaum basicly starts out by saying this is not a 'fight', but a technical discussion. Communication and debate is an important part of research and development. That's what is being attempted here, at least at face by Tanenbaum. There may be antagonism behind the scenes, or bias in presentation, but that is just human. The primary intent is to advance the state of the art, not fight.
All this 'what's the point' or 'we have this now' type of talk really bugs me. Everything can always be improved, or at least that is the attitude I'd like to stick with.
> When did we collectively forget that everything has its place
Another key component of research and development is to question everything. Not throw everything away and always start over, but to at least question it. Just because monolithic kernels rule the desktop now does does prove that monolithic kernels are inherently the best desktop solution.
In effect it is sometimes good to not even recognize a notion of 'everything has its place'.
Just to add another testamonial on this, I have a triple boot (OS X, gentoo, XP) Macbook Pro (w/ Radeon x1600) and an old dual boot P3/933 + Radeon 8500 desktop.
I play rfactor a lot (a 3D intensive racing simulation game), and thought I'd really be making use of the x1600 in the Macbook. However, as it turns out, the old box with the 8500 is just as fun with its weaker graphics, so I still game mostly on the old box and develop (C++ 3D code) mostly on my linux partition of the Macbook. The compile times on the core duo (parallel of course) completely obliterate the P3/933 compile times.
So a 4-5 year old video card is still good enough for at least some modern 3D games...enough so that even with a better option available the simple inconvienience of a reboot into XP and hooking up a controller outweighs the gain an x1600 has over an 8500.
Physics processing needs a standard interface, and precise specs on what the output should be. If there is only going to be one vendor, and one proprietary interface, this market will fail.
I could not agree more. Competitive multiplayer games in particular would depend on this, and even more specificly, simulation centric games. The biggest case being racing simulation games where differences in 0.01s in laptimes are significant.
So what this requires is something as specified as IEEE floating point, but for a physics enabling coprocessor. Honestly, I think this really just means a generalized vector matrix coprocessor specification. Higher level physics simulation tradeoffs are just too varied (time integration scheme, collision detection and response, etc) for a 'physics' coprocessor. Just give us packed sparse matrix formats with vector matrix multiplies, vector SIMD stuff, etc, all conforming to IEEE floating point.
So much of the heavy lifting of physics processing boils down to solving linear systems, and much of that often boils down to sparse or dense matrix vector multiplies.
With that kind of configuration, we will be going back to the 1990s. It is not worth 150 bucks. If you pay 200 dollars more, you could get a emachines desktop computer with the latest technology.
Stupid reply. The whole point of the cheap entry computer is because of low incomes. I could just pay 20k more than 15k and get a BMW instead of a Hundai, but maybe I don't have that extra 20k.
I can't believe someone serious asserts something based on "you could just pay 133% more..."
>> So for now its Word and Photoshop on my computer, Safari or Firefox for web surfing and OS X Mail or webbased interfaces for e-mails. For the time being I don't see any other way around it.
> Question is, why do you want to get "around" it? Is it really an obstacle?
Bingo. Best comment I've read so far.
That is why google probably has no real immediate interest is a 'WebOS'. Even TFA asserts it is really about data. I'd guess seamless data hosting is where someone could really make a killing. Basicly a personal networked fs/db that automaticly gets mounted/connected on all personal devices. A filesystem (vs. database) approach would probably be best due to legacy app support.
So as an example, for a Windows user, they would download and install 'gDrive', and drive G: (this is a pre vista example) shows up on their 'My Computer'. This drive acts just like any other drive, although slower, but is identical and the same on every device they install gDrive onto. The data on that drive is guarunteed to be backed up, secure, etc, etc.
A linux user would probably just install a kernel module and mount the gDrive.
Many of us cobble something like this together for ourselves and host it ourselves, but for the general public I can see deferring the setup, admin, data integrity (backups), etc to google at the expense of not having the magnetic bits in their own house (which could burn down anyway) would be very attractive. The privacy concerns can be mitigated with encryption, much like DIBS. The data goes over the wire and sits on google's drives encrypted. The only major problem I see is how does google (or whoever) derive value from this themselves? I would not be surprised if they have a solid business model wrapped around this already, but I don't know what it is.
Umm, Alienware does not make their own. They 'theme' ODM laptops, typically Clevos.
Actually, Dell contracts Dell-specific designs from their ODMs. Alienware simply uses commonly available ODM models, that you can get cheaper as a Sager (also repackages Clevos) or even directly as a Clevo.
Voodoo does the same as Alienware but uses ASUS and others.
I'd never seen that before, but I have evolved to basicly the same thing, w/o the clip (so just step 1). My pocket binds them just fine without the clip. Otherwise they sit on my desk; usually spread out; like a bunch of windows on top of my desk. I also prefer a 0.5mm pencil instead of that pen.
Ultra high resolution
Screen space infinitely expandable
Wonderfully tactile interaction methods
Infinite battery life
Immune to EMP
Most replies to your question tend to be of the "because we can" variety.
However, there are real practical reasons. First, the development environment on Linux is different ranging from the UI (I like a very custom fvwm + vim setup) to software architecture issues (linking dynamic libraries, particularly with visibility nuances, differs between the two...or three throwing in win32).
Second, many of us can only afford so much hardware AND we work on cross-platform packages (C++ plugin framework in my case). In addition to this, living in a location such as the Bay area or SoCal with a family severely limits computer space. Triple booting a laptop for development is very attractive.
Third, OSX is a better casual end-user (like for my wife) desktop than Windows, gnome, kde, fvwm, etc. Windows has the games I need (like rfactor), and some applications (like the MyChron telemetry software for my kart racing). Linux supports my favored development environment best. Again, we have a HW budget limit.
In summary, one broken assumption you have is that one home computer supports one end-user (a MAC supports a MAC person). The other related assumption is that one home computer supports predominately one usage pattern.
And to naysayers for implicit typing, it is used all the time under different looks in real heavyweight production code (C++ templates ala STL style, the multitude of runtime aggregate type systems out there, very late bound dispatching, etc, etc). Note that in some cases (like STL), the 'is_suchandsuch' is not necessary, since C++ templates are a compile-time thing so you get compile time type checking and binding.
If long term efficiency (productivity) is the thing to be compared, then I'd assert more than just Gnome or KDE should be on the table. After all, they both represent implementations of very similar metaphors and workflows.
I'd like to see alternatives such as a ultra-lean-configuration fvwm/twm class desktop (representing thinner organizational and interactive metaphors upon a shell-centric workflow), an ion desktop (completely different desktop metaphor), Mac OS X's desktop, and maybe just a straight linux console (for comparison purposes as I do not think a single shell w/o access to graphical apps would be competitive).
Personally, I've refined over the years an fvwm configuration w/o borders, w/o icons, w/o title bars, lots of keybindings...efficient for high shell and vim counts...but difficult for one handed (like with the other hand holding a phone or food) usage. Basicly, ion made sense to me in a lot of ways, but is difficult with apps and application workflows that assume 'normal' windowing, so I went pretty far down the minimalist road with fvwm. (Note that FvwmProxy is indespensible for such a desktop, and I'd say it is superior to Apple's expose in usefulness)
There are 11 types of people in the world: those who can count in binary, and those who can't.
:)
So you'd be in the 10th group? Or did you forget to tell us about the 11th group, which would logically be the empty set given the definition of the first 10 sets?
Oops, the 'good enough on PAL/NTSC' was meant for casual, not hardcore, gamers. I did not write that clear enough.
I'd favor the Mini in the long haul. Hardware is not a single locked spec, but important APIs are (roughly). The HD is not 'optional'. The dev environment is no additional charge (XCode), so a true indy game/app ecosystem can thrive.
Sure, the 'consoles' will initially be superior in graphics muscle, but that will wane. By 2009 the Settop Minis will eclipse the locked-hw-spec aging consoles in power. The underfunded hardcore gamers can justify a 360 or PS3, but not many others. Well funded hardcore gamers are already on PCs, and will remain there. Even the Radeon 9200 of the current Mini can deliver for them just fine at PAL/NTSC resolutions. By the time casuals are moving wholesale to HD, the Minis will have GPUs to match.
And as a state-of-games data point: Civ 4 will be out on OSX before the PS3 is even out.
The real killer is, duh, the iPod. Look around at the gym or mall...those are almost all iPods around people's waists and necks. Teen comes home. Plops down in front of TV with bag of chips. Opens MTV, iTunes, and an IM client (and the bag of chips). Nirvana.
Keys to settop mini success vs. the consoles:
Price Point -- comparable to 360 and PS3
Wireless Keyboard with integrated mouse (to support that teen workflow).
iPod dock (not so much for practicality as for advertising 'hey look, this is what this new mini is for')
First, software development, engineering, applied math, is basicly organized problem solving. The core primitive is the technical analysis and design (software implementation is just fine grained design). Any wrapper (organization/management) around these primitives is theoretically just glue to get the primitives to mesh and go in the 'right' direction. Necessary glue, but just glue.
Development processes do not amplify the inherent problem solving capabilities of your workforce. They can just minimize organizational and communication overhead. You need training and education to raise the inherent problem solving capacity...or hire more smart people. The work environment itself can raise effiency some by reducing burnout and increasing motivation. This includes free lunch (google, dreamworks, etc), frequent (rare is just insulting) company sponsored activities (camping, skiing, etc), and good benefits.
All of these processes, from old-school top-down waterfall, to spiral, to peer-oriented agile/XP, to bottom-up bazaar, impose overhead to the core problem-solving in order to achieve higher level objectives. Different processes are more efficient for particular types of objectives and different workforce cultures. Some scale better than others. Some are more nimble than others. However, a 'new' approach is rarely any better than its almost certainly pre-existing relatives.
A 'new' approach often does carry one short term advantage though. It can create a temporary excitement that can result in extracting more productive problem-solving hours out of employees (like the cited Scrum-month, or a game company's 'crunch' with late night pizza, etc, etc). This wears thin and eventually reduces to just more hours without increased problem solving. New processes can't make people better problem solvers. Bad ones just suppress and oppress them.
But gravity is predicted to be quantum in nature as well
String theory predicts the massless spin-2 'graviton', not quantum theory. Quantum theory predicts nothing about gravity. Gravity is not included in quantum theory. Relativity handles that for us now. Quantum scientists 'predict' the graviton, more by similarity/analogy with existing theory than by any mathematical consequence.
This is a big upside to string theory...that gravity is postdicted by it and therefore that relativity and quantum are unified by it.
However, 'strings' are themselves 'quanta' within the theory, so you could say that gravity is predicted to be quantum in nature...but by string theory...it is just slightly misleading in this (slashdot) context where most readers will equate the term 'quantum' with quantum theory.
However, I have to agree that Linux has not yet provided a decent development environment. ... IDE vs. shells .. etc
I have worked in several places where both Win32 and POSIX had to be supported by middleware we were developing. This means that we all had both VS IDE (on win32 boxen) and X11+shell toolchains (on unix boxen). We had to use both, but most developers could settle into a particular environment of their choice for daily work and verify their work on all platforms about once per week. This also means most people were fluent in both workflows and tools.
About 3/4 of us settled into X11 desktops+shells+X11 editors (vim, xemacs, nedit, etc)+gdb/ddd. The funny observation was that the VS IDE guys were so impressive to watch over their shoulder...them seemed so productive, doing 'stuff' so fast. But then you realize a lot of the slickness is to smooth over the less efficient model of working in the first place.
A note on X11 desktops...most people eventually dropped the pretty iconish desktops (gnome, kde) for streamlined customized setups well suited to very high editor and shell counts (ion, fvwm+clever windowlist setup, custom ctwm, etc). In effect, the desktop became a big chunk of an IDE.
Having said that, even the hardcore unix guys went to the MS debugger itself from time to time. That particular tool _IS_ superior to anything gdb based, but that tool alone is not enough to push most of us into the MS IDE development workflow. Most bugs in quality code seems to fall easily to fprintf and a stack dump just as fast as to any interactive debugger. The really bad memory ones need purify, valgrind, etc. The really bad concurrency ones (race conditions, etc) fall back to fprintf style debugging. So the MS debugger sweet spot is not really as big in practice as one might think.
Very simple... My teenage daughter paid her own money for an iPod and can use it easily. She walked into the Mac store (Glendale Galleria), played with one for three minutes, and could use it. No problem. She bought it. She now wants a Mac Mini.
She tried to use a PDA, with guidance, and still lost interest almost immediately. She said it was like trying to use a PC with ten foot chopsticks.
Apple == Ease of use. Zero learning curve to start. Like a toaster.
Note that this does not exclude a learning curve and more sophistication _after_ entry. Entry must be immediate and rewarding.