Slashdot Mirror

My router uses a floppy-based distro and that has the 2.2 kernel, and I really see no reason why I would want 2.4 on that old box. It isn't broken, so it doesn't need an upgrade to 2.4. You could say that it isn't very vulnerable to the mentioned problem either, because if someone got access to it, I would have a far bigger problem than them crashing my router. Others may have other uses for 2.2, so a fix of the mentioned problem is definately a Good Thing[tm] and nice news.

In short, [Movix is] a small (~5MB) linux distribution designed to be booted from a CD

However, last time I checked (April 2002), XFree86 didn't fully support my laptop's video chip. It's a NeoMagic MagicGraph on an Acer TravelMate 721TX (standard laptop for Rose-Hulman class of 2003), and I've only got its TV output to work in Windows. If I were to use Movix, I would have to buy an expensive VGA to NTSC down-converter or watch video on an LCD panel the same size as a US Letter size sheet of paper, which is microscopic by home theater standards. Do you know of any cheaper workarounds?

1.) Microsoft has already filed patent applications for this process (pretty likely, I think), in which case Lucky Green will be too late.

FYI: He has spoken with the people at Microsoft who should know about that sort of thing. (Google cache) They claimed no knowledge of related work.

Lucky's description of why he did it

--
"Bill Gates: Oh, I didn't get rich by writing a lot of checks!"

Here are some interesting links. Remember kids, it's not whoring if you're doing it anonymously!

http://www.mail-archive.com/cryptography@wasabisys tems.com/msg02554.html: Lucky Green discusses this issue

http://www.chiark.greenend.org.uk/pipermail/ukcryp to/2002-June/019444.html: Palladium and TCPA.

Google should yield even more interesting documents

• why Microsoft think Palladium couldn't be used to protect software copyright (as the subject of Lucky Green's patent)
• are there plans to move SCP functions into processor? any relation to Intel Lagrange TCPA enabled processor
• isn't it quite weak as someone could send different information to the SCP and processor, thereby being able to forge remote attestation without having to tamper with the SCP; and hence being able to run different TOR, observe trusted agents etc.
• at the bottom of the talk invite it says
  

  "Palladium" is not designed to provide defenses against hardware-based attacks that originate from someone in control of the local machine.

  but in this case how does it meet the claimed BORA prevention. Is it BORA prevention _presuming_ the local user is not interested to reconfigure his own hardware?
• Given the above quote (no defense against simple local hw attack) Will palladium really make any significant difference to DRM enforcement rates? Wouldn't the subset of the file sharing community who produce DVD rips still produce Pd DRM rips if the only protection is the assumption that the user won't make simple hardware modifications.

Lucky Green immediately wrote down several ways in which palladium could be used to do this, and filed patents on these methods.

Explain the above, then ask if Palladium have any method of preventing software piracy. Follow up by asking if they are utilizing the methods described in Lucky Green's patents.

Lucky Green immediately wrote down several ways in which palladium could be used to do this, and filed patents on these methods.

Explain the above, then ask if Palladium have any method of preventing software piracy. Follow up by asking if they are utilizing the methods described in Lucky Green's patents.

British-government-owned company involved: QinetiQ

Article from The Economist: "Free-space" optics
'"Free-space" optics requires no fibre' (oh, how I love that British English)

Quantum secure key exchange paper: here

A better place to ask this would be the cypherpunks or wasabisystems.com crypto mailing lists...

If you want some links on the Internet and politics, check out my "e-democracy resources" flyer: http://www.publicus.net/articles/edemresources.htm l

You can also join DO-WIRE: http://www.e-democracy.org/do

Here are some recent subject lines from the archive: http://www.mail-archive.com/do-wire@tc.umn.edu/

[DW] Vox Populi, Online and Downtown - NYTimes Article, Steven Clift

[DW] Die Online-Kampagnen der Parteien Event - Berlin - 19 Oct. 2002, Steven Clift

[DW] Correction - Oct 1 - Re: [DW] Die Online-Kampagnen der Parteien, Steven Clift

[DW] E-Gov Conference - Korea - 6-7 Nov 2002, Steven Clift

[DW] [IP] Student Blogs, School Cracks Down (fwd), Steven Clift

[DW] Carnegie Mellon Team Wins $2.1 Million to Build Online Forum forCitizen Deliberation (fwd), Steven Clift

[DW] Online Campaigning 2002: A Primer - Institute for Politics, Democracy and the Internet, Steven Clift

[DW] Publication - Making a case for local e-government (fwd), Steven Clift

[DW] Paris, Warsaw, Vilnius, Lisbon - Clift Speaking Schedule, Future Requests, Steven Clift

[DW] New Public Sphere: Technology and Politics in Sweden 1969-1999 - Lars Ilshammar PhD Dissertation, Steven Clift

[DW] Parliamentary E-Democracy Inquiry, Key Documents - State of Victoria, Australia, Steven Clift

[DW] US Election 2002 - Senate Campaign E-mail Lists - Wellstone at 25,000, Steven Clift

[DW] GILC Alert - China, Vietnam, Egypt, Iran ... and more, Steven Clift

[DW] Recycling Day - Two Items, Steven Clift

[DW] Voting Technology Glitches in Florida Primary, Steven Clift

[DW] MyBallot.net - New service from E-Democracy - details and press release, Steven Clift

[DW] Netactivism-Oriented Conference Calendar, Steven Clift

[DW] UK Political Participation Online Survey Results - From ERSC, Univof Salford, Steven Clift

