SUCCESS!! Everything working, even the 'roll your own' apps!!
Thanks!!
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Always Learning Sent: Wednesday, September 14, 2011 7:07 PM To: CentOS mailing list Subject: Re: [CentOS] Upgrade from 5.6 => 5.7
On Wed, 2011-09-14 at 19:05 -0400, Thomas Dukes wrote:
SUCCESS!! Everything working, even the 'roll your own' apps!!
What did you expect ? Its not Windoze ;-)
You know, 'Always Learning' is the perfect username! I'm 56 yrs. old and I learn something everyday on this list. Been doing the Linux thing since the mid-90's. I had a two phone line, Wildcat BBS connected the internet pulling newsgroups, running Frontdoor, etc. I can say without a doubt everything CentOS/RHEL is doing is just UFR (probably can't say that on the list)!!
If we could just get a Linux based Quickbooks, I'd never run a windoze system again!!
On Wed, 2011-09-14 at 20:12 -0400, Thomas Dukes wrote:
You know, 'Always Learning' is the perfect username! I'm 56 yrs. old and I learn something everyday on this list. Been doing the Linux thing since the mid-90's.
Blush, blush, I'm older.Been on Linux, properly, since 1 June 2010 and absolutely love it. Its so adult compared to Windoze.
I had a two phone line, Wildcat BBS connected the internet pulling newsgroups, running Frontdoor, etc. I can say without a doubt everything CentOS/RHEL is doing is just UFR (probably can't say that on the list)!!
If we could just get a Linux based Quickbooks, I'd never run a windoze system again!!
One day, if I have time, I want to programme a complete commercial accounts systems using HTML, PHP and MySQL. Its a piece of cake to do well (meaning easily) but a little time consuming. The only difficulty I can think of is printing things locally.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Always Learning Sent: Wednesday, September 14, 2011 8:44 PM To: CentOS mailing list Subject: Re: [CentOS] Upgrade from 5.6 => 5.7
On Wed, 2011-09-14 at 20:12 -0400, Thomas Dukes wrote:
You know, 'Always Learning' is the perfect username! I'm 56
yrs. old
and I learn something everyday on this list. Been doing the Linux thing since the mid-90's.
Blush, blush, I'm older.Been on Linux, properly, since 1 June 2010 and absolutely love it. Its so adult compared to Windoze.
I had a two phone line, Wildcat BBS connected the internet pulling newsgroups, running Frontdoor, etc. I can say without a doubt everything CentOS/RHEL is doing is just UFR (probably can't
say that on the list)!!
If we could just get a Linux based Quickbooks, I'd never
run a windoze
system again!!
One day, if I have time, I want to programme a complete commercial accounts systems using HTML, PHP and MySQL. Its a piece of cake to do well (meaning easily) but a little time consuming. The only difficulty I can think of is printing things locally.
I love the challenge. I'm a hacker from way back. While this sort of stuff isn't humorous now days and since I've 'grown up', I understand why. Still, I love it!!
On 09/14/11 6:03 PM, Thomas Dukes wrote:
One day, if I have time, I want to programme a complete
commercial accounts systems using HTML, PHP and MySQL. Its a piece of cake to do well (meaning easily) but a little time consuming. The only difficulty I can think of is printing things locally.
I love the challenge. I'm a hacker from way back. While this sort of stuff isn't humorous now days and since I've 'grown up', I understand why. Still, I love it!!
an accounting system thats in plain HTML would be incredibly clunky to use. you really want to do this in ajax/jquery or whatever so its more interactive
also, I'd suggest using postgresql for better data integrity, and anything-but-php (Python?) for better webside security.
On Wed, 2011-09-14 at 18:08 -0700, John R Pierce wrote:
an accounting system thats in plain HTML would be incredibly clunky to use. you really want to do this in ajax/jquery or whatever so its more interactive
No thank you. HTML, CSS, PHP and MySQL are my chosen tools for my systems.
I have written 20+ complete systems using these and found them to be fast and very effective. Everyone who has seen my HTML, CSS, PHP, MySQL systems has been favourably impressed (me too!). MySQL is a fast database system. Never ever used a SQL join or view, just well designed databases with carefully planned tables - that is the art of good programming.
Ajax/Jquery is someone else's parametrised programming language. It adds complexity and overhead to what is fundamentally a very basic task. Ajax etc. seem to appeal to people who are not good (or natural) programmers. Ajax etc. is like programming with boxing gloves on and taking several weeks to do it. If they want to use it, let them.
also, I'd suggest using postgresql for better data integrity, and anything-but-php (Python?) for better webside security.
I have been using MySQL on Linux for about 4 years and never had a problem. What security issues has PHP ?
On 09/14/11 6:39 PM, Always Learning wrote:
Ajax/Jquery is someone else's parametrised programming language. It adds complexity and overhead to what is fundamentally a very basic task. Ajax etc. seem to appeal to people who are not good (or natural) programmers. Ajax etc. is like programming with boxing gloves on and taking several weeks to do it. If they want to use it, let them.
Ajax is not a programming language, its a technique of implementing the client (browser) side of your applications in JavaScript, which is the programming language.
ever use gmail or google documents? thats ajax. its interactive within the USER BROWSER without requiring round trips to the web server for every little operation such as summing up the checks entered in a form as they are being entered. An Ajax accounting program could be interactive like Quickbooks is, as opposed to fill in a static form and hit submit for every little action.
And, if you've never used a SQL join, you don't know the first thing about *relational* databases, you've been using SQL as though it was a simple flat table ISAM, DBase-style circa 1983. Might as well use BerkeleyDB for that, its even faster and lighter weight.
but, whatever. its your project, have at it.
On Wed, 2011-09-14 at 19:32 -0700, John R Pierce wrote:
On 09/14/11 6:39 PM, Always Learning wrote:
Ajax/Jquery is someone else's parametrised programming language. It adds complexity and overhead to what is fundamentally a very basic task. Ajax etc. seem to appeal to people who are not good (or natural) programmers. Ajax etc. is like programming with boxing gloves on and taking several weeks to do it. If they want to use it, let them.
Ajax is not a programming language, its a technique of implementing the client (browser) side of your applications in JavaScript, which is the programming language.
Its a programming language is my humble opinion. One has to 'code' in it. It has a defined syntax and it has a rather large and complex overhead. By the way, I also think BASH is a programming language.
ever use gmail or google documents? thats ajax. its interactive within the USER BROWSER without requiring round trips to the web server for every little operation such as summing up the checks entered in a form as they are being entered. An Ajax accounting program could be interactive like Quickbooks is, as opposed to fill in a static form and hit submit for every little action.
One never ever hits the button for every little action, does one ? My latest data entry form takes 20 separate sets of entries before the user clicks SAVE.
And, if you've never used a SQL join, you don't know the first thing about *relational* databases, you've been using SQL as though it was a simple flat table ISAM, DBase-style circa 1983. Might as well use BerkeleyDB for that, its even faster and lighter weight.
Golly. I grew-up in real computers. Relational databases are simply database structures, linking records. There is no reason to use joins and views IF the database is carefully planned. Joins and views are another overhead. Rule Number 000001 in programming is Keep It Simple.
Index-sequential is another database access method that came along. Very useful. Access random is another. Data is actually 'flat'. It can not be anything else. However additional retrieval by non-primary key is usually desirable. Traversing chains of linked records is another method too.
I've done several domestic and international contracts writing applications using relational databases. Are you more of a Sys.Op than a computer programmer / systems analyst / systems programmer / database designer / systems designer ?
When SQL first came out, I think it was an IBM thing, I never liked the syntax. Years later I'm using it effectively and very productively.
but, whatever. its your project, have at it.
Thank you. Thank you too for your interesting comments.
On Thu, 15 Sep 2011, Always Learning wrote:
Golly. I grew-up in real computers. Relational databases are simply database structures, linking records. There is no reason to use joins and views IF the database is carefully planned. Joins and views are another overhead. Rule Number 000001 in programming is Keep It Simple.
Next you'll be saying you don't use triggers and constraints either.
There's nothing wrong with using a database as just a dumb datastore, but you get out exactly what you put in. Suddenly your application is responsible for a whole lot more. You might see a view as complicating things, but if it can make your app faster, and make your code cleaner, what's not to like?
I think with most applications like you're describing people have a decision to make as to how much logic goes in the DB and how much goes in the app. When you're new to it, I think you tend to put all the logic in the application. As you progress I think you at the very least put in controls into the database to maintain the integrity of the data.
jh
On Thu, 2011-09-15 at 10:35 +0100, John Hodrien wrote:
On Thu, 15 Sep 2011, Always Learning wrote:
Golly. I grew-up in real computers. Relational databases are simply database structures, linking records. There is no reason to use joins and views IF the database is carefully planned. Joins and views are another overhead. Rule Number 000001 in programming is Keep It Simple.
Next you'll be saying you don't use triggers and constraints either.
Not consciously. Never heard of them.
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=% 2Frzahf%2Frzahftrigcontable.htm
"A trigger is a type of stored procedure program that is automatically called whenever a specified action is performed on a specific table. Triggers are useful for keeping audit trails, for detecting exceptional conditions, for maintaining relationships in the database, and for running applications and operations that coincide with the change operation."
There's nothing wrong with using a database as just a dumb datastore, but you get out exactly what you put in.
Hopefully that is always possible - retrieving EXACTLY what was stored in the database. Why would one want the database to manipulate (change) data ? Is that a solution for lazy programming ?
Suddenly your application is responsible for a whole lot more. You might see a view as complicating things, but if it can make your app faster, and make your code cleaner, what's not to like?
Simplicity and good design makes applications fast.
If an application is fast and effective, because of its design and simplicity, why complicate it ? A SQL View is an additional overhead and not needed, in my opinion, in (my) well-designed systems.
I think with most applications like you're describing people have a decision to make as to how much logic goes in the DB and how much goes in the app. When you're new to it, I think you tend to put all the logic in the application. As you progress I think you at the very least put in controls into the database to maintain the integrity of the data.
As one becomes more knowledgeable and accustomed to things, one inevitably regards the database and applications as being integral parts of the same system. Efficient retrieval of stored data should be a paramount consideration for the good design of applications.
Unsure why you mean by "at the very least put in controls into the database to maintain the integrity of the data."
The integrity of the data can be divided into two aspects: ensuring the data remains constant (unaltered) while stored, which is the responsibility of the operation system and the database software, and the data's integrity from an application perspective. Junk-in always causes Junk-out even when using 'non-dumb' databases :-)
On Thursday, September 15, 2011 08:21 PM, Always Learning wrote:
The integrity of the data can be divided into two aspects: ensuring the data remains constant (unaltered) while stored, which is the responsibility of the operation system and the database software, and the data's integrity from an application perspective. Junk-in always causes Junk-out even when using 'non-dumb' databases :-)
Did you mentor DJB?
:-D
On Thu, 2011-09-15 at 20:41 +0800, Christopher Chan wrote:
On Thursday, September 15, 2011 08:21 PM, Always Learning wrote:
The integrity of the data can be divided into two aspects: ensuring the data remains constant (unaltered) while stored, which is the responsibility of the operation system and the database software, and the data's integrity from an application perspective. Junk-in always causes Junk-out even when using 'non-dumb' databases :-)
Did you mentor DJB?
No. Never heard of him/her ... (quick Google) ...Daniel Julius Bernstei.
This whole thing has gone wildly OT, so I'll check out on this post.
On Thu, 15 Sep 2011, Always Learning wrote:
Hopefully that is always possible - retrieving EXACTLY what was stored in the database. Why would one want the database to manipulate (change) data ? Is that a solution for lazy programming ?
In the ideal world, a database has sufficient internal intelligence to make sure that you don't get impossible data stored. It doesn't mean you can't have wrong data, but you at least keep the database in a sane state. Without this intelligence, your database becomes a bucket of data, where the only controls are in the application. A bug in the application means issues with the validity of the database.
Simplicity and good design makes applications fast.
If an application is fast and effective, because of its design and simplicity, why complicate it ? A SQL View is an additional overhead and not needed, in my opinion, in (my) well-designed systems.
But you see database simplicity as being simple, but ignore code simplicity. I don't get why you see them separately. I'm not saying every database you produce should be loaded with every feature you've read about in a book. But a constraint here and there, and a mostly normalised database isn't a bad thing. If you're not joining tables ever, your tables are probably poorly designed, or you're doing database work in your application. There's just a rumbling suspicion throughout this that you don't really need a database.
I think with most applications like you're describing people have a decision to make as to how much logic goes in the DB and how much goes in the app. When you're new to it, I think you tend to put all the logic in the application. As you progress I think you at the very least put in controls into the database to maintain the integrity of the data.
As one becomes more knowledgeable and accustomed to things, one inevitably regards the database and applications as being integral parts of the same system. Efficient retrieval of stored data should be a paramount consideration for the good design of applications.
Unsure why you mean by "at the very least put in controls into the database to maintain the integrity of the data."
The integrity of the data can be divided into two aspects: ensuring the data remains constant (unaltered) while stored, which is the responsibility of the operation system and the database software, and the data's integrity from an application perspective. Junk-in always causes Junk-out even when using 'non-dumb' databases :-)
Thing is, that's just not true. Junk-in *can* cause junk-out, or it can cause a runtime error and refuse to let you store the junk. I'm biased in favour of the latter, but you're not going to get that unless you load your database with more logic.
By all means do things your own way, nobody's going to stop you.
jh
On 9/15/11, Always Learning centos@u61.u22.net wrote:
Next you'll be saying you don't use triggers and constraints either.
Not consciously. Never heard of them.
You should take a look at constraints, they are good for ensuring certain types of data integrity. For example, it would make the database to stop situations like somebody trying to insert a record referring customer #9865 but in fact #9865 doesn't exist, whether it was an unintentional user error or a bug in the application.
Hopefully that is always possible - retrieving EXACTLY what was stored in the database. Why would one want the database to manipulate (change) data ? Is that a solution for lazy programming ?
No, in many situation, it's a more secure method. Databases can have privileges set. You could have triggers and stored procedures that update certain records that cannot otherwise be altered by the application which can be written by a third party. For example, a stored procedure would require both a debit and credit account for transferring funds and/or checks that the actual amount is present before doing it. Without this, a bugged application or rogue user/dev who run the app with privleged access would be able to transfer funds that don't exist.
Simplicity and good design makes applications fast.
For some apps, fast is king. For some, data security and integrity is ultimate. Would you want your banking transactions to run faster by stripping out security and validation checks, at the risk that some dude can transfer all your money into somebody else account? If so, please let me know your bank account details and access credentials, I have a program to speed up your banking transactions... ;)
The integrity of the data can be divided into two aspects: ensuring the data remains constant (unaltered) while stored, which is the responsibility of the operation system and the database software, and the data's integrity from an application perspective. Junk-in always causes Junk-out even when using 'non-dumb' databases :-)
And if the database can further ensure that the application cannot put junk in, whether due to a bug, user error or deliberate fraud, why not? Especially when it's likely to be faster because it's native code.
Emmanuel Noobadmin wrote:
On 9/15/11, Always Learning centos@u61.u22.net wrote:
<snip>
Simplicity and good design makes applications fast.
For some apps, fast is king. For some, data security and integrity is ultimate. Would you want your banking transactions to run faster by stripping out security and validation checks, at the risk that some dude can transfer all your money into somebody else account? If so, please let me know your bank account details and access credentials, I have a program to speed up your banking transactions... ;)
<snip> You *need* both. Take too long, and the user will go somewhere else.
I remember hearing about another division, a bunch of years ago, when I worked at the Scummy Mortgage Co. (name available upon request, offline), where the manager had designed the interface... and all the clerks *hated* it, and did everything they could to *not* use it.
In other words, it was a failure. But then, that's another reason I have always wanted, during the design phase, to talk to the actual end users, *not* to the Manager Who Knew, I Mean, Everything.
mark
On 9/16/11, m.roth@5-cent.us m.roth@5-cent.us wrote:
You *need* both. Take too long, and the user will go somewhere else.
Of course :D
I remember hearing about another division, a bunch of years ago, when I worked at the Scummy Mortgage Co. (name available upon request, offline), where the manager had designed the interface... and all the clerks *hated* it, and did everything they could to *not* use it.
In other words, it was a failure. But then, that's another reason I have always wanted, during the design phase, to talk to the actual end users, *not* to the Manager Who Knew, I Mean, Everything.
Similar experiences, but some bosses/managers just don't accept that we have to talk to the people who will actually be using the interface most of the time. I had customers who told me it's a waste of time talking to the workers because they don't understand the whole operational process and insist we build it the upper management way.
On Thu, 2011-09-15 at 13:17 -0400, m.roth@5-cent.us wrote:
In other words, it was a failure. But then, that's another reason I have always wanted, during the design phase, to talk to the actual end users, *not* to the Manager Who Knew, I Mean, Everything.
The end-users definitely know what they want.
On Fri, 2011-09-16 at 01:10 +0800, Emmanuel Noobadmin wrote:
On 9/15/11, Always Learning centos@u61.u22.net wrote:
Next you'll be saying you don't use triggers and constraints either.
Not consciously. Never heard of them.
You should take a look at constraints, they are good for ensuring certain types of data integrity. For example, it would make the database to stop situations like somebody trying to insert a record referring customer #9865 but in fact #9865 doesn't exist, whether it was an unintentional user error or a bug in the application.
Before anyone can add data for customer 9865, the existing customer record is displayed on the screen. This helps the user to be sure he/she has got the correct customer. A customer not found message means the record does not exist. Consequently it is impossible to add data to a non-existent customer record.
In most circumstances, instead of entering anonymous un-meaningful digits to identify customers, look-ups are done with postal code or partial address match or partial organisation name match or partial telephone number match etc. I love easy-to-use user-friendly systems.
No, in many situation, it's a more secure method. Databases can have privileges set.
I use the SQL privileges for tables and enable only the SQL verbs required by a user. I certainly do not want a user being able to 'drop' a table. Only I can do that.
You could have triggers and stored procedures that update certain records that cannot otherwise be altered by the application which can be written by a third party.
I do have some fields as zero-filled, auto increment.
For example, a stored procedure would require both a debit and credit account for transferring funds and/or checks that the actual amount is present before doing it. Without this, a bugged application or rogue user/dev who run the app with privleged access would be able to transfer funds that don't exist.
In my systems such actions could not happen. No user gets permissions they do not genuinely require. If the programme specification says no 'overdraft' then funds can not be transferred out of an account if that account balance would go negative.
Simplicity and good design makes applications fast.
For some apps, fast is king. For some, data security and integrity is ultimate. Would you want your banking transactions to run faster by stripping out security and validation checks, at the risk that some dude can transfer all your money into somebody else account? If so, please let me know your bank account details and access credentials, I have a program to speed up your banking transactions... ;)
Let us be serious. Fast, efficient applications are no good if they malfunction. Proper functioning is the first requirement and if the systems, the database and the programmes, are designed and coded efficiently, the applications will run fast and be secured.
The banks in Holland used to meet monthly to divide-up all the money that got lost in the system. Obviously they were using 'experts' to design and code their systems :-)
The integrity of the data can be divided into two aspects: ensuring the data remains constant (unaltered) while stored, which is the responsibility of the operation system and the database software, and the data's integrity from an application perspective. Junk-in always causes Junk-out even when using 'non-dumb' databases :-)
And if the database can further ensure that the application cannot put junk in, whether due to a bug, user error or deliberate fraud, why not? Especially when it's likely to be faster because it's native code.
Database intervention to validate data is too late, in my opinion. You do not want junk getting pass the application's data input stage. If you want an amount of money and someone specifies the currency as GBQ instead of GBP, then that input error should be identified and rejected at the data input stage not actually sent to the database to be stored.
That is why I always try to wreck my programmes by entering invalid data. If I fail to wreck my programmes there is a reasonable certainty others will fail too.
Paul.
On 9/16/11, Always Learning centos@u61.u22.net wrote:
Before anyone can add data for customer 9865, the existing customer record is displayed on the screen. This helps the user to be sure he/she has got the correct customer. A customer not found message means the record does not exist. Consequently it is impossible to add data to a non-existent customer record.
Assuming the system works as expected. Certainly I would expect the application to be at least doing such basic validation and verification. But wouldn't an added layer of safety be better? After all, there could be race conditions where two or more users could cause the application to pass the transaction to the database, which results in more than the allowed amount being transacted because the individual values were valid when the application checked.
In most circumstances, instead of entering anonymous un-meaningful digits to identify customers, look-ups are done with postal code or partial address match or partial organisation name match or partial telephone number match etc. I love easy-to-use user-friendly systems.
Which is where AJAX comes in. Typing in a partial address or postal code brings up, almost instantly on LAN environment, matches without having to go to a search page or equivalent.
I use the SQL privileges for tables and enable only the SQL verbs required by a user. I certainly do not want a user being able to 'drop' a table. Only I can do that.
I wasn't referring to that kind of problems but normal INSERT/UPDATE.
In my systems such actions could not happen. No user gets permissions they do not genuinely require. If the programme specification says no 'overdraft' then funds can not be transferred out of an account if that account balance would go negative.
Assuming everything works as expected, no bugs, no intentional hacks and nobody edited the application source without your knowledge ;)
I think part of the difference in mentality is the environment our applications run in. I always have to worry about some "admin" in the client's office who thinks they know how to program, and clients wanting to save money, asking them to do some modifications which may lead to problems that I might get blamed for.
So having that added layer of checks at the DB level should help... at least hopefully when the other guy gets an sql error, he might look more carefully at what's wrong with his code instead of trying to delete my trigger/constraints :D
Database intervention to validate data is too late, in my opinion. You do not want junk getting pass the application's data input stage. If you want an amount of money and someone specifies the currency as GBQ instead of GBP, then that input error should be identified and rejected at the data input stage not actually sent to the database to be stored.
It's never too late to stop junk from getting stored. Early prevention might be better than late prevention, but any prevention is definitely better than none! :D
That is why I always try to wreck my programmes by entering invalid data. If I fail to wreck my programmes there is a reasonable certainty others will fail too.
But it doesn't guarantee that somebody/something else can't. After all, we're only humans and I believe all of us have blind spots which can allow edge cases to escape testing.
On Fri, 2011-09-16 at 01:58 +0800, Emmanuel Noobadmin wrote:
On 9/16/11, Always Learning centos@u61.u22.net wrote:
But wouldn't an added layer of safety be better?
Yes of course.
After all, there could be race conditions where two or more users could cause the application to pass the transaction to the database, which results in more than the allowed amount being transacted because the individual values were valid when the application checked.
Record locking should prevent that.
In most circumstances, instead of entering anonymous un-meaningful digits to identify customers, look-ups are done with postal code or partial address match or partial organisation name match or partial telephone number match etc. I love easy-to-use user-friendly systems.
Which is where AJAX comes in. Typing in a partial address or postal code brings up, almost instantly on LAN environment, matches without having to go to a search page or equivalent.
No real different between an Ajax screen and a normal HTML screen (with CSS) showing the matches.
I use the SQL privileges for tables and enable only the SQL verbs required by a user. I certainly do not want a user being able to 'drop' a table. Only I can do that.
I wasn't referring to that kind of problems but normal INSERT/UPDATE.
That too. If a user does not need to perform a SQL function then that user has no authorisation to use the SQL verb.
In my systems such actions could not happen. No user gets permissions they do not genuinely require. If the programme specification says no 'overdraft' then funds can not be transferred out of an account if that account balance would go negative.
Assuming everything works as expected, no bugs, no intentional hacks and nobody edited the application source without your knowledge ;)
User can not change READ ONLY programme files.
It's never too late to stop junk from getting stored. Early prevention might be better than late prevention, but any prevention is definitely better than none! :D
Robust data validation is always an essential requirement for any data input procedure. There is no point in running a super-doper system if it can be contaminated with bad data. Acceptance of bad data makes a mockery of the entire system.
That is why I always try to wreck my programmes by entering invalid data. If I fail to wreck my programmes there is a reasonable certainty others will fail too.
But it doesn't guarantee that somebody/something else can't.
I think it means no one else can :-) What I never tell users is every programme routinely logs every user's details and activities. So if things go wrong, I read the application's log file.
After all, we're only humans and I believe all of us have blind spots which can allow edge cases to escape testing.
No point in me 'escaping testing' of my programmes. I prefer them going wrong in front of me and not in front of the users. Hence my vigorous testing policy when I become the user.
On 09/14/11 8:36 PM, Always Learning wrote:
And, if you've never used a SQL join, you don't know the first thing about*relational* databases, you've been using SQL as though it was a simple flat table ISAM, DBase-style circa 1983. Might as well use BerkeleyDB for that, its even faster and lighter weight.
Golly. I grew-up in real computers. Relational databases are simply database structures, linking records. There is no reason to use joins and views IF the database is carefully planned. Joins and views are another overhead. Rule Number 000001 in programming is Keep It Simple.
lets come up with a really simplistic example here.
table: customers{id, name, address} table: catalogitem(id,description,price} table: customerorder{id,customer references customers(id),date} table: orderlineitem{orderid references customerorder(id),catalogid references catalogitem(id), qty}
that data is normalized, there is no redundant data in any of those tables, they are connected by the relations defined via the references ('foreign keys').
now, if we want to pull up a summary of how much customer named 'joe' has ordered in 2010, we'd do something like...
select sum(ci.price*oi.qty) from customers c join customerorders co on (co.customer=c.id) join orderlineitem oi on (co.id=oi.catalogid) join catalogitem cati on (cati.id=oi.catalogid) where c.name = 'joe' and extract (year from co.date) = 2010;
boom. one query. concise. one round trip to the database engine, the database engine does all the heavy lifting, for which its designed, and it returns just the data you need to answer this query.
On Thu, 2011-09-15 at 10:42 -0700, John R Pierce wrote:
lets come up with a really simplistic example here.
table: customers{id, name, address} table: catalogitem(id,description,price} table: customerorder{id,customer references customers(id),date} table: orderlineitem{orderid references customerorder(id),catalogid references catalogitem(id), qty}
that data is normalized, there is no redundant data in any of those tables, they are connected by the relations defined via the references ('foreign keys').
I would not design my orders database exactly like you have.
If I knew the system user wanted to know "how much customer named 'joe' has ordered in 2010," then I would first ask
? by value
? by quantity of different items
? by gross quantity of all items
I might even make a table like this:-
C1
c1ref c1customer (code) c1quantity (integers only) c1price (in cents) c1discount (2 decimal places held as integers) c1catalogue (code) c1date (yymmdd) c1order (number) c1comments (text)
then do a query:
select c1quantity, c1price, c1discount from c1 where c1customer = 'joebloggs' and c1date like '10%'
while ...
$value.= ($c1price*$c1quantity*((100-$c1discount)/100));
now, if we want to pull up a summary of how much customer named 'joe' has ordered in 2010, we'd do something like...
select sum(ci.price*oi.qty) from customers c join customerorders co on (co.customer=c.id) join orderlineitem oi on (co.id=oi.catalogid) join catalogitem cati on (cati.id=oi.catalogid) where c.name = 'joe' and extract (year from co.date) = 2010;
Never used SQL sum, so I would try
select sum($c1price*$c1quantity*((100-$c1discount)/100)) from c1 where c1customer = 'joebloggs' and c1date like '10%'
Not a 'join' insight :-)
On Thu, Sep 15, 2011 at 08:51:23PM +0100, Always Learning wrote:
On Thu, 2011-09-15 at 10:42 -0700, John R Pierce wrote:
lets come up with a really simplistic example here.
table: customers{id, name, address} table: catalogitem(id,description,price} table: customerorder{id,customer references customers(id),date} table: orderlineitem{orderid references customerorder(id),catalogid references catalogitem(id), qty}
that data is normalized, there is no redundant data in any of those tables, they are connected by the relations defined via the references ('foreign keys').
I would not design my orders database exactly like you have.
If I knew the system user wanted to know "how much customer named 'joe' has ordered in 2010," then I would first ask
? by value
? by quantity of different items
? by gross quantity of all items
I might even make a table like this:-
C1
c1ref c1customer (code) c1quantity (integers only) c1price (in cents) c1discount (2 decimal places held as integers) c1catalogue (code) c1date (yymmdd) c1order (number) c1comments (text)
then do a query:
select c1quantity, c1price, c1discount from c1 where c1customer = 'joebloggs' and c1date like '10%'
while ...
$value.= ($c1price*$c1quantity*((100-$c1discount)/100));
now, if we want to pull up a summary of how much customer named 'joe' has ordered in 2010, we'd do something like...
select sum(ci.price*oi.qty) from customers c join customerorders co on (co.customer=c.id) join orderlineitem oi on (co.id=oi.catalogid) join catalogitem cati on (cati.id=oi.catalogid) where c.name = 'joe' and extract (year from co.date) = 2010;
Never used SQL sum, so I would try
select sum($c1price*$c1quantity*((100-$c1discount)/100)) from c1 where c1customer = 'joebloggs' and c1date like '10%'
Not a 'join' insight :-)
I think this is how we all started learning SQL and writing web applications... without normalization. And it won't cause you much grief in simpler use case scenarios with smaller data sizes.
You might take a stab at learning normalization though. It's really quite intuitive, helps keep your tables from "column bloat" and you can offload a lot of the processing to the SQL engine instead of passing unnecessary information from the DB to your app layer and doing processing there. It also forces you to put a little more thought into design and you'll end up with a schema another DBA could look at and not run away scared. :)
My $0.02 anyways!
Ray
Ray Van Dolson wrote:
On Thu, Sep 15, 2011 at 08:51:23PM +0100, Always Learning wrote:
On Thu, 2011-09-15 at 10:42 -0700, John R Pierce wrote:
<SNIP>
Not a 'join' insight :-)
I think this is how we all started learning SQL and writing web applications... without normalization. And it won't cause you much grief in simpler use case scenarios with smaller data sizes.
You might take a stab at learning normalization though. It's really quite intuitive, helps keep your tables from "column bloat" and you can offload a lot of the processing to the SQL engine instead of passing
<snip> First time I was working with SQL, in '91, my manager tried normalizing the tables... with the result that one data file had more key than data in each record, sorry, "row", oops, that's tuple, and it was a HUGE number of rows.
I offered a redesign that had a fixed number of datum, and he took that. Took the number of records vastly down.
Normalization is a torx screwdriver; it doesn't fit all uses.
mark
On 9/16/11, Always Learning centos@u61.u22.net wrote:
C1
c1ref c1customer (code) c1quantity (integers only) c1price (in cents) c1discount (2 decimal places held as integers) c1catalogue (code) c1date (yymmdd) c1order (number) c1comments (text)
then do a query:
select c1quantity, c1price, c1discount from c1 where c1customer = 'joebloggs' and c1date like '10%'
Isn't it bad practise to store customer reference by name? What happens if we want to look up a customer called John Smith and there are say a dozen of them?
I would at the very least have a separate table holding core customer information with an auto-incremented ID so that customers with the same name won't cause a problem. Of course, that would mean requiring a join on the query, or at the very least two queries with one pulling the customer ID first. Although since the base customer ID table is usually a frequently accessed but not changed table, it's likely to be in memory and therefore faster to issue a join, which the dbms should handle smartly enough than to separate queries.
Emmanuel Noobadmin wrote:
On 9/16/11, Always Learning centos@u61.u22.net wrote:
C1
c1ref c1customer (code) c1quantity (integers only)
<snip>
then do a query:
select c1quantity, c1price, c1discount from c1 where c1customer = 'joebloggs' and c1date like '10%'
Isn't it bad practise to store customer reference by name? What happens if we want to look up a customer called John Smith and there are say a dozen of them?
I would at the very least have a separate table holding core customer information with an auto-incremented ID so that customers with the same name won't cause a problem. Of course, that would mean requir
I would, also. Actually, I'd rather have an autogenerated ID, since unless your name's as short as mine, most times the key will be shorter than the name, and faster on lookups.
On the other hand, customer *does* change more frequently than it used to, I'd think: online, you get folks from all over, not just someone in town; then, they may buy once, and that's it, you never hear from them again.
mark
On 09/15/11 12:51 PM, Always Learning wrote:
that data is normalized, there is no redundant data in any of those
tables, they are connected by the relations defined via the references ('foreign keys').
I would not design my orders database exactly like you have.
once again, you completely miss the point, and go off on a tangent explaining how YOU do things, justifying your ignorance.
ignoring the fact that I contrived my example in a few minutes, and it was not intended to be a realistic complete implementation of a order processing system, that same set of normalized tables could be used to generate a result like...
select c.name, c.address, sum(ci.price*oi.qty) from customers c join customerorders co on (co.customer=c.id) join orderlineitem oi on (co.id=oi.catalogid) join catalogitem cati on (cati.id=oi.catalogid) group by c.id;
which would output a list of all customers with their name, address, and total of their sales.
select cati.description, sum(oi.qty) from orderlineitem oi join catalogitem cati on (cati.id=oi.catalogid) group by cati.id order by sum(oi.qty) desc;
would output a list of all catalog items and the total quantity. a slightly more involved query could summarize this by month or by year by customer, etc etc.
Golly Gosh, here we go again.
On Fri, 2011-09-16 at 11:10 -0700, John R Pierce wrote:
On 09/15/11 12:51 PM, Always Learning wrote:
I would not design my orders database exactly like you have.
once again, you completely miss the point, and go off on a tangent explaining how YOU do things, justifying your ignorance.
The point is I write programmes for pleasure. Naturally as an always learning individual, I appraise others' methods and when they seem advantageous and relevant I am likely to use them.
Ignorance, by the way, includes the inability of some to understand the perspective of others!
ignoring the fact that I contrived my example in a few minutes, and it was not intended to be a realistic complete implementation of a order processing system, that same set of normalized tables could be used to generate a result like...
When IBM introduced its Structured Query Language many years ago, it seemed like a helpful facility for end-users who could, using SQL, access they own data fairly quickly rather than wait several weeks for a purposely written computer programme.
You write SQL more like an end-user. I use SQL like a computer programmer and via a programming language called PHP.
I do not propose to use your SQL techniques. I prefer my own.
select c.name, c.address, sum(ci.price*oi.qty) from customers c join customerorders co on (co.customer=c.id) join orderlineitem oi on (co.id=oi.catalogid) join catalogitem cati on (cati.id=oi.catalogid) group by c.id;
which would output a list of all customers with their name, address, and total of their sales.
select cati.description, sum(oi.qty) from orderlineitem oi join catalogitem cati on (cati.id=oi.catalogid) group by cati.id order by sum(oi.qty) desc;
would output a list of all catalog items and the total quantity. a slightly more involved query could summarize this by month or by year by customer, etc etc.
How does a PHP programmer obtain the output, from your examples, in a variable ?
On Fri, Sep 16, 2011 at 09:18:24PM +0100, Always Learning wrote:
The point is I write programmes for pleasure. Naturally as an always learning individual, I appraise others' methods and when they seem advantageous and relevant I am likely to use them.
The point is that absolutely none of this is even remotely CentOS related and is nothing more than just noise on this list. Can you _please_ try to be considerate to the thousands of people that don't give a monkey's behind about any of this and take it elsewhere?
John
John R. Dennison wrote:
On Fri, Sep 16, 2011 at 09:18:24PM +0100, Always Learning wrote:
The point is I write programmes for pleasure. Naturally as an always learning individual, I appraise others' methods and when they seem advantageous and relevant I am likely to use them.
The point is that absolutely none of this is even remotely CentOS related and is nothing more than just noise on this list. Can you _please_ try to be considerate to the thousands of people that don't give a monkey's behind about any of this and take it elsewhere?
Actually, I responded to several, and CHANGED THE SUBJECT, and no one else followed them.
mark
Always Learning wrote:
On Fri, 2011-09-16 at 11:10 -0700, John R Pierce wrote:
On 09/15/11 12:51 PM, Always Learning wrote:
<snip>
When IBM introduced its Structured Query Language many years ago, it seemed like a helpful facility for end-users who could, using SQL, access they own data fairly quickly rather than wait several weeks for a purposely written computer programme.
<snip> As a point of information, it *was* intended for ->managers<- to get reports themselves, rather than waiting weeks, or months, for a program to be written.
Another "cure" for the software backlog. Heh. Heh. Heh....
mark
On Fri, 2011-09-16 at 16:28 -0400, m.roth@5-cent.us wrote:
As a point of information, it *was* intended for ->managers<- to get reports themselves, rather than waiting weeks, or months, for a program to be written.
Another "cure" for the software backlog. Heh. Heh. Heh....
I'm thinking of installing Mailman and calling the first list something like centos.chat@.......
Paul.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Always Learning Sent: Wednesday, September 14, 2011 9:40 PM To: CentOS mailing list Subject: Re: [CentOS] Upgrade from 5.6 => 5.7
On Wed, 2011-09-14 at 18:08 -0700, John R Pierce wrote:
an accounting system thats in plain HTML would be
incredibly clunky to
use. you really want to do this in ajax/jquery or whatever so its more interactive
No thank you. HTML, CSS, PHP and MySQL are my chosen tools for my systems.
I have written 20+ complete systems using these and found them to be fast and very effective. Everyone who has seen my HTML, CSS, PHP, MySQL systems has been favourably impressed (me too!). MySQL is a fast database system. Never ever used a SQL join or view, just well designed databases with carefully planned tables - that is the art of good programming.
Ajax/Jquery is someone else's parametrised programming language. It adds complexity and overhead to what is fundamentally a very basic task. Ajax etc. seem to appeal to people who are not good (or natural) programmers. Ajax etc. is like programming with boxing gloves on and taking several weeks to do it. If they want to use it, let them.
also, I'd suggest using postgresql for better data integrity, and anything-but-php (Python?) for better webside security.
I have been using MySQL on Linux for about 4 years and never had a problem. What security issues has PHP ?
I, like you have been using mysql/php for ecommerce since 2003. Never had and issue except RHEL/CentOS is about a release behind everyone else. Stability is one thing, holding back is another when Fedora is 3 or 4 release ahead. Again, not CentOS's fault.
On 9/15/11, Always Learning centos@u61.u22.net wrote:
I have written 20+ complete systems using these and found them to be fast and very effective. Everyone who has seen my HTML, CSS, PHP, MySQL systems has been favourably impressed (me too!). MySQL is a fast database system. Never ever used a SQL join or view, just well designed databases with carefully planned tables - that is the art of good programming.
So how do you retrieve data that are kept in different tables? Or do you simply replicate the same data in every single table that needs it?
Ajax/Jquery is someone else's parametrised programming language. It adds complexity and overhead to what is fundamentally a very basic task. Ajax etc. seem to appeal to people who are not good (or natural) programmers. Ajax etc. is like programming with boxing gloves on and taking several weeks to do it. If they want to use it, let them.
While I'd agree with you somewhat on jQuery and frameworks, AJAX isn't the same thing. It's just a style of user interface that does make the application more user-friendly. After all, in the hypothetical accounting program, wouldn't typing a few letters in the invoicing page to start displaying a list of possible customers be more efficient than having to go to a separate search page to list and select a customer?
also, I'd suggest using postgresql for better data integrity, and anything-but-php (Python?) for better webside security.
I have been using MySQL on Linux for about 4 years and never had a problem. What security issues has PHP ?
In my largely unresearched opinion, the same security issues that any server side language might have: careless or naive programmers.
Emmanuel Noobadmin wrote:
On 9/15/11, Always Learning centos@u61.u22.net wrote:
I have written 20+ complete systems using these and found them to be fast and very effective. Everyone who has seen my HTML, CSS, PHP, MySQL systems has been favourably impressed (me too!). MySQL is a fast database system. Never ever used a SQL join or view, just well designed databases with carefully planned tables - that is the art of good programming.
So how do you retrieve data that are kept in different tables? Or do you simply replicate the same data in every single table that needs it?
I've done a lot of what we used to call embedded SQL, and when I did do a join, it was *not* an explicit join. I've also used right or left once? twice? ever? But then, I carefully design and code my queries. One place I worked, someone else would run a query, and it would bring a server to its knees: I and a co-worker looked at it at one point, and it was a nightmare of joins, multiple references, etc, etc.
But then, third normal form is, in general, idiotic except in the design phase. After you've decided on individual data, then collect them into records (oh, sorry, I'll have to do penance for not using the correct theological term, tubles). One table for one major set of info, and a key or two across several. Classic is an entire year's monthly payments for one customer on *one* record, not 12 records, as it would be in third normal.
mark
On 9/16/11, m.roth@5-cent.us m.roth@5-cent.us wrote:
I've done a lot of what we used to call embedded SQL, and when I did do a join, it was *not* an explicit join. I've also used right or left once? twice? ever? But then, I carefully design and code my queries.
So it's more like a series of "select a,b,c from x where d=y", then "select a2,b2,c2 from x2 where z=a"? I'm just curious, not that I think it's wrong because I'm actually leaning towards this. There were many occasions where I find that breaking up complex queries and doing filtering within my code was faster than trusting the dbms to optimize the query.
One place I worked, someone else would run a query, and it would bring a server to its knees: I and a co-worker looked at it at one point, and it was a nightmare of joins, multiple references, etc, etc.
I had that kind of experience before, nightmare to figure out exactly what the original coder was trying to do and a performance hell.
But then, third normal form is, in general, idiotic except in the design phase. After you've decided on individual data, then collect them into records (oh, sorry, I'll have to do penance for not using the correct theological term, tubles).
lol, despite my "formal" education, I never got used to calling them "tuples". It just sounds too much like a nonsense word to me, and it confuses the hell out of most people compared to "records" and "rows".
One table for one major set of info, and a key or two across several. Classic is an entire year's monthly payments for one customer on *one* record, not 12 records, as it would be in third normal.
I'm actually leaning towards highly normalized schema but instead of doing joins in queries, I'd do it in my application code. I haven't formally tested and benchmarked things but it would seem that getting the dbms to return 10 matching rows from a 1 million row table of say 100 bytes rows, then calling for 10 records matching those rows out of another 1 million 1KB rows, is going to be a lot faster than letting the dbms attempt to create a 1 million 100bytes x 1 million KB product just to pull those same 10 rows. Unless the dbms' internal optimization logic works every time. Maybe somebody with better understanding of mysql/postgresql innards can shed some light on this.
On Fri, 2011-09-16 at 00:56 +0800, Emmanuel Noobadmin wrote:
So how do you retrieve data that are kept in different tables? Or do you simply replicate the same data in every single table that needs it?
No unnecessary replication because it wastes space and needs multiple updates. A customer number would be stored in an invoice header record and in a customer name and address record.
Data is generally stored once. However because of legal requirements a customer's invoicing name and address and delivery address will be copied from the customer file and permanently stored in an invoice's header record. This means when the customer's record details are changed, the invoice continues to show the original name and address data valid at the time of creating that invoice.
Each table as a unique reference number.
A simple retrieval illustration ...
select * from p2 where p2ref = '$p1ref' ....
select p3surname, p3forename, p3add1, p3add2, p3add3, p3add4 (etc) from p3 where p3customer = '$e7customer' ....
select w1note from w1 where w1date = '$s5date' ....
Paul.
On 9/16/11, Always Learning centos@u61.u22.net wrote:
Data is generally stored once. However because of legal requirements a customer's invoicing name and address and delivery address will be copied from the customer file and permanently stored in an invoice's header record. This means when the customer's record details are changed, the invoice continues to show the original name and address data valid at the time of creating that invoice.
Each table as a unique reference number.
A simple retrieval illustration ...
select * from p2 where p2ref = '$p1ref' ....
select p3surname, p3forename, p3add1, p3add2, p3add3, p3add4 (etc) from p3 where p3customer = '$e7customer' ....
select w1note from w1 where w1date = '$s5date' ....
This looks rather similar to what I am doing nowadays instead of massive queries with sub-selects. Glad to see I'm not alone in this direction. Hopefully this is a case of great minds think alike than fools seldom differs! :D
On Fri, 2011-09-16 at 01:41 +0800, Emmanuel Noobadmin wrote:
On 9/16/11, Always Learning centos@u61.u22.net wrote:
select w1note from w1 where w1date = '$s5date' ....
This looks rather similar to what I am doing nowadays instead of massive queries with sub-selects. Glad to see I'm not alone in this direction. Hopefully this is a case of great minds think alike than fools seldom differs! :D
It is surprising that some 'computer people' lack a logical insight into their own work. One 'expert' wrote a single Cobol IF statement spanning 10 and a bit pages. 60 printed coding lines per page. He thought that was 'great'. I shuddered and thought it was stupid.
At the same place, Schiphol Airport (Amsterdam), I was asked NOT to make my programmes user-friendly and to remove user-friendly features from my programmes because "If the users see them, they will ask us to put your user-friendly improvements in our programmes".
The applications I wrote carried data from one screen to the next screen and saved the worker having to re-enter the data. NVLS (the airport authority) staff wanted their old system retained - the user having to copy onto a piece of paper the essential data and type it in on the next screen. There was I thinking I had done a good job and the next minute I was told to programme like a moron.
Sometimes well-paid contract work can make the contractor feel like a prostitute. Does one object to utter stupidity and walk-out or abandon one's principals and stay ?
Paul.
Always Learning wrote:
On Fri, 2011-09-16 at 01:41 +0800, Emmanuel Noobadmin wrote:
On 9/16/11, Always Learning centos@u61.u22.net wrote:
<snip>
It is surprising that some 'computer people' lack a logical insight into their own work. One 'expert' wrote a single Cobol IF statement spanning 10 and a bit pages. 60 printed coding lines per page. He thought that was 'great'. I shuddered and thought it was stupid.
Oh, *Ghu*. <shakes head> I left behind at several jobs CICS code that had in it PERFORM 1000-DUMMY-PARAGRAPH THROUGH 1000-DUMMY-PARAGRAPH EXIT WHILE <an entire while loop, that may actually have called another subroutine>, just to make up for COBOL's shortage of control structures (for/next, while). PL/1 was nicer, and when I got to C, I thought I'd gone to heaven....
I've seen code like you mention. A number of years ago, I was brought in to program. The place's code was all in perl, which my manager had written. He had most of his EE, and hadn't studied programming... and it showed. I rewrote 600 or 1000 lines of code that were straight line spaghetti into clean, modular stuff, and as I did it, he was clearly studying what I did (I know, because I saw he'd copied one brief date routine into a program he was working on).
Remember, even among those who studied, a) half of them were in the bottom of their class, and b) too many are True Believers in the latest programming (not the P word!) paradigm; y'know, recursion is the answer to *everything*, or OO, or....
At the same place, Schiphol Airport (Amsterdam), I was asked NOT to make my programmes user-friendly and to remove user-friendly features from my programmes because "If the users see them, they will ask us to put your user-friendly improvements in our programmes".
The applications I wrote carried data from one screen to the next screen and saved the worker having to re-enter the data. NVLS (the airport authority) staff wanted their old system retained - the user having to copy onto a piece of paper the essential data and type it in on the next screen. There was I thinking I had done a good job and the next minute I was told to programme like a moron.
And they want to *guarantee* that more errors will come in.
Sometimes well-paid contract work can make the contractor feel like a prostitute. Does one object to utter stupidity and walk-out or abandon one's principals and stay ?
I think I'd work my way up management... and/or look for another job.
mark "actually, did that"
On 9/16/11, m.roth@5-cent.us m.roth@5-cent.us wrote:
Remember, even among those who studied, a) half of them were in the bottom of their class, and b) too many are True Believers in the latest programming (not the P word!) paradigm; y'know, recursion is the answer to *everything*, or OO, or....
Part of the problem is sometimes otherwise intelligent customers who heard of the latest buzzword be it XML/Ruby/Web 2.0/HTML5 start demanding that you use it for their application regardless of whether it's relevant or if they really know what it is about . If you try to educate them any other way, they start thinking you're outdated.
On top of that, sometimes you have to work with people who are True Believers or Purists...
On Sat, Sep 17, 2011 at 2:37 PM, Emmanuel Noobadmin centos.admin@gmail.com wrote:
On 9/16/11, m.roth@5-cent.us m.roth@5-cent.us wrote:
Remember, even among those who studied, a) half of them were in the bottom of their class, and b) too many are True Believers in the latest programming (not the P word!) paradigm; y'know, recursion is the answer to *everything*, or OO, or....
Part of the problem is sometimes otherwise intelligent customers who heard of the latest buzzword be it XML/Ruby/Web 2.0/HTML5 start demanding that you use it for their application regardless of whether it's relevant or if they really know what it is about . If you try to educate them any other way, they start thinking you're outdated.
Well, you can always lie to those people. :-)
I had a situation once when a client asked me to implement something fairly trivial, but insisted that I use C++ (overkill would be an understatement here...). Namely, they heard from some "expert" that all "real programming" is done in C++... Naturally, I implemented the solution as a bash script, and just told them "sure, no problem, it is pure C++". They had no interest (nor the knowledge) to check it, and everyone was happy. :-)
I tend to develop a relationship with clients where they trust my decisions, so lying to them for their own benefit now and then doesn't hurt, and I don't consider it too unethical.
I also remember the situation where one client received that typical "somefile.exe is a virus" hoax e-mail (Windows users, of course), and insisted that I check and "disinfect" all machines on the premises. There was no point in trying to explain that such e-mails are hoaxes and that the issue is nonexistent. Instead, I just told him "sure, I'll get right on it", and then did absolutely nothing about it. The guy didn't know how to check the presence of a file himself, so tomorrow when he asked me about "the threat", I just replied that all machines have been disinfected and there is nothing to worry about anymore. He went on to commend my prompt reaction to others... ;-)
There are lots of such anecdotes. Being a sysadmin is a social skill as much as a technical one. ;-)
Best, :-) Marko
On Thu, 15 Sep 2011, Always Learning wrote:
*snip*
Sometimes well-paid contract work can make the contractor feel like a prostitute. Does one object to utter stupidity and walk-out or abandon one's principals and stay ?
I gues it depends on how much the hourly rate is ;)
Kind Regards,
Keith
----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
Keith Roberts wrote:
On Thu, 15 Sep 2011, Always Learning wrote:
*snip*
Sometimes well-paid contract work can make the contractor feel like a prostitute. Does one object to utter stupidity and walk-out or abandon one's principals and stay ?
I gues it depends on how much the hourly rate is ;)
It depends on your ethics.
I've had to relocate 5 times in my life, halfway across the US each time, leaving folks behind. The last time, in '09, with the depression in full swing, I had a choice of staying in Chicago, and taking a third shift job for six months or a year (before they'd let me shift to day), supporting trading firms (that is, rich or wannabe rich assholes do their best to get richer by screwing everyone else), that might eventually have been a lot more money, or taking a good salary working for a federal contractor, and having to relocate *again*, this time to DC.
I'm in DC. I'm doing something useful to society, and not prostituting myself.
mark
On Wed, 2011-09-14 at 18:08 -0700, John R Pierce wrote:
On 09/14/11 6:03 PM, Thomas Dukes wrote:
One day, if I have time, I want to programme a complete
commercial accounts systems using HTML, PHP and MySQL. Its a piece of cake to do well (meaning easily) but a little time consuming. The only difficulty I can think of is printing things locally.
I love the challenge. I'm a hacker from way back. While this sort of stuff isn't humorous now days and since I've 'grown up', I understand why. Still, I love it!!
an accounting system thats in plain HTML would be incredibly clunky to use. you really want to do this in ajax/jquery or whatever so its more interactive
also, I'd suggest using postgresql for better data integrity, and anything-but-php (Python?) for better webside security.
---- to each his own...
I put my customer on WebERP (http://www.weberp.com)
He has used in the last 15 years... Real World Accounting (since bought by Great Plains - bought by MS) Peachtree Accounting BusinessWorks Cougar Mountain Demand
I handled all of the data import/transitions from one to the next with the exception of Cougar Mountain => Demand because the woman who sold him on that was a previous technical support manager for Cougar Mountain.
Anyway, the one he has liked the most is the one that he didn't pay for - WebERP
Before anyone gets the idea that this is all wine and roses, there are some shortcomings with WebERP, largely due to the fact that they seem to do continual releases and never really have a 'stable' version (regardless of what they say). That meant to me that I had to fix about 10-15 different things and needless to say I have no intentions of upgrading at this point (now 2+ years down the road). I have more gripes about WebERP but they are not entirely significant (with the exception that to 'extend' the featureset of WebERP, I used Ruby on Rails instead of PHP because I can do significantly better code in one quarter of the time).
WebApps are clearly the future - it's hard to justify specialized server/client applications (installation, limited choice of clients, maintenance, licensing) and it seems that the future will offer 2 choices... SAAS or run your own.
My own take on it... 'plain html' accounting is just fine. This company has 4 retail stores, each with a warehouse and relatively low skilled computer users entering orders. Print jobs are downloaded (or e-mailed PDF files). This is NOT a POS system (then again, neither is Quickbooks). To keep the PHP reasonably secure, it requires HTTPS and access authorization is done by LDAP authz so if you don't have a username and password on his system, you can't get the login screen. Of course the server is kept up to date.
Ajax/jquery definitely ups the quality of appearance, sometimes ups the quality of the UI but definitely slows down the application and is just another demonstration of all that glitters isn't necessarily gold.
As for Paul's expressed notions... It would take a fairly massive amount of man hours to produce a fully functional dual entry accounting package for widespread business use. Before you decide on an environment, you would probably want to commit to test driven development and MVC which almost invites the use of a framework (Cake/Django/RoR). Personally I am biased towards RoR but starting a large scale project in ruby, php or python without using one of the frameworks at this point would be a really poor choice. There are a number of PHP based accounting systems out there which you could probably fork but why? They all missed the boat somewhere, somehow.
Craig
On Wed, 2011-09-14 at 19:17 -0700, Craig White wrote:
... snip interesting posting ....
WebApps are clearly the future - it's hard to justify specialized server/client applications (installation, limited choice of clients, maintenance, licensing) and it seems that the future will offer 2 choices... SAAS or run your own.
That is the way I see things. Web runs anywhere. Otherwise specific application software (usually costing money), licensing involvement, software dependency etc. Grab a reasonable browser and start using the application!
My own take on it... 'plain html' accounting is just fine.
Mine are a bit more than 'plain'. I use CSS. However accounting is basically entering or capturing the data; then doing basic tasks like orders, invoices, statements etc. Add some complicated things like credit control and specific discount structures for individual customers. Branch-out in to name, address and other contract details, add the mailing list facility. Add stock control, automatic re-ordering etc.
The best bits that make the directors happy is when they can sit in front of the screen and see the sales figures and trends. Everything summarised on a single page with more detailed analyse with a simple click. Think Gmagic, or perhaps Imagic, may be able to plot on a HTML screen.
Have headings in a language file, so international customisation becomes easier. Add an access control system allowing users to access different modules and menus.
OK one can't (yet?) plug-in a bar code reader to a web application but an interface box can transmit the data using TCP.
To keep the PHP reasonably secure, it requires HTTPS and access authorization is done by LDAP authz so if you don't have a username and password on his system, you can't get the login screen. Of course the server is kept up to date.
Agreed. Security with HTTPS and non-standard ports not 443, 8000, 8080 etc. Currently use static IPs to prevent unauthorised access.
As for Paul's expressed notions... It would take a fairly massive amount of man hours to produce a fully functional dual entry accounting package for widespread business use.
I think the essential thing is sheer inspirational brain work carefully thinking about everything before stating to code. Get the structure and the objectives correct and the rest is a piece of cake. And be prepared to modify.
Before you decide on an environment, you would probably want to commit to test driven development and MVC which almost invites the use of a framework (Cake/Django/RoR). Personally I am biased towards RoR but starting a large scale project in ruby, php or python without using one of the frameworks at this point would be a really poor choice. There are a number of PHP based accounting systems out there which you could probably fork but why? They all missed the boat somewhere, somehow.
Unsure what you mean by 'framework'.
Simple to write, harder to ensure everything integrates well. Probably 3 to 4 months part-time. Easy and intuitive to use and delivering what the users want plus scope for customisation.
On Thu, 2011-09-15 at 04:07 +0100, Always Learning wrote:
On Wed, 2011-09-14 at 19:17 -0700, Craig White wrote:
... snip interesting posting ....
WebApps are clearly the future - it's hard to justify specialized server/client applications (installation, limited choice of clients, maintenance, licensing) and it seems that the future will offer 2 choices... SAAS or run your own.
That is the way I see things. Web runs anywhere. Otherwise specific application software (usually costing money), licensing involvement, software dependency etc. Grab a reasonable browser and start using the application!
My own take on it... 'plain html' accounting is just fine.
Mine are a bit more than 'plain'. I use CSS. However accounting is basically entering or capturing the data; then doing basic tasks like orders, invoices, statements etc. Add some complicated things like credit control and specific discount structures for individual customers. Branch-out in to name, address and other contract details, add the mailing list facility. Add stock control, automatic re-ordering etc.
The best bits that make the directors happy is when they can sit in front of the screen and see the sales figures and trends. Everything summarised on a single page with more detailed analyse with a simple click. Think Gmagic, or perhaps Imagic, may be able to plot on a HTML screen.
---- evidently not knowing what you are talking about and not ever having actually done anything like it does not represent a barrier for you to express your opinion on a subject...
Gmagic/Imagick are somewhat incapable of doing graphing at all. You would likely use a flash or google charts implementation these days to generate graphs as there are all sorts of libraries that make this dead simple. ----
Before you decide on an environment, you would probably want to commit to test driven development and MVC which almost invites the use of a framework (Cake/Django/RoR). Personally I am biased towards RoR but starting a large scale project in ruby, php or python without using one of the frameworks at this point would be a really poor choice. There are a number of PHP based accounting systems out there which you could probably fork but why? They all missed the boat somewhere, somehow.
Unsure what you mean by 'framework'.
---- Framework is the core of any application. It's well known terminology for anyone who has done software development... http://en.wikipedia.org/wiki/Software_framework
If you don't adopt an existing framework, then you have to create your own framework as your application develops sucking an inordinate amount of time and given to endless refactoring as your application evolves.
Recognize that by admitting you were unsure of what a framework is w/r/t software development provides a clear recognition that you really don't have any experience with software development.
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Anyone who has developed software that embraces MVC will never want to work on a project that doesn't. ----
Simple to write, harder to ensure everything integrates well. Probably 3 to 4 months part-time. Easy and intuitive to use and delivering what the users want plus scope for customisation.
---- I'm sort of done with this thread. No reason to try to seriously discuss something with someone who knows nothing about what they write.
Craig
On Thu, 2011-09-15 at 05:16 -0700, Craig White wrote:
Gmagic/Imagick are somewhat incapable of doing graphing at all.
Have you ever really looked ? What about GmagickDraw::point and similar items ?
You would likely use a flash or google charts implementation these days to generate graphs as there are all sorts of libraries that make this dead simple.
No Flash. It is a known security danger and stores, without the user's knowledge and permission, files on the user's hard disk which are not removed by normal browser behaviour. If it can be done, I prefer to do it with PHP. Open Source HTML 5 should replace Flash.
Framework is the core of any application. It's well known terminology for anyone who has done software development... http://en.wikipedia.org/wiki/Software_framework
Untrue. The 'framework' seems like a nightmare ....
"... software frameworks consist of frozen spots and hot spots ...
"... Hot spots represent those parts where the programmers using the framework add their own code to add the functionality specific to their own project....
"... Software frameworks define the places in the architecture where application programmers may make adaptations for specific functionality— the hot spots.
"... Without a framework though, "there is no such thing as a component"
"... consists of abstract and concrete classes ...
"... framework consists of composing and subclassing ...
"... When developing a concrete software system with a software framework, developers utilize the hot spots according to the specific needs and requirements of the system.
"... Software frameworks rely on the Hollywood Principle: "Don't call us, we'll call you."[12] This means that the user-defined classes (for example, new subclasses), receive messages from the predefined framework classes. Developers usually handle this by implementing superclass abstract methods."
NO THANKS. Frameworks is certainly not for me. It seems like a gigantic and over-complicated time-waster.
If you don't adopt an existing framework, then you have to create your own framework as your application develops sucking an inordinate amount of time and given to endless refactoring as your application evolves.
Disagree. 'Keep it Simple' is my preference. Don't complicate things. Framework crap is probably why so many multi-million pounds or dollars computer projects fail so abysmally. In Britain the public sector is littered with them, while computer companies make millions and millions of pounds profit from failed projects.
Recognize that by admitting you were unsure of what a framework is w/r/t software development provides a clear recognition that you really don't have any experience with software development.
I have 44 years computer programming experience. I have seen enormous amounts of time-wasting, and usually money generating, crap with wonderful names and impressive waffle, presented by men wearing very expensive new suits and ultra shinny black shoes. Sometimes they offer bribes to get the contract. I have developed a basic aversion to anything which creates an unnecessary complication or overhead.
Perhaps you really lack a clear understanding about the Art of Programming effectively and efficiently. Frameworks is just another complicated idea which slows application development and costs unnecessary sums of money.
I am honest about computers. I have no intention of claiming I know about 'frameworks' when I do not. Many so-called 'computer experts' routinely lie and talk in jargon to conceal their limited understanding.
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Anyone who has developed software that embraces MVC will never want to work on a project that doesn't.
Here we go again .....
"Though MVC comes in different flavors, control flow is generally as follows:
1. The user interacts with the user interface in some way (for example, by pressing a mouse button). 2. The controller handles the input event from the user interface, often via a registered handler or callback, and converts the event into an appropriate user action, understandable for the model. 3. The controller notifies the model of the user action, possibly resulting in a change in the model's state. (For example, the controller updates the user's shopping cart.)[4] 4. A view queries the model in order to generate an appropriate user interface (for example the view lists the shopping cart's contents). The view gets its own data from the model. In some implementations, the controller may issue a general instruction to the view to render itself. In others, the view is automatically notified by the model of changes in state (Observer) that require a screen update. 5. The user interface waits for further user interactions, which restarts the control flow cycle."
Among other things, I just write programmes. Why would I want to refer to the above when designing, writing and testing systems ? Remember what I wrote about an aversion to complication et cetera and keeping things simple ? Perhaps the less-well-informed need to be told what is the objective of writing programmes and how a programme should interface with users.
I'm sort of done with this thread. No reason to try to seriously discuss something with someone who knows nothing about what they write.
Please do not denigrate yourself. You might eventually learn what computer programming, systems design and end-user satisfaction is really about.
On Thu, 15 Sep 2011, Always Learning wrote:
On Thu, 2011-09-15 at 05:16 -0700, Craig White wrote:
Gmagic/Imagick are somewhat incapable of doing graphing at all.
Have you ever really looked ? What about GmagickDraw::point and similar items ?
I think the risk of the KISS approach is that you tend to reimplement everything, because everything everyone else has done is overcomplicated.
It's not that you *can't* do all this yourself, but that you're possibly dealing with life at a layer or two lower than you might. Simply by using an existing library (say jpgraph, but it's chosen at random) you get a load of functionality (that gets improved over time) without having to implement any of it yourself. You're not simply producing a graph, you're producing code that draws a graph and then drawing a graph. Why write the code?
I much prefer other people's bugs to my own, as there's a chance they'll fix it, or failing that, I can fix their bug and the world's a better place.
jh
John Hodrien wrote:
On Thu, 15 Sep 2011, Always Learning wrote:
On Thu, 2011-09-15 at 05:16 -0700, Craig White wrote:
Gmagic/Imagick are somewhat incapable of doing graphing at all.
Have you ever really looked ? What about GmagickDraw::point and similar items ?
I think the risk of the KISS approach is that you tend to reimplement everything, because everything everyone else has done is overcomplicated.
The "danger" of KISS approach? So, you endorse complex and complicated schemes? And here I thought that the True Believers in OO asserted that OOP was cleaner, simpler, and easier. <snip> mark
In article b0189c04b5d9a25bd50d4ceacf479b79.squirrel@mail.5-cent.us, m.roth@5-cent.us wrote:
John Hodrien wrote:
On Thu, 15 Sep 2011, Always Learning wrote:
On Thu, 2011-09-15 at 05:16 -0700, Craig White wrote:
Gmagic/Imagick are somewhat incapable of doing graphing at all.
Have you ever really looked ? What about GmagickDraw::point and similar items ?
I think the risk of the KISS approach is that you tend to reimplement everything, because everything everyone else has done is overcomplicated.
The "danger" of KISS approach? So, you endorse complex and complicated schemes? And here I thought that the True Believers in OO asserted that OOP was cleaner, simpler, and easier.
As Einstein said once: "Make everything as simple as possible, but not simpler."
More to the point would be: "Judging something *solely* on its simplicity is an overly simplistic approach." -- Kiel Hodges. This appears to me to be the trap that Paul Always Learning has fallen into.
Cheers Tony
On Thu, 2011-09-15 at 14:30 +0000, Tony Mountifield wrote:
More to the point would be: "Judging something *solely* on its simplicity is an overly simplistic approach." -- Kiel Hodges. This appears to me to be the trap that Paul Always Learning has fallen into.
Judge my systems on their:-
1. functionality (i.e. doing what is required) 2. speed 3. ease of use 4. ease of maintenance
In article 1316097747.32765.118.camel@m6.u226.com, Always Learning centos@u61.u22.net wrote:
On Thu, 2011-09-15 at 14:30 +0000, Tony Mountifield wrote:
More to the point would be: "Judging something *solely* on its simplicity is an overly simplistic approach." -- Kiel Hodges. This appears to me to be the trap that Paul Always Learning has fallen into.
Judge my systems on their:-
- functionality (i.e. doing what is required)
- speed
- ease of use
- ease of maintenance
I can't do that, since I know nothing about them. All I can judge are the comments you make here, such as your apparently simplistic view of SQL and relational databases. For example, joins and views are efficient and powerful if used correctly with a properly-designed database, and relieve the application code of a lot of complexity, reinvented wheels and scope for errors. Describing such constructs as merely a complex overhead betrays a lack of understanding and a reluctance to continue "always learning".
Cheers Tony
Tony Mountifield wrote:
In article b0189c04b5d9a25bd50d4ceacf479b79.squirrel@mail.5-cent.us, m.roth@5-cent.us wrote:
John Hodrien wrote:
On Thu, 15 Sep 2011, Always Learning wrote:
On Thu, 2011-09-15 at 05:16 -0700, Craig White wrote:
Gmagic/Imagick are somewhat incapable of doing graphing at all.
Have you ever really looked ? What about GmagickDraw::point and similar items ?
I think the risk of the KISS approach is that you tend to reimplement everything, because everything everyone else has done is overcomplicated.
The "danger" of KISS approach? So, you endorse complex and complicated schemes? And here I thought that the True Believers in OO asserted that OOP was cleaner, simpler, and easier.
As Einstein said once: "Make everything as simple as possible, but not simpler."
More to the point would be: "Judging something *solely* on its simplicity is an overly simplistic approach." -- Kiel Hodges. This appears to me to be the trap that Paul Always Learning has fallen into.
I think you don't know enough of Paul's (or my) style to suggest that he's fallen into any trap.
And my style, for stuff that's intended to be permanent, is aimed at elegance, not cleverness. Cleverness is defined as that 02:00 or Fri, 16:45 phone call, followed by hours of "what the hell did I do last year?". Elegance, and KISS, is fixing the problem and going back to sleep or leaving on time.
mark
On Thu, 2011-09-15 at 14:42 +0100, John Hodrien wrote:
I think the risk of the KISS approach is that you tend to reimplement everything, because everything everyone else has done is overcomplicated.
I share coding within systems (because it means just a single alternation each time) and have general routines available to all applications. My definition of programming efficiency excludes senseless re-implementations of coding.
It's not that you *can't* do all this yourself, but that you're possibly dealing with life at a layer or two lower than you might. Simply by using an existing library (say jpgraph, but it's chosen at random) you get a load of functionality (that gets improved over time) without having to implement any of it yourself. You're not simply producing a graph, you're producing code that draws a graph and then drawing a graph. Why write the code?
In this instance I would use a GMagick Draw function from with a routine. The PHP coding would be minimal and straight-forward.
Paul.
Top note: I missed this whole thread, being on the east coast of the US, and it came in overnight.
Always Learning wrote:
On Thu, 2011-09-15 at 05:16 -0700, Craig White wrote:
<snip>
You would likely use a flash or google charts implementation these days to generate graphs as there are all sorts of libraries that make this dead simple.
No Flash. It is a known security danger and stores, without the user's
Flash, for reports? That's like the VeryLargeCorporate website I saw a few years ago, that had a bloody FLASH VIDEO on the search page for jobs, with some actress (or HR person) telling me about their "hot jobs" (gee, I'm know nothing about that field, but it's Hot, so I think I'll apply!!!)
Not good enough for Hollywood or the ad agencies, so they want to make video for NO good reason. Style over content.
Framework is the core of any application. It's well known terminology for anyone who has done software development... http://en.wikipedia.org/wiki/Software_framework
Untrue. The 'framework' seems like a nightmare ....
I agree. Why use a framework when you just need to know what library functions to call.
This is, in fact, a part of my rant, which I will someday write as a paper, on the failure of OOP (Jan, 1994: IEEE Spectrum cover, where OOP was *literally* presented as the silver bullet to the software backlog).
In short: you want a clipping from Godzilla's toenail, and, using OOP and frameworks, you call in Godzilla, and put a frame around his (her?) toenail.
Looking up the word "bloatware" is left as an exercise for the reader. <snip>
"... Software frameworks rely on the Hollywood Principle: "Don't call us, we'll call you."[12] This means that the user-defined classes (for example, new subclasses), receive messages from the predefined framework classes. Developers usually handle this by implementing superclass abstract methods."
NO THANKS. Frameworks is certainly not for me. It seems like a gigantic and over-complicated time-waster.
Ah, yes. About 5 years ago, I was teaching myself java, and using, um, swing? struts? I forget, and trying to get information out of a whatsit that controlled a button was like trying to scratch your ear by reaching between your legs. IIRC, I had to define a bloody *global* to get info out, which violates *every* part of OOP, and even good programming.
If you don't adopt an existing framework, then you have to create your own framework as your application develops sucking an inordinate amount of time and given to endless refactoring as your application evolves.
Disagree. 'Keep it Simple' is my preference. Don't complicate things.
Right. Write a main line, add stubs, put library calls in stubs. Unless you write spaghetti code, you're not talking more than, say, 100 lines of main line. So, how's that "an inordinate amount of time" creating a framework? You do have to sit and think, first.... <snip>
I have 44 years computer programming experience. I have seen enormous
Beat me - I "only" started doing it for a living in 1980 (after two years of classes). <snip> mark, KISS
On Thursday, September 15, 2011 09:08 AM, John R Pierce wrote:
On 09/14/11 6:03 PM, Thomas Dukes wrote:
One day, if I have time, I want to programme a complete
commercial accounts systems using HTML, PHP and MySQL. Its a piece of cake to do well (meaning easily) but a little time consuming. The only difficulty I can think of is printing things locally.
I love the challenge. I'm a hacker from way back. While this sort of stuff isn't humorous now days and since I've 'grown up', I understand why. Still, I love it!!
an accounting system thats in plain HTML would be incredibly clunky to use. you really want to do this in ajax/jquery or whatever so its more interactive
also, I'd suggest using postgresql for better data integrity, and anything-but-php (Python?) for better webside security.
How about perl with postgresql? sql-ledger - double entry goodness. Sure shorts out my brain when I try to contemplate creating the COA,
On Thu, 15 Sep 2011, Always Learning wrote:
One day, if I have time, I want to programme a complete commercial accounts systems using HTML, PHP and MySQL. Its a piece of cake to do well (meaning easily) but a little time consuming. The only difficulty I can think of is printing things locally.
Have you considered using sqlite3 for this Paul?
http://www.youtube.com/watch?v=giAMt8Tj-84
Kind Regards,
Keith
----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
On Thu, 15 Sep 2011, Keith Roberts wrote:
To: CentOS mailing list centos@centos.org From: Keith Roberts keith@karsites.net Subject: Re: [CentOS] Upgrade from 5.6 => 5.7
On Thu, 15 Sep 2011, Always Learning wrote:
One day, if I have time, I want to programme a complete commercial accounts systems using HTML, PHP and MySQL. Its a piece of cake to do well (meaning easily) but a little time consuming. The only difficulty I can think of is printing things locally.
Have you considered using sqlite3 for this Paul?
I'd also suggest taking a look at PHP Smarty Template Engine, which allows you to cleanly seperate the back-end programming logic, from the Web Browser HTML display code.
http://www.smarty.net/crash_course
HTH
Keith
----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
Always Learning wrote:
What did you expect ? Its not Windoze ;-)
Hrm. In an effort to pull this thread back onto topic, instead of a "my IBM DB2 database is better than your mysql junk anyday" thread, let's look back at various known issues over each release cycle;
5.1 - http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.1#head-da845ab1cd8fc5296... * Kernel had known issues regarding autofs and nfs * Typo in /etc/X11/xinit/Xsession * nautilus-sendto has a require for libgaim.so.0., which no longer existed in the CentOS-5 tree
5.2 - http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.2#head-447967c60eb305ef2... *The nss_ldap package is broken with bash 3.2 (command substitution), causing substitution errors and prevents su - <any_ldap_user> from working. * upgrading bind-chroot where the bind update overwrites any of the user's custom settings like ROOTDIR=/some/other/path with the default ROOTDIR * performance issue with 3ware controllers * known issue with the kernel that prevents it from booting.
5.3 - http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.3#head-198f803bc13b52348... * Known issue with rpm and glibc updates that required a specific upgrade path. * you need to uninstall openmpi and lam before you can update * ntfs code was broken, resulting in centosplus kernel not being able to be shiped with ntfs enabled. * 5.3 would crash immediately after install on certain virtualisation platforms.
5.4 - http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.4#head-29511ff6659f6463d... * known issues with the glibc version and incompatibility under vmware. * the typo in /etc/X11/xinit/Xsession from 5.1 resurfaces * intel video cards would blank screen following the update, requiring editing of the xorg.conf and a restart. * More known updates to glibc, yum, rpm and python requiring a specific update sequence.
5.5 - http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.5#head-2dd2d2fe0b1675dbb... * issues with Virtualbox compatibilty during the upgrade * nvidia drivers are not compatible with updated system * More intel video card breakage * LDAP was lobotomised, requiring configuration changes to operate * Performance issues with nvidia controllers resulting in sluggish and limited performance. * yep, you guessed it, More known updates to glibc, yum, rpm and python requiring a specific update sequence.
5.6 - http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.6#head-60758eb5ab66c94f9... * httpd would not start after an update due to ssl and mod_nss issues * scsi-target-utils broke iscsi mounts for large disks, requiring a downgrade to 5.5 packages to function properly * changes to the configuration files for file-backed KVM machines * the version of nspr-devel shipped with 5.6 was older than that in 5.5 updates * potential issues with subversion package * kernel errors on some platforms where the system had more than 3Gb ram. * Yay! More known updates to glibc, yum, rpm and python requiring a specific update sequence
So, what can wrong? Quite a bit.
Yes, the 'known issues' section on the 5.7 release notes is pretty barren, but that doesn't mean that there aren't any bugs at all in the product, waiting to bite someone who blindly charged into their update crying "Sod off with the backups, we're not using Microsoft products here" and run 'yum -y update'.
Steve
-
Always Learning -
Christopher Chan -
Craig White -
Emmanuel Noobadmin -
John Hodrien -
John R Pierce -
John R. Dennison -
Keith Roberts -
m.roth＠5-cent.us -
Marko Vojinovic -
Ray Van Dolson -
Steve Walsh -
Thomas Dukes -
tony＠softins.co.uk