Hmm, it would be interesting to know what network card you are having trouble with. This quite sounds like a bug to me.
With regards to your comments about FreeBSD 5.x and Dragonfly, I'd like to mention a few things..
- It is very easy to have a high speed of development in a new project. People are focussed on the project goals and there is little 'distraction' in the form of people actually using the project. It is about as difficult to keep an old project making progress because of the opposite conditions being true in general.
- If KSE and ULE are such good ideas is debatable, but seeing your post, you are interested in trying them. This architecture took its time to develop, and if you followed the smp mailinglist in the last few years, you'd see that that development was not easy, and in fact, noone before FreeBSD managed to implement this architecture in a workable way (while it looks very promising in theory, in practise it comes with lots of nice little problems)
I think Dragonfly is a very usefull addition to the *BSD family because of the exact work that you mention, a multithreaded network stack. It may bring more equally important new developments in the future if it can keep up its pase of development.
> DragonFly seems to be doing better in this department (it looks as if thier "light weight kernel threading" subsystem has allowed them to almost completely multi-thread their network stack in roughly a one month period (the project itself being little over one year old)
I did my own reimplementation of the FreeBSD network stack at some point so I do have some idea what the code looks like and what kind of work would be involved..
The biggest part of it is properly splitting up the code, as it is now, it is mostly concentrated in a few HUGE functions that are almost impossible to maintain.
From there to a multithreaded implementation is not such a big issue once you have settled on an architecture for multithreading inside the kernel.
It seems that the method chosen by Dragonfly results in a lot less work in the kernel then what FreeBSD chose.
> while the FreeBSD folks *still* have not made significant progress doing the same with 5.x (no, even with 5.3 there is more code that cannot function without the big giant lock than there is code that can run happily without it)).
How much code can run without it is hardly relevant. How much time is spent running such code is of major relevance.
This of course would suggest that the network stack is something to look at....
At any rate, lightweight kernel threads lead to fast results for Dragonfly. If it will keep supporting that in the future is a question for me. Almost always such quicker solutions come to bite you a little bit later. If it does however then all the better. It is good to actually see multiple different branches of development for this.
First of all, congrats on writing an actually somewhat funny troll.
As is the case with most trolls, the 'information' provided is incorrect. Lets look at the specifics..
> --To support SMP
FreeBSD has supported SMP for years, and 5.3 still does. You can argue all you want about which smp implementation is better, but that doesn't change that it is supported.
> --To generate media attention
Your post was a reply to one form of media attention it is getting. Don't think it needs any further comments.
> --To spawn a professionally managed distribution
Ah... like the 200+ incompatible Linux distributions? I'd seriously look at this one again because this is one of the things where it does better then any linux distribution.
> --To innovate...
> --To be relevant.
Maybe not to you. I'd hope you refrain from using for exampel Yahoo and Hotmail in the future tho.. else it might just become somewhat relevant for you also.
At any rate.. I had a bit of a chuckle, you at least found a funny way for posting your nonsense.
Hmm, looks like I'll have to skip beta 1 for my smp machine.
Built and installed it earlier this week, and it crashes under heavy load.
The problem is documented and should be fixed in the next beta, so guess I'll have to wait for a bit there.
Just thought I should post this in case others want to try.. be sure to build yourself a non-smp kernel just in case..
Except for this specific issue, it seems to work quite nicely.
Re:Upgrading from 5.2.1 to 5.3-BETA1 a little bump
on
FreeBSD 5.3 Beta1
·
· Score: 1
> I thought mergemaster was supposed to prepare your system for installworld, and that buildworld was just for compiling the system (not installing it).
mergemaster is for upgrading your/etc directory mostly.
There are cases where make buildworld depends on what is in your/etc directory (ie: make.conf, and in this case, the groups and password files)
So no, it is not to prepare your system for an install, it is to upgrade your configuration for the new version.
> How many CPU architectures does nVidia release binary drivers for? This may be less of an issue for AGP cards (hmm, AMD64?), but you'll find PCI cards in x86, PPC, MIPS and Sparc boxes.
heh, x86 only for what I know.
> An open source Linux (or BSD) driver can be recompiled to support any of those (modulo some CPU-specific tweaking). I somehow doubt an x86 binary driver is as versatile.
Yep, quite a good point.
There are many more good arguments for open source drivers.
In the days of Xfree 3.3.x it did help a lot to be able to build the mga driver and opengl/glx hacks for the specific x86 variation that you had.. it would still help nowadays I'd think.
That doesn't change that the drivers as nvidia releases them should be usable to most people.
For me it is more a practical choice.. I want a cheap but relatively powerfull system (hardware) and don't want to bother with Windows for the little gaming that I do every now and then (mostly some quake3 engine based games). With the nvidia hardware I do not get the best possible picture quality, nor do I get open source drivers.. but I do get a card that happens to do the job I want it to do very well for very little. (and hrm, it does the job a lot better then equivalent ati hardware with oss drivers performance wise)
If I were to install a pci graphics card in some non x86 machine, I'd be on the lookout for whomever supports open source... but I'm a bit less likely to want fast opengl from it (exception maybe when running on a ppc mac)
I do know quite well what problems there were with 5.x, and have posted about them on here also.
Basicly, as logn as you kept acpi out of the kernel, kept to the bsd42 scheduler and libc_r, the old driver worked as well as in 4.x
Turn any of those on and your results can vary anywhere between very usable and crashing at the start of X.
This was finally fixed with the new driver indeed.
Would this be easier with an open source driver? definitely.
The problem is all the 'locked up' ip that is being used in the graphics card hardware and drivers. Untill companies start dealing differently with that (which may take a change to the whole ip system for at least some of them) we either get an open source driver or such binary drivers.
For most nvidia hardware, the Xfree/Xorg nv driver worked quite well as long as you didn't need 3d acceleration.
I used it for soem time untill I had the time to bother with the old driver and 5.x again, but mostly for some 'office' work and watching video.
Was kinda funny... about 2 weeks after I bothered to get the old driver to work, nvidia came with the new one.
While I recognize the problem you speak of, I disagree with your example. The drivers from nVidia require a little bit of work to install, but have been working at least for me on about any linux distro that I tried (as well as on FreeBSD, even on the at that moment explicitly non supported development version) An issue with Linux may be your kernel configuration tho.
The way nVidia solves this is about the only way to get binary drivers that do work more or less independent of what release of the OS you use.
You do have to get the drivers with the module sources tho, getting a pre-packaged binary for your distibution did not ever get me usefull results.
if we replace SnafuCard.v2 with for example nVidia's RIVA TNT or TNT2, then we actually find that those are supported by the manufacteror with their Linux drivers.
THey also have a (recently updated) FreeBSD driver btw.
I do have the impression that once they got the framework in place, releasing those drivers is very little efford for them and it does a nice thing for their reputation.
Of course this doesn't prove much beyond that it might be a good idea to look at each individual case and not draw generalized conclusions.
> Didn't NDIS start out as a portable driver standard, anyway? Netware, OS/2 and Windows, wasn't it? What would be really elegant is to use some sort of code translation to allow the drivers to be used on non-ix86 machines...
NDIS started out as a specification for a multi protocol stack, ie, it would allow you to bind netbeui, tcp/ip and appn protocols to the same network interface.
Windows and OS/2 both use NDIS stacks but did not use the same implementation, so drivers were not exchangable between the 2. Maybe they are now, haven't looked at OS/2 in almost half a decade.
I run Linux on some early/mid 90s SGI hardware, and that stuff is retty usefull, and even to modern standards far from slow (wouldn't call it fast anymore)
A $400 PC from 5+ years ago might not be that usefull, but my dual pII machine from 5 years ago now has pIII cpus, and can run for another couple of years easily before performance might become an issue with some of the software that it runs (mostly web server, mail server etc). Yeah, that machine costed a bit more also.
On another note.. I bet those nice IBM mainframes that run Linux get replaced every 5 years as well..
The notion that 5 years old hardware is outdated is simply silly. At best it is true for some specific desktop use, and mostly gaming.
> There aren't too many other players that can adjust brightness and contrast. Resize and adjust a number of other features. The problem with the player is the media support. Can't play quicktime files etc.
> If someone can name a real strong windows media player alternative PLEASE SPEAK!!
To answer both questions at once, take a peek at mplayer (mentioned repeatedly throughout the discussion already), there is a win32 version as well.
I have never used the windows version myself, but the unix (hello people, mplayer is NOT Linux specific in any way) version does all that you ask for, can use hardware for scaling in quite a few cases and given that you have the codecs, will play about any media you throw at it (it does play anything from realmedia to quicktime to wmv to mpeg4 to whatever..)
> Yet they make the leading word processor, spread sheet, developer environment, desktop operating system, and media player
Last time I looked, those are 'leading' in marketshare, not in technology. Now, the post you replied to was talking about leading in technology.
> the open source world is trying hard to clone them, and ease of use is measured with respect to the standard they set.
Clone as in look and feel? yes.
But let em tell you something, the leading OSS office package, OpenOFfice is based on the much older StarOffice. Now, StarOffice was around a decade ago as well, and has been leading MS in usefull features and integration for quite some time.
You are somewhat right in one thing: MS does set the standard for the interface with which people operate their computer, but even that one is a ripoff (no, not talking about windows beign a ripoff of the ancient mac or looking back to Xerox times, just that the concept and metafor behind the Windws 9x/2k/2k3/xp desktops comes from the Workplace Shell that was used by OS/2, and was there quite some time before MS got to market with their variation)
In other words, the parent you replied to is entirely right, MS is not leading and has never been technically, and except for detail enhancements, their products are functional ripoffs of pre-existing competitive products or at times competitors they bought out. Oh, and as a nice sidenote, MS didn't write Word or Excel, they bought it.
So.. you are only somewhat right with regards to the cosmetics side of the thing.
> You need the bios to be customized to support the feature (instantOn is its own BIOS) and you need memory (flash?) to store it. It will raise the price at least as much as a cheap portable player.
Now, lets see...
Needed for DVD/MP3 playback: 1 flash memory for OS and player 2 small change to bios code 3 media reader hardware
Now, 1 and 2 can be combined on the same chip, and last time I checked flash memory was not extremely expensive. The 3rd item from the list you already needed anyway, so that makes the total cost of this the cost for a slightly larger bit of flash memory if there isn't space available in the installed module already, and the cost of a small bios change.
I do not know how much flash memory costs at your place, but here I can buy a lot more then the few mb required for this for the price of a portable DVD player.
> Some people like to have a word processor, email client, mp3/music player, development environment, web pages, network files and thier favorite game running at the same time
Well.. for quite a few games you want to have fullscreen display and dedicated sound.. so the mp3 player is useless already, and unless it is doing something in the background, your IDE is not that usefull either.. I can see the use for a web browser for looking up stuff for playing (givemn that you can switch the game to running in a window of course wlese your browser is kinda out of reach)
Yeah, it depends on the game.. but with many games, having a zillion other apps open does no good (since you can't reach the apps) and can do a lot of bad (since they interfer with the game, either by claimning memory, cpu or sound hardware)
Of course.. I do run an mp3 player while playign a mud with a mudclient... but hrm.. I also have a seperately configured version of X for playing RTCW and Enemy Territory, this to give maximum resources to those games.
Having a seperate X config for it means having to stop X and restart it before playing, but the experience of playing without interference from other programs is rather worth it.
> Can you do that if your output is a class library (.dll or.so)? This is an honest question.
First of all, it is purely theoretical, I am not actually aware of a compuiler doing this automatically but I have done it manually as a result of verbose compiler output a few times.
It is something that you can do well for anything that you have the source for and that is statically linked into your binary. You cannot do it that easily if at all for something that is linked dynamically, if only because in that case the actual linking happens at runtime, so after you do your optimizing, while compilation is completely independent of your project.
You could include a.so or.dll in your project and try this, but it will very likely break whenever some other binary tries to use this shared library, so not a good idea at all.
So, not for shared libraries, but if you build statically linked libraries specifically for this project you can.
What this of course gets you is a situation where if you have a shared library that implements a class with a virtual method, the runtime environment cannot do anything with the knowledge that it is not overloaded. This of course is different when running JAVA in a JVM.
If you were to run C++ in a VM, you would not have this limitation either, while if you were to run JAVA compiled to a native binary you would get the same limitations.
So... mail is stopped at this 'firewall' and only valid mail is allowed through... sounds good but how exactly is that different from an mta with spam filter?
You are aware that there exist garbage collectors for c/c++?
Also, in the example you give, you can know that a virtual method is never going to be overridden before runtime, you do need to link your.o files tho, so it is after compile time. THere is however no theoretical reason why you cannot decide at that time to recompile a bit of code to get the exact same optimizing as you could with java.
There are other cases where you can't tell things untill you are actually running the code, and java can indeed have a performance advantage there that is only possible in c/c++ when you do extensive profiling and debugging (to see what is really happening) and direct the compiler properly by correct hinting.
That hinting is something you cannot do in java, so well.. it depends in part on the code and how well it takes advantage of the specific environment.
For java you have to do less work to get the best performance then for c/c++ for some situations.
Slashdot Mirror
Hrm... your submit button seems to have an auto repeat function.. tell me, how do you get it to do that?
Hmm, it would be interesting to know what network card you are having trouble with. This quite sounds like a bug to me.
With regards to your comments about FreeBSD 5.x and Dragonfly, I'd like to mention a few things..
- It is very easy to have a high speed of development in a new project. People are focussed on the project goals and there is little 'distraction' in the form of people actually using the project. It is about as difficult to keep an old project making progress because of the opposite conditions being true in general.
- If KSE and ULE are such good ideas is debatable, but seeing your post, you are interested in trying them. This architecture took its time to develop, and if you followed the smp mailinglist in the last few years, you'd see that that development was not easy, and in fact, noone before FreeBSD managed to implement this architecture in a workable way (while it looks very promising in theory, in practise it comes with lots of nice little problems)
I think Dragonfly is a very usefull addition to the *BSD family because of the exact work that you mention, a multithreaded network stack.
It may bring more equally important new developments in the future if it can keep up its pase of development.
> DragonFly seems to be doing better in this department (it looks as if thier "light weight kernel threading" subsystem has allowed them to almost completely multi-thread their network stack in roughly a one month period (the project itself being little over one year old)
I did my own reimplementation of the FreeBSD network stack at some point so I do have some idea what the code looks like and what kind of work would be involved..
The biggest part of it is properly splitting up the code, as it is now, it is mostly concentrated in a few HUGE functions that are almost impossible to maintain.
From there to a multithreaded implementation is not such a big issue once you have settled on an architecture for multithreading inside the kernel.
It seems that the method chosen by Dragonfly results in a lot less work in the kernel then what FreeBSD chose.
> while the FreeBSD folks *still* have not made significant progress doing the same with 5.x (no, even with 5.3 there is more code that cannot function without the big giant lock than there is code that can run happily without it)).
How much code can run without it is hardly relevant. How much time is spent running such code is of major relevance.
This of course would suggest that the network stack is something to look at....
At any rate, lightweight kernel threads lead to fast results for Dragonfly. If it will keep supporting that in the future is a question for me. Almost always such quicker solutions come to bite you a little bit later. If it does however then all the better. It is good to actually see multiple different branches of development for this.
First of all, congrats on writing an actually somewhat funny troll.
...
As is the case with most trolls, the 'information' provided is incorrect. Lets look at the specifics..
> --To support SMP
FreeBSD has supported SMP for years, and 5.3 still does. You can argue all you want about which smp implementation is better, but that doesn't change that it is supported.
> --To generate media attention
Your post was a reply to one form of media attention it is getting. Don't think it needs any further comments.
> --To spawn a professionally managed distribution
Ah... like the 200+ incompatible Linux distributions? I'd seriously look at this one again because this is one of the things where it does better then any linux distribution.
> --To innovate
> --To be relevant.
Maybe not to you. I'd hope you refrain from using for exampel Yahoo and Hotmail in the future tho.. else it might just become somewhat relevant for you also.
At any rate.. I had a bit of a chuckle, you at least found a funny way for posting your nonsense.
Gee... I have an old Ericsson phone... and a Palmtop..
There is free software for my palmtop for converting and editing (midi like) ringtones.. I can transfer them using infrared or bluetooth...
This all is like 3 years old.. you are telling me that 'modern' phones no longer allow this kind of thing? that is insane.
Hmm, looks like I'll have to skip beta 1 for my smp machine.
Built and installed it earlier this week, and it crashes under heavy load.
The problem is documented and should be fixed in the next beta, so guess I'll have to wait for a bit there.
Just thought I should post this in case others want to try.. be sure to build yourself a non-smp kernel just in case..
Except for this specific issue, it seems to work quite nicely.
> I thought mergemaster was supposed to prepare your system for installworld, and that buildworld was just for compiling the system (not installing it).
/etc directory mostly.
/etc directory (ie: make.conf, and in this case, the groups and password files)
mergemaster is for upgrading your
There are cases where make buildworld depends on what is in your
So no, it is not to prepare your system for an install, it is to upgrade your configuration for the new version.
> How many CPU architectures does nVidia release binary drivers for? This may be less of an issue for AGP cards (hmm, AMD64?), but you'll find PCI cards in x86, PPC, MIPS and Sparc boxes.
heh, x86 only for what I know.
> An open source Linux (or BSD) driver can be recompiled to support any of those (modulo some CPU-specific tweaking). I somehow doubt an x86 binary driver is as versatile.
Yep, quite a good point.
There are many more good arguments for open source drivers.
In the days of Xfree 3.3.x it did help a lot to be able to build the mga driver and opengl/glx hacks for the specific x86 variation that you had.. it would still help nowadays I'd think.
That doesn't change that the drivers as nvidia releases them should be usable to most people.
For me it is more a practical choice.. I want a cheap but relatively powerfull system (hardware) and don't want to bother with Windows for the little gaming that I do every now and then (mostly some quake3 engine based games). With the nvidia hardware I do not get the best possible picture quality, nor do I get open source drivers.. but I do get a card that happens to do the job I want it to do very well for very little. (and hrm, it does the job a lot better then equivalent ati hardware with oss drivers performance wise)
If I were to install a pci graphics card in some non x86 machine, I'd be on the lookout for whomever supports open source... but I'm a bit less likely to want fast opengl from it (exception maybe when running on a ppc mac)
I do know quite well what problems there were with 5.x, and have posted about them on here also.
Basicly, as logn as you kept acpi out of the kernel, kept to the bsd42 scheduler and libc_r, the old driver worked as well as in 4.x
Turn any of those on and your results can vary anywhere between very usable and crashing at the start of X.
This was finally fixed with the new driver indeed.
Would this be easier with an open source driver? definitely.
The problem is all the 'locked up' ip that is being used in the graphics card hardware and drivers. Untill companies start dealing differently with that (which may take a change to the whole ip system for at least some of them) we either get an open source driver or such binary drivers.
For most nvidia hardware, the Xfree/Xorg nv driver worked quite well as long as you didn't need 3d acceleration.
I used it for soem time untill I had the time to bother with the old driver and 5.x again, but mostly for some 'office' work and watching video.
Was kinda funny... about 2 weeks after I bothered to get the old driver to work, nvidia came with the new one.
While I recognize the problem you speak of, I disagree with your example. The drivers from nVidia require a little bit of work to install, but have been working at least for me on about any linux distro that I tried (as well as on FreeBSD, even on the at that moment explicitly non supported development version)
An issue with Linux may be your kernel configuration tho.
The way nVidia solves this is about the only way to get binary drivers that do work more or less independent of what release of the OS you use.
You do have to get the drivers with the module sources tho, getting a pre-packaged binary for your distibution did not ever get me usefull results.
Well.. in theory you could do that with modules I'd think...
Still in the kernel, just linked dynamically instead of statically.
Well, lets take a real world example.
if we replace SnafuCard.v2 with for example nVidia's RIVA TNT or TNT2, then we actually find that those are supported by the manufacteror with their Linux drivers.
THey also have a (recently updated) FreeBSD driver btw.
I do have the impression that once they got the framework in place, releasing those drivers is very little efford for them and it does a nice thing for their reputation.
Of course this doesn't prove much beyond that it might be a good idea to look at each individual case and not draw generalized conclusions.
> Didn't NDIS start out as a portable driver standard, anyway? Netware, OS/2 and Windows, wasn't it? What would be really elegant is to use some sort of code translation to allow the drivers to be used on non-ix86 machines...
NDIS started out as a specification for a multi protocol stack, ie, it would allow you to bind netbeui, tcp/ip and appn protocols to the same network interface.
Windows and OS/2 both use NDIS stacks but did not use the same implementation, so drivers were not exchangable between the 2. Maybe they are now, haven't looked at OS/2 in almost half a decade.
I run Linux on some early/mid 90s SGI hardware, and that stuff is retty usefull, and even to modern standards far from slow (wouldn't call it fast anymore)
A $400 PC from 5+ years ago might not be that usefull, but my dual pII machine from 5 years ago now has pIII cpus, and can run for another couple of years easily before performance might become an issue with some of the software that it runs (mostly web server, mail server etc). Yeah, that machine costed a bit more also.
On another note.. I bet those nice IBM mainframes that run Linux get replaced every 5 years as well..
The notion that 5 years old hardware is outdated is simply silly. At best it is true for some specific desktop use, and mostly gaming.
> I will not buy it if it does not support Linux, even if it is for a Windows PC as I know someday I will run Linux and not windows with it.
By which time someoen most likely reverse engineered the thing and made a linux driver anyway..
I am not so sure that IBM would be unwilling to cross-license with them.. they have done a fair share of it in the past (also after the OS/2 fallout)
> There aren't too many other players that can adjust brightness and contrast. Resize and adjust a number of other features. The problem with the player is the media support. Can't play quicktime files etc.
> If someone can name a real strong windows media player alternative PLEASE SPEAK!!
To answer both questions at once, take a peek at mplayer (mentioned repeatedly throughout the discussion already), there is a win32 version as well.
I have never used the windows version myself, but the unix (hello people, mplayer is NOT Linux specific in any way) version does all that you ask for, can use hardware for scaling in quite a few cases and given that you have the codecs, will play about any media you throw at it (it does play anything from realmedia to quicktime to wmv to mpeg4 to whatever..)
> Yet they make the leading word processor, spread sheet, developer environment, desktop operating system, and media player
Last time I looked, those are 'leading' in marketshare, not in technology. Now, the post you replied to was talking about leading in technology.
> the open source world is trying hard to clone them, and ease of use is measured with respect to the standard they set.
Clone as in look and feel? yes.
But let em tell you something, the leading OSS office package, OpenOFfice is based on the much older StarOffice. Now, StarOffice was around a decade ago as well, and has been leading MS in usefull features and integration for quite some time.
You are somewhat right in one thing: MS does set the standard for the interface with which people operate their computer, but even that one is a ripoff (no, not talking about windows beign a ripoff of the ancient mac or looking back to Xerox times, just that the concept and metafor behind the Windws 9x/2k/2k3/xp desktops comes from the Workplace Shell that was used by OS/2, and was there quite some time before MS got to market with their variation)
In other words, the parent you replied to is entirely right, MS is not leading and has never been technically, and except for detail enhancements, their products are functional ripoffs of pre-existing competitive products or at times competitors they bought out. Oh, and as a nice sidenote, MS didn't write Word or Excel, they bought it.
So.. you are only somewhat right with regards to the cosmetics side of the thing.
> Those wont slow down standby / hibernation....
Cool, so I can put (popup) hell in standby or even hibernate mode?
> You need the bios to be customized to support the feature (instantOn is its own BIOS) and you need memory (flash?) to store it. It will raise the price at least as much as a cheap portable player.
Now, lets see...
Needed for DVD/MP3 playback:
1 flash memory for OS and player
2 small change to bios code
3 media reader hardware
Now, 1 and 2 can be combined on the same chip, and last time I checked flash memory was not extremely expensive.
The 3rd item from the list you already needed anyway, so that makes the total cost of this the cost for a slightly larger bit of flash memory if there isn't space available in the installed module already, and the cost of a small bios change.
I do not know how much flash memory costs at your place, but here I can buy a lot more then the few mb required for this for the price of a portable DVD player.
I am getting this deja vue feeling... anyone here remembers the Commodore plus 4?
> Some people like to have a word processor, email client, mp3/music player, development environment, web pages, network files and thier favorite game running at the same time
Well.. for quite a few games you want to have fullscreen display and dedicated sound.. so the mp3 player is useless already, and unless it is doing something in the background, your IDE is not that usefull either.. I can see the use for a web browser for looking up stuff for playing (givemn that you can switch the game to running in a window of course wlese your browser is kinda out of reach)
Yeah, it depends on the game.. but with many games, having a zillion other apps open does no good (since you can't reach the apps) and can do a lot of bad (since they interfer with the game, either by claimning memory, cpu or sound hardware)
Of course.. I do run an mp3 player while playign a mud with a mudclient... but hrm.. I also have a seperately configured version of X for playing RTCW and Enemy Territory, this to give maximum resources to those games.
Having a seperate X config for it means having to stop X and restart it before playing, but the experience of playing without interference from other programs is rather worth it.
> Can you do that if your output is a class library (.dll or .so)? This is an honest question.
.so or .dll in your project and try this, but it will very likely break whenever some other binary tries to use this shared library, so not a good idea at all.
First of all, it is purely theoretical, I am not actually aware of a compuiler doing this automatically but I have done it manually as a result of verbose compiler output a few times.
It is something that you can do well for anything that you have the source for and that is statically linked into your binary. You cannot do it that easily if at all for something that is linked dynamically, if only because in that case the actual linking happens at runtime, so after you do your optimizing, while compilation is completely independent of your project.
You could include a
So, not for shared libraries, but if you build statically linked libraries specifically for this project you can.
What this of course gets you is a situation where if you have a shared library that implements a class with a virtual method, the runtime environment cannot do anything with the knowledge that it is not overloaded. This of course is different when running JAVA in a JVM.
If you were to run C++ in a VM, you would not have this limitation either, while if you were to run JAVA compiled to a native binary you would get the same limitations.
So... mail is stopped at this 'firewall' and only valid mail is allowed through... sounds good but how exactly is that different from an mta with spam filter?
> Java Virtual Machine hardware implementation.
Somehow this sounds a bit like a paradox..
You are aware that there exist garbage collectors for c/c++?
.o files tho, so it is after compile time. THere is however no theoretical reason why you cannot decide at that time to recompile a bit of code to get the exact same optimizing as you could with java.
Also, in the example you give, you can know that a virtual method is never going to be overridden before runtime, you do need to link your
There are other cases where you can't tell things untill you are actually running the code, and java can indeed have a performance advantage there that is only possible in c/c++ when you do extensive profiling and debugging (to see what is really happening) and direct the compiler properly by correct hinting.
That hinting is something you cannot do in java, so well.. it depends in part on the code and how well it takes advantage of the specific environment.
For java you have to do less work to get the best performance then for c/c++ for some situations.