It comes down to a matter of which you consider more l33t -- memorising enough keystrokes to use the default editor {thereby effectively letting the computer win}, or compiling an editor from source that actually shows you the keystrokes at the bottom of the screen?
Of course, the opposite slant you could put on that would be that vi is more likely to be encountered on any random system you might come across than nano or pico, which means you have an advantage if you do know some of the keystrokes.
And there is a school of thought that views obscure editors as a form of recreational self-abuse -- a sort of extreme sport in its own right. Hmm..... I've just had a vision of a guy in body-hugging lycra, dangling precariously from a rope halfway up a mountain, ice-axe in one hand, laptop in the other, editing a kernel config file with ed, typing with his nose. Extreme editing! I may be on to something here.....
No, but our business is very specific and most users don't really need those kind of general purpose tools for what they do {though some of us do use a rather well-known, general purpose web-based database application}. We have a number of database-driven applications with dedicated front-ends that are accessed using a web browser; and dedicated back-ends that talk directly to printers, the VoIP exchange {to send faxes} and of course sendmail {including a third party email-to-SMS gateway; though we're investigating the possibility of interfacing directly to a stack of PAYG mobes and sending SMSes directly}.
We send various types of fill-in-the-gaps standard letters using dedicated scripts, we have database-driven purchase and sales order tracking systems, and we don't generally show each other presentations. Our whole workflow is handled this way; whenever we see the need for improvements, we can just make them {instead of getting people to behave the way the computer expects, which I have seen in far too many Windows installations}. When whole new procedures are being introduced, we always start off with old-fashioned pens and paper; that way, we can work out exactly what needs automating and how best to do so.
The result is a system that is as tightly integrated as anyone can get. Right down to the point of never having routinely to copy and paste stuff into an e-mail, because if there's an e-mail to be sent it will be fired off by the appropriate page on the server; nor out of an e-mail, because all the applications are written so as to work seamlessly together.
They hardly notice the difference. They used to use pirated copies of IE on Windows to access our own in-house-written web apps. Now they use legal copies of Mozilla on Linux to access the same web apps. To the average user, all that has changed is the icons. But we're fully licence-compliant.
Companies that need to exchange documents with a lot of other organizations (that are already using MSOffice) would probably have a harder time switching to OOo, than a company who doesn't really do a lot of outside contact.
Not really..... The MSOfice-users with whom they exchange data just have to download and install OpenOffice.org. As I said, you don't have to be a vegetarian to eat tofu {but you do have to be an omnivore to eat m**t}.
No, my boss is a hacker and he was glad to have some support in the getting-rid-of-Windows thing. And I got the company fully licence-compliant.
Almost nothing depended on MS Office, because everything was done through CGI applications on a server. OpenOffice.org works fine for the odd occasions someone needs to create a document in a word processor or spreadsheet.
How many times have you wasted valuable time at a meeting while attendees share paper copies of the pre-distributed incompatible (with their version of WORD) Word documents? If you don't remember, you're not trying.
Never, but the place I work at has almost banned Microsoft Office {pretty much on my say-so}. We keep just two Windows applications running for compatibility with Group Head Office. Everyone else gets Linux; we used to use Mandriva, but we're currently evaluating Kubuntu and probably will adopt Breezy as the new standard.
I know this is the exception, though! Most of our software is written in-house in Perl or PHP and accessed through a web browser. This keeps desktops fairly lightweight. As a system, it's theoretically fairly platform-agnostic, but tends to be a tiny wee bit Mozilla-centric in practice. Some do use Windows, at their own expense and their own risk; but we won't move a muscle to support it except for the necessary legacy apps, and then we just get someone from Group Head Office down to fix it.
As long as they're all started at the same time, it won't actually take any longer than compiling it on one PC.
In all seriousness: you probably would pre-compile the lot on one machine {or one sample machine of each architecture}, tweak until you were happy, then transfer just the twooken binaries to each machine in turn. This does work. Knowing how long it takes to do one machine, and how many staff you have available to perform installations, will give you an idea how many CDs to burn.....
1. If it takes one IT technician 9 minutes to install an operating system on a PC from CD, there are 300 PCs in the department and it takes 1 minute to walk from one PC to the next, how many CDs will six IT technicians require between them and how long will it take to complete the installation?
That's not really OpenOffice's fault. OpenOffice.org's document format is openly available. Neither Microsoft's document format, nor the necessary information to write a "native" import filter, are known to anybody except Microsoft.
Of course, as has been pointedoutelsewhere, for Microsoft to integrate OO.o file formats would be something between daft and suicidal..... proprietary file formats are Microsoft's way of holding users' data, and by extension users, to ransom.
Anyway, there is absolutely nothing to stop these "other business units/companies/organizations" {that presumably are running MSOffice on Windows} from installing OpenOffice.org themselves. You don't have to be a vegetarian to eat tofu.....
Indeed..... I'm forever pressing ctrl+W in Kate when I want to search for something, and closing the file {don't even get an "are you sure?" requester if the file wasn't modified}; or ctrl+A when I mean to go to the beginning of the line and ending up selecting everything.
Anyone who says they have never hit a shortcut key from a different application by mistake is either lying, or just doesn't use very many applications.
..... either have to find a pirate copy of the latest version of Word, or *shudder* pay for it {which businesses actually are likely to do}. Adopting OpenDocument will mean.....
It is about features. OpenDocument does not, and never will, support the ability to extort money from users by altering the file format at some stage in the future; and relying on the fact that newer pre-installs will be set up not to save in the old format, effectively to force users to upgrade if they want to read documents created by their friends and co-workers.
That's the feature Microsoft most desperately wants: the ability to hold your data to ransom. If you've got Word documents, any version of Word should be able to open them; but if someone sends you a document from the latest version of Word, then you also will need the latest Word to open it. This means you will either have to find. Adopting OpenDocument will mean they have to sacrifice exactly that ability.
It is already supported. OpenDocument files are merely ZIP archives. One of the files in the archive is a manifest. Another is the main file in XML, which includes links to the other files in the archive. These may be any kind of file: stylesheets, sounds, Flash animations, graphics, movies, more XML, more OpenDocument files -- all preserved in their original formats. And not translated to some horrible proprietary format which needs a payware viewer/editor; they are all editable with standard tools.
Go and have a butcher's at some OpenOffice documents.
OpenDocument compatibility is coming to Office anyway, and whether Microsoft likes it or not. Office has an embedded programming language, a bastardised dialect of BASIC, which includes a document object model. So, it ought to be entirely possible to write a series of Office macros which turned an Office document into an OpenDocument document -- and maybe back as well.
Now the only thing keeping Office popular is the lack of interoperability with anything else. Lack of interoperability is usually considered to be a bad thing -- name me one electricity company that sells 48 volts DC. We have already seen protectionism fail when countries did things like adopting different TV standards from their neighbours effectively to prevent imports of cheap tellies {setmakers just went multi-standard, and SCART connectors with RGB input eventually became the norm}.
These realities do not appear to have hit the computer market yet..... or at least, not hard enough. Probably the ones who are still in awe of computers don't even realise what ought to be possible. I've been connecting stuff together all my life -- before computers, it was record players, tape recorders and radio sets, recording signals from the wireless and amplifying them through the record player's speaker. My first VCR, with its separate audio and video sockets opened up exciting new possibilities in connectivity {4 hour long recordings of radio broadcasts from pop festivals! Complete with teletext-style graphics from the Model B, which were initially only there to keep the muting off but evolved into a kind of artform in their own right}. Every computer I have ever owned has had something unusual plugged into it.
But I don't think I represent most of the population. I think most people don't expect things to be connected together and just work like that; they're still so taken in by the fact that they just press the keys and the letters come up on the screen, and later pop out of the printer, that they don't think past that. That ought to change in the future; but it will depend more on the fact of clue filtering slowly through to the population than anything any major player does {unless that something is to cause sudden and large-scale data loss}.
If the conversion suite was released as quasi-Open Source software {as open as anything running on a closed platform can be}, then the only thing Microsoft could do about that is try and prove they own a patent on converting documents between Office and OpenDocument standards; but then they would expose themselves to the patent being struck down on the grounds that the invention had not been worked {which is still valid in some jurisdictions IMMSMC}. Not to mention that it would constitute an admission that Microsoft already had the technology to perform the conversion {otherwise the patent would be a mere work of science fiction, therefore null and void by default}. This would have the effect of casting doubt on other things Microsoft are fond of saying.
Once a mechanism was in place for converting documents between OpenDocument and Office formats, a business would then need only one PC running Office -- and then only for as long as they have any Office files to convert to OpenDocument. Under well-established doctrines, they would even be within their rights to sell that machine to another business when it was finished with.
At the moment, I have good reasons not to be having a go at this. When those reasons change, if there is not already a functioning translator, I will definitely set up a Windows machine of my own and give it a crack.
I would guess the corruptability also depends to some greater or lesser extent on the underlying filing system.
For instance, the mail transport agent exim runs very fast on Linux, but very slowly on Solaris. This is due to different default caching policies: Linux {with ext2} caches every single disk write in RAM and only ever commits them to disk when it begins running out of RAM, or at shutdown; whereas Solaris by default blocks until the disk write is completed. Exim generates many temporary files in the course of its operation; on a Linux box with plenty of RAM, these files may never even see oxide.
MySQL is of course as vulnerable as anything else to file corruption, and the ext2 way makes it also vulnerable to RAM corruption.
Questions: What OS were you running to get files corrupted? What was the filing system and what was its caching policy? Did you have any closed-source software running? Have you stress-tested your RAM and HDD?
If you make backups of the relevant.MYD,.MYI and.frm files just as the MySQL logs are about to drop off the end of the rotation sequence, you should at least be able to rebuild your database semi-automatically.....
Where are you making your call to the database server from? A scripting language perhaps?
If you really care about losing the end of a ten-character word by putting it into a VARCHAR(9) field, or about a field not being populated which should be populated, then do the check in the scripting language before you call the database server and complain about it there.
You've got to pick a behaviour for exceptional cases -- either try and do as much as you can with what you have available, or protest loudly and not even bother. Whichever you pick is certain to piss somebody off -- I'll dare bet you there are users of other people's databases complaining that if you try to store a string in a field that's too short it should just lop off the excess characters, not throw up an error.
If you had a database that sometimes barfed over exceptions and sometimes dealt with them quietly, and gave you no way to know in advance which it was going to do, then you would have a valid cause for complaint. But MySQL always tries its best to store something {and it keeps verbatim logs of queries just in case, so if something goes really tits-up it can be fixed manually}. You should know that's its default behaviour. And if you really don't like it, what's stopping you from changing it?
I haven't found MySQL to be too sensitive to crashes -- except once, in the case of a table with c.28M records and indices on several fields. This is used in a read-only application, being rebuilt from sources every quarter. One day, the server lost power when someone {I won't say which telephone company they were working for, lest someone misread it and think I am saying nasty things about BitTorrent} pulled the wrong plug.
It was taking forever to repair the table {and breaking the bootup process}; but fortunately, I had bzip2'ed copies of the.MYD and.MYI files from just a week earlier when I had copied the database to another server. Once I had got the affected box into single-user mode and chmod -x'ed the mysql initscript, I just had to go multiuser, copy the bz2 files from the CDs and bunzip2 them. And when I mended the initscript, mysql started up like nothing had happened.
For this one particular application, which is straight lookups, MySQL really does rock. Every query is a SELECT * and uses an indexed field in the WHERE clause, and it's lightning fast. We don't need transactions, stored procedures or triggers. Beside which, all the calls to the database are being made from a scripting language, so it'd be a bit like giving Edward Scissorhands a penknife.
But there's a postscript. The source data comes as flat text files on CDs, which are records containing fixed-width fields which are keys to other files. Proper old-school database stuff {it's also available on various types of tape cartridges and probably even on punched cards}. So building the database in the format we needed involved building intermediate databases {or massive arrays}. Now, the guy who used to deal with the building of the big database left the company for pastures new, and I couldn't make head or tail of the scripts he had written to do the job -- so I rewrote the whole lot from scratch and documented everything properly this time. He had used MySQL for the intermediate databases, and the build took weeks. I used Perl's dbmopen function, which basically treats a GDBM file as an associative array -- and got it done in days, including building a new GDBM file from an old MySQL database {which won't need to be done ever again now, touch wood}. So MySQL is not always the fastest.....
..... but OpenDocument compatibility is coming to Office anyway, and whether Microsoft likes it or not. Office has an embedded programming language, a bastardised dialect of BASIC, which includes a document object model. So, it ought to be possible to write a series of Office macros which turned an Office document into an OpenDocument document -- and maybe back as well.
Now the only thing keeping Office popular is the lack of interoperability with anything else. Lack of interoperability is usually considered to be a bad thing -- name me one electricity company that sells 48 volts DC. We have already seen protectionism fail when countries did things like adopting different TV standards from their neighbours effectively to prevent imports of cheap tellies {setmakers just went multi-standard, and SCART connectors with RGB input eventually became the norm}.
These realities do not appear to have hit the computer market yet..... or at least, not hard enough. Probably the ones who are still in awe of computers don't even realise what ought to be possible. I've been connecting stuff together all my life -- before computers, it was record players, tape recorders and radio sets, recording signals from the wireless and amplifying them through the record player's speaker. My first VCR, with its separate audio and video sockets opened up exciting new possibilities in connectivity {4 hour long recordings of radio broadcasts from pop festivals! Complete with teletext-style graphics from the Model B, which were initially only there to keep the muting off but evolved into a kind of artform in their own right}. Every computer I have ever owned has had something unusual plugged into it.
But I don't think I represent most of the population. I think most people don't expect things to be connected together and just work like that; they're still so taken in by the fact that they just press the keys and the letters come up on the screen, and later pop out of the printer, that they don't think past that. That ought to change in the future; but it will depend more on the fact of clue filtering slowly through to the population than anything any major player does {unless that something is to cause sudden and large-scale data loss}.
My soultion would be to use Office's own macro language to deal with the conversion. These macros could then be released as quasi-Open Source software {as open as anything running on a closed platform can be}. The only thing Microsoft could do about that is try and prove they own a patent on converting documents between Office and OpenDocument standards; but then they would expose themselves to the patent being struck down on the grounds that the invention had not been worked {which is still valid in some jurisdictions IMMSMC}. Not to mention that it would constitute an admission that Microsoft already had the technology to perform the conversion {otherwise the patent would be a mere work of science fiction, therefore null and void by default}. This would have the effect of casting doubt on other things Microsoft are fond of saying.
Once a mechanism was in place for converting documents between OpenDocument and Office formats, a business would then need only one PC running Office -- and then only for as long as they have any Office files to convert to OpenDocument. Under well-established doctrines, they would even be within their rights to sell that machine to another business when it was finished with.
Who needs MIN() and MAX() anyway? What's wrong with something like SELECT height FROM suspects ORDER BY height ASC LIMIT 1 ? Come to think of it, I probably would just use SELECT *....., read the whole record into a numeric array and pull out the field I wanted. But that's just because I'm used to using the GPL version of MySQL, which isn't so much a database but a set of extensions for implementing special large associative arrays via an abstraction layer which resembles a programming language.
Anyway, the only people who don't like the GPL are the ones from whom it was meant to protect the rest of us -- the ones who want to take someone else's hard work which they intended to be for the benefit of all, then cage it up and profit from it.
Serious question for GPL-haters: Which of the Four Freedoms don't you believe in?
AJS318's idea of "trusted computing" is where every computer has a different {but obviously user-changeable} instruction set and addressing schema, and so can only run code compiled for it. If I am administering a whole lot of PCs in an enterprise, I might choose to personalise them all the same for ease of code roll-out; but if I am just downloading and compiling apps for my own desktop machine, the personalisation can be truly unique. Of course, the risky part is bootstrapping..... At some stage, I obviously have to compile from source a compiler personalised to the machine I want to run it on -- and I am not certain that that isn't a big enough security hole to slip in something really really nasty.
Veering even further offtopic but brushing against your bit about governments having access to keys, I think attempts to enforce healthy eating in schools have nothing to do with solving the problem of "childhood obesity" and everything to do with promoting the acceptance, from an early age, of being told what to do by the government. If they can tell you what to eat, it's a short step to telling you what to think.
And just how conscionable is a demand that you return your property, which you bought and paid for with your own money, which you earned by your own efforts of hand or brain, to Lexmark when they say so?
This could never happen in Britain, where we have the Unfair Contract Terms Act and the WEEE directive.
The madness will only end the day that some government somewhere decides to enforce non-discriminatory IP licencing {i.e. if you licence your IP to anybody at all, you have to licence it to everybody on exactly the same terms} -- using as punishment a court order forcing the offender's IP into the Public Domain.
Why do I believe it will take government intervention to accomplish this, rather than just letting the market decide? Human nature. Listen to a request show on the wireless..... every listener, without exception, agrees that every record they play, without exception, is shite. These are the same listeners that chose the records in the first place. QED.
In some regimes, ones with complicated tax laws, energy recovery isn't automatically counted as recycling. Otherwise a company could spin off the department which heats its buildings as a concern in its own right, signing over all boilers, radiators, pumps, thermostats and so forth to the new company; buy the usual amount of heating fuel; immediately declare it waste {since the original company has no boilers of its own} and pay the former heating department to "recycle" the "waste" heating fuel. The original company, meanwhile, claims back any taxes it paid on the fuel, and the heating company doesn't owe tax since it is burning waste products -- which do not attract the same taxes as the fossil fuels they embarrassingly resemble. And the heating company's figures are carefully massaged so as to keep the company in the lowest possible tax band.
That's what you get for having broken tax regimes..... it's the equivalent of making it an offence to sell bodily waste products lest they be used for fraudulent purposes. You need to keep adding dafter and dafter laws to prop up one daft one.
Now, stuff like disposable nappies {I personally would favour a hard per capita limit -- or should that be per fundamens?} and aluminised mylar crisp packets can only feasibly be recycled by burning them for the stored energy. But I am still tempted to think it should be kept as a very last resort.
For a user leaving MySQL, the main difference is in the quotes; MySQL uses 'single' or "double" quotes to delimit string literals and `back` quotes around field names which would otherwise conflict with reserved words, whereas PostgreSQL uses 'single' quotes to delimit string literals and "double" quotes around dodgy field names. {TTBOMK the "official" standard, if there is one, is 'single' quotes around string literals and tough titty if you want a field name that looks like a reserved word.} I reckon a simple patch would effectively fix the quotes issue..... just have an option in the rcfile to allow Postgres-style quotes or MySQL-style quotes. {There is of course going to be a load of stuff being done with Perl, PHP and Python scripts that Postgres does natively..... but we can deal with that later.}
Of course, there's nothing to stop someone forking GPL MySQL. Nobody actually uses non-GPL MySQL anyway..... if they're going to use a payware database, they'll use MS SQL server or Oracle.
Slashdot Mirror
It comes down to a matter of which you consider more l33t -- memorising enough keystrokes to use the default editor {thereby effectively letting the computer win}, or compiling an editor from source that actually shows you the keystrokes at the bottom of the screen?
..... I've just had a vision of a guy in body-hugging lycra, dangling precariously from a rope halfway up a mountain, ice-axe in one hand, laptop in the other, editing a kernel config file with ed, typing with his nose. Extreme editing! I may be on to something here .....
Of course, the opposite slant you could put on that would be that vi is more likely to be encountered on any random system you might come across than nano or pico, which means you have an advantage if you do know some of the keystrokes.
And there is a school of thought that views obscure editors as a form of recreational self-abuse -- a sort of extreme sport in its own right. Hmm
No, but our business is very specific and most users don't really need those kind of general purpose tools for what they do {though some of us do use a rather well-known, general purpose web-based database application}. We have a number of database-driven applications with dedicated front-ends that are accessed using a web browser; and dedicated back-ends that talk directly to printers, the VoIP exchange {to send faxes} and of course sendmail {including a third party email-to-SMS gateway; though we're investigating the possibility of interfacing directly to a stack of PAYG mobes and sending SMSes directly}.
We send various types of fill-in-the-gaps standard letters using dedicated scripts, we have database-driven purchase and sales order tracking systems, and we don't generally show each other presentations. Our whole workflow is handled this way; whenever we see the need for improvements, we can just make them {instead of getting people to behave the way the computer expects, which I have seen in far too many Windows installations}. When whole new procedures are being introduced, we always start off with old-fashioned pens and paper; that way, we can work out exactly what needs automating and how best to do so.
The result is a system that is as tightly integrated as anyone can get. Right down to the point of never having routinely to copy and paste stuff into an e-mail, because if there's an e-mail to be sent it will be fired off by the appropriate page on the server; nor out of an e-mail, because all the applications are written so as to work seamlessly together.
They hardly notice the difference. They used to use pirated copies of IE on Windows to access our own in-house-written web apps. Now they use legal copies of Mozilla on Linux to access the same web apps. To the average user, all that has changed is the icons. But we're fully licence-compliant.
No, my boss is a hacker and he was glad to have some support in the getting-rid-of-Windows thing. And I got the company fully licence-compliant.
Almost nothing depended on MS Office, because everything was done through CGI applications on a server. OpenOffice.org works fine for the odd occasions someone needs to create a document in a word processor or spreadsheet.
I know this is the exception, though! Most of our software is written in-house in Perl or PHP and accessed through a web browser. This keeps desktops fairly lightweight. As a system, it's theoretically fairly platform-agnostic, but tends to be a tiny wee bit Mozilla-centric in practice. Some do use Windows, at their own expense and their own risk; but we won't move a muscle to support it except for the necessary legacy apps, and then we just get someone from Group Head Office down to fix it.
In all seriousness: you probably would pre-compile the lot on one machine {or one sample machine of each architecture}, tweak until you were happy, then transfer just the twooken binaries to each machine in turn. This does work. Knowing how long it takes to do one machine, and how many staff you have available to perform installations, will give you an idea how many CDs to burn
That's not really OpenOffice's fault. OpenOffice.org's document format is openly available. Neither Microsoft's document format, nor the necessary information to write a "native" import filter, are known to anybody except Microsoft.
..... proprietary file formats are Microsoft's way of holding users' data, and by extension users, to ransom.
.....
Of course, as has been pointed out elsewhere, for Microsoft to integrate OO.o file formats would be something between daft and suicidal
Anyway, there is absolutely nothing to stop these "other business units/companies/organizations" {that presumably are running MSOffice on Windows} from installing OpenOffice.org themselves. You don't have to be a vegetarian to eat tofu
Indeed ..... I'm forever pressing ctrl+W in Kate when I want to search for something, and closing the file {don't even get an "are you sure?" requester if the file wasn't modified}; or ctrl+A when I mean to go to the beginning of the line and ending up selecting everything.
Anyone who says they have never hit a shortcut key from a different application by mistake is either lying, or just doesn't use very many applications.
..... either have to find a pirate copy of the latest version of Word, or *shudder* pay for it {which businesses actually are likely to do}. Adopting OpenDocument will mean .....
It is about features. OpenDocument does not, and never will, support the ability to extort money from users by altering the file format at some stage in the future; and relying on the fact that newer pre-installs will be set up not to save in the old format, effectively to force users to upgrade if they want to read documents created by their friends and co-workers.
That's the feature Microsoft most desperately wants: the ability to hold your data to ransom. If you've got Word documents, any version of Word should be able to open them; but if someone sends you a document from the latest version of Word, then you also will need the latest Word to open it. This means you will either have to find. Adopting OpenDocument will mean they have to sacrifice exactly that ability.
It is already supported. OpenDocument files are merely ZIP archives. One of the files in the archive is a manifest. Another is the main file in XML, which includes links to the other files in the archive. These may be any kind of file: stylesheets, sounds, Flash animations, graphics, movies, more XML, more OpenDocument files -- all preserved in their original formats. And not translated to some horrible proprietary format which needs a payware viewer/editor; they are all editable with standard tools.
Go and have a butcher's at some OpenOffice documents.
OpenDocument compatibility is coming to Office anyway, and whether Microsoft likes it or not. Office has an embedded programming language, a bastardised dialect of BASIC, which includes a document object model. So, it ought to be entirely possible to write a series of Office macros which turned an Office document into an OpenDocument document -- and maybe back as well.
..... or at least, not hard enough. Probably the ones who are still in awe of computers don't even realise what ought to be possible. I've been connecting stuff together all my life -- before computers, it was record players, tape recorders and radio sets, recording signals from the wireless and amplifying them through the record player's speaker. My first VCR, with its separate audio and video sockets opened up exciting new possibilities in connectivity {4 hour long recordings of radio broadcasts from pop festivals! Complete with teletext-style graphics from the Model B, which were initially only there to keep the muting off but evolved into a kind of artform in their own right}. Every computer I have ever owned has had something unusual plugged into it.
Now the only thing keeping Office popular is the lack of interoperability with anything else. Lack of interoperability is usually considered to be a bad thing -- name me one electricity company that sells 48 volts DC. We have already seen protectionism fail when countries did things like adopting different TV standards from their neighbours effectively to prevent imports of cheap tellies {setmakers just went multi-standard, and SCART connectors with RGB input eventually became the norm}.
These realities do not appear to have hit the computer market yet
But I don't think I represent most of the population. I think most people don't expect things to be connected together and just work like that; they're still so taken in by the fact that they just press the keys and the letters come up on the screen, and later pop out of the printer, that they don't think past that. That ought to change in the future; but it will depend more on the fact of clue filtering slowly through to the population than anything any major player does {unless that something is to cause sudden and large-scale data loss}.
If the conversion suite was released as quasi-Open Source software {as open as anything running on a closed platform can be}, then the only thing Microsoft could do about that is try and prove they own a patent on converting documents between Office and OpenDocument standards; but then they would expose themselves to the patent being struck down on the grounds that the invention had not been worked {which is still valid in some jurisdictions IMMSMC}. Not to mention that it would constitute an admission that Microsoft already had the technology to perform the conversion {otherwise the patent would be a mere work of science fiction, therefore null and void by default}. This would have the effect of casting doubt on other things Microsoft are fond of saying.
Once a mechanism was in place for converting documents between OpenDocument and Office formats, a business would then need only one PC running Office -- and then only for as long as they have any Office files to convert to OpenDocument. Under well-established doctrines, they would even be within their rights to sell that machine to another business when it was finished with.
At the moment, I have good reasons not to be having a go at this. When those reasons change, if there is not already a functioning translator, I will definitely set up a Windows machine of my own and give it a crack.
I would guess the corruptability also depends to some greater or lesser extent on the underlying filing system.
.MYD, .MYI and .frm files just as the MySQL logs are about to drop off the end of the rotation sequence, you should at least be able to rebuild your database semi-automatically .....
For instance, the mail transport agent exim runs very fast on Linux, but very slowly on Solaris. This is due to different default caching policies: Linux {with ext2} caches every single disk write in RAM and only ever commits them to disk when it begins running out of RAM, or at shutdown; whereas Solaris by default blocks until the disk write is completed. Exim generates many temporary files in the course of its operation; on a Linux box with plenty of RAM, these files may never even see oxide.
MySQL is of course as vulnerable as anything else to file corruption, and the ext2 way makes it also vulnerable to RAM corruption.
Questions: What OS were you running to get files corrupted? What was the filing system and what was its caching policy? Did you have any closed-source software running? Have you stress-tested your RAM and HDD?
If you make backups of the relevant
Where are you making your call to the database server from? A scripting language perhaps?
If you really care about losing the end of a ten-character word by putting it into a VARCHAR(9) field, or about a field not being populated which should be populated, then do the check in the scripting language before you call the database server and complain about it there.
You've got to pick a behaviour for exceptional cases -- either try and do as much as you can with what you have available, or protest loudly and not even bother. Whichever you pick is certain to piss somebody off -- I'll dare bet you there are users of other people's databases complaining that if you try to store a string in a field that's too short it should just lop off the excess characters, not throw up an error.
If you had a database that sometimes barfed over exceptions and sometimes dealt with them quietly, and gave you no way to know in advance which it was going to do, then you would have a valid cause for complaint. But MySQL always tries its best to store something {and it keeps verbatim logs of queries just in case, so if something goes really tits-up it can be fixed manually}. You should know that's its default behaviour. And if you really don't like it, what's stopping you from changing it?
I haven't found MySQL to be too sensitive to crashes -- except once, in the case of a table with c.28M records and indices on several fields. This is used in a read-only application, being rebuilt from sources every quarter. One day, the server lost power when someone {I won't say which telephone company they were working for, lest someone misread it and think I am saying nasty things about BitTorrent} pulled the wrong plug.
.MYD and .MYI files from just a week earlier when I had copied the database to another server. Once I had got the affected box into single-user mode and chmod -x'ed the mysql initscript, I just had to go multiuser, copy the bz2 files from the CDs and bunzip2 them. And when I mended the initscript, mysql started up like nothing had happened.
.....
It was taking forever to repair the table {and breaking the bootup process}; but fortunately, I had bzip2'ed copies of the
For this one particular application, which is straight lookups, MySQL really does rock. Every query is a SELECT * and uses an indexed field in the WHERE clause, and it's lightning fast. We don't need transactions, stored procedures or triggers. Beside which, all the calls to the database are being made from a scripting language, so it'd be a bit like giving Edward Scissorhands a penknife.
But there's a postscript. The source data comes as flat text files on CDs, which are records containing fixed-width fields which are keys to other files. Proper old-school database stuff {it's also available on various types of tape cartridges and probably even on punched cards}. So building the database in the format we needed involved building intermediate databases {or massive arrays}. Now, the guy who used to deal with the building of the big database left the company for pastures new, and I couldn't make head or tail of the scripts he had written to do the job -- so I rewrote the whole lot from scratch and documented everything properly this time. He had used MySQL for the intermediate databases, and the build took weeks. I used Perl's dbmopen function, which basically treats a GDBM file as an associative array -- and got it done in days, including building a new GDBM file from an old MySQL database {which won't need to be done ever again now, touch wood}. So MySQL is not always the fastest
..... but OpenDocument compatibility is coming to Office anyway, and whether Microsoft likes it or not. Office has an embedded programming language, a bastardised dialect of BASIC, which includes a document object model. So, it ought to be possible to write a series of Office macros which turned an Office document into an OpenDocument document -- and maybe back as well.
..... or at least, not hard enough. Probably the ones who are still in awe of computers don't even realise what ought to be possible. I've been connecting stuff together all my life -- before computers, it was record players, tape recorders and radio sets, recording signals from the wireless and amplifying them through the record player's speaker. My first VCR, with its separate audio and video sockets opened up exciting new possibilities in connectivity {4 hour long recordings of radio broadcasts from pop festivals! Complete with teletext-style graphics from the Model B, which were initially only there to keep the muting off but evolved into a kind of artform in their own right}. Every computer I have ever owned has had something unusual plugged into it.
Now the only thing keeping Office popular is the lack of interoperability with anything else. Lack of interoperability is usually considered to be a bad thing -- name me one electricity company that sells 48 volts DC. We have already seen protectionism fail when countries did things like adopting different TV standards from their neighbours effectively to prevent imports of cheap tellies {setmakers just went multi-standard, and SCART connectors with RGB input eventually became the norm}.
These realities do not appear to have hit the computer market yet
But I don't think I represent most of the population. I think most people don't expect things to be connected together and just work like that; they're still so taken in by the fact that they just press the keys and the letters come up on the screen, and later pop out of the printer, that they don't think past that. That ought to change in the future; but it will depend more on the fact of clue filtering slowly through to the population than anything any major player does {unless that something is to cause sudden and large-scale data loss}.
My soultion would be to use Office's own macro language to deal with the conversion. These macros could then be released as quasi-Open Source software {as open as anything running on a closed platform can be}. The only thing Microsoft could do about that is try and prove they own a patent on converting documents between Office and OpenDocument standards; but then they would expose themselves to the patent being struck down on the grounds that the invention had not been worked {which is still valid in some jurisdictions IMMSMC}. Not to mention that it would constitute an admission that Microsoft already had the technology to perform the conversion {otherwise the patent would be a mere work of science fiction, therefore null and void by default}. This would have the effect of casting doubt on other things Microsoft are fond of saying.
Once a mechanism was in place for converting documents between OpenDocument and Office formats, a business would then need only one PC running Office -- and then only for as long as they have any Office files to convert to OpenDocument. Under well-established doctrines, they would even be within their rights to sell that machine to another business when it was finished with.
Who needs MIN() and MAX() anyway? What's wrong with something like SELECT height FROM suspects ORDER BY height ASC LIMIT 1 ? Come to think of it, I probably would just use SELECT * ....., read the whole record into a numeric array and pull out the field I wanted. But that's just because I'm used to using the GPL version of MySQL, which isn't so much a database but a set of extensions for implementing special large associative arrays via an abstraction layer which resembles a programming language.
Anyway, the only people who don't like the GPL are the ones from whom it was meant to protect the rest of us -- the ones who want to take someone else's hard work which they intended to be for the benefit of all, then cage it up and profit from it.
Serious question for GPL-haters: Which of the Four Freedoms don't you believe in?
Precisely.
..... At some stage, I obviously have to compile from source a compiler personalised to the machine I want to run it on -- and I am not certain that that isn't a big enough security hole to slip in something really really nasty.
AJS318's idea of "trusted computing" is where every computer has a different {but obviously user-changeable} instruction set and addressing schema, and so can only run code compiled for it. If I am administering a whole lot of PCs in an enterprise, I might choose to personalise them all the same for ease of code roll-out; but if I am just downloading and compiling apps for my own desktop machine, the personalisation can be truly unique. Of course, the risky part is bootstrapping
Veering even further offtopic but brushing against your bit about governments having access to keys, I think attempts to enforce healthy eating in schools have nothing to do with solving the problem of "childhood obesity" and everything to do with promoting the acceptance, from an early age, of being told what to do by the government. If they can tell you what to eat, it's a short step to telling you what to think.
And just how conscionable is a demand that you return your property, which you bought and paid for with your own money, which you earned by your own efforts of hand or brain, to Lexmark when they say so?
This could never happen in Britain, where we have the Unfair Contract Terms Act and the WEEE directive.
The madness will only end the day that some government somewhere decides to enforce non-discriminatory IP licencing {i.e. if you licence your IP to anybody at all, you have to licence it to everybody on exactly the same terms} -- using as punishment a court order forcing the offender's IP into the Public Domain.
..... every listener, without exception, agrees that every record they play, without exception, is shite. These are the same listeners that chose the records in the first place. QED.
Why do I believe it will take government intervention to accomplish this, rather than just letting the market decide? Human nature. Listen to a request show on the wireless
In some regimes, ones with complicated tax laws, energy recovery isn't automatically counted as recycling. Otherwise a company could spin off the department which heats its buildings as a concern in its own right, signing over all boilers, radiators, pumps, thermostats and so forth to the new company; buy the usual amount of heating fuel; immediately declare it waste {since the original company has no boilers of its own} and pay the former heating department to "recycle" the "waste" heating fuel. The original company, meanwhile, claims back any taxes it paid on the fuel, and the heating company doesn't owe tax since it is burning waste products -- which do not attract the same taxes as the fossil fuels they embarrassingly resemble. And the heating company's figures are carefully massaged so as to keep the company in the lowest possible tax band.
..... it's the equivalent of making it an offence to sell bodily waste products lest they be used for fraudulent purposes. You need to keep adding dafter and dafter laws to prop up one daft one.
That's what you get for having broken tax regimes
Now, stuff like disposable nappies {I personally would favour a hard per capita limit -- or should that be per fundamens?} and aluminised mylar crisp packets can only feasibly be recycled by burning them for the stored energy. But I am still tempted to think it should be kept as a very last resort.
Cue mass migration to PostgreSQL!
..... just have an option in the rcfile to allow Postgres-style quotes or MySQL-style quotes. {There is of course going to be a load of stuff being done with Perl, PHP and Python scripts that Postgres does natively ..... but we can deal with that later.}
..... if they're going to use a payware database, they'll use MS SQL server or Oracle.
For a user leaving MySQL, the main difference is in the quotes; MySQL uses 'single' or "double" quotes to delimit string literals and `back` quotes around field names which would otherwise conflict with reserved words, whereas PostgreSQL uses 'single' quotes to delimit string literals and "double" quotes around dodgy field names. {TTBOMK the "official" standard, if there is one, is 'single' quotes around string literals and tough titty if you want a field name that looks like a reserved word.} I reckon a simple patch would effectively fix the quotes issue
Of course, there's nothing to stop someone forking GPL MySQL. Nobody actually uses non-GPL MySQL anyway
Myself, I'm glad I live in the EU where the obligation to "reduce, reuse, recycle" trumps the right to gouge the people who pay your wages for money.