Windows Update is a really nice mechanism for distributing patches and updates - none of the Linux vendors (even Mandrake) come close to that level of functionality.
Actually Debian does a great job with network updates, although it uses a command-line interface instead of a button. RedHat also has similar functionality in RPM and a fairly nice GUI interface to this tool called GnoRPM.
Both of these tools are much better than Windows update IMHO, because they also update applications (including server applications with security holes) in addition to updating the kernel itself.
I'm fairly certain both of these distributions had this functionality before Microsoft "innovated" the Windows update mechanism.
--d
Great! Now all we need is to get this thing running on human sweat (or motion) instead of battery power. Once we get apache running, I'll lose 20 pounds a week!
Who needs another library that doesn't offer any new functionality? When I have to use GTK+ in C++ applications, I simply wrap the most commonly used components myself. What's the point of making the user obtain yet another library?
Yesterday we were complaining about DLL hell/lack of code reuse, and here we are today talking about another implementation of something that already exists.
"Dynamic linking simply does not fit in with a healthy model of average joe, consumer desktop computing."
One major problem with this is libraries which depend on hardware in order to function. The first such library that comes to mind is OpenGL. I have used two separate implementations of this library, the pure software Mesa, and a GL implementation from 3dfx for my Voodoo3. As a developer, how do I know which one to use? What you are suggesting implies linking against all possibile versions of a library, dramatically increasing the number of distributions. Also, this is not exactly feasable, as some implementations of GL have yet to be written.
IMHO better management of shared object libraries makes much more sense than the automatic static linking of everything.
Well, I've just been reading a great big book on OpenGL (OpenGL Superbible... forgive me for not remembering the authors' name... it's at home, I'm at work) and it strongly suggests (for performance reasons) not sending ANY geometry to OpenGL which will not get rendered.
The clippng which the book does by example would work just fine with this type of hack though, because it uses the frustum (basically, the d3-area of the camera view) to determine whether or not to render an object. IMHO if game manufacturers would take this one step further by implementing some kind of depth test, eliminating geometry behind walls, etc., then this type of card could have no effect whatsoever.
Hi everyone. I have been a SlashLeech(tm) for a while now, but I feel compeled to speak.
CmdrTaco seems to reffer to the relationship between browser and server in the same capacity as model/view/controller separation used widely in programming circles. From this point of view, the user interface is part of the program, and therefore subject to GPL rules.
In the early days of the web, we just had content. Nobody envisioned that the browser could become an interface to large scale applications. The GPL appears to suffer from this same blind spot which afflicted (or afflicts) the browser implementations of today. They are not equipped to deal with an entity which can at the same time be both program output and part of a binary application program.
I feel torn by this issue, not wishy-washy, so don't interpret my next statement the wrong way. I feel that the GPL should be modified to be explicit about allowing what is already happening today on a massive scale: the GPL should not alienate any market segment which helped make it mainstream. Image the massive amount of work necessary to make 50% or so (open for debate) of existing web sites which would have to change to accomodate this. --Peace out
Jon... you're preaching to the choir here. We have been discussing and thinking about these issues for months now. What we need is a real and effective defense against the kind of corporate greed and power that you describe. I would suggest lobbying, but it can be prohibativly expensive. It sucks to keep rehashing this stuff every time a new "survey" comes out. I fail to see what legitemacy this study has over any other. This one just happens to contain exactly what we want to hear.
Slashdot Mirror
Actually Debian does a great job with network updates, although it uses a command-line interface instead of a button. RedHat also has similar functionality in RPM and a fairly nice GUI interface to this tool called GnoRPM.
Both of these tools are much better than Windows update IMHO, because they also update applications (including server applications with security holes) in addition to updating the kernel itself.
I'm fairly certain both of these distributions had this functionality before Microsoft "innovated" the Windows update mechanism.
--d
Great! Now all we need is to get this thing running on human sweat (or motion) instead of battery power. Once we get apache running, I'll lose 20 pounds a week!
Who needs another library that doesn't offer any new functionality? When I have to use GTK+ in C++ applications, I simply wrap the most commonly used components myself. What's the point of making the user obtain yet another library?
Yesterday we were complaining about DLL hell/lack of code reuse, and here we are today talking about another implementation of something that already exists.
Ukab the Great wrote:
"Dynamic linking simply does not fit in with a healthy model of average joe, consumer desktop computing."
One major problem with this is libraries which depend on hardware in order to function. The first such library that comes to mind is OpenGL. I have used two separate implementations of this library, the pure software Mesa, and a GL implementation from 3dfx for my Voodoo3. As a developer, how do I know which one to use? What you are suggesting implies linking against all possibile versions of a library, dramatically increasing the number of distributions. Also, this is not exactly feasable, as some implementations of GL have yet to be written.
IMHO better management of shared object libraries makes much more sense than the automatic static linking of everything.
--d
Damn. Sorry about that last post... I forgot a closing tag symbol. I know... use the preview.
:
...jar is a general-purpose archiving and compression tool, based on ZIP and the ZLIB compression format...
from the jar tool documentation
You can even use winzip (ug) to crack jars open.
--d
from the jar tool :
...jar is a general-purpose archiving and compression tool, based on ZIP and the ZLIB compression format...
You can even use winzip (ug) to crack jars open.
--d
A Java JAR is simply a ZIP file. Not very useful for knowing about details of the file system structure of a dozen distributions.
An install system could use the jar format for distribution, but by itself it does not help fix any of the issues brought forth in the article.
--d
Well, I've just been reading a great big book on OpenGL (OpenGL Superbible... forgive me for not remembering the authors' name... it's at home, I'm at work) and it strongly suggests (for performance reasons) not sending ANY geometry to OpenGL which will not get rendered.
The clippng which the book does by example would work just fine with this type of hack though, because it uses the frustum (basically, the d3-area of the camera view) to determine whether or not to render an object. IMHO if game manufacturers would take this one step further by implementing some kind of depth test, eliminating geometry behind walls, etc., then this type of card could have no effect whatsoever.
Peace
Hi everyone. I have been a SlashLeech(tm) for a while now, but I feel compeled to speak.
CmdrTaco seems to reffer to the relationship between browser and server in the same capacity as model/view/controller separation used widely in programming circles. From this point of view, the user interface is part of the program, and therefore subject to GPL rules.
In the early days of the web, we just had content. Nobody envisioned that the browser could become an interface to large scale applications. The GPL appears to suffer from this same blind spot which afflicted (or afflicts) the browser implementations of today. They are not equipped to deal with an entity which can at the same time be both program output and part of a binary application program.
I feel torn by this issue, not wishy-washy, so don't interpret my next statement the wrong way. I feel that the GPL should be modified to be explicit about allowing what is already happening today on a massive scale: the GPL should not alienate any market segment which helped make it mainstream. Image the massive amount of work necessary to make 50% or so (open for debate) of existing web sites which would have to change to accomodate this.
--Peace out
Jon... you're preaching to the choir here. We have been discussing and thinking about these issues for months now. What we need is a real and effective defense against the kind of corporate greed and power that you describe. I would suggest lobbying, but it can be prohibativly expensive. It sucks to keep rehashing this stuff every time a new "survey" comes out. I fail to see what legitemacy this study has over any other. This one just happens to contain exactly what we want to hear.