But many companies do copy code to one extent or another. If a company has some code under one license (perhaps that they purchased), it is likely incompatible wit the GPL and MySQL could enforce against them.
If they don't distribute, how are they infringing the GPL? Or perhaps you are talking of other licenses which forbid exposure or linking to GPL licensed material?
Why should someone sponsor the change when you are already licensing InnoDB from InnoBase for the commercial version of MySQL? Obviously this is something that MySQL's paying customers are probably asking for.
How is it obvious that paying customers are asking for this feature? Are you a paying customer?
It may be that some paying customers are asking for but perhaps Innobase has decided that they do not want to implement it or perhaps the price that have asked for to add the feature is not affordable - to be honest, I do not know! In any case, MySQL is not going to fork InnoDB... development of InnoDB has always and will continue to be in Innobase's hands.
You should be trying to convince Innobase to implement the feature instead of blaming MySQL for the lack of it.
(opinions are my own, not of my employer nor of anyone else)
At last! A reasonable sounding criticism - so rare on Slashdot.
What would be the list of priorities for you for features/changes to be made to MySQL in order for you to seriously concider it. Bear in mind that MySQL does not have an infinite amount of developers so delivering on all of them overnight would not happen.
What would be the minimum set of requirements for you and what would comprise the expanded set which would be nice to have but not immediately urgent.
I personally cannot say much about performance statistics that other people trumpet. The only one which was published widely and compared several vendor's databases using the same app and hardware was the review conducted by eWeek a couple of years ago. AFAIK only InnoDB was used on MySQL during testing.
If your application links against the client library, it must adhere to the GPL. This is NOT a myth unless you know of an alternate client library.
I still fail to see how adhering to the GPL would prevent a company from actually using GPL products. The GPL would only come into play if the company was distributing software products and services which made use of or was derived from GPL code. The last time I checked, the overwhelming majority of companies on this planet are not software companies.
Maybe I should, if one generator supported MMX while another supports SSE and yet another SSE2 and so on, but no single one supported them all.
I am pretty sure that the PPC970 code generator doesn't support those... and the x86_64 code generator doesn't support Altivec... and the ARM code generator supports none of those mentioned already.
Worse yet, the Java-bytecode generator completely ignores the "register" variable attribute!
It's a solution necessary because the prerequisite is flawed to begin with IMHO. You say that the storage engine providers have to implement feature X. Where did the idea come from that a separated storage and parser is actually a good idea?
Just because no one else has done it like that, doesn't mean it is a bad idea. Perhaps you should complain about GCC having separated the code generator from the parser? Or maybe you want to grumble that the whole concept of having seperate drivers from the kernel is equally flawed and that they should always be in one monolithic kernel, hmmm?
It is good to innovate - don't berate us just because we are different.
(opinions are my own, not of my employer nor anyone else)
MyISAM was never designed with transactions in mind. It performs its intended function excellently. Not all data is useful to keep in some kind of transaction context - take for example a table mapping UPC codes to product names and descriptions: it will never need to change in a transaction so having transactional overhead would be wasteful.
This is typical LAMP programmer thinking. What do I need transactions and data integrity in a database for? I'll just code the checks into my application. I prefer instead to put checks both in the database and in the application.
Mmmm'kay... so if there is a performance bottleneak in accessing a table which is essentially constants, the developer decides to simply hard code all that rather than keeping it all in the database. Great. Seen it done many times.
This is no myth. MySQL's client libraries are definitely GPL. If you link to them you must abide by the terms of the GPL. Alternatively, you can purchase a license from MySQL AB. MySQL AB spins this up so much saying that they are open source but what they really mean is that they are open so long as you are open.
I personally know of many companies which make use of MySQL and have never publically released any code and are still abiding by the GPL. MySQL obviously encourages support contracts for companies using MySQL internally but does not force people to license MySQL in the non-GPL form if their use of MySQL is strictly internal. ie: no binary distribution etc.
I personally use BSD-style licenses for many of my personal project code (see for example the PC-Net simulation code in Xen) but I will equally defend the GPL against FUD attacks. There is nothing stopping companies from using GPL code within their organisation.
Well, you're forgetting that InnoDB is not developed my MySQL. For InnoDB to have fulltext searches, the Innobase guys have to fit it into their storage engine.
For where you see problems, I try to see a possible solution. The storage engine API supports fulltext indicies, its up to the storage engine implementor to actually implement that functionality.
Perhaps there will one day be a storage engine which is both transactional and supports fulltext indicies - right now there is no such thing for MySQL. For a feature to be developed either requries it to be on the roadmap or requires someone (or perhaps a group) to sponsor a feature to be developed.
Are you willing to sponsor such a feature? If yes, phone up the MySQL sales team, they will be happy to arrange business with you. If not and you just want it for free... well, you can code it yourself if you want, it is all open-source!
Then when I want to search, I have to throw in an extra join.
Only when you need to do a fulltext search or access a column stored there. Partitioning large rows is quite common anyways as a method to improve performance. Otherwise, why not have all your data in one table and have huge rows?
There will be no need to pressure existing users off from InnoDB.... InnoDB is GPL code and as such will always be available: This is the strength of open source software, it is very hard for players to pick up their toys and leave the sandbox. If they leave the sandbox, they have to leave their toys there. Besides, Oracle has stated that they do not intend to change Innobase's business. Lets hope that they keep that promise.
Of course, MySQL can encourage people to use a particular product choice based upon future roadmaps but I don't imagine that InnoDB support will ever be axed.
(opinions are my own, not of my employer nor anyone else)
With MySQL, it's often hard to get all the features you want at one time. In the case of full text indexes, you can't also have transactions because only InnoDB has transactions.
You know, it really depends.... If you are creative, you can have your cake and eat it too.
The most straightforward way would be to create a MyISAM table with the same primary key as the InnoDB table. If the commit succeeds to the InnoDB table, you can safely add the row to the MyISAM table and have your fulltext indicies there. Do something similar for deleting rows and for updates if neccessary.
You know, it may seem "obvious" that Oracle acquired Innobase and Sleepycat to hurt MySQL AB but I am not sure if MySQL really competes in the same application space as Oracle. They are two very different products.
Have you concidered that Oracle has started to acquire opensource companies because they have suddenly discovered that companies like IBM, Novell and Sun may have something profitable in their open-source strategies and wants to get a piece of that pie?
Who knows what Oracle's reasons are. Only they do. Why must people assume the most malicious reason all the time?
(disclaimer: opinions are my own and not of my employer nor anyone else)
Anyway, on a lighter note, this new engine looks pretty hot, and like it could take MySQL in a lot of directions that I never really foresaw it going.
I think it would be fun to make MySQL as versatile as possible with a huge choice of plug-ins available. Sort of like what Linux is for operating systems but for databases instead. MySQL is platform agnostic and want it to perform well everywhere, including Microsoft Windows and even... SCO (hey, its not their customer's fault).
If there is anyone out there which has some kind of data storage/retreval system, I am sure that MySQL would be happy to assist and encourage them to make it into a storage engine for MySQL. If they want to GPL their code and join the open-source party, I am sure MySQL would be happy to help in that too.
(1) "MySQL has many applications written for it" * Not if you enable strict mode, or if you use storage engines that don't support the features you need.
If your application is designed for MySQL specificially without strict mode, then strict mode is not for you. It is more useful to people porting their applications from some other product to MySQL than to the existing MySQL user base.
(2) "MySQL is optionally SQL compliant with strict mode" * Only if you want to forego 99% of the existing MySQL applications, and start fresh.
Ditto above. Perhaps the existing MySQL user wants to go to strict mode in order to support databases *other* than MySQL. Have you concidered that?
(3) "MySQL has transactions" * Not in MyISAM, which means no full text indexing.
MyISAM was never designed with transactions in mind. It performs its intended function excellently. Not all data is useful to keep in some kind of transaction context - take for example a table mapping UPC codes to product names and descriptions: it will never need to change in a transaction so having transactional overhead would be wasteful.
(4) "MySQL is free" * Only if your application which links against the client library is also GPL.
Myth used to scare people away from opensource GPL code.
(5) "MySQL is fast" * Only if you use MyISAM, which means no transactions or many other features that aren't available in MyISAM.
Some people would disagree with that statement. Quite a lot of people have found that for their needs, MySQL is lighter and faster (or at least, as fast as the big name products) even when never using MyISAM tables.
There will be people whose needs are best served with products from Oracle, IBM, Microsoft, Sybase... I am sure that no one in MySQL claims that it is the only solution to all problems: MySQL is a young database product which is actively being developed so it will improve.
Oh, I doubt that there is a single MySQL developer who would be offended. We are not so aloof that we cannot take criticism - actually we welcome constructive criticism, it lets us know what needs to be improved.
Perhaps we have been a bit lazy: Assuming that the partnership with Innobase would continue forever and that MySQL would eventually acquire Innobase.
MySQL has a few advantages - it is a small company which can react quickly to unexpected changes. We learn. Jim Starkey has joined us - he is a veteran of relational database designs and a delight to work with - and we do plan to have our own storage engines with transactional goodness, we already have Cluster but we need something more lightweight usuable by everyone.
In the meanwhile, it is good to take advantage of the MySQL architecture and make partnerships which can make use of one of our strengths. Having 3rd party storage engines is something which has been quietly encouraged for many years and is now something I think will see more publicity.
(disclaimer: opinions are my own and not of my employer nor anyone else)
That is an obvious difference but not the most surprising difference. The non-transactional MyISAM tables can be very useful for referential (read mostly, update rarely) data for which transactions are not useful. There are other non-transactional storage engines such as CSV.
I think a more startling difference for users between the different storage engines is that of Referential Integrity - foreign keys are currently only supported within InnoDB.
This is something which I personally hope will change in the near future and become available for all (transactional) storage engines. Alas, it is not easy to do - if it was, everyone would already have multiple storage engines with it.
(disclaimer: my views are my own and not that of my employer nor anyone else)
Isn't it better to have a choice of technologies? Also isn't it better to have friends and partnerships than make enemies or treat everyone else as foe? Isn't it better to be able to choose how you want your data stored than to have no choice whatsoever? MySQL is about choice... You can choose to use it or you can choose to use something else. You can choose to store your data in InnoDB, BerkeleyDB, Cluster, MyISAM, Memory, CSV - or if you have very specific requirements, something you put together yourself - the code is all GPL open source.
Besides, the most complex part of any modern database system is the optimizer - which has to use many heuristics to guess an optimal way to retrieve the data requested taking into account what indicies are available and the performance characteristics of the underlying storage engine. The actual storage engine only has to be as fast as possible in execution and keep transaction state and isolation between connections (for transactional storage engines). A good transactional storage engine takes a long time to design and an even longer amount of time to prove. I am sure that DBAs would much prefer to entrust their data to an engine which is based upon proven technology than something which is unknown and all new and shiny.
Freedom of choice is always a good thing.
MySQL is not about having cheap database... MySQL is about Freedom of choice.
(disclaimer: opinions are my own and not of my employer or anyone else)
SGI wasn't the only vendor who replaced damaged media...
When one of the install diskettes for Lotus 1-2-3 became unreadable, all I had to do was post the damaged floppy to Lotus with sufficient return postage and they sent a replacement back.
At the time, this seemed perfectly normal - lots of vendors did that kind of thing.
And software came with *real* manuals, sometimes ring-bound, often spiral-bound. Written in English and actually *useful*.
And tech support was worth calling when you have a problem - and you didn't get some snot-nosed dork who was reading from a script.
My only problem to getting access to my past is getting hold of a working 5.25" diskette drive but all the floppies are accounted for and present.
I seem to have misplaced the cassettes I had for the ZX-81 and Spectrum but I have the cassette player. Recently discovered that I have lost the ZX printer but I still have 5 rolls of paper for it.
What is amazing is how the stuff on the 3.5" floppy disks are still quite readable.
One of these days I'll get around to transferring them to DAT tape for longer term storage.
It may probably make more sense to send Hubble into Luna orbit rather than into free space... Less energy and easy to locate and has one BIG bonus: when its on the far side, the Moon is acting as a giant shield against all the crap that Earth emits.
Unless the user has to switch to CGA 80x25 text mode or if the encrypted data is a bitmap already suitable to blt to the video framebuffer, the user interface of the user's operating system will have access to the unencrypted plaintext.
Just imagine fitting some kind of data capture trojan into the target machine's font renderer. Is this a vector of attack which has been concidered?
Besides, this all does nothing to help against the classical hardware man-in-middle attacks such as a keystroke sniffer device between the keyboard and the computer.
Interesting idea but I think we will all be better served with a new ethernet wire protocol which is simple, transparent and secure. A truely worthy challenge which would benefit the majority of users and would be non-trivial to design.
I am not sure as to if the idea was taken anywhere.... but on the QEMU mailing lists as long as a year ago suggested implementing the following:
A simple hard drive partition boot sector to load QEMU stored in the empty spare-space at the start of a hard drive before the first partition. This QEMU would perform monitoring of the guest operating system in a largely transparent manner, allowing the OS to boot after it and perform any hardware access it needs while hiding itself from the guest operating system.
In this senerio, there is no host operating system. The guest operating system is responsible for controlling all hardware devices.... and the QEMU code would be relatively simple as it only has to emulate a small number of privileged instructions in order to hide itself, so any performance loss would be tiny... perhaps fractions of a percent.
The suggested use for such a thing was for reverse-engineering of closed-source device drivers but it can be easily applied to anything - even code injection into the guest operating system.
Source code is not documentation.... In much the same way that uncooked dough is not the ingredients to bread.
With the source code, you can compile the application into a runnable state in much the same way you can bake the dough to make bread.
(Of course, people who have no knowledge in software design and no meaningful experience in software development are likely to make this mistake and assume that source code is a viable replacement to documentation)
Obviously, you are either too young to have ever use dial-up electronic Bulletin Board Systems (BBS) with a simple terminal emulator... or you are a computer newbie who hasn't realised that the unwashed masses was using a distributed network of computers before the internet became cheaply available.
In those days (ok - we are only talking about 15 years or so), modems would report "NO CARRIER" when the connection was lost. Actually they still do but the user never sees what goes on between the computer and modem anymore.
Ahh, nostalgia... I remember wasting time playing multiplayer "Global Thermonuclear War"... since the round-trip-time for FidoNET email could be measured in days, a game would take weeks!
Slashdot Mirror
If they don't distribute, how are they infringing the GPL? Or perhaps you are talking of other licenses which forbid exposure or linking to GPL licensed material?
Honestly, I want to know.
How is it obvious that paying customers are asking for this feature? Are you a paying customer?
It may be that some paying customers are asking for but perhaps Innobase has decided that they do not want to implement it or perhaps the price that have asked for to add the feature is not affordable - to be honest, I do not know! In any case, MySQL is not going to fork InnoDB
You should be trying to convince Innobase to implement the feature instead of blaming MySQL for the lack of it.
(opinions are my own, not of my employer nor of anyone else)
At last! A reasonable sounding criticism - so rare on Slashdot.
What would be the list of priorities for you for features/changes to be made to MySQL in order for you to seriously concider it. Bear in mind that MySQL does not have an infinite amount of developers so delivering on all of them overnight would not happen.
What would be the minimum set of requirements for you and what would comprise the expanded set which would be nice to have but not immediately urgent.
I still fail to see how adhering to the GPL would prevent a company from actually using GPL products. The GPL would only come into play if the company was distributing software products and services which made use of or was derived from GPL code. The last time I checked, the overwhelming majority of companies on this planet are not software companies.
I am pretty sure that the PPC970 code generator doesn't support those... and the x86_64 code generator doesn't support Altivec... and the ARM code generator supports none of those mentioned already.
Worse yet, the Java-bytecode generator completely ignores the "register" variable attribute!
Time for you to start complaining?
Just because no one else has done it like that, doesn't mean it is a bad idea. Perhaps you should complain about GCC having separated the code generator from the parser? Or maybe you want to grumble that the whole concept of having seperate drivers from the kernel is equally flawed and that they should always be in one monolithic kernel, hmmm?
It is good to innovate - don't berate us just because we are different.
(opinions are my own, not of my employer nor anyone else)
Mmmm'kay... so if there is a performance bottleneak in accessing a table which is essentially constants, the developer decides to simply hard code all that rather than keeping it all in the database. Great. Seen it done many times.
I personally know of many companies which make use of MySQL and have never publically released any code and are still abiding by the GPL. MySQL obviously encourages support contracts for companies using MySQL internally but does not force people to license MySQL in the non-GPL form if their use of MySQL is strictly internal. ie: no binary distribution etc.
I personally use BSD-style licenses for many of my personal project code (see for example the PC-Net simulation code in Xen) but I will equally defend the GPL against FUD attacks. There is nothing stopping companies from using GPL code within their organisation.
(opinions are my own and not of my employer)
Well, you're forgetting that InnoDB is not developed my MySQL. For InnoDB to have fulltext searches, the Innobase guys have to fit it into their storage engine.
For where you see problems, I try to see a possible solution. The storage engine API supports fulltext indicies, its up to the storage engine implementor to actually implement that functionality.
Perhaps there will one day be a storage engine which is both transactional and supports fulltext indicies - right now there is no such thing for MySQL. For a feature to be developed either requries it to be on the roadmap or requires someone (or perhaps a group) to sponsor a feature to be developed.
Are you willing to sponsor such a feature? If yes, phone up the MySQL sales team, they will be happy to arrange business with you. If not and you just want it for free... well, you can code it yourself if you want, it is all open-source!
Only when you need to do a fulltext search or access a column stored there. Partitioning large rows is quite common anyways as a method to improve performance. Otherwise, why not have all your data in one table and have huge rows?
There will be no need to pressure existing users off from InnoDB .... InnoDB is GPL code and as such will always be available: This is the strength of open source software, it is very hard for players to pick up their toys and leave the sandbox. If they leave the sandbox, they have to leave their toys there. Besides, Oracle has stated that they do not intend to change Innobase's business. Lets hope that they keep that promise.
Of course, MySQL can encourage people to use a particular product choice based upon future roadmaps but I don't imagine that InnoDB support will ever be axed.
(opinions are my own, not of my employer nor anyone else)
You know, it really depends.... If you are creative, you can have your cake and eat it too.
The most straightforward way would be to create a MyISAM table with the same primary key as the InnoDB table. If the commit succeeds to the InnoDB table, you can safely add the row to the MyISAM table and have your fulltext indicies there. Do something similar for deleting rows and for updates if neccessary.
It is not rocket science.
You know, it may seem "obvious" that Oracle acquired Innobase and Sleepycat to hurt MySQL AB but I am not sure if MySQL really competes in the same application space as Oracle. They are two very different products.
Have you concidered that Oracle has started to acquire opensource companies because they have suddenly discovered that companies like IBM, Novell and Sun may have something profitable in their open-source strategies and wants to get a piece of that pie?
Who knows what Oracle's reasons are. Only they do. Why must people assume the most malicious reason all the time?
(disclaimer: opinions are my own and not of my employer nor anyone else)
I think it would be fun to make MySQL as versatile as possible with a huge choice of plug-ins available. Sort of like what Linux is for operating systems but for databases instead. MySQL is platform agnostic and want it to perform well everywhere, including Microsoft Windows and even... SCO (hey, its not their customer's fault).
If there is anyone out there which has some kind of data storage/retreval system, I am sure that MySQL would be happy to assist and encourage them to make it into a storage engine for MySQL. If they want to GPL their code and join the open-source party, I am sure MySQL would be happy to help in that too.
If your application is designed for MySQL specificially without strict mode, then strict mode is not for you. It is more useful to people porting their applications from some other product to MySQL than to the existing MySQL user base.
Ditto above. Perhaps the existing MySQL user wants to go to strict mode in order to support databases *other* than MySQL. Have you concidered that?
MyISAM was never designed with transactions in mind. It performs its intended function excellently. Not all data is useful to keep in some kind of transaction context - take for example a table mapping UPC codes to product names and descriptions: it will never need to change in a transaction so having transactional overhead would be wasteful.
Myth used to scare people away from opensource GPL code.
Some people would disagree with that statement. Quite a lot of people have found that for their needs, MySQL is lighter and faster (or at least, as fast as the big name products) even when never using MyISAM tables.
There will be people whose needs are best served with products from Oracle, IBM, Microsoft, Sybase... I am sure that no one in MySQL claims that it is the only solution to all problems: MySQL is a young database product which is actively being developed so it will improve.
Oh, I doubt that there is a single MySQL developer who would be offended. We are not so aloof that we cannot take criticism - actually we welcome constructive criticism, it lets us know what needs to be improved.
Perhaps we have been a bit lazy: Assuming that the partnership with Innobase would continue forever and that MySQL would eventually acquire Innobase.
MySQL has a few advantages - it is a small company which can react quickly to unexpected changes. We learn. Jim Starkey has joined us - he is a veteran of relational database designs and a delight to work with - and we do plan to have our own storage engines with transactional goodness, we already have Cluster but we need something more lightweight usuable by everyone.
In the meanwhile, it is good to take advantage of the MySQL architecture and make partnerships which can make use of one of our strengths. Having 3rd party storage engines is something which has been quietly encouraged for many years and is now something I think will see more publicity.
(disclaimer: opinions are my own and not of my employer nor anyone else)
That is an obvious difference but not the most surprising difference. The non-transactional MyISAM tables can be very useful for referential (read mostly, update rarely) data for which transactions are not useful. There are other non-transactional storage engines such as CSV.
I think a more startling difference for users between the different storage engines is that of Referential Integrity - foreign keys are currently only supported within InnoDB.
This is something which I personally hope will change in the near future and become available for all (transactional) storage engines. Alas, it is not easy to do - if it was, everyone would already have multiple storage engines with it.
(disclaimer: my views are my own and not that of my employer nor anyone else)
Isn't it better to have a choice of technologies? Also isn't it better to have friends and partnerships than make enemies or treat everyone else as foe? Isn't it better to be able to choose how you want your data stored than to have no choice whatsoever? MySQL is about choice... You can choose to use it or you can choose to use something else. You can choose to store your data in InnoDB, BerkeleyDB, Cluster, MyISAM, Memory, CSV - or if you have very specific requirements, something you put together yourself - the code is all GPL open source.
Besides, the most complex part of any modern database system is the optimizer - which has to use many heuristics to guess an optimal way to retrieve the data requested taking into account what indicies are available and the performance characteristics of the underlying storage engine. The actual storage engine only has to be as fast as possible in execution and keep transaction state and isolation between connections (for transactional storage engines). A good transactional storage engine takes a long time to design and an even longer amount of time to prove. I am sure that DBAs would much prefer to entrust their data to an engine which is based upon proven technology than something which is unknown and all new and shiny.
Freedom of choice is always a good thing.
MySQL is not about having cheap database... MySQL is about Freedom of choice.
(disclaimer: opinions are my own and not of my employer or anyone else)
SGI wasn't the only vendor who replaced damaged media...
When one of the install diskettes for Lotus 1-2-3 became unreadable, all I had to do was post the damaged floppy to Lotus with sufficient return postage and they sent a replacement back.
At the time, this seemed perfectly normal - lots of vendors did that kind of thing.
And software came with *real* manuals, sometimes ring-bound, often spiral-bound. Written in English and actually *useful*.
And tech support was worth calling when you have a problem - and you didn't get some snot-nosed dork who was reading from a script.
I'll stop my rant now.
My only problem to getting access to my past is getting hold of a working 5.25" diskette drive but all the floppies are accounted for and present.
I seem to have misplaced the cassettes I had for the ZX-81 and Spectrum but I have the cassette player. Recently discovered that I have lost the ZX printer but I still have 5 rolls of paper for it.
What is amazing is how the stuff on the 3.5" floppy disks are still quite readable.
One of these days I'll get around to transferring them to DAT tape for longer term storage.
It may probably make more sense to send Hubble into Luna orbit rather than into free space... Less energy and easy to locate and has one BIG bonus: when its on the far side, the Moon is acting as a giant shield against all the crap that Earth emits.
Hmm... How about a Luna-orbit radio telescope?
Unless the user has to switch to CGA 80x25 text mode or if the encrypted data is a bitmap already suitable to blt to the video framebuffer, the user interface of the user's operating system will have access to the unencrypted plaintext.
Just imagine fitting some kind of data capture trojan into the target machine's font renderer. Is this a vector of attack which has been concidered?
Besides, this all does nothing to help against the classical hardware man-in-middle attacks such as a keystroke sniffer device between the keyboard and the computer.
Interesting idea but I think we will all be better served with a new ethernet wire protocol which is simple, transparent and secure. A truely worthy challenge which would benefit the majority of users and would be non-trivial to design.
There are nearly 400,000 Jedi Knights in the United Kingdom http://www.statistics.gov.uk/census2001/profiles/c ommentaries/ethnicity.asp... So if you know enough people from the UK, chances are, you may already know a Jedi Knight who knows the answer.
I am not sure as to if the idea was taken anywhere.... but on the QEMU mailing lists as long as a year ago suggested implementing the following:
... perhaps fractions of a percent.
A simple hard drive partition boot sector to load QEMU stored in the empty spare-space at the start of a hard drive before the first partition. This QEMU would perform monitoring of the guest operating system in a largely transparent manner, allowing the OS to boot after it and perform any hardware access it needs while hiding itself from the guest operating system.
In this senerio, there is no host operating system. The guest operating system is responsible for controlling all hardware devices.... and the QEMU code would be relatively simple as it only has to emulate a small number of privileged instructions in order to hide itself, so any performance loss would be tiny
The suggested use for such a thing was for reverse-engineering of closed-source device drivers but it can be easily applied to anything - even code injection into the guest operating system.
Source code is not documentation.... In much the same way that uncooked dough is not the ingredients to bread.
With the source code, you can compile the application into a runnable state in much the same way you can bake the dough to make bread.
(Of course, people who have no knowledge in software design and no meaningful experience in software development are likely to make this mistake and assume that source code is a viable replacement to documentation)
Obviously, you are either too young to have ever use dial-up electronic Bulletin Board Systems (BBS) with a simple terminal emulator ... or you are a computer newbie who hasn't realised that the unwashed masses was using a distributed network of computers before the internet became cheaply available.
... since the round-trip-time for FidoNET email could be measured in days, a game would take weeks!
In those days (ok - we are only talking about 15 years or so), modems would report "NO CARRIER" when the connection was lost. Actually they still do but the user never sees what goes on between the computer and modem anymore.
Ahh, nostalgia... I remember wasting time playing multiplayer "Global Thermonuclear War"
Good times....