The Session Key of the SSL session is what they seek to control. So this is a matter for a secure key exchange protocol to fix.
I don't understand how storing information inside a cookie (which is presumably inside the HTTPS connection) helps the attacker. Since in order to examine it they would have already brute forced their 100 million known keys to find the one that worked. So why do they need any extra information from the cookie.
Maybe a cryptographer can explain if key exchange protocols such as DH are immune to this kind of concern, since don't both ends pick their own random numbers, to derive a usable symmetric cipher key. So as long as each end can trust their own local random number generation isn't the exchange immune to this attack even if you presume the other end uses same (not random number) every time. They still can not control my RNG and my RNG perterbs the resulting master key. So we just need to make sure there is enough entropy from one ends input to satisfy their ends security concerns.
No the real problem here is having the remote endpoint simply persist and store for later lookup, or forward in realtime the agreed key the client and server used of any SSL session along with a timestamp and the IP address and port number tuples. This you can never protect yourself from. You have to ask the question, what data would I trust the endpoint with, just like any other kind of relationship ?
More encryption is good, because then at least there maybe whistle blowers and loss of reputation costing the relevant company some financial penalty, hopefully 10x more than the bribe.
No. Even with a commercial one you always keep the private key part and never disclose it to the CA.
The point in the summary is that the "authorities" contact you (under threat of violence) to obtain the private key part from you, so they can setup their own SSL endpoint to pretend to be you without the other end knowing.
So even with a self-signed the same process applies in this case.
The problem with commercial ones is that the NSA can approach the CA directly and have them reissue a cert made out to you for which they already have and provide to the CA the new private key. Now there are 2 certs out there that clients accept with your name inside them.
I believe google has a mechanism now to actually check against a know valid list of certs it will accept when their own name is listed as the subject of the certificate.
Why not a redesign? What's so great about the current one?
It was cheap! Someone else already paid for all the relatively expensive SoC development work on it. Wasn't a large order of SoC chips originally canceled by a large customer of Broadcom. So this is a contributing factor to making the Raspberry Pi fly. Maybe this is a myth I read but I've always believe this to be the story.
Now of course we can have this (RaspberryPi Mk1 A/B) level of specification/performance cheaper if we build / design something new today, but everyone today expects more, as your posting explains. So the problem is confining the project to the project goals.
http://vertx.io/ Have both (the promises of Node.JS and the enterprisey seal of approval from the Java ecosystem:)
There also exists Servlets + ASync + WebSockets exists if you want to lean towards the more traditional model (one thread per request) but need a little bit of ASync.
The Java ecosystem is set to get better native JS support (to run / integrate JavaScript directly into the JVM), via both improved Rhino (based on new Java7/8 features) and also a V8 engine (also webkit) due in future JREs. So once these things happen the polygot vert.x can push JS directly as well. As historically JS performance is not good on JVM.
"This is what they'd like to charge you more for."
Makes sense. They "the grid" are getting the energy to the point of the customer for a higher price than they are willing to pay at the point of your production location.
"the grid" is paying to maintain those transmission lines to transport your surplus energy so it can be sold at all.
"the grid" has a bunch of fixed overheads that also need to be maintained in order for the system to exist in the first place. They don't have a minimum power production contract with you over a long period, yet they need to plan over decades.
"the grid" is handling the money collection and cash flow problem of the input/output power arrangement between customers. You are not the one chasing your next door neighbor for his electricity payment this month,.
All these things to me do make up for a cost different. I mean we can all buy relatively cheap crude oil directly in large enough quantities and burn it ourselves to produce electricity. We don't because we can not beat the economies of scale.
and any old / existing version(s) for which they have full rights on because as you say they own it, so would be entitled to provide additional licensing options on existing code.
This is not the same thing as retracting/withdrawing the previously GPLed versions of the same. As I'm sure the GP knows this is not legally possible. The only thing they could in this regard is simply stop redistributing any form of it neither binary nor source of the older versions and then hope it disappears from the Internet, since they could not stop a 3rd party providing redistribution but can control what they themselves redistribute.
It goes out via a separate channel and never looks like you from the perspective of the Internet, different IP etc... Maybe even Carrier Grade NAT.
But sure the possibility exists for a firmware but that somehow allows a public wifi user to gain excess to something that should not have been allowed. But I've not heard of such a far todate. BTs technical department can be pretty good with their specify and testing of customer premise equipment so, i.e. they perform actual testing and verification of the equipment many months prior to the roll out of the first piece of equipment.
However the overall feature set of the BT routers is poor, even if to the less savvy Internet users it does everything it says on the tin is easy to setup and is reliable.
No... it maybe a separate ATM channel or something used for low level encapsulation by DSL service, but it still has to run over the same Signal-to-Noise ratio that is possible for the physical DSL line BT use between the DSL modem and the exchange.
So indeed you have the share bandwidth, since the public side will be eating bandwidth out of the maximum possible bandwidth for the given signal-to-noise ratio of the physical line. Well this is true for ASDL2+ services (upto 24Mbit) that have historically run most BT.Fon access points. If you are 8 Kilometers from the exchange maybe you can only get 2Mbit services, where as if you are under 500m you can get over 20Mbit.
Now BT have an VDSL service running 100Mbit and maybe more, I am not yet lucky enough to be able to order this service as the exchange upgrade cycle has not yet completed in my area. In this scenario it might be said that it doesn't matter if the public side eats some bandwidth since there is plenty for 2+ people to stream video. A single user can easily max out a 24Mbit services for some periods of time.
Re GPP: " Nuvoton/Winbond Super I/O chips" these sound like cheap chips, I don't think many of my servers uses these. The servers under high temp and high CPU load do indeed have sensors to throttle/control fans to increase/decrease airflow, they also have a fail-safe mechanism that is the sensor breaks the falls run at full speed. On top of all this the server unit has a motherboard base thermal shutdown that turns the whole server off if the ambient temperature is over some limit.
I have had this happen before in just such a scenario where the D/C aircon failed and the redundant capacity was under-rated for the area being cooled. The room temperature rose so the point that it increased the set-points of the equipments ambient temperature and other parts to trigger a shutdown to protect itself.
Bollox. Many IP connectivity installations have exactly 1 ingress/egress router. This simply does not pass any traffic between any interfaces unless a stateful inspection rule allows it to. This matter does not change for IPv4 or IPv6.
Sure unplugging and replugging a cable can cause a device to be accessible on the Internet, but this is also true of IPv4 and your DMZ/public IP network (if so configured).
The only thing that IPv6 adds is that many IPv6 default installs might allow such an incorrectly plugged device to obtain information about the default gateway and therefore become accessible. However if this is a security concern is indeed a problem to you, then you simply do not enable Router Advertisement feature or IPv6 DHCP on the DMZ/public IP network segment. Such devices on the DMZ/public IP network might/could hardwire their default gateway (much like you already do for IPv4) or you setup IPv6 DHCP which will authenticate via MAC address (or other mechanism). But I understand router advertisement enabled on a DMZ/public IP network might be a concern (just like IPv4 DHCP would be for the same scenario of IPv4). Just turn it off!
This way any incorrectly plugged in device will not be able to obtain a default route and is therefore in accessible.
Now you have your security blanket back.
IPv6 does not make things worse in the way you describe, when you better understand the improved mechanism IPv6 bring and how to take command of the IPv6 network configuration to make it less prone to human error.
We have not even talked about IPv6 privacy extensions to fuzz/randomize/rotate the public IPv6 address used by a specific device to prevent the MAC address from being a constant source for leaking
"Judge, I merely clicked into the address bar to enter a search term like I always do, but this time it changed just one 'Query String' parameter value to the term I type in, and presto. Sorry Judge I didn't realize it was possible to hack websites while performing a web search, next time I shall turn on safe searching,"
No No... you make your canned "This call is being recorded announcement" over the top of their similar announcement often played from a tape, just before a real person picks up the call.
Both parties get to keep their recordings to prove you have both announced this matter to each other.
I think it should be that if one party chooses to record a call then that automatically allows the other party to make a recording without needing to announce the matter. If one party makes a recording it should automatically become a reciprocal matter. More so if you have a recording yourself to prove such an announcement was made (by the other party).
This is true on the desktop with big fat caches and CPU cycles to burn. But JIT on mobile has a long way to go yet. Most things on mobile run interpreted mode only, maybe you can not tell the difference? because it is fast enough.
Qt (one of the APIs of the BB10 platform) does do well to make C++ difficult to write code that crashes easily.
I looked over the libc API calls used by graphics drivers once and it wasn't anything special. Maybe less than 25 symbols.
The point of this claim is that there is probably no need for a bionic reimplementation (bugs and all) all that needs to happen it struct layout conversion across the APIs calls. I would guess only 5 or less API calls are affected the rest follow same or similar ABI constructs for both bionic and glibc.
The overhead, if there are no bugs/quirks to manages then next to nothing, you are copying one data layout to another data layout in those calls that changes. Since the values are all probably in the CPU cache (due to cache lines being recently references/zeros/accessed) to cost is not worth being concerned about. This is only the libc calls like to open files and read them.
The Open GL APIs themselves could follow the exact same ABI.
Maybe I should get back to that porting Android to Raspberry Pi (this is the reverse situation, where drivers exist linked to glibc as part of debian raspian but require an ABI and API that conforms to Android). Raspberry Pi don't really want their fine device being labeled Android as it may detract from the educational focus of the device and also the performance may not be as good as an Android user expects.
Round trip latency is a problem. X11 object handles could be arbitrary reference exchanges (instead of the client asking the server to create a new object and then waiting for a handle by return of message), this way the client can jump start usage of the object with pipelining. This is where a create object request with my arbitrary reference is sent and I proceed to immediately send more instructions as-if that handle was successfully created. With ability to cope with recovery when the server denies a new handle.
Making the X11 protocol compression optimizations (that also help fix round trip latency).
The bandwidth between a CPU and a GPU is huge, the notion of having a single serialized pipeline between the client and server/GPU is not a good one. In the future I see multiple threads on a client each having their own pipeline to the GPU to be able to instruct it in parallel and maybe even whole widgets sets in GPU instructions. How might X.11 look that working well in such a world.
I'm in the camp that X.11 has had its day and ripping up and starting over does not seems such a bad thing. If applications are already using client side libraries loaded into the clients address space / process to perform the majority of drawing operations and the X.11 protocol to convey input events and copy pixmaps.
It does seems like widget sets are already supporting replaceable low-level drivers so who cares which protocol is actually in use as long as they world. I switched from using Linux as my Eclipse development environment because the X11/gtk combination is too slow on modern hardware, Windows provides a far better experience. I'm just too tired of having to hold the mouse button down waiting for the menu to draw itself, I have other things to be doing than waiting for X11 protocol to do its work.
Also you talk of X11 a being the core (like POSIX or kernel) but really is it GPU silicon that is driving display technology not protocols. Linux needs keep up with that progress in anyway possible.
One day Linux itself will also be just as obsolete as some claim X.11 to be, just maybe not in my lifetime.
Well exactly and what legal action took place over it, from what I recall the people (and press) of the UK were giving him a pat on the back. Go on my son!
A "webapp" is a server side application, think like what PHP is mainly used for. There are a huge number Java Servlet Containers running Java webapp's in the world. Note the use of the term "webapp" was coined by Java back 12+ years ago to mean use of Servlets. From my view of the world only MS.NET with ASP.NET comes close to the capabilities possible with Java webapps. Sure today some other technologies have hijacked the term for their own use.
No one does Java Applets anymore, except as noted for corporate equipment vendors and this is usually because those large corporations (IBM, HP, Equalogic, VMware, Oracle, etc...) use the Java language for everything so they can reuse in-house knowledge. But no general public facing business uses Java Applets anymore, only closed portals or contracted for services.
Now the issue with JavaScript and AJAX this is talking about the HTTP client side of things, so the JavaScript != Java is not relevant to the original comments (since they were talking about "webapps" and therefore server side Java, but you confuse it with client side; that no one does). Currently NodeJS is about the only technology that can be said to have an edge on Java for server side processing of AJAX/WebSockets. But there are at least 2 major projects for Java making use of the NIO/Event processing model that should be able to scale better than NodeJS. The Servlet specification has an update to ratify WebSockets as at least 4 Java webserver implementations have already supported WebSockets to some degree already but in slightly different ways, so now we have a new standard.
My current choices are: Ruby for the offline development tools for content processing and generation (css/sprites/etc...), AngularJS for MVVM in HTML5, Java Servlets on Servlet container for service side programming model.
Sure you have to craft the file to match MD5 but also be interpreted as a substitute of the original but with evil data.
This can become an easier problem to resolve if you are allowed unlimited length of input, but with a digest hash it becomes much harder if you also sign the input length the same as the original.
Yes you can now, but there was a time when subsidized phones with contract were locked in the UK. You could often pay an additional fee when the contract expires to get the unlock code from the carrier making the carrier additional revenue.
But as is usual in telecoms (in the UK) customer get hit over the head by these fees and then start to demand unlocked phones when they take the contract out and voting with their wallets. Since there is a contract anyway with early termination fees written into it the notion of locking a phone handset was not unnecessary as the carrier would both keep the subscribers mobile telephone number and enforce the contract terms in the courts.
It has been a while since I looked at some carriers but certainly O2 and Vodafone have provided unlocked handsets for a long time, I know Orange used to lock (6+years ago) and I'm not sure on T-Mobile, Three and now Everything Everywhere current policies.
PCI compliance is only a legal/contractual stipulation it has no under lying requirement in law. Therefore in order to need to be PCI compliant you first need to locate a contract that you have in force and are liable to that requires PCI. Until you have one of those then you have no requirement to be PCI compliant and the GPP is scaremongering.
Organizations who have such a contract might have a "Merchant Bank Account" (supplied by a real bricks and mortar bank) or an agreement with a "Payment Processor" that include such contract terms. Since no card holder data passes though most google checkout merchant they do not need PCI compliance.
Now the GP suggested that the data is card holder data and I say here it is not. It maybe described in the PCI compliance documentation as such but remember PCI only relates to you if you have a contractual obligation. If you don't this information in googles case is simply sales taxation information, i.e. the information most organizations need to provide their government to prove income from legitimate sales and then comply with taxation regulation. What you (or rather PCI) calls "card holder data" someone else may call "foobar data" since "card holder data" is an irrelevant term to a party that does it not obligated to a contract that requires PCI.
So for example a US merchant might not be allowed to sell certain kinds of digital products to certain countries in the middle east. For example Value Added Tax / Sales Tax maybe different depending upon the date of tax, the country of the customer resides. There are many other reasons to need some parts of this data.
So the question is does the agreement between google checkout and the individual/organization who is the merchant selling Android products have it written into their terms that PCI compliance is required ?
There is no such thing as "automatic" requirement to be PCI compliant, only a contractual obligation to be compliant that is enforced by the ability to levy fines.
24" 1920x1600 by IIYAMA (ProLite B2403WS), please someone inform this thread where equivalent monitors can be sourced.
16:9 and 16:10 formats are bad for multi-monitor use.
DPI seems to get poorer and poorer, but I hope some of the developments coming from mobile and tablet formats ends up in the midline and professional end of the desktop LCD market.
Qt is LGPL as well, with a linking/classpath exception. Read license for exact details.
But you don't have your make your resulting application GPL or LGPL when using Qt. Part of the reason for the linking/classpath exception is to ensure the Copyright holders interpretation is understood rather than maybe another possible interpretation.
While I do not know the full details of the DevKit licensing you made an implication concerning Qt that some readers might misinterpret if they did not know Qt licencing any better.
Slashdot Mirror
>> you would have to scrutinize the key material in many thousands of connections before you would even start to suspect something was wrong.'
A few iterations of their plugin, to also examine key information and find a safe way to report such concerns.
https://www.eff.org/observatory
The Session Key of the SSL session is what they seek to control. So this is a matter for a secure key exchange protocol to fix.
I don't understand how storing information inside a cookie (which is presumably inside the HTTPS connection) helps the attacker. Since in order to examine it they would have already brute forced their 100 million known keys to find the one that worked. So why do they need any extra information from the cookie.
Maybe a cryptographer can explain if key exchange protocols such as DH are immune to this kind of concern, since don't both ends pick their own random numbers, to derive a usable symmetric cipher key. So as long as each end can trust their own local random number generation isn't the exchange immune to this attack even if you presume the other end uses same (not random number) every time. They still can not control my RNG and my RNG perterbs the resulting master key. So we just need to make sure there is enough entropy from one ends input to satisfy their ends security concerns.
No the real problem here is having the remote endpoint simply persist and store for later lookup, or forward in realtime the agreed key the client and server used of any SSL session along with a timestamp and the IP address and port number tuples. This you can never protect yourself from. You have to ask the question, what data would I trust the endpoint with, just like any other kind of relationship ?
More encryption is good, because then at least there maybe whistle blowers and loss of reputation costing the relevant company some financial penalty, hopefully 10x more than the bribe.
No. Even with a commercial one you always keep the private key part and never disclose it to the CA.
The point in the summary is that the "authorities" contact you (under threat of violence) to obtain the private key part from you, so they can setup their own SSL endpoint to pretend to be you without the other end knowing.
So even with a self-signed the same process applies in this case.
The problem with commercial ones is that the NSA can approach the CA directly and have them reissue a cert made out to you for which they already have and provide to the CA the new private key. Now there are 2 certs out there that clients accept with your name inside them.
I believe google has a mechanism now to actually check against a know valid list of certs it will accept when their own name is listed as the subject of the certificate.
Negatives:
- Intel thinks it'll be slower than a more integrated driver like what they build already.
But seemingly faster to implement something / anything if you have no code to begin with and need to write a driver from the shadows.
Why not a redesign? What's so great about the current one?
It was cheap! Someone else already paid for all the relatively expensive SoC development work on it. Wasn't a large order of SoC chips originally canceled by a large customer of Broadcom. So this is a contributing factor to making the Raspberry Pi fly. Maybe this is a myth I read but I've always believe this to be the story.
Now of course we can have this (RaspberryPi Mk1 A/B) level of specification/performance cheaper if we build / design something new today, but everyone today expects more, as your posting explains. So the problem is confining the project to the project goals.
Good on Ben for doing a grand job of that.
http://vertx.io/ Have both (the promises of Node.JS and the enterprisey seal of approval from the Java ecosystem :)
There also exists Servlets + ASync + WebSockets exists if you want to lean towards the more traditional model (one thread per request) but need a little bit of ASync.
The Java ecosystem is set to get better native JS support (to run / integrate JavaScript directly into the JVM), via both improved Rhino (based on new Java7/8 features) and also a V8 engine (also webkit) due in future JREs. So once these things happen the polygot vert.x can push JS directly as well. As historically JS performance is not good on JVM.
"This is what they'd like to charge you more for."
Makes sense. They "the grid" are getting the energy to the point of the customer for a higher price than they are willing to pay at the point of your production location.
"the grid" is paying to maintain those transmission lines to transport your surplus energy so it can be sold at all.
"the grid" has a bunch of fixed overheads that also need to be maintained in order for the system to exist in the first place. They don't have a minimum power production contract with you over a long period, yet they need to plan over decades.
"the grid" is handling the money collection and cash flow problem of the input/output power arrangement between customers. You are not the one chasing your next door neighbor for his electricity payment this month,.
All these things to me do make up for a cost different. I mean we can all buy relatively cheap crude oil directly in large enough quantities and burn it ourselves to produce electricity. We don't because we can not beat the economies of scale.
> (and more importantly any new versions of it)
and any old / existing version(s) for which they have full rights on because as you say they own it, so would be entitled to provide additional licensing options on existing code.
This is not the same thing as retracting/withdrawing the previously GPLed versions of the same. As I'm sure the GP knows this is not legally possible. The only thing they could in this regard is simply stop redistributing any form of it neither binary nor source of the older versions and then hope it disappears from the Internet, since they could not stop a 3rd party providing redistribution but can control what they themselves redistribute.
It goes out via a separate channel and never looks like you from the perspective of the Internet, different IP etc... Maybe even Carrier Grade NAT.
But sure the possibility exists for a firmware but that somehow allows a public wifi user to gain excess to something that should not have been allowed. But I've not heard of such a far todate. BTs technical department can be pretty good with their specify and testing of customer premise equipment so, i.e. they perform actual testing and verification of the equipment many months prior to the roll out of the first piece of equipment.
However the overall feature set of the BT routers is poor, even if to the less savvy Internet users it does everything it says on the tin is easy to setup and is reliable.
No... it maybe a separate ATM channel or something used for low level encapsulation by DSL service, but it still has to run over the same Signal-to-Noise ratio that is possible for the physical DSL line BT use between the DSL modem and the exchange.
So indeed you have the share bandwidth, since the public side will be eating bandwidth out of the maximum possible bandwidth for the given signal-to-noise ratio of the physical line. Well this is true for ASDL2+ services (upto 24Mbit) that have historically run most BT.Fon access points. If you are 8 Kilometers from the exchange maybe you can only get 2Mbit services, where as if you are under 500m you can get over 20Mbit.
Now BT have an VDSL service running 100Mbit and maybe more, I am not yet lucky enough to be able to order this service as the exchange upgrade cycle has not yet completed in my area. In this scenario it might be said that it doesn't matter if the public side eats some bandwidth since there is plenty for 2+ people to stream video. A single user can easily max out a 24Mbit services for some periods of time.
I concur...
Re GPP: " Nuvoton/Winbond Super I/O chips" these sound like cheap chips, I don't think many of my servers uses these. The servers under high temp and high CPU load do indeed have sensors to throttle/control fans to increase/decrease airflow, they also have a fail-safe mechanism that is the sensor breaks the falls run at full speed. On top of all this the server unit has a motherboard base thermal shutdown that turns the whole server off if the ambient temperature is over some limit.
I have had this happen before in just such a scenario where the D/C aircon failed and the redundant capacity was under-rated for the area being cooled. The room temperature rose so the point that it increased the set-points of the equipments ambient temperature and other parts to trigger a shutdown to protect itself.
Bollox. Many IP connectivity installations have exactly 1 ingress/egress router. This simply does not pass any traffic between any interfaces unless a stateful inspection rule allows it to. This matter does not change for IPv4 or IPv6.
Sure unplugging and replugging a cable can cause a device to be accessible on the Internet, but this is also true of IPv4 and your DMZ/public IP network (if so configured).
The only thing that IPv6 adds is that many IPv6 default installs might allow such an incorrectly plugged device to obtain information about the default gateway and therefore become accessible. However if this is a security concern is indeed a problem to you, then you simply do not enable Router Advertisement feature or IPv6 DHCP on the DMZ/public IP network segment. Such devices on the DMZ/public IP network might/could hardwire their default gateway (much like you already do for IPv4) or you setup IPv6 DHCP which will authenticate via MAC address (or other mechanism). But I understand router advertisement enabled on a DMZ/public IP network might be a concern (just like IPv4 DHCP would be for the same scenario of IPv4). Just turn it off!
This way any incorrectly plugged in device will not be able to obtain a default route and is therefore in accessible.
Now you have your security blanket back.
IPv6 does not make things worse in the way you describe, when you better understand the improved mechanism IPv6 bring and how to take command of the IPv6 network configuration to make it less prone to human error.
We have not even talked about IPv6 privacy extensions to fuzz/randomize/rotate the public IPv6 address used by a specific device to prevent the MAC address from being a constant source for leaking
"Judge, I merely clicked into the address bar to enter a search term like I always do, but this time it changed just one 'Query String' parameter value to the term I type in, and presto. Sorry Judge I didn't realize it was possible to hack websites while performing a web search, next time I shall turn on safe searching,"
No No... you make your canned "This call is being recorded announcement" over the top of their similar announcement often played from a tape, just before a real person picks up the call.
Both parties get to keep their recordings to prove you have both announced this matter to each other.
I think it should be that if one party chooses to record a call then that automatically allows the other party to make a recording without needing to announce the matter. If one party makes a recording it should automatically become a reciprocal matter. More so if you have a recording yourself to prove such an announcement was made (by the other party).
This is true on the desktop with big fat caches and CPU cycles to burn. But JIT on mobile has a long way to go yet. Most things on mobile run interpreted mode only, maybe you can not tell the difference? because it is fast enough.
Qt (one of the APIs of the BB10 platform) does do well to make C++ difficult to write code that crashes easily.
I looked over the libc API calls used by graphics drivers once and it wasn't anything special. Maybe less than 25 symbols.
The point of this claim is that there is probably no need for a bionic reimplementation (bugs and all) all that needs to happen it struct layout conversion across the APIs calls. I would guess only 5 or less API calls are affected the rest follow same or similar ABI constructs for both bionic and glibc.
The overhead, if there are no bugs/quirks to manages then next to nothing, you are copying one data layout to another data layout in those calls that changes. Since the values are all probably in the CPU cache (due to cache lines being recently references/zeros/accessed) to cost is not worth being concerned about. This is only the libc calls like to open files and read them.
The Open GL APIs themselves could follow the exact same ABI.
Maybe I should get back to that porting Android to Raspberry Pi (this is the reverse situation, where drivers exist linked to glibc as part of debian raspian but require an ABI and API that conforms to Android). Raspberry Pi don't really want their fine device being labeled Android as it may detract from the educational focus of the device and also the performance may not be as good as an Android user expects.
Round trip latency is a problem. X11 object handles could be arbitrary reference exchanges (instead of the client asking the server to create a new object and then waiting for a handle by return of message), this way the client can jump start usage of the object with pipelining. This is where a create object request with my arbitrary reference is sent and I proceed to immediately send more instructions as-if that handle was successfully created. With ability to cope with recovery when the server denies a new handle.
Making the X11 protocol compression optimizations (that also help fix round trip latency).
The bandwidth between a CPU and a GPU is huge, the notion of having a single serialized pipeline between the client and server/GPU is not a good one. In the future I see multiple threads on a client each having their own pipeline to the GPU to be able to instruct it in parallel and maybe even whole widgets sets in GPU instructions. How might X.11 look that working well in such a world.
I'm in the camp that X.11 has had its day and ripping up and starting over does not seems such a bad thing. If applications are already using client side libraries loaded into the clients address space / process to perform the majority of drawing operations and the X.11 protocol to convey input events and copy pixmaps.
It does seems like widget sets are already supporting replaceable low-level drivers so who cares which protocol is actually in use as long as they world. I switched from using Linux as my Eclipse development environment because the X11/gtk combination is too slow on modern hardware, Windows provides a far better experience. I'm just too tired of having to hold the mouse button down waiting for the menu to draw itself, I have other things to be doing than waiting for X11 protocol to do its work.
Also you talk of X11 a being the core (like POSIX or kernel) but really is it GPU silicon that is driving display technology not protocols. Linux needs keep up with that progress in anyway possible.
One day Linux itself will also be just as obsolete as some claim X.11 to be, just maybe not in my lifetime.
Well exactly and what legal action took place over it, from what I recall the people (and press) of the UK were giving him a pat on the back. Go on my son!
A "webapp" is a server side application, think like what PHP is mainly used for. There are a huge number Java Servlet Containers running Java webapp's in the world. Note the use of the term "webapp" was coined by Java back 12+ years ago to mean use of Servlets. From my view of the world only MS .NET with ASP.NET comes close to the capabilities possible with Java webapps. Sure today some other technologies have hijacked the term for their own use.
No one does Java Applets anymore, except as noted for corporate equipment vendors and this is usually because those large corporations (IBM, HP, Equalogic, VMware, Oracle, etc...) use the Java language for everything so they can reuse in-house knowledge. But no general public facing business uses Java Applets anymore, only closed portals or contracted for services.
Now the issue with JavaScript and AJAX this is talking about the HTTP client side of things, so the JavaScript != Java is not relevant to the original comments (since they were talking about "webapps" and therefore server side Java, but you confuse it with client side; that no one does). Currently NodeJS is about the only technology that can be said to have an edge on Java for server side processing of AJAX/WebSockets. But there are at least 2 major projects for Java making use of the NIO/Event processing model that should be able to scale better than NodeJS. The Servlet specification has an update to ratify WebSockets as at least 4 Java webserver implementations have already supported WebSockets to some degree already but in slightly different ways, so now we have a new standard.
My current choices are: Ruby for the offline development tools for content processing and generation (css/sprites/etc...), AngularJS for MVVM in HTML5, Java Servlets on Servlet container for service side programming model.
Sure you have to craft the file to match MD5 but also be interpreted as a substitute of the original but with evil data.
This can become an easier problem to resolve if you are allowed unlimited length of input, but with a digest hash it becomes much harder if you also sign the input length the same as the original.
tripwire much ?
http://www.linuxjournal.com/article/2160 "Tripping up Intruders with Tripwire, Issue #40, Aug 01, 1997"
Yes you can now, but there was a time when subsidized phones with contract were locked in the UK. You could often pay an additional fee when the contract expires to get the unlock code from the carrier making the carrier additional revenue.
But as is usual in telecoms (in the UK) customer get hit over the head by these fees and then start to demand unlocked phones when they take the contract out and voting with their wallets. Since there is a contract anyway with early termination fees written into it the notion of locking a phone handset was not unnecessary as the carrier would both keep the subscribers mobile telephone number and enforce the contract terms in the courts.
It has been a while since I looked at some carriers but certainly O2 and Vodafone have provided unlocked handsets for a long time, I know Orange used to lock (6+years ago) and I'm not sure on T-Mobile, Three and now Everything Everywhere current policies.
Can someone TL;DR it into 3 paras ?
PCI compliance is only a legal/contractual stipulation it has no under lying requirement in law.
Therefore in order to need to be PCI compliant you first need to locate a contract that you have in force and are liable to that requires PCI.
Until you have one of those then you have no requirement to be PCI compliant and the GPP is scaremongering.
Organizations who have such a contract might have a "Merchant Bank Account" (supplied by a real bricks and mortar bank) or an agreement with a "Payment Processor" that include such contract terms. Since no card holder data passes though most google checkout merchant they do not need PCI compliance.
Now the GP suggested that the data is card holder data and I say here it is not. It maybe described in the PCI compliance documentation as such but remember PCI only relates to you if you have a contractual obligation. If you don't this information in googles case is simply sales taxation information, i.e. the information most organizations need to provide their government to prove income from legitimate sales and then comply with taxation regulation. What you (or rather PCI) calls "card holder data" someone else may call "foobar data" since "card holder data" is an irrelevant term to a party that does it not obligated to a contract that requires PCI.
So for example a US merchant might not be allowed to sell certain kinds of digital products to certain countries in the middle east. For example Value Added Tax / Sales Tax maybe different depending upon the date of tax, the country of the customer resides. There are many other reasons to need some parts of this data.
So the question is does the agreement between google checkout and the individual/organization who is the merchant selling Android products have it written into their terms that PCI compliance is required ?
There is no such thing as "automatic" requirement to be PCI compliant, only a contractual obligation to be compliant that is enforced by the ability to levy fines.
24" 1920x1600 by IIYAMA (ProLite B2403WS), please someone inform this thread where equivalent monitors can be sourced.
16:9 and 16:10 formats are bad for multi-monitor use.
DPI seems to get poorer and poorer, but I hope some of the developments coming from mobile and tablet formats ends up in the midline and professional end of the desktop LCD market.
Qt is LGPL as well, with a linking/classpath exception. Read license for exact details.
But you don't have your make your resulting application GPL or LGPL when using Qt. Part of the reason for the linking/classpath exception is to ensure the Copyright holders interpretation is understood rather than maybe another possible interpretation.
While I do not know the full details of the DevKit licensing you made an implication concerning Qt that some readers might misinterpret if they did not know Qt licencing any better.