Somebody go get a bunch of patents on anti-piracy googaws and then claim prior-art on all the companies attempting to put stuff like this in place.

Somebody go get a bunch of patents on anti-piracy googaws and then claim prior-art on all the companies attempting to put stuff like this in place.

During the summer, I suggested to my local Unix Users Group that we put together a campaign on campus dubbed "Software for Starving Students." The idea is that we would advocate the use of Free Software among the student body at BYU.

The ball got rolling, and we put together a CD image that we burned and handed out to students from a booth in the student center. We selected OpenOffice, Mozilla, The Gimp, BZFlag, and AbiWord in the most recent incarnation.

Last week, we gave out 400 copies of the CD from the booth. I mentioned to the group that if we did the math the way Microsoft does math, with each disc, we saved a student around $1,300. The 400 copies from last week combined with the 180 copies we gave out during the summer comes to around 3/4 of a million dollars with of savings to the student body! :-)

I, of course, took every opportunity to explain to passerby who accepted the disc about the multiple meanings of the word "free." The club president was making people promise to copy the software and give it to their friends in exchange for receiving the disc. Our Linux Install Fest last Saturday kept the classroom packed with students who heard about Linux and wanted us to install it on their computers for them.

I'm happy to say that we're doing our part to keep Linux from getting "stomped."

Possible Palladium patents from Microsoft:

• 6,330,670 Digital rights management operating system
• 6,327,652 Loading and identifying a digital rights management operating system

You can probably find others pending in Europe, where you have to disclose upon filing.

At a panel on Palladium at the USENIX Security Conference in August, Microsoft representatives claimed that there was no way Palladium could be used to enforce Digital Rights Management. In response, Lucky Green invented a bunch of ways Palladium could be used to enforce DRM and then filed for a patent.

1. http://www.mail-archive.com/cryptography@wasabisys tems.com/msg02506.html
2. http://www.mail-archive.com/cryptography@wasabisys tems.com/msg02554.html

Possible Palladium patents from Microsoft:

• 6,330,670 Digital rights management operating system
• 6,327,652 Loading and identifying a digital rights management operating system

You can probably find others pending in Europe, where you have to disclose upon filing.

At a panel on Palladium at the USENIX Security Conference in August, Microsoft representatives claimed that there was no way Palladium could be used to enforce Digital Rights Management. In response, Lucky Green invented a bunch of ways Palladium could be used to enforce DRM and then filed for a patent.

1. http://www.mail-archive.com/cryptography@wasabisys tems.com/msg02506.html
2. http://www.mail-archive.com/cryptography@wasabisys tems.com/msg02554.html

Look at a project like LyX. They were making great progress until they decided to have a unified GUI API. While they have been working on "GUI independence", very little improvements have been made to the actual application.

What I once considered of the most interesting applications is now spending all of development time on writing a GUI toolkit instead of improving the application.

Writing a unified API for a forms/graphics toolkit sounds great. What some people do not realize is that writing a unified API is really creating a third toolkit.

Check out this thread where Matthias Ettrich points that Netscape tried something similar with Navigator and failed and trying to make every happy makes no one happy.

A quote about users (not developers ) not wanting to use certain toolkits from Ettrich:

