You don't need drivers or the OS to provide support for encryption. Any of that can be written proprietarily, and in much less time than it would take to write a whole embedded OS. The only reason I suggested any Linux or BSD flavor is because of their typical "everything shut off unless you need it" state.
You're absolutely right.. I should have clarified that further. The MS ANSI set is 8-bit while the real ANSI set is only 7. Sorry if I caused any confusion.
That's true, and we did find a workaround. The workaround was to set up initial tablespace at 1MB and EXTENTS at the same size. Fragmentation never occurs now. We take up extra drive space, but space is cheap (same arguement folks make about taking too many clocks in code.. Moore's law will fix that for you, yada yada).
I don't want to sound like an M$ zealot, but SQL Server handles all of this seamlessly. I have a very hard time imagining why folks use Oracle over SQL Server, other than the ability to run it on UNIX boxes.
You're so right. There was a time when that was the status-quo, but it's cheaper to set up an old pc with (insert your own OS here) than to write/support your own embedded system. Before the idea of using someone elses OS (MS in this case) most banks had their own proprietary standards, and when ATM's were young, they did use proprietary embedded systems in a lot of cases (though not all).
On the flip side of that, communication between banks wasn't easy at all, and standardization of that led to standardization of all of their systems.
Now, the idea of using an MS on an ATM, while not the best idea, isn't a completely horrible decision. Any OS you come across will have flaws... MS just has the most/most public of these. These machines would have been ok for this round but maybe not for the next.
Linux would have been a better choice, BSD even more so. And there are tons of smaller OS's that could have been used that are ovscure enough to write viruses off as well.
I suppose the whole point of my post is Diebold has a history of not only making bad decisions, but also defending those decisions and staying on track with them.
Re:The main issue with XML is performance
on
Effective XML
·
· Score: 1
Hey, I appreciate the link. I haven't read very much yet, but so far the document has been very insightful. That's been the first really strong case for better uses for XML than I've seen (this, coming from a member of HR-XML). Thanks for digging that up for this thread.
I don't have a very strong opinion about how the last day at the Waco compound should have been handled. However, being a Texan, I have tons of opinions about how it should have been handled leading up to the disaster on the final day.
I didn't post any links regarding Clarke's involvement, because I thought it would be common knowledge by anyone who's read up on him. He was the commandant at Ft. Hood at the time, and authorized use of military vehicles and personnel for use by the ATF, which is a violation of federal law. You can find information here, here, or if you prefer threads, here, or if you would rather trust conglomerate media, you're on your own, as I don't hit any of those sites. You could probably google if you like though.
About how Waco was handled in the first place though...
The ATF went to Waco to serve an arrest warrant, although no ATF agent has ever been able to provide who actually had the warrant in hand at trial or to any congressional committee. Were the 5 family dogs shot before or after attempting to show someone this warrant? How would helicoptors aid in facilitating the peaceful service of a search warrant? And why would you need 76 agents if you're peacefully serving a warrant? Usually (here in Texas) Constables or Marshalls serve warrants, why the ATF? If they weren't planning on peacefully serving the warrant, where's the evidence that Koresh had arms inside (he did, but no evidence was ever provided during inquiries or trials by the ATF, which would have been required to secure the warrant)? Why did they open fire as soon as Koresh opened the door while waving his empty hands and saying "Wait, let's talk, there are women and children in here"?
Yes, Koresh was a loony, but there was an agenda in place for dealing with him already, and it included tanks, APCs, and personnel from Ft. Hood. If you're in charge of a military base, nothing leaves it without your consent. And in my mind, that makes Wesley Clarke a bad person.
Re:The main issue with XML is performance
on
Effective XML
·
· Score: 1
If I sounded terse in my previous post (I just re-read it) I apologize... I actually enjoy this kind of thread.
Bear in mind there is a huge difference between a flatfile and a fixed file. Flat files can simply be one-line (or in some cases more than one line) per record and delimited by any character or combination of characters. So the idea of extra spaces taking up room is a bit moot if you're delimiting by a single character. Granted, that one character per "field" in each line of the flatfile, so you would have n-1 extra characters, where n is the number of fields.
About this... It has everything to do with speed, because more work and money spent, directly translates into a more efficient program.
Say you get all of the coding done, and you start your batch processing of data, which happens on a daily basis. A batch on the flatfile will always be faster, and in some cases, many multiples of times faster, because there is no parsing to do other than read until the next delimiter.
Part of the XML standard allows for data to be in any order, so your parser has to check for the tags themselves, and use the data accordingly. In one record employee_number may be at the beginning of the employee's data, in another it might be at the end. With flatfile processing that's not a concern. And if the developers on both ends are worth their weight in wheat, the data will always come in in the specified format, as related in the header file.
I do see your point, and I have to say that I now see another use for XML that I didn't before, but I'm still not convinced that you couldn't do the same with a flatfile and some halfway decent documentation. Maybe I'm getting old and have hit that point in my career where I resist change or something.
Re:The main issue with XML is performance
on
Effective XML
·
· Score: 1
I agree with that issue, except that in typical ISAM or simple flat files, you generally have a header file associated with it. And a "few" extra bites is a stretch.
Maybe XML, then, is useful for development where coding fast (less documentation) is important. That's not a world I want to live in, but I'm sure others would think differently.
that, we don't compromise the freedoms and rights which are the very essence of the America we are protecting
This from the very same guy who loaded the tanks, APC's, and a few soldiers (illegally) to the ATF for their successful attempt at negotiating with David Koresh et. al. in Waco...
You're definitely right about the "stay elected" part. It seems most Americans won't find the time to read a little about how they're being represented by their elected officials. Those that don't follow up have little room to complain about the bills that are being passed.
Re:The main issue with XML is performance
on
Effective XML
·
· Score: 1
I have to ask this though... which is more important to you regarding web apps/services in the enterprise. The possibility of representation changing, or the speed at which you can get the data to the client?
My entire history of coding in the enterprise has been about saving bandwidth while focusing on performance of the app. I deal with very large amounts of data (as do many programmers that read/. I'm sure) and cannot hog bandwidth here in the office or on the VPN's to our vendor data with files that could easily be smaller and faster.
Add to that the idea that there are RDBMS's with XML parsers... that's an awful idea. Can you imagine the geniuses that are trying to load GB's at a time using XML? That sort of activity would bring many DB servers to their knees, if not to a screeching halt.
Personally, I just think well written code handles 99% of what people seem to be using XML for. That being said, I did suggest the book might have some insight into uses for XML that I have yet to come across.
Re:The main issue with XML is performance
on
Effective XML
·
· Score: 1
Uh huh. Now let me ask you, is that record space-delimited? Comma-delimited? Fixed-width [shudder]? If it's fixed width, and the first name is fixed at four characters, is the person's name "John" or "John-Paul"?
I'm assuming since you can read that you also read my minor disclaimer that followed that text. If not, go back and revisit it.
XML is standard
So are flat files, and all you need to know is what the fields are. And if you don't know what they are (and no data dictionary is provided) then you don't need to mess with the file.
but how many extra bytes were spent on code to manage your particular flavor of data?
None, since it was hand typed to form an example with empirical data, which I have yet to see elsewhere in this article.... nothing but subjective opinions. In my experience, flat files don't require any more code than your typical XML parsers... as a matter of fact far less code to manage them, since they don't care about anything but a header file and some sort of delimiter. Simple stuff really.
Since MS is integrating XML into all of their products
Have you seen MS's implementation of XML in ADO? It's horrible, and a bit like a flat file anyway. And it requires some pretty detailed XSL to make it readable... not like the typical XML most people would write out.
but XML's simplicity and universality will make it so that the XML parsers will have more eyes.
That has nothing to do with speed, which is what this thread was about in the first place.
Re:The main issue with XML is performance
on
Effective XML
·
· Score: 5, Insightful
To put it another way...
this single record
Doe, John 1234567 12/1/2001
took 31 bytes, while it's XML companion (using short, simple tags) took 96 bytes.
Not all XML files wind up being 3 times the size of their flatfile counterparts, but they are inherintly larger. There really isn't a way to make loading/parsing that data any faster, by the nature of working with ASCII/ANSI files. XML will always be slower.
Re:The main issue with XML is performance
on
Effective XML
·
· Score: 2, Interesting
I share your opinion regarding XML, and have yet to find a great reason to use it, other than feeding data to our vendors systems through their proprietary file layouts.
On that note though, I wonder if this author has some insight into better uses for XML than what I've typically seen (XML does everything!). I won't, however, be running out to buy it, as XML will always be just more bloat and a resource hog by nature.
Sure it is, unless that jazz studies degree I have from University of North Texas is just a farce.
There are different styles of jazz, and just because her's isn't fusion, experimental, be-bop, and instead happens to fit into the classic/jazz-vocal blends genre doesn't mean she's not jazz.
Of course, if you don't think Ella Fitzgerald, Billie Holiday, Sarah Vaughan, Dinah Washington, Carmen McRae, Nancy Wilson, Ernestine Anderson, Shirley Horn, Nina Simone, Etta James, Abbey Lincoln, Lena Horne, and Rosemary Clooney weren't jazz singers either, then I suppose Norah Jones isn't jazz, and neither is "Don't Know Why" by your standards.
They also made money off the sale of whole cd's from the site. They would let you decide a price and they would pay for distribution, for which they charged (last I knew) $4. Anything above that in price would be split 50/50 between mp3.com and the artist.
Isn't that backwards? If their current price is $13.50 after a 4/1 split, then the shares before the split would be worth $54.00, given that each single share owner would have what is now the equivalent of 4 shares.
The United States doesn't know how to fight against an idea, it only knows how to fight against a militia...
It's not so much that the US doesn't know how to, is that the US citizens (rightfully) don't have the stomach for the activities the US would have to go through to fight it.
I don't hammer the keyboard, and I try to rest all my forearms on the desk in front of the keyboard
That must be the key to success, because I'm the same way when I work at the computer. I'm a professional developer with 12 years experience (20 if you could the pre-professional coding time). Never any problems with RSI/CTD or CTS. I shy away from using the mouse whenever possible too.
My eyesight has gone from 20/15 to 20/20 though, but that may just be from getting a little older. Jury's still out on that one.
Strange world, but I found a $75/hr gig for a friend in Boston on JobSearchEngine. The punch line is it was for writing VB. Where's fair in this world?
Slashdot Mirror
You don't need drivers or the OS to provide support for encryption. Any of that can be written proprietarily, and in much less time than it would take to write a whole embedded OS. The only reason I suggested any Linux or BSD flavor is because of their typical "everything shut off unless you need it" state.
You're absolutely right.. I should have clarified that further. The MS ANSI set is 8-bit while the real ANSI set is only 7. Sorry if I caused any confusion.
Most people mistakenly use ASCII and ANSI interchangeably. Although ANSI doesn't make up for all non-latin characters, it does encompass quite a few.
That's true, and we did find a workaround. The workaround was to set up initial tablespace at 1MB and EXTENTS at the same size. Fragmentation never occurs now. We take up extra drive space, but space is cheap (same arguement folks make about taking too many clocks in code.. Moore's law will fix that for you, yada yada).
I don't want to sound like an M$ zealot, but SQL Server handles all of this seamlessly. I have a very hard time imagining why folks use Oracle over SQL Server, other than the ability to run it on UNIX boxes.
You're so right. There was a time when that was the status-quo, but it's cheaper to set up an old pc with (insert your own OS here) than to write/support your own embedded system. Before the idea of using someone elses OS (MS in this case) most banks had their own proprietary standards, and when ATM's were young, they did use proprietary embedded systems in a lot of cases (though not all).
On the flip side of that, communication between banks wasn't easy at all, and standardization of that led to standardization of all of their systems.
Now, the idea of using an MS on an ATM, while not the best idea, isn't a completely horrible decision. Any OS you come across will have flaws... MS just has the most/most public of these. These machines would have been ok for this round but maybe not for the next.
Linux would have been a better choice, BSD even more so. And there are tons of smaller OS's that could have been used that are ovscure enough to write viruses off as well.
I suppose the whole point of my post is Diebold has a history of not only making bad decisions, but also defending those decisions and staying on track with them.
Hey, I appreciate the link. I haven't read very much yet, but so far the document has been very insightful. That's been the first really strong case for better uses for XML than I've seen (this, coming from a member of HR-XML). Thanks for digging that up for this thread.
I don't have a very strong opinion about how the last day at the Waco compound should have been handled. However, being a Texan, I have tons of opinions about how it should have been handled leading up to the disaster on the final day.
I didn't post any links regarding Clarke's involvement, because I thought it would be common knowledge by anyone who's read up on him. He was the commandant at Ft. Hood at the time, and authorized use of military vehicles and personnel for use by the ATF, which is a violation of federal law. You can find information here, here, or if you prefer threads, here, or if you would rather trust conglomerate media, you're on your own, as I don't hit any of those sites. You could probably google if you like though.
About how Waco was handled in the first place though...
The ATF went to Waco to serve an arrest warrant, although no ATF agent has ever been able to provide who actually had the warrant in hand at trial or to any congressional committee. Were the 5 family dogs shot before or after attempting to show someone this warrant? How would helicoptors aid in facilitating the peaceful service of a search warrant? And why would you need 76 agents if you're peacefully serving a warrant? Usually (here in Texas) Constables or Marshalls serve warrants, why the ATF? If they weren't planning on peacefully serving the warrant, where's the evidence that Koresh had arms inside (he did, but no evidence was ever provided during inquiries or trials by the ATF, which would have been required to secure the warrant)? Why did they open fire as soon as Koresh opened the door while waving his empty hands and saying "Wait, let's talk, there are women and children in here"?
Yes, Koresh was a loony, but there was an agenda in place for dealing with him already, and it included tanks, APCs, and personnel from Ft. Hood. If you're in charge of a military base, nothing leaves it without your consent. And in my mind, that makes Wesley Clarke a bad person.
If I sounded terse in my previous post (I just re-read it) I apologize... I actually enjoy this kind of thread.
Bear in mind there is a huge difference between a flatfile and a fixed file. Flat files can simply be one-line (or in some cases more than one line) per record and delimited by any character or combination of characters. So the idea of extra spaces taking up room is a bit moot if you're delimiting by a single character. Granted, that one character per "field" in each line of the flatfile, so you would have n-1 extra characters, where n is the number of fields.
About this... It has everything to do with speed, because more work and money spent, directly translates into a more efficient program.
Say you get all of the coding done, and you start your batch processing of data, which happens on a daily basis. A batch on the flatfile will always be faster, and in some cases, many multiples of times faster, because there is no parsing to do other than read until the next delimiter.
Part of the XML standard allows for data to be in any order, so your parser has to check for the tags themselves, and use the data accordingly. In one record employee_number may be at the beginning of the employee's data, in another it might be at the end. With flatfile processing that's not a concern. And if the developers on both ends are worth their weight in wheat, the data will always come in in the specified format, as related in the header file.
I do see your point, and I have to say that I now see another use for XML that I didn't before, but I'm still not convinced that you couldn't do the same with a flatfile and some halfway decent documentation. Maybe I'm getting old and have hit that point in my career where I resist change or something.
I agree with that issue, except that in typical ISAM or simple flat files, you generally have a header file associated with it. And a "few" extra bites is a stretch.
Maybe XML, then, is useful for development where coding fast (less documentation) is important. That's not a world I want to live in, but I'm sure others would think differently.
that, we don't compromise the freedoms and rights which are the very essence of the America we are protecting
This from the very same guy who loaded the tanks, APC's, and a few soldiers (illegally) to the ATF for their successful attempt at negotiating with David Koresh et. al. in Waco...
You're definitely right about the "stay elected" part. It seems most Americans won't find the time to read a little about how they're being represented by their elected officials. Those that don't follow up have little room to complain about the bills that are being passed.
I have to ask this though... which is more important to you regarding web apps/services in the enterprise. The possibility of representation changing, or the speed at which you can get the data to the client?
/. I'm sure) and cannot hog bandwidth here in the office or on the VPN's to our vendor data with files that could easily be smaller and faster.
My entire history of coding in the enterprise has been about saving bandwidth while focusing on performance of the app. I deal with very large amounts of data (as do many programmers that read
Add to that the idea that there are RDBMS's with XML parsers... that's an awful idea. Can you imagine the geniuses that are trying to load GB's at a time using XML? That sort of activity would bring many DB servers to their knees, if not to a screeching halt.
Personally, I just think well written code handles 99% of what people seem to be using XML for. That being said, I did suggest the book might have some insight into uses for XML that I have yet to come across.
Uh huh. Now let me ask you, is that record space-delimited? Comma-delimited? Fixed-width [shudder]? If it's fixed width, and the first name is fixed at four characters, is the person's name "John" or "John-Paul"?
I'm assuming since you can read that you also read my minor disclaimer that followed that text. If not, go back and revisit it.
XML is standard
So are flat files, and all you need to know is what the fields are. And if you don't know what they are (and no data dictionary is provided) then you don't need to mess with the file.
but how many extra bytes were spent on code to manage your particular flavor of data?
None, since it was hand typed to form an example with empirical data, which I have yet to see elsewhere in this article.... nothing but subjective opinions. In my experience, flat files don't require any more code than your typical XML parsers... as a matter of fact far less code to manage them, since they don't care about anything but a header file and some sort of delimiter. Simple stuff really.
Since MS is integrating XML into all of their products
Have you seen MS's implementation of XML in ADO? It's horrible, and a bit like a flat file anyway. And it requires some pretty detailed XSL to make it readable... not like the typical XML most people would write out.
but XML's simplicity and universality will make it so that the XML parsers will have more eyes.
That has nothing to do with speed, which is what this thread was about in the first place.
To put it another way...
this single record
Doe, John 1234567 12/1/2001
took 31 bytes, while it's XML companion (using short, simple tags) took 96 bytes.
Not all XML files wind up being 3 times the size of their flatfile counterparts, but they are inherintly larger. There really isn't a way to make loading/parsing that data any faster, by the nature of working with ASCII/ANSI files. XML will always be slower.
I share your opinion regarding XML, and have yet to find a great reason to use it, other than feeding data to our vendors systems through their proprietary file layouts.
On that note though, I wonder if this author has some insight into better uses for XML than what I've typically seen (XML does everything!). I won't, however, be running out to buy it, as XML will always be just more bloat and a resource hog by nature.
How about pigment-challenged? Then you might get to park up front at Walman-Marcus.
Sure it is, unless that jazz studies degree I have from University of North Texas is just a farce.
There are different styles of jazz, and just because her's isn't fusion, experimental, be-bop, and instead happens to fit into the classic/jazz-vocal blends genre doesn't mean she's not jazz.
Of course, if you don't think Ella Fitzgerald, Billie Holiday, Sarah Vaughan, Dinah Washington, Carmen McRae, Nancy Wilson, Ernestine Anderson, Shirley Horn, Nina Simone, Etta James, Abbey Lincoln, Lena Horne, and Rosemary Clooney weren't jazz singers either, then I suppose Norah Jones isn't jazz, and neither is "Don't Know Why" by your standards.
That's the beauty of opinion.
The funny thing is Norah Jones is really a jazz singer, but got tossed onto pop stations, I suppose for lack of any other decent music.
Sure... back beats, lyrics about nothing, and lots of bass. Although categorizing Norah Jones as pop is a stretch...
They also made money off the sale of whole cd's from the site. They would let you decide a price and they would pay for distribution, for which they charged (last I knew) $4. Anything above that in price would be split 50/50 between mp3.com and the artist.
Oops, sorry. Guess I should have paid more attention to the underlying information.
Isn't that backwards? If their current price is $13.50 after a 4/1 split, then the shares before the split would be worth $54.00, given that each single share owner would have what is now the equivalent of 4 shares.
The United States doesn't know how to fight against an idea, it only knows how to fight against a militia...
It's not so much that the US doesn't know how to, is that the US citizens (rightfully) don't have the stomach for the activities the US would have to go through to fight it.
I only mentioned it for the obvious Delta, not the implication that 20/20 is bad.
I don't hammer the keyboard, and I try to rest all my forearms on the desk in front of the keyboard
That must be the key to success, because I'm the same way when I work at the computer. I'm a professional developer with 12 years experience (20 if you could the pre-professional coding time). Never any problems with RSI/CTD or CTS. I shy away from using the mouse whenever possible too.
My eyesight has gone from 20/15 to 20/20 though, but that may just be from getting a little older. Jury's still out on that one.
Strange world, but I found a $75/hr gig for a friend in Boston on JobSearchEngine. The punch line is it was for writing VB. Where's fair in this world?