Hyperthreading helps you avoid the cost of context switches when multithreading,
I had impression that it's not about context switches. In case of Sparc T2, they actually try to execute several threads in parallel. If one thread stalls on memory access or IO, CPU picks some other thread to execute.
I can't say overall, but for well optimized C/C++ programs this is a disaster. My employer did benchmarks on Sparc T2. With HT enabled system couldn't deliver stable latencies: performance figures were shattered all over the graphs. With HT disabled it performed just like on other Sparcs, albeit bit slower compared to earlier benchmarks on higher-end pre-HT systems. But as I understood Sparc T2 systems are also priced lower.
but a) the cost of context switches is remarkably lower these days due to register renaming and other tricks
It is remarkably lower. But still it is quite easy to bog down performance of whole system with single MT application which uses lots of synchronization.
Yet to see a system with high core count where people didn't have to resort to CPU affinity/processor sets/etc to get full performance out of it.
and b) only on Unix do you care anyway; traditionally we spawn lots of processes on Unix and lots of threads on Windows. It's not necessarily the right way to do things, and the Windows thread-heavy model is paying off now that multicore processors have brought multiprocessing to the masses.
Debatable. I have seen how single threaded I/O heavy *nix application easily beat its Windows analogue which used high thread count. Also multi-threading overhead of *nix (except for Solaris probably) seems to be consistently lower than it is of Windows - what is important to CPU bound tasks. One still has to do much more of tinkering under Windows than under *nix to accomplish the same.
And as experienced Windows developers commented, during sizing one should never forget to leave at least half CPU/core for Windows itself. Better whole CPU_0. Because sometimes it starts doing something, doesn't tell you what it does - but ruins system performance completely.
Sword-fighting is always going to be unrealistic in a game because there is no resistance in the "target". How can you be parried? It doesn't matter how good the controller is, it's just not going to be a realistic experience.
Force feedback might actually compensate for that. At least to make up the feel of sword's weight and shock of parried strike.
And yet It wouldn't be too realistic. And it doesn't have to be. It has to allow player to submerse into game's world better. And frankly everything they might come up with would be better than "classical" controller.
This innovative product could revolutionise gaming. Congratulations Microsoft, you've done it again!
LOL. Seeing how much of acceptance WiiMote is getting in industry, I'd say that MS with much more radical approach would have even more problems. Though to give them the ill deserved credit, unlike Nintendo, MS has lots of experience forcing something onto markets.
Look out "core" gamers, I bet you never seen that coming!
(goes back to playing with Eyetoy)
You'll pry my mouse+wasd from my cold dead finger!
I'd prefer a language which restricted my thinking in beneficial ways to one which left me entirely my own devices.
"Restricted [...] thinking"? So instead of doing more with the same tool, you want to do less?? and buy more other tools to do the rest???
Honestly, I see "restricted thinkng" applicable only to developer who are not mature yet or are refusing on improving themselves. Just like guilds of past v. industry of today. In past there were skillful craftsmen - now we have some random folks off the street who simply punch a button for the 8 hours with lunch break.
I hope that llama-isation of software development would happen after my retirement....
I recall seeing a study that showed that bugs per line of code(*) was fairly constant across languages. (Anyone know what study that was?) Thus the fewer lines of code(*) in your program the fewer bugs. Thus more expressive languages are better.
I do not remember the source of the study, but you got it wrong anyway.
The result of study was that amount of bugs per [effective] line of code depends solely on programmer. Different languages have different code density, yet programmer makes literally same amount of bugs regardless of language.
I have seen apparently perfect one-line Perl programs - which had 3+ bugs in them. If the same person wrote it say in Java, then it would have been say 25 lines of code, but very highly likely number of bugs remained the same.
If they want to make any impression on M$Office advanced users, they have to also offer inter-application scripting. e.g. script to convert special text document to spreadsheet. or script to convert spreadsheet lines into appointments.
The forte of M$Office is seamless - from scripting point of view - integration between the applications.
Assembling your environment by accreting bits of configuration is a highway to Problemville. You probably just needed to add a local-set-key sexp for the appropriate major or minor mode hook to override TAB. Knowing which key map is current is the trick.
And in VIM it takes less than a minute. Without any tricks. And is well described in its near-perfect documentation.
Yet, imagine me of ~15 years ago: fresh Linux user who had to pick an editor for a life. I spent two weeks in Emacs and two weeks in VIM. Most problems in VIM I have solved by end of the first week and second week I could already work. With Emacs, by the end of the second week, I was simply frustrated that even its developers have problems grasping all the details. I attempted similar reevaluation of Emacs few years later when I was more versed in the ways of *nix. Time after time I need something feature-laden like Emacs and my new colleague had worked in Emacs 20+ years, what gave me short lived hope that I will finally manage to tame Emacs. But it ended with much the same results as before. And answers I got were also the same as before: "oh. dunno. just copy my.emacs.el. it should be OK."
KDE 4 added a lot of eye candy. They are slow on old hardware because they have lots of UI polish activated by default. Try to set some simpler theme, for example.
P.S. The error message looks to me more like an error find a shortcut to the application. Try starting "kword" from Katapult or terminal.
I'm not going to install Java (and most OO.o extensions are in Java) just to have some fancy bit of extra functionality.
Neither KOffice nor FireFox require me to install 250MB of Java bloat (in addition to one already packaged with OO.o) to simply access the functionality.
It's also the first time I've seen someone accusing Emacs of not being extensible...
Then code to make Emacs in cc-mode upon press of the Tab to insert a Tab in studio.
I have searched for that little crap for two weeks - before giving up. Even exchanged e-mails with cc-mode authors. Nobody f***ing knows how to do anything in Emacs. Because everybody lost track of the things in Emacs very very long time ago.
So, yeah, as a matter of fact I state that Emacs is not extensible.
I see no real difference betweeen Emacs and vi users these days...
VI users know precisely what every key press does. And know how to change that to achieve different effect if desired. Emacs users - do not. They just hope that Emacs by default does something sensible. And most of the time it does. Not always. But most of the time. Not always what user actually wants or needs - but since one can't change that anyway, they learn to love it. It's not that they have a choice. Isn't it?
I'm in 100% control over my VIM and what it does to files I edit. I can also change every however tiny aspect of VIM's behavior at any given time. With Emacs you can never ever achieve that.
Feel the difference.
CMake is a huge thing to accommodate huge projects.
Cons is a small thing which also can huge projects. But probably doesn't have all the bells and whistles. (CMake IIRC also has facilities a-la autoconf.)
This two are out of different leagues.
Needless to mention, it is rather pointless to have Windows v. UNIX portability, as Windows tends to break trivial things on way too many levels, often requiring in the end source code modifications. (And that is actual experience of my colleagues who tried once to port (unsuccessfully) their Qt4.x project to Linux.) IOW, build system is least of concerns.
... we haven't "vi v. Emacs" flames for a while...
If you lift the lid on what Emacs can do (as in, you grok Emacs lisp), then Emacs offers a level of flexibility that can't be matched by vi.
Very true. And every VIM and Emacs user knows that well.
Emacs is more extensible.
The problem is that Emacs is *too* extensible.
I once tried to find a way to override Tab in one of its modes (during my last Emacs trial). After two day when I reached 7th level of Tab hook overload I stopped abruptly and swore to never ever try to learn Emacs again.
It is *too* extensible.
And it is already out-of-box extended too much, up to the point where 99% of its users do not understand how Emacs actually works. During my trial I have tried also to locate whoever does understand that, only to find out that most Internet populace (and all of my Emacs user friends) have absolutely no idea on how to configure anything in Emacs. Instead, everybody simply copy-paste parts of.emacs.el files they find on Internet.
I went VIM way for a simple reason: I can learn it on my own, gradually and deeply. Learning Emacs in a timely fashion proved to be nearly impossible (unless of course one has lots of spare time to reverse engineers the decades of CL hacks which went into it already).
That's why I earlier drew the parallel between Emacs and IDE. The actual difference isn't that big, as Emacs offers more functions than some commercial IDEs. Many IDEs are black boxes due to proprietary nature. Emacs is a black box due to steep learning curve one encounters when s/he tries to "lift the lid". And I know that for a fact: I have tried twice (2 times 2 weeks; before I finally settled on the VIM) to do it.
Yes. But try once to explain the difference to normal folks the declarative nature of Makefiles.
We had a case when some developers proclaimed a war on "=" and replaced it with ":=" in all their Makefiles. Since, you know, everybody understands better how ":=" works. You can imagine the disaster which followed during preparations of next release. Worst part was that I had to explain the difference between "=" and ":=" to the brainless developer who understand very little of how make works at all.
So demanding that someone knows UNIX and bash, is not an impossible requirement if you develop on UNIX. That is, we assume if you develop on UNIX that you know how to use UNIX.
So, I don't really understand the objection.
Objection withdrawn. This is common sense.
I generally am not that demanding and rarely have the choice of people with whom I work. I try to put everyone into position where they can do their best. Even in UNIX programming, there are lots of task which do not involve shell. Though, yes, being able to learn scripting is a great advantage.
As I put it: if people are not able to create their own working environment, then I simply write one for them.
Though, frankly, people who have decade(s) of UNIX programming experience struggling to write working 5-line shell script is still freaking me out. And I meet a lot of such folks - especially coming from commercial UNIX variants.
P.S. BTW, note how that correlate with old UNIX truth: real programmers do not write programs, they write programs which write programs for them.
Few people can - and want - to go into details of how tool-chain really works. I too prefer to view some things as black box with few buttons. By virtue of being system developer, I often have too look into the details of how tool chain really works. And I like to dissect it til understand it completely. But I am rather an exception than a norm.
I know many good developer who know about e.g. make only how to invoke it - "make all". Not more. Rest they do in e.g. Emacs. For Windows (or GUI development in general) it is very hard (if possible at all) to keep a track of all the details tool-chain does for you. And many people prefer to ignore the details - to concentrate on job at hand instead.
[ After all, the concentration is a limited resource: more things people have to keep in their heads constantly, less concentration they can direct to any one of them. ]
The holywar "Emacs v. vi" from its inception revolved around precisely the nature of developer. Some developers like to know the details. Some developers prefer to ignore them and just press a button to achieve desired result. On side of "vi", one has to deal with more information. On side of "Emacs" one has to accept that some workflows would be impossible, since there might be no ready button for it. Side of "vi" is flexibility. Side of "Emacs" is conservatism. Different people - different views of a system - different approach to development. And for a good team one needs a healthy mix of both, because looking at system from two different view points allows the team to cover wider range of solutions.
I thought people preferring GNU make did so due purely due to availability or having all their experience with that - but if I read you right, you say you actually have deep experience with both and still prefer the GNU variant?
I used BSD make ~10 years ago and only very shortly. So I can't really opine on it.
GNU make is often pain, but with careful planning it's getting the job done. But from my experience I would admit that GNU make has enormous capacity to confuse and freak out people. Lazy evaluation isn't for everybody. I probably should be considered GNU make profi, as I have read through its documentation numerous times already. That further precludes me from commenting on BSD make.
I personally prefer (and use for all my pet projects) GNU cons. It's simple and perl based. (N.B. There is also SCons which is Python based. At times slower than cons, but has more features and more portable.) Cons is pretty much only known to me solution to retain sanity on large projects: built-in dep checker, built-in installation support, proper dependency handling for static libraries, built-in object caching, support for commands having multiple products, etc. But the main goal of cons (and what I love it for most) is to guarantee consistent builds: unlike make(s), cons uses MD5 to check whether the source have changed. (Though can be reconfigured to use timestamps). Takes time to get used to, but is really worth it.
Frankly, I would put/bin/bash as first on the list.
My toolchain (ranked by degree of my dependency on the tool) is: bash, vim, exuberant ctags, GNU make, GNU diff, GNU grep, GNU find, GCC, man, git, perl, gdb, objdump.
The chain covers about 95% of projects I do. (To GNU moniker: I'm no GNU nazi, but just to highlight the fact that - flame me all you want - I find the BSD variants of the tools mostly useless in everyday use.)
VIM is powerful indeed. But one should never forget that sizable chunk of its utilities depend on good shell and system file/text tools. Otherwise you probably want to pick Emacs instead.
P.S. For Qt/KDE development one also has to include qmake and FireFox (on-line documentation browser).
If you really believed that piracy was no worse with sneakernet than it is now, you'd be too stupid to have learned to type.
Flamebait aside, you apparently have no clue what you are talking about.
**AAs consider giving your friend a CD/DVD/etc to be also a theft. And in the time of sneakernet, that was all over the place. Decade ago, probably half of my CD collection was constantly in other hands. And **AAs consistently consider that to be a "theft" too. Internet changed only one thing: most of my CD collection now is buried below thick layer of dust as MP3/OGG/AAC are exchanged by all possible means. (And I'd say external hard drives play not so little role in friend-to-friend (sneakernet's analogue of P2P) content exchange even now.)
Internet or sneakernet, human nature hasn't changed by a bit: if we enjoy something, we want to share that with others. And copyright laws cannot change that.
Believe me, both Mac OS and Linux have the history of stupid workarounds. Though as the OSs evolve much faster than Windows, none of such workarounds ever had reached such epic proportions. Windows is pretty much unique in the way MS sticks to all the mistakes they ever made.
P.S. With Vista they decided though to break completely backward compatibility - and replace old broken interfaces with new incompatible but equally broken interfaces. Otherwise God only knows how many people in R&D and IT would have lost their jobs, supported solely by vast number of Windows bogosities.
OMG. This problem is old... I do not know how old it. It was so many years ago.
With some NICs under Win9x one had to do some hand waving to make it working. And two reboots. (Good NICs with good OEM drivers (e.g. Intel) had no the problem - setup.exe did it all for you. But e.g. RealTek was shipping only drivers, without any fancy installation program.) I already forgot what to do precisely, but yes, it was caused by Win9x not installing something during setup since network wasn't present (but some dummy stuff was installed instead). The installation of missing pieces could be triggered artificially later - with minimum two reboots - but how and what were the step I already forgot. Haven't seen Win9x for 10+ years now....
I still remember though the impression of people when I did extra redundant reboot and Win9x network was magically coming to life. (*)
(*) Not always, as Win9x's DHCP/WINS was atrocious and sometimes also causing the effect as if network was down.
Go ahead and create a multi-TB database (on one server) with a few tables that are >100GB each. Do some performance benchmarking after scaling as best you can with each DB System and let me know how that works out for you.
Thanks for the great example!!! Now I know how 99.999% of DBs out there are!!!!!!
At home, I had removed all traces of Java like eons ago. Never had a problem. Only OO.o occasionally complains that there is no Java installed, but no crucial functionality is affected.
In office, one of the corporate portals uses ActiveX and Java. Though Java applet is used apparently only during authentication, it still requires Java. (IOW, puny 20K applet wastes countless megabytes/gigabytes of disk space on hundred desktops.) Otherwise - no Java in sight.
Slashdot Mirror
Hyperthreading helps you avoid the cost of context switches when multithreading,
I had impression that it's not about context switches. In case of Sparc T2, they actually try to execute several threads in parallel. If one thread stalls on memory access or IO, CPU picks some other thread to execute.
I can't say overall, but for well optimized C/C++ programs this is a disaster. My employer did benchmarks on Sparc T2. With HT enabled system couldn't deliver stable latencies: performance figures were shattered all over the graphs. With HT disabled it performed just like on other Sparcs, albeit bit slower compared to earlier benchmarks on higher-end pre-HT systems. But as I understood Sparc T2 systems are also priced lower.
but a) the cost of context switches is remarkably lower these days due to register renaming and other tricks
It is remarkably lower. But still it is quite easy to bog down performance of whole system with single MT application which uses lots of synchronization.
Yet to see a system with high core count where people didn't have to resort to CPU affinity/processor sets/etc to get full performance out of it.
and b) only on Unix do you care anyway; traditionally we spawn lots of processes on Unix and lots of threads on Windows. It's not necessarily the right way to do things, and the Windows thread-heavy model is paying off now that multicore processors have brought multiprocessing to the masses.
Debatable. I have seen how single threaded I/O heavy *nix application easily beat its Windows analogue which used high thread count. Also multi-threading overhead of *nix (except for Solaris probably) seems to be consistently lower than it is of Windows - what is important to CPU bound tasks. One still has to do much more of tinkering under Windows than under *nix to accomplish the same.
And as experienced Windows developers commented, during sizing one should never forget to leave at least half CPU/core for Windows itself. Better whole CPU_0. Because sometimes it starts doing something, doesn't tell you what it does - but ruins system performance completely.
Sword-fighting is always going to be unrealistic in a game because there is no resistance in the "target". How can you be parried? It doesn't matter how good the controller is, it's just not going to be a realistic experience.
Force feedback might actually compensate for that. At least to make up the feel of sword's weight and shock of parried strike.
And yet It wouldn't be too realistic. And it doesn't have to be. It has to allow player to submerse into game's world better. And frankly everything they might come up with would be better than "classical" controller.
This innovative product could revolutionise gaming. Congratulations Microsoft, you've done it again!
LOL. Seeing how much of acceptance WiiMote is getting in industry, I'd say that MS with much more radical approach would have even more problems. Though to give them the ill deserved credit, unlike Nintendo, MS has lots of experience forcing something onto markets.
Look out "core" gamers, I bet you never seen that coming!
(goes back to playing with Eyetoy)
You'll pry my mouse+wasd from my cold dead finger!
Code barfed out by people that are not talented programmers.
You haven't seen what such people do with more "limiting" languages....
Crappiness of code doesn't depend on language - it depends on who wrote it.
I'd prefer a language which restricted my thinking in beneficial ways to one which left me entirely my own devices.
"Restricted [...] thinking"? So instead of doing more with the same tool, you want to do less?? and buy more other tools to do the rest???
Honestly, I see "restricted thinkng" applicable only to developer who are not mature yet or are refusing on improving themselves. Just like guilds of past v. industry of today. In past there were skillful craftsmen - now we have some random folks off the street who simply punch a button for the 8 hours with lunch break.
I hope that llama-isation of software development would happen after my retirement....
I recall seeing a study that showed that bugs per line of code(*) was fairly constant across languages. (Anyone know what study that was?) Thus the fewer lines of code(*) in your program the fewer bugs. Thus more expressive languages are better.
I do not remember the source of the study, but you got it wrong anyway.
The result of study was that amount of bugs per [effective] line of code depends solely on programmer. Different languages have different code density, yet programmer makes literally same amount of bugs regardless of language.
I have seen apparently perfect one-line Perl programs - which had 3+ bugs in them. If the same person wrote it say in Java, then it would have been say 25 lines of code, but very highly likely number of bugs remained the same.
No language will have APIs for all you might want to do in order for you to use only one line of code !
It seems you never seen C++'s STL.
I envy you already.
If they want to make any impression on M$Office advanced users, they have to also offer inter-application scripting. e.g. script to convert special text document to spreadsheet. or script to convert spreadsheet lines into appointments.
The forte of M$Office is seamless - from scripting point of view - integration between the applications.
Assembling your environment by accreting bits of configuration is a highway to Problemville. You probably just needed to add a local-set-key sexp for the appropriate major or minor mode hook to override TAB. Knowing which key map is current is the trick.
And in VIM it takes less than a minute. Without any tricks. And is well described in its near-perfect documentation.
Yet, imagine me of ~15 years ago: fresh Linux user who had to pick an editor for a life. I spent two weeks in Emacs and two weeks in VIM. Most problems in VIM I have solved by end of the first week and second week I could already work. With Emacs, by the end of the second week, I was simply frustrated that even its developers have problems grasping all the details. I attempted similar reevaluation of Emacs few years later when I was more versed in the ways of *nix. Time after time I need something feature-laden like Emacs and my new colleague had worked in Emacs 20+ years, what gave me short lived hope that I will finally manage to tame Emacs. But it ended with much the same results as before. And answers I got were also the same as before: "oh. dunno. just copy my .emacs.el. it should be OK."
KDE 4 added a lot of eye candy. They are slow on old hardware because they have lots of UI polish activated by default. Try to set some simpler theme, for example.
P.S. The error message looks to me more like an error find a shortcut to the application. Try starting "kword" from Katapult or terminal.
I'm not going to install Java (and most OO.o extensions are in Java) just to have some fancy bit of extra functionality.
Neither KOffice nor FireFox require me to install 250MB of Java bloat (in addition to one already packaged with OO.o) to simply access the functionality.
It's also the first time I've seen someone accusing Emacs of not being extensible ...
Then code to make Emacs in cc-mode upon press of the Tab to insert a Tab in studio.
I have searched for that little crap for two weeks - before giving up. Even exchanged e-mails with cc-mode authors. Nobody f***ing knows how to do anything in Emacs. Because everybody lost track of the things in Emacs very very long time ago.
So, yeah, as a matter of fact I state that Emacs is not extensible.
I see no real difference betweeen Emacs and vi users these days ...
VI users know precisely what every key press does. And know how to change that to achieve different effect if desired. Emacs users - do not. They just hope that Emacs by default does something sensible. And most of the time it does. Not always. But most of the time. Not always what user actually wants or needs - but since one can't change that anyway, they learn to love it. It's not that they have a choice. Isn't it?
I'm in 100% control over my VIM and what it does to files I edit. I can also change every however tiny aspect of VIM's behavior at any given time. With Emacs you can never ever achieve that.
Feel the difference.
CMake is a huge thing to accommodate huge projects.
Cons is a small thing which also can huge projects. But probably doesn't have all the bells and whistles. (CMake IIRC also has facilities a-la autoconf.)
This two are out of different leagues.
Needless to mention, it is rather pointless to have Windows v. UNIX portability, as Windows tends to break trivial things on way too many levels, often requiring in the end source code modifications. (And that is actual experience of my colleagues who tried once to port (unsuccessfully) their Qt4.x project to Linux.) IOW, build system is least of concerns.
If you lift the lid on what Emacs can do (as in, you grok Emacs lisp), then Emacs offers a level of flexibility that can't be matched by vi.
Very true. And every VIM and Emacs user knows that well.
Emacs is more extensible.
The problem is that Emacs is *too* extensible.
I once tried to find a way to override Tab in one of its modes (during my last Emacs trial). After two day when I reached 7th level of Tab hook overload I stopped abruptly and swore to never ever try to learn Emacs again.
It is *too* extensible.
And it is already out-of-box extended too much, up to the point where 99% of its users do not understand how Emacs actually works. During my trial I have tried also to locate whoever does understand that, only to find out that most Internet populace (and all of my Emacs user friends) have absolutely no idea on how to configure anything in Emacs. Instead, everybody simply copy-paste parts of .emacs.el files they find on Internet.
I went VIM way for a simple reason: I can learn it on my own, gradually and deeply. Learning Emacs in a timely fashion proved to be nearly impossible (unless of course one has lots of spare time to reverse engineers the decades of CL hacks which went into it already).
That's why I earlier drew the parallel between Emacs and IDE. The actual difference isn't that big, as Emacs offers more functions than some commercial IDEs. Many IDEs are black boxes due to proprietary nature. Emacs is a black box due to steep learning curve one encounters when s/he tries to "lift the lid". And I know that for a fact: I have tried twice (2 times 2 weeks; before I finally settled on the VIM) to do it.
Yes. But try once to explain the difference to normal folks the declarative nature of Makefiles.
We had a case when some developers proclaimed a war on "=" and replaced it with ":=" in all their Makefiles. Since, you know, everybody understands better how ":=" works. You can imagine the disaster which followed during preparations of next release. Worst part was that I had to explain the difference between "=" and ":=" to the brainless developer who understand very little of how make works at all.
So demanding that someone knows UNIX and bash, is not an impossible requirement if you develop on UNIX. That is, we assume if you develop on UNIX that you know how to use UNIX.
So, I don't really understand the objection.
Objection withdrawn. This is common sense.
I generally am not that demanding and rarely have the choice of people with whom I work. I try to put everyone into position where they can do their best. Even in UNIX programming, there are lots of task which do not involve shell. Though, yes, being able to learn scripting is a great advantage.
As I put it: if people are not able to create their own working environment, then I simply write one for them.
Though, frankly, people who have decade(s) of UNIX programming experience struggling to write working 5-line shell script is still freaking me out. And I meet a lot of such folks - especially coming from commercial UNIX variants.
P.S. BTW, note how that correlate with old UNIX truth: real programmers do not write programs, they write programs which write programs for them.
This is plain discrimination.
Few people can - and want - to go into details of how tool-chain really works. I too prefer to view some things as black box with few buttons. By virtue of being system developer, I often have too look into the details of how tool chain really works. And I like to dissect it til understand it completely. But I am rather an exception than a norm.
I know many good developer who know about e.g. make only how to invoke it - "make all". Not more. Rest they do in e.g. Emacs. For Windows (or GUI development in general) it is very hard (if possible at all) to keep a track of all the details tool-chain does for you. And many people prefer to ignore the details - to concentrate on job at hand instead.
[ After all, the concentration is a limited resource: more things people have to keep in their heads constantly, less concentration they can direct to any one of them. ]
The holywar "Emacs v. vi" from its inception revolved around precisely the nature of developer. Some developers like to know the details. Some developers prefer to ignore them and just press a button to achieve desired result. On side of "vi", one has to deal with more information. On side of "Emacs" one has to accept that some workflows would be impossible, since there might be no ready button for it. Side of "vi" is flexibility. Side of "Emacs" is conservatism. Different people - different views of a system - different approach to development. And for a good team one needs a healthy mix of both, because looking at system from two different view points allows the team to cover wider range of solutions.
I thought people preferring GNU make did so due purely due to availability or having all their experience with that - but if I read you right, you say you actually have deep experience with both and still prefer the GNU variant?
I used BSD make ~10 years ago and only very shortly. So I can't really opine on it.
GNU make is often pain, but with careful planning it's getting the job done. But from my experience I would admit that GNU make has enormous capacity to confuse and freak out people. Lazy evaluation isn't for everybody. I probably should be considered GNU make profi, as I have read through its documentation numerous times already. That further precludes me from commenting on BSD make.
I personally prefer (and use for all my pet projects) GNU cons. It's simple and perl based. (N.B. There is also SCons which is Python based. At times slower than cons, but has more features and more portable.) Cons is pretty much only known to me solution to retain sanity on large projects: built-in dep checker, built-in installation support, proper dependency handling for static libraries, built-in object caching, support for commands having multiple products, etc. But the main goal of cons (and what I love it for most) is to guarantee consistent builds: unlike make(s), cons uses MD5 to check whether the source have changed. (Though can be reconfigured to use timestamps). Takes time to get used to, but is really worth it.
Frankly, I would put /bin/bash as first on the list.
My toolchain (ranked by degree of my dependency on the tool) is: bash, vim, exuberant ctags, GNU make, GNU diff, GNU grep, GNU find, GCC, man, git, perl, gdb, objdump.
The chain covers about 95% of projects I do. (To GNU moniker: I'm no GNU nazi, but just to highlight the fact that - flame me all you want - I find the BSD variants of the tools mostly useless in everyday use.)
VIM is powerful indeed. But one should never forget that sizable chunk of its utilities depend on good shell and system file/text tools. Otherwise you probably want to pick Emacs instead.
P.S. For Qt/KDE development one also has to include qmake and FireFox (on-line documentation browser).
If you really believed that piracy was no worse with sneakernet than it is now, you'd be too stupid to have learned to type.
Flamebait aside, you apparently have no clue what you are talking about.
**AAs consider giving your friend a CD/DVD/etc to be also a theft. And in the time of sneakernet, that was all over the place. Decade ago, probably half of my CD collection was constantly in other hands. And **AAs consistently consider that to be a "theft" too. Internet changed only one thing: most of my CD collection now is buried below thick layer of dust as MP3/OGG/AAC are exchanged by all possible means. (And I'd say external hard drives play not so little role in friend-to-friend (sneakernet's analogue of P2P) content exchange even now.)
Internet or sneakernet, human nature hasn't changed by a bit: if we enjoy something, we want to share that with others. And copyright laws cannot change that.
Believe me, both Mac OS and Linux have the history of stupid workarounds. Though as the OSs evolve much faster than Windows, none of such workarounds ever had reached such epic proportions. Windows is pretty much unique in the way MS sticks to all the mistakes they ever made.
P.S. With Vista they decided though to break completely backward compatibility - and replace old broken interfaces with new incompatible but equally broken interfaces. Otherwise God only knows how many people in R&D and IT would have lost their jobs, supported solely by vast number of Windows bogosities.
OMG. This problem is old ... I do not know how old it. It was so many years ago.
With some NICs under Win9x one had to do some hand waving to make it working. And two reboots. (Good NICs with good OEM drivers (e.g. Intel) had no the problem - setup.exe did it all for you. But e.g. RealTek was shipping only drivers, without any fancy installation program.) I already forgot what to do precisely, but yes, it was caused by Win9x not installing something during setup since network wasn't present (but some dummy stuff was installed instead). The installation of missing pieces could be triggered artificially later - with minimum two reboots - but how and what were the step I already forgot. Haven't seen Win9x for 10+ years now....
I still remember though the impression of people when I did extra redundant reboot and Win9x network was magically coming to life. (*) (*) Not always, as Win9x's DHCP/WINS was atrocious and sometimes also causing the effect as if network was down.
Go ahead and create a multi-TB database (on one server) with a few tables that are >100GB each. Do some performance benchmarking after scaling as best you can with each DB System and let me know how that works out for you.
Thanks for the great example!!! Now I know how 99.999% of DBs out there are!!!!!!
Very similar here.
At home, I had removed all traces of Java like eons ago. Never had a problem. Only OO.o occasionally complains that there is no Java installed, but no crucial functionality is affected.
In office, one of the corporate portals uses ActiveX and Java. Though Java applet is used apparently only during authentication, it still requires Java. (IOW, puny 20K applet wastes countless megabytes/gigabytes of disk space on hundred desktops.) Otherwise - no Java in sight.
Looks like a good ToDo list for any distro which desires to be a Linux Desktop champion.