Comment Re:SQL Injections SHOULD NEVER WORK (Score 0) 267
Is it more work than a simple users table and single sign on? Yes. Is it a more sound methodology than SSO? Yes.
Single sign-on is not the same as using the same user account for everybody...
Is it more work than a simple users table and single sign on? Yes. Is it a more sound methodology than SSO? Yes.
Single sign-on is not the same as using the same user account for everybody...
That looks rather historic. From the sudo changelog:
2004-05-16 18:47 millert
* CHANGES: There was no 1.6.7p6.
So 1.6.7p5 should be from around 2004.
MySQL dying? SCNR.
That has got me thinking... How can the London stock Exchange crash twice with Windows Server in one year, but didn' t crash at all in all previous years it was running Linux? Professional quality must mean that the quality sucks...
Umm, didn't the London Stock Exchange run Solaris or some other commercial unix/unix-like system before switching to Microsoft Windows? Even now they switched (or still plan to switch? I don't know) to a heterogenos environment running both Solaris and Linux.
And that's not to say that sticking with old versions is always bad, it's just that the method of deciding what's stable is literally "is it old?". Why not test things and then update, instead of arbitrarily picking a version and declaring it to be stable? Or keep track of projects that release safe code and give them 2 weeks to make sure there's no horrible bugs, and then update (like what exactly is the reason for holding back Firefox and Pidgin?).
Because it is hard to do so. You cannot assure that there are no regressions as you can only test very few configurations, then somebody has to spend the resources to do the actual testing, and so on.
A stable (i.e. static) release means that at least no *new* regressions are introduced. Sometimes an exception has to be made (e.g. security updates), but these fixes are often backported to the version supplied in the release to avoid changes in behaviour as much as possible, but sometimes there are still regressions (see the security updates Debian provides, sometimes there are follow-ups due to regressions *not* noticed during testing). How many more regressions would there be when *new* upstream releases are included in the stable release?
Okular (the KDE PDF viewer) also obeys DRM restrictions by default, but at least it can be turned off in the preferences (Setting Configure, General, Obey DRM limitations). I believe this was implemented due to Adobe's requirements. If Apple's PDF viewer does not allow to ignore DRM restrictions, maybe you should just use a different one that allows to do so?
It is sad that you see Freedom of Expression, one of the Human Rights, as a privilege that can be taken away instead of an inalienable right. On the same line of thought goverments take away the *right* (not privilege) not to be tortured (because you are an evil person and so do not deserve any "privileges")...
So this security problem did not exist? Yes, it's a problem in Java, but Java is part of the default MacOSX installation, and Apple only fixed the problems months later.
Properly set up however, the important data should be arriving at the cloud encrypted and be stored encrypted. The host should have no ability to access raw personal data.
And how you would go to process the data?
Real programs don't eat cache.