In relation to this: How important is Civ IV's introduction of Python? Do you think having a real programming language will make a difference to the quality and realism of game AI, or merely provide an easier way of doing things that could have been done anyway with the more usual methods?
It affects it if MS decides they're going to require installers to use this service. They'd have to make it free-as-in-beer, but what about requiring you to give MS rights to your code, or promising not to make it run on any other OS, if you want free access, or a small fee that larger companies can pay to use it and keep their code.
Underage people aren't allowed to consent because we feel they aren't able to reason fully about the consequences, they don't really know what will happen and how it will affect their life. The same is in all likelihood true of horses.
"Wasn't designed for it" is a cop-out. UNIX wasn't designed as a desktop OS, but that doesn't mean that Mac OS X isn't an excellent desktop OS.
OSX is not unix, most of the GUI layer runs independently of the unix base. Would you seriously advocate unix as a destop OS?
Things move on. Things change. Things advance. The web has done so. Was the web originally designed for running applications? Maybe not. But the myriad ways in which it has moved on - Javascript, cookies, TLS, etc - have enabled it to grow and become an applications platform. Its original design is of no importance because what matters is the properties it holds today. Perhaps you would like me to judge Java and X on what they were like fifteen years ago as well?
X you certainly can. Java wasn't around then, but you can judge it from the point when it was. Both were built from the ground up for remote applications.
Aspects of the web have changed, but HTTP is still the same as it always was, and still sucks for doing remote applications.
You are advocating X and Java - where you are likely to find computers without either available on a regular basis - and then criticising the web because if you try hard, you might be able to think of one or two devices that are connected to the Internet but don't have web browsers.
I'm not criticising the web, I'm just saying both are equal in this respect. Yes, there's a quantative difference in the numbers of computers with one or the other, but there's no fundamental difference. I have yet to see a computer with a working web browser but no Java.
You seem to think using the web for applications is good because web browsers are more widely deployed. Would you advocate using MS Word for DTP tasks, because you can do them in word and Word is on just about every computer?
Do some research and you'll find that pornography usage is strikingly correlated with serious felonies (domestic abuse, rape, incest, murder...) as well as correlated with the development of many phsycological pathologies.
Maybe you should do some research. Most types of pornography have no detectable effect on temperament or attitudes, in fact I only know of one sort (that which promotes the "rape fantasy") which has been shown to have any negative effects. Any type of porn has far far less correlation with crime etc. than alcohol, and see your history for the effects of banning that.
It's perfectly possible to write secure web applications. The only reason you see so many web application vulnerbilities is that the learning curve for writing web applications is so shallow, you get a lot of inexperienced developers writing them, and because the barrier to using a web application is so thin that these inexperienced developers can get a lot of people using their software.
That's not just it, the web wasn't designed to handle the issues involved with running applications. Sure, you can write secure web applications, just like you can write highly readable perl or functional programs in C, but it's a lot harder when the platform isn't designed for it.
X applications are executed on the client, not the server.
Only in X terminology. It's server-side in the sense that a number of computers will normally use X applications running on a single, larger computer.
Java and X suffer from the same problem - you have to install stuff to get it to work everywhere. You can't count on them being available, so if you need to run something, then you end up carrying software with you anyway, which defeats the purpose.
And with web applications you have to count on a web browser being available. Sure, you'll find them most places because the web is enormously overused and overemphasised, but I've seen internet-connected computers without them, and plenty of windows machines with the only browser (IE) in an unusable state.
So far, a Linux system secure against hostile user code does not exist because it hasn't been proven to exist, and because there is a sufficient body of evidence to show that no amount of claiming Linux is secure will make it secure.
You're treating security as a binary thing here. Yes, a Linux system isn't absolutely secure when faced with hostile user code, but it is more secure than when faced with hostile root code.
In the realm of installing software, this means you are forced to trust the program itself due to privilege escalation, just as you would have to trust maintainer scripts that are executed as root.
Yes, you have to trust it, but you don't have to trust it absolutely. You need to trust code and scripts more to run them as root than as a user since it's easier to cause trouble when running as root. Just like I have friends I trust enough to give user accounts but not root access on my box. Yes, there's a certain amount of trust needed to grant user access, but not as much as for root.
Maintainer scripts are extremely useful to keeping a package in a working state, and throwing them out as a precaution when there are plenty of holes to be found elsewhere is a bad idea.
There aren't as easy holes anywhere else, or at least there shouldn't be.
Note that I do not believe maintainer scripts should be run without requiring the administrator to manually trust the signed source of the package if the source has not been trusted before.
Certainly, but that still doesn't mean you should trust the maintainer scripts absolutely even after verifying. Never rely on a single layer of security.
And hey, if you're really paranoid, extract the scripts and check them out before installing the package. Can't really do that with the binary - how do you know what the source *really* was?
Disassemble it and check the assembler. Yes, it's a bit harder, unless the scripts are written in perl, but you can hide things in any language if you're good enough. There is no way to be absolutely secure, scripts and programs can never be absolutely trustworthy, so anything which makes them less able to exploit you is a good thing, and worth doing unless the cost in terms of inconvenience etc. outweighs the security increase.
Yes, the vendor does have to worry about this and ship a separate application for the two distributions.
Read what you quoted just after this: "If an application cannot limit itself to the interfaces of the libraries previously listed, thento minimize runtime errorsthe application must either bundle the nonspecified library as part of the application, or it must statically link the library to the application." If they build their package the LSB way, it will work on any LSB distro. That's the whole point.
As for your last question, what exactly does autopackage have to "handle" regarding shared libraries (unless you are building a shared library package)?
I'm asking what autopackage does about the problems you're listing, "Example: one system has a c102 version of QT3 and another has a version compiled with an older C++ compiler."
These attacks are still enough to make MD5 invalid for some applications, e.g. digital signing of contracts, and attacks only get better. You should move away from MD5, whatever you're doing.
An incredibly stupid idea when Usenet is there and was created with this purpose in mind.
doing online banking;
Bank statements, loan requests etc. aren't documents?
interactively looking at maps;
Maps aren't documents?
or even shopping online
We would be better off with a specialised protocol for this.
Every time I've seen an attempt to do over the web something that a specialist protocol exists for - e.g. webmail, web forums (fora?), web VNC/SSH, it has always been far worse than using the proper protocol and a client program. There are many things that the web is not suited to, and far too much that it's used for when there are better alternatives.
It wasn't designed for it. The web is meant as a documents platform. Trying to use it for applications is a recipie for security problems that'll make Windows look like fort knox, not to mention all the other problems that go with misusing a system like that. There are plenty of perfectly good systems for remote applications, X is great if you're willing to accept server-side execution, if you prefer client-side then for all its faults Java at least handles it with dedication and a modicum of security. Stop trying to make the web the medium for everything, there are 65535 other ports and superior specialised protocols.
There were several root exploits as late as 2.6.10. That is a hell of a lot of vulnerable kernels out there.
Only one of those you list would have affected my system, I'd forgotten about the uselib() one but that's all. I think it's far from given that a typical cracker/script kiddie/virus writer would be able to get root on a typical system, and as soon as the exploit became known it would be fixed, meaning the malware would stop affecting any patched systems which hadn't already been broken into and wouldn't spread/be used much further. Wheras there's no way to to patch to fix a script run as root having root privilidges.
No. A package needs to be built against the same versions of shared libraries that are on the target system or breakage will occur. This is what leads to vendors having to ship 20 different RPMs for a single application.
And that's why the LSB standardises on which shared libraries are available and where they will be located, as well as what changes can occur to them. If the distributions are LSB-compliant, vendors don't have to worry about it.
Since the distribution provides autopackage itself, I would presume that the distribution packagers would know how to configure autopackage to build packages compatible with the distribution. But I must confess I don't really understand what you are asking.
I'm asking how autopackage handles the problem of different names, versions and locations for shared libraries.
The 2^60 number is for the current best (AFAIK) attack on SHA1, yes it's not feasible at the moment, but my point is that it's just as feasible to attack an MD5-SHA1 combo as SHA1 on its own.
I wouldn't say that using both MD5 and SHA1 is useless when compared to using SHA1 alone. For one thing, we don't know what the future SHA1 exploit will look like. If the number of files you need to generate a dual collision is quite large, it may be sufficiently impractical enough to buy a few years.
No it won't. If there's enough files required to make it impractical with MD5 as well, then there's enough files required to make it impractical anyway.
Or files generated this way may have detectable characteristics.
Again, adding MD5 makes no difference as to whether or not that is the case.
It's not a long term solution of course, but in security everything always boils down to matter of time.
So enforcable no-one's dared challenge it. There have been plenty of companies with the motivation to go up against it if they thought they stood a reasonable chance of winning, and none of them have tried.
and IS "linux" a trademark
In some countries, yes, definitely, Linus only got the trademark after a legal battle when someone else trademarked it. However, in Australia it isn't. It just depends on local laws.
Slashdot Mirror
In relation to this: How important is Civ IV's introduction of Python? Do you think having a real programming language will make a difference to the quality and realism of game AI, or merely provide an easier way of doing things that could have been done anyway with the more usual methods?
True, but I don't see the relevance. Although several GPL ones exist there are no GNU gnutella clients.
It affects it if MS decides they're going to require installers to use this service. They'd have to make it free-as-in-beer, but what about requiring you to give MS rights to your code, or promising not to make it run on any other OS, if you want free access, or a small fee that larger companies can pay to use it and keep their code.
Underage people aren't allowed to consent because we feel they aren't able to reason fully about the consequences, they don't really know what will happen and how it will affect their life. The same is in all likelihood true of horses.
Say I download a song falsely tagged as CC licensed, and then proceed to share it, am I then liable for copyright infringement?
There's no GNU in gnutella.
We don't need them to be wonderfully creative, we just need them to be good at the science.
OSX is not unix, most of the GUI layer runs independently of the unix base. Would you seriously advocate unix as a destop OS?
Things move on. Things change. Things advance. The web has done so. Was the web originally designed for running applications? Maybe not. But the myriad ways in which it has moved on - Javascript, cookies, TLS, etc - have enabled it to grow and become an applications platform. Its original design is of no importance because what matters is the properties it holds today. Perhaps you would like me to judge Java and X on what they were like fifteen years ago as well?
X you certainly can. Java wasn't around then, but you can judge it from the point when it was. Both were built from the ground up for remote applications.
Aspects of the web have changed, but HTTP is still the same as it always was, and still sucks for doing remote applications.
You are advocating X and Java - where you are likely to find computers without either available on a regular basis - and then criticising the web because if you try hard, you might be able to think of one or two devices that are connected to the Internet but don't have web browsers.
I'm not criticising the web, I'm just saying both are equal in this respect. Yes, there's a quantative difference in the numbers of computers with one or the other, but there's no fundamental difference. I have yet to see a computer with a working web browser but no Java.
You seem to think using the web for applications is good because web browsers are more widely deployed. Would you advocate using MS Word for DTP tasks, because you can do them in word and Word is on just about every computer?
Does that apply to people? A 15 year old girl can be aroused and enjoying things but under the law she hasn't consented.
Maybe you should do some research. Most types of pornography have no detectable effect on temperament or attitudes, in fact I only know of one sort (that which promotes the "rape fantasy") which has been shown to have any negative effects. Any type of porn has far far less correlation with crime etc. than alcohol, and see your history for the effects of banning that.
That's not just it, the web wasn't designed to handle the issues involved with running applications. Sure, you can write secure web applications, just like you can write highly readable perl or functional programs in C, but it's a lot harder when the platform isn't designed for it.
X applications are executed on the client, not the server.
Only in X terminology. It's server-side in the sense that a number of computers will normally use X applications running on a single, larger computer.
Java and X suffer from the same problem - you have to install stuff to get it to work everywhere. You can't count on them being available, so if you need to run something, then you end up carrying software with you anyway, which defeats the purpose.
And with web applications you have to count on a web browser being available. Sure, you'll find them most places because the web is enormously overused and overemphasised, but I've seen internet-connected computers without them, and plenty of windows machines with the only browser (IE) in an unusable state.
You're treating security as a binary thing here. Yes, a Linux system isn't absolutely secure when faced with hostile user code, but it is more secure than when faced with hostile root code.
In the realm of installing software, this means you are forced to trust the program itself due to privilege escalation, just as you would have to trust maintainer scripts that are executed as root.
Yes, you have to trust it, but you don't have to trust it absolutely. You need to trust code and scripts more to run them as root than as a user since it's easier to cause trouble when running as root. Just like I have friends I trust enough to give user accounts but not root access on my box. Yes, there's a certain amount of trust needed to grant user access, but not as much as for root.
Maintainer scripts are extremely useful to keeping a package in a working state, and throwing them out as a precaution when there are plenty of holes to be found elsewhere is a bad idea.
There aren't as easy holes anywhere else, or at least there shouldn't be.
Note that I do not believe maintainer scripts should be run without requiring the administrator to manually trust the signed source of the package if the source has not been trusted before.
Certainly, but that still doesn't mean you should trust the maintainer scripts absolutely even after verifying. Never rely on a single layer of security.
And hey, if you're really paranoid, extract the scripts and check them out before installing the package. Can't really do that with the binary - how do you know what the source *really* was?
Disassemble it and check the assembler. Yes, it's a bit harder, unless the scripts are written in perl, but you can hide things in any language if you're good enough. There is no way to be absolutely secure, scripts and programs can never be absolutely trustworthy, so anything which makes them less able to exploit you is a good thing, and worth doing unless the cost in terms of inconvenience etc. outweighs the security increase.
I thought there was a standard one already: pornography is any work with the primary purpose of being erotic.
Pornography is a type of art that changes its level of aesthetic appeal according to the level of sexual arousal of the viewer.
This makes pornography a subset of art, which is not the case. Although much porn has at least an element of art to it, this isn't necessary.
Read what you quoted just after this: "If an application cannot limit itself to the interfaces of the libraries previously listed, thento minimize runtime errorsthe application must either bundle the nonspecified library as part of the application, or it must statically link the library to the application." If they build their package the LSB way, it will work on any LSB distro. That's the whole point.
As for your last question, what exactly does autopackage have to "handle" regarding shared libraries (unless you are building a shared library package)?
I'm asking what autopackage does about the problems you're listing, "Example: one system has a c102 version of QT3 and another has a version compiled with an older C++ compiler."
These attacks are still enough to make MD5 invalid for some applications, e.g. digital signing of contracts, and attacks only get better. You should move away from MD5, whatever you're doing.
An incredibly stupid idea when Usenet is there and was created with this purpose in mind.
doing online banking;
Bank statements, loan requests etc. aren't documents?
interactively looking at maps;
Maps aren't documents?
or even shopping online
We would be better off with a specialised protocol for this.
Every time I've seen an attempt to do over the web something that a specialist protocol exists for - e.g. webmail, web forums (fora?), web VNC/SSH, it has always been far worse than using the proper protocol and a client program. There are many things that the web is not suited to, and far too much that it's used for when there are better alternatives.
It wasn't designed for it. The web is meant as a documents platform. Trying to use it for applications is a recipie for security problems that'll make Windows look like fort knox, not to mention all the other problems that go with misusing a system like that. There are plenty of perfectly good systems for remote applications, X is great if you're willing to accept server-side execution, if you prefer client-side then for all its faults Java at least handles it with dedication and a modicum of security. Stop trying to make the web the medium for everything, there are 65535 other ports and superior specialised protocols.
Only one of those you list would have affected my system, I'd forgotten about the uselib() one but that's all. I think it's far from given that a typical cracker/script kiddie/virus writer would be able to get root on a typical system, and as soon as the exploit became known it would be fixed, meaning the malware would stop affecting any patched systems which hadn't already been broken into and wouldn't spread/be used much further. Wheras there's no way to to patch to fix a script run as root having root privilidges.
And that's why the LSB standardises on which shared libraries are available and where they will be located, as well as what changes can occur to them. If the distributions are LSB-compliant, vendors don't have to worry about it.
Since the distribution provides autopackage itself, I would presume that the distribution packagers would know how to configure autopackage to build packages compatible with the distribution. But I must confess I don't really understand what you are asking.
I'm asking how autopackage handles the problem of different names, versions and locations for shared libraries.
I was reading and posting for years before I got an account, not that it matters.
The 2^60 number is for the current best (AFAIK) attack on SHA1, yes it's not feasible at the moment, but my point is that it's just as feasible to attack an MD5-SHA1 combo as SHA1 on its own.
No it won't. If there's enough files required to make it impractical with MD5 as well, then there's enough files required to make it impractical anyway.
Or files generated this way may have detectable characteristics.
Again, adding MD5 makes no difference as to whether or not that is the case.
It's not a long term solution of course, but in security everything always boils down to matter of time.
Using both doesn't gain anyone any time.
Oh wait, they already did.
Does anyone come here for serious discussion anymore?
Yeah, and other people should hold their copyrights for them too.
If anyone has your trademark it should be you. Anything else is asking for trouble.
So enforcable no-one's dared challenge it. There have been plenty of companies with the motivation to go up against it if they thought they stood a reasonable chance of winning, and none of them have tried.
and IS "linux" a trademark
In some countries, yes, definitely, Linus only got the trademark after a legal battle when someone else trademarked it. However, in Australia it isn't. It just depends on local laws.