Any asset bubble behaves in exactly the same way as a ponzi scheme. People who get out before the inevitable crash can make a huge profit, funded by the people who are left holding the assets. Just because it's a shared delusion with many people separately promoting it and no evil mastermind to blame, doesn't change the fact that the income people believe they are earning only exists on paper.
The biggest compression gains for video involve improving motion compensation, which may raise the decoders memory requirements, and entropy coding. Entropy coding is implicitly single threaded, and the complexity of this process will impose a lower bound on the clock speed of your decoder. While the rest of the decoding process can be done in parallel with lower powered circuits.
If you join my mailing list and ask good questions that demonstrate knowledge that you have gained from your own research, I will gladly answer your questions.
If you submit a concise patch out of the blue to address a specific problem, I'll probably accept it.
The patches you submit should concisely tell a story that I can quickly read to understand both the problem and the solution. The biggest piece of advice I can give you, is to study and understand your source control tools. If we are communicating through email & patches, we need a common language.
But if you're still learning, it's probably going to take a number of iterations to get any patch right. You need to be prepared to throw away everything you've done and start over. You need to be persistent, you need to ask the right questions.
If you were employed as my subordinate, I would invest a considerable amount of my time in training you in the hope that your future productivity would pay back my investment with interest. If you want to work on an open source project, convince the maintainers that you have a similar commitment.
Sure, use RDP instead of X11. It gives a reasonable display, with minimal latency between the client and server, and reasonably minimal complexity. Now try bouncing your network connection off the moon. Did I really hit that button? It doesn't look like it has changed.
What you really want is a local process to animate the button push. But locking you into using a motif style X11 button limits future innovation. And what about other kinds of user feedback?
Web browsers have thrived for many types of applications, as they give you a standard(-ish) rendering engine, a standard way to talk to remote applications, with a small amount of scripting support. But you can't always fit a round peg into a square hole.
So why not allow a application to run some code in a sandbox, with resource limits, and remove all other restrictions.
What I'd like to see built as a replacement for X11's network abstractions, is a sandboxed VM running on top of the display server, passing arbitrary messages back and forth with the remote application.
For example, take the llvm based pNaCl sandbox that the google Chrome team are building. Expose wayland API's for updating and displaying window pixmaps, and receiving input.
Then you could port the widget libraries from a UI toolkit to run directly in this VM without imposing any limits to creativity and future innovation. Visual feedback for a drag operation or button push can then be animated immediately on the display, while a simple event message is sent back to the host application to trigger further processing.
Plus the application developer could implement arbitrary custom widgets and have the same low latency interaction with the user.
I'm not suggesting that the entire application should be run in this sandbox, but in some cases that may be acceptable too.
You should *always* have a stable base version that can be released at a moments notice. Each feature should be developed and tested on a branch. If the feature isn't "done", it isn't merged. If you discover a bug after merging you back it out again and review how you missed it.
Pausing development of the current set of half-finished features so you can shift priorities onto something else, should be as simple as creating a new branch and ignoring the others until your next sprint.
... which works for local communications even when the internet itself is down. Importantly, this is an application that already exists. Plus everything we're doing is open source and we'll never lock any features behind a paywall.
I've been working on Serval's software for a couple of years now building the core feature set; encrypted calling and messaging, distributed phone number lookups, file distribution, software updates and installs in the field...
But since we're initially targeting android phones, we're stuck with the range limitations of Wi-Fi. So we're trying to fund the design and manufacture of a pocket sized device with much longer range (totally shameless plug).
There's still a few missing features in our software that we'll need to finish before we call it version 1.0. But with a enough funding I could easily build a P2P directory to provide services across the internet. With no centrally controlled servers at all.
Looks like the fix they have applied will cause java.lang.zip.ZipFile to throw a ZipException, indicating a format error, whenever it encounters a duplicate entry in *any* zip file, for *any* application using android's dalvik JVM.
I'm not certain that's the correct response to this issue. Should a zip file with duplicate entries always be considered invalid?
Add your exploit code to an existing apk without removing the original items, creating a zip file with duplicate entries. The original files match the signature, the duplicates are executed after installing.
The Serval Mesh software for android encrypts voice and text messaging by default. Though it's focused on enabling communications in a disaster when everything else has failed, and doesn't have any internet based message routing. It's perfectly fine for a small community, or for sneaker-net based messaging.
They're also starting an indiegogo campaign to build and sell a device with much longer range than Wi-Fi.
APK's are signed with what amounts to the normal jar signing process. So either they have found a way to create a hash collision, or there's some other bug in the verification process that allows some unsigned code to be included in the file and executed.
Either way, you will still need to trick people into installing your version of the apk.
With DNSSEC we should be able to publish and verify certificate information via signed dns records, which would also shift the root of the trust relationship up to the dns registrars. And since the authentication part of CA certificates is tied to dns already, I don't see that this would change much.
So, if they had launched it into space, how fast would it be going after all this time? And would it still be receiving enough energy from the sun to maintain that level of thrust?
Let me tell you what's wrong with the built in messaging system in Android.
There should be a clear separation between the text entry / conversation viewing user interface, and the services that can send and receive text messages. Right now, if anyone wants to provide an alternative text message delivery service, they must replace the entire text entry user interface.
Your replacement could store the sent and received messages in the phone's SMS database. But then, whenever you open an unread message you have to remember to open the correct text entry application based on which 3rd party service your contact can use.
You can't keep a conversation going with one person, while automatically swapping between message delivery services based on changing network conditions. Nor can you easily choose which application to use based on other subscription information, eg we both use a 3rd party app like TextSecure. While you can add an app specific raw contact record with a custom action, you can't create anything with the same behaviour as a phone number field.
Application integration with Google Voice, Hangouts & the old Talk app suffer from this same basic problem.
Voice calling has similar 3rd party integration issues, but I won't delve into them now.
It probably isn't deliberate at all. If the pdf was created with a windows printer driver, the easiest method for converting word files for example, then the printer driver interface basically does the same thing. "Here's this new font definition, but I'm only using these 50 glyphs so I'm not going to tell you what the unicode characters are."
I was also thinking that each target replacement would have more than one possible variation, though from a pure entropy point of view that doesn't change the likelyhood of invalidating the watermark.
Also once you've discovered a couple of the variations used in the watermark, then choose one option from each variation randomly. Then the remaining mark may be able to identify one of the purchasers, or perhaps both of you. But could certainly narrow down the possibilities to a handful of people.
Then they'll implemented a polymorphic sentence generator. Actually you could set it all up by hand, it wouldn't take too much effort. Pick a handful of sentences, pick a handful of alternative words from a thesaurus or rephrasings that don't change the intent. Heck the alternatives could all be provided by the original author if you like. You'd need less than 60 possible replacements across the whole book to encode a unique enough watermark.
The movement of share prices correlates strongly (0.8 - 0.9) with either the velocity or the acceleration in the level of margin debt. Share prices are growing because people are borrowing money to buy them. This isn't "real" wealth creation, and it isn't sustainable.
This is an objective of the Serval Project. Our Serval Mesh software for android currently provides secure voice / chat / file distribution over local networks. But since Wi-Fi has such lousy range, we're also planning to build and sell small Wi-Fi routers with 915MHz ISM band radios for long range / low bandwidth links.
While we're focused on local communications in places where the infrastructure is down / never existed / can't be trusted, with the addition of a Distributed Hash Table, we could provide services over the internet.
Slashdot Mirror
On a phone, I doubt the magnetic heading is accurate enough.
Any asset bubble behaves in exactly the same way as a ponzi scheme. People who get out before the inevitable crash can make a huge profit, funded by the people who are left holding the assets. Just because it's a shared delusion with many people separately promoting it and no evil mastermind to blame, doesn't change the fact that the income people believe they are earning only exists on paper.
The biggest compression gains for video involve improving motion compensation, which may raise the decoders memory requirements, and entropy coding. Entropy coding is implicitly single threaded, and the complexity of this process will impose a lower bound on the clock speed of your decoder. While the rest of the decoding process can be done in parallel with lower powered circuits.
That's just Archaeologists speaking. They don't believe anything unless they dug it out of the ground themselves.
If you join my mailing list and ask good questions that demonstrate knowledge that you have gained from your own research, I will gladly answer your questions.
If you submit a concise patch out of the blue to address a specific problem, I'll probably accept it.
The patches you submit should concisely tell a story that I can quickly read to understand both the problem and the solution. The biggest piece of advice I can give you, is to study and understand your source control tools. If we are communicating through email & patches, we need a common language.
But if you're still learning, it's probably going to take a number of iterations to get any patch right. You need to be prepared to throw away everything you've done and start over. You need to be persistent, you need to ask the right questions.
If you were employed as my subordinate, I would invest a considerable amount of my time in training you in the hope that your future productivity would pay back my investment with interest. If you want to work on an open source project, convince the maintainers that you have a similar commitment.
Sure, use RDP instead of X11. It gives a reasonable display, with minimal latency between the client and server, and reasonably minimal complexity. Now try bouncing your network connection off the moon. Did I really hit that button? It doesn't look like it has changed.
What you really want is a local process to animate the button push. But locking you into using a motif style X11 button limits future innovation. And what about other kinds of user feedback?
Web browsers have thrived for many types of applications, as they give you a standard(-ish) rendering engine, a standard way to talk to remote applications, with a small amount of scripting support. But you can't always fit a round peg into a square hole.
So why not allow a application to run some code in a sandbox, with resource limits, and remove all other restrictions.
What I'd like to see built as a replacement for X11's network abstractions, is a sandboxed VM running on top of the display server, passing arbitrary messages back and forth with the remote application.
For example, take the llvm based pNaCl sandbox that the google Chrome team are building. Expose wayland API's for updating and displaying window pixmaps, and receiving input.
Then you could port the widget libraries from a UI toolkit to run directly in this VM without imposing any limits to creativity and future innovation. Visual feedback for a drag operation or button push can then be animated immediately on the display, while a simple event message is sent back to the host application to trigger further processing.
Plus the application developer could implement arbitrary custom widgets and have the same low latency interaction with the user.
I'm not suggesting that the entire application should be run in this sandbox, but in some cases that may be acceptable too.
Branch the source code!
You should *always* have a stable base version that can be released at a moments notice. Each feature should be developed and tested on a branch. If the feature isn't "done", it isn't merged. If you discover a bug after merging you back it out again and review how you missed it.
Pausing development of the current set of half-finished features so you can shift priorities onto something else, should be as simple as creating a new branch and ignoring the others until your next sprint.
... which works for local communications even when the internet itself is down. Importantly, this is an application that already exists. Plus everything we're doing is open source and we'll never lock any features behind a paywall.
I've been working on Serval's software for a couple of years now building the core feature set; encrypted calling and messaging, distributed phone number lookups, file distribution, software updates and installs in the field...
But since we're initially targeting android phones, we're stuck with the range limitations of Wi-Fi. So we're trying to fund the design and manufacture of a pocket sized device with much longer range (totally shameless plug).
There's still a few missing features in our software that we'll need to finish before we call it version 1.0. But with a enough funding I could easily build a P2P directory to provide services across the internet. With no centrally controlled servers at all.
Looks like the fix they have applied will cause java.lang.zip.ZipFile to throw a ZipException, indicating a format error, whenever it encounters a duplicate entry in *any* zip file, for *any* application using android's dalvik JVM.
I'm not certain that's the correct response to this issue. Should a zip file with duplicate entries always be considered invalid?
Add your exploit code to an existing apk without removing the original items, creating a zip file with duplicate entries. The original files match the signature, the duplicates are executed after installing.
Here's a much more useful and accurate review of PHP.
The Serval Mesh software for android encrypts voice and text messaging by default. Though it's focused on enabling communications in a disaster when everything else has failed, and doesn't have any internet based message routing. It's perfectly fine for a small community, or for sneaker-net based messaging.
They're also starting an indiegogo campaign to build and sell a device with much longer range than Wi-Fi.
APK's are signed with what amounts to the normal jar signing process. So either they have found a way to create a hash collision, or there's some other bug in the verification process that allows some unsigned code to be included in the file and executed.
Either way, you will still need to trick people into installing your version of the apk.
With DNSSEC we should be able to publish and verify certificate information via signed dns records, which would also shift the root of the trust relationship up to the dns registrars. And since the authentication part of CA certificates is tied to dns already, I don't see that this would change much.
Except for the transmission itself, which will at least allow us to track it and probably measure the effect of gravity.
So, if they had launched it into space, how fast would it be going after all this time? And would it still be receiving enough energy from the sun to maintain that level of thrust?
Let me tell you what's wrong with the built in messaging system in Android.
There should be a clear separation between the text entry / conversation viewing user interface, and the services that can send and receive text messages. Right now, if anyone wants to provide an alternative text message delivery service, they must replace the entire text entry user interface.
Your replacement could store the sent and received messages in the phone's SMS database. But then, whenever you open an unread message you have to remember to open the correct text entry application based on which 3rd party service your contact can use.
You can't keep a conversation going with one person, while automatically swapping between message delivery services based on changing network conditions. Nor can you easily choose which application to use based on other subscription information, eg we both use a 3rd party app like TextSecure. While you can add an app specific raw contact record with a custom action, you can't create anything with the same behaviour as a phone number field.
Application integration with Google Voice, Hangouts & the old Talk app suffer from this same basic problem.
Voice calling has similar 3rd party integration issues, but I won't delve into them now.
It probably isn't deliberate at all. If the pdf was created with a windows printer driver, the easiest method for converting word files for example, then the printer driver interface basically does the same thing. "Here's this new font definition, but I'm only using these 50 glyphs so I'm not going to tell you what the unicode characters are."
Heck, whenever R2D2 or C3PO get damaged in the movies, they show you just how easily they can be repaired. No harm done.
I was also thinking that each target replacement would have more than one possible variation, though from a pure entropy point of view that doesn't change the likelyhood of invalidating the watermark.
Also once you've discovered a couple of the variations used in the watermark, then choose one option from each variation randomly. Then the remaining mark may be able to identify one of the purchasers, or perhaps both of you. But could certainly narrow down the possibilities to a handful of people.
Then they'll implemented a polymorphic sentence generator. Actually you could set it all up by hand, it wouldn't take too much effort. Pick a handful of sentences, pick a handful of alternative words from a thesaurus or rephrasings that don't change the intent. Heck the alternatives could all be provided by the original author if you like. You'd need less than 60 possible replacements across the whole book to encode a unique enough watermark.
The movement of share prices correlates strongly (0.8 - 0.9) with either the velocity or the acceleration in the level of margin debt. Share prices are growing because people are borrowing money to buy them. This isn't "real" wealth creation, and it isn't sustainable.
Then again, if they are sending you an SMS to verify your ownership of the number, can they gain any revenue from that?
This is an objective of the Serval Project. Our Serval Mesh software for android currently provides secure voice / chat / file distribution over local networks. But since Wi-Fi has such lousy range, we're also planning to build and sell small Wi-Fi routers with 915MHz ISM band radios for long range / low bandwidth links.
While we're focused on local communications in places where the infrastructure is down / never existed / can't be trusted, with the addition of a Distributed Hash Table, we could provide services over the internet.