> Sorry, user mode doesn't really make much sense here, drivers need full hw access
It depends on the quality of the design of the hardware, the latency requirement of the task versus the latency guarantees of the kernel, the memory available for buffering, and the proximity of the memory to the hardware.
If the hardware has it's textures, vertex shaders, lighting data, and geometry in video memory that can be mapped directly into userspace, and some registers to give instructions and read certain bits of data, you can almost certainly put the driver in userspace, becuase it *has* all the hardware access it needs.
Of course, at the low end of the market, it is not cost-effective to put everything on the video board yet, but there is very little that needs extreme low latency (refresh triggered tasks is just about it).
There *can* be a performance hit, though it comes somewhere else. When the driver is mapped into kernel space it can be executed while the application is still mapped, that means no TLB flushes to draw. If the driver is in a second process, then the user-context must be changed and this is more expensive. To alleviate this, you need buffering, which can increase latency and make a game feel less responsive.
However, if the user-space driver code and data is mapped into the same user-space process as the game, it is not a problem. There are other issues with that...
If the driver is mapped into the process, what if it is running in a window, and another 3d program is running in another window. You can have the windows be textures on surfaces, but the hardware *must* be able to distinugish which context is drawing, and also must somehow fairly assign resources to the two. This can be done, especially since resource management does not have to be done terribly often it can be in a third process a lot of the time (though some tasks may require a lot of changes to resource assignment I'm sure).
So the hardware manufacturer must work slightly harder to create better drivers, but that just means nVidia haven't put in the effort. Imagine, you're including code into the kernel (of all things!) from a software producer that hasn't put much effort into it. How dangerous is that?
I beleive (though I do not offer legal counsel), that in the UK a consumer sale is different from a business transaction.
A consumer sale is not subject to an EULA, since they walk into a shop, pick up a box based on the flashy colours and title "Microsoft Doodaa: manage your doodaas more effectively", and pay for it. Even small print on the back may not apply since an old biddie with poor eyesight is expected to buy things without reading everything. It also means that if the box is labelled to indicate suitability for a particular purpose, then it *must* be so. Children can install it, so the EULA is not expected to apply.
A business *may* be subject to an EULA especially since a business buying software is expected to research the value of their transaction before buying - but a seller must honour the EULA return provision similarly.
If you are running a safety-critical operation, that is a business operation whether you make money by it or not. Building a mechanical gantry to get on your roof is not within the capability of normal people, so the software used is sold in a business transaction. Even if you are just making the computer operated gantry for yourself, you are smart, you have no rights - unless you can show that it is a consumer activity like making toys for your kids. You cannot sue the software manufacturer unless they told you it was safe to use for that and offered a modicum of evidence.
Having said that, software *cannot* kill people, hardware should not operate in a dangerous manner. If you have a mechanical gantry that can kill people, it should have a safety rail with a lock on it that will not unlock unless it is within, oh, say 60 cm of an adequately sized stable platform such as the floor. Any software you install to operate that hardware must have any dangerous instructions ignored unless you have by-passed the hardware's restrictions, restrictions that are complex enough to by-pass that it won't happen by accident. Thus the sofware must be malicious to by-pass it. The hardware may extend these restrictions to preventing you from installing new software, or at least *forcing* you to think again about removing the provided software that provides safety.
The fact that people spend hours of their spare time creating software purely for it's artistic value, and allowing people free access to it shows that it is a hobbyist activity.
If I make a human cannon and safety net arrangement for my own extreme sporting drive, and allow a friend that is also an extreme sportsman to use it, I am not liable for injuries. If I arrange an event and take administrative control to provide the cannon to a host of people in an orderly fashion, then that is a business persuit and I *am* liable.
Back on the "Microsoft Doodaa" software, the subtitle includes the qualification "more effectively"... If you can't read, you only heard the name and what it does, and ask for "Microsoft Doodaa", you can expect it to do it properly. Even if you *can* read, the software should provide effective management facilities, but *should* *not* *stop* *working* occasionally. A TV praised for lower eyestrain labelled "watch more TV" shouldn't switch off once a week even though it allows you to watch more TV in general.
"In other words, consider the test criteria equivalent to Nature and the various fibers as types of animals. If Nature changes a few times, an animal ideal for the latest natural conditions might have been "breeded" out of existence by a previous change in Nature."
That's why GA systems often randomly introduce brand new genomes to a population. It supplies some entropy to "tunnel" out of local minima.
Yes, I put that in my comment, but in this case it wouldn't be difficult for the compiler to spot that it can inline the method calls even though they are virtual.
And since these classes are supposed to be used in some of the other benchmarks, it may be best to leave them virtual to fairly compare how a real program would be written.
Re:One example of why the tests are BS
on
Java Faster Than C++?
·
· Score: 3, Informative
The cout is done twice, and the new and delete are each done only once. They are not the reason for the poor performance.
The problem is that g++ probably does not optimise it all inline, whereas the particular java VM he has chosen to use probably does.
Although defining the Toggle variables with auto storage class may give g++ the hint it needs to realise this.
Additionally, the activate method is declared to be virtual, this shouldn't be a problem, except that it may further hide the optimisation opportunity from g++. Note that the description of the test does not stipulate that it is testing virtual methods.
"Let's take the slippery slope to your suggestion above. Why not name every file with a.ext extension and let the OS do the rest "from the contents"? Seems to be a lot easier to me. Let's throw in some MIME types too."
The file endings on C source files are because there will be several versions of the same logical unit. They are used by the compilation system for it to manage its files in a regular fashion that can also be seen and parsed by humans. It is because there is a myunit C source file, a myunit assembly file, a myunit object file, and possibly a myunit executable or shared object and archive. This sort of thing ends up as "myunit.c", "myunit.s", "myunit.o" and "myunit" or "myunit.so" and "myunit.a". This is a part of the particular system as each file must have a different name if they often end up in the same directory, the alternative endings is a simple way to allow it.
If I had a directory that I used to rip files, I might reasonably expect the ripping software to extract from cd to files "track1.riff", "track2.riff", "track3.riff" (windows waveform files - often.wav), and I create a mixing instructions source file called "techno.insns". The automated mixing deck software only accepts flac, so in that case, my makefile encodes the riff versions of those to "track1.flac", "track2.flac" and "track3.flac", then the mixing software takes the tracks and the instructions to produce "techno.flac". Finally I encode it for web streaming with my_favorite_vorbis_encoder_that_frames_it_in_ogg to a file named "techno".
The last few characters of each filename are used by that particular build system to distinguish several components or stages of the production of a file in an orderly manner.
The file "techno" can be sent via http with a content type, it can be type-sniffed by a file browser, or have a mime type included in filesystem extended attributes, or many other schemes.
So you see, an "extension" is not necessarily even needed, it's just a name, not a type. They are often used, even on unix systems, as part of a file transformation management system. If an audio professional were trying to sell some audio archiving system, (s)he might offer files called "technosample.vorbis" and "technosample.mycompanyscoolnewcodec", but the filename is only for the users benefit because they need to tell which codec produced the best result. If it is for your music collection, the filetype_in_the_name thing is quite pointless, since your player is opening the file and will read it, it'll find the type - the listener only cares to be told the artist, album and track name.
If you have a playlist program that will choose an Ogg Flac version of a track over an Ogg Vorbis version, then they need to identify that they are the same track, so a naming scheme or comment scheme would be required anyway.
In summary I don't think the filename "standard" is an issue at all really. Name it how you feel.
what has the user's personal choice of filename got to do with usability? If you name the file "foo.ogg" it's your choice, if you name it "this_is_an_ogg_container_holding_a_vorbis_audio_s tream_named_foo", that is, similarly, your choice. The Operating System can work out what it is easily and quickly from the contents, or extended attributes can indicate the MIME type.
I remember when Intel started the Intel Inside (TM) campaign. I was asked by my school friends to confirm that an "Intel" was a special "extra" chip that makes your computer go faster.
OGG doesn't even explicitly support subtitles does it? OGG is a stream container. so it can hold one or more audio streams, one or more subtitle streams, one or video streams, etc.
In the same way that an OGG file can hold an audio stream using vorbis, along with an alternative using speex and an alternative using flac, it could have a subtitle stream which uses unicode characters.
OGG is just a container, it does not provide for data such as subtitles, audio or video. it just allows subtitles, audio and video to be contained, and synchronised.
It probably isn't a burden to the British TV license payer. The BBC gets to sell international broadcast and distribution rights. I believe that the Walking With Dinosaurs series and the Teletubbies paid for themselves several times over - though I may be misinformed, please feel free to correct me.
This open-source codec could place the BBC in an even better position internationally. It is already considered one of the worlds greatest entertainment, education and news content providers.
I would like to see them become allowed to create films for commercial purposes provided they pay for themselves - though assessing how much license fees would contribute to be considered to pay for what would have been the BBCs broadcast rights may be an obstacle.
Building a nifty little lock management facade *does* make the problem go away. That is precisely the point. The user of that interface cannot even *compile* a program that is not safe with respect to it (Not to say that C++ is any good in other respects, of course).
The only real ways to do this in Java are twofold:
1) Use synchronize, and only return the accessor object if the appropriate monitor is held. Then the accessor object throws an exception for each method if you use it without holding that monitor. But there is no reasonable way to implement a cache within that accessor object. There may be a way with several waiting threads and using notify in a complex way that will probably deadlock - but that is hardly the goal of using an object oriented design.
The problem is that leaving the synchronize block should cause all cached data in the accessor to be flushed to the *real* object - this is often necessary to guarantee performance when the main memory bus is significantly slower than the on-die cache. Furthermore, using a reference to the accessor outside of the synchronize block in which it was created should not only be prohibited - it should be inhibited.
2) Continuation passing style. But to get that inline one define a subclass inline, which means that any access to local variables requires that they be final. That is not always desirable, and frequently undesirable. This *could* be alleviated in Java with some simple changes (such as allowing reference to non-final variables if it can be guaranteed that there will remain no references to the object after return, but it is still quite ugly conceptually.
I also don't believe that the alternative of folding the cache into the real object lazily when another accessor is created is workable without an eccessive level of synchronization, possibly causing immense slowdowns on NUMA architectures.
So while, in C++, the programmer of the interface manages the resources, the interface they produce causes the user of the interface not to have to worry about it. Without that, the user of the interface must be very cautious of their use, and consider far more exceptions. And probably have to take bug reports from end-users that would *not* happen with the C++ method (as long as they don't use "&", see below).
This post is not intended to mark GC as bad, as there *may* be a solution. An object can be explicitly deleted at a given moment by waiting for notification performed in the finalize method - if the runtime guarantees to GC the object early when waiting for that notification. That is, however, difficult to make both safe and strict in Java, since the wait may be a long one, and it can be hard to statically prove that there are no other references, or to inhibit their creation. C++ also cannot utterly inhibit the creation of references to the accessor object that exists beyond its lifetime, but that is a problem with allowing pointers.
An unfortunate choice in C++ is that the register keyword is nothing more than an optimisation hint, while in C it inhibits the address-of ("&") operator. An unfortunate choice in Java is that references are just C++ pointers with no arithmetic operations - only the "dereference and resolve member" operator "." ("->" from C++) that can throw an exception, "==", and crucially, assignment.
If you write a PC emulator for the iMac, you can run *any* PC operating system on it. Unless a union of the major few operating system producers says it is not permitted to write PC emulators without paying them money in return for no copyright license, and no patent license, while the PC instruction set is not a trade secret.
The DVDCCA has no more authority to offer authorisation to make a DVD player than a small hobbyist filmmaker.
If an object is not allocated by new, but rather has automatic storage class, or is a member, then everything happens automatically.
Imagine that you have a class that represents an abstract datatype, but it has no methods to manipulate the data. It can have a method that returns an object that has the member functions necessary to access it, as well as taking an appropriate lock. If you overload operator new to prevent creating one of these on the heap the lock is completely managed, and you are guaranteed efficient, safe access.
So they program the card with their biometric data. And sign it using the governments cryptographic key, which can't simply be changed every few months so it will be easily cracked with fast computers.
The bank will *know* it was you, the police will *know* it was you, you won't ever get your money back, and they won't even look for the culprit. The whole point of the card is that it *proves* that the holder is the person named on the card, so by cracking the cryptography, criminals can assume your identity and everyone that doesn't know you in person will *know* for certain that they are the rightful owner of the property/account/ballot.
> The replies to this post will probably say "what's wrong with Linux as it is today?"
And when they do, you won't answer them, you wont tell the computer programmers that have the ability to turn you user interface ideas into reality:
A) What exactly your ideas are (sticking to fague, it should all be consistent from the ground up, sort of things), or B) Why they will make a good user interface and a preferable design over the other choices.
Everybody wants to bitch, and nobody wants to work.
Oh well, I'm off to complain at the size of my social security cheque.
Slashdot Mirror
> Sorry, user mode doesn't really make much sense here, drivers need full hw access
It depends on the quality of the design of the hardware, the latency requirement of the task versus the latency guarantees of the kernel, the memory available for buffering, and the proximity of the memory to the hardware.
If the hardware has it's textures, vertex shaders, lighting data, and geometry in video memory that can be mapped directly into userspace, and some registers to give instructions and read certain bits of data, you can almost certainly put the driver in userspace, becuase it *has* all the hardware access it needs.
Of course, at the low end of the market, it is not cost-effective to put everything on the video board yet, but there is very little that needs extreme low latency (refresh triggered tasks is just about it).
There *can* be a performance hit, though it comes somewhere else. When the driver is mapped into kernel space it can be executed while the application is still mapped, that means no TLB flushes to draw. If the driver is in a second process, then the user-context must be changed and this is more expensive. To alleviate this, you need buffering, which can increase latency and make a game feel less responsive.
However, if the user-space driver code and data is mapped into the same user-space process as the game, it is not a problem. There are other issues with that...
If the driver is mapped into the process, what if it is running in a window, and another 3d program is running in another window. You can have the windows be textures on surfaces, but the hardware *must* be able to distinugish which context is drawing, and also must somehow fairly assign resources to the two. This can be done, especially since resource management does not have to be done terribly often it can be in a third process a lot of the time (though some tasks may require a lot of changes to resource assignment I'm sure).
So the hardware manufacturer must work slightly harder to create better drivers, but that just means nVidia haven't put in the effort. Imagine, you're including code into the kernel (of all things!) from a software producer that hasn't put much effort into it. How dangerous is that?
It seems to search for exact phrases and is case sensitive.
... crap
I tried "Microsoft sucks" and it found some. and "Linux" did well, but "linux" found nothing at all!
There seems to be an exception to the case-sensitive rule: "microsoft" works just like "Microsoft".
All in all, for a billion sites indexed this search engine is so far
I beleive (though I do not offer legal counsel), that in the UK a consumer sale is different from a business transaction.
A consumer sale is not subject to an EULA, since they walk into a shop, pick up a box based on the flashy colours and title "Microsoft Doodaa: manage your doodaas more effectively", and pay for it. Even small print on the back may not apply since an old biddie with poor eyesight is expected to buy things without reading everything. It also means that if the box is labelled to indicate suitability for a particular purpose, then it *must* be so. Children can install it, so the EULA is not expected to apply.
A business *may* be subject to an EULA especially since a business buying software is expected to research the value of their transaction before buying - but a seller must honour the EULA return provision similarly.
If you are running a safety-critical operation, that is a business operation whether you make money by it or not. Building a mechanical gantry to get on your roof is not within the capability of normal people, so the software used is sold in a business transaction. Even if you are just making the computer operated gantry for yourself, you are smart, you have no rights - unless you can show that it is a consumer activity like making toys for your kids. You cannot sue the software manufacturer unless they told you it was safe to use for that and offered a modicum of evidence.
Having said that, software *cannot* kill people, hardware should not operate in a dangerous manner. If you have a mechanical gantry that can kill people, it should have a safety rail with a lock on it that will not unlock unless it is within, oh, say 60 cm of an adequately sized stable platform such as the floor. Any software you install to operate that hardware must have any dangerous instructions ignored unless you have by-passed the hardware's restrictions, restrictions that are complex enough to by-pass that it won't happen by accident. Thus the sofware must be malicious to by-pass it. The hardware may extend these restrictions to preventing you from installing new software, or at least *forcing* you to think again about removing the provided software that provides safety.
The fact that people spend hours of their spare time creating software purely for it's artistic value, and allowing people free access to it shows that it is a hobbyist activity.
If I make a human cannon and safety net arrangement for my own extreme sporting drive, and allow a friend that is also an extreme sportsman to use it, I am not liable for injuries. If I arrange an event and take administrative control to provide the cannon to a host of people in an orderly fashion, then that is a business persuit and I *am* liable.
Back on the "Microsoft Doodaa" software, the subtitle includes the qualification "more effectively"... If you can't read, you only heard the name and what it does, and ask for "Microsoft Doodaa", you can expect it to do it properly. Even if you *can* read, the software should provide effective management facilities, but *should* *not* *stop* *working* occasionally. A TV praised for lower eyestrain labelled "watch more TV" shouldn't switch off once a week even though it allows you to watch more TV in general.
No, everybody will sue to car manufacturer. They are far more likely to get paid.
No, they did it quite reasonably, although the only mention of some alternatives is in a slashbox at the side.
"In other words, consider the test criteria equivalent to Nature and the various fibers as types of animals. If Nature changes a few times, an animal ideal for the latest natural conditions might have been "breeded" out of existence by a previous change in Nature."
That's why GA systems often randomly introduce brand new genomes to a population. It supplies some entropy to "tunnel" out of local minima.
Yes, I put that in my comment, but in this case it wouldn't be difficult for the compiler to spot that it can inline the method calls even though they are virtual.
And since these classes are supposed to be used in some of the other benchmarks, it may be best to leave them virtual to fairly compare how a real program would be written.
The cout is done twice, and the new and delete are each done only once. They are not the reason for the poor performance.
The problem is that g++ probably does not optimise it all inline, whereas the particular java VM he has chosen to use probably does.
Although defining the Toggle variables with auto storage class may give g++ the hint it needs to realise this.
Additionally, the activate method is declared to be virtual, this shouldn't be a problem, except that it may further hide the optimisation opportunity from g++. Note that the description of the test does not stipulate that it is testing virtual methods.
"Let's take the slippery slope to your suggestion above. Why not name every file with a .ext extension and let the OS do the rest "from the contents"? Seems to be a lot easier to me. Let's throw in some MIME types too."
.wav), and I create a mixing instructions source file called "techno.insns". The automated mixing deck software only accepts flac, so in that case, my makefile encodes the riff versions of those to "track1.flac", "track2.flac" and "track3.flac", then the mixing software takes the tracks and the instructions to produce "techno.flac". Finally I encode it for web streaming with my_favorite_vorbis_encoder_that_frames_it_in_ogg to a file named "techno".
The file endings on C source files are because there will be several versions of the same logical unit. They are used by the compilation system for it to manage its files in a regular fashion that can also be seen and parsed by humans. It is because there is a myunit C source file, a myunit assembly file, a myunit object file, and possibly a myunit executable or shared object and archive. This sort of thing ends up as "myunit.c", "myunit.s", "myunit.o" and "myunit" or "myunit.so" and "myunit.a". This is a part of the particular system as each file must have a different name if they often end up in the same directory, the alternative endings is a simple way to allow it.
If I had a directory that I used to rip files, I might reasonably expect the ripping software to extract from cd to files "track1.riff", "track2.riff", "track3.riff" (windows waveform files - often
The last few characters of each filename are used by that particular build system to distinguish several components or stages of the production of a file in an orderly manner.
The file "techno" can be sent via http with a content type, it can be type-sniffed by a file browser, or have a mime type included in filesystem extended attributes, or many other schemes.
So you see, an "extension" is not necessarily even needed, it's just a name, not a type. They are often used, even on unix systems, as part of a file transformation management system. If an audio professional were trying to sell some audio archiving system, (s)he might offer files called "technosample.vorbis" and "technosample.mycompanyscoolnewcodec", but the filename is only for the users benefit because they need to tell which codec produced the best result. If it is for your music collection, the filetype_in_the_name thing is quite pointless, since your player is opening the file and will read it, it'll find the type - the listener only cares to be told the artist, album and track name.
If you have a playlist program that will choose an Ogg Flac version of a track over an Ogg Vorbis version, then they need to identify that they are the same track, so a naming scheme or comment scheme would be required anyway.
In summary I don't think the filename "standard" is an issue at all really. Name it how you feel.
speexenc and mv to rename it to something sensible.
what has the user's personal choice of filename got to do with usability? If you name the file "foo.ogg" it's your choice, if you name it "this_is_an_ogg_container_holding_a_vorbis_audio_s tream_named_foo", that is, similarly, your choice. The Operating System can work out what it is easily and quickly from the contents, or extended attributes can indicate the MIME type.
Yeah, but so are my FLAC files, and my Speex files, I've also got some video (theora) files that are named with .ogg.
I've also got some of each that don't have any file suffixes beginning with dot
"Imagine if wagon-wheel manufacturers had
criminalized the tire."
Or jam!
I remember when Intel started the Intel Inside (TM) campaign. I was asked by my school friends to confirm that an "Intel" was a special "extra" chip that makes your computer go faster.
No, *that* was the Germans:
From Diebold's About Us - History - The Early Yearsturn them into fur coats, oil, and pig feed
OGG doesn't even explicitly support subtitles does it? OGG is a stream container. so it can hold one or more audio streams, one or more subtitle streams, one or video streams, etc.
In the same way that an OGG file can hold an audio stream using vorbis, along with an alternative using speex and an alternative using flac, it could have a subtitle stream which uses unicode characters.
OGG is just a container, it does not provide for data such as subtitles, audio or video. it just allows subtitles, audio and video to be contained, and synchronised.
It probably isn't a burden to the British TV license payer. The BBC gets to sell international broadcast and distribution rights. I believe that the Walking With Dinosaurs series and the Teletubbies paid for themselves several times over - though I may be misinformed, please feel free to correct me.
This open-source codec could place the BBC in an even better position internationally. It is already considered one of the worlds greatest entertainment, education and news content providers.
I would like to see them become allowed to create films for commercial purposes provided they pay for themselves - though assessing how much license fees would contribute to be considered to pay for what would have been the BBCs broadcast rights may be an obstacle.
Building a nifty little lock management facade *does* make the problem go away. That is precisely the point. The user of that interface cannot even *compile* a program that is not safe with respect to it (Not to say that C++ is any good in other respects, of course).
The only real ways to do this in Java are twofold:
1) Use synchronize, and only return the accessor object if the appropriate monitor is held. Then the accessor object throws an exception for each method if you use it without holding that monitor. But there is no reasonable way to implement a cache within that accessor object. There may be a way with several waiting threads and using notify in a complex way that will probably deadlock - but that is hardly the goal of using an object oriented design.
The problem is that leaving the synchronize block should cause all cached data in the accessor to be flushed to the *real* object - this is often necessary to guarantee performance when the main memory bus is significantly slower than the on-die cache. Furthermore, using a reference to the accessor outside of the synchronize block in which it was created should not only be prohibited - it should be inhibited.
2) Continuation passing style. But to get that inline one define a subclass inline, which means that any access to local variables requires that they be final. That is not always desirable, and frequently undesirable. This *could* be alleviated in Java with some simple changes (such as allowing reference to non-final variables if it can be guaranteed that there will remain no references to the object after return, but it is still quite ugly conceptually.
I also don't believe that the alternative of folding the cache into the real object lazily when another accessor is created is workable without an eccessive level of synchronization, possibly causing immense slowdowns on NUMA architectures.
So while, in C++, the programmer of the interface manages the resources, the interface they produce causes the user of the interface not to have to worry about it. Without that, the user of the interface must be very cautious of their use, and consider far more exceptions. And probably have to take bug reports from end-users that would *not* happen with the C++ method (as long as they don't use "&", see below).
This post is not intended to mark GC as bad, as there *may* be a solution. An object can be explicitly deleted at a given moment by waiting for notification performed in the finalize method - if the runtime guarantees to GC the object early when waiting for that notification. That is, however, difficult to make both safe and strict in Java, since the wait may be a long one, and it can be hard to statically prove that there are no other references, or to inhibit their creation. C++ also cannot utterly inhibit the creation of references to the accessor object that exists beyond its lifetime, but that is a problem with allowing pointers.
An unfortunate choice in C++ is that the register keyword is nothing more than an optimisation hint, while in C it inhibits the address-of ("&") operator.
An unfortunate choice in Java is that references are just C++ pointers with no arithmetic operations - only the "dereference and resolve member" operator "." ("->" from C++) that can throw an exception, "==", and crucially, assignment.
If you write a PC emulator for the iMac, you can run *any* PC operating system on it. Unless a union of the major few operating system producers says it is not permitted to write PC emulators without paying them money in return for no copyright license, and no patent license, while the PC instruction set is not a trade secret.
The DVDCCA has no more authority to offer authorisation to make a DVD player than a small hobbyist filmmaker.
If an object is not allocated by new, but rather has automatic storage class, or is a member, then everything happens automatically.
Imagine that you have a class that represents an abstract datatype, but it has no methods to manipulate the data. It can have a method that returns an object that has the member functions necessary to access it, as well as taking an appropriate lock. If you overload operator new to prevent creating one of these on the heap the lock is completely managed, and you are guaranteed efficient, safe access.
> That would be the biometric identifiers
So they program the card with their biometric data. And sign it using the governments cryptographic key, which can't simply be changed every few months so it will be easily cracked with fast computers.
The bank will *know* it was you, the police will *know* it was you, you won't ever get your money back, and they won't even look for the culprit. The whole point of the card is that it *proves* that the holder is the person named on the card, so by cracking the cryptography, criminals can assume your identity and everyone that doesn't know you in person will *know* for certain that they are the rightful owner of the property/account/ballot.
No the *first* thing I *didn't* think of was Ruby Wax making sweet love to an elderly orangutan.
> Wind turbines ... will affect the local climate
At least in England that might go some way to making up for the incredible deforestation that has occurred over the last couple of millenia.
> The replies to this post will probably say "what's wrong with Linux as it is today?"
And when they do, you won't answer them, you wont tell the computer programmers that have the ability to turn you user interface ideas into reality:
A) What exactly your ideas are (sticking to fague, it should all be consistent from the ground up, sort of things), or
B) Why they will make a good user interface and a preferable design over the other choices.
Everybody wants to bitch, and nobody wants to work.
Oh well, I'm off to complain at the size of my social security cheque.