We still would avoid using toolkits at all (some users don't want to use XYZ toolkit, so better use Xlib. Ooops, some users don't want to use X, so better use Curses. Oops, some users have broken termcaps and cannot use Curses, better use stdout.

Thank you for your post. First, I'd like to say that I hoping you are who you claim to be. The fact that you're posting as an AC, and that google doesn't know about you, and that you're not listed as a fink developer at the fink project member list, and that no reference of you exists at the fink-devel archive gives me pause. Appologies if my skepticism turns out to be unwarranted. For the sake of this response, I will assume that you are not trolling and are who you claim to be.

That being the case, I'm afraid you've been misled by the comment that you initially responded to. That comment was posted by someone who extracted out a small section of a report that I sent to various mailing lists last night. The comment to which you responded has effectively deprived you of the relevant context surrounding the issue. My full report can be found at the archives for the three lists I sent it to:

• maco sx@perl.org archive
• perl5-porters@perl.org
• fink -devel@lists.sourceforge.net

This is caused by fink setting PERL5LIB to /sw/lib/perl5 which contains one or more compiled XS modules. Since perl 5.8.0 is not binary compatible with any prior perl release all XS modules will have to be recompiled in order to not experience the show-stopping dyld issue.

At this moment in time there have been several replies. One was a reply from Max Horn, a senior developer at fink. And, another reply was a reply from Michael Schwern, quality assurance manager for perl. Both acknowledge this as an issue and further outline the cause of this as well as possible permanent solutions.

The steps outlined in the 'RESOLUTION' section of the report are sane and well tested. They do indeed correct the issue that the report details, and should absolutely not cause any peripheral problems.

I'd like to request that if you further reply, please also do so on one of the three lists mentioned above so we can keep everyone in the loop.

Thank you!

Thank you for your post. First, I'd like to say that I hoping you are who you claim to be. The fact that you're posting as an AC, and that google doesn't know about you, and that you're not listed as a fink developer at the fink project member list, and that no reference of you exists at the fink-devel archive gives me pause. Appologies if my skepticism turns out to be unwarranted. For the sake of this response, I will assume that you are not trolling and are who you claim to be.

That being the case, I'm afraid you've been misled by the comment that you initially responded to. That comment was posted by someone who extracted out a small section of a report that I sent to various mailing lists last night. The comment to which you responded has effectively deprived you of the relevant context surrounding the issue. My full report can be found at the archives for the three lists I sent it to:

• maco sx@perl.org archive
• perl5-porters@perl.org
• fink -devel@lists.sourceforge.net

This is caused by fink setting PERL5LIB to /sw/lib/perl5 which contains one or more compiled XS modules. Since perl 5.8.0 is not binary compatible with any prior perl release all XS modules will have to be recompiled in order to not experience the show-stopping dyld issue.

At this moment in time there have been several replies. One was a reply from Max Horn, a senior developer at fink. And, another reply was a reply from Michael Schwern, quality assurance manager for perl. Both acknowledge this as an issue and further outline the cause of this as well as possible permanent solutions.

The steps outlined in the 'RESOLUTION' section of the report are sane and well tested. They do indeed correct the issue that the report details, and should absolutely not cause any peripheral problems.

I'd like to request that if you further reply, please also do so on one of the three lists mentioned above so we can keep everyone in the loop.

Thank you!

Thank you for your post. First, I'd like to say that I hoping you are who you claim to be. The fact that you're posting as an AC, and that google doesn't know about you, and that you're not listed as a fink developer at the fink project member list, and that no reference of you exists at the fink-devel archive gives me pause. Appologies if my skepticism turns out to be unwarranted. For the sake of this response, I will assume that you are not trolling and are who you claim to be.

That being the case, I'm afraid you've been misled by the comment that you initially responded to. That comment was posted by someone who extracted out a small section of a report that I sent to various mailing lists last night. The comment to which you responded has effectively deprived you of the relevant context surrounding the issue. My full report can be found at the archives for the three lists I sent it to:

• maco sx@perl.org archive
• perl5-porters@perl.org
• fink -devel@lists.sourceforge.net

This is caused by fink setting PERL5LIB to /sw/lib/perl5 which contains one or more compiled XS modules. Since perl 5.8.0 is not binary compatible with any prior perl release all XS modules will have to be recompiled in order to not experience the show-stopping dyld issue.

At this moment in time there have been several replies. One was a reply from Max Horn, a senior developer at fink. And, another reply was a reply from Michael Schwern, quality assurance manager for perl. Both acknowledge this as an issue and further outline the cause of this as well as possible permanent solutions.

The steps outlined in the 'RESOLUTION' section of the report are sane and well tested. They do indeed correct the issue that the report details, and should absolutely not cause any peripheral problems.

I'd like to request that if you further reply, please also do so on one of the three lists mentioned above so we can keep everyone in the loop.

Thank you!

The release notes for perl 5.8.0 indicate:

"Perl 5.8 is not binary compatible with any earlier Perl release, XS MODULES WILL HAVE TO BE RECOMPILED!"

Mac OS X users that have fink installed may experience the following error when executing certain perl operations (see 'EXAMPLE').

[snip]

The error is caused by the following sequence of events:

• 1 - a .bashrc (or other shell rc file) sources /sw/bin/init.[c]sh
• 2 - init.[c]sh sets PERL5LIB to /sw/lib/perl5
• 3 - /sw/lib/perl5 contains Storable (the only compiled perl module, included by default, to my knowledge), and possibly other XS modules. Since Storable is a compiled XS module that was compiled with a prior version of perl that is binary incompatible with perl 5.8.0 it will be necessary to recompile Storable (see 'RESOLUTION').

Fink stable currently includes the following six XS modules. If any of these were installed prior to installing 5.8.0 you will likely experience the dyld issue.

• - DBD::Mysql
• - DBI
• - Digest::MD5
• - MacOSX::File
• - Storable
• - Term::ReadKey

You will also experience the dyld issue if any other XS modules are contained within the /sw/lib/perl5 directory. That is, XS modules from fink unstable or another source.

From there, the remedy suggested roughly matches that which Ellem posted earlier, and which you are objecting to now. In his .sig footer, Folson identifies himself as "CPAN Tester for Mac OS X", and the advice he gives sounds credible.

If the advice summarized in these postings is unsound, do you have any counter suggestions that address the issues raised by Foxson's post? Or are those issues themselves phantoms? I didn't realize that Apple had a dedicated Fink developer, but seeing as that seems to be a part of your job description, a clarification of this matter would be very much appreciated -- and you might want to include the mailing lists mentioned above so that the users/developers will know what's going on "from the horse's mouth", so to speak.

Thanks a lot.

The release notes for perl 5.8.0 indicate:

"Perl 5.8 is not binary compatible with any earlier Perl release, XS MODULES WILL HAVE TO BE RECOMPILED!"

Mac OS X users that have fink installed may experience the following error when executing certain perl operations (see 'EXAMPLE').

[snip]

The error is caused by the following sequence of events:

• 1 - a .bashrc (or other shell rc file) sources /sw/bin/init.[c]sh
• 2 - init.[c]sh sets PERL5LIB to /sw/lib/perl5
• 3 - /sw/lib/perl5 contains Storable (the only compiled perl module, included by default, to my knowledge), and possibly other XS modules. Since Storable is a compiled XS module that was compiled with a prior version of perl that is binary incompatible with perl 5.8.0 it will be necessary to recompile Storable (see 'RESOLUTION').

Fink stable currently includes the following six XS modules. If any of these were installed prior to installing 5.8.0 you will likely experience the dyld issue.

• - DBD::Mysql
• - DBI
• - Digest::MD5
• - MacOSX::File
• - Storable
• - Term::ReadKey

You will also experience the dyld issue if any other XS modules are contained within the /sw/lib/perl5 directory. That is, XS modules from fink unstable or another source.

From there, the remedy suggested roughly matches that which Ellem posted earlier, and which you are objecting to now. In his .sig footer, Folson identifies himself as "CPAN Tester for Mac OS X", and the advice he gives sounds credible.

If the advice summarized in these postings is unsound, do you have any counter suggestions that address the issues raised by Foxson's post? Or are those issues themselves phantoms? I didn't realize that Apple had a dedicated Fink developer, but seeing as that seems to be a part of your job description, a clarification of this matter would be very much appreciated -- and you might want to include the mailing lists mentioned above so that the users/developers will know what's going on "from the horse's mouth", so to speak.

Thanks a lot.

It's not yet easy to manually remap keys in OSX, (many do with XDarwin) but you can do it by text-editing the appropriate xmodmap file you're using (Warning: the DMCA may seriously repercussions if you live in the US and try to do this... check out the scary disclaimer on this how-to for remapping keys with XDarwin!!) This really should be something user-changeable in the System Prefs itself, under "Keyboard" and hopefully will be in Jaguar or not too long after.

In OSX, you could manually re-map the modmap file for the appropriate keymap you want to change out of the list of keymaps in the /System/Library/Keyboards/ directory (pick yours, though I think there are even more now with 10.1.5):

/System/Library/Keyboards
/System/Library/Keyboards/ACE.keyboard
/System/Library/Keyboards/ACE_102.keyboard
/System/Library/Keyboards/Apple.keyboard
/System/Library/Keyboards/AppleAdjJIS.keyboard
/System/Library/Keyboards/AppleExt.keyboard
/System/Library/Keyboards/AppleII.keyboard
/System/Library/Keyboards/AppleISO.keyboard
/System/Library/Keyboards/AppleISOExt.keyboard
/System/Library/Keyboards/AppleJIS.keyboard
/System/Library/Keyboards/Belge.keymapping
/System/Library/Keyboards/Canadian-CSA.keymapping
/System/Library/Keyboards/Canadian-ISO.keymapping
/System/Library/Keyboards/Canadien.keymapping
/System/Library/Keyboards/Dansk.keymapping
/System/Library/Keyboards/Deutsch.keymapping
/System/Library/Keyboards/Espanol.keymapping
/System/Library/Keyboards/Francais.keymapping
/System/Library/Keyboards/HIL.keyboard
/System/Library/Keyboards/HIL_ITF_JAPANESE.keyboa rd
/System/Library/Keyboards/HIL_JIS.keyboard
/System/Library/Keyboards/HP_MiniDIN_JIS.keyboard
/System/Library/Keyboards/Italiano.keymapping
/System/Library/Keyboards/Japanese.keymapping
/System/Library/Keyboards/LatinoAmericano.keymapp ing
/System/Library/Keyboards/MSN.keyboard
/System/Library/Keyboards/Netherlands.keymapping
/System/Library/Keyboards/NeXT.keyboard
/System/Library/Keyboards/Norsk.keymapping
/System/Library/Keyboards/OADG_A01.keyboard
/System/Library/Keyboards/OADG_AX.keyboard
/System/Library/Keyboards/OADG_J3100.keyboard
/System/Library/Keyboards/Portugues.keymapping
/System/Library/Keyboards/Schweizer.keymapping
/System/Library/Keyboards/Suisse.keymapping
/System/Library/Keyboards/Svenska.keymapping
/System/Library/Keyboards/TYPE5.keyboard
/System/Library/Keyboards/TYPE5_Compact.keyboard
/System/Library/Keyboards/TYPE5_Compact_JAPANESE. keyboard
/System/Library/Keyboards/TYPE5_Compact_UNIX.keyb oard
/System/Library/Keyboards/TYPE5_JAPANESE.keyboard
/System/Library/Keyboards/TYPE5_PC.keyboard
/System/Library/Keyboards/TYPE5_TUV_EUROPEAN.keyb oard
/System/Library/Keyboards/UK.keymapping
/System/Library/Keyboards/USA.keymapping
/Volumes/Mac/System/Library/Keyboards
/Volumes/Mac/System/Library/Keyboards/ACE.keyboar d
/Volumes/Mac/System/Library/Keyboards/ACE_102.key board
/Volumes/Mac/System/Library/Keyboards/Apple.keybo ard
/Volumes/Mac/System/Library/Keyboards/AppleAdjJIS . eyboard
/Volumes/Mac/System/Library/Keyboards/AppleExt.ke yboard
/Volumes/Mac/System/Library/Keyboards/AppleII.key board
/Volumes/Mac/System/Library/Keyboards/AppleISO.ke yboard
/Volumes/Mac/System/Library/Keyboards/AppleISOExt . eyboard
/Volumes/Mac/System/Library/Keyboards/AppleJIS.ke yboard
/Volumes/Mac/System/Library/Keyboards/Belge.keyma pping
/Volumes/Mac/System/Library/Keyboards/Canadian-CS A.keymapping
/Volumes/Mac/System/Library/Keyboards/Canadian-IS O.keymapping
/Volumes/Mac/System/Library/Keyboards/Canadien.ke ymapping
/Volumes/Mac/System/Library/Keyboards/Dansk.keyma pping
/Volumes/Mac/System/Library/Keyboards/Deutsch.key mapping
/Volumes/Mac/System/Library/Keyboards/Espanol.key mapping
/Volumes/Mac/System/Library/Keyboards/Francais.ke ymapping
/Volumes/Mac/System/Library/Keyboards/HIL.keyboar d
/Volumes/Mac/System/Library/Keyboards/HIL_ITF_JAP ANESE.keyboard
/Volumes/Mac/System/Library/Keyboards/HIL_JIS.key board
/Volumes/Mac/System/Library/Keyboards/HP_MiniDIN_ JIS.keyboard
/Volumes/Mac/System/Library/Keyboards/Italiano.ke ymapping
/Volumes/Mac/System/Library/Keyboards/Japanese.ke ymapping
/Volumes/Mac/System/Library/Keyboards/LatinoAmeri cano.keymapping
/Volumes/Mac/System/Library/Keyboards/MSN.keyboar d
/Volumes/Mac/System/Library/Keyboards/Netherlands . eymapping
/Volumes/Mac/System/Library/Keyboards/NeXT.keyboa rd
/Volumes/Mac/System/Library/Keyboards/Norsk.keyma pping
/Volumes/Mac/System/Library/Keyboards/OADG_A01.ke yboard
/Volumes/Mac/System/Library/Keyboards/OADG_AX.key board
/Volumes/Mac/System/Library/Keyboards/OADG_J3100. keyboard
/Volumes/Mac/System/Library/Keyboards/Portugues.k eymapping
/Volumes/Mac/System/Library/Keyboards/Schweizer.k eymapping
/Volumes/Mac/System/Library/Keyboards/Suisse.keym apping
/Volumes/Mac/System/Library/Keyboards/Svenska.key mapping
/Volumes/Mac/System/Library/Keyboards/TYPE5.keybo ard
/Volumes/Mac/System/Library/Keyboards/TYPE5_Compa ct.keyboard
/Volumes/Mac/System/Library/Keyboards/TYPE5_Compa ct_JAPANESE.keyboard
/Volumes/Mac/System/Library/Keyboards/TYPE5_Compa ct_UNIX.keyboard
/Volumes/Mac/System/Library/Keyboards/TYPE5_JAPAN ESE.keyboard
/Volumes/Mac/System/Library/Keyboards/TYPE5_PC.ke yboard
/Volumes/Mac/System/Library/Keyboards/TYPE5_TUV_E UROPEAN.keyboard
/Volumes/Mac/System/Library/Keyboards/UK.keymappi ng
/Volumes/Mac/System/Library/Keyboards/USA.keymapp ing

But of course, there's will soon be an easier way if you don't want to muck about. Michael Baltak's GPL'd DoubleCommand Deluxe, under development and hopefully to be released soon should offer a good amount of flexibility in custom keymapping for free. Or, to kill the bug with a sledgehammer you could get a macro utility like Quickeys from CE Software and map the Caps Lock key to trigger a one-key "shortcut" of your choosing (ie: map it to another key)

I wouldn't worry too much about paying to upgrade the OS to Jaguar, Apple so far has been fairly good about this sort of stuff. You could also wait a few months until Jaguar comes out and you might not need a keymapping utility at all, if you can bear to wait.

It is all about outreach. With E-Democracy we host local community discussions that have a tremendously diverse amount of expression. We don't know who our 800 participants are compared to say the census, but we know that 800 people in any geographic community discussing local issues is very important and empowering. Take a look and judge for yourself.

In terms of gender, age, neighborhood, ethnicity, income, etc. we can alway have more diversity and we are actually working on some grant proposals to hit various community events in-person to recruit for our forums. However, these community forums really only matter to various communities when they themselves think they matter. Right now the "active citizens" of Minneapolis, St. Paul, and Winona understand the real world political agenda setting power of online discussions where community leaders/the media participate/lurk, while many of diverse and newer immigrant communities haven't caught on yet. They will as they come to use all forms of media and communication to increase their power in the community ... or they won't if it doesn't appeal to them or relate in someway to their everyday life.

Steven Clift

Great question.

The world is run by those who show up. In Minneapolis 13 council members represent 380,000 people. We have 800 active citizens including many of the council members, local journalists and hundreds of people active in their neighborhoods. Our goal is to open up community discussions - put an online forum in the middle of real politics to make it more accessible and transparent. What is better, 13 council members with little city-wide press coverage in a metro-media market only or an open forum that allows anyone with good ideas to see their opinions spread and perhaps help set/influence the agenda?

More information including links to articles in the local paper about the forum.

Cheers, Steven Clift

In the specific area of online discussions in local communities we need your advice. Related discussions on this has occured on the Democracies Online Code Network e-mail list for civic-minded techies.

We use e-mail lists. They work. Our participants love them. They need to work better with the web. We do not need a web-based system that treats e-mail participants as second class citizens. Our thousands of users won't make the transition - and we are not going to sacrifice our sustainable non-profit model that has worked for eight years.

In an ideal world someone would create an e-mail/web system akin to a cleaner, crisper Yahoogroups but something better that you can host on your own domain.

What we have:
Mailman with additional archives using Mail-Archive. (We are moving our last few lists off Yahoogroups.)
Basic web pages with forum information, hundreds of Minnesota-specific political links, and special election/candidate link directories.

What we need in term of priority:

1. Advanced Web Archives and Subject Line Syndication - Improved web access to our e-mail forum archives including the ability to post via the web to -recent- messages by "no e-mail" members, the ability to automatically display via RSS the most recent subject lines from our various lists on our home page/other key web pages to posts in the archives. Hypermail, Mhonarc just don't cut it. They were great in their time, but we need something that takes advantage of MySQL, allows for linear display of posts in the same thread, and other tools. More on this ....

2. Member Preferences Page - A single page like Yahoogroups where someone can control their settings on the all the lists they subscribe to on our server. We'd also like to allow people to recommend new e-mail lists for their local communities and essentially reserve a spot by letting us know that they are interested in a specific city/county/region or statewide public policy issue. We do not open community discussions without at least 100 participants and have an extensive public outreach process that goes with each new lists (i.e. online and in-person recruiting). If we recruit 50,000 "e-citizens" across Minnesota we need to use technology to help shape our forum development priorities.

3. Member Directory with Archive Links - (Again, we are not interested/able to use a web-centric conferencing system) This is where the web can complement our e-mail environment. I'd like each member to have the option to share information about themselves (our rules for posting including signing your real name, we have to use personal accountability in our model for online political discourse or everything would be pure crap). I'd like each e-mail that goes through the list server to insert their member directory page URL. From the member-directory page I'd to present both the information provided by the participants but also links to their recent posts across our various forums. And perhaps ...

4. Participant Ratings - With unmoderated mailing lists, rating each post before it is delivered is impossible. Even if we moderate our lists, a multiple moderater bottle neck among our mostly non-techie audience would cause major delays in discourse. So ... one idea is to allow participants to optionally vote +1 substance, -1 for style for any post after it is distributed. We don't want to create a situation where people simply vote against people of other ideologies (we have a cherished and extremely rare cross-political spectrum audience) so some sort of forumula would have to be developed to give various weight to votes (i.e. repeat votes by one individual against another count less over time) and always bring the rating toward zero over time. Oh - why do this? While our unmoderated lists to have forum managers who have the power to sanction participants who violate our rules and guidelines, we ultimately believe that self-regulation, and group self-governance is our strength. We walk on a tight rope between chaos and control in order to keep and build our participatory civic audience based on our democratic and community purpose.

5. E-Newsletter Distributed Content Management System - We have currently have 4,000+ people on our general announcement list (over next five years we'd like it to raise it to 50,000 or 1% of Minnesotans). We are planning a once or twice monthly e-mail newsletter with various content sections. I'd like to give our volunteer editor the tools to allow other volunteers to submit content (i.e. event lists, Minnesota political history this month, quotes of the month from our forums) on a regular basis into key sections of the newsletter and assuming that some content will be to long for e-mail newsletter format, something that integrates with a longer web section. 6. Mailman Advancements? Or another list packages. As an organization we'd like the ability to send one message to everyone on one of our lists without double posting. For our volunteer list managers we need the ability to quickly delete all the non-member (mostly spam) posts in one or two clicks and not have to click and select every post. What list packages do people recommend?

If you actually read this far, you should join the DO-CODE e-mail list that I mentioned above.

Cheers, Steven Clift

They successfully sued people in court (Schlafly), and settled where it looked plausible that litigation would have invalidated the patent (Cylink).

upon analysis it will seem pretty clear that that harm was the result not so much of the patent itself, but rather of the misinterpretation of the meaning of the patent by one party or another.

And yes, SSL was available; in Web browsers and Web servers manufactured by 2 deep-pocketed companies, and a few smaller companies selling binary only Apache-based servers.

So, you could use SSL for web browsing if you wanted to use one of only two browser implementations, and for Web serving only if you had $$$. RSARDI refused to license the *use* of the patent without licensing their expensive implementation (it was never clear to me in discussions with them and/or 3rd parties whether you could use some other implementation if you paid the $$$ for theirs), so using SSL for any purpose other than web browsing or serving in a commercial setting for a small company was virutally impossible -- legally, anyway.

So, I think my claim that the patent prevented innovation is reasonably sound and that the fault was due to the patent system which included the patent and its prevailing interpretation, correct or not.

Only slightly on topic but (IMHO) interesting anyway, a long-ago thread on openssl-users about RSADSI's indimidation, licensing, standards manipulation and other nasty practices including: this, this, this and this is available for you reading pleasure at this site.

They successfully sued people in court (Schlafly), and settled where it looked plausible that litigation would have invalidated the patent (Cylink).

upon analysis it will seem pretty clear that that harm was the result not so much of the patent itself, but rather of the misinterpretation of the meaning of the patent by one party or another.

And yes, SSL was available; in Web browsers and Web servers manufactured by 2 deep-pocketed companies, and a few smaller companies selling binary only Apache-based servers.

So, you could use SSL for web browsing if you wanted to use one of only two browser implementations, and for Web serving only if you had $$$. RSARDI refused to license the *use* of the patent without licensing their expensive implementation (it was never clear to me in discussions with them and/or 3rd parties whether you could use some other implementation if you paid the $$$ for theirs), so using SSL for any purpose other than web browsing or serving in a commercial setting for a small company was virutally impossible -- legally, anyway.

So, I think my claim that the patent prevented innovation is reasonably sound and that the fault was due to the patent system which included the patent and its prevailing interpretation, correct or not.

Only slightly on topic but (IMHO) interesting anyway, a long-ago thread on openssl-users about RSADSI's indimidation, licensing, standards manipulation and other nasty practices including: this, this, this and this is available for you reading pleasure at this site.

They successfully sued people in court (Schlafly), and settled where it looked plausible that litigation would have invalidated the patent (Cylink).

upon analysis it will seem pretty clear that that harm was the result not so much of the patent itself, but rather of the misinterpretation of the meaning of the patent by one party or another.

And yes, SSL was available; in Web browsers and Web servers manufactured by 2 deep-pocketed companies, and a few smaller companies selling binary only Apache-based servers.

So, you could use SSL for web browsing if you wanted to use one of only two browser implementations, and for Web serving only if you had $$$. RSARDI refused to license the *use* of the patent without licensing their expensive implementation (it was never clear to me in discussions with them and/or 3rd parties whether you could use some other implementation if you paid the $$$ for theirs), so using SSL for any purpose other than web browsing or serving in a commercial setting for a small company was virutally impossible -- legally, anyway.

So, I think my claim that the patent prevented innovation is reasonably sound and that the fault was due to the patent system which included the patent and its prevailing interpretation, correct or not.

Only slightly on topic but (IMHO) interesting anyway, a long-ago thread on openssl-users about RSADSI's indimidation, licensing, standards manipulation and other nasty practices including: this, this, this and this is available for you reading pleasure at this site.

They successfully sued people in court (Schlafly), and settled where it looked plausible that litigation would have invalidated the patent (Cylink).

upon analysis it will seem pretty clear that that harm was the result not so much of the patent itself, but rather of the misinterpretation of the meaning of the patent by one party or another.

And yes, SSL was available; in Web browsers and Web servers manufactured by 2 deep-pocketed companies, and a few smaller companies selling binary only Apache-based servers.

So, you could use SSL for web browsing if you wanted to use one of only two browser implementations, and for Web serving only if you had $$$. RSARDI refused to license the *use* of the patent without licensing their expensive implementation (it was never clear to me in discussions with them and/or 3rd parties whether you could use some other implementation if you paid the $$$ for theirs), so using SSL for any purpose other than web browsing or serving in a commercial setting for a small company was virutally impossible -- legally, anyway.

So, I think my claim that the patent prevented innovation is reasonably sound and that the fault was due to the patent system which included the patent and its prevailing interpretation, correct or not.

Only slightly on topic but (IMHO) interesting anyway, a long-ago thread on openssl-users about RSADSI's indimidation, licensing, standards manipulation and other nasty practices including: this, this, this and this is available for you reading pleasure at this site.

They successfully sued people in court (Schlafly), and settled where it looked plausible that litigation would have invalidated the patent (Cylink).

upon analysis it will seem pretty clear that that harm was the result not so much of the patent itself, but rather of the misinterpretation of the meaning of the patent by one party or another.

And yes, SSL was available; in Web browsers and Web servers manufactured by 2 deep-pocketed companies, and a few smaller companies selling binary only Apache-based servers.

So, you could use SSL for web browsing if you wanted to use one of only two browser implementations, and for Web serving only if you had $$$. RSARDI refused to license the *use* of the patent without licensing their expensive implementation (it was never clear to me in discussions with them and/or 3rd parties whether you could use some other implementation if you paid the $$$ for theirs), so using SSL for any purpose other than web browsing or serving in a commercial setting for a small company was virutally impossible -- legally, anyway.

So, I think my claim that the patent prevented innovation is reasonably sound and that the fault was due to the patent system which included the patent and its prevailing interpretation, correct or not.

Only slightly on topic but (IMHO) interesting anyway, a long-ago thread on openssl-users about RSADSI's indimidation, licensing, standards manipulation and other nasty practices including: this, this, this and this is available for you reading pleasure at this site.

rpm-rebuilder

There are two popular IM clients for OS X-- Fire and Proteus.

From the author of Fire, on the Fire development mailing list


{#} Replies are directed back to fire@firelist.org
{#} To reply to the author, write to Eric Peyton

Also to note some other "relationships" ...

Proteus uses many of the same underlying libraries but is violating the
GPL by not releasing the source to code to either those libraries or the
application itself.

Fire releases all of it's source code as specified by the GPL.

Proteus may one day attempt to charge users for it's application.

Fire will never attempt to do such a thing.

Proteus has no open source contributions.

Fire is mostly open source contributions at this time.

Eric


(a discussion on Proteus's site is here. The author says "As of now, proteus is in violation of GPL.")

Note that there have been rumors of an RSA cracker built by a three-letter agency in custom silicon before this, but until analyzing Bernstein's paper I had always dismissed them as ridiculous paranoid fantasies. Now it looks like such a device is entirely feasible and, in fact, likely.

Now let me guess...

It's disguised to look like an answering machine, right?

-S

here's a thread (J2EE considered harmful) on the jakarta-general list that precipitated the Apache statement.

There is an article in the September 2001 issue of Secure Computing Magazine. (a "trade rag" - so it never says anything bad about a potential advertiser)

Pay Your Dues by Jay Heiser in Information Security Magazine is also worth reading.

A small reader survey, May 2001 - Talkback.

Security Focus offers several mailing lists that you may wish to subscribe to, or at least read the archives about. In particular Security Certification, CISSP Study, and security-basics. One recent message is certainly worth reading. Similar questions have been also asked in cryptography and firewall wizards - Nov 2001 mailing lists, and I believe has come up several times before.

A review of one IS manager's experience from Computerworld secuirty Column.

A so-so review of different security certificates from CertCities.

The main points I would make are choose a certificate that has the right focus for your career. CISSP is the best known cert, but it is aimed at IT/IS Security Managers and Consultants not at senior technologists / engineers / "in the trenchs" types. The best features of this is requiring 3 years of computer / network / audit security experience and having a broad overview of computing security (the 10 common bodies of knowledge, CBK). This makes it out of reach for many people new to info sec, and that's okay, they likely should focus on another certification anyhow. Next is the SANS/GIAC certificates which are more focused and hands on. The best feature is that they require a "practical" part to the certification, which is doubly good because it is not just exam cramming and lets the student practice her communicaton skills, which is important in the security field since you should be able to work in a team and with others (non-technical other) in an organization outside your team for the common benefit of the business.

Certifications tend to be expensive to get, and don't forget most of them have requirements for maintaince such as x number of contuning education credits, re-examinations, or conference attendance. This is a mixed bag, it is good that it justifies staying up to date, but it can also be very expensive for a member working as a new contractor or for a small company that isn't pre-IPO throwing money around.

2) Right, right. So lets go all the way and just forgo BFS completely.

Two words: public domain.

PAPER CUTS: The Golden Fleece

http://www.mail-archive.com/license-discuss@openso urce.org/msg01433.html

http://www.interesting-people.org/archives/interes ting-people/199901/msg00052.html

Unfortunately ipchains doesn't seem to handle thousands of deny rules very well.

Take a look at this post to the debian-security mailing list for another script and some insights.

If you want a ~$600 DVD recorder, you already have a couple of other choices.

At $629 on PriceWatch, the Pioneer DVR-A03 that a number of posters have already mentioned writes DVD-R at 2X, DVD-RW at 1X, as well as CD-R and CD-RW.

At $535 on PriceWatch, the Panasonic LF-D311 writes DVD-R at 1X and DVD-RAM (1X for 2.6GB, 2X for 4.7GB), as well as reading the usual CD formats, but apparently not writing any CD format whatsoever.

Currently, to the best of my knowledge, the only Linux software that can drive DVD writes is proprietary (sorry, there really is no good link for it). I am not sure whether complete information on how to drive these DVD writes is given in the SCSI-3 standards on www.t10.org or whether some additional information is needed. Any pointers to this information would be appreciated, as I might get ambitious one of these days and try to hack cdrecord or cdwrite to control these drives if nobody beats me to it.

This may be somewhat risky because you are potentially leaving yourself open to lawsuits. Of course, you don't have to use the GPL, but it is better to use some sort of license which disclaims all warranty to be on the safe side (e.g., like the Apache or X11 licenses).

There was a discussion of this on an apache mailing list a little while ago.

You apparently don't know about Option82 and 'lease limit', which will let you limit the DHCP leases a customer's connection will let you receive.
http://www.mail-archive.com/dhcp-server@isc.org/ms g11269.html

For example, Mandrake 7.2 (downloadable version) shipped with a bad ipop3d. I eventually fixed the problem but Mandrake never did - the package that came with the retail Mandrake 7.2 worked fine.

Mandrake 8.0 (downloadable version) shipped with kernel source which wouldn't compile the modules unless you did a "make mrproper" which killed the default config. I'm not sure that everybody confident enough to rebuild the kernel would think to do a "make mrproper". To the best of my knowledge, this hasn't been fixed either. I don't think it's a problem with Mandrake 8 retail.

I still use Mandrake because I like it... But if you get the downloadable version, expect complications.

P.S. if you're reading this Dan, do you need an electrophysiologist? G. (LOL)

count yourself bloody lucky that these companies give you their work for free.

Go and have a look back at, for example, the old Mandrake Cooker archives (I'm a list member there). Time and time again, people wrote to say ``Hey, I really like your distro but downloaded it instead of buying a boxed set because the box was [too slow/unavailable in my area/Had extras I didn't want/etc]. Is there some way I can give you some money to offset the cost of providing that free download?'' Mandrake caved in after about a year of this and provided the donations link.

I am left with the impression that Mandrake management didn't quite believe it, until the money started flowing...

Does anybody know what the Automatic Stanford Checker is?

Seems that some guys at Stanford wrote some programs to scan the kernel source for various potential bugs, so that the maintainers could check them out. Here are some examples from Junfeng Yang and Dawson Engler. If you search the LKML archives for "CHECKER", you'll surely find more.

Does anybody know what the Automatic Stanford Checker is?

Seems that some guys at Stanford wrote some programs to scan the kernel source for various potential bugs, so that the maintainers could check them out. Here are some examples from Junfeng Yang and Dawson Engler. If you search the LKML archives for "CHECKER", you'll surely find more.

Does anybody know what the Automatic Stanford Checker is?

Seems that some guys at Stanford wrote some programs to scan the kernel source for various potential bugs, so that the maintainers could check them out. Here are some examples from Junfeng Yang and Dawson Engler. If you search the LKML archives for "CHECKER", you'll surely find more.

Does anybody know what the Automatic Stanford Checker is?

Seems that some guys at Stanford wrote some programs to scan the kernel source for various potential bugs, so that the maintainers could check them out. Here are some examples from Junfeng Yang and Dawson Engler. If you search the LKML archives for "CHECKER", you'll surely find more.

Does anybody know what the Automatic Stanford Checker is?

Seems that some guys at Stanford wrote some programs to scan the kernel source for various potential bugs, so that the maintainers could check them out. Here are some examples from Junfeng Yang and Dawson Engler. If you search the LKML archives for "CHECKER", you'll surely find more.