I was in a similar situation when I got out of college. I had a lot of theoretical training in college and wanted to get my hands bloody. I was coding at work, but it was odd embedded stuff and I wanted some different experiences to "cleanse the palate". I ended up doing work for two projects: Vim and Mozilla. I chose these projects for two reasons: I liked what they did, and they had lots of room for additional coders.
Vim was sort of a dive-right-in situation. Bram maintains a vast TODO list that ships with every version of the product. I spent a while reading it, picked out a couple things that seemed like they ought to be easy, and got to work. I joined vim-dev and mailed out patches. I didn't do a ton for the app, but I got a few things in.
Mozilla was a different beast in many ways. It was a much more structured environment due to the review process and the presence of Netscape. Also, it was in C++ (which I barely even knew, thanks to some shoddy university training), and not just any C++, but XPCOM. At first I was intimidated by the size of the code and not knowing where to start, so I didn't even touch the code. I spent several months just sitting in #mozillazine and triaging bugs. I dup'd, I closed, I changed to NEW, all that good stuff. Through this, I achieved two important things: I got a much better sense of how the product worked, and I met some of the players involved through IRC contact. By this time I was sitting on #mozilla as well, but I never said a word.
Eventually, I downloaded the code and bought a copy of Don Box's "Understanding COM" for background reading (that book is amazing). From all the time spent triaging, I knew some of the areas where bugs were piling up and nobody was looking at them, so I started there. I submitted a few small patches, had them reviewed, had people check them in for me. The reviews were harsh sometimes, but I was learning a lot. Eventually I moved around a bit and took on larger fixes.
I did this for a year or so before I got too busy with work and dropped out of sight. To this day it was some of the most fun I've had as a coder. For all its flaws (in those days, Firefox was still "m/b", and Netscape ran the show), it was a great project, and some of the people who worked on it were the best programmers I've ever worked with.
So, my advice: start slow, start small. Figure out who you can ask for advice about something. Look for other (non-coding) ways you can help out that will help you get familiar with what's going on. It's worth it.
(Public service announcement: Object pooling is now a serious performance loss for all but the most heavyweight of objects, and even then it is tricky to get right without introducing concurrency bottlenecks.)
vs
If the allocator were truly implemented as shown in Listing 1, the shared heapStart field would quickly become a significant concurrency bottleneck, as every allocation would involve acquiring the lock that guards this field. To avoid this problem, most JVMs use thread-local allocation blocks, where each thread allocates a larger chunk of memory from the heap and services small allocation requests sequentially out of that thread-local block.
So wait, JVMs are okay because they can eliminate concurrency by using thread-local pools, but other pool allocators can't?
I reserve a certain amount of cynicism towards "The Government is Out to Get Me" and related mindsets, but FISA is one thing that scares the living fuck out of me.
The idea that a similar court (proceedings so secret that the accused doesn't get to know the charges; has denied only *one* wiretap request in its history) is needed to deal with computer crime is nuts.
A couple of links:
http://www.ainfos.ca/98/aug/ainfos00031.html
http://mediafilter.org/caq/Caq53.court.html
See bug 19258 -- support for a user pref to override blinking text.
Both that and the fixed blink support itself should be in 0.9.6, hopefully.
Please don't link to bugzilla from the front page!
on
Chief Lizard Wrangler axed
·
· Score: 5, Insightful
CmdrTaco et al,
Please don't link directly to a bugzilla bug ever again, at least not from the front page. The system is under constant use by bug reporters, triagers, and developers, who are all working hard to make the 0.9.4 milestone happen as fast as possible./.'ing the server only serves to disrupt development. In the future, please think about the people who are relying on a particular server before targetting it for destruction. Thanks.
I agree, Michael is making things unnecessarily confusing -- forking is still bad, and still a danger.
But everyone seems to be forgetting about a very simple observation from The Cathedral and the Bazaar: even though forking is possible, it's highly discouraged; it's one of the stronger taboos in the open source community.
The evidence that this taboo is still in effect is plentiful. So the chance of code forking should not be seen as an additional danger of OSS, since it only happens when the open source development model is already breaking down. In other words, it's a symptom, rather than a problem.
Taco, I would have expected you to pick up on this by now.
Regardless of whether or not people use Mozilla as a browser, it's an excellent idea for distros to ship it. The reason? Mozilla is an application development framework. I may prefer Lynx to Mozilla-the-browser (or any other GUI-based browser...), but that doesn't mean that I'll never want to run Komodo or any of the interesting bits being developed on top of Mozilla at mozdev. Shipping a copy of Mozilla with a distro allows the end users to take advantage of mozilla-based XP apps, regardless of whether they ever *touch* Seamonkey.
"An article from MIT's Technology Review has the details on a new kind of fiber optic cabling that could provide part of the backbone bandwidth increase everyone is looking for....I wonder if it'll be cheap enough for home use."
For the last time, THE BACKBONE IS NOT IN YOUR BASEMENT.
Technologies that are being developed for the core are not being designed for your house. They never have been and, unless the semi-hierarchical design of the core dissolves into fractal jelly (which would be pretty interesting, actually, but won't happen as long as it's privately owned), they never will be, because the scalability problem in last-mile deployment is an absolute bitch.
That said, QWest and others are swimming in backbone bandwidth -- they can't sell it all!
Something else that users/testers can do that's quicker and easier than fixing or even reporting bugs is to vote for them. Bugzilla users get a fixed number of votes (eg 10 for the browser) to allocate as they wish among open bugs. This helps gives developers an additional priority metric -- the will of the users!
Speaking of which... I didn't check out the Star Wars Lego project the first time around, and it appears that the URL has changed (poor guy probably got kicked off his previous hosting after the beating/. gave their servers...). I tracked it down by backing up a directory.. the english version appears to be now available at
http://www5b.biglobe.ne.jp/~mbsf/swo rde.htm.
(Incidentally I voted Simons, Lessig, Auerbach, in that order. The others I left blank. If I could do it over, I think I would add Chapin fourth, ahead of Dr. Tiller.)
I think you're giving Lyman Chapin a raw deal. He "works" for Verizon in the sense that he's a longtime employee (Chief Scientist) at BBN, which has been bought out so frequently in the last five years that it's no longer even news.
I also think Chapin is more of a technologist than you give him credit for. I was at the ICANN forum at HLS Monday night, and Chapin's answers sounded the most like Karl Auerbach's of any of the candidates. The difference is that Chapin is less radical -- he sees more shades of grey in the issues. Which is what has always bothered me a little about Auerbach: he is so combative that I am afraid he will be entirely ineffective as a board member. Since the at-large representation is so tiny compared the size of the board, would-be revolutionaries must be careful, subtle, and cunning.
I have recently become aware of legal threats being made against Michael Rothwell by the law firm of Kenyon and Kenyon, representing Digital Convergence, makers of the:CueCat bar code scanner available at Radio Shack outlets. As Mr. Rothwell explains on his web page,
Kenyon & Kenyon has accused him of intellectual property infringement over his distribution of software for the Linux operating system that would interpret the output of a:CueCat scanner in the same manner as the currently (and freely) available software for Windows. This attitude is both misguided, in that the net effect of Mr. Rothwell's work would be increased usage of:CueCat scanners by people who would otherwise by unable to use it, as well as dangerous, in that it stands against the principles of reverse engineering which are a cornerstone of scientific advancement.
I am greatly distressed by the actions taken by Kenyon and Kenyon/Digital Convergence. I would appreciate a statement from Digital Convergence clarifying and explaining your position on the issue.
I am a little confused why a single article like this (even one by the esteemed Mr. McCullagh) gets posted. There's been plenty of other coverage of this in other media, much of it just as pro-DeCSS:
If the MPAA's current attempts to stop 2600 from linking to DeCSS fall through, they can bust them for patent infringement!
Napster using DMCA to evade Metallica
on
An MP3 Update
·
· Score: 5
This article at Salon summarizing this message from Napster -- Napster is using DMCA as a defense! Users who were fingered by Metallica are allowed under DMCA (assuming, that is, you count napster as an ISP) to submit a counternotification is they think they were incorrectly identified as copyright infringers. Unless Metallica pursues legal action against those individuals within ten days of the receipt of the counternotification, Napster must reinstate them!
Yeah, I'm sort of glad they're pulling these absurd antics -- the alternative is just too grisly. Napster as a technology is legal -- it has to be, or else we are all in big, big trouble. But if Napster successfully defends itself against the current crop of lawsuits, the reaction will not be "I guess that Napster is ok after all", but rather "We are allowing legal piracy! Better fix it quick!" As RMS concisely put it in his Q&A last week:
If they do not win using present-day law, we can expect to see the record companies purchase new laws they can use to suppress these programs in the future--and trot out famous musicians like Metallica (only famous musicians get much of their income from copyright) who will say that copying music is like killing their baby.
Letting them mess with users is rough stuff, but more in line with the traditional way that piracy has been handled. That in this case it may be very difficult to prove (i still haven't seen an answer to why you can't just run out and buy certain CDs after the fact, though i may have missed it) is another matter.
I would be running this so fast if it supported the 5300. Unfortunately, the hardware is screwy enough that I'm locked out of Linux support. Last I checked, MkLinux supported the 5300 but did not support the SCSI port or the PCMCIA slot -- which means no network connectivity and no CD-ROM drive.
Wait a minute here, so if this is true, and even playing a DVD is illegal, then that means the MPAA has a MONOPOLY on DVD playback.
Note what Kaplan says:
The interest served by prohibiting means that facilitate such piracy---the protection of the monopoly granted to copyright owners by the Copyright Act---is of constitutional dimension.
He is clearly aware that he is protecting a monopoly. Unfortunately, he does not realize that he is proecting the wrong one. He thinks he is protecting the monopoly on distribution of content, which he's not -- as piracy still exists. What he's protecting (unintentionally, I assume) is the monopoly on *who* gets to view that content and *how*.
Finally, and most important, the legislative history makes it abundantly clear that Section 1201(f) permits reverse engineering of copyrighted computer programs only and does not authorize circumvention of technological systems that control access to other copyrighted works, such as movies.21 In consequence, the reverse engineering exception does not apply.
It seems that the law is ambiguous with the definition of "access" -- there is "access" to a DVD in that I can make a bitwise copy and now you have one, and there is "access" in that you need something to be able to understand it. Obv. DeCSS enables #2 but not #1 -- yet there's no distinction (or indication of awareness of such a distinction) in the law. This muddles the debate over what exactly the "piracy" argument is.
What I (and a good number of people, I'd guess) want to know is, why didn't the counsel for the defense make these sorts of piracy arguments? I am somewhat confused as to why the plaintiffs got away with the classification of CSS as "a technological system that controls access to other copyrighted works" -- although here you get into the ambiguity I just described. Kaplan ends up ruling that CSS protects content -- but it really only ends up protecting playback, since anyone with some equipment can copy but only people with "legit" DVD technology can play it back. As far as I can tell from the various hearings/rulings that have been posted, this distinction is never made clear by the defense! There's a lot of exemptions they try to invoke, but Kaplan's reasons for rejecting them do not seem out of line. In fact, he appears to do a pretty decent job of assessing what has been presented to him. Did the defense throw it all away by ignoring its best argument? The recent LinuxWorld interview with Jon J. had the same complaint; i'm just echoing it here.
Presto: the protection is compromised, and the DVD coalition is vulnerable to their (erstwhile) partner's legal fury. The content owners could sue the DVD makers right into their pockets for failure to come through on the protection of their content if the DVD coalition doesn't nip this in the bud..
Wasn't there some suit where a bank was found liable for negligance after encrypting some sensitive transaction with only 56-bit encryption? I thought I read something like that. It seems like a reasonable precendent -- sooner or later, the content owners could figure out that it's going to be impossible to keep the code under wraps (you can buy it on a t-shirt at copyleft), and file a class action lawsuit for negligance on the part of the people who implemented the "hack-proof" DVD encryption system.
I don't know if that sort of thing would be a "win" for the world at large, though.
>Freedom isn't for anonymous internet, it's for pseudonymous use
Looks like I should have read the zks page a bit more carefully:) With that knowledge my original question would have been much different (if it had even existed). pseudonymous use rather than anonymous pretty much negates the effect I was implying. Thanks for the correction.
Some of you may consider this flamebait, but I'm serious.
Things like ZKS make me wonder about what we are striving for in terms of privacy. There is the "real" world and the digital world -- is one meant to be an analogue of the other? Obviously, we want privacy because we don't want the digital world to be worse than the real world in certain ways. For instance, if we didn't encrypt credit card data during transactions, the digital world would be broken compared to the real when it comes to purchasing. Similarly, I want to be able to secure documents that I send to someone so that they are at least as good as taking certain "security" measures in the real world (registered mail, envelopes that aren't transparent, etc).
There seems to be a distinction between the desire for online security (which seeks to emulate the security we can find in the real world) and the desire for online privacy (which seeks to surpass the real). There is no real-world equivalent to what ZKS proposes. If I walk down the street, people may not recognize me (unless they know me), but I clearly have an identity -- I can be distinguished from someone else on the street by a third-party observer, even though the observer may not be able to identify either of us. ZKS would allow me to walk down the street and appear identical to everyone else -- not just nameless, but faceless.
Obviously, a lack of privacy dehumanizes; but couldn't an overabundance dehumanize as well? I'm interested in where exactly we're going with all this.
I was in a similar situation when I got out of college. I had a lot of theoretical training in college and wanted to get my hands bloody. I was coding at work, but it was odd embedded stuff and I wanted some different experiences to "cleanse the palate". I ended up doing work for two projects: Vim and Mozilla. I chose these projects for two reasons: I liked what they did, and they had lots of room for additional coders.
Vim was sort of a dive-right-in situation. Bram maintains a vast TODO list that ships with every version of the product. I spent a while reading it, picked out a couple things that seemed like they ought to be easy, and got to work. I joined vim-dev and mailed out patches. I didn't do a ton for the app, but I got a few things in.
Mozilla was a different beast in many ways. It was a much more structured environment due to the review process and the presence of Netscape. Also, it was in C++ (which I barely even knew, thanks to some shoddy university training), and not just any C++, but XPCOM. At first I was intimidated by the size of the code and not knowing where to start, so I didn't even touch the code. I spent several months just sitting in #mozillazine and triaging bugs. I dup'd, I closed, I changed to NEW, all that good stuff. Through this, I achieved two important things: I got a much better sense of how the product worked, and I met some of the players involved through IRC contact. By this time I was sitting on #mozilla as well, but I never said a word.
Eventually, I downloaded the code and bought a copy of Don Box's "Understanding COM" for background reading (that book is amazing). From all the time spent triaging, I knew some of the areas where bugs were piling up and nobody was looking at them, so I started there. I submitted a few small patches, had them reviewed, had people check them in for me. The reviews were harsh sometimes, but I was learning a lot. Eventually I moved around a bit and took on larger fixes.
I did this for a year or so before I got too busy with work and dropped out of sight. To this day it was some of the most fun I've had as a coder. For all its flaws (in those days, Firefox was still "m/b", and Netscape ran the show), it was a great project, and some of the people who worked on it were the best programmers I've ever worked with.
So, my advice: start slow, start small. Figure out who you can ask for advice about something. Look for other (non-coding) ways you can help out that will help you get familiar with what's going on. It's worth it.
FWIW, the name is an acronym: SLACK - Sysadmins' Lazy Auto-Configuration Kit
sundell.net rate-limits http so the server should be ok. Hopefully. Game on, I suppose.
(This isn't alan, just another s.n user.)
I reserve a certain amount of cynicism towards "The Government is Out to Get Me" and related mindsets, but FISA is one thing that scares the living fuck out of me.
The idea that a similar court (proceedings so secret that the accused doesn't get to know the charges; has denied only *one* wiretap request in its history) is needed to deal with computer crime is nuts.
A couple of links:
http://www.ainfos.ca/98/aug/ainfos00031.html
http://mediafilter.org/caq/Caq53.court.html
See bug 19258 -- support for a user pref to override blinking text.
Both that and the fixed blink support itself should be in 0.9.6, hopefully.
Please don't link directly to a bugzilla bug ever again, at least not from the front page. The system is under constant use by bug reporters, triagers, and developers, who are all working hard to make the 0.9.4 milestone happen as fast as possible.
But everyone seems to be forgetting about a very simple observation from The Cathedral and the Bazaar: even though forking is possible, it's highly discouraged; it's one of the stronger taboos in the open source community.
The evidence that this taboo is still in effect is plentiful. So the chance of code forking should not be seen as an additional danger of OSS, since it only happens when the open source development model is already breaking down. In other words, it's a symptom, rather than a problem.
Regardless of whether or not people use Mozilla as a browser, it's an excellent idea for distros to ship it. The reason? Mozilla is an application development framework. I may prefer Lynx to Mozilla-the-browser (or any other GUI-based browser...), but that doesn't mean that I'll never want to run Komodo or any of the interesting bits being developed on top of Mozilla at mozdev. Shipping a copy of Mozilla with a distro allows the end users to take advantage of mozilla-based XP apps, regardless of whether they ever *touch* Seamonkey.
For the last time, THE BACKBONE IS NOT IN YOUR BASEMENT.
Technologies that are being developed for the core are not being designed for your house. They never have been and, unless the semi-hierarchical design of the core dissolves into fractal jelly (which would be pretty interesting, actually, but won't happen as long as it's privately owned), they never will be, because the scalability problem in last-mile deployment is an absolute bitch.
That said, QWest and others are swimming in backbone bandwidth -- they can't sell it all!
This memory cache bug is (imho) worth voting for. Other worthwhile bugs: mozilla should not need write-access to binary directory, url box doesn't update after a theme switch, and best of all, XBL is killing babies and german tourists.
As a side note, voting for a bug will add you to the cc list for that bug. So be ready.
Speaking of which... I didn't check out the Star Wars Lego project the first time around, and it appears that the URL has changed (poor guy probably got kicked off his previous hosting after the beating /. gave their servers...). I tracked it down by backing up a directory.. the english version appears to be now available at
http://www5b.biglobe.ne.jp/~mbsf/swo rde .htm.
I think you're giving Lyman Chapin a raw deal. He "works" for Verizon in the sense that he's a longtime employee (Chief Scientist) at BBN, which has been bought out so frequently in the last five years that it's no longer even news.
I also think Chapin is more of a technologist than you give him credit for. I was at the ICANN forum at HLS Monday night, and Chapin's answers sounded the most like Karl Auerbach's of any of the candidates. The difference is that Chapin is less radical -- he sees more shades of grey in the issues. Which is what has always bothered me a little about Auerbach: he is so combative that I am afraid he will be entirely ineffective as a board member. Since the at-large representation is so tiny compared the size of the board, would-be revolutionaries must be careful, subtle, and cunning.
To whom it may concern,
I have recently become aware of legal threats being made against Michael Rothwell by the law firm of Kenyon and Kenyon, representing Digital Convergence, makers of the :CueCat bar code scanner available at Radio Shack outlets. As Mr. Rothwell explains on his web page,
http://www.flyingbuttmonkeys.com/useofthingsyouown isnowillegal/
Kenyon & Kenyon has accused him of intellectual property infringement over his distribution of software for the Linux operating system that would interpret the output of a :CueCat scanner in the same manner as the currently (and freely) available software for Windows. This attitude is both misguided, in that the net effect of Mr. Rothwell's work would be increased usage of :CueCat scanners by people who would otherwise by unable to use it, as well as dangerous, in that it stands against the principles of reverse engineering which are a cornerstone of scientific advancement.
I am greatly distressed by the actions taken by Kenyon and Kenyon/Digital Convergence. I would appreciate a statement from Digital Convergence clarifying and explaining your position on the issue.
Thank you for your time,
ardran@hotmail.com
- ZDNet: Decision is "Shocking"
- San Jose Mercury News: DMCA comes back to haunt consumers
And so on. Also, Emmanuel Goldstein posted his comments on the decision on 2600 a couple days ago (I'm not sure if that's showed up onAvailable here. Kaplan refuses the recuse request!
If the MPAA's current attempts to stop 2600 from linking to DeCSS fall through, they can bust them for patent infringement!
This article at Salon summarizing this message from Napster -- Napster is using DMCA as a defense! Users who were fingered by Metallica are allowed under DMCA (assuming, that is, you count napster as an ISP) to submit a counternotification is they think they were incorrectly identified as copyright infringers. Unless Metallica pursues legal action against those individuals within ten days of the receipt of the counternotification, Napster must reinstate them!
I would be running this so fast if it supported the 5300. Unfortunately, the hardware is screwy enough that I'm locked out of Linux support. Last I checked, MkLinux supported the 5300 but did not support the SCSI port or the PCMCIA slot -- which means no network connectivity and no CD-ROM drive.
Note what Kaplan says:
He is clearly aware that he is protecting a monopoly. Unfortunately, he does not realize that he is proecting the wrong one. He thinks he is protecting the monopoly on distribution of content, which he's not -- as piracy still exists. What he's protecting (unintentionally, I assume) is the monopoly on *who* gets to view that content and *how*.What I (and a good number of people, I'd guess) want to know is, why didn't the counsel for the defense make these sorts of piracy arguments? I am somewhat confused as to why the plaintiffs got away with the classification of CSS as "a technological system that controls access to other copyrighted works" -- although here you get into the ambiguity I just described. Kaplan ends up ruling that CSS protects content -- but it really only ends up protecting playback, since anyone with some equipment can copy but only people with "legit" DVD technology can play it back. As far as I can tell from the various hearings/rulings that have been posted, this distinction is never made clear by the defense! There's a lot of exemptions they try to invoke, but Kaplan's reasons for rejecting them do not seem out of line. In fact, he appears to do a pretty decent job of assessing what has been presented to him. Did the defense throw it all away by ignoring its best argument? The recent LinuxWorld interview with Jon J. had the same complaint; i'm just echoing it here.
Wasn't there some suit where a bank was found liable for negligance after encrypting some sensitive transaction with only 56-bit encryption? I thought I read something like that. It seems like a reasonable precendent -- sooner or later, the content owners could figure out that it's going to be impossible to keep the code under wraps (you can buy it on a t-shirt at copyleft), and file a class action lawsuit for negligance on the part of the people who implemented the "hack-proof" DVD encryption system.
I don't know if that sort of thing would be a "win" for the world at large, though.
Looks like I should have read the zks page a bit more carefully :)
With that knowledge my original question would have been much different (if it had even existed). pseudonymous use rather than anonymous pretty much negates the effect I was implying. Thanks for the correction.
Things like ZKS make me wonder about what we are striving for in terms of privacy. There is the "real" world and the digital world -- is one meant to be an analogue of the other? Obviously, we want privacy because we don't want the digital world to be worse than the real world in certain ways. For instance, if we didn't encrypt credit card data during transactions, the digital world would be broken compared to the real when it comes to purchasing. Similarly, I want to be able to secure documents that I send to someone so that they are at least as good as taking certain "security" measures in the real world (registered mail, envelopes that aren't transparent, etc).
There seems to be a distinction between the desire for online security (which seeks to emulate the security we can find in the real world) and the desire for online privacy (which seeks to surpass the real). There is no real-world equivalent to what ZKS proposes. If I walk down the street, people may not recognize me (unless they know me), but I clearly have an identity -- I can be distinguished from someone else on the street by a third-party observer, even though the observer may not be able to identify either of us. ZKS would allow me to walk down the street and appear identical to everyone else -- not just nameless, but faceless.
Obviously, a lack of privacy dehumanizes; but couldn't an overabundance dehumanize as well? I'm interested in where exactly we're going with all this.