I would overlook that for the present considering that the US still practices capital punishment and Reiser could very well face death if convicted of 1st degree murder.
Hans Reiser has already been convicted of 1st degree murder. He won't be facing the death penalty because in California they only give that out for 1st degree murder "with special circumstances" such as multiple murders or laying in wait.
The reality was, that the kids just wanted to pretend they were doing OOP. They still used straight C, they just created structs and organized functions in files as if they were classes. It was actually rather clever and made it easier to maintain.
I was under the impression that this is how all quality contemporary software development in the C language was conducted. Maybe the kids weren't as clever as they were up to date.
Except the same law also made "receipt or expectation of receipt" of other copyrighted materials equivalent to "material gain." In other words, they criminalized trading.
Console games are "a computer program embodied in or used in conjunction with a limited purpose computer that is designed for playing video games and may be designed for other purposes" and have a special exception in 17 USC 109.
I have worked with almost all of them. Some of them for extended periods of time with developers I sat next to in the office who committed to a central repository but also with distributed teams (distributed teams usually push changes frequently to a shared "central" repo, btw.) That includes Codeville, Git, Monotone, Darcs, and Mercurial. Really, they are all essentially the same and the differences are mostly in implementation and flexibility, especially WRT merge algorithms.
A few months ago I switched to git. Git seems like the winner - it's fast, modular, and many people are hacking on it and have written many cool tools (most of which are "built-in" git "commands.") However, its Windows support lags behind the other front-runner Mercurial. Darcs is mostly used by Haskell hackers, Monotone never seemed to really take off, and Codeville has died on the vine.
The good thing is you can switch because there are migration tools for almost every one and the histories tend to be isomorphic.
Seems to me that most of the people promoting DVCS have used them and have seen the light. Once you use a DVCS on a project you don't want to go back to the bad old way of doing things.
Most of the people knocking DVCS or saying they can't see the benefits haven't actually used them on any projects. They have built up a framework in their minds of How Things Should Work, but unfortunately that model was defined by the limitations of their tools.
Even when I code by myself on my own projects I greatly prefer the flexibility of git over Subversion. Why settle for "perfectly adequate" when you can have your choice of several tools that are much better?
One of the best things is you can checkin changes, roll back to previous versions, branch, merge, etc... all on your local repository while you're on the plane or beach where there is no network access. With Subversion you can't do that. So if you have this crazy idea but don't have network access, you either have to make changes to your current work area and risk screwing stuff up and possibly losing any changes you already have in that work area (which may not be as crazy and speculative) or you might just forgo trying out your crazy ideas because you can't take a branch or commit your changes. The same goes for when you do have network access. The DVCS systems are much faster at branching and the merging is much better IME. Most Subversion/CVS users avoid making many branches because keeping them in sync is a PITA.
Most CVCS users don't realize how incredibly useful taking branches and merging them at the drop of a hat is because they have studiously avoided it except where absolutely necessary.
I understand why location aware choking is helpful to ISPs - it reduces border traffic and their costs. I can also understand how location aware peer selection on the tracker can help torrents that have too many peers for every peer to be connected to every other peer. So does this client plugin or any other client based location aware selection/choking make any real difference for users? The classic tit-for-tat choking algorithm means you unchoke the peers giving you the fastest download. It doesn't matter if they are close or near, have high latency or not - fast is fast and slow is slow. In the end, throughput is the only thing that matters. Maybe location can be a useful weight for optimistic unchoke, so you can potentially find fast peers sooner, but that seems like a pretty small optimization.
Unfortunately, the paper for Ono isn't available yet.
The root of the problem is shared state, operations on shared state need to have ACI properties - atomic, consistent, and independent. Some languages / environments, like Erlang and QNX, solve this problem by basically getting rid of shared state and making all threads communicate with each other over socket-like abstractions. With common programming languages the solution is mutually exclusive locks. You lock up the memory you're working on then unlock it when you're done.
Locks have problems. In order to get good concurrency, you need fine grained locking. Once you have multiple resources protected with multiple locks you run into gotchas like deadlocks and race conditions. There are also issues with exceptions and programmer mistakes causing locks to remain locked or unlocked. All of this can make it very difficult to reason about what is happening in your program and you can end up with bugs that are very difficult to reproduce and/or fix. Locking is also pessimistic - you pay for the cost of locking even if nobody else is looking at the same pieces of memory while you are. Finally, you can't necessarily compose two operations that use their own locks.
A relatively new approach is (Software) Transactional Memory. This is an optimistic method that doesn't use locks. Instead its more like an in-memory database transaction that provides atomic, independent, and consistent access to a set of shared variables. Shared variables have versions associated with them. When you start a transaction the runtime records the versions of the variables. Then after reading and/or writing all the variables in the transaction the runtime compares the current versions with the originally recorded versions. If they are the same the transaction commits and you continue, otherwise the runtime "rolls back" the changes and retries (or doesn't retry, you get control over that if you want.) The cost for uninterrupted reads and writes is very low, you only pay a higher recovery cost when there is an actual conflict.
There are STM libraries available for many popular languages (C#, C++, Java, Ruby) but the most mature and elegant support seems to be in Haskell. Since Haskell is a pure functional language, all side-effects are encapsulated in monads. Because of this encapsulation enforced by the language, it's impossible to actually read or write any transactional variables outside of a transaction. Reading or writing a transactional variable "infects" that function and every calling function until the data is safely brought out of shared memory locations by a transaction. The rest of your code is already thread safe because it doesn't have shared state. The compiler keeps you safe and type checks everything.
There are a bunch of papers you can check out as a starting point. I think this is definitely the future of multithreaded programming.
uh, most NeXT computers could only hold 32 megs of RAM, which was considered quite a lot, and they ran what is essentially full blown OSX just fine, thanks. Most had only 8-16 megs of RAM. That's Cocoa with 32 bit color Display PostScript and fully double buffered windows and everything on a 1120×832 screen.
on one hand they want to rubbish scientific thinking and deny evolution on the other they want bluray discs, microwaves and nuclear tipped bombs. Get real.
Don't forget that when their children get sick, they take them to a church - a Church of Science, a.k.a. a hospital.
Like a lot of people have commented on this thread, it's past time for you to learn a functional language. I'm not sure if it is true, but new CS students at MIT used to have to learn Scheme as their first language. Learning a functional language will transform your programming ability.
I recommend the book The Little Schemer This book is like no other programming book you have ever used. It is a socratic dialog between you and the interpreter. Questions on the left, answers on the right. It is meant to be used with an interpreter.
Once you make it through this book you'll be a much, much better programmer. You'll also have an easy time learning languages like Haskell, which is used quite a bit in academia and is useful for real world software.
So buy a copy of the Little Schemer and download an interpreter, Dr. Scheme is pretty good, and get cracking.
A lot of people are saying "Why isn't Google in the dock, I can search for infringing torrents!?" Well in the USA, Google and other search engines are protected by the DMCA. Yes, not all of the DMCA is bad, in fact, pretty much only the copy protection anti-circumvention stuff is bad. The rest is pretty good, it indemnifies ISPs when their caches or search indices contain infringing material. All they have to do comply with the takedown protocol.
See, in the US, if you're operating an index like Google or Napster that works on an automated basis or is controlled by your users, you don't have to worry about infringing material, until you have actual knowledge of it. Once you have actual knowledge of infringing material you have to do something about it. Thats the difference between Google and Pirate Bay (besides the fact that TPB is not in the USA.) Once Google has actual knowledge of infringing material they take it down and they are OK.
Furthermore, Google's service just finds torrents. TPBs helps you find torrents, but they also host the torrents. After you've download the torrent from TPB, TPB's tracker helps you connect to the other peers for exchanging the requested infringing material. Combined with the actual knowledge of infringing torrents on their site, that's a lot closer to contributory infringement than anything that Google does.
Back to your regularly scheduled TPB Swedish Legal Follies.
It isn't necessary to accept incoming connections to "share." You can do that just fine with only outgoing connections to peers. The tracker can't "throttle you to hell and back" as it plays no part in the choking done by peers. The tracker merely introduces peers to each other.
Also, "ratios" enforced by trackers is only done by pirate sites. The purpose being to ensure there are seeds for infringing torrents because nobody wants to be left "holding the bag." Legitimate torrents have dedicated seeds, so there is no danger of the torrent becoming unseeded if downloaders aren't forced to stick around long after they are done downloading.
BitTorrent was created specifically because of the problems with FTP: the number of simultaneous downloaders with FTP is limited by the publishers network connection. With BitTorrent you can have about three orders of magnitude more simultaneous downloaders for the same amount of bandwidth, when you include the tracker traffic. That is revolutionary.
BitTorrent works just fine behind a typical "firewall." It is not necessary to accept incoming connections, especially with a well seeded legitimate torrent. If you can't download with BitTorrent at all then you have a problem with your firewalls policy not the firewall per se.
It's not a horrible method of distribution. Its an excellent method of distribution, especially for free software. Thats why it is being used for such distribution.
Sorry, but you're wrong. Under normal circumstances, you can't change your ringtone unless you pay for a ringtone from Apple. There is nothing stopping Apple from putting a button in the iPhone software that says "make this mp3/wav/aac my ring tone" but it isn't there. The phone obviously can play these formats, there is nothing technically or legally stopping them from doing this. Can you really come up with any legal reason at all why Apple can't have such a button so I can use a recording of my kids voice as a ringtone?
Even if the music that Apple sells in the ITMS isn't licensed for ringtones, they can make the feature not work for those files.
Face it, they just want you to give them more money to change the ring tone on the phone.
They can't cache it either, because so many uses are copyright violations and the protocol is not designed to be friendly to transparent caches. You could make up a cache, but you'd basically have to do a LOT of work with an IDS and a custom cache for a cache which will require many MANY terabytes of disk and that will get you sued if you deploy it.
In the USA at least, ISPs running automatic caches on behalf of their users are protected from secondary infringement liability by the DMCA.
BitTorrent implemented caching extensions and there was at least one company producing caches for BT and other p2p protocols but it didn't seem to go anywhere.
Slashdot Mirror
Hans Reiser has already been convicted of 1st degree murder. He won't be facing the death penalty because in California they only give that out for 1st degree murder "with special circumstances" such as multiple murders or laying in wait.
I was under the impression that this is how all quality contemporary software development in the C language was conducted. Maybe the kids weren't as clever as they were up to date.
Except the same law also made "receipt or expectation of receipt" of other copyrighted materials equivalent to "material gain." In other words, they criminalized trading.
Console games are "a computer program embodied in or used in conjunction with a limited purpose computer that is designed for playing video games and may be designed for other purposes" and have a special exception in 17 USC 109.
I have worked with almost all of them. Some of them for extended periods of time with developers I sat next to in the office who committed to a central repository but also with distributed teams (distributed teams usually push changes frequently to a shared "central" repo, btw.) That includes Codeville, Git, Monotone, Darcs, and Mercurial. Really, they are all essentially the same and the differences are mostly in implementation and flexibility, especially WRT merge algorithms.
A few months ago I switched to git. Git seems like the winner - it's fast, modular, and many people are hacking on it and have written many cool tools (most of which are "built-in" git "commands.") However, its Windows support lags behind the other front-runner Mercurial. Darcs is mostly used by Haskell hackers, Monotone never seemed to really take off, and Codeville has died on the vine.
The good thing is you can switch because there are migration tools for almost every one and the histories tend to be isomorphic.
Seems to me that most of the people promoting DVCS have used them and have seen the light. Once you use a DVCS on a project you don't want to go back to the bad old way of doing things.
Most of the people knocking DVCS or saying they can't see the benefits haven't actually used them on any projects. They have built up a framework in their minds of How Things Should Work, but unfortunately that model was defined by the limitations of their tools.
Even when I code by myself on my own projects I greatly prefer the flexibility of git over Subversion. Why settle for "perfectly adequate" when you can have your choice of several tools that are much better?
One of the best things is you can checkin changes, roll back to previous versions, branch, merge, etc... all on your local repository while you're on the plane or beach where there is no network access. With Subversion you can't do that. So if you have this crazy idea but don't have network access, you either have to make changes to your current work area and risk screwing stuff up and possibly losing any changes you already have in that work area (which may not be as crazy and speculative) or you might just forgo trying out your crazy ideas because you can't take a branch or commit your changes. The same goes for when you do have network access. The DVCS systems are much faster at branching and the merging is much better IME. Most Subversion/CVS users avoid making many branches because keeping them in sync is a PITA.
Most CVCS users don't realize how incredibly useful taking branches and merging them at the drop of a hat is because they have studiously avoided it except where absolutely necessary.
I understand why location aware choking is helpful to ISPs - it reduces border traffic and their costs. I can also understand how location aware peer selection on the tracker can help torrents that have too many peers for every peer to be connected to every other peer. So does this client plugin or any other client based location aware selection/choking make any real difference for users? The classic tit-for-tat choking algorithm means you unchoke the peers giving you the fastest download. It doesn't matter if they are close or near, have high latency or not - fast is fast and slow is slow. In the end, throughput is the only thing that matters. Maybe location can be a useful weight for optimistic unchoke, so you can potentially find fast peers sooner, but that seems like a pretty small optimization.
Unfortunately, the paper for Ono isn't available yet.
The root of the problem is shared state, operations on shared state need to have ACI properties - atomic, consistent, and independent. Some languages / environments, like Erlang and QNX, solve this problem by basically getting rid of shared state and making all threads communicate with each other over socket-like abstractions. With common programming languages the solution is mutually exclusive locks. You lock up the memory you're working on then unlock it when you're done.
Locks have problems. In order to get good concurrency, you need fine grained locking. Once you have multiple resources protected with multiple locks you run into gotchas like deadlocks and race conditions. There are also issues with exceptions and programmer mistakes causing locks to remain locked or unlocked. All of this can make it very difficult to reason about what is happening in your program and you can end up with bugs that are very difficult to reproduce and/or fix. Locking is also pessimistic - you pay for the cost of locking even if nobody else is looking at the same pieces of memory while you are. Finally, you can't necessarily compose two operations that use their own locks.
A relatively new approach is (Software) Transactional Memory. This is an optimistic method that doesn't use locks. Instead its more like an in-memory database transaction that provides atomic, independent, and consistent access to a set of shared variables. Shared variables have versions associated with them. When you start a transaction the runtime records the versions of the variables. Then after reading and/or writing all the variables in the transaction the runtime compares the current versions with the originally recorded versions. If they are the same the transaction commits and you continue, otherwise the runtime "rolls back" the changes and retries (or doesn't retry, you get control over that if you want.) The cost for uninterrupted reads and writes is very low, you only pay a higher recovery cost when there is an actual conflict.
There are STM libraries available for many popular languages (C#, C++, Java, Ruby) but the most mature and elegant support seems to be in Haskell. Since Haskell is a pure functional language, all side-effects are encapsulated in monads. Because of this encapsulation enforced by the language, it's impossible to actually read or write any transactional variables outside of a transaction. Reading or writing a transactional variable "infects" that function and every calling function until the data is safely brought out of shared memory locations by a transaction. The rest of your code is already thread safe because it doesn't have shared state. The compiler keeps you safe and type checks everything.
There are a bunch of papers you can check out as a starting point. I think this is definitely the future of multithreaded programming.
Sorry, but you're wrong. It's not art, it's science. The stopwatch doesn't lie.
The primary reason is to prevent an individual from acquiring multiple IDs.
uh, most NeXT computers could only hold 32 megs of RAM, which was considered quite a lot, and they ran what is essentially full blown OSX just fine, thanks. Most had only 8-16 megs of RAM. That's Cocoa with 32 bit color Display PostScript and fully double buffered windows and everything on a 1120×832 screen.
Kids these days...
Don't forget that when their children get sick, they take them to a church - a Church of Science, a.k.a. a hospital.
Like a lot of people have commented on this thread, it's past time for you to learn a functional language. I'm not sure if it is true, but new CS students at MIT used to have to learn Scheme as their first language. Learning a functional language will transform your programming ability.
I recommend the book The Little Schemer This book is like no other programming book you have ever used. It is a socratic dialog between you and the interpreter. Questions on the left, answers on the right. It is meant to be used with an interpreter.
Once you make it through this book you'll be a much, much better programmer. You'll also have an easy time learning languages like Haskell, which is used quite a bit in academia and is useful for real world software.
So buy a copy of the Little Schemer and download an interpreter, Dr. Scheme is pretty good, and get cracking.
just append ".nyud.net:8090" to the domain name
A lot of people are saying "Why isn't Google in the dock, I can search for infringing torrents!?" Well in the USA, Google and other search engines are protected by the DMCA. Yes, not all of the DMCA is bad, in fact, pretty much only the copy protection anti-circumvention stuff is bad. The rest is pretty good, it indemnifies ISPs when their caches or search indices contain infringing material. All they have to do comply with the takedown protocol.
See, in the US, if you're operating an index like Google or Napster that works on an automated basis or is controlled by your users, you don't have to worry about infringing material, until you have actual knowledge of it. Once you have actual knowledge of infringing material you have to do something about it. Thats the difference between Google and Pirate Bay (besides the fact that TPB is not in the USA.) Once Google has actual knowledge of infringing material they take it down and they are OK.
Furthermore, Google's service just finds torrents. TPBs helps you find torrents, but they also host the torrents. After you've download the torrent from TPB, TPB's tracker helps you connect to the other peers for exchanging the requested infringing material. Combined with the actual knowledge of infringing torrents on their site, that's a lot closer to contributory infringement than anything that Google does.
Back to your regularly scheduled TPB Swedish Legal Follies.
I call bullshit, Tony Hoyle has no idea what he is talking about or he is just trolling.
Do you think FTP can saturate your 10 mbit link when its downloading from my FTP server sitting on a 384 kbit up DSL line?
Huh? Do you have any idea how BitTorrent works?
It isn't necessary to accept incoming connections to "share." You can do that just fine with only outgoing connections to peers. The tracker can't "throttle you to hell and back" as it plays no part in the choking done by peers. The tracker merely introduces peers to each other.
Also, "ratios" enforced by trackers is only done by pirate sites. The purpose being to ensure there are seeds for infringing torrents because nobody wants to be left "holding the bag." Legitimate torrents have dedicated seeds, so there is no danger of the torrent becoming unseeded if downloaders aren't forced to stick around long after they are done downloading.
BitTorrent was created specifically because of the problems with FTP: the number of simultaneous downloaders with FTP is limited by the publishers network connection. With BitTorrent you can have about three orders of magnitude more simultaneous downloaders for the same amount of bandwidth, when you include the tracker traffic. That is revolutionary.
BitTorrent works just fine behind a typical "firewall." It is not necessary to accept incoming connections, especially with a well seeded legitimate torrent. If you can't download with BitTorrent at all then you have a problem with your firewalls policy not the firewall per se.
It's not a horrible method of distribution. Its an excellent method of distribution, especially for free software. Thats why it is being used for such distribution.
Maybe Apple thought FLAC was infringing on patents and didn't want to risk being the only user of it with deep pockets.
Sorry, but you're wrong. Under normal circumstances, you can't change your ringtone unless you pay for a ringtone from Apple. There is nothing stopping Apple from putting a button in the iPhone software that says "make this mp3/wav/aac my ring tone" but it isn't there. The phone obviously can play these formats, there is nothing technically or legally stopping them from doing this. Can you really come up with any legal reason at all why Apple can't have such a button so I can use a recording of my kids voice as a ringtone?
Even if the music that Apple sells in the ITMS isn't licensed for ringtones, they can make the feature not work for those files.
Face it, they just want you to give them more money to change the ring tone on the phone.
So much for "write once, run everywhere."
In the USA at least, ISPs running automatic caches on behalf of their users are protected from secondary infringement liability by the DMCA.
BitTorrent implemented caching extensions and there was at least one company producing caches for BT and other p2p protocols but it didn't seem to go anywhere.