I think Postgres is good for what it is-- a clean, single-node database system. Clustering adds some complexity in deployment (we're working on making this easier) that you wouldn't want to incur for a typical Postgres install.
I think there are pieces of Postgres-XL that make sense to be in core/vanilla PostgreSQL, and we'll be working to contribute them upstream. Likewise, there are more pieces from TransLattice's commercial database offering, TED, that Postgres-XL could benefit from that we intend to contribute.
Honestly, just organizational readiness. We are likely to move to a BSD-style license in the future... but initially taking a license that made it a little harder to have a closed-source fork was easier to convince some members of the team/board. (There's been a significant amount of investment in producing this codebase and we wanted to make sure we didn't immediately enable a competitor).
Look at Postgres-XL that we just released. It's a clustered database and can do MPP execution of your queries and has good write-scalability too. (To use all the processors in each machine, you'll want to have a few data nodes per machine.) It's pretty clever about planning a lot of things.
> (protip: fully parenthesize everything, because no, that line doesn't do what you meant, and I have to fix it after they can your ass).
Heh. I more often have to deal with the opposite-- people who know the order of operations and use it to write really complicated expressions that are correct but not obvious, and confuse the fuck out of people trying to read the code... that then I have to go break into the actual expressions and describe to people.
The summary is correct about reduced pain. It's backwards about stress level:
Further testing showed that the rodents exposed to male odors were actually feeling less pain, rather than simply hiding the pain they were in. The male aroma ramped up their stress levels, which deadened the hurt. “It’s really astounding that such a robust effect could have been missed for so many years,” Mogil says.
Note a depth mapping technique for each pixel isn't Doom-style restrictions unless the camera is in an unusual orientation.
You can have tables, etc. Every pixel has a distance from the camera to the object estimated. Since the camera is probably in a horizontal location this works. What you -can't- know about are objects behind other objects from the camera's standpoint, or stuff behind the camera. This is mostly OK for faking depth of field.
The problem is a fairly large proportion of GSM phones stolen in the US are sent to other countries, with carriers who do not blacklist from US theft reports.
Yah, that's not a great move vs. a civil regulator like the FAA or FCC.
He has a pilot certificate that they can revoke; they can impose civil (not criminal) fines of tens of thousands of dollars before an administrative law judge, where there's no standard of proof beyond a reasonable doubt (only preponderance of the evidence).
It's pretty much what everyone's expected to do and makes technical sense: you don't know the topology of the other guy's network, so if you have a packet for one of his customers, you should hand it over to that network at the closest possible point, rather than hauling it over your backbone and possibly having the other guy haul it back if your assumptions about costs are wrong..
But this means people that are "push" heavy use a lot less backbone resources than the provider that is receiving the traffic. Historically that has resulted in payments when peering connections have significantly asymmetric traffic flows.
Name one thing you know firsthand is connected to the Internet and could result in casualties if attacked. Sure banks computers could crash, sure amazon could go down, but ICBMs are not going to launch and the power grid wont go down. If anything that could actually cause casualties is connected to the Internet then it shouldn't be.
SCADA (Supervisory Control and Data Acquisition) technology provides the means to monitor and control distributed systems from a central location. They are used widely in the telecommunications, power distribution, oil & gas and transportation industries. SCADA systems are typically deployed with dedicated communication infrastructure, proprietary software and hardware.
iSCADA, on the other hand is an Internet-based SCADA solution that utilizes the public Internet infrastructure as the data communication medium. It uniquely combines traditional SCADA technology with the open data communication protocols, services and data formats of the public Internet to deliver cost-effective and easy-to-use SCADA solutions. With iSCADA, it is now feasible to monitor and control virtually anything from anywhere in the world.
This kind of stuff is getting deployed more and more.
Any person who willfully threatens to commit a crime which will result in death or great bodily injury to another person, with the specific intent that the statement, made verbally, in writing, or by means of an electronic communication device, is to be taken as a threat, even if there is no intent of actually carrying it out, which, on its face and under the circumstances in which it is made, is so unequivocal, unconditional, immediate, and specific as to convey to the person threatened, a gravity of purpose and an immediate prospect of execution of the threat, and thereby causes that person reasonably to be in sustained fear for his or her own safety or for his or her immediate family's safety, shall be punished by imprisonment in the county jail not to exceed one year, or by imprisonment in the state prison.
or (c) Any person who maliciously informs any other person that a bomb or other explosive has been or will be placed or secreted in any public or private place, knowing that the information is false, is guilty of a crime punishable by imprisonment in the state prison, or imprisonment in the county jail not to exceed one year.
Or there are many other choices of statute depending on specific circumstances. Note that both of these require malice. If you were going to legally set off a bomb as part of a demonstration when you had a pyrotechnics license, neither of these would apply.
The short answer is, CA/CP/AP on a transaction-by-transaction basis depending on application requirements. Also of note: network delay is effectively a special "partition", requiring an engine that can have massive workloads in flight and reconcile/order non-commutative changesets in a distributed fashion.
And that's what Translattice does, actually: for the database part of the system, we transparently shard large tables behind the scenes, and figure out how to store it to the computing resources available taking into account historical usage patterns and administrators' policies on how data must be stored (for redundancy and compliance purposes). A different population of nodes is used to store each shard and the redundancy is effectively loosely coupled, so when a failure or partition occurs, the work involved in re-establishing redundancy is fairly shared over all nodes. This provides linear scalability for many workloads and better redundancy properties, and can also as a side benefit position data closer to where it's consumed.
When it comes time to access the data, the query planner in our database figures out how to efficiently dispatch the query to the minimal necessary population of nodes, introducing map and reduce steps to provide for data reduction and efficient execution.
All of the table storage is directly attached to the nodes, eliminating much of the need for a storage area network and scaling beyond where shared-disk database clusters can go.
I didn't expect we'd be on Slashdot just yet. I'm Michael Lyle, CTO and cofounder of Translattice.
With regards to the original submitter's question, we'd love to talk to him. How much we can help, of course, depends on the specific scenario he's hitting.
What we've built is an application platform constituted from identical nodes, each containing a geographically decentralized relational database, a distributed (J2EE compatible) application container, and distributed load balancing and management capabilities. Massive relational data is transparently sharded behind the scenes and assigned redundantly to the computing resources in the cluster, and a distributed consensus protocol keeps all of the transactions in flight coherent and provides ACID guarantees. In essence, we allow existing enterprise applications to scale out horizontally while keeping the benefits of the existing programming model for transactional applications, by letting computing resources from throughout an organization combine to run enterprise workloads.
Current stacks are really complicated, multi-vendor, and require extensive integration/custom engineering for each application install. We're striving to create a world where massively performing infrastructure can be built from identical pieces.
OK, but to say it one more time, adjusted this time for your example...
If you take a given JPEG2000 compressor, not all valid JPEG2000 files can be created by a given compression implementation, no matter what the input is. If the input is further constrained in some way -- whether it's constrained to be a particular input or say, just something that came from a Bayer-filtered sensor... the number of possible output files is decreased further.
A smart adversary may be able to prove that the beginning of the file (or other files you have around) was created by a given compressor, but that other portions could never be created by that implementation, thus detecting the steganography.
If you're saying to leave the files unaltered, what you're really doing is using the contents of the files as the key, and carrying the enciphered message in the form of offset numbers. Which is really cryptography (and weak cryptography at that), and not steganography.
If you're proposing editing the files on disk to hide the message in them, well.. that's potentially vulnerable to the types of attack I mentioned above. A small amount of modification is no more innocent than a lot of modification when this attack/detection practice applies.
Still, that 6MB high entropy MP3 was not created by hand. You must be able to hide the data in such a way that not only is the file functionally intact for decompression, but also that the file could be created by an MP3 compressor (probably a known implementation even). The problem may be even further constrained if the input is known.
If there's 100,000 combinations of MP3 compressors and reasonable settings for them, and playing the audio back returns a certain song such that it appears the song was ripped from MP3 or is otherwise tied to original source material (as most all MP3s are)... for each song there's less than 100,000 likely values. If you can fingerprint based on output the likely compressor and settings (not too demanding of a task for at least the common approaches), you can then evaluate how that compressor would compress the entire song and compare for differences. You can also do things like fuzzy comparison against known circulating copies of songs, etc.
Functionally intact is not hard. Making the file have a plausible non-steganography-related history of how it was created against smart people carefully looking at it is hard.
The problem with steg'ing inside known container formats, compressed container formats, is this:
Each implementation of the compression algorithm has its nuances. If the majority of an MP3 looks like it was compressed by the iTunes implementation, but then there's a range of output iTunes would not generate (particularly if the input file is known), that's very suspect. Ditto if things like PSNR change, even subtly, for the portion where steganography is in play. Even though compressed data has a great deal of entropy, it IS significantly constrained over random data in that A) known decompression programs must return specified output from it, and B) known compression programs generated this data as output from possibly-known input data.
If your adversary is the local police or one of your buddies, this stuff doesn't matter. If it's intelligence agencies or research organizations, good luck. Steganography is hard.
[citation needed] on slashdot is annoying. It's doubly annoying when you say it to someone who clearly is engaging in some over-the-top satire and not trying to make a true, serious, fact-based argument.
My original simple model for the point of discussion left out the effects of birth defects, as well as things other than death that can cause human misery (e.g. cancers). Also, bioaccumulation was left out. It's purely a back of the envelope approximation.
When you mention the Sb in particular, it is likely to do a bit better (locally) than the half life would indicate, because antimony oxides are fairly soluble and are likely to find transport in water.
As others have mentioned, no doubt some of the effects on animal populations are because of the radioactivity itself, but others are probably due to humans leaving and no longer leaving so much yummy trash around (and other related effects as the area transitions and "goes wild").
If I'm done breeding, and there was some good reason to, I'd be happy to live there in another 10 years. The risk over my remaining lifespan would be pretty small, I think.
Slashdot Mirror
Really premature, and unlikely in any event.
I think Postgres is good for what it is-- a clean, single-node database system. Clustering adds some complexity in deployment (we're working on making this easier) that you wouldn't want to incur for a typical Postgres install.
I think there are pieces of Postgres-XL that make sense to be in core/vanilla PostgreSQL, and we'll be working to contribute them upstream. Likewise, there are more pieces from TransLattice's commercial database offering, TED, that Postgres-XL could benefit from that we intend to contribute.
Honestly, just organizational readiness. We are likely to move to a BSD-style license in the future... but initially taking a license that made it a little harder to have a closed-source fork was easier to convince some members of the team/board. (There's been a significant amount of investment in producing this codebase and we wanted to make sure we didn't immediately enable a competitor).
We just released Postgres-XL so you can have horizontal scalability and MPP.
Look at Postgres-XL that we just released. It's a clustered database and can do MPP execution of your queries and has good write-scalability too. (To use all the processors in each machine, you'll want to have a few data nodes per machine.) It's pretty clever about planning a lot of things.
> (protip: fully parenthesize everything, because no, that line doesn't do what you meant, and I have to fix it after they can your ass).
Heh. I more often have to deal with the opposite-- people who know the order of operations and use it to write really complicated expressions that are correct but not obvious, and confuse the fuck out of people trying to read the code... that then I have to go break into the actual expressions and describe to people.
The summary is correct about reduced pain. It's backwards about stress level:
Further testing showed that the rodents exposed to male odors were actually feeling less pain, rather than simply hiding the pain they were in. The male aroma ramped up their stress levels, which deadened the hurt. “It’s really astounding that such a robust effect could have been missed for so many years,” Mogil says.
vs.
The rodents are also less stressed out.
Note a depth mapping technique for each pixel isn't Doom-style restrictions unless the camera is in an unusual orientation.
You can have tables, etc. Every pixel has a distance from the camera to the object estimated. Since the camera is probably in a horizontal location this works. What you -can't- know about are objects behind other objects from the camera's standpoint, or stuff behind the camera. This is mostly OK for faking depth of field.
The argument against shorter-term leases is that you have to invest a lot in infrastructure to make use of the spectrum.
Most of these licenses that are being bid for in the auction are for ten year terms, I believe.
The problem is a fairly large proportion of GSM phones stolen in the US are sent to other countries, with carriers who do not blacklist from US theft reports.
Yah, that's not a great move vs. a civil regulator like the FAA or FCC.
He has a pilot certificate that they can revoke; they can impose civil (not criminal) fines of tens of thousands of dollars before an administrative law judge, where there's no standard of proof beyond a reasonable doubt (only preponderance of the evidence).
What counts are the claims, not the description of how it works. You won't find Windows 95, SLIP, etc, in the claims.
Uh.. secure communications for the client even if the adversary controls the client? Good luck with that.
Shortest exit path routing.
It's pretty much what everyone's expected to do and makes technical sense: you don't know the topology of the other guy's network, so if you have a packet for one of his customers, you should hand it over to that network at the closest possible point, rather than hauling it over your backbone and possibly having the other guy haul it back if your assumptions about costs are wrong..
But this means people that are "push" heavy use a lot less backbone resources than the provider that is receiving the traffic. Historically that has resulted in payments when peering connections have significantly asymmetric traffic flows.
Name one thing you know firsthand is connected to the Internet and could result in casualties if attacked. Sure banks computers could crash, sure amazon could go down, but ICBMs are not going to launch and the power grid wont go down. If anything that could actually cause casualties is connected to the Internet then it shouldn't be.
http://www.devicesworld.net/
This kind of stuff is getting deployed more and more.
I think he was engaging in some hyperbole for effect, but..
Most of Wisconsin gets over 4' of snow per year, and portions of northern Wisc. get over 13 feet.
http://www.crh.noaa.gov/mkx/climate/avg-wi-snow.gif
Yes. For instance, under California law:
Any person who willfully threatens to commit a crime which
will result in death or great bodily injury to another person, with
the specific intent that the statement, made verbally, in writing, or
by means of an electronic communication device, is to be taken as a
threat, even if there is no intent of actually carrying it out,
which, on its face and under the circumstances in which it is made,
is so unequivocal, unconditional, immediate, and specific as to
convey to the person threatened, a gravity of purpose and an
immediate prospect of execution of the threat, and thereby causes
that person reasonably to be in sustained fear for his or her own
safety or for his or her immediate family's safety, shall be punished
by imprisonment in the county jail not to exceed one year, or by
imprisonment in the state prison.
or (c) Any person who maliciously informs any other person that a
bomb or other explosive has been or will be placed or secreted in any
public or private place, knowing that the information is false, is
guilty of a crime punishable by imprisonment in the state prison, or
imprisonment in the county jail not to exceed one year.
Or there are many other choices of statute depending on specific circumstances. Note that both of these require malice. If you were going to legally set off a bomb as part of a demonstration when you had a pyrotechnics license, neither of these would apply.
The short answer is, CA/CP/AP on a transaction-by-transaction basis depending on application requirements. Also of note: network delay is effectively a special "partition", requiring an engine that can have massive workloads in flight and reconcile/order non-commutative changesets in a distributed fashion.
And that's what Translattice does, actually: for the database part of the system, we transparently shard large tables behind the scenes, and figure out how to store it to the computing resources available taking into account historical usage patterns and administrators' policies on how data must be stored (for redundancy and compliance purposes). A different population of nodes is used to store each shard and the redundancy is effectively loosely coupled, so when a failure or partition occurs, the work involved in re-establishing redundancy is fairly shared over all nodes. This provides linear scalability for many workloads and better redundancy properties, and can also as a side benefit position data closer to where it's consumed.
When it comes time to access the data, the query planner in our database figures out how to efficiently dispatch the query to the minimal necessary population of nodes, introducing map and reduce steps to provide for data reduction and efficient execution.
All of the table storage is directly attached to the nodes, eliminating much of the need for a storage area network and scaling beyond where shared-disk database clusters can go.
I didn't expect we'd be on Slashdot just yet. I'm Michael Lyle, CTO and cofounder of Translattice.
With regards to the original submitter's question, we'd love to talk to him. How much we can help, of course, depends on the specific scenario he's hitting.
What we've built is an application platform constituted from identical nodes, each containing a geographically decentralized relational database, a distributed (J2EE compatible) application container, and distributed load balancing and management capabilities. Massive relational data is transparently sharded behind the scenes and assigned redundantly to the computing resources in the cluster, and a distributed consensus protocol keeps all of the transactions in flight coherent and provides ACID guarantees. In essence, we allow existing enterprise applications to scale out horizontally while keeping the benefits of the existing programming model for transactional applications, by letting computing resources from throughout an organization combine to run enterprise workloads.
Current stacks are really complicated, multi-vendor, and require extensive integration/custom engineering for each application install. We're striving to create a world where massively performing infrastructure can be built from identical pieces.
OK, but to say it one more time, adjusted this time for your example...
If you take a given JPEG2000 compressor, not all valid JPEG2000 files can be created by a given compression implementation, no matter what the input is. If the input is further constrained in some way -- whether it's constrained to be a particular input or say, just something that came from a Bayer-filtered sensor... the number of possible output files is decreased further.
A smart adversary may be able to prove that the beginning of the file (or other files you have around) was created by a given compressor, but that other portions could never be created by that implementation, thus detecting the steganography.
If you're saying to leave the files unaltered, what you're really doing is using the contents of the files as the key, and carrying the enciphered message in the form of offset numbers. Which is really cryptography (and weak cryptography at that), and not steganography.
If you're proposing editing the files on disk to hide the message in them, well.. that's potentially vulnerable to the types of attack I mentioned above. A small amount of modification is no more innocent than a lot of modification when this attack/detection practice applies.
Still, that 6MB high entropy MP3 was not created by hand. You must be able to hide the data in such a way that not only is the file functionally intact for decompression, but also that the file could be created by an MP3 compressor (probably a known implementation even). The problem may be even further constrained if the input is known.
If there's 100,000 combinations of MP3 compressors and reasonable settings for them, and playing the audio back returns a certain song such that it appears the song was ripped from MP3 or is otherwise tied to original source material (as most all MP3s are)... for each song there's less than 100,000 likely values. If you can fingerprint based on output the likely compressor and settings (not too demanding of a task for at least the common approaches), you can then evaluate how that compressor would compress the entire song and compare for differences. You can also do things like fuzzy comparison against known circulating copies of songs, etc.
Functionally intact is not hard. Making the file have a plausible non-steganography-related history of how it was created against smart people carefully looking at it is hard.
Not exactly.
The problem with steg'ing inside known container formats, compressed container formats, is this:
Each implementation of the compression algorithm has its nuances. If the majority of an MP3 looks like it was compressed by the iTunes implementation, but then there's a range of output iTunes would not generate (particularly if the input file is known), that's very suspect. Ditto if things like PSNR change, even subtly, for the portion where steganography is in play. Even though compressed data has a great deal of entropy, it IS significantly constrained over random data in that A) known decompression programs must return specified output from it, and B) known compression programs generated this data as output from possibly-known input data.
If your adversary is the local police or one of your buddies, this stuff doesn't matter. If it's intelligence agencies or research organizations, good luck. Steganography is hard.
[citation needed] on slashdot is annoying. It's doubly annoying when you say it to someone who clearly is engaging in some over-the-top satire and not trying to make a true, serious, fact-based argument.
It's a good point you raise.
My original simple model for the point of discussion left out the effects of birth defects, as well as things other than death that can cause human misery (e.g. cancers). Also, bioaccumulation was left out. It's purely a back of the envelope approximation.
When you mention the Sb in particular, it is likely to do a bit better (locally) than the half life would indicate, because antimony oxides are fairly soluble and are likely to find transport in water.
As others have mentioned, no doubt some of the effects on animal populations are because of the radioactivity itself, but others are probably due to humans leaving and no longer leaving so much yummy trash around (and other related effects as the area transitions and "goes wild").
If I'm done breeding, and there was some good reason to, I'd be happy to live there in another 10 years. The risk over my remaining lifespan would be pretty small, I think.