The code is there, the actual performance is going to be lackluster at best.
Mesh networks suffer from scaling problems due to the overhead associated with ad-hoc protocols. All that flexibility and adaptability come at a price: efficiency, latency and throughtput all decrease as the size of the mesh increases (and even more so when you have popular / power law nodes attracting routes)
Voice is notoriously sensitive to delay and to some degree packet loss. Sure, delay effects can be overblown (ATM anyone?) but you get a saturated mesh network trying to route voice and those multi-second round trip times are going to make your cable modem look like a T3.
[You get losses due to interference, transient link problems, mobile nodes, sun spots, whatever, that cause delays at the physical layer (an ethernet frame takes a while to traverse the ether) which then affects all higher layer protocols: UDP packets can't be reassembled because a fragment is lost. TCP starts backing off too agressively. Retransmission timers get triggered adding to inefficiencies, the list goes on]
Wireless and mesh networking in particular are very promising and useful technologies, but they are no where near the utopia that is often presented.
Trivial DoS attacks, scalability problems, and compounded complexity all add up to make it a very volatile environment.
Sure, this stuff will work, but only in very constrained configurations / environments.
Maybe someday further in the future these dreams can be realized when we have robust MIMO software radios and intelligent network stacks that can adapt to such harsh conditions.:-)
Rather, the network needs some form of role-based assertion or qualification of the relationship.
The problem with this is the classic meta-data problem: how do you get users to enter in a sufficient amount of meaninful information about their peers?
The simple approach (and also the most innaccurate/flawed) is the binary status of "friend / non-friend" which has the drawbacks you mention.
But a much more detailed and expressive syntax would be incredibly cumbersome. For every person in your social network you would need to answer the detailed questionaire: "is this person a friend acquaintance. Is the friendship activity based, personal, business, etc." ad infinitum.
And unless everyone responded with completeness, the validity of any given link expressed between two people could vary greatly.
I'm a big fan of the implicit approach, and the research mentioned above goes a little ways towards implictly identifying and categorizing the nature of links between peers in a social network.
If a system could observe your interactions with others via email, phone, web communities, etc. (and preserve the privacy of such information - but thats another discussion) then the need for explicitly defining this social metadata would be reduced, as many of the aspects of social interactions could be inferred implicitly without bothering the user to enter (partial) information themselves.
There is a lot of progress to be made in this space; hopefully it will happen soon:-)
The problem is more complicated, and you touch on one of the main weaknesses of any system where reputation and feedback in involved.
One aspect of the problem is the granularity by which relationships are defined. In many of the sites there is only one state: "friend or non friend". The real world encompases a number of shades and types, from business acquaintance to personal friend, intimate lover, etc.
Another aspect is the incentive to "game" these systems by increasing your friend count. This inevitably leads people loosening their interpretation such that they increase their visibile friend count. If the number if friends you were linked to was not public, there would be less of this (but you can't do that without breaking some of the functionality of the sites)
People have talked about "winning" at friendster or tribe or orkut - but there is no "winning" in these systems, as there should not be competition.
Last, there is no method for verification of any status between peers. Can you "prove" that so and so is really a friend?
There are others, but these are the main three, and not likely to be solved or addressed any time soon.
From football conferences to food webs: U-M researcher uncovers patterns in complicated networks SEATTLE---The world is full of complicated networks that scientists would like to better understand---human social systems, for example, or food webs in nature. But discerning patterns of organization in such vast, complex systems is no easy task.
"The structure of those networks can tell you quite a lot about how the systems work, but they're far too big to analyze by just putting dots on a piece of paper and drawing lines to connect them," said Mark Newman, an assistant professor of physics and complex systems at the University of Michigan.
One challenge in making sense of a large network is finding clumps---or communities---of members that have something in common, such as Web pages that are all about the same topic, people that socialize together or animals that eat the same kind of food. Newman and collaborator Michelle Girvan, a postdoctoral fellow at the Santa Fe Institute in Santa Fe, New Mexico, have developed a new method for finding communities that reveals a lot about the structure of large, complex networks. Newman will discuss the method and its applications Feb. 15 at the annual meeting of the American Association for the Advancement of Science in Seattle.
"The way most people have approached the problem is to look for the clumps themselves---to look for things that are joined together strongly," said Newman. "We decided to approach it from the other end," by searching out and then eliminating the links that join clumps together. "When we remove those from the network, what we're left with is the clumps."
The researchers tested their method on several networks for which the structure was already known---college football conferences, for example. In college football, teams in the same conference face off more frequently than teams in different conferences. When inter-conference games do occur, they're more likely to be between teams that are geographically close together than between teams that are far apart. Plugging in information on frequency of games between pairs of teams in the 2000 regular season, Newman and Girvan tested their method to see if it could correctly sort the colleges into conferences. "There were a few cases where it made mistakes, but it got well over 90 percent of them right," said Newman. "It gave us the structure we were expecting, so that was encouraging."
Newman and Girvan---and other researchers who've learned about their work---have gone on to apply the technique to systems where the structure is not as well understood, looking at everything from networks of Spanish language web logs to communities of early jazz musicians to a food web of marine organisms living in Chesapeake Bay.
"Networks and other systems that we study are becoming increasingly large and complicated these days," said Newman. "New methods like this help us to make sense of what we see and to understand better how things work."
###
For more information: Mark Newman -- http://www-personal.umich.edu/~mejn/ American Association for the Advancement of Science -- http://www.aaas.org/ Santa Fe Institute -- http://www.santafe.edu/
If this were done (and it's definitely a good idea) they would likely have to switch to acoustic fingerprinting.
This would require a lot more resources and complexity, but I doubt the RIAA would give up so easily.
Recall that people were doing the same thing to the napster filters when they were applied. Names of files would have letters swapped around and replaced, all to avoid the strict filtering that was supposed to stem the trade of copyrighted music.
Because if it's true, BitTorrent (or a full-fledged P2P network employing similar concepts) takes care of that.
You have to be careful to draw a distinction between a protocol that supports multi-source downloading and one that enforces multi source downloading.
In bittorrent (and any of the other multi-source DL apps) it is possible to download the entire file from a single peer, by altering the client to only use that one peer for the duration of a download.
The RIAA also has a number of nodes at their disposal, so even a coordinated download among many of them obtaining pieces could collectively obtain the entire file from a peer, without them having the slightest clue what just happened.
Attack resistance of this nature is difficult to implement. This is a war of attrition, and when the current easy methods are subverted, additional methods will be applied (acoustic fingerprinting for example).
I can see it now, next generation P2P networks where only 99% (or whatever) of the file is shared.... Actually that begs the question, how much of a song do you have to share to cross the line into the illegal
Any block by itself is completely useless and cannot be considered infringing. A user simply requests the various blocks and when all are obtained, recreates the original file in whole.
Many other peer networks designed for anonymous distribution also use similar methods.
they don't. downloading music is perfectly legal. It is the unauthorized distribution part that they can get you for.
Confusion over how infringing files are identified
on
RIAA Files 532 Lawsuits
·
· Score: 5, Interesting
I see a lot of confusion over the way files are identified and whether this will stand up in court or not.
If you think they are using a method as trivial as "they responded to a search for name label_muzak.mp3" you are mistaken. This would definitely not be credible evidence in court (anything could be in the file) and it's not how the RIAA is going about tracking illegal uploads.
The method they are using has been described in some of the articles concerning the subpoenas issued to users of the networks and it works as follows:
1. The RIAA employs modified nodes in the various networks (KaZaa and Morpheous seem to be the big two) to search for known song names or groups.
2. When they find a match, they attempt to download the entire file from the user. This point is important: if they can't prove you actually uploaded a copyrighted file in its entirety, they don't have a case.
3. When the upload is complete they perform an MD5 sum on the content and verify that it matches a database of known copyrighted files. If they didn't do this step, they would have to have someone listen to it to be sure its actually what they think it is.
Given the nature of peer networks, there are a number of common rips (i.e. identical) of songs widely shared among many users. Thus the MD5 sums will match for the same file among many users.
This is all the information they need to bring a suit against your. They have an IP address and time/date associated with the upload, they have a verified MD5 sum for the upload that matches known copyrighted files.
This information was covered in a previous article here: Innocent File-Sharers Could Appear Guilty? and the techniques they use are explicitly designed to withstand the scrutiny of a legal proceeding.
All of the cases of mistaken identity to date (the mac user sent a nasty gram, the grandmother, etc) appear to be mistakes by the ISP correlating a given IP + date into the right account holder, and not a flaw in their methods associated with identifying infringing content traded over the networks.
By "interior" i meant that not only would the aerogel have to contain no air, but a hollow cavity as well, with some way to prevent air from entering it either. Kind of like a solid baloon filled with a vacuum instead of a rubber surface filled with helium for example...
But that would be one interesting block of blueish haze. it would rest on your ceiling and not your desk:-)
Air. The substance is made by creating links between strands of silicate (glass) under special conditions contained in a liquid solution. When the liquid is removed, all that remains is a very porous structure with incredibly small silicate links surrounding cavities filled with air. (grossly simplified explanation)
If the interior of aerogel were a vacuum, you could potentially create a solid that is lighter than air (although its structural stability and strength would be reduced)
you can buy this stuff from MarkeTech for the rock bottom price of $975 a 4x8x0.5" piece.
I'll let someone else figure out how expensive an entire house would be to insulate.
Note that this isn't even the really good stuff (the average density of the commercial stuff is only 99.9% air, while the hi-tech versions used by NASA can be as high as 99.99% air or more)
Secure programming requires additional skill and focus during design, development, testing and configuration. This drives up costs and extends schedule for any project.
Ultimately the market decides winners in the software space (usually), and everyone needs to see security as a feature worth paying more for, in terms of employees designing and building the systems, to QA testers performing thorough audits before deployment, to users comparing choices in the corporate or consumer software space.
The author argues that it will take a digital pearl harbor to affect this change. I doubt it will be as drastic. We are already seeing consumers, users and businesses move towards more secure systems (and adding more diversity - breaking the monoculture)
The pain is only going to increase as attacks grow more and more prevalent, and damage more and more severe. Instead of a single, high profile event, I think we are going to see the current trend continue and accelerate: more and more people spending more money on secure systems, and diversifying their environments.
In the software market consumers and producers are equaly responsible for the state of security - it costs more time and money and skill to build secure systems: are people paying more for the secure alternatives on the market? do people make a thorough effort to address security before purchase? Until the answer is yes, the current methods will remain the market leader. Those that ignore security (to the extent they can) will come to market faster and cheaper than their more secure alternatives.
Those that put a premium on secure systems will spend more for a solution that gives them the stability and features they require, and understand the tradeoff involved in terms of cost, time and skill.
You didn't mention any specific vulnerabilities that were directed against you in this audit. Were there any legitimate holes that you overlooked or was most of the report fabricated?
Security is a complex task in any environment (from physical threats, unknown vulnerabilities, social engineering, misconfiguration, etc) and the increased size and complexity of networks and systems means this problem will only get worse.
Having what sounds like a single security / administrator handling a financial computer network does sound risky to me personally (but maybe you were just singled out among you coworkers?)
Your comment about telecommuting is a good one though. No longer requiring physical presence to do a contract or work some other position could free you up for additional tasks at other companies bringing your overall salary to a decent level.
Both parties get what they want in the deal; businesses with inexpensive, on demand services; engineers working an efficient schedule for multiple clients (thus good wage despite lower prices on individual jobs)
I'm not sure what kind of reputable engineer you would need to be to pull this off. Liability is going to be the major sticking point on any contract or work-for-hire (until you get a proven track record of completed, functional projects)
It would seem that if you have a clear line of sight to multiple APs, then you could combine them and have more bandwidth than a single AP-channel connection would provide.
This is called "concurrent multiple association" or simple multiple assocation / AP hopping, and it's something i've been working on off and on for a little while. I talk about it in a bit more detail on the Janus Wireless pages, but I have yet to get anything stable ready for prime time use.
The current problem with multiple association is that you need a very low latency interface to the network radio's at a packet injection / monitor mode level.
I've been able to get this to work in a very crude and inefficient manner with cisco/prism cards used for monitor mode recv of packets, and prism2 based cards for packet injection to implement the multiple association and data packet injection.
There is some hope that the newer cards, specifically the atheros 802.11a/g cards with a reversed binary HAL driver could provide the requisite low level functions to do this efficiently.
But then you are faced with another problem: aggregating the UDP datagrams from multiple sources into a single address space similiar to the way mobile-IP has a dedicated "public" host which acts as your intermediary as your IP changes without breaking existing TCP connections.
I've played with this a bit as well on a dedicated host that has a few IP's, and it works like a NAT that collates UDP datagrams from a wide variety of sources and converts them into the desired TCP/UDP/etc communication from that public endpoint.
In short: for multiple association you need a number of new driver and radio interfaces for:
1) very low latency packet injection and monitor style recv.
2) specialized mobile-IP like drivers on the client that present a virtual interface (ethX) to then host while using injected datagrams over the various multiply-associated wifi links for transport.
3) a dedicated public host with an IP it can allocate to you that accepts all of these incoming UDP packets from various source addresses (all the AP's you are using) and combines them into standard IP traffic from that public IP (ala mobile-IP as well).
None of this is extremely difficult (with the newer cards) but it is a lot of code, and a lot of work, and requires some dedicated host resources.
Now, for the cool part. When you do have all of these pieces in place, it allows you to:
- Simply add cards to your system for more bandwidth. The multiple association throughput is limited only by the number of AP's you can talk to, and the number of cards you have to monitor and inject packets with. It scales nicely barring interference problems.
- Maintain extremely high throughput as you move anywhere within range to open AP's! You could aggregate the upload capacity of 30 AP's to get a 10Mbps link to the net and maintain this constant fat uplink as you drive around the city.
- Enjoy extremely reliable / robust communications. Since you are no longer dependant on a single AP, you dont have to worry about connection dropping, clients messing with your signal, etc. Your aggregate connection is spread over a number of AP's which means problems with individual AP's make only a very small impact on overall connectivity.
This is really the way things are headed, and its only a matter of time before they become useable and widespread.
I think the point was that fixing bugs alone is not sufficient. You need to approach the code base from two angles.
The first being a high level overview / design document that provides a big picture of how the pieces correlate and interact with each other.
The second being bug fixes and other tasks to get familiar with the low level details of the implementation.
The two together make for a great way to familiarize yourself with a project, but code alone with no other documentation is tedious and much less effective.
I've found a few other misconceptions in open source development that have irked me over the years.
1. Using autoconf/automake will make my code portable.
TRUTH: You need to know what system calls are portable, which ones arent, and the nuances in using each on different platforms. The auto* tools will only make detecting and utilizing the correct versions easy. It's up to you to identify and code for them in the first place. (Ditto for compiler flags, shared libraries, linker options, etc)
2. Network programming is easy.
TRUTH: I've seen a lot of projects that implement their own network communication using TCP sockets and sprintf text messages. A number of others transmit little endian integers around. And others still use a blocking style request->response form of communication.
Good network programming is really hard, and unless you take the effort to design and implement something robust from the start, this kind of ad-hoc, inflexible networking will become embedded into the application and require significantly more rework later down the road.
And PLEASE reuse something that might fit before even attempting to write your own layer. The gnutella protocol is a great example of this problem.
3. Threading is as simple as using pthreads and mutexes.
TRUTH: Good threading code is difficult to develop and difficult to debug. It is always preferable to use an event based model where possible, and rely on threads only when you need scalability on SMP, work arounds for blocking system calls (gethostbyname_r), or background tasks that you dont want delaying interaction with a user or network app (there are many other reasons, but these give you the general idea of where threading is appropriate).
Synchronizing access to shared resources between threads is also very tricky. The level of granularity of locking, and the structure of your data structures themselves, will have a significant impact on performance. Too much granularity and you end up with extremely complex locking hierarchies that are difficult to debug, more prone to dead lock. Too little granularity and you get lots of contention for these shared resources.
Finding the sweet spot is tricky, and often requires lots of experience or tuning to get right. The lack of tools to provide visibility to lock contention and latency also make this difficult.
I'm sure there are others, but these are the big ones that come to mind.
There isnt anything specific you need for multipoint, just that the antennas are usually radiating in a much wider path than the highly directional point to point.
For example, many WISP's use 90 degree sector antennas for point to multi-point and have around 9dBi to 12dBi of gain (sometimes as high as 15).
So for these systems you are allowed 4W EIRP max, regardless of antenna gain, and 1W dBm from the radio max, regardless of antenna gain.
So the highest radio output allowed would be a 1W amp on a 6dBi panel antenna.
If you go with a 15dBi sector, you would need to cut the radio output down significantly.
I would be curious to find out how much improved the system is if you did the following (you may need linux / bsd to do it):
1. Use the demo ad-hoc mode designed by Lucent prior to IBSS mode standardization. This has no ACK, and thus will suffer much less when the SIFS and even DIFS is exceeded.
2. Fix the cards at a specific rate. You could start at 1Mbps and work up, see what you max out at. If you have short pigtails going to the amps, going almost directly into the antennas, you should be able to use 5.5, maybe even 11 consistently.
3. The antenna problems sound similiar to things I have encountered on dual port cards with antenna selection gone awry. Can you confirm there is only one port, or if dual that the "master" or "primary" is the one being used?
It could also be the cisco car detecting significant and continued SIFS timeouts and trying antenna diversity as a workaround? Weird...
One last thing that may be useful is fragmentation, but I suspect this wont make a lot of difference...
I think your remaining argument is that regardless of laws of the time, the marriages below a certain age constituted exploitation.
Not exploitation, RAPE. Such a dirty word. A 35+ year old man coercing a 14 year old girl into sex is RAPE. Can we agree on that? If not, good day to you sir, and please stay away from children.
You are correct that in some instances there was no explicit statute that delineated ages and penalties, etc.
But that's not the point. This is about sexual abuse and rape of a child, which, again, a 35+ man manipulating a 14yr old girl falls squarely in this category.
But you defend this practice.
It was widely considered beneficial for all parties.
Care to back that up? If I was a paedophile and "all parties" was me, myself and I, then sure. Can you really tell me, straight faced that Joseph Smith threatening a 14 year old girl with loss of eternal salvation if she did not marry and have sex with him is in any way defensible?
Can you tell me that? As a follower of Christ, you see nothing wrong with a 35+ year old man coercing a 14 year old girl into sex: raping her.
Just say it directly (not via this misleading wording about social norms, circumstance, etc).
Furthermore, a fifteen-year-old girl of that time was more socially and emotionally ready for marriage than a fifteen-year-old girl of our time
Does that matter? She was still WAY TOO YOUNG. Quit changing the subject.
It was culturally acceptable for young (even teenaged) women to marry older men (even in their forties) in the 19th century.
Show me the references which state that it was "culterally acceptable" for 40 year old men in the US to marry 14 year old girls. Show me!
You might disagree with the views of the culture at the time, but you cannot place the faults you perceive in it squarely on the shoulders of Joseph Smith.
I put them squarely on the shoulders of any rapist / child abuser who uses a position of power, including significant age difference and religious coercion to perpetrate these crimes.
There are a number of these guys locked up in prison right now, and I lay blame at them too.
This is discusting behavior, and I can't believe you can rationalize it in any sense.
Any kind of encoding (from WEP to MP3) on the link is going to nullify the HAM angle. I hear this often (get a ham license!) but from non trusted sources who dont even know that you cant encrypt across ham bands.
Where have you seen the FCC OK the use of encoding/encryption for HAM bands if it 802.11b? I think even the frequency multiplexing might be a disqualifier... [ off to scour for info ]
"The youngest age of consent at the time may be argued at 10-13. A more reasonable interpretation would put this at 12-14"
The age for males was closer to 15. There is a huge difference between a 15 year old and a 12 year old getting married, and a 35+ year old and a 14 year old.
The first is very young to be married, the latter criminal sexual assault / statuatory rape.
Does this not phase you? If this were done today that would be quite a prison sentence.
Please dont reply with "things were different then". Sexual abuse has never been acceptable in any society, and the coersive use of "loss of eternal life for you and your family" against these young girls is abhorrent.... you never answered my question; doesn't this bother you at all to rationalize / defend this kind of exploitation / rape?
Slashdot Mirror
The code is there, the actual performance is going to be lackluster at best.
:-)
Mesh networks suffer from scaling problems due to the overhead associated with ad-hoc protocols. All that flexibility and adaptability come at a price: efficiency, latency and throughtput all decrease as the size of the mesh increases (and even more so when you have popular / power law nodes attracting routes)
Voice is notoriously sensitive to delay and to some degree packet loss. Sure, delay effects can be overblown (ATM anyone?) but you get a saturated mesh network trying to route voice and those multi-second round trip times are going to make your cable modem look like a T3.
[You get losses due to interference, transient link problems, mobile nodes, sun spots, whatever, that cause delays at the physical layer (an ethernet frame takes a while to traverse the ether) which then affects all higher layer protocols: UDP packets can't be reassembled because a fragment is lost. TCP starts backing off too agressively. Retransmission timers get triggered adding to inefficiencies, the list goes on]
Wireless and mesh networking in particular are very promising and useful technologies, but they are no where near the utopia that is often presented.
Trivial DoS attacks, scalability problems, and compounded complexity all add up to make it a very volatile environment.
Sure, this stuff will work, but only in very constrained configurations / environments.
Maybe someday further in the future these dreams can be realized when we have robust MIMO software radios and intelligent network stacks that can adapt to such harsh conditions.
Rather, the network needs some form of role-based assertion or qualification of the relationship.
:-)
The problem with this is the classic meta-data problem: how do you get users to enter in a sufficient amount of meaninful information about their peers?
The simple approach (and also the most innaccurate/flawed) is the binary status of "friend / non-friend" which has the drawbacks you mention.
But a much more detailed and expressive syntax would be incredibly cumbersome. For every person in your social network you would need to answer the detailed questionaire: "is this person a friend acquaintance. Is the friendship activity based, personal, business, etc." ad infinitum.
And unless everyone responded with completeness, the validity of any given link expressed between two people could vary greatly.
I'm a big fan of the implicit approach, and the research mentioned above goes a little ways towards implictly identifying and categorizing the nature of links between peers in a social network.
If a system could observe your interactions with others via email, phone, web communities, etc. (and preserve the privacy of such information - but thats another discussion) then the need for explicitly defining this social metadata would be reduced, as many of the aspects of social interactions could be inferred implicitly without bothering the user to enter (partial) information themselves.
There is a lot of progress to be made in this space; hopefully it will happen soon
The problem is more complicated, and you touch on one of the main weaknesses of any system where reputation and feedback in involved.
One aspect of the problem is the granularity by which relationships are defined. In many of the sites there is only one state: "friend or non friend". The real world encompases a number of shades and types, from business acquaintance to personal friend, intimate lover, etc.
Another aspect is the incentive to "game" these systems by increasing your friend count. This inevitably leads people loosening their interpretation such that they increase their visibile friend count. If the number if friends you were linked to was not public, there would be less of this (but you can't do that without breaking some of the functionality of the sites)
People have talked about "winning" at friendster or tribe or orkut - but there is no "winning" in these systems, as there should not be competition.
Last, there is no method for verification of any status between peers. Can you "prove" that so and so is really a friend?
There are others, but these are the main three, and not likely to be solved or addressed any time soon.
From football conferences to food webs: U-M researcher uncovers patterns in complicated networks
SEATTLE---The world is full of complicated networks that scientists would like to better understand---human social systems, for example, or food webs in nature. But discerning patterns of organization in such vast, complex systems is no easy task.
"The structure of those networks can tell you quite a lot about how the systems work, but they're far too big to analyze by just putting dots on a piece of paper and drawing lines to connect them," said Mark Newman, an assistant professor of physics and complex systems at the University of Michigan.
One challenge in making sense of a large network is finding clumps---or communities---of members that have something in common, such as Web pages that are all about the same topic, people that socialize together or animals that eat the same kind of food. Newman and collaborator Michelle Girvan, a postdoctoral fellow at the Santa Fe Institute in Santa Fe, New Mexico, have developed a new method for finding communities that reveals a lot about the structure of large, complex networks. Newman will discuss the method and its applications Feb. 15 at the annual meeting of the American Association for the Advancement of Science in Seattle.
"The way most people have approached the problem is to look for the clumps themselves---to look for things that are joined together strongly," said Newman. "We decided to approach it from the other end," by searching out and then eliminating the links that join clumps together. "When we remove those from the network, what we're left with is the clumps."
The researchers tested their method on several networks for which the structure was already known---college football conferences, for example. In college football, teams in the same conference face off more frequently than teams in different conferences. When inter-conference games do occur, they're more likely to be between teams that are geographically close together than between teams that are far apart. Plugging in information on frequency of games between pairs of teams in the 2000 regular season, Newman and Girvan tested their method to see if it could correctly sort the colleges into conferences. "There were a few cases where it made mistakes, but it got well over 90 percent of them right," said Newman. "It gave us the structure we were expecting, so that was encouraging."
Newman and Girvan---and other researchers who've learned about their work---have gone on to apply the technique to systems where the structure is not as well understood, looking at everything from networks of Spanish language web logs to communities of early jazz musicians to a food web of marine organisms living in Chesapeake Bay.
"Networks and other systems that we study are becoming increasingly large and complicated these days," said Newman. "New methods like this help us to make sense of what we see and to understand better how things work."
###
For more information:
Mark Newman -- http://www-personal.umich.edu/~mejn/
American Association for the Advancement of Science -- http://www.aaas.org/
Santa Fe Institute -- http://www.santafe.edu/
If this were done (and it's definitely a good idea) they would likely have to switch to acoustic fingerprinting.
This would require a lot more resources and complexity, but I doubt the RIAA would give up so easily.
Recall that people were doing the same thing to the napster filters when they were applied. Names of files would have letters swapped around and replaced, all to avoid the strict filtering that was supposed to stem the trade of copyrighted music.
Because if it's true, BitTorrent (or a full-fledged P2P network employing similar concepts) takes care of that.
You have to be careful to draw a distinction between a protocol that supports multi-source downloading and one that enforces multi source downloading.
In bittorrent (and any of the other multi-source DL apps) it is possible to download the entire file from a single peer, by altering the client to only use that one peer for the duration of a download.
The RIAA also has a number of nodes at their disposal, so even a coordinated download among many of them obtaining pieces could collectively obtain the entire file from a peer, without them having the slightest clue what just happened.
Attack resistance of this nature is difficult to implement. This is a war of attrition, and when the current easy methods are subverted, additional methods will be applied (acoustic fingerprinting for example).
I can see it now, next generation P2P networks where only 99% (or whatever) of the file is shared. ... Actually that begs the question, how much of a song do you have to share to cross the line into the illegal
This is actually similar to the way that the Publius censorship resistant publication network works. They split the file into a number of smaller, encrypted blocks.
Any block by itself is completely useless and cannot be considered infringing. A user simply requests the various blocks and when all are obtained, recreates the original file in whole.
Many other peer networks designed for anonymous distribution also use similar methods.
they don't. downloading music is perfectly legal. It is the unauthorized distribution part that they can get you for.
I see a lot of confusion over the way files are identified and whether this will stand up in court or not.
If you think they are using a method as trivial as "they responded to a search for name label_muzak.mp3" you are mistaken. This would definitely not be credible evidence in court (anything could be in the file) and it's not how the RIAA is going about tracking illegal uploads.
The method they are using has been described in some of the articles concerning the subpoenas issued to users of the networks and it works as follows:
1. The RIAA employs modified nodes in the various networks (KaZaa and Morpheous seem to be the big two) to search for known song names or groups.
2. When they find a match, they attempt to download the entire file from the user. This point is important: if they can't prove you actually uploaded a copyrighted file in its entirety, they don't have a case.
3. When the upload is complete they perform an MD5 sum on the content and verify that it matches a database of known copyrighted files. If they didn't do this step, they would have to have someone listen to it to be sure its actually what they think it is.
Given the nature of peer networks, there are a number of common rips (i.e. identical) of songs widely shared among many users. Thus the MD5 sums will match for the same file among many users.
This is all the information they need to bring a suit against your. They have an IP address and time/date associated with the upload, they have a verified MD5 sum for the upload that matches known copyrighted files.
This information was covered in a previous article here: Innocent File-Sharers Could Appear Guilty? and the techniques they use are explicitly designed to withstand the scrutiny of a legal proceeding.
All of the cases of mistaken identity to date (the mac user sent a nasty gram, the grandmother, etc) appear to be mistakes by the ISP correlating a given IP + date into the right account holder, and not a flaw in their methods associated with identifying infringing content traded over the networks.
By "interior" i meant that not only would the aerogel have to contain no air, but a hollow cavity as well, with some way to prevent air from entering it either. Kind of like a solid baloon filled with a vacuum instead of a rubber surface filled with helium for example...
:-)
But that would be one interesting block of blueish haze. it would rest on your ceiling and not your desk
Air. The substance is made by creating links between strands of silicate (glass) under special conditions contained in a liquid solution. When the liquid is removed, all that remains is a very porous structure with incredibly small silicate links surrounding cavities filled with air. (grossly simplified explanation)
If the interior of aerogel were a vacuum, you could potentially create a solid that is lighter than air (although its structural stability and strength would be reduced)
that should be 99% air, and 99.9% air.
you can buy this stuff from MarkeTech for the rock bottom price of $975 a 4x8x0.5" piece.
I'll let someone else figure out how expensive an entire house would be to insulate.
Note that this isn't even the really good stuff (the average density of the commercial stuff is only 99.9% air, while the hi-tech versions used by NASA can be as high as 99.99% air or more)
Secure programming requires additional skill and focus during design, development, testing and configuration. This drives up costs and extends schedule for any project.
Ultimately the market decides winners in the software space (usually), and everyone needs to see security as a feature worth paying more for, in terms of employees designing and building the systems, to QA testers performing thorough audits before deployment, to users comparing choices in the corporate or consumer software space.
The author argues that it will take a digital pearl harbor to affect this change. I doubt it will be as drastic. We are already seeing consumers, users and businesses move towards more secure systems (and adding more diversity - breaking the monoculture)
The pain is only going to increase as attacks grow more and more prevalent, and damage more and more severe. Instead of a single, high profile event, I think we are going to see the current trend continue and accelerate: more and more people spending more money on secure systems, and diversifying their environments.
In the software market consumers and producers are equaly responsible for the state of security - it costs more time and money and skill to build secure systems: are people paying more for the secure alternatives on the market? do people make a thorough effort to address security before purchase? Until the answer is yes, the current methods will remain the market leader. Those that ignore security (to the extent they can) will come to market faster and cheaper than their more secure alternatives.
Those that put a premium on secure systems will spend more for a solution that gives them the stability and features they require, and understand the tradeoff involved in terms of cost, time and skill.
To get a feel for the conference you can listen to the CodeCon 03 audio recordings or review the CodeCon 02 write-ups for day one, day two, and day three.
As a developer who has gone to the previous conferences I can say without hesitation that they are well worth the time and cost.
You didn't mention any specific vulnerabilities that were directed against you in this audit. Were there any legitimate holes that you overlooked or was most of the report fabricated?
Security is a complex task in any environment (from physical threats, unknown vulnerabilities, social engineering, misconfiguration, etc) and the increased size and complexity of networks and systems means this problem will only get worse.
Having what sounds like a single security / administrator handling a financial computer network does sound risky to me personally (but maybe you were just singled out among you coworkers?)
Your comment about telecommuting is a good one though. No longer requiring physical presence to do a contract or work some other position could free you up for additional tasks at other companies bringing your overall salary to a decent level.
Both parties get what they want in the deal; businesses with inexpensive, on demand services; engineers working an efficient schedule for multiple clients (thus good wage despite lower prices on individual jobs)
I'm not sure what kind of reputable engineer you would need to be to pull this off. Liability is going to be the major sticking point on any contract or work-for-hire (until you get a proven track record of completed, functional projects)
are a 802.11b card, a 1W amplifier, and a nice 16dBi vagi antenna:
http://peertech.org/coder/vagi-amp-laptop.jpg
It would seem that if you have a clear line of sight to multiple APs, then you could combine them and have more bandwidth than a single AP-channel connection would provide.
This is called "concurrent multiple association" or simple multiple assocation / AP hopping, and it's something i've been working on off and on for a little while. I talk about it in a bit more detail on the Janus Wireless pages, but I have yet to get anything stable ready for prime time use.
The current problem with multiple association is that you need a very low latency interface to the network radio's at a packet injection / monitor mode level.
I've been able to get this to work in a very crude and inefficient manner with cisco/prism cards used for monitor mode recv of packets, and prism2 based cards for packet injection to implement the multiple association and data packet injection.
There is some hope that the newer cards, specifically the atheros 802.11a/g cards with a reversed binary HAL driver could provide the requisite low level functions to do this efficiently.
But then you are faced with another problem: aggregating the UDP datagrams from multiple sources into a single address space similiar to the way mobile-IP has a dedicated "public" host which acts as your intermediary as your IP changes without breaking existing TCP connections.
I've played with this a bit as well on a dedicated host that has a few IP's, and it works like a NAT that collates UDP datagrams from a wide variety of sources and converts them into the desired TCP/UDP/etc communication from that public endpoint.
In short: for multiple association you need a number of new driver and radio interfaces for:
1) very low latency packet injection and monitor style recv.
2) specialized mobile-IP like drivers on the client that present a virtual interface (ethX) to then host while using injected datagrams over the various multiply-associated wifi links for transport.
3) a dedicated public host with an IP it can allocate to you that accepts all of these incoming UDP packets from various source addresses (all the AP's you are using) and combines them into standard IP traffic from that public IP (ala mobile-IP as well).
None of this is extremely difficult (with the newer cards) but it is a lot of code, and a lot of work, and requires some dedicated host resources.
Now, for the cool part. When you do have all of these pieces in place, it allows you to:
- Simply add cards to your system for more bandwidth. The multiple association throughput is limited only by the number of AP's you can talk to, and the number of cards you have to monitor and inject packets with. It scales nicely barring interference problems.
- Maintain extremely high throughput as you move anywhere within range to open AP's! You could aggregate the upload capacity of 30 AP's to get a 10Mbps link to the net and maintain this constant fat uplink as you drive around the city.
- Enjoy extremely reliable / robust communications. Since you are no longer dependant on a single AP, you dont have to worry about connection dropping, clients messing with your signal, etc. Your aggregate connection is spread over a number of AP's which means problems with individual AP's make only a very small impact on overall connectivity.
This is really the way things are headed, and its only a matter of time before they become useable and widespread.
I think the point was that fixing bugs alone is not sufficient. You need to approach the code base from two angles.
The first being a high level overview / design document that provides a big picture of how the pieces correlate and interact with each other.
The second being bug fixes and other tasks to get familiar with the low level details of the implementation.
The two together make for a great way to familiarize yourself with a project, but code alone with no other documentation is tedious and much less effective.
I've found a few other misconceptions in open source development that have irked me over the years.
1. Using autoconf/automake will make my code portable.
TRUTH: You need to know what system calls are portable, which ones arent, and the nuances in using each on different platforms. The auto* tools will only make detecting and utilizing the correct versions easy. It's up to you to identify and code for them in the first place. (Ditto for compiler flags, shared libraries, linker options, etc)
2. Network programming is easy.
TRUTH: I've seen a lot of projects that implement their own network communication using TCP sockets and sprintf text messages. A number of others transmit little endian integers around. And others still use a blocking style request->response form of communication.
Good network programming is really hard, and unless you take the effort to design and implement something robust from the start, this kind of ad-hoc, inflexible networking will become embedded into the application and require significantly more rework later down the road.
And PLEASE reuse something that might fit before even attempting to write your own layer. The gnutella protocol is a great example of this problem.
3. Threading is as simple as using pthreads and mutexes.
TRUTH: Good threading code is difficult to develop and difficult to debug. It is always preferable to use an event based model where possible, and rely on threads only when you need scalability on SMP, work arounds for blocking system calls (gethostbyname_r), or background tasks that you dont want delaying interaction with a user or network app (there are many other reasons, but these give you the general idea of where threading is appropriate).
Synchronizing access to shared resources between threads is also very tricky. The level of granularity of locking, and the structure of your data structures themselves, will have a significant impact on performance. Too much granularity and you end up with extremely complex locking hierarchies that are difficult to debug, more prone to dead lock. Too little granularity and you get lots of contention for these shared resources.
Finding the sweet spot is tricky, and often requires lots of experience or tuning to get right. The lack of tools to provide visibility to lock contention and latency also make this difficult.
I'm sure there are others, but these are the big ones that come to mind.
There isnt anything specific you need for multipoint, just that the antennas are usually radiating in a much wider path than the highly directional point to point.
For example, many WISP's use 90 degree sector antennas for point to multi-point and have around 9dBi to 12dBi of gain (sometimes as high as 15).
So for these systems you are allowed 4W EIRP max, regardless of antenna gain, and 1W dBm from the radio max, regardless of antenna gain.
So the highest radio output allowed would be a 1W amp on a 6dBi panel antenna.
If you go with a 15dBi sector, you would need to cut the radio output down significantly.
Interesting results!
...
I would be curious to find out how much improved the system is if you did the following (you may need linux / bsd to do it):
1. Use the demo ad-hoc mode designed by Lucent prior to IBSS mode standardization. This has no ACK, and thus will suffer much less when the SIFS and even DIFS is exceeded.
2. Fix the cards at a specific rate. You could start at 1Mbps and work up, see what you max out at. If you have short pigtails going to the amps, going almost directly into the antennas, you should be able to use 5.5, maybe even 11 consistently.
3. The antenna problems sound similiar to things I have encountered on dual port cards with antenna selection gone awry. Can you confirm there is only one port, or if dual that the "master" or "primary" is the one being used?
It could also be the cisco car detecting significant and continued SIFS timeouts and trying antenna diversity as a workaround? Weird
One last thing that may be useful is fragmentation, but I suspect this wont make a lot of difference...
Nice spin, captain.
I think your remaining argument is that regardless of laws of the time, the marriages below a certain age constituted exploitation.
Not exploitation, RAPE. Such a dirty word. A 35+ year old man coercing a 14 year old girl into sex is RAPE. Can we agree on that? If not, good day to you sir, and please stay away from children.
You are correct that in some instances there was no explicit statute that delineated ages and penalties, etc.
But that's not the point. This is about sexual abuse and rape of a child, which, again, a 35+ man manipulating a 14yr old girl falls squarely in this category.
But you defend this practice.
It was widely considered beneficial for all parties.
Care to back that up? If I was a paedophile and "all parties" was me, myself and I, then sure. Can you really tell me, straight faced that Joseph Smith threatening a 14 year old girl with loss of eternal salvation if she did not marry and have sex with him is in any way defensible?
Can you tell me that? As a follower of Christ, you see nothing wrong with a 35+ year old man coercing a 14 year old girl into sex: raping her.
Just say it directly (not via this misleading wording about social norms, circumstance, etc).
Furthermore, a fifteen-year-old girl of that time was more socially and emotionally ready for marriage than a fifteen-year-old girl of our time
Does that matter? She was still WAY TOO YOUNG. Quit changing the subject.
It was culturally acceptable for young (even teenaged) women to marry older men (even in their forties) in the 19th century.
Show me the references which state that it was "culterally acceptable" for 40 year old men in the US to marry 14 year old girls. Show me!
You might disagree with the views of the culture at the time, but you cannot place the faults you perceive in it squarely on the shoulders of Joseph Smith.
I put them squarely on the shoulders of any rapist / child abuser who uses a position of power, including significant age difference and religious coercion to perpetrate these crimes.
There are a number of these guys locked up in prison right now, and I lay blame at them too.
This is discusting behavior, and I can't believe you can rationalize it in any sense.
Any kind of encoding (from WEP to MP3) on the link is going to nullify the HAM angle. I hear this often (get a ham license!) but from non trusted sources who dont even know that you cant encrypt across ham bands.
... [ off to scour for info ]
Where have you seen the FCC OK the use of encoding/encryption for HAM bands if it 802.11b? I think even the frequency multiplexing might be a disqualifier
If this is a pedantic discussion let me rephrase:
... you never answered my question; doesn't this bother you at all to rationalize / defend this kind of exploitation / rape?
"The youngest age of consent at the time may be argued at 10-13. A more reasonable interpretation would put this at 12-14"
The age for males was closer to 15. There is a huge difference between a 15 year old and a 12 year old getting married, and a 35+ year old and a 14 year old.
The first is very young to be married, the latter criminal sexual assault / statuatory rape.
Does this not phase you? If this were done today that would be quite a prison sentence.
Please dont reply with "things were different then". Sexual abuse has never been acceptable in any society, and the coersive use of "loss of eternal life for you and your family" against these young girls is abhorrent.