And the great thing about this project is that if a graphic hardware vendor needs to choose what to spend 1000hours to work on, it can now be the 3D driver instead of a 2D driver. Because someone else created a layer to use that 3D driver for all 2D operations.

Previously the money/time was spent on the 2D to facilitate the largest target audience for the hardware and unfortunately that 2D effort could not be utilize for the linux 3D use case, so no wonder improvement to it were hard to get.

So expect those crappy 3D drivers to get good in the areas needed by the 2d-over-3d code real soon and while they are in there they might as well work on all the low hanging fruit concerning 3d usage.

So won't apply your previously knowledge on linux 3d driver support against what the future will now bring to both the 2d and 3d scene.

Wooossshhhh!

He (somenickname) is talking about the global CA system where all 1000 CAs are equally trusted, so the NSA only need to convince one to reissue a certificate (based on a private key the NSA provided) in the name of the target website they wish to intercept.

The content consumer has no way of knowing if the SSL cert that is being used for the HTTPS connection is the one using the site owner's private key or the one using the NSA's private key. So this is why simply having a green light because you switched to SSL is security theatre.

But you (kasperd) go on an rant about other matters.

The projects such as SSL Observatory https://www.eff.org/observator... and Convergence http://convergence.io/index.ht... and http://tech.slashdot.org/story... combined with DNSSEC (which somewhat has the same problems as the CA system, but useful to allow deployment for low security websites without paying sign-my-certificate tax).

The problem is neither do the maintainers fully understand every corner of every feature, driver and extension in the major X.11 implementations that exist (XFree86/X.Org).

So now we get Linux graphics drivers that target what is really needed (not the performance metric to bitblt specific patterns at specific bit depth to screen) and we de-couple the hardware driver from the display acquisition arbitrator (the software that decides which application get to draw and utilize the hardware at any given time).

Most people are in exactly your position, the best thing to do is let those with knowledge and enthusiasm knock themselves out on trying to produce a better solution to the problem. This is just how progress happens. to me I stopped programming to the X.11 API calls a long time ago, I use a toolkit like Qt and this will not change. So I look forward to an improved graphical experience on all formats of Linux (mobile/pad/notebook/desktop) for the next 30 years from this.

I find Windows currently a better experience for using an IDE, modern X.11 has to much input lag, copy-and-paste that is also laggy and unreliable this really saps productivity.

Ah my requirements are that links be bookmarkable (especially across the same users login session. but occasionally between co-workers). As they are business systems that are in constant use and clicking on a link, finding out your session has expired, re-authenticating and then having the link not work, is not good for productivity.

So with this in place you did not provide anything actual flaw in the problem domain in this area, so this is good news to me.

But multiple users of the same system can not obtain secret business information (such as DB Primary Key ID) that might leak data such as how many records you have.

The other stuff you touched on it generally dealt with once enabled by my choice of website application framework, that still means you have to actively test is is enabled and doing its thing in production.

Bollox, the developers of X11 are over 30years older now. I think you are confusing the current maintainers of the two most popular X11 implementations with the actual developers who came up with the original ideas. The extensions over the past 15 year rise of Linux popularity have had to restrict themselves to the design choices made over 30 years so. It is plenty overdue a revamp, silicon has changed to much in that time.

Re: XOR and real cipher

Use both. Initialize a symmetric cipher server side for your webapp (so keys are hot/high performance). Then for each thing you need to encode XOR the raw database PK ID first then pass it through the cipher. This way database ID 1 for every thing you do does not end up with the same ciphered result.

For extra points many symmetric ciphers use larger block sizes than the 64bit you actually need for your database PK ID, so pad left and right bits with random garbage.

For more points use part of the unused bits (of the cipher block size) also as a form of checksum/CRC, that can be used to detect corruption/brute forcing. No real web request should get this wrong (unless you have bugs, but you can mark the client as being suspect).

But who brute forces larger than 128bits over the Internet.

because the people at the top like and want to be the top of the american lifestyle, not the off shore one.

Better codecs are not required, most people consider standard TV good enough, DVD great and Blueray overkill. Many places are getting home Internet upgrades from 24MBit to 100MBit. Portable and general storage mediums are cheaper and more dense per Gb.

We only have to wait another 10 or so years for the MPEG patents to expire (yeah right, I'm sure the standards will be in perpetual patent, as they phase in some new minor changes, when the 30 year old codec is great for use today). So in the grand scheme of things of paying for these "much needed" expensive codecs, forget it. I don't need them today when the alternatives are good enough, the population of the world will get them all for free in a few short years anyway as the patents "should" be expiring. If they don't expire then it is time to go to war on that basis and rewrite the laws (this will happen).

Presumably someone intercepting has more than one route to the victim AS. one to perform the intercept and another to pass on the traffic with to it ends up delivered to the victims AS. so they shunt the traffic inside some MPLS tunnel across their own network (via their inspection device/system).

Now if you are talking about asymmetric routing issues that is a different matter. Since the victim AS won't automatically send the other half of the data stream via your hijacking networking (unless of course you can perform a reciprocal intercept at the other side as well, if it is possible at one sure, then surely it maybe possible at the other).

You are not an English speaker yourself. Well as an English speaker...

Adding "potentially" to the sentence can often be used by technical/engineering people to better describe a scenario of risk. Since other non-technical/non-engineering people look to the statement to fully understand the situation, so it needs to be described as either being a matter of fact, or a matter of professional opinion, or a matter open to debate.

So to describe something as "potentially" is attempting weight the risk, without claiming it as a matter of fact.

I agree with the other poster, potentially harmful != dangerous. On the basis that for me potentially harmful is unlikely to be dangerous (as in less than 50% risk), and "dangerous" is more likely to result in danger (greater than 50% of risk). Again we (the engineers/technical people) are weighting our response via the use of language in this way.

Agree and understand. But you can create as many private keys as you like, you do not have to maintain a single identity.

Other users sending money can send fragments of the total value to different identities.

No no no, it is up to the other flying object to identify itself and clear a friend-or-foe test, otherwise the default resolution is to open fire.

As an OpenSSL contributor I agree the project is a mess.

The project needs 100% code coverage unit testing.
It needs to move to using git as the main SCM repo.
I don't agree with even the source formatting on the basis that it doesn't make it easier to audit the code base, it is an uncommon code formatting choice.
The project needs a gerrit code review system to streamline the limited committer man-hours when integrating new code. One problem in getting patches into the project is you need to find a committer that agrees with it and has time. Git allows easier unlimited forking and code review allows by anyone and facilities multiple people to run their own tree, so may the best maintainer win popularity.
All new code should include a unit test to accept it.
The network / kernel interactions need also unit testing (something I already did in the part to prove an API interaction deficiency in the OpenSSL API design).

Why IE8 ? Win7 Pro is the new XP, so surely IE10 will be the new target ?