Re:If the review is accurate, the book is revision
on
In Search of Stupidity
·
· Score: 1
> When asked about the possibility of preloading OS/2, he laughed and said something like, ``yeah, right, I'm going to preload the software of a direct competitor on my machines.''
I think that is a good point. It is usually assumed that having two businesses in one company leads to synergy. Reason given are that you can bundle solutions, you can focus your brand etc etc.
However, being in several fields of business can also be a problem. IBM doing hardware and software is an example: you would assume that selling hardware would give them an edge selling software for it, but it did not. Instead, IBM sold its hardware with Windows (for which ever reasons), and IBM compatibles where sold with Windows, because they were competing with IBM and thus with OS/2. Sony is another example: the media division makes them cripple the consumer devices, and in the end they all go down...
I am sure Microsoft was often tempted to produce hardware, but they were smart enough to stay from any actual computer components. They only produce peripherals (and nice ones), which do not threaten their software business.
>> To be completely thorough, a developer should set up both white- and blacklists in order to cover all bases. > I can't help but feel that most developers have at least a little common sense and do something along those lines anyway.
I hope that most developers have the common sense to take the correct approach: avoid injection problems by proper quoting! There is no need to validate the data, you just have to make sure that it stays data when you parse it on. Just use the proper library functions, and you will be fine (especially if you use hex encoding:-)).
White lists are a good idea if you don't trust you quoting, or if you need to verify the input for another reason. Black lists are most certainly not a good idea. Just imagine that the web shop tries to sell a product called "Selecta[tm]", but you block all attempts to buy it because it matches your black word "SELECT":-(
P.S.: Anybody with an apostrophe in their name naturally develops an unsatisfiable urge to kill web programmers.
> So, the redundancy of end tags in XML is there because, in practice, if you didn't have it, we had learned that our users had problems correcting their documents, and we knew that, in general, it was only rarely possible for software to give the users much help. There were some experiments early on with , allowed by SGML (with various options set) to end any element; it soon became obvious that this caused more problems than it was worth, and even Microsoft disabled the troublesome feature in their XML parser.
Given my experience with users that have inadequate support in their editor for structured documents, having the redundancy actually does not help. Sure, you get an error message instead of accidentally specifying something you did not wont, but the error message does not help people all that much. So they still stare at the XML and don't get what is wrong.
Allowing comments within an element (for each attribute) would have been a huge contribution to legibility. Of course that depends on how you use it, but I think attributes get a lot of use exactly because they have less redundancy.
My conclusion is that in the end, you need structured tools for structured data. And so the format does not actually have to be easy to read. (And believe me, even the best of XML documents are not easy to read if the structure is reasonably complicated.)
> The next typical objection is, "What if they ask for classes and books and a reduced workload so that they have time to learn this? That's unacceptable! Can't they just learn it from a couple of articles on the web with no productivity impact?" If that's what you're feeling, then the biggest barrier to adopting good practices at your company isn't your engineers, it's you.
Been there, done that. And I can conclude that it is not only true, but also reality.
Reducing the number of bugs is not going to be free. It is not going to be easy. If you expect it to be, you are doomed from the start.
> I mean, who labels things "best practice" anyway?
"Best practice" is a ridiculous phrase. It does indeed sound of Mount Sinai, but all it means that this is the best way of doing business. Once you translate it, a lot of the bullshit is not nearly as scary any more.
"We should really follow best practice." -> "We should really do things the best way possible." (kind of a tautology, so everybody nods, but nothing is actually said.)
"Our best practices are..." -> "Our best way of doing business is..." (How do you know? What you really mean is that you hope... is the best way of doing business, and you hope everybody is doing it.)
"Best practices would require..., but we can't do that." -> "The best way we can do this is..., but we can't do that." (This is an obvious contradiction in terms, but still everybody is expected to nod.)
> Unfortunately, it's often the job of senior technical folks to force change upon the less experienced and ignorant, because they honestly have no idea what's good for them.
While it is certainly true that there are more and less experienced developers, you are not exactly helping the "buy in" by calling someone "ignorant". If fact, it is a near sure sign that you would design procedure which seem to make sense, but which actually do not work for the people that have to use them.
So if you want to have working procedures, you need to ask the people affected by them first. Everything else is a vain waste of time.
> What ways have you used to convince your developers and engineers to adopt > a new set of practices that may or may not get in the way of their daily work habits?
You have to get them involved in creating and writing the practices. You said yourself that they are smart folkes, so ask them what they would like to have improved. This is not always easy, and it is certainly difficult to reach a consensus between a lot of smart folkes, but it is absolutely essential.
If you just want to know the best way to prescribe your favorite coding styling, and your are afraid that it may get into the way of the engineers' daily work, then forget it.
I did not start from the States, but I did get jobs in different European countries. So I have the experience of applying "somewhere else", but given my right to stay and working within the EU, I did not have VISA/work permit issues. Even so it can be a difficult process.
1. Finding the job should be no problem. Got to www.monster., and you will find thousands of jobs. Unless you are very specialised, there should be something for you.
2. Taking the first hurdle. IT recruitment is usually outsourced or at least concentrated in HR. So your application will be scored, and you do take a hit for not "being there", and another for not being available immediately. Following up by phone really helps, but watch the time zones!
3. Phone interview. Again you have to watch the time zones, but it should not be a problem. I hope you speak the correct language!:-)
4. Getting the interview. Obviously the interview is going to be costly if you are not "there". Usually European employers pay reasonable travel expenses, but I doubt this will include a transatlantic flight. In any way you have another disadvantage at this point, because the interview is expensive and difficult to arrange.
5. Moving. Finding a house and moving your stuff can be expensive, but that depends on your circumstances. Employers usually pay a contribution, and the rest is tax deductible (not bad at tax rates around 40%).
So 2. and 4. are difficult. And there is the work permit issue. You can nearly always get a work permit, if the company "sponsors" you. However, most companies try to avoid the paper work necessary. Getting a work permit based on skills (without a sponsor) is possible, but often expensive, and only valid in one European country.
And don't forget that unemployment is around 10%, so there is plenty of competition. Having a distinguishing (relevant) skill certainly helps a lot.
I hope this does not sound too negative. If you are determined to move, it is certainly possible. And you are rewarded with completely unamerican advantages such as state healthcare, an average of 30 private holidays per year, and usually shorter work hours. Plus you can visit all the European countries in a reasonably short time!
> On one hand, Mozilla doesn't want binaries being redistributed that they didn't build themselves. On the other hand, Debian wants to be able to handle source patches of their entire source tree. The result is that you get two competing ideals, both seemingly valid, creating this bit of a mess.
I disagree. If Mozilla doesn't want modified binaries being redistributed, it is not open software any more. The code base itself might be open, but Firefox (the branded binary) is most certainly closed software now. So while they give a good reason for this, it is not actually a valid requirement.
> After stepping back for a moment, however, I realized that the problem isn't as complex as it seems. In fact, I think it highlights something I've been saying for a while: Package systems under Linux are a broken concept.
Again I disagree. (Some) package systems under Linux work wonderfully well: you get everything from one source, and you can install 6000 packages without a single unexpected conflict. This might seem impossible, but with good policies it is actually quite doable. What makes Debian or Ubuntu or SuSE so powerful are exactly the policies that make everything work together.
Try the same under Windows: you install all your applications, and suddenly something stops working. Even if you find out which two packages interfere, you will just get two companies pointing fingers at each other:-)
> What we're seeing here is a legal extension of that same problem. By integrating the software into the codebase, Debian is attempting to take legal responsibility for the software.
There is no legal responsibility for open software. You get what you pay.
> Mozilla should be outside of that repository, but any software that's not in the repository is not well supported by the packaging system.
Wrong again. With apt-get, it is no problem at all to load third party repositories. So you could have Mozilla Firefox in the Mozilla repository, and Iceweasel in the Debian repository. You would even have a choice. However, Mozilla decided not to release a Debian package of Firefox, which makes installing the official Firefox on Debian a PITA.
> In this case, Debian wants this software to be managed like all the other software they manage.
Which seems reasonable to me. Firefox developers might think that it is the most important piece of software in recent history, but from a packaging point of view it *is* just another piece of software.
> Another benefit is that your electric car becomes more environmentally friendly every time someone puts up a new wind farm.
From a marketing perspective, wind farms are the best thing since sliced bread. You can sell the environmental friendliness many times over: to the investor giving the money, to the area where you put it up, to the customer getting the electricity, to the electric car using the electricity. Everybody involved even a tiny bit will claim that they are responsible for less polution or a cleaner environment.
> As much as people keep saying it, this is totally false... Common Lisp does not even have lists as an intrinsic type.
Funny how LISP stands for LISt Processing. And this thread is about data structures, not data types. The cons cell might be the central data type in LISP, but the nested list is the central data structure.
Just think about it. '(a b c) will be recognised as a 3 element list by any LISP programmer, and not as 2 cons cells plus 3 atoms (which would be equally correct). Now you can also construct binary trees with cons cells, but that is more complicated and therefore a bit rare.
> There have been times when red-black trees are too expensive, because they have 2 pointers per node and I can't afford the memory overhead. It's amazing how much memory gets wasted when you add an 8 byte pointer to a 0x10 byte structure that can have over 2^35 instances.
Too expensive is relative. You can optimise most of the overhead away, but you still have to store 0x10 byte per structure. Investing a lot of work just to reduce the memory usage by 30% is *usually* not worth it, although there are certainly exceptions.
And this is exactly what the Trie is for. It can offer some marginal advantages in general performance over B-trees, and it can offer more significant advantages in a few obscure areas (such as creation and locality). But for most purposes the B-tree is just good enough.
> It's common practice to upgrade to every other major Office release. Organizations still running 2000 are considering the upgrade to the latest.
True. And you can tell clever from not so clever companies by which versions they use. 6 was ok, 95 (7.0) was a lemon, and 97 (8.0) was the best ever, in my experience. 2000 (9.0) got mixed reviews, as got any version since. I have 2003 (11.0), and it is pretty slow even on a recent machine. 2007 (12.0) actually looks pretty good again, although very different from any previous version.
So even versions seem to be good, and odd versions are lemons, at least on the average. Find a company that only used even versions, and they are either lucky or clever:-)
> I'd like to have more in my toolbox than hashes, linked lists, heaps and various binary and n-way trees.
You forgot arrays (very useful!), but maybe that is just too trivial. Anyway, what exactly are you missing? Most problems I know can be solved using these basic data-structures, or a combination thereof.
If you really want to, you can actually get by with just one data-structure:
Lisp uses only nested linked lists, that can be interpreted as binary trees.
Perl only really knows hashes. Arrays and lists exist, but the support is weak.
Embedded programs often use arrays only, sometimes extended with linked lists.
Databases use B-trees pretty much exclusively. They may not always be the fastest solution, but they perform well enough under a wide range of circumstances.
Of course you can go and use advanced graph theory. It may even have its benefit, but will the next person working on your code know what you are doing? Lets face it, most people are spoiled by "convenient" languages. They know array and dictionary, that's as far as most people every get.
I feel old now. My first laptop was running on 10W under full CPU load, and maybe 14W with heavy HD activity and the display at maximum brightness. Battery life was 3 hours with a new battery pack, but going down after a few years of use. And it ran Linux like a charm, as long as you kept in mind that 8MB of RAM are not enough for X11, emacs and gcc...
> I don't get this comparison at all. To me, the big deal with something like Beta vs VHS is that once you make a purchase, you're committed to a format.
Exactly. Betamax vs VHS was a question of compatibility. LCD vs Plasma is only a matter of technology. And consumers care about compatibility, but they couldn't care less about technology. So there is no comparison:-).
I think it is becoming popular to cite Betamax whenever you run out of something to say.
> I've been in the IT industry for over 10 years in companies varying in size from 4 employees to 80,000. I have NEVER, NOT ONCE had a legitimate business reason to use anything using 3D accelleration, and anything more than basic audio is also unnecessary.
I might have been there only a few years, but I have certainly seen several good uses for 3D: Google Earth for planning a business trip (yes, you can do with Google Maps, but Google Earth has a few nice features), and several 3D visualisation packages for big data sets.
Audio is even more important: if you try to use VoIP, you need low latency full duplex audio. I would not trust VMware with that.
So you may be able to do without, but then again you may need it.
> I've seen very few business class machines that were incompatible with linux
There are very few machines that you can't run Linux on, but in my experience installing Linux on a machine that is not meant to run Linux calls for trouble. On my machine it is the broadcom GB ethernet that causes problems with Debian, because some raving evangelist stripped the BLOB firmware out. And I can't get the NVidia driver to work well.
My colleagues have problems with ACPI and with CD drives. And these are all standard HP desktop machines, don't get me started on Notebooks...
> Everyone at my office uses the same key for MS Office. It's called volume licensing.
Ok, so you can install MS Office on the shared image, but what about the application that used by only one or two people? I am sure these exist, certainly we have them. And about half use Visio, the other half has to make do with Powerpoint. With a shared image we would need to buy lots of Visio licenses.
So I think we agree that some planning is in place. Asking Slashdot is not a replacement for brain cells:-)
1. You still need an OS to run VMware. If it is Windows, you get typical Windows problems, and if it is Linux, you will probably find that your hardware is not really compatible with anything but Windows.
2. Do you want to use one image, or a different image per user? If you use one image, you will immediately run into license problems with the software. If you use several images, you need a lot of storage space, and you need to copy the images back in the evening.
But most of all you need to figure out what your real problem is, and why VMs should solve it.
> Despite the fact that this is a dupe, it still angers me that the 'major' pc protection companies can't deal with windows actually securing itself.
Me too, but it makes business sense: the whole "pc protection" industry is based on the fact that Windows is insecure. Of course they are upset if Windows is getting more secure, and they will do everything in their power to prevent this.
> This is exactly why I dropped Linux and went to OS X - the 4th major revision sports feature such as better basic-string handling (!!) and better programming APIs.What about overall user experience[?]
Qt is a toolkit, that means a tool for programmers. So it is only natural that is provides a better *programming* experience. If you want better user experience, you have to wait for an end user program. And I am sure that KDE 4 will deliver exactly that.
> The GNU project was trying to create a free version of Unix - the GNU system - and was going about it in a systematic fashion, one tool at the time.
One tool at a time is by no means systematic. Doing it in the right order would be systematic. Except that the GNU project had an Image Manipulation Program and a desktop environment before the kernel would support 2GB of hard disk space. To me that does not look very systematic.
> You think that Linux - a single operating system kernel - is going to have more lasting influence than the whole free software movement, of which the Linux kernel is just a part of ?
Fortunately, GNU and FSF are not the whole free software movement. There is BSD, there is KDE, there is Mozilla, there is OpenOffice, and there are also countless smaller projects. Freedome is also about choice, but choice is something that RMS seems to reserve to himself.
I do use emacs, or rather xemacs, but the project is a good as dead, and certainly not the future. I use glibc, and I would like to use it even more, but the port to Solaris is dead. I use gdb, and I would like to use it even more, but the support for SPARC64 is very flaky. I use gcc, and I would like to use it even more, but it does not compile to common virtual machines (Perl, Parrot, Java or CIL). bash is nice, certainly compared to the bourne shell, but it has been like this for more then 10 years.
So while a lot of GNU tools are useful, even the very best ones leave at lot do be desired. And don't tell me to just write a patch, because it is not that easy. The missing support of virtual machines for example is a political decision of RMS, and much the same can probably be said about the Solaris port of glibc. The missing support of anti-aliased fonts in emacs is just a symptom that the project is dead.
Slashdot Mirror
> When asked about the possibility of preloading OS/2, he laughed and said something like, ``yeah, right, I'm going to preload the software of a direct competitor on my machines.''
I think that is a good point. It is usually assumed that having two businesses in one company leads to synergy. Reason given are that you can bundle solutions, you can focus your brand etc etc.
However, being in several fields of business can also be a problem. IBM doing hardware and software is an example: you would assume that selling hardware would give them an edge selling software for it, but it did not. Instead, IBM sold its hardware with Windows (for which ever reasons), and IBM compatibles where sold with Windows, because they were competing with IBM and thus with OS/2. Sony is another example: the media division makes them cripple the consumer devices, and in the end they all go down...
I am sure Microsoft was often tempted to produce hardware, but they were smart enough to stay from any actual computer components. They only produce peripherals (and nice ones), which do not threaten their software business.
>> To be completely thorough, a developer should set up both white- and blacklists in order to cover all bases.
:-)).
:-(
> I can't help but feel that most developers have at least a little common sense and do something along those lines anyway.
I hope that most developers have the common sense to take the correct approach: avoid injection problems by proper quoting! There is no need to validate the data, you just have to make sure that it stays data when you parse it on. Just use the proper library functions, and you will be fine (especially if you use hex encoding
White lists are a good idea if you don't trust you quoting, or if you need to verify the input for another reason. Black lists are most certainly not a good idea. Just imagine that the web shop tries to sell a product called "Selecta[tm]", but you block all attempts to buy it because it matches your black word "SELECT"
P.S.: Anybody with an apostrophe in their name naturally develops an unsatisfiable urge to kill web programmers.
> So, the redundancy of end tags in XML is there because, in practice, if you didn't have it, we had learned that our users had problems correcting their documents, and we knew that, in general, it was only rarely possible for software to give the users much help. There were some experiments early on with , allowed by SGML (with various options set) to end any element; it soon became obvious that this caused more problems than it was worth, and even Microsoft disabled the troublesome feature in their XML parser.
Given my experience with users that have inadequate support in their editor for structured documents, having the redundancy actually does not help. Sure, you get an error message instead of accidentally specifying something you did not wont, but the error message does not help people all that much. So they still stare at the XML and don't get what is wrong.
Allowing comments within an element (for each attribute) would have been a huge contribution to legibility. Of course that depends on how you use it, but I think attributes get a lot of use exactly because they have less redundancy.
My conclusion is that in the end, you need structured tools for structured data. And so the format does not actually have to be easy to read. (And believe me, even the best of XML documents are not easy to read if the structure is reasonably complicated.)
> The next typical objection is, "What if they ask for classes and books and a reduced workload so that they have time to learn this? That's unacceptable! Can't they just learn it from a couple of articles on the web with no productivity impact?" If that's what you're feeling, then the biggest barrier to adopting good practices at your company isn't your engineers, it's you.
Been there, done that. And I can conclude that it is not only true, but also reality.
Reducing the number of bugs is not going to be free. It is not going to be easy. If you expect it to be, you are doomed from the start.
> I mean, who labels things "best practice" anyway?
..." -> "Our best way of doing business is ..." (How do you know? What you really mean is that you hope ... is the best way of doing business, and you hope everybody is doing it.)
..., but we can't do that." -> "The best way we can do this is ..., but we can't do that." (This is an obvious contradiction in terms, but still everybody is expected to nod.)
"Best practice" is a ridiculous phrase. It does indeed sound of Mount Sinai, but all it means that this is the best way of doing business. Once you translate it, a lot of the bullshit is not nearly as scary any more.
"We should really follow best practice." -> "We should really do things the best way possible." (kind of a tautology, so everybody nods, but nothing is actually said.)
"Our best practices are
"Best practices would require
> Unfortunately, it's often the job of senior technical folks to force change upon the less experienced and ignorant, because they honestly have no idea what's good for them.
While it is certainly true that there are more and less experienced developers, you are not exactly helping the "buy in" by calling someone "ignorant". If fact, it is a near sure sign that you would design procedure which seem to make sense, but which actually do not work for the people that have to use them.
So if you want to have working procedures, you need to ask the people affected by them first. Everything else is a vain waste of time.
> What ways have you used to convince your developers and engineers to adopt
> a new set of practices that may or may not get in the way of their daily work habits?
You have to get them involved in creating and writing the practices. You said yourself that they are smart folkes, so ask them what they would like to have improved. This is not always easy, and it is certainly difficult to reach a consensus between a lot of smart folkes, but it is absolutely essential.
If you just want to know the best way to prescribe your favorite coding styling, and your are afraid that it may get into the way of the engineers' daily work, then forget it.
> for those that left, how did you get started?
:-)
I did not start from the States, but I did get jobs in different European countries. So I have the experience of applying "somewhere else", but given my right to stay and working within the EU, I did not have VISA/work permit issues. Even so it can be a difficult process.
1. Finding the job should be no problem. Got to www.monster., and you will find thousands of jobs. Unless you are very specialised, there should be something for you.
2. Taking the first hurdle. IT recruitment is usually outsourced or at least concentrated in HR. So your application will be scored, and you do take a hit for not "being there", and another for not being available immediately. Following up by phone really helps, but watch the time zones!
3. Phone interview. Again you have to watch the time zones, but it should not be a problem. I hope you speak the correct language!
4. Getting the interview. Obviously the interview is going to be costly if you are not "there". Usually European employers pay reasonable travel expenses, but I doubt this will include a transatlantic flight. In any way you have another disadvantage at this point, because the interview is expensive and difficult to arrange.
5. Moving. Finding a house and moving your stuff can be expensive, but that depends on your circumstances. Employers usually pay a contribution, and the rest is tax deductible (not bad at tax rates around 40%).
So 2. and 4. are difficult. And there is the work permit issue. You can nearly always get a work permit, if the company "sponsors" you. However, most companies try to avoid the paper work necessary. Getting a work permit based on skills (without a sponsor) is possible, but often expensive, and only valid in one European country.
And don't forget that unemployment is around 10%, so there is plenty of competition. Having a distinguishing (relevant) skill certainly helps a lot.
I hope this does not sound too negative. If you are determined to move, it is certainly possible. And you are rewarded with completely unamerican advantages such as state healthcare, an average of 30 private holidays per year, and usually shorter work hours. Plus you can visit all the European countries in a reasonably short time!
> On one hand, Mozilla doesn't want binaries being redistributed that they didn't build themselves. On the other hand, Debian wants to be able to handle source patches of their entire source tree. The result is that you get two competing ideals, both seemingly valid, creating this bit of a mess.
:-)
I disagree. If Mozilla doesn't want modified binaries being redistributed, it is not open software any more. The code base itself might be open, but Firefox (the branded binary) is most certainly closed software now. So while they give a good reason for this, it is not actually a valid requirement.
> After stepping back for a moment, however, I realized that the problem isn't as complex as it seems. In fact, I think it highlights something I've been saying for a while: Package systems under Linux are a broken concept.
Again I disagree. (Some) package systems under Linux work wonderfully well: you get everything from one source, and you can install 6000 packages without a single unexpected conflict. This might seem impossible, but with good policies it is actually quite doable. What makes Debian or Ubuntu or SuSE so powerful are exactly the policies that make everything work together.
Try the same under Windows: you install all your applications, and suddenly something stops working. Even if you find out which two packages interfere, you will just get two companies pointing fingers at each other
> What we're seeing here is a legal extension of that same problem. By integrating the software into the codebase, Debian is attempting to take legal responsibility for the software.
There is no legal responsibility for open software. You get what you pay.
> Mozilla should be outside of that repository, but any software that's not in the repository is not well supported by the packaging system.
Wrong again. With apt-get, it is no problem at all to load third party repositories. So you could have Mozilla Firefox in the Mozilla repository, and Iceweasel in the Debian repository. You would even have a choice. However, Mozilla decided not to release a Debian package of Firefox, which makes installing the official Firefox on Debian a PITA.
> In this case, Debian wants this software to be managed like all the other software they manage.
Which seems reasonable to me. Firefox developers might think that it is the most important piece of software in recent history, but from a packaging point of view it *is* just another piece of software.
> Another benefit is that your electric car becomes more environmentally friendly every time someone puts up a new wind farm.
From a marketing perspective, wind farms are the best thing since sliced bread. You can sell the environmental friendliness many times over: to the investor giving the money, to the area where you put it up, to the customer getting the electricity, to the electric car using the electricity. Everybody involved even a tiny bit will claim that they are responsible for less polution or a cleaner environment.
Thomas
> As much as people keep saying it, this is totally false... Common Lisp does not even have lists as an intrinsic type.
Funny how LISP stands for LISt Processing. And this thread is about data structures, not data types. The cons cell might be the central data type in LISP, but the nested list is the central data structure.
Just think about it. '(a b c) will be recognised as a 3 element list by any LISP programmer, and not as 2 cons cells plus 3 atoms (which would be equally correct). Now you can also construct binary trees with cons cells, but that is more complicated and therefore a bit rare.
Thomas
> There have been times when red-black trees are too expensive, because they have 2 pointers per node and I can't afford the memory overhead. It's amazing how much memory gets wasted when you add an 8 byte pointer to a 0x10 byte structure that can have over 2^35 instances.
Too expensive is relative. You can optimise most of the overhead away, but you still have to store 0x10 byte per structure. Investing a lot of work just to reduce the memory usage by 30% is *usually* not worth it, although there are certainly exceptions.
And this is exactly what the Trie is for. It can offer some marginal advantages in general performance over B-trees, and it can offer more significant advantages in a few obscure areas (such as creation and locality). But for most purposes the B-tree is just good enough.
Thomas
> It's common practice to upgrade to every other major Office release. Organizations still running 2000 are considering the upgrade to the latest.
:-)
True. And you can tell clever from not so clever companies by which versions they use. 6 was ok, 95 (7.0) was a lemon, and 97 (8.0) was the best ever, in my experience. 2000 (9.0) got mixed reviews, as got any version since. I have 2003 (11.0), and it is pretty slow even on a recent machine. 2007 (12.0) actually looks pretty good again, although very different from any previous version.
So even versions seem to be good, and odd versions are lemons, at least on the average. Find a company that only used even versions, and they are either lucky or clever
Thomas
> I'd like to have more in my toolbox than hashes, linked lists, heaps and various binary and n-way trees.
You forgot arrays (very useful!), but maybe that is just too trivial. Anyway, what exactly are you missing? Most problems I know can be solved using these basic data-structures, or a combination thereof.
If you really want to, you can actually get by with just one data-structure:
Lisp uses only nested linked lists, that can be interpreted as binary trees.
Perl only really knows hashes. Arrays and lists exist, but the support is weak.
Embedded programs often use arrays only, sometimes extended with linked lists.
Databases use B-trees pretty much exclusively. They may not always be the fastest solution, but they perform well enough under a wide range of circumstances.
Of course you can go and use advanced graph theory. It may even have its benefit, but will the next person working on your code know what you are doing? Lets face it, most people are spoiled by "convenient" languages. They know array and dictionary, that's as far as most people every get.
Thomas
> Some kind of basic organization ala MS Project... dunno personally, but MSProject sucks too.
planner works, but it is about as basic as MS Project.
> Visio equivalent... dunno
Take your pick: Dia, tgif, sketch, OpenOffice Draw (and each one has better EPS export than Visio)
> Defect tracking: Bugzilla
I find Bugzilla a bit basic, but it certainly get the job done.
> Source Control: SVN Obliterates some of the 6 figure competitors IMHO
What about a nice GUI? That still seems to be missing.
> Email: Thunderbird
Gmail imho blows everything else away. You can also try Opera, it is not too different.
> Contact management: Yes, we have choices, but the propertiary ones are better IMHO
I am still looking for one, too.
> Scheduler... sorry Sunbird & the like aren't up to part yet... still gotta give Evolution an install, but I'm busy
Google Calendar works like a charm, as long as you use it consistently.
Thomas
> The Merom runs at 34W idle
I feel old now. My first laptop was running on 10W under full CPU load, and maybe 14W with heavy HD activity and the display at maximum brightness. Battery life was 3 hours with a new battery pack, but going down after a few years of use. And it ran Linux like a charm, as long as you kept in mind that 8MB of RAM are not enough for X11, emacs and gcc...
> I don't get this comparison at all. To me, the big deal with something like Beta vs VHS is that once you make a purchase, you're committed to a format.
:-).
Exactly. Betamax vs VHS was a question of compatibility. LCD vs Plasma is only a matter of technology. And consumers care about compatibility, but they couldn't care less about technology. So there is no comparison
I think it is becoming popular to cite Betamax whenever you run out of something to say.
> I've been in the IT industry for over 10 years in companies varying in size from 4 employees to 80,000. I have NEVER, NOT ONCE had a legitimate business reason to use anything using 3D accelleration, and anything more than basic audio is also unnecessary.
I might have been there only a few years, but I have certainly seen several good uses for 3D: Google Earth for planning a business trip (yes, you can do with Google Maps, but Google Earth has a few nice features), and several 3D visualisation packages for big data sets.
Audio is even more important: if you try to use VoIP, you need low latency full duplex audio. I would not trust VMware with that.
So you may be able to do without, but then again you may need it.
> I've seen very few business class machines that were incompatible with linux
:-)
There are very few machines that you can't run Linux on, but in my experience installing Linux on a machine that is not meant to run Linux calls for trouble. On my machine it is the broadcom GB ethernet that causes problems with Debian, because some raving evangelist stripped the BLOB firmware out. And I can't get the NVidia driver to work well.
My colleagues have problems with ACPI and with CD drives. And these are all standard HP desktop machines, don't get me started on Notebooks...
> Everyone at my office uses the same key for MS Office. It's called volume licensing.
Ok, so you can install MS Office on the shared image, but what about the application that used by only one or two people? I am sure these exist, certainly we have them. And about half use Visio, the other half has to make do with Powerpoint. With a shared image we would need to buy lots of Visio licenses.
So I think we agree that some planning is in place. Asking Slashdot is not a replacement for brain cells
You have two main logical problems.
1. You still need an OS to run VMware. If it is Windows, you get typical Windows problems, and if it is Linux, you will probably find that your hardware is not really compatible with anything but Windows.
2. Do you want to use one image, or a different image per user? If you use one image, you will immediately run into license problems with the software. If you use several images, you need a lot of storage space, and you need to copy the images back in the evening.
But most of all you need to figure out what your real problem is, and why VMs should solve it.
> Despite the fact that this is a dupe, it still angers me that the 'major' pc protection companies can't deal with windows actually securing itself.
Me too, but it makes business sense: the whole "pc protection" industry is based on the fact that Windows is insecure. Of course they are upset if Windows is getting more secure, and they will do everything in their power to prevent this.
> This is exactly why I dropped Linux and went to OS X - the 4th major revision sports feature such as better basic-string handling (!!) and better programming APIs.What about overall user experience[?]
Qt is a toolkit, that means a tool for programmers. So it is only natural that is provides a better *programming* experience. If you want better user experience, you have to wait for an end user program. And I am sure that KDE 4 will deliver exactly that.
> The GNU project was trying to create a free version of Unix - the GNU system - and was going about it in a systematic fashion, one tool at the time.
One tool at a time is by no means systematic. Doing it in the right order would be systematic. Except that the GNU project had an Image Manipulation Program and a desktop environment before the kernel would support 2GB of hard disk space. To me that does not look very systematic.
> You think that Linux - a single operating system kernel - is going to have more lasting influence than the whole free software movement, of which the Linux kernel is just a part of ?
Fortunately, GNU and FSF are not the whole free software movement. There is BSD, there is KDE, there is Mozilla, there is OpenOffice, and there are also countless smaller projects. Freedome is also about choice, but choice is something that RMS seems to reserve to himself.
I do use emacs, or rather xemacs, but the project is a good as dead, and certainly not the future.
I use glibc, and I would like to use it even more, but the port to Solaris is dead.
I use gdb, and I would like to use it even more, but the support for SPARC64 is very flaky.
I use gcc, and I would like to use it even more, but it does not compile to common virtual machines (Perl, Parrot, Java or CIL).
bash is nice, certainly compared to the bourne shell, but it has been like this for more then 10 years.
So while a lot of GNU tools are useful, even the very best ones leave at lot do be desired. And don't tell me to just write a patch, because it is not that easy. The missing support of virtual machines for example is a political decision of RMS, and much the same can probably be said about the Solaris port of glibc. The missing support of anti-aliased fonts in emacs is just a symptom that the project is dead.
> I like the summary though at the end of the article : Make your own conclusions;
My conclusion is that the author of the article is clueless. He doesn't like Google PageRank, but he can't even clearly state why.