It's only because I work in a MS-shop that I actually use it, otherwise I'd dump it straight away. The branching/merging is terrible, setting labels is even worse.
The biggest problem is that it corrupts it own database, Especially when you reorganise your project structure! How un-safe can your sources be in "SourceSAFE".
You may think the internet is the end of privacy, but I know for sure that people hand over much information (without even knowing) to marketing companies.
Let me think: 1. What can credit-card companies do with all the payslips: they know where you do your shopping! 2. You've got a discount card of your local supermarket? I do. The supermarket probably knows my shopping behaviour better than I do. 3. Even received the envelop with a questionair? You did return it? Yet another entry in the database. 4. Returned that fill-in form for warranty on a product? Yep, here we go again. 5. Ever done some work for charity? President of your local sport club? It's noted somewhere... 6. This list is enless.
There is a statistic for the Netherlands (where I live) that says that a name appears in 400 databases on avarage. Those who didn't realize that this is happening must have been blind that last 2 decades. The only thing the internet added to this is the even finer granularity.
Marco (with yet another public entry that can be traced).
I completely agree on your first subject (compiler generate faster code than handmade assembly). There's hardly any dispute (except maybe for very esoteric applications that must use very dark corners of a processor).
With the JIT vs. compiled language compilers I must disagree. The JIT-compiled language will never get faster than the chip will compile for. JIT compiler are generally in a hurry: it hasn't been compiled before and the user wants it executed NOW. Pre-compiled application have their compiler sitting a few minutes in silence to figure out the best instructions to use. Who will come up with the fastest code? Yep: the compiler.
The memory allocation issue that you were thinking about is only a small portion of performance and optimal code. Stack or heap allocation/de-allocation algorithms are well understood problems. These issues have been solved before. Compiled vs JIT-compiled will make little difference.
With respect to the "atmosphere of fear" I'd like to say that this effect is true as well for todays CCTV cameras: the fear to be caught while committing a crime.
Though I don't want to advocate crime, the cameras do(!) use the effect of creating fear. Therefore George Orwell was right. He only wasn't right that the cameras would enter our home (now their are at the corner of our street, so he was close).
Next week in yout neighbourhood: the thought police!
Theoretically is may be possible. It's not possible from a practical point of view.
Think about what you'd have to code if an internal structure changes (this happens a lot!). It would add to much code only going from one version to the next. I think they effort of implementing such a thing doesn't compare to the downtime of a few minutes that you would have.
If your uptime is really that sacred, that don't upgrade. Apparently your system is already stable enough that a reboot for a kernel upgrade is considered harmful. This implies that the current version of the kernel already suits your needs in terms of stability. Then there is no reason to upgrade anyway.
If security or stability is an issue, then you should take the time to reboot. Consider the time you lose because someone cracks your system or because unnecesary instability and you know why.
the 1448x1086 resolution is probably a result from the old days when memory was really expensive. It represents the maximum size you can obtain with 1.5MB of memory while keeping the horizontal/vertical ratio to 4:3. Remember the old Sun monitors: 1152x864? Same stuff: it fits just in 1 MB. These aren't VESA standard, but work very often for reasons above. In modern Multi-MB super 3D monitors, the memory size doesn't pose any limits anymore, so let's forget about them.....
Many people write web application. These application don't need all the extra goodies of a (more or less) complete SQL implementation.
The big differences are: 1) Transaction management 2) Stored procedures
Take for example a "Slashdot" system. This system doesn't require very much of the database.
It doesn't need transactions. Most action is making selects on texts to view. After that the "transaction" is complete. The second most use option is probably submitting a text (such as this). This can be done with a single insert command. The last option is updating user settings. This may require transaction handling: what happens if the user is "logged in" twice and changes his user settings at the same time? This situation is probably considered "unlikely" or an "acceptable bug". From this point of view, Slashdot is just like many other web-sites: all it requires is speed.
However, I you try to build a real world financial administration,you cannot live with such "acceptable bugs". This requires more, most important the two features mentioned above.
Now the question is whether many organisation would allow such critical data to live on PostgreSQL. System administrators are used to Oracle, Sybase, Informix etc. These names they trust. PostgreSQL only has become reasonably stable in the last 1.5 year and still has to build its name. Only a few months ago some critical features (e.g. row-locking) have been implemented to make it feasible to make such an administration system. The name still has to grow, but has a great potential. After it has done so, you will find more comments of people being enthousiastic about PostgreSQL.
I think that you should organise it differently. If you program then you work. You can charge for labour. Just make a contract for it. There's nothing special about it. In construction work they do it all the time: charge hours and material. Programming takes time and requires some material (hardware, an office, etc.). That's still the most costly thing about it and that's how you can earn your money.
From this point of view, making a program for somebody is just another service. This is how you earn your money and has nothing to do with OSS or CSS. Most software companies that work on a project basis work that way: they estimate how much work it is to build the program and charge for building it.
If this is to be build like an Open Source book, then you need more time. One of the strengths of Open Source is the continues testing/debuging/reviewing of the programs. This obviously needs time and can hardly be done within 24 hours..
But could you please shut up and stop screaming around that the web (/.) made it possible. Sure it did, but to most techies that is not interesting. I think you should publish this on a site dedicated to sales (of books). I think this time you've choosen the wrong audience.
As an experienced user I tend to forget what struggles the normal starter goes through. Bad hardware and to much to read, while you want to get things done.
People may say: RTFM or the HOW-TO's, but starters simply don't read them: to much and very often to much techie-speak.
I'm glad Jon finally got a bit of the feeling that (what he calls hacking) is fun and in some way needed. He finally gets to see how non-trivial many details are, but on the other hand, how much those details are needed to get the machine to work. Finally he start realizing that the things the OS hides is very much, and when you need it, some vendors hardly gives any access to those details.
However, we cannot expect everybody go into that much detail. This hiding of details is also the succes of some OS-es. Thanks God KDE and GNOME have already done a great deal in making things easy. Hacking may be fun for most readers of/. and it has just caught the interest of Jon that it may be fun to solve problems, but to my neighbour, a very simple user, this still is to much: simple needs require a simple OS.
Jon, good luck getting your computer to work. And please keep posting that many things are not so easy for non-techies.
Slashdot Mirror
It's only because I work in a MS-shop that I actually use it, otherwise I'd dump it straight away. The branching/merging is terrible, setting labels is even worse.
The biggest problem is that it corrupts it own database, Especially when you reorganise your project structure! How un-safe can your sources be in "SourceSAFE".
You may think the internet is the end of privacy, but I know for sure that people hand over much information (without even knowing) to marketing companies.
Let me think:
1. What can credit-card companies do with all the payslips: they know where you do your shopping!
2. You've got a discount card of your local supermarket? I do. The supermarket probably knows my shopping behaviour better than I do.
3. Even received the envelop with a questionair? You did return it? Yet another entry in the database.
4. Returned that fill-in form for warranty on a product? Yep, here we go again.
5. Ever done some work for charity? President of your local sport club? It's noted somewhere...
6. This list is enless.
There is a statistic for the Netherlands (where I live) that says that a name appears in 400 databases on avarage. Those who didn't realize that this is happening must have been blind that last 2 decades. The only thing the internet added to this is the even finer granularity.
Marco (with yet another public entry that can be traced).
It was on 30-8-888 (october, november and december
have a 1 in they numeric representation).
The combination of even numbers will be very common from now on (just as the combination of odd numbers used to be between 1000 and 1999).
So what's the fuss all about?
Marco.
I completely agree on your first subject (compiler generate faster code than handmade assembly). There's hardly any dispute (except maybe for very esoteric applications that must use very dark corners of a processor).
With the JIT vs. compiled language compilers I must disagree. The JIT-compiled language will never get faster than the chip will compile for. JIT compiler are generally in a hurry: it hasn't been compiled before and the user wants it executed NOW. Pre-compiled application have their compiler sitting a few minutes in silence to figure out the best instructions to use. Who will come up with the fastest code? Yep: the compiler.
The memory allocation issue that you were thinking about is only a small portion of performance and optimal code. Stack or heap allocation/de-allocation algorithms are well understood problems. These issues have been solved before. Compiled vs JIT-compiled will make little difference.
Marco Schramp
With respect to the "atmosphere of fear" I'd like to say that this effect is true as well for todays CCTV cameras: the fear to be caught while committing a crime.
Though I don't want to advocate crime, the cameras do(!) use the effect of creating fear. Therefore George Orwell was right. He only wasn't right that the cameras would enter our home (now their are at the corner of our street, so he was close).
Next week in yout neighbourhood: the thought police!
Marco.
Theoretically is may be possible. It's not possible from a practical point of view.
Think about what you'd have to code if an internal structure changes (this happens a lot!). It would add to much code only going from one version to the next. I think they effort of implementing such a thing doesn't compare to the downtime of a few minutes that you would have.
If your uptime is really that sacred, that don't upgrade. Apparently your system is already stable enough that a reboot for a kernel upgrade is considered harmful. This implies that the current version of the kernel already suits your needs in terms of stability. Then there is no reason to upgrade anyway.
If security or stability is an issue, then you should take the time to reboot. Consider the time you lose because someone cracks your system or because unnecesary instability and you know why.
Regards,
Marco.
the 1448x1086 resolution is probably a result from the old days when memory was really expensive. It represents the maximum size you can obtain with 1.5MB of memory while keeping the horizontal/vertical ratio to 4:3. Remember the old Sun monitors: 1152x864? Same stuff: it fits just in 1 MB. These aren't VESA standard, but work very often for reasons above. In modern Multi-MB super 3D monitors, the memory size doesn't pose any limits anymore, so let's forget about them.....
Finally!! I've got a sick mind and don't want
to deprive my body from a good one!
Very good stuff. Looks much better than the simple screenshot from SGI.
Many people write web application. These application don't need all the extra goodies of a (more or less) complete SQL implementation.
The big differences are:
1) Transaction management
2) Stored procedures
Take for example a "Slashdot" system. This system doesn't require very much of the database.
It doesn't need transactions. Most action is making selects on texts to view. After that the
"transaction" is complete. The second most use option is probably submitting a text (such as this). This can be done with a single insert command. The last option is updating user settings. This may require transaction handling: what happens if the user is "logged in" twice and changes his user settings at the same time? This situation is probably considered "unlikely" or an "acceptable bug". From this point of view, Slashdot is just like many other web-sites: all it requires is speed.
However, I you try to build a real world financial administration,you cannot live with such "acceptable bugs". This requires more, most important the two features mentioned above.
Now the question is whether many organisation would allow such critical data to live on PostgreSQL. System administrators are used to Oracle, Sybase, Informix etc. These names they trust. PostgreSQL only has become reasonably stable in the last 1.5 year and still has to build its name. Only a few months ago some critical features (e.g. row-locking) have been implemented to make it feasible to make such an administration system. The name still has to grow, but has a great potential. After it has done so, you will find more comments of people being enthousiastic about PostgreSQL.
I think that you should organise it differently. If you program then you work. You can charge for labour. Just make a contract for it. There's nothing special about it. In construction work they do it all the time: charge hours and material. Programming takes time and requires some material (hardware, an office, etc.). That's still the most costly thing about it and that's how you can earn your money.
From this point of view, making a program for somebody is just another service. This is how you earn your money and has nothing to do with OSS or CSS. Most software companies that work on a project basis work that way: they estimate how much work it is to build the program and charge for building it.
If this is to be build like an Open Source book, then you need more time. One of the strengths of Open Source is the continues testing/debuging/reviewing of the programs. This obviously needs time and can hardly be done within 24 hours..
But could you please shut up and stop screaming around that the web (/.) made it possible. Sure it did, but to most techies that is not interesting. I think you should publish this on a site dedicated to sales (of books). I think this time you've choosen the wrong audience.
Marco Schramp
As an experienced user I tend to forget what
/. and it has just caught the interest of Jon that it may be fun to solve problems, but to my neighbour, a very simple user, this still is to much: simple needs require a simple OS.
struggles the normal starter goes through. Bad hardware and to much to read, while you want to get things done.
People may say: RTFM or the HOW-TO's, but starters simply don't read them: to much and very often to much techie-speak.
I'm glad Jon finally got a bit of the feeling that (what he calls hacking) is fun and in some way needed. He finally gets to see how non-trivial many details are, but on the other hand, how much those details are needed to get the machine to work. Finally he start realizing that the things the OS hides is very much, and when you need it, some vendors hardly gives any access to those details.
However, we cannot expect everybody go into that much detail. This hiding of details is also the succes of some OS-es. Thanks God KDE and GNOME have already done a great deal in making things easy. Hacking may be fun for most readers of
Jon, good luck getting your computer to work. And please keep posting that many things are not so easy for non-techies.
Marco.